Opened 16 years ago
Closed 16 years ago
#143 closed defect (fixed)
Incorrect scale displayed for maps using units other than meters
Reported by: | chrisclaydon | Owned by: | madair |
---|---|---|---|
Priority: | P1 | Milestone: | 2.0 |
Component: | Widgets | Version: | SVN |
Severity: | Major | Keywords: | |
Cc: | Browser: | All | |
External ID: | 1085634 | Operating System: | All |
state: | Analysis Requested |
Description
When a MapGuide map is displayed using Fusion, the initial map view is incorrect for maps that do not use a coordinate system with meters as the units.
The difference between the desired and actual scale seems to be consistent with the difference in size of the actual units from meters.
Change History (10)
comment:1 by , 16 years ago
Priority: | P2 → P1 |
---|
comment:2 by , 16 years ago
Status: | new → assigned |
---|
comment:3 by , 16 years ago
The map is actually rendered at the wrong scale. It is either zoomed too far in or too far out, depending on whether the map units are larger or smaller than meters.
comment:4 by , 16 years ago
I got the test package loaded and I think Fusion/MapGuide are behaving correctly here.
All 3 layers (meters/kilometers/millimeters) are using the same underlying .sdf data file, however the coord sys overrides in the data source are telling MapGuide to interpret the x,y values in that file as meters/km/mm. And given that they all have the same extents, the resulting map images will be scaled +/- a factor of 1000. To have the resulting maps appear the same the max extents of the layers would have to be scaled by +/- 1000 to get the same set of resolutions.
comment:5 by , 16 years ago
If the data is interpreted as being in millimeters, and the Map coordinate system uses millimeters, and the initial extents of the map match the full extent of the data, the entire data set should fill the initial view.
I dug into this a little more, and it seems that there are two separate issues at hand:
1) Fusion maps the metersPerUnit value from the MG map to the nearest OpenLayers unit. So it maps millimeters to inches, which throws everything off. I tried adding a definition for 'mm' units into OpenLayers.js, and that fixed the problem for the millimeter-based map example.
OpenLayers.INCHES_PER_UNIT["mm"] = OpenLayers.INCHES_PER_UNIT.m / 1000.0;
It would be nice to add entries to the OpenLayers.INCHES_PER_UNIT list on the fly for units that don't currently have an entry, rather than having to hard-code every possible supported unit...
2) There seems to be a restriction on the maximum scale of 1:100,000,000. This is what prevents the kilometer-based map example from displaying the full data extents. I'm not sure if the restriction is imposed by Fusion or OpenLayers...
comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'd like to leave this ticket open until the CsMap units are added to OpenLayers - so we don't forget about it.
comment:9 by , 16 years ago
comment:10 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
OL trunk has been patched and the version of OL in Fusion has been updated to include this.
can you clarify what the issue is here please:
I'm testing with the Sheboygan sample which is a map in degrees