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

[aperi2007]

 > 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. :(


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

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,