> 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,
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
