Navigation

GML - Geography Markup Language

OGR a une gestion limité pour la lecture et l’écriture du GML. La mise à jour de fichier existant n’est pas géré.

Version de GML gérées :

OGR version Read Write
OGR >= 1.8.0 GML2 et GML3 qui peut être traduit en modèle simple feature GML 2.1.2 ou GML 3 SF-0 (GML 3.1.1 Compliance level SF-0)
OGR < 1.8.0 GML2 et GML3 limité GML 2.1.2

Parseurs

La partie lecture du pilote fonctionne seulement si OGR est compilé avec Xerces. À partir de OGR 1.7.0, quand Xerces n’est pas disponible, la gestion de la lecture fonctionne également si OGR est compilé avec Expat. La validation XML est désactivée par défaut. L’écriture du GML est toujours géré, même sans Xerces ou Expat.

Note

à partir de OGR 1.9.0, si à la fois Xerces et Expat sont disponibles au moment de la compilation, le pilote GML sélectionnera préférentiellement le parseur Expat pour les cas où cela est possible (le fichier GML dans un encodage compatible), et retournera par défaut au parseur Xerces dans les autres cas. Cependant le choix du parseur peut être écrasé en définissant l’option de configuration GML_PARSER à EXPAT or XERCES.

Gestion des SCR

Introduit dans la version OGR: 1.8.0, Le pilote GML gère le système de coordonnées. Cela est seulement reporté quand toutes les géométries d’une couche possèdent un attribut srsName, dont la valeur est identique pour toutes les géométries. Pour les srsName tels que “urn:ogc:def:crs:EPSG:”, pour les systèmes de coordonnées géographiques (comme retourné par les flux WFS 1.1.0 par exemple), l’ordre des axes doit être (latitude, longitude) comme définie par le standards, mais cela n’est pas sans risque, notamment pour les applications qui n’ont pas conscience de l’ordre des axes. Par défaut donc, le pilote inverse les coordonnées pour qu’elles soient dans l’ordre (longitude, latitude) et reporte un SRS sans ordre des axes définie. Il est possible d’obtenir l’ordre original (latitude, longitude) et le SRS avec l’odre des axes en définissant l’option de configuration GML_INVERT_AXIS_ORDER_IF_LAT_LONG à NO.

Il y a aussi des situations où le srsName est de la forme “EPSG:XXXX” (où “urn:ogc:def:crs:EPSG::XXXX” aurait été plus explicite sur l’intention) et les coordonées dans le fichier sont dans l’ordre (latitude, longitude). Par défaut, OGR ne considérera pas l’ordre des axes EPSG et raportera les cooronnées dans l’ordre (latitude,longitude). Cependant, si vous définissez l’option de configuration GML_CONSIDER_EPSG_AS_URN à YES, les règles expliquées dans le paragraphe précédent seront appliquées.

Introduit dans la version OGR: 1.10, ce qui précède s’applique également pour les systèmes de coordonnées projetés dont l’ordre des axes préféré de l’EPSG est (northing, easting).

Schéma

Contrairement à la plupart des lecteurs GML, Le lecteur GML d’OGR ne nécessite pas la présence d’une définition de Schéma XML des classes d’entités (fichier avec l’extension .xsd) pour être capable de lire le fichier GML. Si le fichier .xsd est absent ou si OGR n’est pas capbable de le lire, le pilote tente automatiquement de découvrir les classes d’entités et leurs propriétés associées en sannant le fichier et cherchant des objets gml connus dans l’espace de nom gml pour déterminer l’organisation. Bien que cette approche implique des erreurs, elle a l’avantage de fonctionner pour les fichiers GML même si le schéma associé (.xsd) a été perdu.

Introduit dans la version OGR: 1.10, il est possible de définir un nom de fichier spécifique pour le schéma XSD, en utilisant “un_fichier.gml,xsd=autre_fichier.xsd” comme chaîne de connexion.

La première fois qu’un fichier GML est ouvert, si le fichier .xsd est absent ou ne peut être parsé, il est complètement scanné dans le but d’obtenir l’ensemble des types des entités, les attributs associés pour chacun d’eux et d’autres informations au niveau du jeu de données. Ces informations sont stockées dans un fichier .gfs avec le même nom que le fichier GML cible. Un accès ultérieur au même fichier GML utilisera ce fichier .gfs pour prédéfinir les informations de niveau du jeu de données accélérant son accès. Pour une étendue limité, le fichier .gfs peut être édité manuellement pour modifier la manière dont le fichier GML sera parsé. Mais sachez que le fichier .gfs sera automatiquement régénéré si le .gml associé a un timestamp supérieur.

Lors du pré-scan du fichier GML pour déterminer la liste des types d’objets, et les champs, les contenus des champs sont scannée pour tenter de déterminer le type du champ. Dans certaines applications cela est plus facile si tous les champs sont traité comme des champs de chaines de caractères. Cela peut être réalisé en définissant l’option de configuration GML_FIELDTYPES à la valeur ALWAYS_STRING.

Introduit dans la version GDAL: 1.11, l’option de configuration GML_ATTRIBUTES_TO_OGR_FIELDS peut être définie à YES afin que les attributs des éléments GML soient aussi pris en compte afin de créer les champs OGR.

Les options de configuration peuvent être définie via la fonction CPLSetConfigOption() ou en tant que variable d’environnement.

Application particulière du schéma GML

Introduit dans la version OGR: 1.8.0 ajoute la gestion pour détecter les attributs des feature dans les éléments GML imbriqués (hiérarchie d’attribut non plat) qui peut être trouvé dans certains profiles GML tels que ceux MasterMap de l’Ordnance Survey UK. OGR 1.8.0 apporte également la gestion de la lecture des champs de types IntegerList, RealList et StringList quand un élément GML a plusieurs occurrences.

Depuis OGR 1.8.0, un pilote GML spécialisé - pilote NAS - ALKIS - est disponible pour lire le format d’échange GML AAA allemand (NAS/ALKIS).

Introduit dans la version OGR: 1.8.0, le pilote GML gèer partiellement la lecture des fichiers AIXM ou CityGML files.

Introduit dans la version OGR: 1.11, le pilote GML gère la lecture :

Lecture des géométries

Lors de la lecture d’une feature, le pilote prendra par défaut seulement en compte la dernière géométrie GML reconnu trouvée (dans le cas où il y en a plusieurs) dans le sous arbre XML décrivant la feature.

Introduit dans la version OGR: 1.11, si le schéma .xsd est compris par le lecteur XSD et

qu’il déclare plusieurs champs géométriques, ou que le fichier .gfs déclare plusieurs champs géométriques, les champs géométriques multiples seront reportés parl e pilote GML selon la RFC 41.

Introduit dans la version 1.10: dans le cas où plusieurs occurences de la géométrie apparaissent, si une géométrie est dans un élément <geometry>, celle-ci sera celle sélectionnée. Cela permet un commportement par défaut consistent avec les objets Inspire.

Introduit dans la version OGR: 1.8.0, l’utilisateur peut changer le fichier .gfs pour sélectionner la géométrie appropriée en spécifiant son chemin avec l’élément <GeometryElementPath>. Voyez la description de la syntaxe .gfs plus bas.

Introduit dans la version OGR: 1.8.0 ajoute la gestion de plusieurs géométries GML incluant TopoCurve, TopoSurface, MultiCurve. Le type géométrie GML TopoCurve peut être interprété comme l’un des deux types de géométries. Les éléments Edge interne contiennent des courbes et leurs noeuds correspondants. Par défaut seules les courbes, la géométrie principale, sont retournées comme OGRMultiLineString. Pour récupérer les noeuds, sous forme de OGRMultiPoint, l’option de configuration GML_GET_SECONDARY_GEOM doit être définie à la valeur YES. Lorsque cela est fait seul les géométries secondaires sont renvoyées.

TopoSurface interpretation rules [polygons and internal holes]

Introduit dans la version 1.9.0: le pilote GML est capable de reconaitre deux règles d’interprétations différentes pour TopoSurface quand un polygone contient un anneau interne :

  • La règle d’interprétation précédente assume que :

    • chaque TopoSurface peut être représenté comme une collection de plusieurs Faces

    • les Faces positives [i.e. déclarant orientation=”+”] sont supposées représenter l’anneau Extérieur du polygone.

    • les Faces négatives [i.e. déclarant orientation=”-“] sont supposées

      représenter un anneau Intérieur (aka troue) appartenant au dernier anneau Extérieur.

    • ordonner un Edge utilisé pour représenter chaque anneau (Ring) est important : chaque Edge est censé être exactement adjacent au prochain.

  • La nouvelle règle d’interprétation assume maintenat que :

    • chaque TopoSurface peut être représenté comme une collection de plusieurs Faces
    • l’orientation déclaré pour les Face n’a rien à voir avec les anneaux Extérieur/Intérieur
    • chaque Face a maintenant comme but de représenter un polygone complet, éventuellement en incluant n’importe quel anneau intérieur (troues)
    • l’ordre relatif des segments (Edges) composant la même Face n’est plus pertinent.

L’interpretation la plus récente semble correspondre pleinement aux recommandations du standard GML 3 ; par conséquent cette dernière est maintenant l’interprétation par défaut géré par OGR.

Note

Utiliser l’interprétation la plus récente nécessite que GDAL/OGR soit compilé avec la bibliothèque GEOS.

En utilisant l’option de configuration GML_FACE_HOLE_NEGATIVE vous pouvez sélectionner l’interprétation actuelle afin qu’elle soit appliqué lors de la lecture de la topologie dans GML 3.

  • définir GML_FACE_HOLE_NEGATIVE NO (option par défaut) activera la règle d’interpretation la plus récente.
  • mais définir explictement GML_FACE_HOLE_NEGATIVE YES activera toujours l’ancienne règle d’interprétation.

Problèmes d’encodage

La bibliothèque Expat gère la lecture des encodages internes suivants :

  • US-ASCII
  • UTF-8
  • UTF-16
  • ISO-8859-1

Lorsqu’il est utilisé avec la bibliothèque Expat, OGR 1.8.0 ajoute la gestion de l’encodage Windows-1252 (pour les versions précédentes, modifier l’encodage mentionnée dans l’en-tête XML à ISO-8859-1 peut fonctionner dans certain cas).

Le contenu renvoyé par OGR sera encodé en UTF-8, après la conversion à partir de l’encodage mentionné dans l’en-tête du fichier.

Si le fichier GML n’est pas encodé dans l’un des encodages précédents et que le seul parseur disponible est Expat, il ne sera pas parsé par le pilote GML. Vous pouvez le convertir dans l’un des encodages gérés avec la commande iconv par exemple et changer la valeur du paramètre encoding dans l’en-tête XML en conséquence.

Note

Les fichiers schémas .xsd sont lu avec un lecteur XML intégré qui ne comprend par pour le moment les encodages XML définie dans l’en-tête XML. Il s’attend à ce que l’encodage soit toujours UTF-8. Si les noms d’attributs dans le fichier schéma contiennent des caractères non-ascii, il est conseillé d’utiliser la commande iconv et de convertir le fichier .xsd en UTF-8 d’abord.

Feature id (fid / gml:id)

Introduit dans la version OGR: 1.9.0, le pilote expose le contenu de l’attribut gml:id comme champ de chaîne de caractères appelé gml_id, lors de la lecture des documents GML des WFS. Lors de la création d’un document GML3, si un champ est appelé gml_id, son contenu sera également utilisé pour écrire le contenue de l’attribut gml:id de la feature créée.

Introduit dans la version OGR: 1.9.0, le pilote auto-détecte la présence d’un attribut fid (GML2) (resp. gml:id (GML3)) au début du fichier, et, si présent, l’expose par défaut en tant que champ fid (resp. gml_id). L’auto-détection peut être écrasée en spécifiant l’option de configuration GML_EXPOSE_FID ou GML_EXPOSE_GML_ID à YES ou NO.

Introduit dans la version OGR: 1.9.0, lors de la création d’un document GML2, si un champ est appelé fid, son contenu sera également utilisé pour écrire le contenu de l’attribut fid de la feature créée.

Problèmes de performance avec les gros fichiers GML multi-couches

Il y a seulement un parseur GML par source de données GML partagé entre les différentes couches. Par défaut, le pilote GML recommencera la lecture du début du fichier, chaque fois qu’une couche est accédée pour la première fois, ce qui entraine une perte des performances avec les gros ficheirs GML.

Introduit dans la version OGR: 1.9.0, l’option de configuration GML_READ_MODE peut être définie à SEQUENTIAL_LAYERS si toutes les entités appartenant à la même couche sont écris séquentiellement dans le fichier. Le lecteur évitera alors les resets inutiles lorsque les couches sont lues complètement l’une après l’autre. Pour obtenir les meilleures performances, les couches doivent être lues dans l’ordre où elles apparaissent dans le fichier.

Si aucun fichiers .xsd et .gfs ne sont trouvé, le parseur détectera le layout des couches lors de la construction du fichier .gfs? Si les couches sont définies comme séquentielles, un élement <SequentialLayers>true</SequentialLayers> sera écrit dans le fichier .gfs, afni que le mode GML_READ_MODE soient automatiquement initialisé à MONOBLOCK_LAYERS si non explicitement définie par l’utilisateur.

Introduit dans la version OGR: 1.9.0, L’option de configuration GML_READ_MODE peut être définie à INTERLEAVED_LAYERS pour permettre de lire un fichier GML dont les entités dans différentes couches sont entrelacées. Dans ce cas, la sémantique de la fonction GetNextFeature() sera sensiblement altéré d’une manière à ce que les valeurs NULL ne signifie pas nécessairement que toutes les entités de la couche actuelle doivent être lues, mais cela peut aussi signifieer qu’il y a encore une entité à lire mais qu’elle appartient à une autre couche. Dans ce cas, le fichier doit être lu avec le code de cette façon :

int nLayerCount = poDS->GetLayerCount();
int bFoundFeature;
do
{
    bFoundFeature = FALSE;
    for( int iLayer = 0; iLayer < nLayerCount; iLayer++ )
    {
        OGRLayer   *poLayer = poDS->GetLayer(iLayer);
        OGRFeature *poFeature;
        while((poFeature = poLayer->GetNextFeature()) != NULL)
        {
            bFoundFeature = TRUE;
            poFeature->DumpReadable(stdout, NULL);
            OGRFeature::DestroyFeature(poFeature);
        }
    }
} while (bInterleaved &amp;&amp; bFoundFeature);

Problèmes lors de création

Lors de l’export, toutes les couches sont écrites dans un seul fichier GML dans une seule collection d’objet. Chaque nom de couche est utilisé comme nom d’élément pour les objets à partir de cette couche. Les géométries sont toujours écrites comme un élément ogr:geometryProperty dans l’objet.

Le pilote GML gère en écriture les options de création de jeu de données suivantes :

  • XSISCHEMAURI : si fournit, l’uri sera inséré comme location du schéma. Notez que le fichier schéma n’est pas réellement accédé par OGR, il est du ressort de l’utilisateur de s’assurer que le schéma correspond au fichier données GML produit par GML.

  • XSISCHEMA : peut être EXTERNAL, INTERNAL ou OFF et par défaut à EXTERNAL. Cela écrit un fichier schéma GML vers un fichier .xsd correspondant (avec le même nom). Si INTERNAL est utilisé le schéma est écrit dans le fichier GML, mais cela est expérimental et probablement pas valide XML. OFF désactive la génération du schéma (et est implicite si XSISCHEMAURI est utilisé).

  • PREFIX (OGR >= 1.10) ‘ogr’ par défaut. Ceci est le préfix pour l’espace de nom cible de l’application.

  • STRIP_PREFIX (OGR >= 1.11 FALSE par défauts. Peut être définie à TRUE afin d’éviter l’écriture du préfixe de l’espace de nom cible de l’application dans le fichier GML.

  • TARGET_NAMESPACE (OGR >= 1.10) ‘http://ogr.maptools.org/‘ par défaut. Ceci est l’espace de nom cible de l’application.

  • FORMAT : (OGR >= 1.8.0) peut être définie à

    • GML3 pour écrire des fichiers GML qui suivent le profile GML3 SF-0.
    • GML3Deegree À partir d’OGR 1.9.0 afin de produire un schema .XSD GML 3.1.1, avec quelques variations en respect des recommandations du profile GML3 SF-0, mais cela sera mieux accepté par certains logiciels (comme Deegree 3).
    • GML3.2 À partir d’OGR 1.9.0 dans le but de produire des fichiers GML qui suivent le profile GML 3.2.1 SF-0.

    Autrement GML2 sera utilisé.

    Introduit dans la version OGR: 1.11, les champs de type StringList, RealList ou IntegerList peuvent être écrit. Cela impliquera une alerte dans le profile SF-1 dans le schéma .XSD (ces types ne sont pas géré par SF-0).

  • GML3_LONGSRS=YES/NO : (OGR >= 1.8.0, seulement valide quand FORMAT=GML3) YES par défaut. Si YES, SRS avec l’autorité EPSG sera écrit avec le préfixe “urn:ogc:def:crs:EPSG::”. Dans ce cas, si la projection est une projection géographique sans ordre d’axe explicite, mais avec ce même code d’autorité de la projection importé avec ImportFromEPSGA() doit être traité comme lat/long, alors la fonction prendra soin d’échanger l’ordre des coordonnées. Si définie à NO, la projection avec l’autorité EPSG sera écrit avec le préfixe “EPSG:”, même s’ils sont dans l’ordre lat/long.

  • **WRITE_FEATURE_BOUNDED_BY**=YES/NO. (OGR >= 1.11, valide seulement quand FORMAT=GML3/GML3Degree/GML3.2) Yes par défaut. Si définie à NO, l’élément <gml:boundedBy> ne sera pas écrit pour chaque entités.

  • **SRSDIMENSION_LOC**=POSLIST/GEOMETRY/GEOMETRY,POSLIST. (seulement valide FORMAT=GML3, GDAL >= 2.0) POSLIST par défaut. Pour les géométries 2.5D, définie la localisation où attacher l’attribut srsDimension. Il y a des implémentations divergentes. Certaines le placent dans l’élement <gml:posList>, d’autres en haut de l’élément geomtrie.

  • SPACE_INDENTATION=YES/NO : (OGR >= 1.8.0) YES par défaut. Si YES, la sortie sera indentée avec des espaces pour une meilleure lisibilité, mais avec une augmentation de la taille.

Gestion de l’API de gestion des fichiers virtuels

(Certaines fonctions ci-dessous peuvent nécessiter OGR >= 1.9.0).

Le pilote gère la lecture et l’écriture vers les fichiers gérés par l’API du Système de Fichier Virtual VSI, ce qui inclus les fichiers “normaux” ainsi que les fichiers dans les domaines /vsizip/ (lecture-écriture), /vsigzip/ (lecture-écriture), /vsicurl/ (lecture seule).

L’écriture vers /dev/stdout ou /vsistdout/ est également géré. Notez que dans ce cas, seulement le contenu du fichier GML sera écrit vers la sortie standard (et pas le .xsd). L’élément <boundedBy> ne sera pas écrit. C’est également le cas si vous écrivez vers /vsigzip/.

Syntaxe des fichiers .gfs par l’exemple

Considérons le fichier test.gml suivant :

<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml">
    <gml:featureMember>
        <LAYER>
            <attrib1>attrib1_value</attrib1>
            <attrib2container>
                <attrib2>attrib2_value</attrib2>
            </attrib2container>
            <location1container>
                <location1>
                    <gml:Point><gml:coordinates>3,50</gml:coordinates></gml:Point>
                </location1>
            </location1container>
            <location2>
                <gml:Point><gml:coordinates>2,49</gml:coordinates></gml:Point>
            </location2>
        </LAYER>
    </gml:featureMember>
</gml:FeatureCollection>

et le fichier associé .gfs suivant :

<GMLFeatureClassList>
    <GMLFeatureClass>
        <Name>LAYER</Name>
        <ElementPath>LAYER</ElementPath>
        <GeometryElementPath>location1container|location1</GeometryElementPath>
        <PropertyDefn>
            <Name>attrib1</Name>
            <ElementPath>attrib1</ElementPath>
            <Type>String</Type>
            <Width>13</Width>
        </PropertyDefn>
        <PropertyDefn>
            <Name>attrib2</Name>
            <ElementPath>attrib2container|attrib2</ElementPath>
            <Type>String</Type>
            <Width>13</Width>
        </PropertyDefn>
    </GMLFeatureClass>
</GMLFeatureClassList>

Notez la présence du caractère ‘|’ dans les éléments <ElementPath> et <GeometryElementPath> pour définir l’élément géométrie/champ désiré qui est l’élément XML imbriqué. Les éléments champs imbriqués sont seulement géré à partir d’OGR 1.8.0, ainsi que spécifier <GeometryElementPath>. Si GeometryElementPath n’est pas définie, le pilote GML utilisera le dernier élément géométrie reconnu.

L’élément <GeometryType> peut être définie pour forcer le type de géométrie. Les valeurs acceptées sont : 0 (n’imoprte quel type de géométrie), 1 (point), 2 (linestring), 3 (polygon), 4 (multipoint), 5 (multilinestring), 6 (multipolygon), 7 (geometrycollection).

Introduit dans la version OGR: 1.11, les éléments <GeometryElementPath> et <GeometryType> peuvent être définie autant de fois qu’il y a de champs géométriques dans le le fichier GML. Une autre possibilité est de définir un élément <GeomPropertyDefn> autant de fois que nécessaire : ::

<GMLFeatureClassList>
<GMLFeatureClass>

<Name>LAYER</Name> <ElementPath>LAYER</ElementPath> <GeomPropertyDefn>

<Name>geometry</Name> <– OGR geometry name –> <ElementPath>geometry</ElementPath> <!– XML element name possibly with ‘|’ to specify the path –> <Type>MultiPolygon</Type>

</GeomPropertyDefn> <GeomPropertyDefn>

<Name>referencePoint</Name> <ElementPath>referencePoint</ElementPath> <Type>Point</Type>

</GeomPropertyDefn>

</GMLFeatureClass>

</GMLFeatureClassList>

La sortie de ogrinfo test.gml -ro -al est :

Layer name: LAYER
Geometry: Unknown (any)
Feature Count: 1
Extent: (3.000000, 50.000000) - (3.000000, 50.000000)
Layer SRS WKT:
(unknown)
Geometry Column = location1container|location1
attrib1: String (13.0)
attrib2: String (13.0)
OGRFeature(LAYER):0
    attrib1 (String) = attrib1_value
    attrib2 (String) = attrib2_value
    POINT (3 50)

Syntaxe avancé .gfs (OGR >= 1.11)

Définir ElementPath pour trouver des objets inclus dans les objets de haut niveau

Considérons le fichier test.gml suivant :

<?xml version="1.0" encoding="utf-8"?>
<gml:FeatureCollection xmlns:xlink="http://www.w3.org/1999/xlink"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                      gml:id="foo" xmlns:gml="http://www.opengis.net/gml/3.2">
  <gml:featureMember>
    <TopLevelObject gml:id="TopLevelObject.1">
      <content>
        <Object gml:id="Object.1">
          <geometry>
            <gml:Polygon gml:id="Object.1.Geometry" srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:exterior>
                <gml:LinearRing>
                  <gml:posList srsDimension="2">48 2 49 2 49 3 48 3 48 2</gml:posList>
                </gml:LinearRing>
              </gml:exterior>
            </gml:Polygon>
          </geometry>
          <foo>bar</foo>
        </Object>
      </content>
      <content>
        <Object gml:id="Object.2">
          <geometry>
            <gml:Polygon gml:id="Object.2.Geometry" srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:exterior>
                <gml:LinearRing>
                  <gml:posList srsDimension="2">-48 2 -49 2 -49 3 -48 3 -48 2</gml:posList>
                </gml:LinearRing>
              </gml:exterior>
            </gml:Polygon>
          </geometry>
          <foo>baz</foo>
        </Object>
      </content>
    </TopLevelObject>
  </gml:featureMember>
</gml:FeatureCollection>

Par défaut, seul l’objet TopLevelObject sera reporté et il utilisera seulement la seconde géométrie. Ce n’est pas le comportement désiré dans cette instance. Vous pouvez éditer le fichier .gfs généré et le modifier comme ce qui suit dans le but de définir un chemin complet à l’élément (l’élément XML de haut niveau étant omis) :

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>Object</Name>
    <ElementPath>featureMember|TopLevelObject|content|Object</ElementPath>
    <GeometryType>3</GeometryType>
    <PropertyDefn>
      <Name>foo</Name>
      <ElementPath>foo</ElementPath>
      <Type>String</Type>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

Obtenir des attributs XML en tant que champs OGR

La synthaxe element@attribute peut être utilisé dans <ElementPath> afin de définir que la valeur de l’attribut ‘attribute’ de l’élément ‘element’ doit être récupéré.

Considérons le fichier test.gml suivant :

<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml">
  <gml:featureMember>
    <LAYER>
      <length unit="m">5</length>
    </LAYER>
  </gml:featureMember>
</gml:FeatureCollection>
</pre>

et le fichier .gfs associé.

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>LAYER</Name>
    <ElementPath>LAYER</ElementPath>
    <GeometryType>100</GeometryType> <!-- no geometry -->
    <PropertyDefn>
      <Name>length</Name>
      <ElementPath>length</ElementPath>
      <Type>Real</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>length_unit</Name>
      <ElementPath>length@unit</ElementPath>
      <Type>String</Type>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

La sortie de ogrinfo test.gml -ro -al est :

Layer name: LAYER
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
gml_id: String (0.0)
length: Real (0.0)
length_unit: String (0.0)
OGRFeature(LAYER):0
  gml_id (String) = (null)
  length (Real) = 5
  length_unit (String) = m

Using conditions on XML attributes

Un élément <Condition> peut être définie comme élément enfant d’un élément <PropertyDefn>. Le contenu de l’élément Condition suit une syntaxe XPath minimaliste. Il doit être de la forme @attrname[=|!=]’attrvalue’ [and|or other_cond]*.

Notez que les opérateurs ‘and’ et ‘or’ ne peuvent pas être mélangés (leur précédence n’est pas pris en compte).

Plusieurs éléments <PropertyDefn> peuvent être définies avec le même élément <ElementPath>, mais avec des éléments <Condition> qui peuvent être mutuellement exclusif.

Considérons le fichier testcondition.gml suivant :

<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
    xmlns:ogr="http://ogr.maptools.org/"
    xmlns:gml="http://www.opengis.net/gml">
  <gml:featureMember>
    <ogr:testcondition fid="testcondition.0">
      <ogr:name lang="en">English name</ogr:name>
      <ogr:name lang="fr">Nom francais</ogr:name>
      <ogr:name lang="de">Deutsche name</ogr:name>
    </ogr:testcondition>
  </gml:featureMember>
</ogr:FeatureCollection>

et le fichier .gfs associé.

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>testcondition</Name>
    <ElementPath>testcondition</ElementPath>
    <GeometryType>100</GeometryType>
    <PropertyDefn>
      <Name>name_en</Name>
      <ElementPath>name</ElementPath>
      <Condition>@lang='en'</Condition>
      <Type>String</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_fr</Name>
      <ElementPath>name</ElementPath>
      <Condition>@lang='fr'</Condition>
      <Type>String</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_others_lang</Name>
      <ElementPath>name@lang</ElementPath>
      <Condition>@lang!='en' and @lang!='fr'</Condition>
      <Type>StringList</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_others</Name>
      <ElementPath>name</ElementPath>
      <Condition>@lang!='en' and @lang!='fr'</Condition>
      <Type>StringList</Type>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

La sortie de ogrinfo testcondition.gml -ro -al est :

Layer name: testcondition
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
fid: String (0.0)
name_en: String (0.0)
name_fr: String (0.0)
name_others_lang: StringList (0.0)
name_others: StringList (0.0)
OGRFeature(testcondition):0
  fid (String) = testcondition.0
  name_en (String) = English name
  name_fr (String) = Nom francais
  name_others_lang (StringList) = (1:de)
  name_others (StringList) = (1:Deutsche name)

Registre pour des schémas d’application GML (OGR >= 1.11)

Le répertoire “data” de l’installation de GDAL contient un fichier “gml_registry.xml” qui lie les types d’entités des schémas d’application GML vers les fichiers .xsd ou .gfs qui contienent leur définition. Cela est utilisé dans le cas où des fichiers .gfs ou .xsd invalides sont trouvés à côté du fichier GML.

Une localisation alternative pour le fichier de registre peut être définie en définissant son chemin complet dans l’option de configuration GML_REGISTRY.

Un exemple d’un tel fichier est :

<gml_registry>
    <!-- Finnish National Land Survey cadastral data -->
    <namespace prefix="ktjkiiwfs" uri="http://xml.nls.fi/ktjkiiwfs/2010/02" useGlobalSRSName="true">
        <featureType elementName="KiinteistorajanSijaintitiedot"
                schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/KiinteistorajanSijaintitiedot.xsd"/>
        <featureType elementName="PalstanTunnuspisteenSijaintitiedot"
                schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/palstanTunnuspisteenSijaintitiedot.xsd"/>
        <featureType elementName="RekisteriyksikonTietoja"
                schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/RekisteriyksikonTietoja.xsd"/>
        <featureType elementName="PalstanTietoja"
                schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/PalstanTietoja.xsd"/>
    </namespace>

    <!-- Inspire CadastralParcels schema -->
    <namespace prefix="cp" uri="urn:x-inspire:specification:gmlas:CadastralParcels:3.0" useGlobalSRSName="true">
        <featureType elementName="BasicPropertyUnit"
                    gfsSchemaLocation="inspire_cp_BasicPropertyUnit.gfs"/>
        <featureType elementName="CadastralBoundary"
                    gfsSchemaLocation="inspire_cp_CadastralBoundary.gfs"/>
        <featureType elementName="CadastralParcel"
                    gfsSchemaLocation="inspire_cp_CadastralParcel.gfs"/>
        <featureType elementName="CadastralZoning"
                    gfsSchemaLocation="inspire_cp_CadastralZoning.gfs"/>
    </namespace>
    &lt;!-- Czech RUIAN (VFR) schema (v1) --&gt;
    <namespace prefix="vf"
             uri="urn:cz:isvs:ruian:schemas:VymennyFormatTypy:v1 ../ruian/xsd/vymenny_format/VymennyFormatTypy.xsd"
             useGlobalSRSName="true">
        <featureType elementName="TypSouboru"
                   elementValue="OB"
                   gfsSchemaLocation="ruian_vf_ob_v1.gfs"/>
        <featureType elementName="TypSouboru"
                   elementValue="ST"
                   gfsSchemaLocation="ruian_vf_st_v1.gfs"/>
    </namespace>
</gml_registry>

Les fichiers (.xsd) de définition des schémas XML sont pointé par l’attribut schemaLocation, tandis que les fichiers .gfs d’OGR sont pointés par l’atribut gfsSchemaLocation. Dans les deux cas, le nom du fichier peut être une URL (http://, https://), un nom de fichier absolut absolute, ou un nom de fichier relatif (relatif à l’endroit du fichier gml_registry.xml).

Le schéma est utilisé si et seulement si le préfixe de l’espace de nom et l’URI sont trouvés dans les premiers octets du fichier GML (e.g. xmlns:ktjkiiwfs=”http://xml.nls.fi/ktjkiiwfs/2010/02”), et que le type de l’entité est aussi détecté dans les premiers octets du fichier GML (e.g. ktjkiiwfs:KiinteistorajanSijaintitiedot). Si la valeur de l’élément est définie alors le schéma est utilisé seulement si le type d’entité est trouvé avec la valeur de l’élément dans les premiers octets du fichier GML (e.g. vf:TypSouboru>OB_UKSH).

Construire des tables de jonction

Le script ogr_build_junction_table.py peut être utilisé pour construire une table de jonction à partir des couches OGR qui contient les champs “XXXX_href”.

Considérons la sortie suivante d’un fichier GML avec des liens vers d’autres entités :

OGRFeature(myFeature):1
  gml_id (String) = myFeature.1
  [...]
  otherFeature_href (StringList) = (2:#otherFeature.10,#otherFeature.20)

OGRFeature(myFeature):2
  gml_id (String) = myFeature.2
  [...]
  otherFeature_href (StringList) = (2:#otherFeature.30,#otherFeature.10)

Après avoir lancé ogr2ogr -f PG PG:dbname=mydb my.gml pour l’importer dans PostGIS et python ogr_build_junction_table.py PG:dbname=mydb, une table myfeature_otherfeature sera créé et contiendra le contenu suivant :

myfeature_gml_id otherfeature_gml_id
myFeature.1 otherFeature.10
myFeature.1 otherFeature.20
myFeature.2 otherFeature.30
myFeature.2 otherFeature.10

Exemple

La commande ogr2ogr peut être utilisé pour faire un dump des résultats d’une requête Oracle en GML :

ogr2ogr -f GML output.gml OCI:usr/pwd@db my_feature -where "id = 0"

La commande ogr2ogr peut être utilisé pour faire un dump des résultats d’une requête PostGIS en GML :

ogr2ogr -f GML output.gml PG:'host=myserver dbname=warmerda' -sql
    "SELECT pop_1994 from canada where province_name = 'Alberta'"

Voir aussi

Crédits

  • Implémentation pour GML_SKIP_RESOLVE_ELEMS HUGE a été une contribution de A.Furieri, financé par la Région Toscane.
  • La gestion pour les données cadastrale dans les GML du Finnish National Land Survey et GML Inspire a été financé par The Information Centre of the Ministry of Agriculture and Forestry (Tike)

Table des Matières

Sujet précédent

GFT - Google Fusion Tables

Sujet suivant

GMT ASCII Vectors (.gmt)

Cette page

Navigation

Créé avec Sphinx 1.2.2.