From j1 at jimenezshaw.com Sun Mar 1 14:46:09 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sun, 1 Mar 2026 23:46:09 +0100 Subject: [PROJ] Creating a dynamic system In-Reply-To: References: Message-ID: In your last PR https://github.com/OSGeo/PROJ/pull/4685/ you use "NAD83(CSRS)v7" as an example, but it does not have a dynamic datum. The datum is type 3, PJ_TYPE_GEODETIC_REFERENCE_FRAME. On Sun, 22 Feb 2026 at 18:32, Even Rouault wrote: > > Le 22/02/2026 ? 15:28, Javier Jimenez Shaw via PROJ a ?crit : > > Hi > > > > the C function proj_coordinate_metadata_create can > > > https://proj.org/en/stable/development/reference/functions.html#c.proj_coordinate_metadata_create > > allows to create a dynamic system with an epoch. > > > > In case the crs is not dynamic, it fails and emits an error. > > However I do not see how to check if a system is dynamic, to call it > > only if really needed. > > > > Is there such a function in the C API? > > checking proj_get_type() == PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME on > the result of proj_crs_get_datum() > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sun Mar 1 14:56:06 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 1 Mar 2026 23:56:06 +0100 Subject: [PROJ] Creating a dynamic system In-Reply-To: References: Message-ID: <11463aa1-0649-4e9e-94db-740c649eb9fa@spatialys.com> for all practical purposes, it seems to be one. I don't know why it hasn't been formally tagged as such in EPSG. I see that back in times I added in CoordinateMetadata::create() an exception to check if a CRS had a point motion operation attached to it to allow it to be used to create a?CoordinateMetadata object Le 01/03/2026 ? 23:46, Javier Jimenez Shaw a ?crit?: > In your last PR https://github.com/OSGeo/PROJ/pull/4685/ you use > "NAD83(CSRS)v7" as an example, but it does not have a dynamic datum. > The datum is type 3,?PJ_TYPE_GEODETIC_REFERENCE_FRAME. > > On Sun, 22 Feb 2026 at 18:32, Even Rouault > wrote: > > > Le 22/02/2026 ? 15:28, Javier Jimenez Shaw via PROJ a ?crit?: > > Hi > > > > the C function?proj_coordinate_metadata_create can > > > https://proj.org/en/stable/development/reference/functions.html#c.proj_coordinate_metadata_create > > allows to create a dynamic system with an epoch. > > > > In case the crs is not dynamic, it fails and emits an error. > > However I do not see how to check if a system is dynamic, to > call it > > only if really needed. > > > > Is there such a function in the C API? > > checking proj_get_type() == > PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME on > the result of proj_crs_get_datum() > > -- > http://www.spatialys.com > My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sun Mar 1 15:12:56 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 01 Mar 2026 18:12:56 -0500 Subject: [PROJ] Creating a dynamic system In-Reply-To: <11463aa1-0649-4e9e-94db-740c649eb9fa@spatialys.com> (Even Rouault via PROJ's message of "Sun, 1 Mar 2026 23:56:06 +0100") References: <11463aa1-0649-4e9e-94db-740c649eb9fa@spatialys.com> Message-ID: Even Rouault via PROJ writes: > for all practical purposes, it seems to be one. I don't know why it > hasn't been formally tagged as such in EPSG. I see that back in times > I added in CoordinateMetadata::create() an exception to check if a CRS > had a point motion operation attached to it to allow it to be used to > create a?CoordinateMetadata object NAD83 is a funny case. Depending on one's view of accuracy, it can be static or dynamic. Originally, it was a crust-fixed frame and formally static. But then two things happened: - greater ability to measure, so the plate not being rigid and part of NA being on the pacific plate starts to matter more. - redefinition in terms of ITRF (NAD83(2011)), with euler pole parameters that in hindsight were not exactly right For the US, NAD83(2011) is technically dynamic, with station velocities. The velocities are very small, a few mm/y, vs the much larger 2cm/year that NA plate stations have in ITRF. So neglectable in more situations. However, nobody uses that datum. When people say NAD83(2011), they mean "NAD83(2011) epoch 2010.0" coordinates, which is effectively a static datum. (Or they don't understand.) The next question is what EPSG:6319 means. It doesn't mention the epoch: https://spatialreference.org/ref/epsg/6319/ but i think everybody who uses it (who is aware of this issue at all) firmly knows that data tagged in EPSG:6319 is epoch 2010.0. The RTK networks run by the various StateDOT agencies are essentially all in NAD83(2011) epoch 2010.0. I know of one that also offers some ITRF and draft NATRF2022 frames. I am unclear on precise Canadian practice but my impression is that the most recent CSRS is more or less the same concept but adjusted to Canadian data and a few cm different then NAD83(2011). I suggest that datums that are technically dynamic but not really be avoided in examples like this. A further issue is to defuzz NAD83(2011) in EPSG in terms of if it is a dynamic datum with a reference epoch with stations having velocities, or if it means epoch 2010.0. I vote for epoch 2010.0 to match US practice. From kristian at evers.dev Sun Mar 1 23:19:04 2026 From: kristian at evers.dev (Kristian Evers) Date: Mon, 02 Mar 2026 07:19:04 +0000 Subject: [PROJ] PROJ 9.8.0RC2 In-Reply-To: <60778F73-BDD3-4482-A456-06FE1E992881@hobu.co> References: <60778F73-BDD3-4482-A456-06FE1E992881@hobu.co> Message-ID: With +1's from Kristian Javier Thomas Even Charles Alan Howard The motion is passed. I?ll announce the release later today when my schedule allows it. /Kristian > On 27 Feb 2026, at 15.31, Howard Butler via PROJ wrote: > > +1 Howard > >> On Feb 27, 2026, at 7:18?AM, Alan Snow via PROJ wrote: >> >> +1 Alan >> >> On Fri, Feb 27, 2026, 1:51?AM Kristian Evers via PROJ wrote: >> >>> PSC Members, >>> >>> I have been informed that the issues in RC1 are confirmed to be fixed in RC2, so I'd like to propose that is promoted to the final release. I expect to put the release out either Sunday or Monday. >>> >>> I'll start with my +1. >>> >>> /Kristian >>> >>> On Wednesday, February 25th, 2026 at 19:51, Kristian Evers via PROJ wrote: >>> >>>> A few problems were found in 9.8.0RC1. They should be fixed now and a new release candidate is ready. >>>> Download it here: >>>> >>>> https://download.osgeo.org/proj/proj-9.8.0RC2.tar.gz >>>> https://download.osgeo.org/proj/proj-9.8.0RC2.zip >>>> >>>> Hopefully there are no further problems with the release candidate but please report them >>>> here or as issues on GitHub if your come across any. >>>> >>>> /Kristian >>>> >>>> _______________________________________________ >>>> PROJ mailing list >>>> PROJ at lists.osgeo.org >>>> https://lists.osgeo.org/mailman/listinfo/proj >>>> >>> _______________________________________________ >>> PROJ mailing list >>> PROJ at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/proj >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian at evers.dev Mon Mar 2 05:16:44 2026 From: kristian at evers.dev (Kristian Evers) Date: Mon, 02 Mar 2026 13:16:44 +0000 Subject: [PROJ] PROJ 9.8.0 Message-ID: --------------------------------------------------------------- It?s my pleasure to announce the release of PROJ 9.8.0! The release includes a number of updates, as well as bug fixes. See the release notes below. Download the archives here: https://download.osgeo.org/proj/proj-9.8.0.tar.gz https://download.osgeo.org/proj/proj-9.8.0.zip /Kristian ----------------------------------------------------------- # PROJ Release Notes ## 9.8.0 ### Updates * Database: update to EPSG v12.049 (#4671) * Database: update ESRI records to ArcGIS Pro 3.6 (#4622) * Support for Canadian vertical references MTM CGVD2013 epoch 1997, 2002, 2010 and UTM CGVD28 epoch 1997, 2002, 2010 (#4623) * `createOperationsCompoundToGeog()`: improvement to make "PNG94 / PNGMG94 zone 54 + Kumul 34 height" to "WGS 84 (G2139)" perform vertical transformation (#4624) * Remove hardcoding of 'ETRS89-NOR [EUREF89]' cases and generalize it to other ETRS89-XXX cases (#4625) * Database: create ESRI aliases for geodetic_datum and geodetic_crs even if they are the same as EPSG ones (#4626) * Use Emscripten fetch in networkfilemanager (#4627) * `ProjectedCRS::identify()`: do not return CRS whose ellipsoid is totally different from the input one (#4635) * `projinfo` added as a library function. This installs a new header: `projapps_lib.h`. (#4646) * respect `CRS_EXTENT_USE=NONE` for ConcatenatedOperations (#4652) * Add support for Equidistant Cylindrical ellipsoidal method (EPSG:1028) (#4656) * Update `proj_symbol_rename.h` (#4657) * WKT1 importer: deal with 'VERT_CS["Geoid 2012A",' (#4659) * Generate correct library name in `proj.pc` (#4660) * Derived projected CRS related improvements (#4667) * ETRS89-xxx to ETRS89-yyy related improvements (#4668) * `createCoordinateOperation()`: tune computed accuracy of a concatenated op within ETRS89 (#4670) * `createOperationsCompoundToGeog()`: discard 2D-only transformations from interpolation 3D CRS to target 3D CRS (#4677) ### Bug Fixes * CRS identification: fix issue when identifying WKT from older EPSG releases with newer ones where the ETRS89-XXX national datums have been added (#4600) * fix `normalizeForVisualization` to skip extent checks for axis-swap operations (#4632) * Improvements to TRACE_FETCH debug messages (#4645) * tmerc spherical: fix numeric instability at lat=lat_0 (#4674) -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Mon Mar 2 08:23:02 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 2 Mar 2026 17:23:02 +0100 Subject: [PROJ] PROJ 9.8.0 In-Reply-To: References: Message-ID: Do we have docker image? I need it to update spatialreference.org On Mon, 2 Mar 2026 at 14:17, Kristian Evers via PROJ wrote: > ------------------------------ > > It?s my pleasure to announce the release of PROJ 9.8.0! > > The release includes a number of updates, as well as bug fixes. > See the release notes below. > > Download the archives here: > https://download.osgeo.org/proj/proj-9.8.0.tar.gzhttps://download.osgeo.org/proj/proj-9.8.0.zip > > /Kristian > > ----------------------------------------------------------- > > # PROJ Release Notes > > ## 9.8.0 > > ### Updates > > * Database: update to EPSG v12.049 (#4671) > > * Database: update ESRI records to ArcGIS Pro 3.6 (#4622) > > * Support for Canadian vertical references MTM CGVD2013 epoch 1997, 2002, > 2010 and > UTM CGVD28 epoch 1997, 2002, 2010 (#4623) > > * `createOperationsCompoundToGeog()`: improvement to make "PNG94 / PNGMG94 > zone 54 + Kumul > 34 height" to "WGS 84 (G2139)" perform vertical transformation (#4624) > > * Remove hardcoding of 'ETRS89-NOR [EUREF89]' cases and generalize it to > other ETRS89-XXX > cases (#4625) > > * Database: create ESRI aliases for geodetic_datum and geodetic_crs even > if they are the > same as EPSG ones (#4626) > > * Use Emscripten fetch in networkfilemanager (#4627) > > * `ProjectedCRS::identify()`: do not return CRS whose ellipsoid is totally > different from the input one (#4635) > > * `projinfo` added as a library function. This installs a new header: > `projapps_lib.h`. (#4646) > > * respect `CRS_EXTENT_USE=NONE` for ConcatenatedOperations (#4652) > > * Add support for Equidistant Cylindrical ellipsoidal method (EPSG:1028) > (#4656) > > * Update `proj_symbol_rename.h` (#4657) > > * WKT1 importer: deal with 'VERT_CS["Geoid 2012A",' (#4659) > > * Generate correct library name in `proj.pc` (#4660) > > * Derived projected CRS related improvements (#4667) > > * ETRS89-xxx to ETRS89-yyy related improvements (#4668) > > * `createCoordinateOperation()`: tune computed accuracy of a concatenated > op within ETRS89 (#4670) > > * `createOperationsCompoundToGeog()`: discard 2D-only transformations from > interpolation > 3D CRS to target 3D CRS (#4677) > > > ### Bug Fixes > > * CRS identification: fix issue when identifying WKT from older EPSG > releases with newer > ones where the ETRS89-XXX national datums have been added (#4600) > > * fix `normalizeForVisualization` to skip extent checks for axis-swap > operations (#4632) > > * Improvements to TRACE_FETCH debug messages (#4645) > > * tmerc spherical: fix numeric instability at lat=lat_0 (#4674) > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Mon Mar 2 09:45:15 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 2 Mar 2026 18:45:15 +0100 Subject: [PROJ] PROJ 9.8.0 In-Reply-To: References: Message-ID: No, we don't. @Ogi I believe the changes?of https://github.com/OSGeo/PROJ/commit/d65d4203b316ba244b14471728fe629132b67591 have broken the creation?of tagged images?of PROJ by always creating a manifest from?-latest amd64 and arm64 images. And looking at https://github.com/OSGeo/PROJ/actions/runs/22577038258/job/65398859539 , it also seems that the amd64 and arm64 images for tags don't have the tag name in their name.?We should have logic specific for tags I just have Internet through mobile phone?this week, so can't manually create & push an image at hand for now. Le 02/03/2026 ? 17:23, Javier Jimenez Shaw via PROJ a ?crit?: > Do we have docker image? > I need it to update spatialreference.org > > On Mon, 2 Mar 2026 at 14:17, Kristian Evers via PROJ > wrote: > > ------------------------------------------------------------------------ > > It?s my pleasure to announce the release of PROJ 9.8.0! > > The release includes a number of updates, as well as bug fixes. > See the release notes below. > > Download the archives here: > > https://download.osgeo.org/proj/proj-9.8.0.tar.gz > https://download.osgeo.org/proj/proj-9.8.0.zip > > /Kristian > > ----------------------------------------------------------- > > # PROJ Release Notes > > ## 9.8.0 > > ### Updates > > * Database: update to EPSG v12.049 (#4671) > > * Database: update ESRI records to ArcGIS Pro 3.6 (#4622) > > * Support for Canadian vertical references MTM CGVD2013 epoch > 1997, 2002, 2010 and > ? UTM CGVD28 epoch 1997, 2002, 2010 (#4623) > > * `createOperationsCompoundToGeog()`: improvement to make "PNG94 / > PNGMG94 zone 54 + Kumul > ? 34 height" to "WGS 84 (G2139)" perform vertical transformation > (#4624) > > * Remove hardcoding of 'ETRS89-NOR [EUREF89]' cases and generalize > it to other ETRS89-XXX > ? cases (#4625) > > * Database: create ESRI aliases for geodetic_datum and > geodetic_crs even if they are the > ? same as EPSG ones (#4626) > > * Use Emscripten fetch in networkfilemanager (#4627) > > * `ProjectedCRS::identify()`: do not return CRS whose ellipsoid is > totally different from the input one (#4635) > > * `projinfo` added as a library function. This installs a new > header: `projapps_lib.h`. (#4646) > > * respect `CRS_EXTENT_USE=NONE` for ConcatenatedOperations (#4652) > > * Add support for ?Equidistant Cylindrical ellipsoidal method > (EPSG:1028) (#4656) > > * Update `proj_symbol_rename.h` (#4657) > > * WKT1 importer: deal with 'VERT_CS["Geoid 2012A",' (#4659) > > * Generate correct library name in `proj.pc` (#4660) > > * Derived projected CRS related improvements (#4667) > > * ETRS89-xxx to ETRS89-yyy related improvements (#4668) > > * `createCoordinateOperation()`: tune computed accuracy of a > concatenated op within ETRS89 (#4670) > > * `createOperationsCompoundToGeog()`: discard 2D-only > transformations from interpolation > ? 3D CRS to target 3D CRS (#4677) > > > ### Bug Fixes > > * CRS identification: fix issue when identifying WKT from older > EPSG releases with newer > ? ones where the ETRS89-XXX national datums have been added (#4600) > > * fix `normalizeForVisualization` to skip extent checks for > axis-swap operations (#4632) > > * Improvements to TRACE_FETCH debug messages (#4645) > > * tmerc spherical: fix numeric instability at lat=lat_0 (#4674) > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Tue Mar 3 08:06:35 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 3 Mar 2026 17:06:35 +0100 Subject: [PROJ] Problems adding geoidmodel tag Message-ID: Hi I want to do transformation in the Czech republic using the vertical CRS with a specific geoid model. For that purpose I am using a WKT2 file with the GEOIDMODEL tag to "PROJ cz_cuzk_CR-2005.tif" that is a file that we have in cdn.proj.org. (actually I have the geoid model registered with a name in the database, but this should be equivalent) Side note: Czechia and Slovakia both use "Baltic 1957 height" as vertical system, but they define different geoid models. The problem is that the transformation is different if I set the geoid model tag vs without it. The content of the file wkt_geoidmodel.txt is just adding that line with the geoid model to EPSG:5514+8357 cat wkt_geoidmodel.txt COMPOUNDCRS["S-JTSK / Krovak East North + Baltic 1957 height", PROJCRS["S-JTSK / Krovak East North", BASEGEOGCRS["S-JTSK", DATUM["System of the Unified Trigonometrical Cadastral Network", ELLIPSOID["Bessel 1841",6377397.155,299.1528128, LENGTHUNIT["metre",1]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433]], ID["EPSG",4156]], CONVERSION["Krovak East North (Greenwich)", METHOD["Krovak (North Orientated)", ID["EPSG",1041]], PARAMETER["Latitude of projection centre",49.5, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8811]], PARAMETER["Longitude of origin",24.8333333333333, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8833]], PARAMETER["Co-latitude of cone axis",30.2881397527778, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",1036]], PARAMETER["Latitude of pseudo standard parallel",78.5, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8818]], PARAMETER["Scale factor on pseudo standard parallel",0.9999, SCALEUNIT["unity",1], ID["EPSG",8819]], PARAMETER["False easting",0, LENGTHUNIT["metre",1], ID["EPSG",8806]], PARAMETER["False northing",0, LENGTHUNIT["metre",1], ID["EPSG",8807]]], CS[Cartesian,2], AXIS["easting (X)",east, ORDER[1], LENGTHUNIT["metre",1]], AXIS["northing (Y)",north, ORDER[2], LENGTHUNIT["metre",1]], USAGE[ SCOPE["GIS."], AREA["Czechia; Slovakia."], BBOX[47.73,12.09,51.06,22.56]], ID["EPSG",5514]], VERTCRS["Baltic 1957 height", VDATUM["Baltic 1957"], CS[vertical,1], AXIS["gravity-related height (H)",up, LENGTHUNIT["metre",1]], * GEOIDMODEL["PROJ cz_cuzk_CR-2005.tif"],* USAGE[ SCOPE["Geodesy, engineering survey, topographic mapping."], AREA["Czechia; Slovakia."], BBOX[47.73,12.09,51.06,22.56]], ID["EPSG",8357]]] ------------------------ The coordinates converting from ETRS89 are different: echo 49 17.8 0 | PROJ_NETWORK=ON cs2cs EPSG:4258 "`cat wkt_geoidmodel.txt`" --3d -513716.51 -1191015.26 -43.12 echo 49 17.8 0 | PROJ_NETWORK=ON cs2cs EPSG:4258 EPSG:5514+8357 --3d -513716.63 -1191015.32 -43.12 The pipelines are "explaining" this problem. Without specifying the geoid model, it uses two grid files. cz_cuzk_CR-2005.tif and cz_cuzk_table_-y-x_3_v1710.tif (the last one added in 9.7.1) : PROJ_NETWORK=ON projinfo EPSG:4258 EPSG:5514+8357 --3d -o proj --bbox 17.8,49,17.81,49.01 Candidate operations found: 16 ------------------------------------- Operation No. 1: PROJ:ETRS89_3D_TO_S_JTSK_E_N_BALTIC_HEIGHT, ETRS89 to S-JTSK / Krovak East North + Baltic 1957 height, 0.05 m, Czechia. PROJ string: +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=push +v_3 +omit_inv +step +inv +proj=vgridshift +grids=cz_cuzk_CR-2005.tif +multiplier=1 +step +proj=push +v_3 +omit_fwd +step +proj=push +v_4 +step +proj=set +v_4=0 +omit_inv +step +proj=axisswap +order=1,2,4,3 +omit_inv +step +proj=pop +v_3 +omit_inv +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert +x=572.213 +y=85.334 +z=461.94 +rx=-4.9732 +ry=-1.529 +rz=-5.2484 +s=3.5378 +convention=coordinate_frame +step +inv +proj=cart +ellps=bessel +step +proj=mod_krovak +lat_0=49.5 +lon_0=24.8333333333333 +alpha=30.2881397222222 +k=0.9999 +x_0=5000000 +y_0=5000000 +ellps=bessel +step +proj=axisswap +order=1,2,4,3 +omit_inv +step +proj=set +v_4=0 +omit_inv +step +proj=pop +v_4 +step +proj=pop +v_3 +omit_fwd +step +inv +proj=gridshift +grids=cz_cuzk_table_-y-x_3_v1710.tif ------------------------------------- While the one setting the geoid model is not using the horizontal grid cz_cuzk_table_-y-x_3_v1710.tif: PROJ_NETWORK=ON projinfo EPSG:4258 "`cat wkt_geoidmodel.txt`" --3d -o proj --bbox 17.8,49,17.81,49.01 Candidate operations found: 8 ------------------------------------- Operation No. 1: unknown id, Inverse of Transformation from Baltic 1957 height to ETRS89 + Inverse of S-JTSK to ETRS89 (3) + Krovak East North (Greenwich), 0.53 m, unknown domain of validity PROJ string: +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=vgridshift +grids=cz_cuzk_CR-2005.tif +multiplier=1 +step +proj=push +v_3 +step +proj=cart +ellps=GRS80 +step +inv +proj=molobadekas +x=558.7 +y=68.8 +z=452.2 +rx=-8.025 +ry=-4.105 +rz=-4.295 +s=5.74 +px=3977358.114 +py=1407223.203 +pz=4765441.589 +convention=coordinate_frame +step +inv +proj=cart +ellps=bessel +step +proj=pop +v_3 +step +proj=krovak +lat_0=49.5 +lon_0=24.8333333333333 +alpha=30.2881397527778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel ------------------------------------- What can I do? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Mar 3 08:41:24 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 3 Mar 2026 17:41:24 +0100 Subject: [PROJ] Problems adding geoidmodel tag In-Reply-To: References: Message-ID: <26114a4f-4f12-4ee3-92dc-ffea3ae9fef4@spatialys.com> Javier, not much you can do but not setting a manual geoid model for that case. The pipeline used is highly manually tuned from?https://github.com/OSGeo/PROJ/blob/master/data/sql/transformations_czechia.sql#L99 and https://github.com/OSGeo/PROJ/blob/master/data/sql/transformations_czechia.sql#L171 for operating?on the CRS defined from the exact EPSG codes. Would be very hard to make PROJ realize that your custom WKT would be compatible?of that pipeline (The pipeline you get with the geoid model node is not fundamentally wrong, just slightly less accurate w.r.t. CUZK recommends for most geodesic proof ETRS89 to S-JTSK / Krovak) Even Le 03/03/2026 ? 17:06, Javier Jimenez Shaw via PROJ a ?crit?: > PROJ_NETWORK=ON projinfo EPSG:4258 EPSG:5514+8357 --3d -o proj --bbox > 17.8,49,17.81,49.01 -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Tue Mar 3 08:48:50 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 3 Mar 2026 17:48:50 +0100 Subject: [PROJ] Problems adding geoidmodel tag In-Reply-To: <26114a4f-4f12-4ee3-92dc-ffea3ae9fef4@spatialys.com> References: <26114a4f-4f12-4ee3-92dc-ffea3ae9fef4@spatialys.com> Message-ID: How could I know in advance that it is not using the geoid model file from Slovakia? They (unfortunately) use the same vertical system, and the accuracy in both cases is 0.03 m https://epsg.org/transformation_10568/ETRS89-CZE-2007-to-ETRS89-CZE-2007-Baltic-1957-height-2.html https://epsg.org/transformation_8361/ETRS89-SVK-SKTRF09-to-ETRS89-SVK-SKTRF09-Baltic-1957-height-1.html Thanks. On Tue, 3 Mar 2026 at 17:41, Even Rouault wrote: > Javier, > > not much you can do but not setting a manual geoid model for that case. > The pipeline used is highly manually tuned > from > https://github.com/OSGeo/PROJ/blob/master/data/sql/transformations_czechia.sql#L99 > and > > https://github.com/OSGeo/PROJ/blob/master/data/sql/transformations_czechia.sql#L171 > for operating on the CRS defined from the exact EPSG codes. Would be > very hard to make PROJ realize that your custom WKT would be > compatible of that pipeline > > (The pipeline you get with the geoid model node is not fundamentally > wrong, just slightly less accurate w.r.t. CUZK recommends for most > geodesic proof ETRS89 to S-JTSK / Krovak) > > Even > > Le 03/03/2026 ? 17:06, Javier Jimenez Shaw via PROJ a ?crit : > > PROJ_NETWORK=ON projinfo EPSG:4258 EPSG:5514+8357 --3d -o proj --bbox > > 17.8,49,17.81,49.01 > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Mar 3 09:05:26 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 3 Mar 2026 18:05:26 +0100 Subject: [PROJ] Problems adding geoidmodel tag In-Reply-To: References: <26114a4f-4f12-4ee3-92dc-ffea3ae9fef4@spatialys.com> Message-ID: <17157362-cc1c-4f6c-bd02-429b4590e3be@spatialys.com> Le 03/03/2026 ? 17:48, Javier Jimenez Shaw a ?crit?: > How could I know in advance that it is not using the geoid model file > from Slovakia? They (unfortunately) use the same vertical system, and > the accuracy in both cases is 0.03 m > https://epsg.org/transformation_10568/ETRS89-CZE-2007-to-ETRS89-CZE-2007-Baltic-1957-height-2.html > https://epsg.org/transformation_8361/ETRS89-SVK-SKTRF09-to-ETRS89-SVK-SKTRF09-Baltic-1957-height-1.html Depends on how you perform the coordinate operation itself. But if you specify "--area Czechia" with cs2cs or? use the PJ_AREA* member of proj_create_crs_to_crs/proj_create_crs_to_crs_from_pj, you should only get those for Czechia -- http://www.spatialys.com My software is free, but my time generally not. From anvalanz at gmail.com Tue Mar 3 10:25:13 2026 From: anvalanz at gmail.com (Antonio Valanzano) Date: Tue, 3 Mar 2026 19:25:13 +0100 Subject: [PROJ] cs2cs options Message-ID: I have used for the first time cs2cs and I have found not easy to discover which transformation the sw uses for the calculations. Here are my questions: 1. Is it possible for cs2cs to output not only the results but also the EPSG code of the transformation(s) used to produce the output ? This information could be useful for users in order to have more control over the transformations and avoid using the sw as a black box. 2. Is it possible to specify, as an option of cs2cs, a particular pipeline of transformations using the codes considered in the Geographic Parameter of the EPSG ? Antonio From anvalanz at gmail.com Tue Mar 3 10:44:10 2026 From: anvalanz at gmail.com (Antonio Valanzano) Date: Tue, 3 Mar 2026 19:44:10 +0100 Subject: [PROJ] cs2cs options - errata corrige Message-ID: In my previous message the sentence .. "considered in the Geographic Parameter of the EPSG ?" should be: "considered in the EPSG Geodetic Parameter Dataset?" Sorry for this. Antonio From pikl.m at czechglobe.cz Wed Mar 4 00:53:17 2026 From: pikl.m at czechglobe.cz (Miroslav Pikl) Date: Wed, 4 Mar 2026 08:53:17 +0000 Subject: [PROJ] Problems adding geoidmodel tag In-Reply-To: References: Message-ID: <1cc7c471dc59ad0e6140ca3765987cdaa3fd2d60.camel@czechglobe.cz> Hello, I also needed transformation between ETRS89UTM elipsoidic height to S- JTSK / Krovak East North + Baltic last year to transform some airborne data using GDAL/PDAL + PROJ. There exists document in czech language describing the official transformation procedure available from CUZK: https://cuzk.gov.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR/Metodika-prevodu-ETRF2000-vs-S-JTSK-var2(101208).aspx This CUZK website also provides the grid data https://cuzk.gov.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/etrf00-jtsk-v1012-a-etrf00-jtsk-v1203.aspx I tried to replicate the procedure in PROJ string comparing against the points from CUZK network and their online transformation tool. I ended up with the following section of PDAL pipeline, which was not exactly the same as CUZK, but good enough for my purpose. Sorry, if you find it very simple but my knowledge of geodesy and the whole concept of how PROJ works is very basic. I hope at least the links will be useful. Best Mira { "type":"filters.reprojection", "in_srs":"EPSG:3045", "out_srs":"EPSG:4936" }, { "type":"filters.projpipeline", "coord_op":"+proj=pipeline +step +inv +proj=cart +ellps=GRS80 +step +proj=push +v_3 +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert +x=572.213 +y=85.334 +z=461.94 +rx=-4.9732 +ry=-1.529 +rz=-5.2484 +s=3.5378 +convention=coordinate_frame +step +inv +proj=cart +ellps=bessel +step +proj=pop +v_3 +step +proj=mod_krovak +axis=swu +lat_0=49.5 +lon_0=24.8333333333333 +alpha=30.2881397222222 +k=0.9999 +x_0=5000000 +y_0=5000000 +ellps=bessel +geoidgrids=cz_cuzk_CR-2005.tif +step +proj=axisswap +order=2,1 +step +proj=gridshift +inv +grids=table_yx_3_v1710_5513.tif +step +proj=axisswap +order=-1,-2" } On Tue, 2026-03-03 at 17:06 +0100, Javier Jimenez Shaw via PROJ wrote: > Hi > > I want to do transformation in the Czech republic using the vertical > CRS with a specific geoid model. > For that purpose I am using a WKT2 file with the GEOIDMODEL tag to > "PROJ cz_cuzk_CR-2005.tif" that is a file that we have in > cdn.proj.org. (actually I have the geoid model registered with a name > in the database, but this should be equivalent) > > Side note: Czechia and Slovakia both use "Baltic 1957 height" as > vertical system, but they define different geoid models. > > The problem is that the transformation is different if I set the > geoid model tag vs without it. > The content of the file?wkt_geoidmodel.txt?is just adding that line > with the geoid model to EPSG:5514+8357 > > cat?wkt_geoidmodel.txt > COMPOUNDCRS["S-JTSK / Krovak East North + Baltic 1957 height", > ? ? PROJCRS["S-JTSK / Krovak East North", > ? ? ? ? BASEGEOGCRS["S-JTSK", > ? ? ? ? ? ? DATUM["System of the Unified Trigonometrical Cadastral > Network", > ? ? ? ? ? ? ? ? ELLIPSOID["Bessel 1841",6377397.155,299.1528128, > ? ? ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1]]], > ? ? ? ? ? ? PRIMEM["Greenwich",0, > ? ? ? ? ? ? ? ? ANGLEUNIT["degree",0.0174532925199433]], > ? ? ? ? ? ? ID["EPSG",4156]], > ? ? ? ? CONVERSION["Krovak East North (Greenwich)", > ? ? ? ? ? ? METHOD["Krovak (North Orientated)", > ? ? ? ? ? ? ? ? ID["EPSG",1041]], > ? ? ? ? ? ? PARAMETER["Latitude of projection centre",49.5, > ? ? ? ? ? ? ? ? ANGLEUNIT["degree",0.0174532925199433], > ? ? ? ? ? ? ? ? ID["EPSG",8811]], > ? ? ? ? ? ? PARAMETER["Longitude of origin",24.8333333333333, > ? ? ? ? ? ? ? ? ANGLEUNIT["degree",0.0174532925199433], > ? ? ? ? ? ? ? ? ID["EPSG",8833]], > ? ? ? ? ? ? PARAMETER["Co-latitude of cone axis",30.2881397527778, > ? ? ? ? ? ? ? ? ANGLEUNIT["degree",0.0174532925199433], > ? ? ? ? ? ? ? ? ID["EPSG",1036]], > ? ? ? ? ? ? PARAMETER["Latitude of pseudo standard parallel",78.5, > ? ? ? ? ? ? ? ? ANGLEUNIT["degree",0.0174532925199433], > ? ? ? ? ? ? ? ? ID["EPSG",8818]], > ? ? ? ? ? ? PARAMETER["Scale factor on pseudo standard > parallel",0.9999, > ? ? ? ? ? ? ? ? SCALEUNIT["unity",1], > ? ? ? ? ? ? ? ? ID["EPSG",8819]], > ? ? ? ? ? ? PARAMETER["False easting",0, > ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1], > ? ? ? ? ? ? ? ? ID["EPSG",8806]], > ? ? ? ? ? ? PARAMETER["False northing",0, > ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1], > ? ? ? ? ? ? ? ? ID["EPSG",8807]]], > ? ? ? ? CS[Cartesian,2], > ? ? ? ? ? ? AXIS["easting (X)",east, > ? ? ? ? ? ? ? ? ORDER[1], > ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1]], > ? ? ? ? ? ? AXIS["northing (Y)",north, > ? ? ? ? ? ? ? ? ORDER[2], > ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1]], > ? ? ? ? USAGE[ > ? ? ? ? ? ? SCOPE["GIS."], > ? ? ? ? ? ? AREA["Czechia; Slovakia."], > ? ? ? ? ? ? BBOX[47.73,12.09,51.06,22.56]], > ? ? ? ? ID["EPSG",5514]], > ? ? VERTCRS["Baltic 1957 height", > ? ? ? ? VDATUM["Baltic 1957"], > ? ? ? ? CS[vertical,1], > ? ? ? ? ? ? AXIS["gravity-related height (H)",up, > ? ? ? ? ? ? ? ? LENGTHUNIT["metre",1]], > ? ? ? ? GEOIDMODEL["PROJ cz_cuzk_CR-2005.tif"], > ? ? ? ? USAGE[ > ? ? ? ? ? ? SCOPE["Geodesy, engineering survey, topographic > mapping."], > ? ? ? ? ? ? AREA["Czechia; Slovakia."], > ? ? ? ? ? ? BBOX[47.73,12.09,51.06,22.56]], > ? ? ? ? ID["EPSG",8357]]] > ------------------------ > > The coordinates converting from ETRS89 are different: > > echo 49 17.8 0 | PROJ_NETWORK=ON cs2cs EPSG:4258 "`cat > wkt_geoidmodel.txt`" --3d > -513716.51 -1191015.26 -43.12 > echo 49 17.8 0 | PROJ_NETWORK=ON cs2cs EPSG:4258? EPSG:5514+8357 --3d > -513716.63 -1191015.32 -43.12 > > The pipelines are "explaining" this problem. Without specifying the > geoid model, it uses two grid files.?cz_cuzk_CR-2005.tif > and?cz_cuzk_table_-y-x_3_v1710.tif (the last one added in 9.7.1) : > > PROJ_NETWORK=ON projinfo EPSG:4258 EPSG:5514+8357 --3d -o proj --bbox > 17.8,49,17.81,49.01 > Candidate operations found: 16 > ------------------------------------- > Operation No. 1: > > PROJ:ETRS89_3D_TO_S_JTSK_E_N_BALTIC_HEIGHT, ETRS89 to S-JTSK / Krovak > East North + Baltic 1957 height, 0.05 m, Czechia. > > PROJ string: > +proj=pipeline > ? +step +proj=axisswap +order=2,1 > ? +step +proj=unitconvert +xy_in=deg +xy_out=rad > ? +step +proj=push +v_3 +omit_inv > ? +step +inv +proj=vgridshift +grids=cz_cuzk_CR-2005.tif > +multiplier=1 > ? +step +proj=push +v_3 +omit_fwd > ? +step +proj=push +v_4 > ? +step +proj=set +v_4=0 +omit_inv > ? +step +proj=axisswap +order=1,2,4,3 +omit_inv > ? +step +proj=pop +v_3 +omit_inv > ? +step +proj=cart +ellps=GRS80 > ? +step +inv +proj=helmert +x=572.213 +y=85.334 +z=461.94 +rx=-4.9732 > +ry=-1.529 > ? ? ? ? +rz=-5.2484 +s=3.5378 +convention=coordinate_frame > ? +step +inv +proj=cart +ellps=bessel > ? +step +proj=mod_krovak +lat_0=49.5 +lon_0=24.8333333333333 > ? ? ? ? +alpha=30.2881397222222 +k=0.9999 +x_0=5000000 +y_0=5000000 > +ellps=bessel > ? +step +proj=axisswap +order=1,2,4,3 +omit_inv > ? +step +proj=set +v_4=0 +omit_inv > ? +step +proj=pop +v_4 > ? +step +proj=pop +v_3 +omit_fwd > ? +step +inv +proj=gridshift +grids=cz_cuzk_table_-y-x_3_v1710.tif > > ------------------------------------- > > > While the one setting the geoid model is not using the horizontal > grid?cz_cuzk_table_-y-x_3_v1710.tif: > > PROJ_NETWORK=ON projinfo EPSG:4258 "`cat wkt_geoidmodel.txt`" --3d -o > proj --bbox 17.8,49,17.81,49.01 > Candidate operations found: 8 > ------------------------------------- > Operation No. 1: > > unknown id, Inverse of Transformation from Baltic 1957 height to > ETRS89 + Inverse of S-JTSK to ETRS89 (3) + Krovak East North > (Greenwich), 0.53 m, unknown domain of validity > > PROJ string: > +proj=pipeline > ? +step +proj=axisswap +order=2,1 > ? +step +proj=unitconvert +xy_in=deg +xy_out=rad > ? +step +inv +proj=vgridshift +grids=cz_cuzk_CR-2005.tif > +multiplier=1 > ? +step +proj=push +v_3 > ? +step +proj=cart +ellps=GRS80 > ? +step +inv +proj=molobadekas +x=558.7 +y=68.8 +z=452.2 +rx=-8.025 > +ry=-4.105 > ? ? ? ? +rz=-4.295 +s=5.74 +px=3977358.114 +py=1407223.203 > +pz=4765441.589 > ? ? ? ? +convention=coordinate_frame > ? +step +inv +proj=cart +ellps=bessel > ? +step +proj=pop +v_3 > ? +step +proj=krovak +lat_0=49.5 +lon_0=24.8333333333333 > +alpha=30.2881397527778 > ? ? ? ? +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel > > ------------------------------------- > > > What can I do? > > Thank you. > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj From j1 at jimenezshaw.com Wed Mar 4 09:09:01 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 4 Mar 2026 18:09:01 +0100 Subject: [PROJ] cs2cs options In-Reply-To: References: Message-ID: Hi Antonio. On Tue, 3 Mar 2026 at 19:25, Antonio Valanzano via PROJ < proj at lists.osgeo.org> wrote: > I have used for the first time cs2cs and I have found not easy to > discover which transformation the sw uses for the calculations. > > Here are my questions: > > 1. Is it possible for cs2cs to output not only the results but also > the EPSG code of the transformation(s) used to produce the output ? > This information could be useful for users in order to have more > control over the transformations and avoid using the sw as a black > box. > There is projinfo https://proj.org/en/stable/apps/projinfo.html , that can give you similar information. But it would be nice to have an option in cs2cs that prints the last operation used calling "proj_trans_get_last_used_operation". That way the user can know "exactly" the operation performed. > > 2. Is it possible to specify, as an option of cs2cs, a particular > pipeline of transformations using the codes considered in the > Geographic Parameter of the EPSG ? > Have you looked at cct application, next to cs2cs? https://proj.org/en/stable/apps/cct.html > Antonio > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Mar 4 09:12:47 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 4 Mar 2026 18:12:47 +0100 Subject: [PROJ] cs2cs options In-Reply-To: References: Message-ID: <1bf81cd1-9cfb-472b-9dd7-b99b417c06b6@spatialys.com> Le 04/03/2026 ? 18:09, Javier Jimenez Shaw via PROJ a ?crit?: > Hi Antonio. > > On Tue, 3 Mar 2026 at 19:25, Antonio Valanzano via PROJ > wrote: > > I have used for the first time cs2cs and I have found not easy to > discover which transformation the sw uses for the calculations. > > Here are my questions: > > 1. Is it possible? for cs2cs to output not only the results but also > the EPSG code of the transformation(s)? used to produce the output ? > This information could be useful for users in order to have more > control over the transformations and avoid using the sw as a black > box. > > > There is projinfo https://proj.org/en/stable/apps/projinfo.html , that > can give you similar information. But it would be nice to have an > option in cs2cs that prints the last operation used calling > "proj_trans_get_last_used_operation". > That way the user can know "exactly" the operation performed. $ echo 49 15 | PROJ_NETWORK=ON PROJ_DEBUG=2 bin/cs2cs EPSG:4258 EPSG:5514+8357 --3d [...] Using coordinate operation ETRS89 to S-JTSK / Krovak East North + Baltic 1957 height [...] -717321.47? ? -1168433.34 -46.13 -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Wed Mar 4 09:24:14 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 4 Mar 2026 18:24:14 +0100 Subject: [PROJ] cs2cs options In-Reply-To: <1bf81cd1-9cfb-472b-9dd7-b99b417c06b6@spatialys.com> References: <1bf81cd1-9cfb-472b-9dd7-b99b417c06b6@spatialys.com> Message-ID: Thanks Even. But that is not always: echo 40 0 | PROJ_DEBUG=2 ./cs2cs etrs89 epsg:25830 pj_open_lib(proj.ini): call fopen(...proj.ini) - succeeded pj_open_lib(proj.db): call fopen(...proj.db) - succeeded 756099.65 4432069.06 0.00 And I understand (way) better the proj pipeline ;) On Wed, 4 Mar 2026 at 18:12, Even Rouault wrote: > > Le 04/03/2026 ? 18:09, Javier Jimenez Shaw via PROJ a ?crit : > > Hi Antonio. > > On Tue, 3 Mar 2026 at 19:25, Antonio Valanzano via PROJ < > proj at lists.osgeo.org> wrote: > >> I have used for the first time cs2cs and I have found not easy to >> discover which transformation the sw uses for the calculations. >> >> Here are my questions: >> >> 1. Is it possible for cs2cs to output not only the results but also >> the EPSG code of the transformation(s) used to produce the output ? >> This information could be useful for users in order to have more >> control over the transformations and avoid using the sw as a black >> box. >> > > There is projinfo https://proj.org/en/stable/apps/projinfo.html , that > can give you similar information. But it would be nice to have an option in > cs2cs that prints the last operation used calling > "proj_trans_get_last_used_operation". > That way the user can know "exactly" the operation performed. > > $ echo 49 15 | PROJ_NETWORK=ON PROJ_DEBUG=2 bin/cs2cs EPSG:4258 > EPSG:5514+8357 --3d > [...] > Using coordinate operation ETRS89 to S-JTSK / Krovak East North + Baltic > 1957 height > [...] > -717321.47 -1168433.34 -46.13 > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Mar 4 09:28:20 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 4 Mar 2026 18:28:20 +0100 Subject: [PROJ] cs2cs options In-Reply-To: References: <1bf81cd1-9cfb-472b-9dd7-b99b417c06b6@spatialys.com> Message-ID: <0bf7d561-7808-4051-935a-d70ee4a41831@spatialys.com> Le 04/03/2026 ? 18:24, Javier Jimenez Shaw a ?crit?: > Thanks Even. > > But that is not always: yes, in that case there's only one single pipeline possible (a map projection without datum change) as reported by projinfo > > echo 40 0 | PROJ_DEBUG=2 ./cs2cs ?etrs89 epsg:25830 > pj_open_lib(proj.ini): call fopen(...proj.ini) - succeeded > pj_open_lib(proj.db): call fopen(...proj.db) - succeeded > 756099.65 4432069.06 0.00 > > And I understand (way) better the proj pipeline ;) > > > On Wed, 4 Mar 2026 at 18:12, Even Rouault > wrote: > > > Le 04/03/2026 ? 18:09, Javier Jimenez Shaw via PROJ a ?crit?: >> Hi Antonio. >> >> On Tue, 3 Mar 2026 at 19:25, Antonio Valanzano via PROJ >> wrote: >> >> I have used for the first time cs2cs and I have found not easy to >> discover which transformation the sw uses for the calculations. >> >> Here are my questions: >> >> 1. Is it possible? for cs2cs to output not only the results >> but also >> the EPSG code of the transformation(s)? used to produce the >> output ? >> This information could be useful for users in order to have more >> control over the transformations and avoid using the sw as a >> black >> box. >> >> >> There is projinfo https://proj.org/en/stable/apps/projinfo.html , >> that can give you similar information. But it would be nice to >> have an option in cs2cs that prints the last operation used >> calling "proj_trans_get_last_used_operation". >> That way the user can know "exactly" the operation performed. > $ echo 49 15 | PROJ_NETWORK=ON PROJ_DEBUG=2 bin/cs2cs EPSG:4258 > EPSG:5514+8357 --3d > [...] > Using coordinate operation ETRS89 to S-JTSK / Krovak East North + > Baltic 1957 height > [...] > -717321.47? ? -1168433.34 -46.13 > > -- > http://www.spatialys.com > My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwcohen at gmail.com Thu Mar 5 17:54:41 2026 From: wwcohen at gmail.com (Will Cohen) Date: Thu, 5 Mar 2026 20:54:41 -0500 Subject: [PROJ] proj in the browser In-Reply-To: References: Message-ID: Inspired by Javier's work on all this grid fetching, I finally got grid working on proj-wasm too and (shamelessly!) tried to fill out the demo page to include some of his lovely transformation web page interface as well. Instead of doing the grid fetches through emscripten, though, it takes a slightly different approach ( https://github.com/willcohen/clj-proj?tab=readme-ov-file#grid-fetching). In an effort to maintain parity with the JVM FFI side of the library, I'm still only trying to stick to the pure C api, so I can't quite get all of the projinfo functions as cleanly, though the C API seems to provide a lot of that info. Parallelism and grid fetching now work on both node and browser, with paths resolving correctly on mac/win/linux. There's also a small console at the bottom of the demo page (still working on the autocomplete -- it's missing some of the functions) that allows trying to run custom PROJ functions in-browser. There's a dropdown with examples to get started. On Mon, Feb 23, 2026 at 3:27?PM Thomas Knudsen via PROJ < proj at lists.osgeo.org> wrote: > Whoa, Javier! That is utterly awesome! > > I needed this badly a few months back, when teaching a geodesy course for > people who would never consider installing PROJ on their PC. Next time > around, I will just point them to your work. > > Thanks for this huge effort! > > /Thomas Knudsen > > Den man. 23. feb. 2026 kl. 11.25 skrev Javier Jimenez Shaw via PROJ < > proj at lists.osgeo.org>: > >> Hi >> >> TL;DR: go to the links below and play :) >> >> Finally, after a long time and learning a lot during the process, I am >> getting a webpage that uses PROJ to perform coordinate transformations >> (similar to cs2cs), and another that replicates projinfo: >> >> tranform: https://jjimenezshaw.github.io/wasm-proj/transform.html >> >> projinfo: https://jjimenezshaw.github.io/wasm-proj/projinfo.html >> >> All runs in the browser with PROJ (current master as of yesterday), no >> server needed. It uses the wasm compilation with emscripten that is run in >> CI (I copied the two needed files into the project). >> It uses a very simple library to manage the memory allocation, trying to >> make it simple for the javascript developer. The library is still in >> development, but functional as you can see. >> >> The transformer is able to use grids: it downloads at execution time the >> part of grid needed (a feature PROJ already has). For that it needs some >> code to run in a web worker, but the library is doing that as well. >> >> For instance, this link >> https://jjimenezshaw.github.io/wasm-proj/transform.html?st=combo&tt=combo&sh=EPSG%3A6318&th=EPSG%3A6539&tv=EPSG%3A6360&p3d=1&net=1&coords=40.7789978+-73.9632654+-20.5 >> uses the geoid model for NAVD88 (in this case, GEOID18) >> >> Tip for projinfo: add "&run=1" when you share the URL, and it will run >> directly the query. Both pages update the URL with the data to make it easy >> to share. >> >> Have fun! >> >> Cheers, >> Javier. >> >> PS. Yes, another one. There are at least two other. This was a personal >> challenge to efficiently use the grid files in the browser. >> PPS. Why these two, and not other things from PROJ? well, these are the >> two apps I use in a daily basis in the console. Now I can send a link to my >> colleagues that do not know how to use the command line. But more things >> can be done. >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Sat Mar 7 09:03:53 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sat, 7 Mar 2026 18:03:53 +0100 Subject: [PROJ] geographic from projected Message-ID: Hi I have seen in proj.cpp and factors.cpp that it gets a lot of code to make a geographic system from the projected/derived/compound/... system. Would I make sense to have a C API for CRS::extractGeographicCRS() that would simplify that? Cheers Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sun Mar 8 11:33:26 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 8 Mar 2026 19:33:26 +0100 Subject: [PROJ] PROJ 9.8.0 In-Reply-To: References: Message-ID: I've now fixed the issues in docker.yml, created a 9.8.0-1 tag with only that extra fix (https://github.com/OSGeo/PROJ/commit/23fc548f3751d47a675a59bd1ebf29431bbc7f81) on top of the 9.8.0 tag, and the Docker images are now available as ghcr.io/osgeo/proj:9.8.0 or docker.io/osgeo/proj:9.8.0 Even Le 02/03/2026 ? 18:45, Even Rouault via PROJ a ?crit?: > > No, we don't. @Ogi I believe the changes?of > https://github.com/OSGeo/PROJ/commit/d65d4203b316ba244b14471728fe629132b67591 > have broken the creation?of tagged images?of PROJ by always creating a > manifest from?-latest amd64 and arm64 images. And looking at > https://github.com/OSGeo/PROJ/actions/runs/22577038258/job/65398859539 > , it also seems that the amd64 and arm64 images for tags don't have > the tag name in their name.?We should have logic specific for tags > > I just have Internet through mobile phone?this week, so can't manually > create & push an image at hand for now. > > Le 02/03/2026 ? 17:23, Javier Jimenez Shaw via PROJ a ?crit?: >> Do we have docker image? >> I need it to update spatialreference.org >> >> On Mon, 2 Mar 2026 at 14:17, Kristian Evers via PROJ >> wrote: >> >> ------------------------------------------------------------------------ >> >> It?s my pleasure to announce the release of PROJ 9.8.0! >> >> The release includes a number of updates, as well as bug fixes. >> See the release notes below. >> >> Download the archives here: >> >> https://download.osgeo.org/proj/proj-9.8.0.tar.gz >> https://download.osgeo.org/proj/proj-9.8.0.zip >> >> /Kristian >> >> ----------------------------------------------------------- >> >> # PROJ Release Notes >> >> ## 9.8.0 >> >> ### Updates >> >> * Database: update to EPSG v12.049 (#4671) >> >> * Database: update ESRI records to ArcGIS Pro 3.6 (#4622) >> >> * Support for Canadian vertical references MTM CGVD2013 epoch >> 1997, 2002, 2010 and >> ? UTM CGVD28 epoch 1997, 2002, 2010 (#4623) >> >> * `createOperationsCompoundToGeog()`: improvement to make "PNG94 >> / PNGMG94 zone 54 + Kumul >> ? 34 height" to "WGS 84 (G2139)" perform vertical transformation >> (#4624) >> >> * Remove hardcoding of 'ETRS89-NOR [EUREF89]' cases and >> generalize it to other ETRS89-XXX >> ? cases (#4625) >> >> * Database: create ESRI aliases for geodetic_datum and >> geodetic_crs even if they are the >> ? same as EPSG ones (#4626) >> >> * Use Emscripten fetch in networkfilemanager (#4627) >> >> * `ProjectedCRS::identify()`: do not return CRS whose ellipsoid >> is totally different from the input one (#4635) >> >> * `projinfo` added as a library function. This installs a new >> header: `projapps_lib.h`. (#4646) >> >> * respect `CRS_EXTENT_USE=NONE` for ConcatenatedOperations (#4652) >> >> * Add support for ?Equidistant Cylindrical ellipsoidal method >> (EPSG:1028) (#4656) >> >> * Update `proj_symbol_rename.h` (#4657) >> >> * WKT1 importer: deal with 'VERT_CS["Geoid 2012A",' (#4659) >> >> * Generate correct library name in `proj.pc` (#4660) >> >> * Derived projected CRS related improvements (#4667) >> >> * ETRS89-xxx to ETRS89-yyy related improvements (#4668) >> >> * `createCoordinateOperation()`: tune computed accuracy of a >> concatenated op within ETRS89 (#4670) >> >> * `createOperationsCompoundToGeog()`: discard 2D-only >> transformations from interpolation >> ? 3D CRS to target 3D CRS (#4677) >> >> >> ### Bug Fixes >> >> * CRS identification: fix issue when identifying WKT from older >> EPSG releases with newer >> ? ones where the ETRS89-XXX national datums have been added (#4600) >> >> * fix `normalizeForVisualization` to skip extent checks for >> axis-swap operations (#4632) >> >> * Improvements to TRACE_FETCH debug messages (#4645) >> >> * tmerc spherical: fix numeric instability at lat=lat_0 (#4674) >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochem.Lesparre at kadaster.nl Tue Mar 10 06:56:54 2026 From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem) Date: Tue, 10 Mar 2026 13:56:54 +0000 Subject: [PROJ] New national ETRS89 realisations in EPSG messing things up in PROJ 9.8.0? Message-ID: Some transformations that used to give correct results (e.g. in PROJ 9.7.1) do no longer give results according to the official transformation (Amersfoort to ETRS89 (9)) of the Dutch national authority in PROJ 9.8.0. I suspect it has to do with the introduction of national realisations of ETRS89 in EPSG. Complicating factor is that EPSG erroneously removed the superseded label from some outdated transformations (Amersfoort to ETRS89 (5) and Amersfoort to ETRS89 (6)). However, these old transformations have a lower accuracy than the official one, so I think PROJ should be able to still find the official transformation. Why can't PROJ find it? Is there something else wrong in EPSG, preventing PROJ to find the official transformation? Or is this an issue in PROJ 9.8.0? Jochem Example 1: Forward >From the national ETRS89 realisation to the national projected CRS, PROJ uses the correct transformation Amersfoort to ETRS89 (9): projinfo EPSG:11037 EPSG:28992 --spatial-test intersects -o proj --hide-ballpark But from ETRF2000 and the ETRS89 ensemble PROJ doesn't use the official transformation of the national authority anymore: projinfo EPSG:9067 EPSG:28992 --spatial-test intersects -o proj --hide-ballpark projinfo EPSG:4258 EPSG:28992 --spatial-test intersects -o proj --hide-ballpark Example 2: Reverse >From the national projected CRS to the national ETRS89 realisation, PROJ uses the correct transformation Amersfoort to ETRS89 (9): projinfo EPSG:28992 EPSG:11037 --spatial-test intersects -o proj --hide-ballpark But to ETRF2000 and the ETRS89 ensemble PROJ doesn't use the official transformation of the national authority anymore: projinfo EPSG:28992 EPSG:9067 --spatial-test intersects -o proj --hide-ballpark projinfo EPSG:28992 EPSG:4258 --spatial-test intersects -o proj --hide-ballpark Disclaimer: De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing [https://www.kadaster.nl/algemene-leveringsvoorwaarden]. Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Our general terms and conditions of delivery apply to all our products and services [https://www.kadaster.com/general-terms-and-conditions]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Tue Mar 10 08:21:01 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 10 Mar 2026 16:21:01 +0100 Subject: [PROJ] Problems adding geoidmodel tag In-Reply-To: <17157362-cc1c-4f6c-bd02-429b4590e3be@spatialys.com> References: <26114a4f-4f12-4ee3-92dc-ffea3ae9fef4@spatialys.com> <17157362-cc1c-4f6c-bd02-429b4590e3be@spatialys.com> Message-ID: Thank you Even. The area solution worked very well. (I had to remove explicitly the geoidmodel tag. Even if the id doesn't exist) On Tue, 3 Mar 2026 at 18:05, Even Rouault wrote: > > Le 03/03/2026 ? 17:48, Javier Jimenez Shaw a ?crit : > > How could I know in advance that it is not using the geoid model file > > from Slovakia? They (unfortunately) use the same vertical system, and > > the accuracy in both cases is 0.03 m > > > https://epsg.org/transformation_10568/ETRS89-CZE-2007-to-ETRS89-CZE-2007-Baltic-1957-height-2.html > > > https://epsg.org/transformation_8361/ETRS89-SVK-SKTRF09-to-ETRS89-SVK-SKTRF09-Baltic-1957-height-1.html > > Depends on how you perform the coordinate operation itself. But if you > specify "--area Czechia" with cs2cs or use the PJ_AREA* member of > proj_create_crs_to_crs/proj_create_crs_to_crs_from_pj, you should only > get those for Czechia > > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Tue Mar 10 08:43:54 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 10 Mar 2026 16:43:54 +0100 Subject: [PROJ] Different behaviour between 9.7.1 and 9.8.0 Message-ID: Hi This change in behaviour is a surprise to me. I would like to know what changed (I know the ETRS89 datum ensemble, but I was not expecting this consequence) Note: I do not want to change it, just to understand it. Context: Going from EPSG:4258 (--3d) to EPSG:5514+8357 is using both cz_cuzk_CR-2005.tif and cz_cuzk_table_-y-x_3_v1710.tif in 9.7.1 and 9.8.0 The difference is going from EPSG:4326 (--3d) to EPSG:5514+8357. In 9.7.1 it is not using cz_cuzk_table_-y-x_3_v1710.tif, but in 9.8.0 it does. (both use cz_cuzk_CR-2005.tif) What changed? PROJ, EPSG, both? Thank you. Javier PROJ 9.8.0: PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4326 EPSG:5514+8357 --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 Candidate operations found: 12 ------------------------------------- Operation No. 1: unknown id, Inverse of ETRS89-CZE [2007] to WGS 84 (1) + ETRS89-CZE [2007] to Baltic 1957 height (2) + Inverse of S-JTSK/05 to ETRS89-CZE [2007] (1) + Modified Krovak East North (Greenwich) + Inverse of S-JTSK / Krovak East North (EPSG:5514) to S-JTSK/05 / Modified Krovak East North (EPSG:5516) + Inverse of Krovak East North (Greenwich) + Krovak East North (Greenwich), 1.065 m, Czechia. ... pipeline omitted. It uses cz_cuzk_CR-2005.tif and cz_cuzk_table_-y-x_3_v1710.tif PROJ 9.7.1: PROJ_NETWORK=ON ./proj_9.7.1/bin/projinfo EPSG:4326 EPSG:5514+8357 --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 Candidate operations found: 7 ------------------------------------- Operation No. 1: unknown id, Inverse of ETRS89 to WGS 84 (1) + ETRS89 to Baltic 1957 height (2) + Inverse of S-JTSK to ETRS89 (1) + Krovak East North (Greenwich), 2.03 m, Czechia. ... pipeline omitted. It only uses cz_cuzk_CR-2005.tif As a reference, from EPSG:4258 it doing this PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4258 EPSG:5514+8357 --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 Candidate operations found: 10 ------------------------------------- Operation No. 1: PROJ:ETRS89_3D_TO_S_JTSK_E_N_BALTIC_HEIGHT, ETRS89 to S-JTSK / Krovak East North + Baltic 1957 height, 0.05 m, Czechia. ... pipeline omitted. It uses cz_cuzk_CR-2005.tif and cz_cuzk_table_-y-x_3_v1710.tif -------------- next part -------------- An HTML attachment was scrubbed... URL: From knudsen.thomas at gmail.com Wed Mar 11 01:45:32 2026 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Wed, 11 Mar 2026 09:45:32 +0100 Subject: [PROJ] Is PROJ unreasonably slow? Message-ID: TL;DR: Is PROJ unreasonably slow? The answer is "Mostly no", but with a few caveats... DISCLAIMER: The evidence presented below is weak - timing experiments repeated only 2-4 times, on just a single computer. But at first sight the speed tests all hint at the same conclusion: That PROJ could be made significantly faster. Closer inspection, however, shows that, while in some corner cases, PROJ really can be made faster, in the general cases, it already really is quite fast. But despite the weak evidence, and the limited speed gains expected, I allow myself to present the material here, to frame some potential items for discussion and/or action - because changes, that may improve speed, may also improve maintainability. And while the latter is hard to quantify, the former is readily quantifiable with a stop watch. Setting ------- I recently did a validation experiment, by reimplementing the PROJ based canonical transformation from ITRF2014 to SWEREF99, the Swedish ETRS89 realization. The reimplementation is based on Rust geodesy (RG) [1], and the validation is carried out by transforming a test set of 10 million randomly generated coordinates. First using the RG coordinate processing program "kp" [2], then the PROJ work horse "cs2cs" [3]. But I did not get around to actually validate, except for a handful of sufficiently convincing random checks. I got sidetracked by something more concerning - namely that PROJ appeared to be unreasonably slow: While kp transformed the 10 million coordinates in a little less than 17 seconds, cs2cs needed more than 20 minutes - i.e. a factor of approximately 75 times slower. Now, the ITRF2014->SWEREF99 transformation is non-trivial [5] and includes grid lookups in the 5th and 7th step of the pipeline (the grid was, by the way, already fully downloaded with projsync). So I had a hunch, that the random organization of the input data might be poison for PROJ's grid caching. And correctly so: After sorting the 10 million input points from north to south, the run time went from about 1200 seconds, to about 100 seconds. A respectable speed-up, although 6 times slower than RG. But as the points are still randomly (dis)organized in the east-west direction, there may be even more speed up possible for a more piecewise localized data set, such as the coordinates of e.g. a typical OGC "simple feature" geometry collection. But before constructing a test data set with such characteristics, I figured, I would take a closer look at some PROJ operators not depending on grid access, to get a feeling for how much time goes with accessing the test coordinates, and converting the external text format to the internal IEEE 754 floating point format. For this, I had to change tool from cs2cs, to cct [4]. But the results were still disappointing: Running the same 10 million coordinates through first a no-operation (proj=noop), then a pipeline of 8 concatenated noops, gave these results: NOOP Running kp first. One noop. kp: 8.95 s, cct: 83 s, (kp 9.27 times faster) Eight noops. kp: 9.38 s, cct: 97 s. (kp 10.34 times faster) Running cct first. One noop. kp: 9.56 s, cct: 83 s, (kp 8.68 times faster) Eight noops. kp: 9.65 s, cct: 92 s. (kp 9.53 times faster) To see what it costs to do some real computation, I also tried projecting the test coordinates to UTM zone 32. Here kp consistently ran at close to 13 seconds, while cct had 3 cases of close to 100 seconds, and an oddly speedy outlier of just 70 seconds. I suspect I may have misread the clock there. UTM Running kp first. utm zone=32 kp: 13.54 s, cct: 70 s, (kp 5.17 times faster) utm zone=32 kp: 12.37 s, cct: 96 s, (kp 7.76 times faster) Running cct first. utm zone=32 kp: 13.36 s, cct: 96 s, (kp 7.18 times faster) utm zone=32 kp: 13.57 s, cct: 101 s, (kp 7.43 times faster) But still, RG seems to be between 5 and 7 times faster than PROJ: Even when comparing the worst kp time with the outlying cct time, kp is still more than 5 times faster than cct. Why is it so? Some potential reasons ------------------------------------ FIRST, RG does grid access by lumping all grids together in an indexed file, a "unigrid", and accessing that file through memory mapping (the rationale, with the punchline "Don't implement poorly, what the OS already provides excellently!" is described in [6]). PROJ accesses files in chunks, and since, in PROJ, files are typically band interleaved, PROJ needs 3 accesses far away from each other, to get all relevant information for a single point value. Whereas RG uses point interleave, and hence gets all relevant information from a single read operation. Also, PROJ uses compressed files. And in this specific case (eur_nkg_nkg17rfvel.tiff), the file is just 303x313 grid nodes, each node consisting of 3 32 bit values, hence 303x313x3x4 bytes = 1_138_068 bytes. But the compression is rather modest: The compressed file weighs 715_692 bytes, i.e. a reduction of just 38%, but it prohibits direct access into the file. RG skips all this, accesses the file as if it is one long array, and leaves all caching/swapping to the OS, which has a much better general view of the system resources available, than any single running process. SECOND, PROJ handles single coordinates, while RG handles collections. Among other things, this leads to a reduction in the number of function calls: PROJ loops over the coordinates, and calls an operator on each coordinate, while RG calls an operator, and let the operator loop over the coordinates. For the same reason, PROJ needs to interpret a pipeline for each coordinate, while RG just interprets the pipeline once for each collection of e.g. 100_000 coordinates. Now, interpreting a pipeline is not a heavy task: Essentially, it is just an iterator over the steps of the pipeline. But it is a little piece of extra ceremony, that needs to be set up for every single coordinate. This leads me on to the THIRD potential reason, namely that PROJ's internal data flow is rather complex, carrying leftovers that made good sense back when PROJ was simply a projection library, but which are mostly annoying today. When all operators were projections, it made good sense to centralize the handling of e.g. the central meridian into the pj_fwd and pj_inv functions. Today, it is to a large degree something that needs being worked around, when the operator is not a projection, but another kind of geodetic operator [7]. Also, originally PROJ was strictly 2D, so pj_fwd and pj_inv handles 2D data only. When we had to extend it with both 3D and 4D variations, we also got functional duplication and undesired messiness. This is likely one of the reasons that PROJ's combined implementation of pipeline and stack functionality weighs in at 725 lines, while RG, which has a unified data flow architecture, provides (mostly) the same functionality in just 188 lines of code (in both cases including blank lines and comments). RG started its life as an experiment with simpler data flows in geodetic software. I believe it has succeeded in this respect. But I cannot yet provide conclusive evidence, that this difference between RG and PROJ, also results in faster execution. It is worth checking, though, and worth considering whether it is worth the effort to retrofit a similar data flow architecture into PROJ? It would clearly be a herculean task. How to interpret the numbers above? ----------------------------------- First and foremost: As I stated up front, the evidence is weak, but it is also unambiguous, and while being a far cry from being able to answer the question whether PROJ is "unreasonably slow" conclusively, at least it indicates that there are ways to making PROJ faster. Whether this will be worth the effort is another discussion. That said, onto the interpretation. The input file is 406 MB, and I ran the tests twice: Once with PROJ running first, once with RG running first. This should reveal whether disk caching made a difference. It doesn't seem to, however. The full SWEREF transformation pipeline is evidently unreasonably slow, and there is good evidence (the dramatic difference between sorted and random input), that this is due to a grid access corner case. So PROJ is unreasonably slow, when presented with unreasonable input data sets. Once the input is sorted, however, the PROJ timing clocks in at around 100 s, no matter whether we do the full transformation, the 8 noops, or the single UTM projection. So PROJ is very sensitive to the spatial ordering of input coordinate tuples. RG not at all. Given the description above (band interleave vs. node/pixel interleave, hand held caching vs. leaving it to the OS), this is probably not at all surprising. But PROJ has the additional feature of being able to automagically downloading missing grid files tile-wise, where RG is stuck with what the user has a priori entered into the unigrid, or manually post-registered at run time. In the present test case, the download-on-demand feature is (hopefully) not used, since the file is fully downloaded with projsync already. But might it influence the overall grid access speed? I have not looked into that part of the code recently, but I'm sure Even will spot it, if there are cheap gains to reap here. The I/O effect -------------- Now, let's assume that the single-NOOP case mostly reflects the effort of converting text based coordinates to the internal IEEE 754 binary format. I/O is clearly a large part of the difference between kp, and the (cct, cs2cs) tuple: "Anything" takes around 10 seconds for RG/kp, and "Anything" takes around 100 seconds for PROJ/(cct, cs2cs) - there is at least some evidence, that this is because string-to-double (and v.v.) are surprisingly heavyweight operations. But cs2cs uses the platform native `strtod()` function for string-to-double, while cct uses `proj_strtod()` [8], which a.o. allows underscores as thousands-separators (42_000). Both routines appear equally slow, compared to the Rust version used in kp. Apparently it just so happens, that the built in Rust converter is much faster than typical C/C++ implementations. This may very well be the case: Rust's float parsing was dramatically improved by Alexander Huszagh some years ago [9][10], but whether this could account for a 10 times speed up, compared to C, is unlikely. I do not trust myself to build a reliable C++ platform, for timing the "real functionality only" (i.e. ignoring the i/o overhead). I would, however, be willing to provide a Rust version for intercomparison, if anyone would take up the C++ task. But fortunately PROJ chairman, Kristian Evers, upon reading an early version of this text, reminded me, that the proj app supports binary I/O (and actually that exact part of the PROJ source code was the target of my first contribution to PROJ, way back in 1999. So shame on me for not thinking about this possibility). Running the utm-projection case through proj (the app), with binary input, significantly speeds up things, making PROJ almost as fast as RG, although with only half the size of input and output, since proj is strictly 2D. But switching to binary output as well, makes it even faster: With binary input and binary output, proj projects 10 million input points in just 3 seconds, i.e. 300 ns/point. This is roughly 4 times as fast as kp, although also with just half the amount of input and output, and no numeric conversion. This indicates that the floating point-to-string output is an even heavier load than the string-to-floating point input. This is perhaps not surprising, although the widespread interest in optimizing the former is much more recent for the latter. But taking a look at some published benchmarks is encouraging: David Tolnay's Rust based shootout [11] indicates that the very recent (November 2025) zmij-algorithm performs almost 8 times better than Rust's default floating point-to-string implementation. Even wilder, when comparing with system-supplied implementations: Victor Zverovich, the creator of the zmij algorithm, in his owm benchmarks [12] measures a 100 times (not 100%, 100 times!) speed up compared to the system provided ostringstream implementation, running on an Apple M1. Hence, we may expect the PROJ command line filters (proj, cct, cs2cs) to speed up significantly, as system libraries mature and include faster floating point-to-string-to-floating point operations... if that ever happens. Obviously, we could also decide to introduce dependencies on stand alone implementations, such as zmij. It is, however, questionable whether it is worth the effort: Back in the 1980's, when Gerald Evenden created PROJ (the system), it was to a very large degree in order to use proj (the app) to handle projections for his map plotting system, MAPGEN, where much of the work was implemented as Unix shell pipelines, hence constantly doing floating point I/O. I conjecture that this is also the reason for proj's binary I/O functionality: It may have sped up things significantly. At that time of history, switching to some (not yet available) floating point I/O algorithms would have made much sense, since so much work was done using shell pipelines. Today, we can safely assume that in most cases, PROJ is used as a linked library in a larger (GIS) system, and all inter-library communication is binary. When PROJ is used from the command line, it is (probably) mostly by specialists, testing hypotheses, or checking a few reference-system-defining benchmarks. And handling even tens of thousands of input points will take insignificant amounts of time on a reasonably modern computer. But I/O still takes some time: The recently launched "rewrite GDAL in Rust" initiative, OxiGDAL [13] uses proj4rs [14], for its coordinate handling (proj4rs is a Rust implementation of proj4js, which in turn is a JavaScript reimplementation of PROJ.4). And OxiGDAL claims a handling time of 100 ns/coordinate tuple. Comparing this to the 300 ns from proj (the app) above leads to the not-terribly-unreasonable conjecture that proj (the app) spends one third of its time reading, one third on computing, and the last third on writing the result. Hence, I would expect us to find, that the general functionality is comparable in speed between RG and PROJ (and proj4rs), while there is probably some modest gains to realize in PROJ's handling of grids. So to answer my initial question: No - PROJ is not unreasonably slow at the library level, although it sure can be sped up. But at the application level, there should be quite a bit of gains possible in the floating point parsing. Whether we should or should not take on this task is dubious: Although I wrote proj_strtod, I would not trust myself to doing a reliable C++ port of Alexander Huszagh's work from Rust. But in the other end of the I/O pipeline, the original version of the super fast zmij output algorithm is already written in C++, under a MIT licence, and hence unproblematic to use in the PROJ code base. But I would highly prefer to leave this kind of code to reside in system libraries, not in an application library, like PROJ. Nevertheless: Hope y'all will consider this (much too) long writeup, and give it a deep thought, whether rearchitecting PROJ, and to what extent, may be worth the effort. /Thomas Knudsen [1] Rust Geodesy: https://lib.rs/geodesy https://github.com/busstoptaktik/geodesy [2] kp: https://github.com/busstoptaktik/geodesy/blob/main/ruminations/003-rumination.md [3] cs2cs: https://proj.org/en/stable/apps/cs2cs.html [4] cct: https://proj.org/en/stable/apps/cct.html [5] The ITRF2014->SWEREF99 transformation: $ projinfo -o proj --hide-ballpark -s itrf2014 -t sweref99 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 +rz=-0.01617 +s=0 +dx=0 +dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=2010 +convention=position_vector +step +inv +proj=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif +ellps=GRS80 +step +proj=helmert +x=0.03054 +y=0.04606 +z=-0.07944 +rx=0.00141958 +ry=0.00015132 +rz=0.00150337 +s=0.003002 +convention=position_vector +step +proj=deformation +dt=-0.5 +grids=eur_nkg_nkgrf17vel.tif +ellps=GRS80 +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 [6] Rumination 012: Unigrids and the UG grid maintenance utility https://github.com/busstoptaktik/geodesy/blob/main/ruminations/012-rumination.md [7] Even Rouault om lam0: https://github.com/OSGeo/PROJ/pull/4667/changes#diff-bfb0c333155a0c8bf863b0a3e76df46cfddf646cd5f13d6313eb8a3cb123f5f1R58 [8] proj_strtod(): https://github.com/OSGeo/PROJ/blob/master/src/apps/proj_strtod.cpp [9] Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm https://github.com/rust-lang/rust/pull/86761 [10] Implementing a Fast, Correct Float Parser https://internals.rust-lang.org/t/implementing-a-fast-correct-float-parser/14670 [11] David Tolnay's dtoa-benchmark: https://github.com/dtolnay/dtoa-benchmark [12] Victor Zverovich's zmij algorithm: https://github.com/vitaut/zmij/ [13] OxiGDAL - Pure Rust Geospatial Data Abstraction Library: https://github.com/cool-japan/oxigdal [14] proj4rs - Rust adaptation of PROJ.4: https://crates.io/crates/proj4rs From j1 at jimenezshaw.com Wed Mar 11 09:10:30 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 11 Mar 2026 17:10:30 +0100 Subject: [PROJ] Finding not implemented projections In-Reply-To: References: Message-ID: Thank you Even. Doing it only once per projectionMethodName is very fast. Just as information, those are the 6 "invalid" projection methods in PROJ 9.7.1 (with the first code catching them) code: 2218 projection: Lambert Conic Conformal (West Orientated) ** invalid ** code: 2963 projection: Bonne (South Orientated) ** invalid ** code: 2985 projection: Polar Stereographic (variant C) ** invalid ** code: 22300 projection: Tunisia Mining Grid ** invalid ** code: 22700 projection: Lambert Conic Near-Conformal ** invalid ** code: 32600 projection: Transverse Mercator Zoned Grid System ** invalid ** On Thu, 26 Feb 2026 at 15:34, Even Rouault wrote: > Javier, > > nothing comes to mind but trying proj_as_proj_string() on them, but that > will be quite slow if you want to filter the whole list of CRS and do > that on every CRS. That said, you could pick up one CRS for each of the > value of projection_method_name to limit the number of CRS instantiation. > > Or add a new C function based on using one of > osgeo::proj::operation::getMapping() from > src/iso19111/operation/parammappings.hpp > > Even > > Le 26/02/2026 ? 11:29, Javier Jimenez Shaw via PROJ a ?crit : > > Hi > > > > Today I met "by accident" EPSG:3053 > > https://spatialreference.org/ref/epsg/3053/ > > looking for a westing-northing system. > > > > I realized that the projection "Lambert Conic Conformal (West > > Orientated)" is not implemented (all fine, I don't want it to be > > implemented). > > > > What I want to know is which CRSs from the catalog do not have an > > implemented projection, to avoid using them. > > We are using "proj_get_crs_info_list_from_database" to get the list of > > all the systems (13722). It includes the field > > "projection_method_name" (a string). > > Is there any function in C or C++ API to know if such a method is > > implemented? Doing a quick search in spatialreference I see there are > > 53 methods in total nowadays. > > I don't want to hardcode that list in my code, in case anything > > changes in the future. > > > > Thank you. > > > > Cheers > > Javier. > > > > _______________________________________________ > > PROJ mailing list > > PROJ at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/proj > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Mar 11 10:43:04 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 11 Mar 2026 18:43:04 +0100 Subject: [PROJ] Is PROJ unreasonably slow? In-Reply-To: References: Message-ID: Thomas, I don't know how you manage to write such long essays. Does my (non LLM generated) below summary reflect your findings: - Command line utilities are to be considered "toys" if you process a large amount of data and care about perf. Not that suprising, and I wouldn't expect anyone trying to use PROJ at its max perf capabilities to use them, but rather use the (binary) API. In GDAL, we use at some places the fast_float C++ header library for fast string->double : https://github.com/fastfloat/fast_float . They claim it can be up to about 4x faster than strtod(). We could also vendor in PROJ if needed. - Grid usage could be made much faster if we decompressed everything in memory. There's already a bit of caching of decompressed tiles. But random spatial access pattern will easily defeat it as it is quite modest currently. We could add an option to increase the cache to a specified size and/or increase the default size. I wouldn't trust too much OS virtual memory mapping. Can easily lead to crashing? your system??(or making it unusable at the point your need to hard reboot) if you map too much memory vs your available RAM. Even Le 11/03/2026 ? 09:45, Thomas Knudsen a ?crit?: > TL;DR: Is PROJ unreasonably slow? The answer is "Mostly no", but with a few > caveats... > > DISCLAIMER: The evidence presented below is weak - timing experiments repeated > only 2-4 times, on just a single computer. But at first sight the speed tests > all hint at the same conclusion: That PROJ could be made significantly faster. > > Closer inspection, however, shows that, while in some corner cases, PROJ really > can be made faster, in the general cases, it already really is quite fast. > > But despite the weak evidence, and the limited speed gains expected, I allow > myself to present the material here, to frame some potential items for > discussion and/or action - because changes, that may improve speed, may also > improve maintainability. And while the latter is hard to quantify, the former is > readily quantifiable with a stop watch. > > Setting > ------- > > I recently did a validation experiment, by reimplementing the PROJ based > canonical transformation from ITRF2014 to SWEREF99, the Swedish ETRS89 > realization. > > The reimplementation is based on Rust geodesy (RG) [1], and the validation is > carried out by transforming a test set of 10 million randomly generated > coordinates. First using the RG coordinate processing program "kp" [2], then the > PROJ work horse "cs2cs" [3]. > > But I did not get around to actually validate, except for a handful of > sufficiently convincing random checks. I got sidetracked by something more > concerning - namely that PROJ appeared to be unreasonably slow: > > While kp transformed the 10 million coordinates in a little less than 17 > seconds, cs2cs needed more than 20 minutes - i.e. a factor of approximately 75 > times slower. > > Now, the ITRF2014->SWEREF99 transformation is non-trivial [5] and includes grid > lookups in the 5th and 7th step of the pipeline (the grid was, by the way, > already fully downloaded with projsync). So I had a hunch, that the random > organization of the input data might be poison for PROJ's grid caching. And > correctly so: After sorting the 10 million input points from north to south, the > run time went from about 1200 seconds, to about 100 seconds. > > A respectable speed-up, although 6 times slower than RG. But as the points are > still randomly (dis)organized in the east-west direction, there may be even more > speed up possible for a more piecewise localized data set, such as the > coordinates of e.g. a typical OGC "simple feature" geometry collection. > > But before constructing a test data set with such characteristics, I figured, I > would take a closer look at some PROJ operators not depending on grid access, to > get a feeling for how much time goes with accessing the test coordinates, and > converting the external text format to the internal IEEE 754 floating point > format. > > For this, I had to change tool from cs2cs, to cct [4]. But the results were > still disappointing: Running the same 10 million coordinates through first a > no-operation (proj=noop), then a pipeline of 8 concatenated noops, gave these > results: > > NOOP > > Running kp first. > One noop. kp: 8.95 s, cct: 83 s, (kp 9.27 times faster) > Eight noops. kp: 9.38 s, cct: 97 s. (kp 10.34 times faster) > Running cct first. > One noop. kp: 9.56 s, cct: 83 s, (kp 8.68 times faster) > Eight noops. kp: 9.65 s, cct: 92 s. (kp 9.53 times faster) > > To see what it costs to do some real computation, I also tried projecting the > test coordinates to UTM zone 32. Here kp consistently ran at close to 13 > seconds, while cct had 3 cases of close to 100 seconds, and an oddly speedy > outlier of just 70 seconds. I suspect I may have misread the clock there. > > UTM > > Running kp first. > utm zone=32 kp: 13.54 s, cct: 70 s, (kp 5.17 times faster) > utm zone=32 kp: 12.37 s, cct: 96 s, (kp 7.76 times faster) > Running cct first. > utm zone=32 kp: 13.36 s, cct: 96 s, (kp 7.18 times faster) > utm zone=32 kp: 13.57 s, cct: 101 s, (kp 7.43 times faster) > > But still, RG seems to be between 5 and 7 times faster than PROJ: Even when > comparing the worst kp time with the outlying cct time, kp is still more than 5 > times faster than cct. > > Why is it so? Some potential reasons > ------------------------------------ > > FIRST, RG does grid access by lumping all grids together in an indexed file, a > "unigrid", and accessing that file through memory mapping (the rationale, with > the punchline "Don't implement poorly, what the OS already provides > excellently!" is described in [6]). > > PROJ accesses files in chunks, and since, in PROJ, files are typically band > interleaved, PROJ needs 3 accesses far away from each other, to get all relevant > information for a single point value. Whereas RG uses point interleave, and > hence gets all relevant information from a single read operation. > > Also, PROJ uses compressed files. And in this specific case > (eur_nkg_nkg17rfvel.tiff), the file is just 303x313 grid nodes, each node > consisting of 3 32 bit values, hence 303x313x3x4 bytes = 1_138_068 bytes. > > But the compression is rather modest: The compressed file weighs 715_692 bytes, > i.e. a reduction of just 38%, but it prohibits direct access into the file. > > RG skips all this, accesses the file as if it is one long array, and leaves all > caching/swapping to the OS, which has a much better general view of the system > resources available, than any single running process. > > SECOND, PROJ handles single coordinates, while RG handles collections. Among > other things, this leads to a reduction in the number of function calls: PROJ > loops over the coordinates, and calls an operator on each coordinate, while RG > calls an operator, and let the operator loop over the coordinates. For the same > reason, PROJ needs to interpret a pipeline for each coordinate, while RG just > interprets the pipeline once for each collection of e.g. 100_000 coordinates. > > Now, interpreting a pipeline is not a heavy task: Essentially, it is just an > iterator over the steps of the pipeline. But it is a little piece of extra > ceremony, that needs to be set up for every single coordinate. > > This leads me on to the THIRD potential reason, namely that PROJ's internal data > flow is rather complex, carrying leftovers that made good sense back when PROJ > was simply a projection library, but which are mostly annoying today. > > When all operators were projections, it made good sense to centralize the > handling of e.g. the central meridian into the pj_fwd and pj_inv functions. > Today, it is to a large degree something that needs being worked around, when > the operator is not a projection, but another kind of geodetic operator [7]. > > Also, originally PROJ was strictly 2D, so pj_fwd and pj_inv handles 2D data > only. When we had to extend it with both 3D and 4D variations, we also got > functional duplication and undesired messiness. This is likely one of the > reasons that PROJ's combined implementation of pipeline and stack functionality > weighs in at 725 lines, while RG, which has a unified data flow architecture, > provides (mostly) the same functionality in just 188 lines of code (in > both cases > including blank lines and comments). > > RG started its life as an experiment with simpler data flows in geodetic > software. I believe it has succeeded in this respect. But I cannot yet provide > conclusive evidence, that this difference between RG and PROJ, also results in > faster execution. It is worth checking, though, and worth considering whether it > is worth the effort to retrofit a similar data flow architecture into PROJ? It > would clearly be a herculean task. > > How to interpret the numbers above? > ----------------------------------- > > First and foremost: As I stated up front, the evidence is weak, but it is also > unambiguous, and while being a far cry from being able to answer the question > whether PROJ is "unreasonably slow" conclusively, at least it indicates that > there are ways to making PROJ faster. Whether this will be worth the effort is > another discussion. > > That said, onto the interpretation. > > The input file is 406 MB, and I ran the tests twice: Once with PROJ running > first, once with RG running first. This should reveal whether disk caching made > a difference. It doesn't seem to, however. > > The full SWEREF transformation pipeline is evidently unreasonably slow, and > there is good evidence (the dramatic difference between sorted and random > input), that this is due to a grid access corner case. So PROJ is unreasonably > slow, when presented with unreasonable input data sets. > > Once the input is sorted, however, the PROJ timing clocks in at around 100 s, no > matter whether we do the full transformation, the 8 noops, or the single UTM > projection. > > So PROJ is very sensitive to the spatial ordering of input coordinate tuples. RG > not at all. Given the description above (band interleave vs. node/pixel > interleave, hand held caching vs. leaving it to the OS), this is probably not at > all surprising. > > But PROJ has the additional feature of being able to automagically downloading > missing grid files tile-wise, where RG is stuck with what the user has a priori > entered into the unigrid, or manually post-registered at run time. > > In the present test case, the download-on-demand feature is (hopefully) not > used, since the file is fully downloaded with projsync already. But might it > influence the overall grid access speed? I have not looked into that part of the > code recently, but I'm sure Even will spot it, if there are cheap gains to reap > here. > > The I/O effect > -------------- > > Now, let's assume that the single-NOOP case mostly reflects the effort of > converting text based coordinates to the internal IEEE 754 binary format. I/O is > clearly a large part of the difference between kp, and the (cct, cs2cs) tuple: > "Anything" takes around 10 seconds for RG/kp, and "Anything" takes around 100 > seconds for PROJ/(cct, cs2cs) - there is at least some evidence, that this is > because string-to-double (and v.v.) are surprisingly heavyweight operations. > > But cs2cs uses the platform native `strtod()` function for string-to-double, > while cct uses `proj_strtod()` [8], which a.o. allows underscores as > thousands-separators (42_000). Both routines appear equally slow, compared to > the Rust version used in kp. > > Apparently it just so happens, that the built in Rust converter is much faster > than typical C/C++ implementations. This may very well be the case: Rust's float > parsing was dramatically improved by Alexander Huszagh some years ago [9][10], > but whether this could account for a 10 times speed up, compared to C, is > unlikely. > > I do not trust myself to build a reliable C++ platform, for timing the "real > functionality only" (i.e. ignoring the i/o overhead). I would, however, be > willing to provide a Rust version for intercomparison, if anyone would take up > the C++ task. > > But fortunately PROJ chairman, Kristian Evers, upon reading an early version of > this text, reminded me, that the proj app supports binary I/O (and actually that > exact part of the PROJ source code was the target of my first contribution to > PROJ, way back in 1999. So shame on me for not thinking about this possibility). > > Running the utm-projection case through proj (the app), with binary input, > significantly speeds up things, making PROJ almost as fast as RG, although with > only half the size of input and output, since proj is strictly 2D. > > But switching to binary output as well, makes it even faster: With binary input > and binary output, proj projects 10 million input points in just 3 seconds, i.e. > 300 ns/point. This is roughly 4 times as fast as kp, although also with just > half the amount of input and output, and no numeric conversion. > > This indicates that the floating point-to-string output is an even heavier load > than the string-to-floating point input. This is perhaps not surprising, > although the widespread interest in optimizing the former is much more recent > for the latter. > > But taking a look at some published benchmarks is encouraging: David Tolnay's > Rust based shootout [11] indicates that the very recent (November 2025) > zmij-algorithm performs almost 8 times better than Rust's default floating > point-to-string implementation. Even wilder, when comparing with system-supplied > implementations: Victor Zverovich, the creator of the zmij algorithm, in his owm > benchmarks [12] measures a 100 times (not 100%, 100 times!) speed up compared to > the system provided ostringstream implementation, running on an Apple M1. > > Hence, we may expect the PROJ command line filters (proj, cct, cs2cs) to speed > up significantly, as system libraries mature and include faster floating > point-to-string-to-floating point operations... if that ever happens. > > Obviously, we could also decide to introduce dependencies on stand alone > implementations, such as zmij. It is, however, questionable whether it is worth > the effort: Back in the 1980's, when Gerald Evenden created PROJ (the system), > it was to a very large degree in order to use proj (the app) to handle > projections for his map plotting system, MAPGEN, where much of the work was > implemented as Unix shell pipelines, hence constantly doing floating point I/O. > I conjecture that this is also the reason for proj's binary I/O functionality: > It may have sped up things significantly. > > At that time of history, switching to some (not yet available) floating point > I/O algorithms would have made much sense, since so much work was done using > shell pipelines. Today, we can safely assume that in most cases, PROJ is used as > a linked library in a larger (GIS) system, and all inter-library communication > is binary. > > When PROJ is used from the command line, it is (probably) mostly by specialists, > testing hypotheses, or checking a few reference-system-defining benchmarks. And > handling even tens of thousands of input points will take insignificant amounts > of time on a reasonably modern computer. > > But I/O still takes some time: The recently launched "rewrite GDAL in Rust" > initiative, OxiGDAL [13] uses proj4rs [14], for its coordinate handling (proj4rs > is a Rust implementation of proj4js, which in turn is a JavaScript > reimplementation of PROJ.4). And OxiGDAL claims a handling time of 100 > ns/coordinate tuple. Comparing this to the 300 ns from proj (the app) above > leads to the not-terribly-unreasonable conjecture that proj (the app) spends one > third of its time reading, one third on computing, and the last third on writing > the result. > > Hence, I would expect us to find, that the general functionality is comparable > in speed between RG and PROJ (and proj4rs), while there is probably some modest > gains to realize in PROJ's handling of grids. So to answer my initial question: > No - PROJ is not unreasonably slow at the library level, although it sure can be > sped up. > > But at the application level, there should be quite a bit of gains possible in > the floating point parsing. Whether we should or should not take on this task is > dubious: Although I wrote proj_strtod, I would not trust myself to doing a > reliable C++ port of Alexander Huszagh's work from Rust. But in the other end of > the I/O pipeline, the original version of the super fast zmij output algorithm > is already written in C++, under a MIT licence, and hence unproblematic to use > in the PROJ code base. > > But I would highly prefer to leave this kind of code to reside in system > libraries, not in an application library, like PROJ. > > Nevertheless: Hope y'all will consider this (much too) long writeup, and give it > a deep thought, whether rearchitecting PROJ, and to what extent, may be worth > the effort. > > /Thomas Knudsen > > > [1] Rust Geodesy: https://lib.rs/geodesy > https://github.com/busstoptaktik/geodesy > [2] kp: https://github.com/busstoptaktik/geodesy/blob/main/ruminations/003-rumination.md > [3] cs2cs: https://proj.org/en/stable/apps/cs2cs.html > [4] cct: https://proj.org/en/stable/apps/cct.html > [5] The ITRF2014->SWEREF99 transformation: > $ projinfo -o proj --hide-ballpark -s itrf2014 -t sweref99 > +proj=pipeline > +step +proj=axisswap +order=2,1 > +step +proj=unitconvert +xy_in=deg +xy_out=rad > +step +proj=cart +ellps=GRS80 > +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 > +rz=-0.01617 +s=0 > +dx=0 +dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 > +t_epoch=2010 +convention=position_vector > +step +inv +proj=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif > +ellps=GRS80 > +step +proj=helmert +x=0.03054 +y=0.04606 +z=-0.07944 +rx=0.00141958 > +ry=0.00015132 +rz=0.00150337 +s=0.003002 > +convention=position_vector > +step +proj=deformation +dt=-0.5 +grids=eur_nkg_nkgrf17vel.tif > +ellps=GRS80 > +step +inv +proj=cart +ellps=GRS80 > +step +proj=unitconvert +xy_in=rad +xy_out=deg > +step +proj=axisswap +order=2,1 > [6] Rumination 012: Unigrids and the UG grid maintenance utility > https://github.com/busstoptaktik/geodesy/blob/main/ruminations/012-rumination.md > [7] Even Rouault om lam0: > https://github.com/OSGeo/PROJ/pull/4667/changes#diff-bfb0c333155a0c8bf863b0a3e76df46cfddf646cd5f13d6313eb8a3cb123f5f1R58 > [8] proj_strtod(): > https://github.com/OSGeo/PROJ/blob/master/src/apps/proj_strtod.cpp > [9] Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm > https://github.com/rust-lang/rust/pull/86761 > [10] Implementing a Fast, Correct Float Parser > https://internals.rust-lang.org/t/implementing-a-fast-correct-float-parser/14670 > [11] David Tolnay's dtoa-benchmark: https://github.com/dtolnay/dtoa-benchmark > [12] Victor Zverovich's zmij algorithm: https://github.com/vitaut/zmij/ > [13] OxiGDAL - Pure Rust Geospatial Data Abstraction Library: > https://github.com/cool-japan/oxigdal > [14] proj4rs - Rust adaptation of PROJ.4: https://crates.io/crates/proj4rs -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Mar 11 13:36:24 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 11 Mar 2026 21:36:24 +0100 Subject: [PROJ] New national ETRS89 realisations in EPSG messing things up in PROJ 9.8.0? In-Reply-To: References: Message-ID: <7c2c003d-cec8-4861-b8c8-d9942ebef735@spatialys.com> Jochem, Yes, this is related to the ETRS89 related changes in the EPSG database. EPSG:9281 which used to be? "Amersfoort to ETRS89 (8)" has been renamed to "Amersfoort to ETRS89-NLD [AGRS2010] (8)" and its target CRS is now the national realization CRS "ETRS89-NLD [AGRS2010]" instead of the generic ETRS89 one (similarly for?Amersfoort to ETRS89 (9)).? ?PROJ prefers to do ETRF2000 to Amersfoort doing ETRF2000 -> ETRS89? (using a null transformation created from the datum ensemble at EPSG database import)? followed by inverse "Amersfoort to ETRS89 (5)"? , rather than ETRF2000 -> ETRS89-NLD [AGRS2010] +? inverse??"Amersfoort to ETRS89-NLD [AGRS2010] (8)"? because we have a direct transformation between the CRS code for ETRF2000 -> ETRS89 , which shortcircuits the attempt at trying ETRF2000 ->?ETRS89-NLD [AGRS2010] which requires more effort from a database search point of view, since the "ETRS89-NLD [AGRS2010] to ETRF2000 (1)" transformation is between the geocentric CRS. In https://github.com/OSGeo/PROJ/pull/4709, I've added logic to force the more expensive look up if the result set from the lighter look ups only return operations using a datum ensemble member <--> datum ensemble null transformation. Regarding ETRS89 to Amersfoort, this is even worse since there are direct transformations between both, which stops PROJ from searching more. I've also been able to tweak that case since all those operations have a remark that they have been replaced by others. So in that case, we also use the more expensive lookup which finally finds the operations going through?ETRS89-NLD [AGRS2010] Even Le 10/03/2026 ? 14:56, Lesparre, Jochem via PROJ a ?crit?: > > Some transformations that used to give correct results (e.g. in PROJ > 9.7.1) do no longer give results according to the official > transformation (Amersfoort to ETRS89 (9)) of the Dutch national > authority in PROJ 9.8.0. > > I suspect it has to do with the introduction of national realisations > of ETRS89 in EPSG. Complicating factor is that EPSG erroneously > removed the superseded label from some outdated transformations > (Amersfoort to ETRS89 (5) and Amersfoort to ETRS89 (6)). However, > these old transformations have a lower accuracy than the official one, > so I think PROJ should be able to still find the official transformation. > > Why can?t PROJ find it? Is there something else wrong in EPSG, > preventing PROJ to find the official transformation? Or is this an > issue in PROJ 9.8.0? > > Jochem > > *Example 1: Forward* > > From the national ETRS89 realisation to the national projected CRS, > PROJ uses the correct transformation Amersfoort to ETRS89 (9): > > projinfo EPSG:11037 EPSG:28992 --spatial-test intersects -o proj > --hide-ballpark > > But from ETRF2000 and the ETRS89 ensemble PROJ doesn?t use the > official transformation of the national authority anymore: > > projinfo EPSG:9067 EPSG:28992 --spatial-test intersects -o proj > --hide-ballpark > > projinfo EPSG:4258 EPSG:28992 --spatial-test intersects -o proj > --hide-ballpark > > *Example 2: Reverse* > > From the national projected CRS to the national ETRS89 realisation, > PROJ uses the correct transformation Amersfoort to ETRS89 (9): > > projinfo EPSG:28992 EPSG:11037 --spatial-test intersects -o proj > --hide-ballpark > > But to ETRF2000 and the ETRS89 ensemble PROJ doesn?t use the official > transformation of the national authority anymore: > > projinfo EPSG:28992 EPSG:9067 --spatial-test intersects -o proj > --hide-ballpark > > projinfo EPSG:28992 EPSG:4258 --spatial-test intersects -o proj > --hide-ballpark > > > > Disclaimer: > De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor > de geadresseerde(n). > Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of > verstrekking van deze informatie aan derden is niet toegestaan. > Op al onze producten en diensten zijn onze algemene > leveringsvoorwaarden van toepassing > [https://www.kadaster.nl/algemene-leveringsvoorwaarden]. > > Disclaimer: > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. > If you are not the intended recipient, you are notified that > disclosing, copying, distributing or taking any action in reliance on > the contents of this information is strictly prohibited. > Our general terms and conditions of delivery apply to all our products > and services > [https://www.kadaster.com/general-terms-and-conditions]. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Mar 11 14:04:29 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 11 Mar 2026 22:04:29 +0100 Subject: [PROJ] Different behaviour between 9.7.1 and 9.8.0 In-Reply-To: References: Message-ID: <454b9fb2-704a-41c4-9ac2-a50274fb76aa@spatialys.com> Javier, I suspect this is due to commit 3717ff00afa6872a2ae581de929ba5559ff84438 where I tweaked transformations_czechia.sql, presumably to make existing tests pass following to the addition of "ETRS89-CZE [2007]". Only a git bisect session would confirm Even Le 10/03/2026 ? 16:43, Javier Jimenez Shaw via PROJ a ?crit?: > Hi > > This change in behaviour is a surprise to me. I would like to know > what changed (I know the ETRS89 datum ensemble, but I was not > expecting this consequence) > > Note: I do not want to change it, just to understand it. > > Context: Going from EPSG:4258 (--3d) to EPSG:5514+8357 is using > both?cz_cuzk_CR-2005.tif and?cz_cuzk_table_-y-x_3_v1710.tif in 9.7.1 > and 9.8.0 > > The difference is going from EPSG:4326 (--3d) to EPSG:5514+8357. In > 9.7.1 it is not using?cz_cuzk_table_-y-x_3_v1710.tif, but in 9.8.0 it > does. (both use?cz_cuzk_CR-2005.tif) > > What changed? PROJ, EPSG, both? > > Thank you. > Javier > > PROJ 9.8.0: > PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4326 EPSG:5514+8357 > --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 12 > ------------------------------------- > Operation No. 1: > > unknown id, Inverse of ETRS89-CZE [2007] to WGS 84 (1) + ETRS89-CZE > [2007] to Baltic 1957 height (2) + Inverse of S-JTSK/05 to ETRS89-CZE > [2007] (1) + Modified Krovak East North (Greenwich) + Inverse of > S-JTSK / Krovak East North (EPSG:5514) to S-JTSK/05 / Modified Krovak > East North (EPSG:5516) + Inverse of Krovak East North (Greenwich) + > Krovak East North (Greenwich), 1.065 m, Czechia. > > ... pipeline omitted. It uses?cz_cuzk_CR-2005.tif > and?cz_cuzk_table_-y-x_3_v1710.tif > > PROJ 9.7.1: > PROJ_NETWORK=ON ./proj_9.7.1/bin/projinfo EPSG:4326 EPSG:5514+8357 > --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 7 > ------------------------------------- > Operation No. 1: > > unknown id, Inverse of ETRS89 to WGS 84 (1) + ETRS89 to Baltic 1957 > height (2) + Inverse of S-JTSK to ETRS89 (1) + Krovak East North > (Greenwich), 2.03 m, Czechia. > > ... pipeline omitted. It only uses?cz_cuzk_CR-2005.tif > > > As a reference, from EPSG:4258 it doing this > > PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4258 EPSG:5514+8357 > --3d --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 10 > ------------------------------------- > Operation No. 1: > > PROJ:ETRS89_3D_TO_S_JTSK_E_N_BALTIC_HEIGHT, ETRS89 to S-JTSK / Krovak > East North + Baltic 1957 height, 0.05 m, Czechia. > > ... pipeline omitted. It uses?cz_cuzk_CR-2005.tif > and?cz_cuzk_table_-y-x_3_v1710.tif > > > > > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Wed Mar 11 14:14:40 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 11 Mar 2026 22:14:40 +0100 Subject: [PROJ] Different behaviour between 9.7.1 and 9.8.0 In-Reply-To: <454b9fb2-704a-41c4-9ac2-a50274fb76aa@spatialys.com> References: <454b9fb2-704a-41c4-9ac2-a50274fb76aa@spatialys.com> Message-ID: Thank you Even. I was not aware of those changes... it is easy to miss something on the EPSG updates. The same way I missed the new German CRS from 2025. On Wed, 11 Mar 2026 at 22:04, Even Rouault wrote: > Javier, > > I suspect this is due to commit 3717ff00afa6872a2ae581de929ba5559ff84438 > where I tweaked transformations_czechia.sql, presumably to make existing > tests pass following to the addition of "ETRS89-CZE [2007]". Only a git > bisect session would confirm > > Even > Le 10/03/2026 ? 16:43, Javier Jimenez Shaw via PROJ a ?crit : > > Hi > > This change in behaviour is a surprise to me. I would like to know what > changed (I know the ETRS89 datum ensemble, but I was not expecting this > consequence) > > Note: I do not want to change it, just to understand it. > > Context: Going from EPSG:4258 (--3d) to EPSG:5514+8357 is using > both cz_cuzk_CR-2005.tif and cz_cuzk_table_-y-x_3_v1710.tif in 9.7.1 and > 9.8.0 > > The difference is going from EPSG:4326 (--3d) to EPSG:5514+8357. In 9.7.1 > it is not using cz_cuzk_table_-y-x_3_v1710.tif, but in 9.8.0 it does. (both > use cz_cuzk_CR-2005.tif) > > What changed? PROJ, EPSG, both? > > Thank you. > Javier > > PROJ 9.8.0: > PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4326 EPSG:5514+8357 --3d > --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 12 > ------------------------------------- > Operation No. 1: > > unknown id, Inverse of ETRS89-CZE [2007] to WGS 84 (1) + ETRS89-CZE [2007] > to Baltic 1957 height (2) + Inverse of S-JTSK/05 to ETRS89-CZE [2007] (1) + > Modified Krovak East North (Greenwich) + Inverse of S-JTSK / Krovak East > North (EPSG:5514) to S-JTSK/05 / Modified Krovak East North (EPSG:5516) + > Inverse of Krovak East North (Greenwich) + Krovak East North (Greenwich), > 1.065 m, Czechia. > > ... pipeline omitted. It uses cz_cuzk_CR-2005.tif > and cz_cuzk_table_-y-x_3_v1710.tif > > PROJ 9.7.1: > PROJ_NETWORK=ON ./proj_9.7.1/bin/projinfo EPSG:4326 EPSG:5514+8357 --3d > --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 7 > ------------------------------------- > Operation No. 1: > > unknown id, Inverse of ETRS89 to WGS 84 (1) + ETRS89 to Baltic 1957 height > (2) + Inverse of S-JTSK to ETRS89 (1) + Krovak East North (Greenwich), 2.03 > m, Czechia. > > ... pipeline omitted. It only uses cz_cuzk_CR-2005.tif > > > As a reference, from EPSG:4258 it doing this > > PROJ_NETWORK=ON ./proj_9.8.0/bin/projinfo EPSG:4258 EPSG:5514+8357 --3d > --spatial-test intersects --bbox 15,50,15.1,50.1 -o proj | head -n 40 > Candidate operations found: 10 > ------------------------------------- > Operation No. 1: > > PROJ:ETRS89_3D_TO_S_JTSK_E_N_BALTIC_HEIGHT, ETRS89 to S-JTSK / Krovak > East North + Baltic 1957 height, 0.05 m, Czechia. > > ... pipeline omitted. It uses cz_cuzk_CR-2005.tif > and cz_cuzk_table_-y-x_3_v1710.tif > > > > > > _______________________________________________ > PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Mar 11 15:03:39 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 11 Mar 2026 23:03:39 +0100 Subject: [PROJ] LLM/AI tool policy Message-ID: Folks, after GDAL and QGIS, I strongly suspect we also now receive LLM driven contributions. What about adopting https://gdal.org/en/stable/community/ai_tool_policy.html with s/GDAL/PROJ ? Even -- http://www.spatialys.com My software is free, but my time generally not. From Jochem.Lesparre at kadaster.nl Thu Mar 12 03:02:14 2026 From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem) Date: Thu, 12 Mar 2026 10:02:14 +0000 Subject: [PROJ] New national ETRS89 realisations in EPSG messing things up in PROJ 9.8.0? In-Reply-To: <7c2c003d-cec8-4861-b8c8-d9942ebef735@spatialys.com> References: <7c2c003d-cec8-4861-b8c8-d9942ebef735@spatialys.com> Message-ID: Thanks for these changes, Even! The Amersfoort / RD to ETRF2000 and ETRS89 transformations are used quite a lot, and not using the route with Amersfoort to ETRS89-NLD [AGRS2010] (9) creates errors up to 0.25 m for users (and questions from them to me). Hopefully, PROJ 9.8.0 with the inaccurate routes won?t end up in QGIS. Also thanks for the explanation on how PROJ searches for transformations routes. I thought it built a graph of all transformations and do an accuracy-weighted shortest path search with some penalties to prevent too many transformation steps, but PROJ is a bit more heuristic than that. Jochem Disclaimer: De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing [https://www.kadaster.nl/algemene-leveringsvoorwaarden]. Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Our general terms and conditions of delivery apply to all our products and services [https://www.kadaster.com/general-terms-and-conditions]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Mar 12 03:09:52 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 12 Mar 2026 11:09:52 +0100 Subject: [PROJ] New national ETRS89 realisations in EPSG messing things up in PROJ 9.8.0? In-Reply-To: References: <7c2c003d-cec8-4861-b8c8-d9942ebef735@spatialys.com> Message-ID: <8d946404-dd9c-470c-ba6d-959ce990ebe4@spatialys.com> > Also thanks for the explanation on how PROJ searches for > transformations routes. I thought it built a graph of all > transformations and do an accuracy-weighted shortest path search with > some penalties to prevent too many transformation steps, but PROJ is a > bit more heuristic than that. > There are situations where if you use the most complicated SQL requests it supports (and PROJ just limits itself to finding a single intermediate step...)? you can end up with several hundreds or more potential transformation pipelines, with runtime of the order of second. While the execution of the pipeline is of the order of the microsecond for a coordinate. So before going to that, it checks if the results of less costly requests look to be good enough. > > Jochem > > > > Disclaimer: > De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor > de geadresseerde(n). > Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of > verstrekking van deze informatie aan derden is niet toegestaan. > Op al onze producten en diensten zijn onze algemene > leveringsvoorwaarden van toepassing > [https://www.kadaster.nl/algemene-leveringsvoorwaarden]. > > Disclaimer: > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. > If you are not the intended recipient, you are notified that > disclosing, copying, distributing or taking any action in reliance on > the contents of this information is strictly prohibited. > Our general terms and conditions of delivery apply to all our products > and services > [https://www.kadaster.com/general-terms-and-conditions]. -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Mar 12 04:17:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 12 Mar 2026 12:17:45 +0100 Subject: [PROJ] Fwd: LLM/AI tool policy In-Reply-To: References: Message-ID: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> (resending due to yesterday's OSGeo server maintenance) -------- Message transf?r? -------- Sujet?: LLM/AI tool policy Date?: Wed, 11 Mar 2026 23:03:39 +0100 De?: Even Rouault Pour?: proj Folks, after GDAL and QGIS, I strongly suspect we also now receive LLM driven contributions. What about adopting https://gdal.org/en/stable/community/ai_tool_policy.html with s/GDAL/PROJ ? Even -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From knudsen.thomas at gmail.com Thu Mar 12 10:14:12 2026 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Thu, 12 Mar 2026 18:14:12 +0100 Subject: [PROJ] Fwd: LLM/AI tool policy In-Reply-To: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> References: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> Message-ID: I have spent a few minutes trying very hard to disagree with the contents of the GDAL AI tool policy. Unfortunately (and much to my regret ?), I did not find a single word, letter, whitespace character, or punctuation mark worth disagreeing with. I would, however, suggest modifying Even's suggestion of "s/GDAL/PROJ/" to the only slightly more verbose "s/GDAL/PROJ/g" ? /Thomas Den tors. 12. mar. 2026 kl. 17.38 skrev Even Rouault via PROJ < proj at lists.osgeo.org>: > (resending due to yesterday's OSGeo server maintenance) > > -------- Message transf?r? -------- > Sujet : LLM/AI tool policy > Date : Wed, 11 Mar 2026 23:03:39 +0100 > De : Even Rouault > > Pour : proj > > Folks, > > after GDAL and QGIS, I strongly suspect we also now receive LLM driven > contributions. What about adopting > https://gdal.org/en/stable/community/ai_tool_policy.html with s/GDAL/PROJ > ? > > Even > > -- http://www.spatialys.com > My software is free, but my time generally not. > > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Thu Mar 12 12:40:40 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 12 Mar 2026 20:40:40 +0100 Subject: [PROJ] Is PROJ unreasonably slow? In-Reply-To: References: Message-ID: Hi Thomas It took me some time to read the email. I hope it is not a revenge for my last emails containing some explicit WKT2 ;) That is good news! If a projection library, with all the trigonometric and complicated functions it is calling, is affected by reading and writing doubles in input/output, it means that the library is really efficient. Maybe not in the parsing of the strings, but the rest it is. When I started reading the email a while ago, my first reaction was "many people say std streams are not efficient". About caching grid files, we could probably add an environment variable (read only once) to set the cache size to a value. That could give you some flexibility requesting random points. Remove compression? well, maybe the Swedish files are small. The new geoid model for US will not fit in the size limit per file we have in GitHub. We will have to do some tricks to include it (like use int16 instead of float32). In summary I agree with Even: command line apps are "toys" for testing/playing. Can we improve that performance? Probably. Is it worth it? I don't know. Is your fear that they use it to compare with other libraries, and PROJ is minus-valued? Could be. About grids in memory, there is always the trade off between memory economics and performance. We can be more flexible for extreme cases as yours. Maybe I am missing other points inside the library where we are slow and we can improve. Please, let me know. Cheers Javier. On Wed, 11 Mar 2026 at 18:43, Even Rouault wrote: > Thomas, > > I don't know how you manage to write such long essays. Does my (non LLM > generated) below summary reflect your findings: > > - Command line utilities are to be considered "toys" if you process a > large amount of data and care about perf. Not that suprising, and I > wouldn't expect anyone trying to use PROJ at its max perf capabilities > to use them, but rather use the (binary) API. In GDAL, we use at some > places the fast_float C++ header library for fast string->double : > https://github.com/fastfloat/fast_float . They claim it can be up to > about 4x faster than strtod(). We could also vendor in PROJ if needed. > > - Grid usage could be made much faster if we decompressed everything in > memory. There's already a bit of caching of decompressed tiles. But > random spatial access pattern will easily defeat it as it is quite > modest currently. We could add an option to increase the cache to a > specified size and/or increase the default size. I wouldn't trust too > much OS virtual memory mapping. Can easily lead to crashing your > system (or making it unusable at the point your need to hard reboot) if > you map too much memory vs your available RAM. > > Even > > Le 11/03/2026 ? 09:45, Thomas Knudsen a ?crit : > > TL;DR: Is PROJ unreasonably slow? The answer is "Mostly no", but with a > few > > caveats... > > > > DISCLAIMER: The evidence presented below is weak - timing experiments > repeated > > only 2-4 times, on just a single computer. But at first sight the speed > tests > > all hint at the same conclusion: That PROJ could be made significantly > faster. > > > > Closer inspection, however, shows that, while in some corner cases, PROJ > really > > can be made faster, in the general cases, it already really is quite > fast. > > > ... deleted content. > > > > But I would highly prefer to leave this kind of code to reside in system > > libraries, not in an application library, like PROJ. > > > > Nevertheless: Hope y'all will consider this (much too) long writeup, and > give it > > a deep thought, whether rearchitecting PROJ, and to what extent, may be > worth > > the effort. > > > > /Thomas Knudsen > > > > > > [1] Rust Geodesy: https://lib.rs/geodesy > > https://github.com/busstoptaktik/geodesy > > [2] kp: > https://github.com/busstoptaktik/geodesy/blob/main/ruminations/003-rumination.md > > [3] cs2cs: https://proj.org/en/stable/apps/cs2cs.html > > [4] cct: https://proj.org/en/stable/apps/cct.html > > [5] The ITRF2014->SWEREF99 transformation: > > $ projinfo -o proj --hide-ballpark -s itrf2014 -t sweref99 > > +proj=pipeline > > +step +proj=axisswap +order=2,1 > > +step +proj=unitconvert +xy_in=deg +xy_out=rad > > +step +proj=cart +ellps=GRS80 > > +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 > > +rz=-0.01617 +s=0 > > +dx=0 +dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 > +ds=0 > > +t_epoch=2010 +convention=position_vector > > +step +inv +proj=deformation +t_epoch=2000 > +grids=eur_nkg_nkgrf17vel.tif > > +ellps=GRS80 > > +step +proj=helmert +x=0.03054 +y=0.04606 +z=-0.07944 > +rx=0.00141958 > > +ry=0.00015132 +rz=0.00150337 +s=0.003002 > > +convention=position_vector > > +step +proj=deformation +dt=-0.5 +grids=eur_nkg_nkgrf17vel.tif > > +ellps=GRS80 > > +step +inv +proj=cart +ellps=GRS80 > > +step +proj=unitconvert +xy_in=rad +xy_out=deg > > +step +proj=axisswap +order=2,1 > > [6] Rumination 012: Unigrids and the UG grid maintenance utility > > > https://github.com/busstoptaktik/geodesy/blob/main/ruminations/012-rumination.md > > [7] Even Rouault om lam0: > > > https://github.com/OSGeo/PROJ/pull/4667/changes#diff-bfb0c333155a0c8bf863b0a3e76df46cfddf646cd5f13d6313eb8a3cb123f5f1R58 > > [8] proj_strtod(): > > https://github.com/OSGeo/PROJ/blob/master/src/apps/proj_strtod.cpp > > [9] Update Rust Float-Parsing Algorithms to use the Eisel-Lemire > algorithm > > https://github.com/rust-lang/rust/pull/86761 > > [10] Implementing a Fast, Correct Float Parser > > > https://internals.rust-lang.org/t/implementing-a-fast-correct-float-parser/14670 > > [11] David Tolnay's dtoa-benchmark: > https://github.com/dtolnay/dtoa-benchmark > > [12] Victor Zverovich's zmij algorithm: https://github.com/vitaut/zmij/ > > [13] OxiGDAL - Pure Rust Geospatial Data Abstraction Library: > > https://github.com/cool-japan/oxigdal > > [14] proj4rs - Rust adaptation of PROJ.4: > https://crates.io/crates/proj4rs > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Thu Mar 12 13:00:39 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 12 Mar 2026 21:00:39 +0100 Subject: [PROJ] Fwd: LLM/AI tool policy In-Reply-To: References: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> Message-ID: As a first step I find it ok. Let's see if it is enough. On Thu, 12 Mar 2026 at 18:14, Thomas Knudsen via PROJ wrote: > I have spent a few minutes trying very hard to disagree with the contents > of the GDAL AI tool policy. Unfortunately (and much to my regret ?), I > did not find a single word, letter, whitespace character, or punctuation > mark worth disagreeing with. > > I would, however, suggest modifying Even's suggestion of "s/GDAL/PROJ/" to > the only slightly more verbose "s/GDAL/PROJ/g" ? > > /Thomas > > > Den tors. 12. mar. 2026 kl. 17.38 skrev Even Rouault via PROJ < > proj at lists.osgeo.org>: > >> (resending due to yesterday's OSGeo server maintenance) >> >> -------- Message transf?r? -------- >> Sujet : LLM/AI tool policy >> Date : Wed, 11 Mar 2026 23:03:39 +0100 >> De : Even Rouault >> >> Pour : proj >> >> Folks, >> >> after GDAL and QGIS, I strongly suspect we also now receive LLM driven >> contributions. What about adopting >> https://gdal.org/en/stable/community/ai_tool_policy.html with >> s/GDAL/PROJ ? >> >> Even >> >> -- http://www.spatialys.com >> My software is free, but my time generally not. >> >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwehr at gmail.com Thu Mar 12 13:35:39 2026 From: schwehr at gmail.com (Kurt Schwehr) Date: Thu, 12 Mar 2026 13:35:39 -0700 Subject: [PROJ] Fwd: LLM/AI tool policy In-Reply-To: References: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> Message-ID: Heh. The point of the point of my LLM list was definitely just how silly / annoying this stuff can be. I'm currently getting eaten alive by AI stuff for my non-PROJ/GDAL work. I spend most of my day slogging through AI generated comments and code trying to figure out what is good, not good, or needs my help to become good. Or I'm trying to figure out how to prompt the tools to do what I want them to. +1 on the LLM coding world currently being stressful when the results are not throw away material. On Thu, Mar 12, 2026 at 1:01?PM Javier Jimenez Shaw via PROJ < proj at lists.osgeo.org> wrote: > As a first step I find it ok. Let's see if it is enough. > > On Thu, 12 Mar 2026 at 18:14, Thomas Knudsen via PROJ < > proj at lists.osgeo.org> wrote: > >> I have spent a few minutes trying very hard to disagree with the contents >> of the GDAL AI tool policy. Unfortunately (and much to my regret ?), I >> did not find a single word, letter, whitespace character, or punctuation >> mark worth disagreeing with. >> >> I would, however, suggest modifying Even's suggestion of "s/GDAL/PROJ/" >> to the only slightly more verbose "s/GDAL/PROJ/g" ? >> >> /Thomas >> >> >> Den tors. 12. mar. 2026 kl. 17.38 skrev Even Rouault via PROJ < >> proj at lists.osgeo.org>: >> >>> (resending due to yesterday's OSGeo server maintenance) >>> >>> -------- Message transf?r? -------- >>> Sujet : LLM/AI tool policy >>> Date : Wed, 11 Mar 2026 23:03:39 +0100 >>> De : Even Rouault >>> >>> Pour : proj >>> >>> Folks, >>> >>> after GDAL and QGIS, I strongly suspect we also now receive LLM driven >>> contributions. What about adopting >>> https://gdal.org/en/stable/community/ai_tool_policy.html with >>> s/GDAL/PROJ ? >>> >>> Even >>> >>> -- http://www.spatialys.com >>> My software is free, but my time generally not. >>> >>> >>> _______________________________________________ >>> PROJ mailing list >>> PROJ at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/proj >>> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian at evers.dev Thu Mar 12 14:30:05 2026 From: kristian at evers.dev (Kristian Evers) Date: Thu, 12 Mar 2026 21:30:05 +0000 Subject: [PROJ] LLM/AI tool policy In-Reply-To: References: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> Message-ID: <00D08F40-D93F-4DF2-B3BC-A791347EBA3E@evers.dev> The influx of LLM-written issues and PRs has definitely increased lately. I find the policy text rather good and am in favour of adopting it. Probably should be formalised in a RFC. Thanks for bringing it up, Even. /Kristian > On 12 Mar 2026, at 21.35, Kurt Schwehr via PROJ wrote: > > Heh. The point of the point of my LLM list was definitely just how silly / annoying this stuff can be. > > I'm currently getting eaten alive by AI stuff for my non-PROJ/GDAL work. I spend most of my day slogging through AI generated comments and code trying to figure out what is good, not good, or needs my help to become good. Or I'm trying to figure out how to prompt the tools to do what I want them to. > > +1 on the LLM coding world currently being stressful when the results are not throw away material. > > On Thu, Mar 12, 2026 at 1:01?PM Javier Jimenez Shaw via PROJ wrote: > >> As a first step I find it ok. Let's see if it is enough. >> >> On Thu, 12 Mar 2026 at 18:14, Thomas Knudsen via PROJ wrote: >> >>> I have spent a few minutes trying very hard to disagree with the contents of the GDAL AI tool policy. Unfortunately (and much to my regret ?), I did not find a single word, letter, whitespace character, or punctuation mark worth disagreeing with. >>> >>> I would, however, suggest modifying Even's suggestion of "s/GDAL/PROJ/" to the only slightly more verbose "s/GDAL/PROJ/g" ? >>> >>> /Thomas >>> >>> Den tors. 12. mar. 2026 kl. 17.38 skrev Even Rouault via PROJ : >>> >>>> (resending due to yesterday's OSGeo server maintenance) >>>> >>>> -------- Message transf?r? -------- >>>> Sujet : LLM/AI tool policy >>>> Date : Wed, 11 Mar 2026 23:03:39 +0100 >>>> De : Even Rouault [](mailto:even.rouault at spatialys.com) >>>> Pour : proj [](mailto:proj at lists.osgeo.org) >>>> >>>> Folks, >>>> >>>> after GDAL and QGIS, I strongly suspect we also now receive LLM driven contributions. What about adopting https://gdal.org/en/stable/community/ai_tool_policy.html with s/GDAL/PROJ ? >>>> >>>> Even >>>> >>>> -- >>>> [http://www.spatialys.com](http://www.spatialys.com/) >>>> My software is free, but my time generally not. >>>> >>>> _______________________________________________ >>>> PROJ mailing list >>>> PROJ at lists.osgeo.org >>>> https://lists.osgeo.org/mailman/listinfo/proj >>> >>> _______________________________________________ >>> PROJ mailing list >>> PROJ at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/proj >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Mar 12 14:39:48 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 12 Mar 2026 22:39:48 +0100 Subject: [PROJ] LLM/AI tool policy In-Reply-To: <00D08F40-D93F-4DF2-B3BC-A791347EBA3E@evers.dev> References: <0354b362-52f6-4a1a-9c7b-26d22805aafc@spatialys.com> <00D08F40-D93F-4DF2-B3BC-A791347EBA3E@evers.dev> Message-ID: <3cd2e7e3-3cc4-48c8-8fd5-041578ed5965@spatialys.com> Le 12/03/2026 ? 22:30, Kristian Evers via PROJ a ?crit?: > The influx of LLM-written issues and PRs has definitely increased > lately. I find the policy text rather good and am in favour of > adopting it. Probably should be formalised in a RFC. I'll skip that formality. I've already done that exercise for both QGIS and GDAL... Consider this thread + https://github.com/OSGeo/PROJ/pull/4710 as the RFC.? ?I'll launch an email vote once conversation settles. -- http://www.spatialys.com My software is free, but my time generally not. From knudsen.thomas at gmail.com Fri Mar 13 02:38:31 2026 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Fri, 13 Mar 2026 10:38:31 +0100 Subject: [PROJ] Is PROJ unreasonably slow? In-Reply-To: References: Message-ID: > don't know how you manage to write such long essays. If we include your coding capabilities, I believe you are a far more productive writer than I am :-) I have once suggested that "productivity in geospatial programming" should be measured in the unit "Rouault" (Rt). I estimated, that the entire world's capacity of geospatial programming is on the order of 4 Rt, of which you by definition, represent one. We, the rest of the world then split the remaining 3 Rt, of which I, on a good day, may lurk in the low milli-Rouaults. > Does my (non LLM generated) below summary reflect your findings At least some of them. I agree that one should not expect speed miracles using text based I/O. On the other hand, with JSON and XML based formats being so important, text based I/O is important as well, even when not rooted in a shell pipeline. >From a communication viewpoint, text I/O in the shell command line is very important, because it is an unambiguous way of describing the exact operation to carry out, including direct inline sample results. I have probably at least a hundred times described, to a colleague or external user, the proper incantation for a given task by including two lines in in the style of: $ echo 55 12 | proj -r +proj=utm +zone=32 +ellps=GRS80 691875.63 6098907.83 But in these cases, obviously throughput is not a problem. Regarding decompressing and caching, I am too unfamiliar with the details of that part of PROJ to actually have an opinion worth considering, although I could see a reason for using interleave-by-point, rather than by-band, to get both channels of a datum-shift-grid at once. On the other hand, except for the pathological case of randomly scattered points, the grid handling seems plenty fast already, so probably not worth the effort. My main architectural suggestion was to unify the data flow, removing all the variations of pj_fwd and pj_inv, and all the ceremony in pj_prepare and pj_finalize. This would probably lead to slightly more code, as each operator should implement the functionality provided by prepare/finalize, but it would only need to handle the individually relevant branches, rather than having the centralized versions inferring what to do. This would, however, be quite intrusive, but we could get rid of the code adapting each operator to the pj_fwd/pj_fwd3d/pj_fwd4d multiplex. In Rust Geodesy, the unified 4D data flow was what I started with. Later on, I introduced the CoordinateSet trait, of which implementations are provided for the simple "array-of-1d/2d/3d/4d-coordinate" cases, and which users can implement for their own data structures (e.g. an OGC GeometryCollection), making it possible to handle in-place transformations of coordinates embedded in more general data types. Much like what is provided by proj_trans_generic, but more general, and without the danger of needing to manually specify the offsets of each coordinate dimension. (Rust traits = "kind of like" Python Abstract Base Classes or C++ virtual base classes) Hence, while Rust Geodesy has a unified data flow, the physical width is determined by the input data. I'm quite sure a similar architecture would result in more clear code, but retrofitting the architecture everywhere in PROJ would, as I wrote, be a Herculean task. On the other hand: It may be possible to implement in smaller steps. My main concern really just is, that we should not ignore the long term maintenance of the "classical parts" of PROJ - especially not, if we can find a way to do it in smaller steps. Rust Geodesy was an experiment wrt. architecture. I think it has been quite successful in that respect, but would it be worth the effort retrofitting a similar architecture onto PROJ? > I wouldn't trust too much OS virtual memory mapping. Can easily lead to > crashing your system (or making it unusable at the point your need to hard > reboot) if you map too much memory vs your available RAM. This is clearly the case for 32-bit systems. But read-only mapping of large files "should" be a lazy process where pages are only loaded upon demand. And since the access patterns tend to be localized, the demand may be meagre. But the Rust Geodesy Unigrid is clearly an experiment, and I'm yet to flesh it out fully. One thing I consider is to force a 16x16 blocking, meaning that even for 3 channel grids, a block will fit into a 4k memory page. Experience from our old transformation system, trlib, shows that for typical usage patterns, 16x16 block access is very efficient, since a typical task will only require one, or a few, block accesses. But how this will work in the case of memory mapped input remains to be seen - and will probably be highly OS-dependent, and probably restricted to 64-bit systems. But thanks for your warning - I will take it ad notam, and tread carefully! /Thomas Den ons. 11. mar. 2026 kl. 18.43 skrev Even Rouault : > > Thomas, > > I don't know how you manage to write such long essays. Does my (non LLM > generated) below summary reflect your findings: > > - Command line utilities are to be considered "toys" if you process a > large amount of data and care about perf. Not that suprising, and I > wouldn't expect anyone trying to use PROJ at its max perf capabilities > to use them, but rather use the (binary) API. In GDAL, we use at some > places the fast_float C++ header library for fast string->double : > https://github.com/fastfloat/fast_float . They claim it can be up to > about 4x faster than strtod(). We could also vendor in PROJ if needed. > > - Grid usage could be made much faster if we decompressed everything in > memory. There's already a bit of caching of decompressed tiles. But > random spatial access pattern will easily defeat it as it is quite > modest currently. We could add an option to increase the cache to a > specified size and/or increase the default size. I wouldn't trust too > much OS virtual memory mapping. Can easily lead to crashing your > system (or making it unusable at the point your need to hard reboot) if > you map too much memory vs your available RAM. > > Even > > Le 11/03/2026 ? 09:45, Thomas Knudsen a ?crit : > > TL;DR: Is PROJ unreasonably slow? The answer is "Mostly no", but with a few > > caveats... > > > > DISCLAIMER: The evidence presented below is weak - timing experiments repeated > > only 2-4 times, on just a single computer. But at first sight the speed tests > > all hint at the same conclusion: That PROJ could be made significantly faster. > > > > Closer inspection, however, shows that, while in some corner cases, PROJ really > > can be made faster, in the general cases, it already really is quite fast. > > > > But despite the weak evidence, and the limited speed gains expected, I allow > > myself to present the material here, to frame some potential items for > > discussion and/or action - because changes, that may improve speed, may also > > improve maintainability. And while the latter is hard to quantify, the former is > > readily quantifiable with a stop watch. > > > > Setting > > ------- > > > > I recently did a validation experiment, by reimplementing the PROJ based > > canonical transformation from ITRF2014 to SWEREF99, the Swedish ETRS89 > > realization. > > > > The reimplementation is based on Rust geodesy (RG) [1], and the validation is > > carried out by transforming a test set of 10 million randomly generated > > coordinates. First using the RG coordinate processing program "kp" [2], then the > > PROJ work horse "cs2cs" [3]. > > > > But I did not get around to actually validate, except for a handful of > > sufficiently convincing random checks. I got sidetracked by something more > > concerning - namely that PROJ appeared to be unreasonably slow: > > > > While kp transformed the 10 million coordinates in a little less than 17 > > seconds, cs2cs needed more than 20 minutes - i.e. a factor of approximately 75 > > times slower. > > > > Now, the ITRF2014->SWEREF99 transformation is non-trivial [5] and includes grid > > lookups in the 5th and 7th step of the pipeline (the grid was, by the way, > > already fully downloaded with projsync). So I had a hunch, that the random > > organization of the input data might be poison for PROJ's grid caching. And > > correctly so: After sorting the 10 million input points from north to south, the > > run time went from about 1200 seconds, to about 100 seconds. > > > > A respectable speed-up, although 6 times slower than RG. But as the points are > > still randomly (dis)organized in the east-west direction, there may be even more > > speed up possible for a more piecewise localized data set, such as the > > coordinates of e.g. a typical OGC "simple feature" geometry collection. > > > > But before constructing a test data set with such characteristics, I figured, I > > would take a closer look at some PROJ operators not depending on grid access, to > > get a feeling for how much time goes with accessing the test coordinates, and > > converting the external text format to the internal IEEE 754 floating point > > format. > > > > For this, I had to change tool from cs2cs, to cct [4]. But the results were > > still disappointing: Running the same 10 million coordinates through first a > > no-operation (proj=noop), then a pipeline of 8 concatenated noops, gave these > > results: > > > > NOOP > > > > Running kp first. > > One noop. kp: 8.95 s, cct: 83 s, (kp 9.27 times faster) > > Eight noops. kp: 9.38 s, cct: 97 s. (kp 10.34 times faster) > > Running cct first. > > One noop. kp: 9.56 s, cct: 83 s, (kp 8.68 times faster) > > Eight noops. kp: 9.65 s, cct: 92 s. (kp 9.53 times faster) > > > > To see what it costs to do some real computation, I also tried projecting the > > test coordinates to UTM zone 32. Here kp consistently ran at close to 13 > > seconds, while cct had 3 cases of close to 100 seconds, and an oddly speedy > > outlier of just 70 seconds. I suspect I may have misread the clock there. > > > > UTM > > > > Running kp first. > > utm zone=32 kp: 13.54 s, cct: 70 s, (kp 5.17 times faster) > > utm zone=32 kp: 12.37 s, cct: 96 s, (kp 7.76 times faster) > > Running cct first. > > utm zone=32 kp: 13.36 s, cct: 96 s, (kp 7.18 times faster) > > utm zone=32 kp: 13.57 s, cct: 101 s, (kp 7.43 times faster) > > > > But still, RG seems to be between 5 and 7 times faster than PROJ: Even when > > comparing the worst kp time with the outlying cct time, kp is still more than 5 > > times faster than cct. > > > > Why is it so? Some potential reasons > > ------------------------------------ > > > > FIRST, RG does grid access by lumping all grids together in an indexed file, a > > "unigrid", and accessing that file through memory mapping (the rationale, with > > the punchline "Don't implement poorly, what the OS already provides > > excellently!" is described in [6]). > > > > PROJ accesses files in chunks, and since, in PROJ, files are typically band > > interleaved, PROJ needs 3 accesses far away from each other, to get all relevant > > information for a single point value. Whereas RG uses point interleave, and > > hence gets all relevant information from a single read operation. > > > > Also, PROJ uses compressed files. And in this specific case > > (eur_nkg_nkg17rfvel.tiff), the file is just 303x313 grid nodes, each node > > consisting of 3 32 bit values, hence 303x313x3x4 bytes = 1_138_068 bytes. > > > > But the compression is rather modest: The compressed file weighs 715_692 bytes, > > i.e. a reduction of just 38%, but it prohibits direct access into the file. > > > > RG skips all this, accesses the file as if it is one long array, and leaves all > > caching/swapping to the OS, which has a much better general view of the system > > resources available, than any single running process. > > > > SECOND, PROJ handles single coordinates, while RG handles collections. Among > > other things, this leads to a reduction in the number of function calls: PROJ > > loops over the coordinates, and calls an operator on each coordinate, while RG > > calls an operator, and let the operator loop over the coordinates. For the same > > reason, PROJ needs to interpret a pipeline for each coordinate, while RG just > > interprets the pipeline once for each collection of e.g. 100_000 coordinates. > > > > Now, interpreting a pipeline is not a heavy task: Essentially, it is just an > > iterator over the steps of the pipeline. But it is a little piece of extra > > ceremony, that needs to be set up for every single coordinate. > > > > This leads me on to the THIRD potential reason, namely that PROJ's internal data > > flow is rather complex, carrying leftovers that made good sense back when PROJ > > was simply a projection library, but which are mostly annoying today. > > > > When all operators were projections, it made good sense to centralize the > > handling of e.g. the central meridian into the pj_fwd and pj_inv functions. > > Today, it is to a large degree something that needs being worked around, when > > the operator is not a projection, but another kind of geodetic operator [7]. > > > > Also, originally PROJ was strictly 2D, so pj_fwd and pj_inv handles 2D data > > only. When we had to extend it with both 3D and 4D variations, we also got > > functional duplication and undesired messiness. This is likely one of the > > reasons that PROJ's combined implementation of pipeline and stack functionality > > weighs in at 725 lines, while RG, which has a unified data flow architecture, > > provides (mostly) the same functionality in just 188 lines of code (in > > both cases > > including blank lines and comments). > > > > RG started its life as an experiment with simpler data flows in geodetic > > software. I believe it has succeeded in this respect. But I cannot yet provide > > conclusive evidence, that this difference between RG and PROJ, also results in > > faster execution. It is worth checking, though, and worth considering whether it > > is worth the effort to retrofit a similar data flow architecture into PROJ? It > > would clearly be a herculean task. > > > > How to interpret the numbers above? > > ----------------------------------- > > > > First and foremost: As I stated up front, the evidence is weak, but it is also > > unambiguous, and while being a far cry from being able to answer the question > > whether PROJ is "unreasonably slow" conclusively, at least it indicates that > > there are ways to making PROJ faster. Whether this will be worth the effort is > > another discussion. > > > > That said, onto the interpretation. > > > > The input file is 406 MB, and I ran the tests twice: Once with PROJ running > > first, once with RG running first. This should reveal whether disk caching made > > a difference. It doesn't seem to, however. > > > > The full SWEREF transformation pipeline is evidently unreasonably slow, and > > there is good evidence (the dramatic difference between sorted and random > > input), that this is due to a grid access corner case. So PROJ is unreasonably > > slow, when presented with unreasonable input data sets. > > > > Once the input is sorted, however, the PROJ timing clocks in at around 100 s, no > > matter whether we do the full transformation, the 8 noops, or the single UTM > > projection. > > > > So PROJ is very sensitive to the spatial ordering of input coordinate tuples. RG > > not at all. Given the description above (band interleave vs. node/pixel > > interleave, hand held caching vs. leaving it to the OS), this is probably not at > > all surprising. > > > > But PROJ has the additional feature of being able to automagically downloading > > missing grid files tile-wise, where RG is stuck with what the user has a priori > > entered into the unigrid, or manually post-registered at run time. > > > > In the present test case, the download-on-demand feature is (hopefully) not > > used, since the file is fully downloaded with projsync already. But might it > > influence the overall grid access speed? I have not looked into that part of the > > code recently, but I'm sure Even will spot it, if there are cheap gains to reap > > here. > > > > The I/O effect > > -------------- > > > > Now, let's assume that the single-NOOP case mostly reflects the effort of > > converting text based coordinates to the internal IEEE 754 binary format. I/O is > > clearly a large part of the difference between kp, and the (cct, cs2cs) tuple: > > "Anything" takes around 10 seconds for RG/kp, and "Anything" takes around 100 > > seconds for PROJ/(cct, cs2cs) - there is at least some evidence, that this is > > because string-to-double (and v.v.) are surprisingly heavyweight operations. > > > > But cs2cs uses the platform native `strtod()` function for string-to-double, > > while cct uses `proj_strtod()` [8], which a.o. allows underscores as > > thousands-separators (42_000). Both routines appear equally slow, compared to > > the Rust version used in kp. > > > > Apparently it just so happens, that the built in Rust converter is much faster > > than typical C/C++ implementations. This may very well be the case: Rust's float > > parsing was dramatically improved by Alexander Huszagh some years ago [9][10], > > but whether this could account for a 10 times speed up, compared to C, is > > unlikely. > > > > I do not trust myself to build a reliable C++ platform, for timing the "real > > functionality only" (i.e. ignoring the i/o overhead). I would, however, be > > willing to provide a Rust version for intercomparison, if anyone would take up > > the C++ task. > > > > But fortunately PROJ chairman, Kristian Evers, upon reading an early version of > > this text, reminded me, that the proj app supports binary I/O (and actually that > > exact part of the PROJ source code was the target of my first contribution to > > PROJ, way back in 1999. So shame on me for not thinking about this possibility). > > > > Running the utm-projection case through proj (the app), with binary input, > > significantly speeds up things, making PROJ almost as fast as RG, although with > > only half the size of input and output, since proj is strictly 2D. > > > > But switching to binary output as well, makes it even faster: With binary input > > and binary output, proj projects 10 million input points in just 3 seconds, i.e. > > 300 ns/point. This is roughly 4 times as fast as kp, although also with just > > half the amount of input and output, and no numeric conversion. > > > > This indicates that the floating point-to-string output is an even heavier load > > than the string-to-floating point input. This is perhaps not surprising, > > although the widespread interest in optimizing the former is much more recent > > for the latter. > > > > But taking a look at some published benchmarks is encouraging: David Tolnay's > > Rust based shootout [11] indicates that the very recent (November 2025) > > zmij-algorithm performs almost 8 times better than Rust's default floating > > point-to-string implementation. Even wilder, when comparing with system-supplied > > implementations: Victor Zverovich, the creator of the zmij algorithm, in his owm > > benchmarks [12] measures a 100 times (not 100%, 100 times!) speed up compared to > > the system provided ostringstream implementation, running on an Apple M1. > > > > Hence, we may expect the PROJ command line filters (proj, cct, cs2cs) to speed > > up significantly, as system libraries mature and include faster floating > > point-to-string-to-floating point operations... if that ever happens. > > > > Obviously, we could also decide to introduce dependencies on stand alone > > implementations, such as zmij. It is, however, questionable whether it is worth > > the effort: Back in the 1980's, when Gerald Evenden created PROJ (the system), > > it was to a very large degree in order to use proj (the app) to handle > > projections for his map plotting system, MAPGEN, where much of the work was > > implemented as Unix shell pipelines, hence constantly doing floating point I/O. > > I conjecture that this is also the reason for proj's binary I/O functionality: > > It may have sped up things significantly. > > > > At that time of history, switching to some (not yet available) floating point > > I/O algorithms would have made much sense, since so much work was done using > > shell pipelines. Today, we can safely assume that in most cases, PROJ is used as > > a linked library in a larger (GIS) system, and all inter-library communication > > is binary. > > > > When PROJ is used from the command line, it is (probably) mostly by specialists, > > testing hypotheses, or checking a few reference-system-defining benchmarks. And > > handling even tens of thousands of input points will take insignificant amounts > > of time on a reasonably modern computer. > > > > But I/O still takes some time: The recently launched "rewrite GDAL in Rust" > > initiative, OxiGDAL [13] uses proj4rs [14], for its coordinate handling (proj4rs > > is a Rust implementation of proj4js, which in turn is a JavaScript > > reimplementation of PROJ.4). And OxiGDAL claims a handling time of 100 > > ns/coordinate tuple. Comparing this to the 300 ns from proj (the app) above > > leads to the not-terribly-unreasonable conjecture that proj (the app) spends one > > third of its time reading, one third on computing, and the last third on writing > > the result. > > > > Hence, I would expect us to find, that the general functionality is comparable > > in speed between RG and PROJ (and proj4rs), while there is probably some modest > > gains to realize in PROJ's handling of grids. So to answer my initial question: > > No - PROJ is not unreasonably slow at the library level, although it sure can be > > sped up. > > > > But at the application level, there should be quite a bit of gains possible in > > the floating point parsing. Whether we should or should not take on this task is > > dubious: Although I wrote proj_strtod, I would not trust myself to doing a > > reliable C++ port of Alexander Huszagh's work from Rust. But in the other end of > > the I/O pipeline, the original version of the super fast zmij output algorithm > > is already written in C++, under a MIT licence, and hence unproblematic to use > > in the PROJ code base. > > > > But I would highly prefer to leave this kind of code to reside in system > > libraries, not in an application library, like PROJ. > > > > Nevertheless: Hope y'all will consider this (much too) long writeup, and give it > > a deep thought, whether rearchitecting PROJ, and to what extent, may be worth > > the effort. > > > > /Thomas Knudsen > > > > > > [1] Rust Geodesy: https://lib.rs/geodesy > > https://github.com/busstoptaktik/geodesy > > [2] kp: https://github.com/busstoptaktik/geodesy/blob/main/ruminations/003-rumination.md > > [3] cs2cs: https://proj.org/en/stable/apps/cs2cs.html > > [4] cct: https://proj.org/en/stable/apps/cct.html > > [5] The ITRF2014->SWEREF99 transformation: > > $ projinfo -o proj --hide-ballpark -s itrf2014 -t sweref99 > > +proj=pipeline > > +step +proj=axisswap +order=2,1 > > +step +proj=unitconvert +xy_in=deg +xy_out=rad > > +step +proj=cart +ellps=GRS80 > > +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 > > +rz=-0.01617 +s=0 > > +dx=0 +dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 > > +t_epoch=2010 +convention=position_vector > > +step +inv +proj=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif > > +ellps=GRS80 > > +step +proj=helmert +x=0.03054 +y=0.04606 +z=-0.07944 +rx=0.00141958 > > +ry=0.00015132 +rz=0.00150337 +s=0.003002 > > +convention=position_vector > > +step +proj=deformation +dt=-0.5 +grids=eur_nkg_nkgrf17vel.tif > > +ellps=GRS80 > > +step +inv +proj=cart +ellps=GRS80 > > +step +proj=unitconvert +xy_in=rad +xy_out=deg > > +step +proj=axisswap +order=2,1 > > [6] Rumination 012: Unigrids and the UG grid maintenance utility > > https://github.com/busstoptaktik/geodesy/blob/main/ruminations/012-rumination.md > > [7] Even Rouault om lam0: > > https://github.com/OSGeo/PROJ/pull/4667/changes#diff-bfb0c333155a0c8bf863b0a3e76df46cfddf646cd5f13d6313eb8a3cb123f5f1R58 > > [8] proj_strtod(): > > https://github.com/OSGeo/PROJ/blob/master/src/apps/proj_strtod.cpp > > [9] Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm > > https://github.com/rust-lang/rust/pull/86761 > > [10] Implementing a Fast, Correct Float Parser > > https://internals.rust-lang.org/t/implementing-a-fast-correct-float-parser/14670 > > [11] David Tolnay's dtoa-benchmark: https://github.com/dtolnay/dtoa-benchmark > > [12] Victor Zverovich's zmij algorithm: https://github.com/vitaut/zmij/ > > [13] OxiGDAL - Pure Rust Geospatial Data Abstraction Library: > > https://github.com/cool-japan/oxigdal > > [14] proj4rs - Rust adaptation of PROJ.4: https://crates.io/crates/proj4rs > > -- > http://www.spatialys.com > My software is free, but my time generally not. > From knudsen.thomas at gmail.com Fri Mar 13 03:18:20 2026 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Fri, 13 Mar 2026 11:18:20 +0100 Subject: [PROJ] Is PROJ unreasonably slow? In-Reply-To: References: Message-ID: > I hope it is not a revenge for my last emails containing some explicit WKT2 @Javier: Definitely not - you are probably one of the friendliest people, I have met, so I would never ponder staging revenge plans in your general direction :-) > That is good news! If a projection library, with all the trigonometric and > complicated functions it is calling, is affected by reading and writing > doubles in input/output, it means that the library is really efficient Definitely good news. My first reaction to the initial results, until I understood how to interpret them, was "this is really bad news". On the other hand I found it unbelievable, because PROJ and Rust Geodesy largely implement the same algorithms (and some of them even implemented by me in both cases), and I wouldn't expect just switching between two compiled languages could make that much of a difference. Fortunately it didn't! > Remove compression? well, maybe the Swedish files are small. I did not suggest ot remove the compression - I just stated that compression eliminates the possibility of direct access, so choosing one implies the other > About grids in memory, there is always the trade off between memory economics > and performance Absolutely! And my reason for testing the Unigrid 1:1 menory mapping is to leave the memory economics considerations to the OS, which has a much better general view of the memory situation. In a sense, any kind of explicit caching/reading ahead is an attempt of second-guessing the OS, so the Unigrid experiment is a matter of testing whether the OS catches the hint of "do your thing - I trust your decisions". As long as the file is mapped read-only, dropping cached pages is in principle close to zero-cost, so mapping infinitely large files should be a realistic possibility. But that's the theory. How it plays out practically may be another thing. I do, however, remember Poul-Henning Kamp, lead developer of the Varnish web cache system, expressing that one of the reasons for Varnish's efficiency was that it did not try to second-guess the OS. So that's what I try (not) to :-) /Thomas Den tors. 12. mar. 2026 kl. 20.40 skrev Javier Jimenez Shaw : > > Hi Thomas > > It took me some time to read the email. I hope it is not a revenge for my last emails containing some explicit WKT2 ;) > > That is good news! If a projection library, with all the trigonometric and complicated functions it is calling, is affected by reading and writing doubles in input/output, it means that the library is really efficient. > Maybe not in the parsing of the strings, but the rest it is. > When I started reading the email a while ago, my first reaction was "many people say std streams are not efficient". > > About caching grid files, we could probably add an environment variable (read only once) to set the cache size to a value. That could give you some flexibility requesting random points. > Remove compression? well, maybe the Swedish files are small. The new geoid model for US will not fit in the size limit per file we have in GitHub. We will have to do some tricks to include it (like use int16 instead of float32). > > In summary I agree with Even: command line apps are "toys" for testing/playing. Can we improve that performance? Probably. Is it worth it? I don't know. Is your fear that they use it to compare with other libraries, and PROJ is minus-valued? Could be. > About grids in memory, there is always the trade off between memory economics and performance. We can be more flexible for extreme cases as yours. > > Maybe I am missing other points inside the library where we are slow and we can improve. Please, let me know. > > Cheers > Javier. > > > On Wed, 11 Mar 2026 at 18:43, Even Rouault wrote: >> >> Thomas, >> >> I don't know how you manage to write such long essays. Does my (non LLM >> generated) below summary reflect your findings: >> >> - Command line utilities are to be considered "toys" if you process a >> large amount of data and care about perf. Not that suprising, and I >> wouldn't expect anyone trying to use PROJ at its max perf capabilities >> to use them, but rather use the (binary) API. In GDAL, we use at some >> places the fast_float C++ header library for fast string->double : >> https://github.com/fastfloat/fast_float . They claim it can be up to >> about 4x faster than strtod(). We could also vendor in PROJ if needed. >> >> - Grid usage could be made much faster if we decompressed everything in >> memory. There's already a bit of caching of decompressed tiles. But >> random spatial access pattern will easily defeat it as it is quite >> modest currently. We could add an option to increase the cache to a >> specified size and/or increase the default size. I wouldn't trust too >> much OS virtual memory mapping. Can easily lead to crashing your >> system (or making it unusable at the point your need to hard reboot) if >> you map too much memory vs your available RAM. >> >> Even >> >> Le 11/03/2026 ? 09:45, Thomas Knudsen a ?crit : >> > TL;DR: Is PROJ unreasonably slow? The answer is "Mostly no", but with a few >> > caveats... >> > >> > DISCLAIMER: The evidence presented below is weak - timing experiments repeated >> > only 2-4 times, on just a single computer. But at first sight the speed tests >> > all hint at the same conclusion: That PROJ could be made significantly faster. >> > >> > Closer inspection, however, shows that, while in some corner cases, PROJ really >> > can be made faster, in the general cases, it already really is quite fast. >> > >> ... deleted content. >> > >> > But I would highly prefer to leave this kind of code to reside in system >> > libraries, not in an application library, like PROJ. >> > >> > Nevertheless: Hope y'all will consider this (much too) long writeup, and give it >> > a deep thought, whether rearchitecting PROJ, and to what extent, may be worth >> > the effort. >> > >> > /Thomas Knudsen >> > >> > >> > [1] Rust Geodesy: https://lib.rs/geodesy >> > https://github.com/busstoptaktik/geodesy >> > [2] kp: https://github.com/busstoptaktik/geodesy/blob/main/ruminations/003-rumination.md >> > [3] cs2cs: https://proj.org/en/stable/apps/cs2cs.html >> > [4] cct: https://proj.org/en/stable/apps/cct.html >> > [5] The ITRF2014->SWEREF99 transformation: >> > $ projinfo -o proj --hide-ballpark -s itrf2014 -t sweref99 >> > +proj=pipeline >> > +step +proj=axisswap +order=2,1 >> > +step +proj=unitconvert +xy_in=deg +xy_out=rad >> > +step +proj=cart +ellps=GRS80 >> > +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 >> > +rz=-0.01617 +s=0 >> > +dx=0 +dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 >> > +t_epoch=2010 +convention=position_vector >> > +step +inv +proj=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif >> > +ellps=GRS80 >> > +step +proj=helmert +x=0.03054 +y=0.04606 +z=-0.07944 +rx=0.00141958 >> > +ry=0.00015132 +rz=0.00150337 +s=0.003002 >> > +convention=position_vector >> > +step +proj=deformation +dt=-0.5 +grids=eur_nkg_nkgrf17vel.tif >> > +ellps=GRS80 >> > +step +inv +proj=cart +ellps=GRS80 >> > +step +proj=unitconvert +xy_in=rad +xy_out=deg >> > +step +proj=axisswap +order=2,1 >> > [6] Rumination 012: Unigrids and the UG grid maintenance utility >> > https://github.com/busstoptaktik/geodesy/blob/main/ruminations/012-rumination.md >> > [7] Even Rouault om lam0: >> > https://github.com/OSGeo/PROJ/pull/4667/changes#diff-bfb0c333155a0c8bf863b0a3e76df46cfddf646cd5f13d6313eb8a3cb123f5f1R58 >> > [8] proj_strtod(): >> > https://github.com/OSGeo/PROJ/blob/master/src/apps/proj_strtod.cpp >> > [9] Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm >> > https://github.com/rust-lang/rust/pull/86761 >> > [10] Implementing a Fast, Correct Float Parser >> > https://internals.rust-lang.org/t/implementing-a-fast-correct-float-parser/14670 >> > [11] David Tolnay's dtoa-benchmark: https://github.com/dtolnay/dtoa-benchmark >> > [12] Victor Zverovich's zmij algorithm: https://github.com/vitaut/zmij/ >> > [13] OxiGDAL - Pure Rust Geospatial Data Abstraction Library: >> > https://github.com/cool-japan/oxigdal >> > [14] proj4rs - Rust adaptation of PROJ.4: https://crates.io/crates/proj4rs >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> From even.rouault at spatialys.com Sat Mar 14 07:49:53 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 14 Mar 2026 15:49:53 +0100 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: References: Message-ID: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Hi, Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Sat Mar 14 07:51:33 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sat, 14 Mar 2026 15:51:33 +0100 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> References: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Message-ID: +1 Javier On Sat, 14 Mar 2026, 15:50 Even Rouault via PROJ, wrote: > Hi, > > Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwehr at gmail.com Sat Mar 14 11:32:29 2026 From: schwehr at gmail.com (Kurt Schwehr) Date: Sat, 14 Mar 2026 11:32:29 -0700 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> References: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Message-ID: +1 KurtS On Sat, Mar 14, 2026, 7:50?AM Even Rouault via PROJ wrote: > Hi, > > Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard at hobu.co Sat Mar 14 15:14:41 2026 From: howard at hobu.co (Howard Butler) Date: Sat, 14 Mar 2026 17:14:41 -0500 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: References: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Message-ID: <9BAC403F-BFC8-4E9F-81FE-81BFE7094957@hobu.co> +1 Howard > On Mar 14, 2026, at 1:32?PM, Kurt Schwehr via PROJ wrote: > > +1 KurtS > > On Sat, Mar 14, 2026, 7:50?AM Even Rouault via PROJ > wrote: >> Hi, >> >> Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 >> >> Starting with my +1 >> >> Even >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Sat Mar 14 15:53:06 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sat, 14 Mar 2026 23:53:06 +0100 Subject: [PROJ] transformations with epoch Message-ID: Hi I have been playing with epochs today. Maybe I am understanding something wrongly, but the outputs are very strange. My deductions are: - the 4th dimension (v_4) from the input is just copied into the output of cs2cs. Independently of epoch flags. - if --s_epoch or --t_epoch are set, the input v_4 is ignored (but still printed in the output) - if only --s_epoch or --t_epoch is set, v_4 is set before and after the transformation to that value - if both are set, v_4 is set to s_epoch before transforming, and to t_epoch after. So in this case t_epoch only works to tag the output time,... but it is not displayed in cs2cs (it is in the C function) Is that correct? Why is t_epoch overwriting the input time/epoch? Why is s_epoch setting the output time/epoch? In addition, cs2cs is apparently not printing the modified output epoch. This is not what C function does. Here are some transformations using the input epoch in the coordinates and the --s_epoch and --t_epoch echo 40 0 0 | ./cs2cs ITRF90 ITRF2014 -d 9 40.000000788 -0.000000207 0.009684166 echo 40 0 0 foo bar | ./cs2cs ITRF90 ITRF2014 -d 9 40.000000788 -0.000000207 0.009684166 foo bar echo 40 0 0 2010 | ./cs2cs ITRF90 ITRF2014 -d 9 40.000000788 -0.000000207 0.009684166 2010 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 40.000000087 -0.000000216 -0.028724159 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --s_epoch 2000 40.000000555 -0.000000210 -0.003118609 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --s_epoch 2010 40.000000788 -0.000000207 0.009684166 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --s_epoch 2010 --t_epoch 2030 40.000000788 -0.000000207 0.009684166 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --s_epoch 2000 --t_epoch 2030 40.000000555 -0.000000210 -0.003118609 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --t_epoch 2010 40.000000788 -0.000000207 0.009684166 1980 echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014 -d 9 --t_epoch 2030 40.000001256 -0.000000201 0.035289716 1980 The pipelines for some cases are without setting --s_epoch or --t_epoch +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 +rz=-0.00026 +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010 +convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m +step +proj=axisswap +order=2,1 setting --s_epoch to 2000 +proj=pipeline +step +proj=set +v_4=2000 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 +rz=-0.00026 +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010 +convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m +step +proj=axisswap +order=2,1 +step +proj=set +v_4=2000 setting --t_epoch to 2030 +proj=pipeline +step +proj=set +v_4=2030 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 +rz=-0.00026 +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010 +convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m +step +proj=axisswap +order=2,1 +step +proj=set +v_4=2030 setting --s_epoch to 2000 and --t_epoch to 2030 +proj=pipeline +step +proj=set +v_4=2000 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 +rz=-0.00026 +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010 +convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m +step +proj=axisswap +order=2,1 +step +proj=set +v_4=2030 PS https://jjimenezshaw.github.io/wasm-proj/transform.html is in this case probably showing better the output of the C function. -------------- next part -------------- An HTML attachment was scrubbed... URL: From knudsen.thomas at gmail.com Sun Mar 15 13:08:57 2026 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Sun, 15 Mar 2026 21:08:57 +0100 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> References: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Message-ID: +1 /Thomas Den l?r. 14. mar. 2026 kl. 15.50 skrev Even Rouault via PROJ : > > Hi, > > Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj From even.rouault at spatialys.com Wed Mar 18 05:07:59 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 18 Mar 2026 13:07:59 +0100 Subject: [PROJ] Motin: adopt LLM/AI tool policy In-Reply-To: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> References: <3b639981-448a-47f7-8844-3a55a4381f89@spatialys.com> Message-ID: <0c1e4d1a-7750-4775-b01b-5dfa46c295b3@spatialys.com> Passed with +1 from PSC members JavierJS, CharlesK , KurstS, HowardB, ThomasK, AlanS and me Le 14/03/2026 ? 15:49, Even Rouault via PROJ a ?crit?: > Hi, > > Motion: adopt LLM/AI tool policy: https://github.com/OSGeo/PROJ/pull/4710 > > Starting with my +1 > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Thu Mar 19 13:31:00 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 19 Mar 2026 21:31:00 +0100 Subject: [PROJ] How to not take the direct transformation Message-ID: Hi There is a "feature" in PROJ that is sometimes inconvenient: if there is a direct transformation from A to B, it is not searching for better options. That can be really annoying in some cases, and confusing as well. Is there any way to "disable" it? something in the context? an environment variable? Example: If I transform from WGS84 to NAD83(2011) it is going to use the transformation https://epsg.org/transformation_9774/NAD83-2011-to-WGS-84-1.html, that is a no-op, with 2m accuracy. However from WGS84 to NAD83(2011)+NAVD88 it is taking a more complicated transformation for the horizontal values. That is very confusing. It happens in other situations (that of course I cannot remember now). I understand that changing the current behaviour could be to big (we can discuss if it makes sense or not), but having a way to disable that "optimization" would be great. Thank you Cheers Javier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Mar 19 13:57:00 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 19 Mar 2026 21:57:00 +0100 Subject: [PROJ] How to not take the direct transformation In-Reply-To: References: Message-ID: <450956d3-1c46-41a0-9565-b3584d1dc625@spatialys.com> No there's no such option but you could easily add one to the coordinate operation factory context and when set relax checks about res.empty() likely at https://github.com/OSGeo/PROJ/blob/8072ad6aae7a11f605c04a7068bd295404705fe0/src/iso19111/operation/coordinateoperationfactory.cpp#L4161 , https://github.com/OSGeo/PROJ/blob/8072ad6aae7a11f605c04a7068bd295404705fe0/src/iso19111/operation/coordinateoperationfactory.cpp#L4207 and https://github.com/OSGeo/PROJ/blob/8072ad6aae7a11f605c04a7068bd295404705fe0/src/iso19111/operation/coordinateoperationfactory.cpp#L4228 Le 19/03/2026 ? 21:31, Javier Jimenez Shaw via PROJ a ?crit?: > Hi > > There is a "feature" in PROJ that is sometimes inconvenient: if there > is a direct transformation from A to B, it is not searching for better > options. > > That can be really annoying in some cases, and confusing as well. > > Is there any way to "disable" it? something in the context? an > environment variable? > > Example: > If I transform from WGS84 to NAD83(2011) it is going to use the > transformation > https://epsg.org/transformation_9774/NAD83-2011-to-WGS-84-1.html, that > is a no-op, with 2m accuracy. > However from WGS84 to NAD83(2011)+NAVD88 it is taking a more > complicated transformation for the horizontal values. That is very > confusing. It happens in other situations (that of course I cannot > remember now). > > I understand that changing the current behaviour could be to big (we > can discuss if it makes sense or not), but having a way to disable > that "optimization" would be great. > > Thank you > > Cheers > Javier. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. From ben at redsnapper.net Sun Mar 22 07:32:07 2026 From: ben at redsnapper.net (Ben Griffin) Date: Sun, 22 Mar 2026 14:32:07 +0000 Subject: [PROJ] Synthetic Coordinate System Message-ID: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> I am working on a CRS of the work I?ve been doing involved a series of novel projections. (The current python module is hhg9), My current PROJ (C++) implementation shows an RTE (round-trip error) of about ~15nm - and has been extensively tested. The natural encoding of HEX9 a co-ordinate is hybrid, and involves a separation of the WGS84 ellipsoid into octants (carved at 0,90, etc). This lends itself to a 3-tuple x,y, octant_id. Therefore I am currently using PROJCRS["HEX9 Octahedral Barycentric", BASEGEOGCRS["WGS 84?, ?. ], CONVERSION["H9 Octahedral Barycentric", METHOD["PROJ h9_boct", ID["HEX9","h9_boct"]]], CS[Cartesian,3], AXIS["hex9 x (X)",east, ORDER[1], LENGTHUNIT["metre",1]], AXIS["hex9 y (Y)",north, ORDER[2], LENGTHUNIT["metre",1]], AXIS["hex9 octant (O)",unspecified, ORDER[3], SCALEUNIT["unity",1]], ID["HEX9","Oct?]] (This is the registration of the underlying continuous projection ? the octant component plays the same role as, for example, a UTM zone number. The discrete hex-cell addressing scheme of the supported DGG built on top of this CRS is not what's being registered here). The octant component is ordinal/nominal, not a third spatial axis ? there's no meaningful interpolation between octant 3 and octant 4. I'm encoding it as a 3rd Cartesian axis with orientation=unspecified and SCALEUNIT["unity",1] because OrdinalCRS isn't composable with ProjectedCRS in current PROJ. Is there a better-supported pattern for this? Is there any precedent for face-indexed projections (eg, HEALPix has the same issue ? 12 faces, each with a local Cartesian frame)? I considered using EngineeringCRS but that seems to be a mistake - it is strongly tied to WGS84, and lends itself better to DerivedGeographicCRS. So, the last axis is not strictly Z. The X, Y axes are also octant-specific and while X is ?east?, and Y is on the north/south axis, the direction of north is inverted on some octants. I will be adding ProjectedCRS to the above base - but I thought it wise to post a line to the list at this point. Thoughts/Suggestions welcome! From even.rouault at spatialys.com Sun Mar 22 09:47:06 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 22 Mar 2026 17:47:06 +0100 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> Message-ID: <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> Hi Ben, I don't think PROJ API is the best fit for DGGS implementations. Probably https://github.com/ecere/dggal would be a better host (I haven't used it myself) And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases in mind either. Even Le 22/03/2026 ? 15:32, Ben Griffin via PROJ a ?crit?: > I am working on a CRS of the work I?ve been doing involved a series of novel projections. (The current python module is hhg9), > My current PROJ (C++) implementation shows an RTE (round-trip error) of about ~15nm - and has been extensively tested. > > The natural encoding of HEX9 a co-ordinate is hybrid, and involves a separation of the WGS84 ellipsoid into octants (carved at 0,90, etc). > This lends itself to a 3-tuple x,y, octant_id. Therefore I am currently using > > PROJCRS["HEX9 Octahedral Barycentric", > BASEGEOGCRS["WGS 84?, ?. ], > CONVERSION["H9 Octahedral Barycentric", > METHOD["PROJ h9_boct", > ID["HEX9","h9_boct"]]], > CS[Cartesian,3], > AXIS["hex9 x (X)",east, > ORDER[1], > LENGTHUNIT["metre",1]], > AXIS["hex9 y (Y)",north, > ORDER[2], > LENGTHUNIT["metre",1]], > AXIS["hex9 octant (O)",unspecified, > ORDER[3], > SCALEUNIT["unity",1]], > ID["HEX9","Oct?]] > > (This is the registration of the underlying continuous projection ? the octant component plays the same role as, for example, a UTM zone number. > The discrete hex-cell addressing scheme of the supported DGG built on top of this CRS is not what's being registered here). > > The octant component is ordinal/nominal, not a third spatial axis ? there's no meaningful interpolation between octant 3 and octant 4. I'm encoding it as a 3rd Cartesian axis with orientation=unspecified and SCALEUNIT["unity",1] because OrdinalCRS isn't composable with ProjectedCRS in current PROJ. Is there a better-supported pattern for this? > Is there any precedent for face-indexed projections (eg, HEALPix has the same issue ? 12 faces, each with a local Cartesian frame)? I considered using EngineeringCRS but that seems to be a mistake - it is strongly tied to WGS84, and lends itself better to DerivedGeographicCRS. > > So, the last axis is not strictly Z. > The X, Y axes are also octant-specific and while X is ?east?, and Y is on the north/south axis, the direction of north is inverted on some octants. > > I will be adding ProjectedCRS to the above base - but I thought it wise to post a line to the list at this point. > > Thoughts/Suggestions welcome! > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. From ben at redsnapper.net Sun Mar 22 10:00:05 2026 From: ben at redsnapper.net (Ben Griffin) Date: Sun, 22 Mar 2026 17:00:05 +0000 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> Message-ID: Hi Even, Thank-you for your thoughts. As mentioned in my OP, the CRS isn?t a DGGS. It is a continuous CRS that acts as the backbone for a DGGS. Consider, please, the net projections that are run using the current system (albeit via the python module). https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/rhombus.jpg Or https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/butterfly.jpg Those are projections under the CRS declared in the OP - they are not representative of a DGGS. I?m not denying that the CRS is related to (and supports) DGGS - but it is not a DGGS. The query concerned how best to capture a global coordinate that involves an octahedral scheme - It feels like you picked up on something else. One of the aspects of this, which to me feels the most obvious, is that a CRS is continuous, while a DGGS is not. I feel that my position on this is defensible. Best regards Ben. > On 22 Mar 2026, at 16:47, Even Rouault wrote: > > Hi Ben, > I don't think PROJ API is the best fit for DGGS implementations. Probably https://github.com/ecere/dggal would be a better host (I haven't used it myself) > And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases in mind either. > > Even -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at redsnapper.net Sun Mar 22 10:07:09 2026 From: ben at redsnapper.net (Ben Griffin) Date: Sun, 22 Mar 2026 17:07:09 +0000 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> Message-ID: <0198B0FF-BB7E-4862-82B6-44DE67E2593A@redsnapper.net> Hi Even, Furthermore, we see a precedents in existing projections of Proj that are substrates of DGGS - such as HEALPix. Don?t get me wrong - I?m not averse to including DGGAL as an additional library - but Project has an edge for integration purposes, and especially for PostGIS, etc. If my project was a DGGS without a supporting CRS - then I would not be looking to Proj. Best regards Ben. > On 22 Mar 2026, at 16:47, Even Rouault wrote: > > Hi Ben, > I don't think PROJ API is the best fit for DGGS implementations. Probably https://github.com/ecere/dggal would be a better host (I haven't used it myself) > And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases in mind either. > > Even -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.desruisseaux at geomatys.com Sun Mar 22 10:01:51 2026 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Sun, 22 Mar 2026 18:01:51 +0100 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> Message-ID: <825bcd45-1126-4420-bec7-0cc14150fef4@geomatys.com> Hello Ben I confirm, ISO 19111 has not been designed for DGGS. I'm on the ISO 19111 revision group, and DGGS is still not on the radar for the next version. A better match may be ISO 19112 (referencing by identifiers). I know that some participants of OGC Testbed have explored the use of ISO 19112 for DGGS, but I don't know if there is an agreement about whether this is the way to go. ? ? Martin Le 22/03/2026 ? 17:47, Even Rouault via PROJ a ?crit?: > Hi Ben, > > I don't think PROJ API is the best fit for DGGS implementations. > Probably https://github.com/ecere/dggal would be a better host (I > haven't used it myself) > > And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases in > mind either. > > Even > From even.rouault at spatialys.com Sun Mar 22 10:10:20 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 22 Mar 2026 18:10:20 +0100 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> Message-ID: <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> ah ok I jumped too far to conclusion seeing DGGS mentionned. I read too quickly and am not familiar with HEX9. Do you plan to submit your work to PROJ upstream? I don't think it would make sense in the PROJ API to report the octant number in PROJ_COORD or in WKT, since it isn't needed to unambiguously qualify a location: just X and Y are sufficient, right ? So I don't really have a good suggestion to propose to you to be able to output the octant number. Perhaps there should be a way in the API to be able to report extra information, specific to a given projection, but that infrastructure doesn't exist. Even Le 22/03/2026 ? 18:00, Ben Griffin via PROJ a ?crit?: > Hi Even, > Thank-you for your thoughts. > > As mentioned in my OP, the CRS isn?t a DGGS. It is a continuous CRS > that acts as the backbone for a DGGS. > Consider, please, the net projections that are run using the current > system (albeit via the python module). > > https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/rhombus.jpg > > > Or > > https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/butterfly.jpg > > Those are projections under the CRS declared in the OP - they are not > representative of a DGGS. > I?m not denying that the CRS is related to (and supports) DGGS - but > it is not a DGGS. > > The query concerned how best to capture a global coordinate that > involves an octahedral scheme - It feels like you picked up on > something else. > One of the aspects of this, which to me feels the most obvious, is > that a CRS is continuous, while a DGGS is not. > > I feel that my position on this is defensible. > > Best regards > Ben. > >> On 22 Mar 2026, at 16:47, Even Rouault >> wrote: >> >> Hi Ben, >> I don't think PROJ API is the best fit for DGGS implementations. >> Probably https://github.com/ecere/dggal would be a better host (I >> haven't used it myself) >> And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases >> in mind either. >> >> Even > > > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at redsnapper.net Sun Mar 22 10:48:34 2026 From: ben at redsnapper.net (Ben Griffin) Date: Sun, 22 Mar 2026 17:48:34 +0000 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> Message-ID: > ah ok I jumped too far to conclusion seeing DGGS mentioned. I read too quickly and am not familiar with HEX9. :-) It?s a rite of passage for me with this work. I need to write it on my forehead, I guess. > Do you plan to submit your work to PROJ upstream? > If there is interest, then yes - definitely. I personally believe that the system has a lot to offer; like any projection, it?s not a universal solution - but it certainly offers benefits for those who are looking at developing well-defined binning strategies that rest upon strong mathematical foundations. > I don't think it would make sense in the PROJ API to report the octant number in PROJ_COORD or in WKT, since it isn't needed to unambiguously qualify a location: just X and Y are sufficient, right ? > There are two major approaches here - the underlying structure is the unit octahedron - the fundamental CRS converts WGS<->Unit Octahedron with high fidelity. However, the way in which we visualise is mainly on the 2D plane, so then each side / octant of the Unit Octahedron must be rotated onto the 2D plane - and then (via rigid transforms) placed with the other sides into a net or similar map. The projection engine itself works directly from the WGS longitude/latitude to the 2D plane - but each face of the octahedron is centred on the origin. Therefore, there is an ambiguity arising as to which face is being looked at without some means of octant identity. One may further suggest that I nominate a 2D projection (like the ?butterfly? projection linked to earlier) - but then that adds a discontinuity on the edges of the map which are not ?felt? in the 3D representation. I can project the 2D+octant back down to the 3D xyz octahedral surface - but the approach is adding the matrix transform just for the sake of data storage / WKT declaration - as it is the 2D projection derivatives that are of interest. Again, the challenge with 3D is that there could be a presumption that the underlying shape is ellipsoidal - where it is not - although it is (currently) strongly dependent upon WGS 84 (both via the analytic calculations and the warp matrix). Therefore, it feels better and more suitable to go for an [X,Y, Octant] scheme. Anyway - my post was me wondering aloud if the approach (X, Y, Octant) is considered reasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef at norbit.de Mon Mar 23 01:57:58 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Mon, 23 Mar 2026 09:57:58 +0100 Subject: [PROJ] cdn.proj.org stats? Message-ID: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> Hi, QGIS currently ships full proj-data with the windows msi installers and that's a good part of the installer. We're trying to reduce that and therefore I'm now looking (again) into which grids could be separated. I suppose "Access logs to this resource are permanently deleted after one day, are not mirrored or stored, and are not publicly available. If this policy is not sufficient, users are encourage to mirror a local copy of the grid files and access them directly." means that there is no stats that could help with this - ie. identifying huge grids that are never used (eg. maybe de_lgl_bw_BWTA2017.tif) J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany Matrix: @jef:osgeo.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From michael.smith.erdc at gmail.com Mon Mar 23 02:56:49 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Mon, 23 Mar 2026 05:56:49 -0400 Subject: [PROJ] cdn.proj.org stats? In-Reply-To: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> References: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> Message-ID: <8F3935ED-C6C4-460B-8786-A0C8A5445B42@gmail.com> Could you distribute 2 bundles? 1. Full proj grid data 2. No proj grid data and PROJ_NETWORK=on to fetch over http Then you'd have an offline/online versions of QGIS. Another option would be just an QGIS installer around the PROJ grid bundles that would install for qgis. -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps ?On 3/23/26, 4:58 AM, "PROJ on behalf of J?rgen E. Fischer via PROJ" on behalf of proj at lists.osgeo.org > wrote: Hi, QGIS currently ships full proj-data with the windows msi installers and that's a good part of the installer. We're trying to reduce that and therefore I'm now looking (again) into which grids could be separated. I suppose "Access logs to this resource are permanently deleted after one day, are not mirrored or stored, and are not publicly available. If this policy is not sufficient, users are encourage to mirror a local copy of the grid files and access them directly." means that there is no stats that could help with this - ie. identifying huge grids that are never used (eg. maybe de_lgl_bw_BWTA2017.tif) J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany Matrix: @jef:osgeo.org _______________________________________________ PROJ mailing list PROJ at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj From howard at hobu.co Mon Mar 23 06:08:07 2026 From: howard at hobu.co (Howard Butler) Date: Mon, 23 Mar 2026 08:08:07 -0500 Subject: [PROJ] cdn.proj.org stats? In-Reply-To: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> References: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> Message-ID: <0EFDEE32-F98F-4FB9-BFC0-38CB3910D807@hobu.co> > On Mar 23, 2026, at 3:57?AM, J?rgen E. Fischer via PROJ wrote: > > Hi, > > QGIS currently ships full proj-data with the windows msi installers and that's > a good part of the installer. We're trying to reduce that and therefore I'm > now looking (again) into which grids could be separated. > > I suppose > > "Access logs to this resource are permanently deleted after one day, are not > mirrored or stored, and are not publicly available. If this policy is not > sufficient, users are encourage to mirror a local copy of the grid files and > access them directly." > > means that there is no stats that could help with this - ie. identifying huge > grids that are never used (eg. maybe de_lgl_bw_BWTA2017.tif) No. The alternative is answering questions like "why are you spying on me by storing logs of spatial queries from my desktop application?" My retort to the question is asking why doesn't *QGIS* have these statistics :) Some options I see: * Keep distributing a fat installer * Distribute a thin installer that takes in user input during the installation and syncs grids based on it. https://proj.org/en/stable/apps/projsync.html has --bbox and --area-of-use and --exclude-world-coverage options which the installer could use to restrict that initial caching * Only distribute a thin installer and projsync grids as they are used on first access * Provide a "Sync all geodetic support data" option buried in the settings and distribute with only global grid files. The size of these grids have always been a problem. The purpose of the CDN is to provide a gradient that makes it convenient to do the most accurate thing in most cases. I think it has been quite successful in that regard. Howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef at norbit.de Mon Mar 23 06:11:44 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Mon, 23 Mar 2026 14:11:44 +0100 Subject: [PROJ] cdn.proj.org stats? In-Reply-To: <0EFDEE32-F98F-4FB9-BFC0-38CB3910D807@hobu.co> References: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> <0EFDEE32-F98F-4FB9-BFC0-38CB3910D807@hobu.co> Message-ID: <20260323131143.qb64kxzdss4cgbe3@norbit.de> Hi Howard, On Mon, 23. Mar 2026 at 08:08:07 -0500, Howard Butler wrote: > > "Access logs to this resource are permanently deleted after one day, are not > > mirrored or stored, and are not publicly available. If this policy is not > > sufficient, users are encourage to mirror a local copy of the grid files and > > access them directly." > > means that there is no stats that could help with this - ie. identifying huge > > grids that are never used (eg. maybe de_lgl_bw_BWTA2017.tif) > > No. Thanks ;) J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany Matrix: @jef:osgeo.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Pflichtangaben URL: From jef at norbit.de Mon Mar 23 10:28:29 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Mon, 23 Mar 2026 18:28:29 +0100 Subject: [PROJ] cdn.proj.org stats? In-Reply-To: <0EFDEE32-F98F-4FB9-BFC0-38CB3910D807@hobu.co> References: <20260323085758.tjeo4uf2vdvnnbyv@norbit.de> <0EFDEE32-F98F-4FB9-BFC0-38CB3910D807@hobu.co> Message-ID: <20260323172829.5qscdssxjdnbbrwt@norbit.de> Hi Howard, On Mon, 23. Mar 2026 at 08:08:07 -0500, Howard Butler wrote: > > means that there is no stats that could help with this - ie. identifying huge > > grids that are never used (eg. maybe de_lgl_bw_BWTA2017.tif) > No. The alternative is answering questions like "why are you spying on me by > storing logs of spatial queries from my desktop application?" My retort to > the question is asking why doesn't *QGIS* have these statistics :) As you said this is not a new issue - and the named options are clear, but kind of circumvent the point of the standalone installer. It should be self contained. So the only better idea that I had is to exclude hardly used grids. But it there's no data that might tells use which those could be, that's also not an option. Currently the user is just pointed at the cdn to download a grid if it's missing. But we won't have a backchannel to track that either - and won't do any for the same reasons (we just evaluate which clients fetch the qgis update info to do analytics.qgis.org). It's probably the best bet, as it would fetch a grid that the user actually needs instead of of fetching all the grids at the user's location, that he might not need at all (eg. grids for legacy crses that are hardly used nowadays) or not even work in. But there still might be environments where downloads aren't possible at all. But yes, maybe a thin and a fat installer are the best option. J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany Matrix: @jef:osgeo.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Pflichtangaben URL: From ben at redsnapper.net Mon Mar 23 13:21:39 2026 From: ben at redsnapper.net (Ben Griffin) Date: Mon, 23 Mar 2026 20:21:39 +0000 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> Message-ID: I am honoured to have met both of you, Even, Martin - and I really do value your respective thoughts; I have invested quite a bit of research time and work I?ve put into this project so far, and your opinions are really valuable. Martin, your points on ISO 19111/19112 are really well made. As I understand it - and I am happy to be corrected, it appears that you are confirming that there is not (yet) an agreed standard as to what a DGGS should be in ISO terms. However, I feel that ISO 19112 (referencing by identifiers ? "what cell am I in?") is a natural home for the DGGS addressing layer: given a location, return an identifier: That's the H9 address, the H3 index, the S2 cell ID? and it's a different question from "what are the coordinates of this location in the Hex9 projection?? ? which is unambiguously ISO 19111 territory. My work - Hex9 - straddles both standards cleanly: - The projection (continuous CRS) ? ISO 19111 - The addressing system (H9 cell hierarchy) ? ISO 19112 It seems that most DGGS systems have historically conflated these two things. When I designed Hex9, it became clear that they are better refactored into genuinely separate layers which, while being architecturally unusual, feels arguably correct. (I chose to design the system so that the cell hierarchy is a consumer of the projection rather than intrinsic to it. This, I feel, was a design decision with consequences: Any hierarchical resolution can sit on top of the same CRS without changing the projection. The PROJ plugin I am currently working on would implement the ISO 19111 layer. The Python hhg9 package, and/or additional software libraries would implement the ISO 19112 layer on top of it. Hex9 is truly continuous (although both the python and the PROJ C++ implementation hit machine epsilon limits). The PROJ implementation achieves sub-25nm round-trip geodesic accuracy in current testing ? the continuous nature of the CRS is not just theoretical. There is an additional question worth addressing directly: the CRS is octahedral, and the coordinate geometry is inherently triangular. The hexagonal cell structure arises as a precise consequence of that triangulation ? it is not imposed on the projection but derived from it. I will admit that in my own earlier documentation I conflated the projection geometry with the cell addressing, which likely contributed to the DGGS framing. That conflation was mine to make, not the architecture's ? and separating them clearly is part of what this PROJ submission is intended to establish. Kind regards. -Ben. From ben at redsnapper.net Mon Mar 23 13:21:39 2026 From: ben at redsnapper.net (Ben Griffin) Date: Mon, 23 Mar 2026 20:21:39 +0000 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> Message-ID: I am honoured to have met both of you, Even, Martin - and I really do value your respective thoughts; I have invested quite a bit of research time and work I?ve put into this project so far, and your opinions are really valuable. Martin, your points on ISO 19111/19112 are really well made. As I understand it - and I am happy to be corrected, it appears that you are confirming that there is not (yet) an agreed standard as to what a DGGS should be in ISO terms. However, I feel that ISO 19112 (referencing by identifiers ? "what cell am I in?") is a natural home for the DGGS addressing layer: given a location, return an identifier: That's the H9 address, the H3 index, the S2 cell ID? and it's a different question from "what are the coordinates of this location in the Hex9 projection?? ? which is unambiguously ISO 19111 territory. My work - Hex9 - straddles both standards cleanly: - The projection (continuous CRS) ? ISO 19111 - The addressing system (H9 cell hierarchy) ? ISO 19112 It seems that most DGGS systems have historically conflated these two things. When I designed Hex9, it became clear that they are better refactored into genuinely separate layers which, while being architecturally unusual, feels arguably correct. (I chose to design the system so that the cell hierarchy is a consumer of the projection rather than intrinsic to it. This, I feel, was a design decision with consequences: Any hierarchical resolution can sit on top of the same CRS without changing the projection. The PROJ plugin I am currently working on would implement the ISO 19111 layer. The Python hhg9 package, and/or additional software libraries would implement the ISO 19112 layer on top of it. Hex9 is truly continuous (although both the python and the PROJ C++ implementation hit machine epsilon limits). The PROJ implementation achieves sub-25nm round-trip geodesic accuracy in current testing ? the continuous nature of the CRS is not just theoretical. There is an additional question worth addressing directly: the CRS is octahedral, and the coordinate geometry is inherently triangular. The hexagonal cell structure arises as a precise consequence of that triangulation ? it is not imposed on the projection but derived from it. I will admit that in my own earlier documentation I conflated the projection geometry with the cell addressing, which likely contributed to the DGGS framing. That conflation was mine to make, not the architecture's ? and separating them clearly is part of what this PROJ submission is intended to establish. Kind regards. -Ben. From j1 at jimenezshaw.com Mon Mar 23 14:48:56 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 23 Mar 2026 22:48:56 +0100 Subject: [PROJ] Synthetic Coordinate System In-Reply-To: References: <5D9C48FF-D1D4-4ADD-A04F-E78C6A87515C@redsnapper.net> <0da5f107-64c1-422b-b84a-8d4a89eab97c@spatialys.com> <5af7706b-165f-481b-8807-a402b6446aae@spatialys.com> Message-ID: Hi Ben I think I see your point. I have been recently developing some code related to GBT and DGGS. What I do not completely understand is how the face is part of the projection, specially in PROJ. Yes, it can be easier to implement. However all the other polyhedral projections in PROJ are doing the forward and inverse transformation without relying on that information. I think the projection in PROJ should be like the other ones, taking lat and lon, and return x and y (and viceversa). Deciding on with face is the point and what to do with it is a task for the algorithm on top of it. Cheers, Javier On Mon, 23 Mar 2026 at 21:22, Ben Griffin via PROJ wrote: > I am honoured to have met both of you, Even, Martin - and I really do > value your respective thoughts; > I have invested quite a bit of research time and work I?ve put into this > project so far, and your opinions are really valuable. > > Martin, your points on ISO 19111/19112 are really well made. > > As I understand it - and I am happy to be corrected, it appears that you > are confirming that there is not (yet) an > agreed standard as to what a DGGS should be in ISO terms. > > However, I feel that ISO 19112 (referencing by identifiers ? "what cell am > I in?") is a natural home for the DGGS addressing layer: given a location, > return an > identifier: That's the H9 address, the H3 index, the S2 cell ID? and it's > a different question from "what are the coordinates of this location in the > Hex9 projection?? > ? which is unambiguously ISO 19111 territory. > > My work - Hex9 - straddles both standards cleanly: > - The projection (continuous CRS) ? ISO 19111 > - The addressing system (H9 cell hierarchy) ? ISO 19112 > > It seems that most DGGS systems have historically conflated these two > things. > > When I designed Hex9, it became clear that they are better refactored into > genuinely separate layers which, while being architecturally unusual, feels > arguably correct. (I chose to design the system so that the cell hierarchy > is a consumer of the projection rather than intrinsic to it. This, I feel, > was a design decision with consequences: Any hierarchical resolution can > sit on top of the same CRS without changing the projection. > > The PROJ plugin I am currently working on would implement the ISO 19111 > layer. > The Python hhg9 package, and/or additional software libraries would > implement the ISO 19112 layer on top of it. > > Hex9 is truly continuous (although both the python and the PROJ C++ > implementation hit machine epsilon limits). The PROJ implementation > achieves sub-25nm round-trip geodesic accuracy in current testing ? the > continuous nature of the CRS is not just theoretical. > > There is an additional question worth addressing directly: the CRS is > octahedral, and the coordinate geometry is inherently triangular. The > hexagonal cell structure arises as a precise consequence of that > triangulation ? it is not imposed on the projection but derived from it. I > will admit that in my own earlier documentation I conflated the projection > geometry with the cell addressing, which likely contributed to the DGGS > framing. That conflation was mine to make, not the architecture's ? and > separating them clearly is part of what this PROJ submission is intended to > establish. > > Kind regards. > -Ben. > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: