Opened 11 years ago

Closed 11 years ago

#42 closed defect (fixed)

Sheboygan Districts layer is displaced

Reported by: waltweltonlair Owned by: rexszeto
Priority: high Milestone: 1.2
Component: General Version: 1.2.0
Severity: major Keywords:
Cc: External ID: 926447


Jackie Ng reports:

I've been playing around with the 1.2 beta and I've noticed when I brought
up the Sheboygan Sample Dataset, that the "Districts" layer has been
displaced to the north.

Has anyone else noticed this? Problem with the data? Regression in MapGuide?

I remember seeing this at one point as well. This is a regression.

Change History (8)

comment:1 Changed 11 years ago by waltweltonlair

The problem involves the coordinate system for the Districts layer. Here's the WKT I get for this layer (as computed in MgStylizationUtil::GetLayerToMapTransform):

GEOGCS["LL84",DATUM["WGS 84",SPHEROID["WGS 84",6378137,0],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0],UNIT["Degrees",0.01745329252]]

For the CityLimits layer (and for the map as a whole) the coordinate system WKT is:

GEOGCS["WGS84 Lat/Long?'s, Degrees, -180 ==> +180",DATUM["D_WGS_1984",SPHEROID["World_Geodetic_System_of_1984",6378137,298.257222932867]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

The main difference that caught my eye was the SPHEROID y-value. For the Districts layer it's 0, while for the other WKT it's 298.2... Isn't this some kind of a datum shift?

I know some bugs were fixed around datums not too long ago. Maybe the WKT for the Districts layer has been invalid all ths time, and this problem only showed up recently?

comment:2 Changed 11 years ago by waltweltonlair

According to the OGC spec, the 3rd argument for the SPHEROID is the "inverse flattening". Using the debugger I interactively changed the value of this parameter for the Districts layer from 0 to 298.257222932867. When I did that the Districts layer lined up correctly with the CityLimits layer.

I think the WKT for the Districts feature source is simply incorrect.

comment:3 Changed 11 years ago by waltweltonlair

The problem is definitely the Sheboygan data set itself. All source data in the data set should be using the same coordinate system. In our case though, the VotingDistricts? feature source shows "LL84" while all the others show some a different one - "WGS84 Lat/Long?'s, Degre" ... The WKTs for these two are different, as noted above.

To fix this I think we simply need to republish all the data files for the data set using the same coordinate system. We also need to make sure we use the correct one!

comment:4 Changed 11 years ago by brucedechant

The coordinate systems are slightly different and this is causing a datum shift.

As Walt pointed out the fix is to republish the data using the same coordinate system.

comment:5 Changed 11 years ago by rexszeto

External ID: 926447

comment:6 Changed 11 years ago by anonymous

According to Brad Nesom:

The correct spheroid should be 298. For any spheroid based system it would
be approx that not 0.

comment:7 Changed 11 years ago by rexszeto

Owner: set to rexszeto

comment:8 Changed 11 years ago by rexszeto

Resolution: fixed
Status: newclosed

A new sheboygan package has been created.

Note: See TracTickets for help on using tickets.