Projection Zone knowable before transformation?

[ctieben]

In the current design of the sempr spatial classes the user have to know the exact source and destination coordinate system before a transformation could be applied to the geometries.

This also mean that the user have to predict in which region or zone a global project will happen. Following Information need to be known in these cases:

• UPS: north or south
• UTM: zone and north or south - e.g. 32
• MGRS: grid zone designator (GZD) - e.g. 4QFJ a 100 km Grid Square ID

The transformation from WGS84 internally get these information but there is currently no loop back. This could lead to an mismatch because the GeographicLib will for example calculate a zone 33 projection but the defined destination is still in zone 32.

See this zone 33 position in zone 32: https://geographiclib.sourceforge.io/cgi-bin/GeoConvert?input=32n+705243+5785860&zone=-3&prec=0&option=Submit The same position but in zone 33: https://geographiclib.sourceforge.io/cgi-bin/GeoConvert?input=52.18496+12.00241&zone=-3&prec=0&option=Submit

A loop back to the the reference system is possible but this can compromise a geometry if it cross the border of a zone. So one geometry have to be in one zone but there is no option to force the Lib to project it into a specific zone!

[ctieben]

This is only the case if you transform it to a projection.

[niniemann]

I cannot see any "zone 33" stuff at the link you provided. But if I understood correctly the problem is that a geometry that is e.g. stored in WGS84 and overlaps multiple UTM/MGRS zones will be split, with some result-coordinates in different zones than the others? That sounds bad.

Keep in mind that we should not alter a coordinate system that the user has given us as a target, as we don't know what else is linked to it. I think the best way to deal with this is to abort the transformation (-> roll back) and throw an exception to let the user deal with this. :wink:

[ctieben]

I have add a addition link above with the same position but in its correct zone.

Yes the geometry will be split up in different zones but reference still defines another. In worst case you will misinterpreter this position with a longitude difference of 6 degree. (about 450km) See: https://geographiclib.sourceforge.io/cgi-bin/GeoConvert?input=32n+704395+5785825&zone=-3&prec=0&option=Submit https://geographiclib.sourceforge.io/cgi-bin/GeoConvert?input=33n+704395+5785825&zone=-3&prec=0&option=Submit

It's possible to abort the transformation and throw an exception. But this will need some rework in the geometry filter.

[ctieben]

The basic algorithms of the geoegraphic lib allows to force the target zone by a projection to utm. Only the forward mgrs transformation have this issue and its now covered by a zone missmatch exception. (see 6cfc2d77f815084dac0c862c8e9221b2d15d437e)

So its handled and this issue can be closed.