[gdal-dev] GML / NAS code redundancy

Even Rouault even.rouault at mines-paris.org
Wed Apr 16 04:27:43 PDT 2014


Le mercredi 16 avril 2014 13:16:16, Martin Landa a écrit :
> Hi,
> 
> 2014-04-05 12:36 GMT+02:00 Martin Landa <landa.martin at gmail.com>:
> > First is related to GML registry. The input file contains different
> > layers based on its internal type (TypSouboru). For each of these
> > types are prepared separated GFS file.
> > 
> >     <!-- Czech VFR schame-->
> >     <namespace prefix="vf"
> >     
> >                uri="urn:cz:isvs:ruian:schemas:VymennyFormatTypy:v1
> > 
> > ../ruian/xsd/vymenny_format/VymennyFormatTypy.xsd"
> > 
> >                useGlobalSRSName="true">
> >         
> >         <featureType elementName="TypSouboru"
> >         
> >                      elementValue="OB_UKSH"
> >                      gfsSchemaLocation="vfr_ob_uksh_v1.gfs"/>
> >         
> >         <featureType elementName="TypSouboru"
> >         
> >                      elementValue="ST_UKSH"
> >                      gfsSchemaLocation="vfr_st_uksh_v1.gfs"/>
> >         
> >         <featureType elementName="TypSouboru"
> >         
> >                      elementValue="ST_UKSG"
> >                      gfsSchemaLocation="vfr_st_uksg_v1.gfs"/>
> >     
> >     </namespace>
> 
> I am closer to commit support for this format to SVN (GFS files).
> Feature geometry (definicni bod - centroid, originalnihranice -
> original boundary and generalizovanehranice - geneneralized
> boundaries) differs based on the file type (eg. ST_UKSG x ST_UKSH). To
> avoid redundancy (separate GFS for each file type) I created two files
> - one for ST and OB major file types (they contains different layers -
> vrstva), see [1]. Currently some of classes have three geometry
> columns (definicnibod, originalnihranice and generalizovanahranice)
> which is not elegant but works.
> 
> I was thinking to change featureType logic in the sense that only one
> GFS (ruain_v1.gfs) file would be needed. Then you would list GML
> feature classes manually and define also properties which should be
> ignored, eg.
> 
>        <featureType elementName="TypSouboru"
>                      elementValue="OB_UKSH"
>                      gfsSchemaLocation="ruain_v1.gfs">
>           <GMLFeatureClassList>
>             <GMLFeatureClass>
>               <Name>Obce</Name>
>               <PropertyIgnored>
>                 <ElementPath>Geometrie|GeneralizovaneHranice5</ElementPath>
>               </PropertyIgnored>
>             </GMLFeatureClass>
>             <GMLFeatureClass>CastiObci</GMLFeatureClass>
>             <GMLFeatureClass>KatastralniUzemi</GMLFeatureClass>
>              <PropertyIgnored>
>                 <ElementPath>Geometrie|GeneralizovaneHranice4<ElementPath>
>               </PropertyIgnored>
>             <GMLFeatureClass>Zsj</GMLFeatureClass>
>              <PropertyIgnored>
>                 <ElementPath>Geometrie|GeneralizovaneHranice4</ElementPath>
>               </PropertyIgnored>
>             <GMLFeatureClass>Ulice</GMLFeatureClass>
>             <GMLFeatureClass>Parcely</GMLFeatureClass>
>              <PropertyIgnored>
>                 <ElementPath>Geometrie|GeneralizovaneHranice3</ElementPath>
>               </PropertyIgnored>
>             <GMLFeatureClass>StavebniObjekty</GMLFeatureClass>
>              <PropertyIgnored>
>                 <ElementPath>Geometrie|GeneralizovaneHranice2</ElementPath>
>               </PropertyIgnored>
>             <GMLFeatureClass>AdresniMista</GMLFeatureClass>
>           </GMLFeatureClassList>
>         </featureType>
>       </featureType>
> 
> In this case OGR would report layers Obce, ..., AdresniMista (so
> subset of major GFS file), Obce would define only two geometries
> (DefinicniBod and OriginalniHranice). Similarly for OB_UKSG only
> DefinicniBod and GeneralizovaneHranice.
> 
> What do you think? Martin

Martin,

I'm personaly not a big fan of that approach. It looks a bit odd to work with 
exclusion mechanisms, and this means additional source code to write, debug 
and maintain, whereas there is already a working solution with the .gfs files, 
even if there's some redundancy between them.

If you really want to avoid redundancy while steal having only the relevant 
attributes for each feature type, another option would be to add <xi:include> 
( cf http://en.wikipedia.org/wiki/XInclude , http://www.w3.org/TR/xinclude/ ) 
support in the parsing of .gfs files so as to be able to define a common .gfs 
shared by 2 feature types .gfs. Would be more standard.

Even

> 
> [1] http://geo.fsv.cvut.cz/freegis/RUIAN#Knihovna_OGR (in Czech, but
> tables should be understandable)

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


More information about the gdal-dev mailing list