From mmogilvi4711+proj at gmail.com Tue Jun 2 16:58:20 2026 From: mmogilvi4711+proj at gmail.com (Matthew Ogilvie) Date: Tue, 2 Jun 2026 17:58:20 -0600 Subject: [PROJ] proj4 compatibilty and angular units questions In-Reply-To: References: Message-ID: On Thu, May 21, 2026 at 09:53:39AM -0600, Matthew Ogilvie wrote: > PRIMARY QUESTION: Given a previously imported/converted image file > with a proj4 string from GDAL ca. version 2.3.1 or earlier > embedded in it, what is the "best" way to create an appropriately > compatible transformation object with new PROJ versions like 9.8.1? In the absense of any responses, I'm tentatively using (roughly) the following code snippet. Maybe someone will alert me if anything seems non-ideal in it, or if good, maybe it could be an example to help anyone else with similar questions. ========= CUT =========== PJ *wgs84=proj_create(ctx,"EPSG:4326"); wgs84=proj_normalize_for_visualization(ctx,wgs84); wgs84=proj_crs_alter_cs_angular_units(ctx,wgs84,"radian",1.0,NULL,NULL); //////// PG *newCrs; if(oldProj4) { /* Adapted from pj_add_type_crs_if_needed() internally used * by proj_create_crs_to_crs() only (not other forms of creation). */ std::string adjStr=proj4String; if( ( starts_with(adjStr, "proj=") || starts_with(adjStr, "+proj=") || starts_with(adjStr, "+init=") || starts_with(adjStr, "+title=") ) && adjStr.find("type=crs") == std::string::npos ) { adjStr.append(" +type=crs"); } newCrs = proj_create(ctx,adjStr.c_str()); PJ_TYPE pjType=proj_get_type(newCrs); if( pjType==PJ_TYPE_GEOGRAPHIC_2D_CRS || pjType==PJ_TYPE_GEOGRAPHIC_3D_CRS ) { newCrs = proj_crs_alter_cs_angular_unit(ctx,newCrs, "radian",1.0,NULL,NULL ); } } else // new WKT { newCrs = proj_create(ctx,wktString); } newCrs = proj_normalize_for_visualization(ctx,newCrs); //////// PJ *transform; transform = proj_create_crs_to_crs_from_pj(ctx,wgs84,newCrs,NULL,NULL); // Then just use that final "transform"... ========= CUT =========== Notes: - Obviously the snippet above is leaving out a lot of error checking, memory leak cleanup, and other tangential details. (Real code has those...) - Most piecemeal construction / tweaking of a transform apparently requires actual CRS's, which needs the " +type=crs" appended to the proj4 string, or else later CRS-dependent steps fail. 1. Except for plain proj_create_crs_to_crs(), which does that for you. Perhaps this could be clarified in the documentation? 2. MINOR CONCERN: As mentioned in my original email, I don't think this is very robust (I don't think it works with pipelines, etc), but it is probably good enough for my purposes here. - CONCERN: Are there more PJ_TYPE's I need to worry about? - I notice that GDAL's OGRSpatialReference::IsGeographic() may also do a bunch more stuff for "bound CRS"s that I don't really understand. - FYI: If I unconditionally do newCrs's proj_crs_alter_cs_angular_unit() adjustment and print out the proj4String and WKT representations of the final resulting transform, it looks like non-geopraphic newCrs's will create transforms that involve extra steps that aren't optimized properly. (As near as I can tell.) - The documentation mentions that finding the best CRS to CRS transform sometimes involves looking up special cases in the proj database file. - https://proj.org/en/stable/operations/operations_computation.html - CONCERN: Could customizing axes (order, units) mess this up in some cases when it does such lookups in the final proj_crs_to_crs_with_pj() call? - ALTERNATIVE: In most (all?) cases it might work to just use "transform = proj_create(proj4String);" directly (no explicit crs_to_crs at all). - CONCERN: Could this ever result in a different transform? Lack of datum conversions, etc? If different, how should I decide which would be better? - Future CONCERN: One of the archived emails I linked to from my first email mentioned the idea of changing this to work in degrees as well? - FYI: My original email mentions these concerns and others in more detail. - FYI: My original email also has a section about what looks like documentation bugs / typos someone may want to fix... --------- Matthew Ogilvie --------- From Jochem.Lesparre at kadaster.nl Mon Jun 8 12:54:28 2026 From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem) Date: Mon, 8 Jun 2026 19:54:28 +0000 Subject: [PROJ] Setting the GEOIDMODEL in the CRS short id In-Reply-To: References: Message-ID: > This explains why the Danish height system DVR90 is now in EPSG as a datum ensemble I'm not sure of the Danish situation, but for the Netherlands the only official realisation of the height system is the levelling benchmarks. The geoid provides only an approximate transformation. Making it two different CRSs is an interesting tweak, but I'm afraid it would only create more confusion. 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]. From gdt at lexort.com Mon Jun 8 14:04:24 2026 From: gdt at lexort.com (Greg Troxel) Date: Mon, 08 Jun 2026 17:04:24 -0400 Subject: [PROJ] Setting the GEOIDMODEL in the CRS short id In-Reply-To: (Jochem Lesparre's message of "Mon, 8 Jun 2026 19:54:28 +0000") References: Message-ID: "Lesparre, Jochem" writes: >> This explains why the Danish height system DVR90 is now in EPSG as a datum ensemble > > I'm not sure of the Danish situation, but for the Netherlands the only > official realisation of the height system is the levelling > benchmarks. The geoid provides only an approximate > transformation. Making it two different CRSs is an interesting tweak, > but I'm afraid it would only create more confusion. I think the the Netherlands situation is the same as the US (different orthometric height definitions, different underlying datum for HAE, different geoid models of course, but structurally the same). In both NL and US cases, I think it is incorrect to add a CRS for [orthometric height estimated from HAE and GEOID X]. (I believe, after off-list conversations with Kristian and trying to read a report in Danish, that in Denmark, there really are additional height system realizations.) From j1 at jimenezshaw.com Tue Jun 9 08:06:46 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 9 Jun 2026 17:06:46 +0200 Subject: [PROJ] Setting the GEOIDMODEL in the CRS short id In-Reply-To: References: Message-ID: I see what you all mean. But surveyors are all the time asking "where do I specify the geoid model". Actually many people only know the geoid model, and they have not idea that the is a vertical CRS. (Probably because there is only one. Like the (small) countires with just one projection, that they don't make a clear difference between the geographic and the projected system) On Mon, 8 Jun 2026 at 23:04, Greg Troxel via PROJ wrote: > "Lesparre, Jochem" writes: > > >> This explains why the Danish height system DVR90 is now in EPSG as a > datum ensemble > > > > I'm not sure of the Danish situation, but for the Netherlands the only > > official realisation of the height system is the levelling > > benchmarks. The geoid provides only an approximate > > transformation. Making it two different CRSs is an interesting tweak, > > but I'm afraid it would only create more confusion. > > I think the the Netherlands situation is the same as the US (different > orthometric height definitions, different underlying datum for HAE, > different geoid models of course, but structurally the same). In both > NL and US cases, I think it is incorrect to add a CRS for [orthometric > height estimated from HAE and GEOID X]. > > (I believe, after off-list conversations with Kristian and trying to > read a report in Danish, that in Denmark, there really are additional > height system realizations.) > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Jun 10 07:36:07 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 10 Jun 2026 10:36:07 -0400 Subject: [PROJ] Setting the GEOIDMODEL in the CRS short id In-Reply-To: (Javier Jimenez Shaw's message of "Tue, 9 Jun 2026 17:06:46 +0200") References: Message-ID: Javier Jimenez Shaw writes: > I see what you all mean. But surveyors are all the time asking "where do I > specify the geoid model". Actually many people only know the geoid model, > and they have not idea that the is a vertical CRS. I really don't know how to deal with that. I don't think proj should do something that isn't technically justifiable to make people that don't really understand think things are ok. I think that leaves us as "that's metadata about how you obtained heights in that vertical CRS, sort of in the same category as which RTN you used". I would think that if surveyors are using HAE and geoid models to obtain orthometric heights, they really need to understand that, and the accuracy issues vs leveled heights from passive controls. I would think that either the RPLS exam and continuing education requirements would ensure this, or they shouldn't be using HAE and geoid models. But IANARPLS :-) From even.rouault at spatialys.com Sun Jun 21 09:14:20 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 21 Jun 2026 18:14:20 +0200 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? Message-ID: Hi, I was reading https://lists.osgeo.org/pipermail/qgis-user/2026-June/056346.html where Greg mentions "Also use command-line proj:? $ projinfo -s ETRF2000 -t ETRF2020?which returns a lot of operations that surprise me, being time-dependent?transforms with non-zero rates". Indeed PROJ does that transformation using a ITRF2020 pivot, which is in line with the EUREF technical note 1 (http://etrs89.ensg.ign.fr/pub/EUREF-TN-1-Mar-04-2024.pdf). But the consequence of using such time-dependent transforms is that the results depends *and change* on a coordinate epoch.? So ETRFxx frames are not "static" ? From a number of things seen in past years, it looks to me that this opposition of static vs dynamic frames is still very fuzzy and perhaps is not relevant at all. On the US side their recent renaming of NATRF2022 to NATRF2022e2020 (epoch 2020.0) also shows similar confusion. $ echo 49 2 0 2000 | bin/cs2cs -d 8 ETRF2000 ETRF2020 49.00000061? ? 1.99999942 0.00346292 2000 $ echo 49 2 0 2015 | bin/cs2cs -d 8 ETRF2000 ETRF2020 49.00000065? ? 1.99999955 0.01117636 2015 $ echo 49 2 0 2020 | bin/cs2cs -d 8 ETRF2000 ETRF2020 49.00000067? ? 1.99999960 0.01374751 2020 The good news is that while playing with the online? ETRF/ITRF Coordinate Transformation Tool (ECTT)? tool (https://epncb.oma.be/_productsservices/coord_trans/index.php#results), both this tool and PROJ agree at the tenth of millimeter on a few random points I tried, and when checking the " show intermediate steps" tick box, one can also see they use a ITRF2020 intermediate (actually they do ETRF2000 -> ITRF2000 -> ITRF2020 -> ETRF2020 at the specified epoch.? But the?ETRF2000 ->?ITRF2020 direct transformation we have in PROJ must be the compaction of?ITRF2000 -> ITRF2000 -> ITRF2020) /me still not having any clue at geodesy ;-) Even -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot From even.rouault at spatialys.com Sun Jun 21 12:33:23 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 21 Jun 2026 21:33:23 +0200 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? In-Reply-To: References: Message-ID: Xavier, (re-adding the list) Thanks for the hint. I should have looked more closely at the WKT definition which does indicate the dynamic nature with frameepoch 1989 (and NATRF2022e2020 is a different beast with an *anchor epoch* of 2020) Even Le 21/06/2026 ? 21:27, Xavier Collilieux a ?crit?: > Dear colleagues, > > Yes, I confirm that ETRFxx are dynamic frames. Indeed, they are derived from ITRFxx by applying a 14-parameter transformation. As ITRFxx are dynamic, ETRFxx also are. > > Best regards, > > Xavier > > -----Message d'origine----- > De?: PROJ De la part de Even Rouault via PROJ > Envoy??: dimanche 21 juin 2026 18:14 > ??: proj > Objet?: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? > > Hi, > > I was reading > https://lists.osgeo.org/pipermail/qgis-user/2026-June/056346.html where Greg mentions "Also use command-line proj:? $ projinfo -s ETRF2000 -t > ETRF2020?which returns a lot of operations that surprise me, being time-dependent?transforms with non-zero rates". > > Indeed PROJ does that transformation using a ITRF2020 pivot, which is in line with the EUREF technical note 1 (http://etrs89.ensg.ign.fr/pub/EUREF-TN-1-Mar-04-2024.pdf). But the consequence of using such time-dependent transforms is that the results depends *and change* on a coordinate epoch.? So ETRFxx frames are not "static" ? From a number of things seen in past years, it looks to me that this opposition of static vs dynamic frames is still very fuzzy and perhaps is not relevant at all. On the US side their recent renaming of > NATRF2022 to NATRF2022e2020 (epoch 2020.0) also shows similar confusion. > > $ echo 49 2 0 2000 | bin/cs2cs -d 8 ETRF2000 ETRF2020 > 49.00000061? ? 1.99999942 0.00346292 2000 $ echo 49 2 0 2015 | bin/cs2cs -d 8 ETRF2000 ETRF2020 > 49.00000065? ? 1.99999955 0.01117636 2015 $ echo 49 2 0 2020 | bin/cs2cs -d 8 ETRF2000 ETRF2020 > 49.00000067? ? 1.99999960 0.01374751 2020 > > The good news is that while playing with the online? ETRF/ITRF Coordinate Transformation Tool (ECTT)? tool (https://epncb.oma.be/_productsservices/coord_trans/index.php#results), > both this tool and PROJ agree at the tenth of millimeter on a few random points I tried, and when checking the " show intermediate steps" tick box, one can also see they use a ITRF2020 intermediate (actually they do > ETRF2000 -> ITRF2000 -> ITRF2020 -> ETRF2020 at the specified epoch. But the?ETRF2000 ->?ITRF2020 direct transformation we have in PROJ must be the compaction of?ITRF2000 -> ITRF2000 -> ITRF2020) > > /me still not having any clue at geodesy ;-) > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > LLMs contribute to global warming and brain rot > > _______________________________________________ > 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. LLMs contribute to global warming and brain rot From gdt at lexort.com Sun Jun 21 12:41:13 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 21 Jun 2026 15:41:13 -0400 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? In-Reply-To: (Even Rouault via PROJ's message of "Sun, 21 Jun 2026 18:14:20 +0200") References: Message-ID: Even Rouault via PROJ writes: > I was reading > https://lists.osgeo.org/pipermail/qgis-user/2026-June/056346.html > where Greg mentions "Also use command-line proj:? $ projinfo -s > ETRF2000 -t ETRF2020?which returns a lot of operations that surprise > me, being time-dependent?transforms with non-zero rates". > > Indeed PROJ does that transformation using a ITRF2020 pivot, which is > in line with the EUREF technical note 1 > (http://etrs89.ensg.ign.fr/pub/EUREF-TN-1-Mar-04-2024.pdf). But the > consequence of using such time-dependent transforms is that the > results depends *and change* on a coordinate epoch.? So ETRFxx frames > are not "static" ? From a number of things seen in past years, it > looks to me that this opposition of static vs dynamic frames is still > very fuzzy and perhaps is not relevant at all. I think we're suffering from increased measurement accuracy. As I understand it, a static datum is one where stations (of stable physical monuments) have coordinates and do not have velocities. This is a definitional choice rather than a physical reality. Traditional plate-fixed datums (NAD27, original NAD83, probably ED50) are like this. A dynamic datum is where the datum definition assigns both coordinates and velocities to monumented stations. It seems the velocities can be per station, or there can be a plate motion model. NAD83(2011) is defined in terms of ITRF and a rotation, intending to make it plate fixed. But it's not quite, we now know, super roughly 2 mm/y station velocities vs 20 mm/y velocities in ITRF. Thus, static carrier phase solutions and RTNs operate in "epoch 2010.0" which is truly static because it is defined that way. As I understand ETRS89 (a system not a datum?), there is similarly a defined rotation from ITRF. One then has two choices: - 1) say that the coordinates will evolve with some no net motion constraint over all of Eurasia - 2) say that the system is forever that rotation from ITRF and I believe it is 2 that was chosen (but I am fuzzy on ETRS). Thus, ETRFnnnn are not truly static, they are close-to-static, and I think this is in exactly the same sense as NAD83(2011) is close-to-static (but perhaps with a lower velocity). Unlike NAD83(2011), there are multiple and continuing ETRF realizations, and ETRS/ETRF* is conceptually much more like NATRF2022 than NAD83(2011). I find it surprising (that's a comment about me, not EU choices!) and interesting that official guidance goes through ITRF. There's a big question of whether time transformation of ITRF coordinates is according to a plate motion model, implying that a monument is being transformed, vs a more abstract coordinate location not fixed -- and that's where I start feeling unclear. > On the US side their recent renaming of NATRF2022 to NATRF2022e2020 > (epoch 2020.0) also shows similar confusion. I just looked at https://beta.ngs.noaa.gov/NATRF2022/ and don't see this mentioned. NATRF2022 includes an "intra-frame velocity model", which more or less is "stations have coordindates at the epoch and a velocity", except that there are individual station velocities; this is especially important in deformation zones between the NA and PA plates where it's messy and can't be modeled by a rotation. I am not aware of this part of the "new datums" changing. While geodesists and researchers want the full complexity, surveyors and highway departments don't. They want a static datum that covers their area of work. NAD83(2011) epoch 2010.0 served that need (and still does), and I think NATRF2022e2020 is exactly the same concept: an RTN might operate so that users get the epoch 2020.0 coordinates. I would thus consider this CRS a static datum, even though that's a little funny in terms of definitions. As an example, if I go to a passive control and use an RTN in NAD83(2011) epoch 2010.0 for each of January 1-5, 2020 and record points, and do it again in January 1-5, 2026, I expect all 10 points to cluster and show no drift from the 1st 5 to the 2nd 5. With EPSG:6319, it's ambiguous if it means the dynamic datum NAD83(2011) or the static datum NAD83(2011) epoch 2010.0. My take is that 99.9% of actual uses of the codepoint mean the static/2010.0 version. It's amazing how good low-cost equipment (ublox F9P, Mosaic X5) with a decent ($100ish) antenna is, with a professsonal RTN. A friend measured a passive control something like 4 times over 2 days, and I plotted the 4 values and those from an OPUS solution produced by a professional surveyor with MassDOT. I visualized these in qgis and zoomed in. Of course, any distribution looks like it is 2/3 the screen width! The human can note the scale and be careful, but it's hard to perceive. My friend then plotted the coordinates on metric graph paper (which nerds in the US can get :-) at 1:1 scale. It was trimmed to about 2cm by 2 cm and the cluster was mostly about 1 cm in diameter. This was a completely different impression than looking at the screen; errors that seemed, well, 2/3 of the screen, were seen to be thumb sized. I think this is a large part of why the larger community is considering more and more frames to be dynamic, because 2 mm/y * 10 years is easily 2 standard deviations for the measurement error, and would be the dominant error if not corrected. > The good news is that while playing with the online? ETRF/ITRF > Coordinate Transformation Tool (ECTT)? tool > (https://epncb.oma.be/_productsservices/coord_trans/index.php#results), > both this tool and PROJ agree at the tenth of millimeter on a few > random points I tried, and when checking the " show intermediate > steps" tick box, one can also see they use a ITRF2020 intermediate > (actually they do ETRF2000 -> ITRF2000 -> ITRF2020 -> ETRF2020 at the > specified epoch. That's great things are so close! This week, I see 0.1 mm as totally acceptable rounding/etc. error. 1 mm is probably actually ok but socially unacceptable and 1 cm is IMHO a real problem. > But the?ETRF2000 ->?ITRF2020 direct transformation we have in PROJ > must be the compaction of?ITRF2000 -> ITRF2000 -> ITRF2020) Interesting; ever more things to understand.... From even.rouault at spatialys.com Sun Jun 21 14:07:28 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 21 Jun 2026 23:07:28 +0200 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: References: Message-ID: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", I see it is a noop transformation, so with no time dependency...? How does that fit with the fact that ETRF2000 is dynamic. I see that "ETRS89-NLD [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when applying?"ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate epoch 2010.5, right?? ?Shouldn't the PROJ pipeline +proj=set +v_4=2010.5 ? Same question for ETRS89-FRA [RGF93 v2] to ETRF2000 (1) and ETRS89-FRA [RGF93 v2b] to ETRF2000 (1) with are both no-ops. Shouln't output coordinate epochs be respectively 2009 and 2019 per their anchor epoch ? -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot From j1 at jimenezshaw.com Sun Jun 21 14:17:13 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sun, 21 Jun 2026 23:17:13 +0200 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: Even, you are opening a can of worms? epochs. I want to see what comes out of this ;P (if any) On Sun, 21 Jun 2026, 23:07 Even Rouault via PROJ, wrote: > Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", I > see it is a noop transformation, so with no time dependency... How does > that fit with the fact that ETRF2000 is dynamic. I see that "ETRS89-NLD > [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has > ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when > applying "ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate epoch > 2010.5, right? Shouldn't the PROJ pipeline +proj=set +v_4=2010.5 ? > > Same question for ETRS89-FRA [RGF93 v2] to ETRF2000 (1) and ETRS89-FRA > [RGF93 v2b] to ETRF2000 (1) with are both no-ops. Shouln't output > coordinate epochs be respectively 2009 and 2019 per their anchor epoch ? > > -- > http://www.spatialys.com > My software is free, but my time generally not. > LLMs contribute to global warming and brain rot > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sun Jun 21 14:43:05 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 21 Jun 2026 17:43:05 -0400 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> (Even Rouault via PROJ's message of "Sun, 21 Jun 2026 23:07:28 +0200") References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: Is "anchor epoch" a new term, or an EPSG term? I think I know what you mean, and I'm probably off, but it seems new to me. Formally, I feel like coordinates in a dynamic datum that do not carry an epoch are improper, but that dynamic datums specify a default epoch, so that when coordinates without a date are given, one can assume that epoch. Anchor epoch could be that. Then, transforms could be given with 7 parameters assuming a particular input datum epoch, and anther 7 as rates. Theoretically that epoch could be different from the default epoch of the frame. I bet it ~never is, because that would be even more confusing for no good reason. Is "ANCHOREPOCH" just the EPSG term for "this is the epoch assumed if you don't give a time for a set of coordinates", or is there more? Even Rouault via PROJ writes: > Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", > I see it is a noop transformation, so with no time dependency...? How > does that fit with the fact that ETRF2000 is dynamic. I see that > "ETRS89-NLD [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has > ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when > applying?"ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate > epoch 2010.5, right?? ?Shouldn't the PROJ pipeline +proj=set > +v_4=2010.5 ? Doesn't that mean that if you give XYZ or LLh in "ETRS89-NLD [AGRS2010]" and you don't give t, then t is assumed to be 2010.5? And that if the transforms from that frame to something else are written assuming 2010.5 input, not doing anything is correct? Then there's the question of the output epoch, which should be part of the transform spec. I dimly remember an admonition that transforms among dynamic datums should have the same epoch on both sides, and coordinates should be moved from epoch to epoch in each datum to meet the transform. From even.rouault at spatialys.com Sun Jun 21 14:52:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 21 Jun 2026 23:52:45 +0200 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: https://docs.ogc.org/as/18-005r8/18-005r8.pdf: """datum anchor epoch:? epoch at which a static reference frame matches a dynamic reference frame from which it has been derived. Note: Not to be confused with the frame reference epoch of dynamic geodetic and dynamic vertical reference frames. Nor with the epoch at which a reference frame is defined to be aligned with another reference frame; this information should be included in?the datum anchor definition." -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot From gdt at lexort.com Sun Jun 21 15:09:53 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 21 Jun 2026 18:09:53 -0400 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: (Even Rouault's message of "Sun, 21 Jun 2026 23:52:45 +0200") References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: Even Rouault writes: > https://docs.ogc.org/as/18-005r8/18-005r8.pdf: > > """datum anchor epoch:? epoch at which a static reference frame > matches a dynamic reference frame from which it has been > derived. Note: Not to be confused with the frame reference epoch of > dynamic geodetic and dynamic vertical reference frames. Nor with the > epoch at which a reference frame is defined to be aligned with another > reference frame; this information should be included in?the datum > anchor definition." Thanks. So: CRS A: "NAD83(2011)" is a dynamic datum and has a frame reference epoch of 2010.0. CRS B: "NAD83(2011) epoch 2010.0" has a datum anchor epoch of 2010.0, but this value is logically distinct from the reference epoch 2010.0 Had it been 2015.0 instead, then coordinates in A with a missing time would be different from coordinates in B. But the values are the same, so A-missing-t and B use the same coordinates. It would seem madness to pick a different datum anchor epoch than the underlying frames frame reference epoch, but I see that AGRS2010 is an annual solution for a reference network and thus I guess only expected to be used by a select few with high clue. Or maybe not, if it's the frame of the transmitted reference data. It seems that there is an implied null transform: [B] to [A at B's datum anchor epoch] which if the epochs match is [B] to [A at A's frame reference epoch] which is also [B] to [A with epoch not specified] and these are definitional, not aproximate. But also that this is probably not what's going on in this case. These static-derived-from-dynamic frames seem highly useful for operators of RTK networks. Consider running a network: what values do you plug in for reference station coordinates and how do you update them? With a dynamic datum, you have to either put in velocities and hope the software computes new coordinates at some reasonable frequency and that receivers pick up the new coordinate, or you need to just change the coordinates say monthly. (It's interesting to note that GPS changes the coordinates ~yearly as I understand it.) With a static-derived-from-dynamic frame, you just put the coordinates in once, being careful not make mistakes, and then you don't touch them, avoiding future mistakes. From gdt at lexort.com Sun Jun 21 15:14:39 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 21 Jun 2026 18:14:39 -0400 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? In-Reply-To: (Even Rouault via PROJ's message of "Sun, 21 Jun 2026 21:33:23 +0200") References: Message-ID: Even Rouault via PROJ writes: > Xavier, (re-adding the list) > > Thanks for the hint. I should have looked more closely at the WKT > definition which does indicate the dynamic nature with frameepoch 1989 > > (and NATRF2022e2020 is a different beast with an *anchor epoch* of 2020) indeed but at least by using anchor epoch, the semantics are clear. I have been wondering about EPSG:6319 (6317), which seems to be a dynamic frame with a frame reference epoch of 2010.0, but the frame reference epoch is not part of the EPSG definition. I don't see how the datum is tagged as static vs dynamic, or is "no frame reference epoch" --> static? Do people think this is correct, or not quite? https://epsg.org/crs_6317/NAD83-2011-.html From gdt at lexort.com Sun Jun 21 15:39:44 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 21 Jun 2026 18:39:44 -0400 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? In-Reply-To: (Greg Troxel via PROJ's message of "Sun, 21 Jun 2026 18:14:39 -0400") References: Message-ID: Greg Troxel via PROJ writes: > I have been wondering about EPSG:6319 (6317), which seems to be a > dynamic frame with a frame reference epoch of 2010.0, but the frame > reference epoch is not part of the EPSG definition. I don't see how the > datum is tagged as static vs dynamic, or is "no frame reference epoch" > --> static? > > https://epsg.org/crs_6317/NAD83-2011-.html Sorry, I was confused and didn't open up all the sub-parts of the page. It says "ANCHOR EPOCH" = "2010.0". So this is exactly the "NAD83(2011) epoch 2010.0" in use for RTK networks (and everything else). Adding anchor epoch is a relatively recent change, in November of 2024. https://epsg.org/closed-change-request/browse/id/2024.065 I guess it's interesting but not important that the dynamic datum this is derived from is (apparently) not in the db. From Jochem.Lesparre at kadaster.nl Mon Jun 22 00:51:59 2026 From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem) Date: Mon, 22 Jun 2026 07:51:59 +0000 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: > So I'm thinking the output coordinate when applying "ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate epoch 2010.5, right? Shouldn't the PROJ pipeline +proj=set +v_4=2010.5 ? For the transformation from ETRS89-NLD [AGRS2010] to ETRF2000 that would make sense, but for the reverse transformation you would strictly need ETRF2000 velocities of your input points to change the epoch to 2010.50. As ETRF2000 can be considered static for most applications in the Netherlands, the epoch could be set to 2010.50 in both directions in practice. However, setting the epoch is most important if you want to transform ETRS89-NLD [AGRS2010] to ETRF2000 to ITRF2020 (or reverse). In that case you need to set the epoch to the required epoch (e.g. current epoch) for the output ITRF2020 coordinates, not 2010.50. 3 Steps between ETRS89-NLD[AGRS2010] and ITRF2020 at current: ETRS89-NLD[AGRS2010] <-> ETRF2000 at 2010.50 (null transformation) ETRF2000 at 2010.50 <-> ETRF2000 at current (null transformation or based on station velocity) ETRF2000 at current <-> ITRF2020 at current (time-dependent transformation) 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]. From xavier.collilieux at ign.fr Mon Jun 22 00:58:35 2026 From: xavier.collilieux at ign.fr (Xavier Collilieux) Date: Mon, 22 Jun 2026 07:58:35 +0000 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: Hello, If the output epoch is changed, there should be an additional operation for time propagation, which is the application of a deformation model. For countries like France, or any country on the stable part of the tectonic plate for plate-fixed frames, the deformation model is simply a null-velocity field. Adding this null operation would make clearer the assumption which is made. As soon as an epoch needs to be changed, a deformation model should be applied. And it makes sense in some cases, not to change the coordinates when the deformation is negligible. Best regards, Xavier -----Message d'origine----- De?: PROJ De la part de Even Rouault via PROJ Envoy??: dimanche 21 juin 2026 23:07 ??: proj Objet?: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", I see it is a noop transformation, so with no time dependency...? How does that fit with the fact that ETRF2000 is dynamic. I see that "ETRS89-NLD [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when applying?"ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate epoch 2010.5, right?? ?Shouldn't the PROJ pipeline +proj=set +v_4=2010.5 ? Same question for ETRS89-FRA [RGF93 v2] to ETRF2000 (1) and ETRS89-FRA [RGF93 v2b] to ETRF2000 (1) with are both no-ops. Shouln't output coordinate epochs be respectively 2009 and 2019 per their anchor epoch ? -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot _______________________________________________ PROJ mailing list PROJ at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj From xavier.collilieux at ign.fr Mon Jun 22 00:55:19 2026 From: xavier.collilieux at ign.fr (Xavier Collilieux) Date: Mon, 22 Jun 2026 07:55:19 +0000 Subject: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) In-Reply-To: References: <20abec7d-a57c-44f9-9a6c-bcc2c8724d95@spatialys.com> Message-ID: Hello, If the output epoch is changed, there should be an additional operation for time propagation, which is the application of a deformation model. For countries like France, or any country on the stable part of the tectonic plate for plate-fixed frames, the deformation model is simply a null-velocity field. Adding this null operation would make clearer the assumption which is made. As soon as an epoch needs to be changed, a deformation model should be applied. And it makes sense in some cases, not to change the coordinates when the deformation is negligible. Best regards, Xavier -----Message d'origine----- De?: PROJ De la part de Even Rouault via PROJ Envoy??: dimanche 21 juin 2026 23:07 ??: proj Objet?: [PROJ] ETRFxx to national ETRS89 realizations (e.g. ETRS89-NLD [AGRS2010], RGF93 v2/v2b, ETRS89-HUN [ETRF2000], etc.) (was Re: Time dependency in ETRFxx to ETRFyy coordinate transformations?) Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", I see it is a noop transformation, so with no time dependency...? How does that fit with the fact that ETRF2000 is dynamic. I see that "ETRS89-NLD [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when applying?"ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate epoch 2010.5, right?? ?Shouldn't the PROJ pipeline +proj=set +v_4=2010.5 ? Same question for ETRS89-FRA [RGF93 v2] to ETRF2000 (1) and ETRS89-FRA [RGF93 v2b] to ETRF2000 (1) with are both no-ops. Shouln't output coordinate epochs be respectively 2009 and 2019 per their anchor epoch ? -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot _______________________________________________ PROJ mailing list PROJ at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj From Jochem.Lesparre at kadaster.nl Mon Jun 22 01:26:07 2026 From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem) Date: Mon, 22 Jun 2026 08:26:07 +0000 Subject: [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations? In-Reply-To: References: Message-ID: > This week, I see 0.1 mm as totally acceptable rounding/etc. error. 1 mm is probably actually ok but socially unacceptable and 1 cm is IMHO a real problem. For end-users, 1 cm measurement precision is the best they can get for points without a permanent GNSS station. To make sure the transformation accuracy is negligible, we require software to give correct results within 1 mm for the transformation to/from Dutch CRSs. To check this fairly with PROJ, 0.1 mm accuracy is indeed good enough. For permanent GNSS stations a few mm is the best measurement precision we can get. So, for transforming GNSS station coordinates with PROJ, 0.1 mm accuracy is good enough too. 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].