Sheboygan Districts layer is displaced

[waltweltonlair]

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.

[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?

[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.

[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!

[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.

[anonymous]

According to Brad Nesom:

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

[rexszeto]

A new sheboygan package has been created.