[patch]UTM support inaccurate and partly non-standard

[Gnonthgol]

UTM.getCode() returns "EPSG:3258xx" where xx is the UTM zone. But ​http://www.epsg-registry.org/ does not contain those codes.

It should rather return "EPSG:326xx" witch is the epsg codes for UTM in the northern hemisphere.

[stoecker]

EPSG:3258xx is the special form of currently implemented UTM, which has a 3000000 km offset. The corresponding base code without offset would be EPSG:258xx. UTM needs improvement to support other UTM variants, but your patch is wrong.

[Gnonthgol]

EPSG:258xx is "UTM xxN/ETRS89" while the currently implemented code is a variant of EPSG:326xx "UTM xxN/WGS84", with offset of 3500000m instead of 500000m as specified in all other UTM projections.

As to supporting other UTM variants. There is only 120 versions of UTM and 60 is implemented incorrectly. The other 60 is not implemented because they are the same as the first 60 but with an offset of 10000000m north.

The way it is now users who rightfully assumes that their UTM map uses the same coordinates as josm are in for a surprise. In addition all coordinates displayed in josm will be between 3,167,000 meters to 3,833,000 meters. Where is the logic in that?

[stoecker]

As it seems you know UTM good enough, please provide fixes, which support all UTM correctly (including the +3.000.000 offset variant for EPSG:258xx).

I implemented UTM as I needed EPSG:325833 the official coordinate system in Brandenburg/Germany. You say there may be a bug regarding ETRS89/WGS84. That can be true, but is not really important, as for our accuracy this wont be noticable.

Nevertheless it would be fine to have a correct UTM support.

There aren't only 120 variants, as special forms for North/South handling as well as non-standard offsets exist and are used.

[stoecker]

This patch breaks currently working usage and thus is like the previous one not really helpful.

[Gnonthgol]

I just tested the last patch and I can not find anything that breaks. In fact many WMS services now works for UTM projections witch was broken before. Maybe I have missed something.

[stoecker]

As I told you above EPSG:3258xx is a needed service. You drop that and support another set. That may be fine for your special case, but not for others (especially me). So a proper fix supports old and new codes and not changes the codes which exists into another subset.

[Gnonthgol]

After investigating the use of EPSG:325833 I found what appears to be the origin:​http://www.pg-forum.de/postgis/2424-koordinaten_umrechnen_brandenburg.html where it is used as a placeholder epsg code.
The projection defined appears to be in use in some Brandenburg source where 3000000 is added to the easting coordinate to make (0, 0) translate to (0, 0).
There appears to be no other use of that projection.

EPSG:326xx is the standard code used for UTM projection in the world. This is the most common UTM projection used today.

If EPSG:325833 is so important as you claim (I am not saying it is not) we could make a Brandenburg projection but this is not what most people consider UTM.

[stoecker]

Projections now support parameters for some time. For UTM this is currently the zone. It is easy to add more parameters to support all the other variants. I did not really investigate all UTM stuff in detail, so I don't know what is right and what is not. But whatever patch is accepted, it must keep the status quo and improve situation. I have no problem, when e.g. a parameter "Offset 3.000.000 m" is added and default is standard UTM.

[stoecker]

This new patch has again one major problem. Instead of keeping the UTM stuff inside UTM it creates a new class. Actually this is opposite to the concept of JOSM, which means to keep the base projections list small and move the specifics into the sub-parameters. Why don't you try as I suggested, that would be compliant with JOSMs policy?

Also the code must be EPSG:325833 or the WMS servers wont support it.

[Gnonthgol]

OK, I did what you suggested (although it seems to me to be very messy). Updates uses the same settings as before but the default settings are set to EPSG:32630. I also added an option for hemisphere. We now supports all UTF zones.

[stoecker]

(In [3477]) apply patch by Gnonthgol - fix #5330 - UTM issues

[stoecker]

Maybe from a code-view your previous suggestion is better, but I have to look at it from users view and there it is better to encapsulate UTM stuff in UTM and don't spread it over multiple projections or we very fast have thousands of projections in the initial list.

Thanks for your work.