[fdo-internals] FDO RFC 16 - FDO Provider for SQLite

[Bruce Dechant]

Hi,

MapGuide does have a requirement of needing a coordinate system. It is difficult to do anything spatially without a coordinate system as the reference for the data.
However, this is not strictly enforced by the server.

The reason that the SHP files work without a projection file is because the SHP provider is providing a default coordinate system for MapGuide to use - which is called "Default" which is essentially an empty coordinate system. This causes the MapGuide server to failover to using an empty coordinate system for the data with the extents of the data set to what the data is - so a layer preview works and a map using this layer appears to work. However, this is not a proper definition of a coordinate system.

It looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<FdoSpatialContextList>
  <ProviderName>OSGeo.SHP.3.3</ProviderName>
  <SpatialContext IsActive="true">
    <Name>Default</Name>
    <Description></Description>
    <CoordinateSystemName></CoordinateSystemName>
    <CoordinateSystemWkt></CoordinateSystemWkt>
    <ExtentType>Dynamic</ExtentType>
    <Extent>
      <LowerLeftCoordinate>
        <X>-141.00300598144531</X>
        <Y>41.913318634033203</Y>
      </LowerLeftCoordinate>
      <UpperRightCoordinate>
        <X>-52.620281219482422</X>
        <Y>83.108322143554688</Y>
      </UpperRightCoordinate>
    </Extent>
    <XYTolerance>0.001000</XYTolerance>
    <ZTolerance>0.001000</ZTolerance>
  </SpatialContext>
</FdoSpatialContextList>

In the above the extent information is there, but there is no OGC WKT string.

Things can start to go bad when this layer is used on a map that has a coordinate system that is different and thus may require a coordinate system transform - in this case things fail.

If you happen to use Studio to add the SHP file via a load procedure it will automatically set the coordinate system for you - it defaults to Arbitrary XY - Meters.

Thanks,
Bruce

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, April 22, 2008 10:00 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite

Frank's new files are still not working.  I don't think that MapGuide
has a specific requirement for a CS; it works fine with shape files that
don't have projection info.

This explanation doesn't make a lot of sense given where in the MapGuide
code this is failing.

http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Server/src/Services/F
eature/ServerGetFeatures.cpp#l978

(or thereabouts).  I find it amusing that the comment at the default
condition is "We will probably never hit this code" :)

My guess would be that the provider is passing a data type that MapGuide
hasn't accounted for or is not a valid FDO type.  From the code, it
looks like MapGuide understands:

  Boolean, Byte, DateTime, Decimal, Double, Int16, Int32, Int64, Single,
String, BLOB and CLOB.

Traian, in your manual tests of describing the schema of Frank's tables,
what data types are you getting?

Jason

-----Original Message-----
From: Traian Stanev
Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite


The data reads fine in my manual tests, but Jason pointed out that it
errors out in MapGuide. One thing I noticed is that some of the geometry
columns have an SRID equal to 0, meaning they don't have a coord sys.
Was that intentional? Generally FDO data sources are required to have a
coordinate system, so this is what could be causing the problem in
MapGuide.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals