#13694 closed enhancement (fixed)
Display UTM zone and letter in object info panel
Reported by: | naoliv | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 17.11 |
Component: | Core | Version: | |
Keywords: | projection utm zone | Cc: | bastiK |
Description
Could we have the UTM zone and letter displayed in the object info panel, please?
JOSM:
Build-Date:2016-09-24 13:12:40 Revision:11048 Is-Local-Build:true Identification: JOSM/1.5 (11048 SVN pt_BR) Linux Debian GNU/Linux unstable (sid) Memory Usage: 1089 MB / 4029 MB (439 MB allocated, but free) Java version: 1.8.0_102-8u102-b14.1-2-b14, Oracle Corporation, OpenJDK 64-Bit Server VM Screen: :0.0 1920x1080 Maximum Screen Size: 1920x1080 Java package: openjdk-8-jre:amd64-8u102-b14.1-2 Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-9 VM arguments: [-Dawt.useSystemAAFontSettings=on] Dataset consistency test: No problems found
Attachments (0)
Change History (10)
comment:1 follow-up: 2 Changed 5 years ago by
Cc: | bastiK added |
---|---|
Keywords: | projection utm zone added |
comment:2 Changed 5 years ago by
Replying to Don-vip:
@bastiK: is JOSM capable of this? I thought UTM zones were uniform before learning about the exceptions:
The only information we have in JOSM right now is the mapping from UTM zone (1-60) to central longitude.
These grid zones are uniform over the globe, except in two areas. On the southwest coast of Norway, grid zone 32V (9° of longitude in width) is extended further west, and grid zone 31V (3° of longitude in width) is correspondingly shrunk to cover only open water. Also, in the region around Svalbard, the four grid zones 31X (9° of longitude in width), 33X (12° of longitude in width), 35X (12° of longitude in width), and 37X (9° of longitude in width) are extended to cover what would otherwise have been covered by the seven grid zones 31X to 37X. The three grid zones 32X, 34X and 36X are not used.
Those exceptions are very limited and could be hard-coded.
comment:3 Changed 5 years ago by
In geodesy sometimes working in neighbor UTM zone is also done to prevent UTM zone switches.
I think the main question here is: Why should we do this?
Nearly nobody needs this and zone calculation is extremly simple and can be done manually.
comment:5 Changed 5 years ago by
Believe or not, JOSM is better than some GIS programs to edit data (and having the UTM info would make some edits even more convenient).
But of course, I can understand that this is not exactly related with OSM.
comment:6 Changed 5 years ago by
@bastiK: Don't we have a bug in CustomProjection
?
// "utm" is a shortcut for a set of parameters if ("utm".equals(parameters.get(Param.proj.key))) { Integer zone; try { zone = Integer.valueOf(Optional.ofNullable(parameters.get(Param.zone.key)).orElseThrow( () -> new ProjectionConfigurationException(tr("UTM projection (''+proj=utm'') requires ''+zone=...'' parameter.")))); } catch (NumberFormatException e) { zone = null; } if (zone == null || zone < 1 || zone > 60) throw new ProjectionConfigurationException(tr("Expected integer value in range 1-60 for ''+zone=...'' parameter.")); this.lon0 = 6d * zone - 183d; this.k0 = 0.9996; this.x0 = 500_000; this.y0 = parameters.containsKey(Param.south.key) ? 10_000_000 : 0; }
I see nothing about exceptions for zones 31V/32V. I fear lon0 calculation is wrong for these zones.
comment:7 Changed 5 years ago by
The exceptions are for the military grid reference system (MGRS), which is based on UTM. As we don't support MGRS, there can be no bug...
comment:9 Changed 5 years ago by
Milestone: | → 17.11 |
---|
@bastiK: is JOSM capable of this? I thought UTM zones were uniform before learning about the exceptions: