Proj experiments by jdroenner · Pull Request #1110 · geo-engine/geoengine

jdroenner · 2026-01-13T16:39:01Z

I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Here is a brief summary of what I did:

…-based-queries-rebase

michaelmattig · 2026-01-19T16:48:33Z

datatypes/src/util/geodesy_projector.rs

+impl Transformer<geodesy::ctx::Minimal> {
+    pub fn pro4_string_modifications(code: u16, proj4: &str) -> String {
+        match (code, proj4) {
+            (3857, _) => proj4.replace("merc", "webmerc"),


guess this should be documented

also: are there any other cases that require this?

would it make sense to curate this in the crs definitions crate?

yes. This is a very complex topic. I do not know if other projections need this. Also the crs_definitions crate is not bound to Geodesy and as i see it this is something only geodesy requires. We should upstream this to the geo-geodesy crate but there are other things that needs to be done there first.

michaelmattig · 2026-01-19T16:49:46Z

datatypes/src/util/geodesy_projector.rs

+            });
+        }
+
+        if source.code() > u32::from(u16::MAX) {


isnt GOOGLE crs larger than u16?

yes but it is not a real EPSG code. This would need something handling "alias" names

michaelmattig · 2026-01-19T16:50:35Z

datatypes/src/util/geodesy_projector.rs

+    }
+}
+
+impl<C: geodesy::ctx::Context> Transformer<C> {


are there even multiple geodesy context implementations?

yes there are two and they plan a "ParallelContext" upstream

michaelmattig · 2026-01-19T16:56:02Z

datatypes/src/util/mixed_projector.rs

+};
+
+pub enum MixedCoordinateProjector {
+    ProjProjector(super::proj_projector::ProjCoordinateProjector),


unrelated to this line: in general we need to think about whether the approach to use geodesy because of performance and fall back to proj only when geodesy does not support a projection suits all our use cases. can we be reasonably certain that we will not need some crs in the future that geodesy does not support and where we need good performance? because then we would need to implement proj context reusage anyway.

well this is a very interesting question. One "projection" not implemented in Godesy is the GEOS projection. However, we could create a PR if we need it (it is not very complex). Basically all non-EPSG projections are not supported but this is not really Geodesys fault. Geodesy should add a WKT parser... Currently it requires the proj4 strings and we get them from crs-definitions and there are only EPSG codes listed.

currently, all projections we use should work. However, if someone uses DHDN then we have a problem.

michaelmattig · 2026-01-19T16:58:29Z

datatypes/src/util/geodesy_projector.rs

+pub struct Transformer<C: geodesy::ctx::Context = geodesy::ctx::Minimal> {
+    ctx: C,
+    source_crs: u16,
+    source: geodesy::ctx::OpHandle,


why store the ophandle?

this is what you use to call the "fwd" and "rew" projection

michaelmattig · 2026-01-19T16:58:48Z

datatypes/src/util/geodesy_projector.rs

+    ctx: C,
+    source_crs: u16,
+    source: geodesy::ctx::OpHandle,
+    source_latlon: bool,


is this not derivable fro the source/target crs?

well i derive it by looking for "latlong" in the proj4 string. I do not think there is a better way at the moment. Since we use this for every coordinate we should remember this instead of the proj string. However, if you see a better way please let me know :)

michaelmattig · 2026-01-19T16:59:08Z

datatypes/src/util/geodesy_projector.rs

+#[derive(Debug, Clone)]
+pub struct Transformer<C: geodesy::ctx::Context = geodesy::ctx::Minimal> {
+    ctx: C,
+    source_crs: u16,


is this always epsg code? are all relevant projections describable by this?

Geodesy currently parses the proj4 strings to create objects. We need to get the proj4 strings somewhere and the easiest way is to get them from the crs-definitions crate (this is what geo-geodesy does). The crs-definitions crate only has EPSG codes at the moment. We would need to add more e.g. ESRI if we need them

michaelmattig · 2026-01-19T17:00:00Z

datatypes/src/util/geodesy_projector.rs

+        let source_latlon = source_def.proj4.starts_with("+proj=longlat");
+        let target_latlon = target_def.proj4.starts_with("+proj=longlat");
+
+        let source_proj_string = Self::pro4_string_modifications(source_crs, source_def.proj4);


can't we store the definitions "correctly" in the first place instead of modifying them each time?

of the crs-definitions should be useable by other crates then no. If we want them only for geodesy then yes.

michaelmattig · 2026-01-19T17:01:04Z

datatypes/src/util/geodesy_projector.rs

+
+    pub fn transform_coord(&self, coord: Coordinate2D) -> Result<Coordinate2D, Error> {
+        let mut geodesy_coord = if self.source_latlon {
+            [geodesy::coord::Coor2D::gis(coord.x, coord.y)]


so we need to copy all data. does proj do this too?

i think we can also implement a trait. We need to look that up.

michaelmattig · 2026-01-19T17:02:13Z

datatypes/src/util/geodesy_projector.rs

+            [geodesy::coord::Coor2D::raw(coord.x, coord.y)]
+        };
+        self.ctx
+            .apply(self.source, geodesy::Direction::Inv, &mut geodesy_coord)?;


why does geodesy look up the op in the context each time? can we prevent this? we always use the same op but it does a registry lookup each time

it is a very strange design. We would need to look into this.

michaelmattig · 2026-01-19T17:03:21Z

datatypes/src/util/geodesy_projector.rs

+    */
+}
+
+pub fn geodesy_ctx() -> geodesy::ctx::Minimal {


thie Minimal context is also not Send or Sync or is it?

nope but it is fast. There is an issue for a ParallelContext. Maybe this would be Send or Sync.

michaelmattig · 2026-01-19T17:04:00Z

datatypes/src/util/proj_projector.rs

+};
+
+pub struct ProjCoordinateProjector {
+    pub from: SpatialReference,


can this not be derived from the Proj instance?

not in a way that would be halpfull

michaelmattig · 2026-01-19T17:06:13Z

operators/src/processing/reprojection.rs

 ) -> Result<SpatialGridDescriptor> {
    let proj_from_to =
-        CoordinateProjector::from_known_srs(in_srs, params.target_spatial_reference)?;
+        MixedCoordinateProjector::from_known_srs(in_srs, params.target_spatial_reference)?;


wouldn't it still make sense to try to reuse the projector? did you measure the overhead of instantiation?

i created a small benchmark. It is much faster then proj.. You can add more benches if you have ideas how to measure that.

…longer works now that resolutions are no longer part of the query rectangle

- [ ] I added an entry to [`CHANGELOG.md`](CHANGELOG.md) if knowledge of this change could be valuable to users. --- Here is a brief summary of what I did: <TEXT>

…ks now that resolutions are no longer part of the query rectangle (#1112) - [ ] I added an entry to [`CHANGELOG.md`](CHANGELOG.md) if knowledge of this change could be valuable to users. --- Here is a brief summary of what I did: <TEXT>

…e/geoengine into new-pixel-based-queries-rebase

…e/geoengine into proj_experiments

- [ ] I added an entry to [`CHANGELOG.md`](CHANGELOG.md) if knowledge of this change could be valuable to users. --- Here is a brief summary of what I did: <TEXT>

…e/geoengine into proj_experiments

…riments

datatypes/src/util/proj_projector.rs

+    ) -> Result<Vec<Coordinate2D>> {
+        let c_ref = coords.as_ref();
+
+        let mut cc = Vec::from(c_ref);


jdroenner added 30 commits July 30, 2024 16:44

remove prints

be35b4b

Merge branch 'main' of github.com:geo-engine/geoengine into new-pixel…

40d1a5d

…-based-queries-rebase

adapt to changes

96daf3b

building again

059249a

Merge branch 'main' of github.com:geo-engine/geoengine into new-pixel…

6bb07c9

…-based-queries-rebase

building operators

c75cff4

remove debug output

585b073

more tests

e1d859c

Merge branch 'main' of github.com:geo-engine/geoengine into new-pixel…

b270995

…-based-queries-rebase

adapt to changes

1dc22b9

remove debug output

efd3a64

remove dbg! calls

f89e31a

more tests

a1bc2cb

clippy fix datatypes

5de2abf

fix clippy things in services

944e562

clippy lints and reduce complexity

3b15301

more lints and renames

c53144c

Merge branch 'main' of github.com:geo-engine/geoengine into new-pixel…

1ef0cbc

…-based-queries-rebase

adapt cache text

0f4a8d0

more lints

9e9d115

use correct type ein api

24cad6c

interpolation: reuse geotransform and use fail safe lookup

8550edf

Merge branch 'main' of github.com:geo-engine/geoengine into new-pixel…

b5df687

…-based-queries-rebase

remove unused methods

50010bf

update tests

5b57b1e

togeotiff: don't set tiled for COG

66411b7

use type from api model in dataset handlers

b063456

reuse pixel to tiling logic

2d5f798

remove resolution from VectorStreamQuery

7682e6e

RasterWebsocketStream: log why stream was closed

d244bf0

michaelmattig reviewed Jan 19, 2026

View reviewed changes

michaelmattig and others added 14 commits January 20, 2026 16:46

fix: remove workflow benchmarks using gdal becaue benchmark logic no …

7076f8f

…longer works now that resolutions are no longer part of the query rectangle

remove all workflow benches

1296041

fix: properly initialize wrapped operator (#1111)

bddf5f5

- [ ] I added an entry to [`CHANGELOG.md`](CHANGELOG.md) if knowledge of this change could be valuable to users. --- Here is a brief summary of what I did: <TEXT>

fix: shift overview grid by a pixel fraction if needed

69f985f

Merge branch 'new-pixel-based-queries-rebase' of github.com:geo-engin…

80e1ccd

…e/geoengine into new-pixel-based-queries-rebase

Merge branch 'new-pixel-based-queries-rebase' of github.com:geo-engin…

8687262

…e/geoengine into proj_experiments

fix: unify geotransform in api

4af18d5

reduce no-data tiles produced in empty tile-intervals with regular steps

17d28b9

Merge branch 'new-pixel-based-queries-rebase' of github.com:geo-engin…

298812a

…e/geoengine into proj_experiments

bring back release_max_level_debug

8640bdd

make GeoTransform Copy

f2eacfc

fix: unify geotransform in api (#1113)

b48f735

- [ ] I added an entry to [`CHANGELOG.md`](CHANGELOG.md) if knowledge of this change could be valuable to users. --- Here is a brief summary of what I did: <TEXT>

Merge branch 'new-pixel-based-queries-rebase' of github.com:geo-engin…

e46b67b

…e/geoengine into proj_experiments

Base automatically changed from new-pixel-based-queries-rebase to main February 3, 2026 14:51

Merge branch 'main' of github.com:geo-engine/geoengine into proj_expe…

7637fd8

…riments

github-advanced-security bot found potential problems Feb 5, 2026

View reviewed changes

Conversation

jdroenner commented Jan 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michaelmattig Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jdroenner Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Check failure

Uh oh!

Copilot Autofix

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

michaelmattig Jan 19, 2026 •

edited

Loading

jdroenner Jan 21, 2026 •

edited

Loading