Opened 15 years ago

Closed 15 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


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 chrisclaydon, 15 years ago

Priority: P2P1

comment:2 by madair, 15 years ago

Status: newassigned

can you clarify what the issue is here please:

  • is it that the scale value displayed in the status bar is incorrect?
  • or is it that a scale value element in an InitialView in AppDef doesn't get interpreted correctly?

I'm testing with the Sheboygan sample which is a map in degrees

comment:3 by chrisclaydon, 15 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 madair, 15 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 chrisclaydon, 15 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 madair, 15 years ago

Resolution: fixed
Status: assignedclosed

(In [1648]) closes #143: remove arbitrary maxScale of 100M; add OL inches per unit value for millimeters - full patch for OL to support more CS-MAP units to come

comment:7 by chrisclaydon, 15 years ago

Resolution: fixed
Status: closedreopened

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 madair, 15 years ago

(In [1693]) re #143: update of OL with extra units (and the Google layer type)

comment:10 by madair, 15 years ago

Resolution: fixed
Status: reopenedclosed

OL trunk has been patched and the version of OL in Fusion has been updated to include this.

Note: See TracTickets for help on using tickets.