Extent in layer preview is calculated wrongly (OGR provider)

[nkjoller]

When using a feature set in EPSG:25832 (ETRS89/UTM32) with the ogr provider, the preview function works as expected in the data connection, showing an area of approximately 3 x 3 miles.

When I create a layer definition with the data, the preview function does not show anything, but uses coordinates like "X: 72156417880489584.0000, Y: 61763504620569632.00000" when pointing. The expected coordinates would look to be be "X: 721,564.17, Y: 6,176,350.46".

When I add that layer definition to a map, and try to calculate the extents, it shows up as

  <Extents>
    <MinX>7.19497399174557E+16</MinX>
    <MaxX>7.23630958461686E+16</MaxX>
    <MinY>6.17459435922873E+16</MinY>
    <MaxY>6.17810656432956E+16</MaxY>
  </Extents>

Which obviously seems wrong.

I have tried with both a QGIS produced MapInfo tab file, the same file converted to ESRI shape, and also a tab file produced using MapInfo.

I would expect that if the trouble was in the data, the preview on the data connection would fail too. But since the trouble happens in the layer part, I do not know where the problems start.

I hope I have provided enough information to make sense of it all. Please do not hesitate to ask for more info.

[jng]

The problem is simple.

The all so powerful CS-Map library that supports thousands of different coordinate systems and transformations and used by MapGuide, is not available for Maestro to use over the mapagent http interface, because no coordinate transformation APIs are exposed over it.

So as a result, we resort to using the imperfect Proj.Net library which does not have the same power, reach and flexibility as CS-Map. The numbers you see generated are the result of going through this library.

There are solutions for this problem in the long-term (I'd have to implement them first). The short term one would be to write a web-based helper script in PHP/ASP.net/Java that can access the MgCoordinateSystem API and do this extent number crunching for you

[nkjoller]

Thank you for the swift response.

I just did an experiment taking the same feature set as a tab file (using OGR) and from our MSSQL database (using the MSSQL provider). The OGR feature set worked as described above, but the MSSQL feature set worked as expected.

Is this because of some (MS)SQL-feature to get extents that OGR does not have?

Replying to jng:

The problem is simple.

The all so powerful CS-Map library that supports thousands of different coordinate systems and transformations and used by MapGuide, is not available for Maestro to use over the mapagent http interface, because no coordinate transformation APIs are exposed over it.

So as a result, we resort to using the imperfect Proj.Net library which does not have the same power, reach and flexibility as CS-Map. The numbers you see generated are the result of going through this library.

There are solutions for this problem in the long-term (I'd have to implement them first). The short term one would be to write a web-based helper script in PHP/ASP.net/Java that can access the MgCoordinateSystem API and do this extent number crunching for you

[jng]

The problem with consuming data via the OGR FDO provider is that FDO is not working against a particular data store or RDBMS whose capabilities we know of and are well documented, but against another generic data access API (OGR) whose capabilities may not be enough for us or may be ambiguous.

As a result some things may not exactly translate 1:1 if consuming data through the OGR FDO provider. I normally suggest using the OGR provider as a "last resort" when using a specialized provider or moving data to a data store that is supported by a specialized provider is not an option.

[jng]

Another thing to consider is to run ogrinfo against this data source. Does it return the same numbers for the bounding box? If so, then that particular OGR driver is the source of the problem.

[jng]

MGOS 3.0 will bundle a significantly enhanced OGR provider that should make extent calculations more accurate.