Le mercredi 16 avril 2014 13:16:16, Martin Landa a écrit : > Hi, > > 2014-04-05 12:36 GMT+02:00 Martin Landa <[email protected]>: > > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
