[PROJ] Dealing with different versions of PROJ along time

[Greg Troxel]

Javier Jimenez Shaw <j1 at jimenezshaw.com> writes:

> Let's say I have a GeoTIFF in "HD72 / EOV" on my server. I generate
> web-mercator tiles with gdal2tiles one day (to show it in a browser
> online), where I am using PROJ 7.0.1.
> I also have some other info (markers, GCPs) stored in "HD72 / EOV". To
> display those markers in the browser, I convert them on the fly. (btw, all
> in python).

Slightly out on a limb, you are phrasing this as "dealing with
different", but I would probably change that to "some versions result in
bad transforms due to null transform assumptions".

There is a core bug in TMS/web-mercator in that it is said to be
"WGS84", which in modern times translates to WGS84(ensemble) which means
"some version of WGS84 and I don't know which".  This leads to "because
there is a theoretical possibility that the output will be interpreteted
as WGS84(TRANSIT) and because this is low accuracy, we can just ignore
the last meter or two".  That's not really fair and shows a point of
view, but it's not that far off.

I have the same issue with NAD83 and WGS84 (web mercator).  I actually
have imagery that is referenced to about 0.1m, in jpeg200 in NAD83.
MassGIS has transformed that to TMS/web-mercator and actually
transformed it (a bit more than a meter).  But if I ask proj (6.x) to
transform NAD83 to WGS84, it uses a null transform, because the oldest
NAD83 and the oldest WGS84 are more or less the same.  But NAD83(2011)
that my imagery is in, and WGS84(G1762) that the TMS *should be IMHO*
presumed to be in are clearly different.  This is particularly
troublesome when translating *to* WGS84; while there is some merit tin
the notion of fuzz when someone shows up and says their data is in WGS84
and that they don't know more, if one is asked to transform to WGS84 the
latest realization is a clear target.

I solve this by choosing ITRF2014 (= to WGS84(G1762) at the several mm
level) as my target CRS when producing GPX/geojson for display against
TMS.  Also as my input CRS for ITRF2014, but where I am precise
coordinates are either NAD83(2011) or ITRF, because there is no
reasonable mechanism to access other datums at the 10cm level or beter.

Perhaps it is the same for HD72 and WGS84?

> LATER I update the version on my server to PROJ 7.2.0. When I transform the
> marker coordinates to web-mercator to display them in the browser, the
> marker does not fit exactly where it was before with the image. Just an
> update in the server PROJ version made the location in the browser
> different (between the image and the marker).

Yes, but which one is wrong, or was wrong before?  You are raising the
issue of "difference" but I think the real issue is that one of these
transforms is wrong.

> See that I am not running gdal2tiles again. The tiles stay with the
> transformation selected by PROJ 7.0.1
> Also I display every coordinate (the numbers I mean) in "HD72 / EOV".
> Web-mercator is used mainly to interact with the browser with a javascript
> library (openlayers).

Sure, and leaflet (that I am using for this) is likely to be the same.

> Running
> projinfo -s "HD72 / EOV" -t "WGS84 / Pseudo-Mercator"
> with both versions, I see that in proj 7.0.1 it is using the transformation
> "HD72 to WGS 84 (3)" while in 7.2.0 it is using "HD72 to WGS 84 (4)".
> Similar but not the same.

The root cause is that the definition of TMS using a datum ensemble is
just broken in the modern world.  Change TMS to use ITRF2014 and things
will probably go better.

> I understand that PROJ criteria to choose automatically a transformation
> may change. EPSG can change too, or new transformations may appear. I am
> not complaining about that.

So you are complaining that you are not able to output the chosen
transformation in the first step and to input that in the second step?

> How can I solve this discrepancy? Regenerating all the tiles every time I
> update PROJ could be expensive for every GeoTIFF. That would end up not
> updating PROJ as often as wanted.
> My problem is not the accuracy, but the consistency along the time.

Even was more helpful than I was :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201124/9c341ab9/attachment.sig>