[gdal-dev] GML / NAS code redundancy

[Even Rouault]

Le mardi 18 mars 2014 18:33:21, Martin Landa a écrit :
> Hi Even,
> 
> 2014-03-18 18:04 GMT+01:00 Even Rouault <even.rouault at mines-paris.org>:
> > increase the szHeader size). Add in the GML registry your feature types
> > and make them point to the same .gfs file that define all the feature
> > types ! The only
> 
> I do not understand this part, point to the same GFS file? This file
> is generated by OGR, why not to use available XSD for given format? I
> tried registry file bellow

The OGR GML XSD parser is limited and only understands simple feature model. 
The .gfs is indeed generated by OGR but can also be customized (when the 
automatic parser does not work) and used as a template in the GML registry. 
See the "Syntax of .gfs file by example" paragraph of 
http://www.gdal.org/ogr/drv_gml.html with the syntax of ElementPath and 
GeometryElementPath when you want to build a OGR field from a nested XML 
element. You can have a look at data/inspire_cp_CadastralParcel.gfs for a 
practical example.

> 
> <gml_registry>
>     <!-- VFR -->
>     <namespace prefix="vf"
>                uri="urn:cz:isvs:ruian:schemas:VymennyFormatTypy:v1
> ../ruian/xsd/vymenny_format/VymennyFormatTypy.xsd"
>                useGlobalSRSName="true">
>         <featureType elementName="Obec"
>                  schemaLocation="/path/to/xsd/prvky_int/ObecIntTypy.xsd"/>
>     </namespace>
> </gml_registry>
> 
> where ObecIntTypy.xsd is taken from [1], but doesn't work. I would
> expect that OGR reports 'Obec' layer with one feature in this case.
> 
> Martin
> 
> [1]
> http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-
> ISUI-VDP/Vymenny-format-RUIAN/Vymenny-format-RUIAN-(VFR)/2013_08_30_vf_xsd.
> aspx

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html