Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#5330 closed defect (fixed)

[patch]UTM support inaccurate and partly non-standard

Reported by: Gnonthgol Owned by: team
Priority: minor Milestone:
Component: Core Version:
Keywords: UTM projection epsg Cc:


UTM.getCode() returns "EPSG:3258xx" where xx is the UTM zone. But does not contain those codes.

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

Attachments (1)

epsg.patch (9.4 KB) - added by Gnonthgol 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by stoecker

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 9 years ago by Gnonthgol

Resolution: invalid
Status: closedreopened

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?

comment:3 Changed 9 years ago by stoecker

Summary: UTM.getCode() returns wrong EPSG codeUTM support inaccurate and partly non-standard

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.

comment:4 Changed 9 years ago by Gnonthgol

Summary: UTM support inaccurate and partly non-standard[patch]UTM support inaccurate and partly non-standard

comment:5 Changed 9 years ago by stoecker

Summary: [patch]UTM support inaccurate and partly non-standardUTM support inaccurate and partly non-standard

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

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by Gnonthgol

After investigating the use of EPSG:325833 I found what appears to be the origin: 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.

comment:9 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by Gnonthgol

Summary: UTM support inaccurate and partly non-standard[patch]UTM support inaccurate and partly non-standard

comment:11 Changed 9 years ago by 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.

Changed 9 years ago by Gnonthgol

Attachment: epsg.patch added

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

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

comment:14 Changed 9 years ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.