[gdal-dev] GML3 wrong result for some kind of fields

[Even Rouault]

Le dimanche 24 juillet 2011 12:46:12, aperi2007 a écrit :
>  > string fields. This can be accomplished by setting the configuration
>  >
>  >option
>  >
>  > GML_FIELDTYPES to the value ALWAYS_STRING."
> 
> wow, this is really a good choice for me !
> 
>  >> But I don't know if the gfs file do something else or only the
> 
> description
> 
>  >> of every field.
>  > 
>  > Yes essentially that, plus the layer name, and optionnaly its extent,
> 
> the type
> 
>  > of the geometry, the number of features, etc...
> 
> unfortunately extent and number of feature are not fixed for all GML
> files I have. :(

That's why I mentionned they are *optional* ;-) If you don't include them, the 
driver will recompute the missing info if necessary

> 
>  > Another alternative is to provide a .xsd file.
> 
> The GML file has a set of xsds starting from a main xsd file linked over
> internet using the schemaLocation attribute.
> (http://www.rete.toscana.it/sett/territorio/carto/gml/dbtopo/18.9.2/dbtopo.
> xsd)
> 
> The GML driver seem don't use it.
> I guess was not used because it is linked with schemaLocation on
> internet and the xsd itself link to the GML's xsd in the OGC site.

Yes, it won't download the schema. You have to put it besides the GML file and 
with the same basename. So if you have foo.gml, the XSD must be called 
foo.xsd. Note also that the XSD parser of the GML driver is limited and will 
not always understand the schema. In which case, it will scan the GML file to 
produce a .gfs file

> 
> again
> 
> the code fields are described with a enumeration like this:
> 
> --------------------
> 	<xs:simpleType name="ClasseLarghezzaType">
> 		<xs:restriction base="AbstractDominioType">
> 			<xs:enumeration value="0100">
> 				<xs:annotation>
> 					<xs:appinfo source="urn:x-
gml:codelistValue">Larghezza Minore Di
> 3.5 Mt</xs:appinfo>
> 				</xs:annotation>
> 			</xs:enumeration>
> 			<xs:enumeration value="0200">
> 				<xs:annotation>
> 					<xs:appinfo source="urn:x-
gml:codelistValue">Larghezza Compresa Tra
> 3.5 Mt E 7.0 Mt</xs:appinfo>
> 				</xs:annotation>
> 			</xs:enumeration>
> 			<xs:enumeration value="0300">
> 				<xs:annotation>
> 					<xs:appinfo source="urn:x-
gml:codelistValue">Larghezza Maggiore Di
> 7.0 Mt</xs:appinfo>
> 				</xs:annotation>
> 			</xs:enumeration>
> ---------------
> 
> 
> However the solution to apply always text seem a good choice for me.
> 
> thx,
> 
> Andrea.
> 
> Il 24/07/2011 12:31, Even Rouault ha scritto:
> > Le dimanche 24 juillet 2011 12:20:38, Andrea Peri a écrit :
> >> Hi,
> >> 
> >> I notice that the GML driver wrong to understand some kind of field.
> >> 
> >> for example:
> >> 
> >> I have this tags:
> >> 
> >> <element>
> >> 
> >>    <id>1</id>
> >>    <code>010206</code>
> >> 
> >> </element>
> >> <element>
> >> 
> >>    <id>2</id>
> >>    <code>100206</code>
> >> 
> >> </element>
> >> 
> >> the GML driver parsing this tags intepret they as integer so in the
> >> shapefile result
> >> they are translate in
> >> 
> >> id (integer), code (integer)
> >> 1, 10206
> >> 2, 100206
> >> 
> >> this is a bad situation for me because the values in code field is a
> >> block-code to fixed lenght (6 characters).
> >> And after the conversion in shapefile is not possible to join with
> >> tables where there is the values (text) 010206, 100206
> > 
> > Quote of http://gdal.org/ogr/drv_gml.html :
> > 
> > "When prescanning the GML file to determine the list of feature types,
> > and fields, the contents of fields are scanned to try and determine the
> > type of the field. In some applications it is easier if all fields are
> > just treated as string fields. This can be accomplished by setting the
> > configuration option GML_FIELDTYPES to the value ALWAYS_STRING."
> > 
> >> I see the GML driver create a .gfs field where it has the description of
> >> these fileds,
> >> I could change it, but unfortunately I have many files and to change all
> >> the gfs is a huge work.
> >> 
> >> I think perhaps a good solution should be to use a config parameter to
> >> overlap the description in the gfs files.
> >> So I could manually write a GFS file usable for all the files GML I need
> >> to translate in shapefile/postgis.
> >> 
> >> But I don't know if the gfs file do something else or only the
> >> description of every field.
> > 
> > Yes essentially that, plus the layer name, and optionnaly its extent, the
> > type of the geometry, the number of features, etc...
> > 
> > Another alternative is to provide a .xsd file.
> > 
> >> thx,