Closed arx-it closed 8 years ago
L’export GML n’export pour l’instant qu’un fichier GML par couche, je vais devoir les fusionner, cette fonction n’est pas présente pour l’instant dans Staging de la livraison 2
Je n'ai pas le bouton export, est-ce normal? (Donc je n'arrive même pas à tester l'export "par couche")
Oui c'est normal, je ne l'ai pas mis en Staging pour l'instant, puisque qu'a priori ca ne passera pas votre checker. Mais je peux la pousser quand même d'ici midi si vous voulez tester.
ce serait bien pour se faire une idée
2015-10-26 9:45 GMT+01:00 arx-it notifications@github.com:
Oui c'est normal, je ne l'ai pas mis en Staging pour l'instant, puisque qu'a priori ca ne passera pas votre checker. Mais je peux la pousser quand même d'ici midi si vous voulez tester.
— Reply to this email directly or view it on GitHub https://github.com/Geoportail-Luxembourg/qgis-pag-plugin/issues/7#issuecomment-151063167 .
Jeff Konnen
Très bien, je vais l'intégrer dans la matinée
C'est poussé en staging, donc un GML par couche pour l'instant
OK, j'ai testé. Il y a un GML par couche, mais ce n'est pas le problème principal. Le GML généré ne correspond pas du tout à notre XSD. C'est l'utilisation de l'export standard XSD de QGIS qui fait ceci. Ce n'est pas le bon namespace etc..
Voici deux fois le même feature:
(ce qu'on importe):
<member>
<ZONAGE id="x526535b4-3dde-4128-aba2-ce7017aa840f">
<CATEGORIE>AGR</CATEGORIE>
<NOM_FICHIER>078_PE_AGR</NOM_FICHIER>
<GEOMETRIE>
<Polygon id="iox22904" srsName="urn:ogc:def:crs:EPSG:2169">
<exterior>
<Ring>
<curveMember>
<Curve id="iox22905">
<segments>
<LineStringSegment interpolation="linear">
<posList>107730.23960000093 58782.83949953856 107726.83960000059 58774.61949954043 107733.78969999969 58771.88949953922 107736.62959999965 58779.9694995399 107730.23960000093 58782.83949953856</posList>
</LineStringSegment>
</segments>
</Curve>
</curveMember>
</Ring>
</exterior>
</Polygon>
</GEOMETRIE>
</ZONAGE>
</member>
<featureMember>
<PAG fid="PAG.0">
<geometryProperty>
<Polygon srsName="EPSG:2169">
<outerBoundaryIs>
<LinearRing>
<coordinates>58782.839499538560631,107730.239600000917562 58774.619499540429388,107726.839600000603241 58771.889499539218377,107733.789699999673758 58779.969499539896788,107736.629599999636412 58782.839499538560631,107730.239600000917562</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</geometryProperty>
<OGC_FID>1</OGC_FID>
<CATEGORIE>AGR</CATEGORIE>
<NOM_FICHIER>078_PE_AGR</NOM_FICHIER>
</PAG>
</featureMember>
On voit notamment que la géométrie n'est pas encodée de la même manière. Si la manière d'encoder les coordonnées à l'intérieur du polygone ne doit pas nécessairement être la même, il faut quand même faire attention au SRS et à l'ordre des axes. L'ordre des axes n'est pas le même, afin d'éviter les incompatbilités entre différents programmes il faut utiliser urn:ogc:def:crs:EPSG:2169, où l'ordre est N,E et pas E,N)
D'ailleurs, même si le système annonce "importation was successful", on n'arrive pas à importer le fichier exporté avec l'application.
Oui bien sûr, la sortie du driver OGR n'est pas conforme au XSD, je vais de toute façon devoir l'adapter.
GML fusionné semble conforme au XSD, réimporté avec succès
testé, le fichier a l'air OK dans QGIS et FME; par contre il ne passe pas une validation contre le XSD.
Il s'agit notamment des tags "OGC_FID" qui font partie du fichier mais qui ne sont pas définis dans le schéma
(testé avec un xmlvalidator dans FME)
Effectivement, il exporte la PK de la BD Spatialite, je vais le supprimer
Le champ OGC_FID n'est plus dans le GML de sortie
Les fichiers ne passent toujours pas la validation xsd.
Les attributs ne viennent pas dans le bon ordre.
p.ex:
dans le schéma XSD les attributs sont définis comme séquence ce qui fait que leur ordre est important
<xsd:complexType name="PAP_APPROUVEType">
<xsd:complexContent>
<xsd:extension base="gml:AbstractFeatureType">
<xsd:sequence>
<xsd:element name="NOM_FICHIER_EC" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:normalizedString">
<xsd:maxLength value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="NOM_FICHIER_GR" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:normalizedString">
<xsd:maxLength value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="GEOMETRIE" type="gml:SurfacePropertyType">
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<PAP_APPROUVE gml:id="x80d2d3a4-0391-4163-9453-f80c7b5d240d"><NOM_FICHIER_EC>022_PAP_PE_17139</NOM_FICHIER_EC><GEOMETRIE>..</GEOMETRIE></PAP_APPROUVE>
<PAP_APPROUVE gml:id="PAP_APPROUVE.22">
<GEOMETRIE>..</GEOMETRIE>
<NOM_FICHIER_EC>022_PAP_PE_17139</NOM_FICHIER_EC>
</PAP_APPROUVE>
OK, l'ordre est respecté, en fait c'était le champ GEOMETRIE qui était toujours en premier, car il est créé en premier dans la BD Spatialite.
OK pour l'ordre. Reste cette erreur ci (4 fois dans un fichier): value '76b512cf-7eef-11e5-bea8-00505684014b' is invalid NCName' (NCName doit commencer par une lettre, c'est pourquoi dans l'export FME que j'utilise, l'outil préfixe les UUID qui commencent par un chiffre avec un x
Avec ces 4x, le fichier passe la validation
OK, je vais rajouter un x alors
x ajouté à tous les gml:id
Export du projet dans un fichier GML conforme au schema GML