FW: [fdo-users] RE: Which GML version is supported by FDO 3.5.0

Brent Robinson brent.robinson at autodesk.com
Tue Jan 18 08:59:27 EST 2011


I got a chance to look at the srsName issue and FDO 3.5 always sets it to EPSG:4326. In FDO 3.6, the xmlFeatureWriter sets it to the name of the associated spatial context for the geometric property. This is only done if a class definition has been passed to the xmlFeatureWriter (which is done by the xmlFeatureSerializer). Otherwise, it falls back to setting srsName to EPSG:4326.

There is a workaround to get the srsName back to EPSG:4326, which is to set the following properties on the xmlFeatureFlags that are passed to xmlFeatureSerializer:


However, this has a side effect in that the feature and property elements end up prefixed by the defaultNamespacePrefix (e.g.: if defaultNamespacePrefix="abc" then all output element names will start with "abc:"). The workaround also takes advantage of another bug. By prefixing the property names, it fakes out the xmlFeatureWrite, which no longer finds the geometric property in the class definition when looking for the spatial context name, meaning that the workaround will lose effect once this bug is fixed.

When writing from SHP, another possibility is to add a .prj file. The spatial context name will be set from the first field in the WKT in the .prj. However, I don't know if setting this name to "EPSG:4326" causes problems when the SHP files are used in other applications.

I'm not sure of any other workarounds, other than post-processing the XML to change the srsName.

In general, neither setting is completely correct. In FDO 3.5, the srsName was set to EPSG:4326 even if the geometry was in a different coordinate system. In FDO 3.6. it is possible to get a GML representation of the spatial context through the xmlSpatialContextSerializer but this definition tends to be FDO-specific.

FDO relates spatial contexts to geometric properties so it doesn't need the associations between spatial contexts and geometry values. Therefore, a potential fix would be to set the srsName for the values to the underlying coordinate system, rather than the spatial context. For EPSG coordinate systems, it could just be a well-know reference.


-----Original Message-----
From: Brent Robinson 
Sent: Monday, January 17, 2011 9:35 AM
To: 'FDO Users Mail List'
Subject: RE: [fdo-users] RE: Which GML version is supported by FDO 3.5.0

If you use the xmlFeatureSerializer then the null properties will be absent in the output file, which would be a bug. This is done to be consistent with how FDO serializes feature schemas; a nullable property is represented by an <element> with minoccurs="0". I don't remember why this was done, rather than set the nillable attribute, probably an oversight. For reading schemas, the situation is a bit better; the nillable attribute is handled if present.


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Crispin_at_1Spatial
Sent: Friday, January 14, 2011 3:40 AM
To: fdo-users at lists.osgeo.org
Subject: [fdo-users] RE: Which GML version is supported by FDO 3.5.0

The provider is SHP.

I have the same code in two .NET projects referencing FDO 3.5 and 3.6 so I
end up with a 3.5 exe and a 3.6 exe so I know the application is the same
and I am referencing the same SHP file.

A query to get spatial context returns "Default" on the SHP file in 3.5 and
3.6 (there is no .PRJ file with the SHP)

So it looks like the previous 3.5 XML provider is setting the srs to
EPSG:4326 - through some rule?
The 3.6 provider is preserving the default name.

I am no GML expert so I couldn't say which is a better interpretation where
there is no spatial context found.

I'd be more interested in a clarification if NULL properties should be
absent or with empty XML tags.

 Thanks for updating the thread - Crispin
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Which-GML-version-is-supported-by-FDO-3-5-0-tp5906711p5921022.html
Sent from the FDO Users mailing list archive at Nabble.com.
fdo-users mailing list
fdo-users at lists.osgeo.org

More information about the fdo-users mailing list