WFS pour débutants bis

**cmail** · 04/10/2013, 12h37

Chère Zainab,
Je parlais bien de geoportalMap_simple9.html . et non "...simple8.html"
J'ai toujours en masse des erreurs 404 au chargement dans la console de firebug... Pas vous?

**zainab_k** · 04/10/2013, 14h59

Je me suis trompée, c'est le 9 qui refonctionne...
les erreurs 404 sont dues au fait que la couche carte n'est pas disponible partout.
L'exemple 8 quant à lui montre tout simplement comment charger une couche wfs en utilisant le loader.

**cmail** · 04/10/2013, 15h06

OK pour le 9! pour les 404...
Cependant, il me semble que le rendu de la carte est bizarre (voir entouré rouge de l'image jointe). Non?

**zainab_k** · 04/10/2013, 16h00

Les problème de rendu que vous indiquez sont dus au service WMS et non à l'API:
http://geodesie.ign.fr/cgi-bin/mapse...256&HEIGHT=256

Nous allons les remonter au service concerné.
Merci de nous l'avoir signalé

**cmail** · 08/10/2013, 09h00

Un peu difficile à m'en sortir car j'ai plusieurs interlocuteurs (qui se renvoient la balle!):
La DDT43, lassé, m'a confié aux bons soins de la DREAL Auvergne qui gère le service Prodige Auvergne. Conclusion:
Très surpris que je puisse charger du WFS avec un appel à http://carto.test.prodige-auvergne.fr/cgi-bin/mapserv? alors que pour eux c'est http://carto.test.prodige-auvergne.fr/cgi-bin/mapservwfs? qui doit être sollicité (comme mentionné dans différentes pages de présentation du service). L'API geoportail aurait-elle des propriétés insoupçonnées de hacking?

Devant ces interrogations "métaphysiques", le service carto DREAL Auvergne s'est rapproché de son grand frère plus aguerri le service carto DREAL Rhone-Alpes dont on attend les conclusions....
De mon coté, avec cette nouvelle page d'essai (utilisation basique du loader) j'ai titillé les retours du mapserver Rhone-Alpes...
Résultat: idem!
Connexion sur http://carto.prodige.rhone-alpes.gou...gi-bin/mapservwfs?>>>>Erreur
Connexion sur http://carto.prodige.rhone-alpes.gouv.fr/cgi-bin/mapserv?>>>>Chargement du WFS attendu qui ne devrait pas être délivré!!!!
Et je n'aborde même plus le problème de filtrage!!!!

1/ Est-ce que l'IGN a un expert mapserver qui pourrait clarifier la situation, peut-être en faisant quelques tests directs dont j'ignore tout sur carto.prodige.rhone-alpes.gouv.fr ? Le chargement de wfs à partir d'un appel à mapserv lui parait-il alors normal?
2/ Dans le codage simplissime de ma dernière page de test, y a t-il des erreurs ou des manques qui expliqueraient les erreurs à l'attaque du mapservwfs? Notamment dans les options de la couche wfs, je ne sais pas très bien ce que représente featurePrefix et geometryName, leur utilité et leur nécessité...
3/ Autre piste: le proxy utilisé demande-t-il une adaptation?

**mga_geo** · 08/10/2013, 10h36

Pour moi l'échec sur ta nouvelle page provient de la taille de la réponse du serveur : elle dépasse les capacités d'OpenLayers.
J'ai essayé avec 'ZonehumideRAMSARdeRhoneAlpes' et cela passe !

**cmail** · 08/10/2013, 11h41

avec 'ZonehumideRAMSARdeRhoneAlpes' et cela passe

Cela passe quand on attaque http://carto.prodige.rhone-alpes.gou...i-bin/mapserv? mais pas avec http://carto.prodige.rhone-alpes.gou...gi-bin/mapservwfs? préconisé par les DREAL et qui devrait permettre l'utilisation de filtre...

Certes avec AleasinondationAuvergne, il y a un petit problème de dépassement de taille de chargement mais avec un peu d'attente on obtient bien le wfs en entier mais toujours sur http://carto.prodige.rhone-alpes.gou...i-bin/mapserv? habilité au chargement du wms...

Sinon j'ai appris ce matin que le chef de service DREAL Auvergne, en concertation avec la DREAL Rhone-Alpes, font remonter le problème à leur "correspondant inter-régional". Combien de niveau dans l'expertise????? Après l'inter-région, il y a le national et l'international!!!!

Et coté IGN, quoi de neuf?

**mga_geo** · 08/10/2013, 17h29

Le paramétrage du serveur ne doit pas être correct car sur des requêtes wfs, j'ai des réponses avec une image au format png contenant le message msWMSDispatch() : WMS server error ...

**cmail** · 08/10/2013, 18h47

sur des requêtes wfs

Tu dis bien WFS??
Quelles requêtes? Tout cela pour essayer de transmettre une info étayée aux DREAL....
Merci Marc.

**mga_geo** · 08/10/2013, 20h47

Un service WFS peut être interrogé en POST ou en GET.
C'est lors d'une interrogation en POST que j'ai une image en retour

<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<wfs:Query typeName="ms:SchemasdeCoherenceTerritoriale" xmlns:ms="http://mapserver.gis.umn.edu/mapserver">
<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
<ogc:And>
<ogc:And>
<ogc:PropertyIsLike wildCard="*" singleChar="." escape="!">
<ogc:PropertyName>nom_schema</ogc:PropertyName>
<ogc:Literal>*Allier</ogc:Literal>
</ogc:PropertyIsLike>
</ogc:And>
<ogc:BBOX>
<ogc:PropertyName>msGeometry</ogc:PropertyName>
<gml:Box xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:2154">
<gml:coordinates decimal="." cs="," ts=" ">343480.88069126895,6226517.786573779 1166322.8506132322,6670253.190866038</gml:coordinates>
</gml:Box>
</ogc:BBOX>
</ogc:And>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

**gcebelieu** · 09/10/2013, 22h38

Envoyé par cmail

1/ Est-ce que l'IGN a un expert mapserver qui pourrait clarifier la situation, peut-être en faisant quelques tests directs dont j'ignore tout sur carto.prodige.rhone-alpes.gouv.fr ? Le chargement de wfs à partir d'un appel à mapserv lui parait-il alors normal?
2/ Dans le codage simplissime de ma dernière page de test, y a t-il des erreurs ou des manques qui expliqueraient les erreurs à l'attaque du mapservwfs? Notamment dans les options de la couche wfs, je ne sais pas très bien ce que représente featurePrefix et geometryName, leur utilité et leur nécessité...
3/ Autre piste: le proxy utilisé demande-t-il une adaptation?

Sans être une expert mapserver, mais en attaquant le service WFS à la main et selon le standard, on observe que :

1. la requête GetCapabilities sur l'url ../mapservwfs? retourne un document xml incomplet (interruption brutale en plein milieu du document).

2. pour essayer d'avoir un peu plus d'infos, on fait une requête DescribeFeatureType (pour obtenir une description des features que l'on peut avoir avec le service :

../mapservwfs?request=DescribeFeatureType&service=WFS&version=1.1.0

et on obtient un long document XML avec tout un tas de features que l'on peut interroger, dont voici un extrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  <element name="ForetsrelevantdelagestiondelONFselonregimeforestier" ...
  <element name="UniteterritorialeONF" ...
  <element name="Reservesbiologiquesforestieres_01" ...
  <element name="ContourdelaregionRhone-AlpesGEOFLA®IGN" ...
  <element name="ContourdesarrondissementsdelaregionRhone-AlpesReferentielGEOFLA®IGN" ...
  <element name="ContourdescantonsdelaregionRhone-AlpesReferentielGEOFLA®IGN" ...
  <element name="ContourdescommunesdelaregionRhone- AlpesReferentielGEOFLA®IGN" ...
  <element name="Regionagricole" ...
  <element name="Petiteregionfourragere-Rhone-Alpes" ...
  <element name="Zonesagricolesdefavoriseesinfracommunales-Rhone-Alpes" ...
  <element name="Etablissementsdenseignementagricole-Rhone-Alpes" ...
  <element name="Unitespastorales-Rhone-Alpes" ...
  <element name="PortaildentreedecarriereenAuvergne" ...
  <element name="OuvragesminiersenAuvergne" ...
  <element name="AleasminiersenAuvergne" ... 
 ...

3. Ensuite, j'ai essayé une opération GetFeature (celle qui est faite par l'API pour afficher une couche WFS) avec par exemple "Regionagricole" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<wfs:Query typeName="ms:Regionagricole" xmlns:ms="http://mapserver.gis.umn.edu/mapserver">
<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
<ogc:And>
<ogc:And>
<ogc:PropertyIsLike wildCard="*" singleChar="." escape="!">
<ogc:PropertyName>nom_schema</ogc:PropertyName>
<ogc:Literal>*Allier</ogc:Literal>
</ogc:PropertyIsLike>
</ogc:And>
<ogc:BBOX>
<ogc:PropertyName>msGeometry</ogc:PropertyName>
<gml:Box xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:2154">
<gml:coordinates decimal="." cs="," ts=" ">343480.88069126895,6226517.786573779 1166322.8506132322,6670253.190866038</gml:coordinates>
</gml:Box>
</ogc:BBOX>
</ogc:And>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

et j'ai obtenu des résultats.

Par contre, c'est assez volumineux et lorsque j'essaye la requête avec mon navigateur, celui-ci plante. Du coup, pour afficher ces données avec l'API, il faut zoomer assez fort pour limiter le nombre d'objets retournés.

En conclusion, j'aurais tendance à dire qu'il y a bien un serveur WFS derrière l'url

http://carto.prodige.rhone-alpes.gou...in/mapservwfs?

que ce serveur répond, mais qu'il est peut être mal configuré (cf. le GetCapabilitites incomplet).

Sinon, pour l'attaquer avec l'API Géoportail, c'est un problème récurent avec le WFS : dès qu'il y a beaucoup d'objets retournés ou que ceux-ci ont une géométrie complexe alors, l'affichage est très ralenti, voire impossible... Mais ça, on le savait déjà :

cf. le paragraphe Performances de la page :

http://api.ign.fr/tech-docs-js/fr/we...une_couche_WFS

**EricLebottier** · 10/10/2013, 09h49

Envoyé par gcebelieu

un problème récurent avec le WFS : dès qu'il y a beaucoup d'objets retournés ou que ceux-ci ont une géométrie complexe alors, l'affichage est très ralenti, voire impossible...

Il faudrait peut-être limiter la requête à un nombre d'objet (1000?), coté serveur ou coté client.

**cmail** · 10/10/2013, 10h39

Je fais à peu près les mêmes constats que Gilles.

Et pour limiter le chargement, l'intérêt des filtres malheureusement pas pris en compte, d'où mon courriél à la DREAL Auvergne suivant, avec des demandes peut-être farfelues (?) :

Ainsi sur le mapserver en demo de mapserver.org, la requête suivante :
http://demo.mapserver.org/cgi-bin/wfs?&VERSION=1.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=cities&Filter=%3CFilter%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3EPOPULATION%3C/PropertyName%3E%3CLiteral%3E93840%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E , filtre correctement la couche « cities » sur le champs :<ms: POPULATION>93840</ms: POPULATION>

Par contre sur votre serveur, une requête très similaire, adaptée seulement à vos champs, soit : http://carto.test.prodige-auvergne.fr/cgi-bin/mapserv?&VERSION=1.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=LesCartesCommunalesApprouveese&Filter=%3CFilter%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Einsee%3C/PropertyName%3E%3CLiteral%3E43130%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E qui devrait donc filtrer la couche « LesCartesCommunalesApprouveese » sur le champ :<ms:insee>43130</ms:insee> , renvoie l’erreur suivante :

msWFSGetFeature(): WFS server error. FLTApplyFilterToLayer() failed
msPostGISLayerWhichShapes(): Query error. Error (ERREUR: l'opérateur n'existe pas : character = integer
LINE 1: ...000000,-25000000 -25000000))',2154) and ( ("insee"= 43130) )
^
HINT: Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
) executing query: select "gid","idurba","libelle","typesect","fermreco","destdomi","nomfic","urlfic","insee","datappro","datvalid",encode(AsBinary(force_collection(force_2d("the_geom")),'NDR'),'hex') as geom,"gid" from (select * from n_secteur_cc_043) as foo where the_geom && GeomFromText('POLYGON((-25000000 -25000000,-25000000 25000000,25000000 25000000,25000000 -25000000,-25000000 -25000000))',2154) and ( ("insee"= 43130) )

Ou bien avec mapserverwfs l’erreur est de même nature et est :

msWFSGetFeature(): WFS server error. FLTApplyFilterToLayer() failed
msPostGISLayerWhichShapes(): Query error. Error (ERREUR: l'opérateur n'existe pas : character = integer
LINE 1: ...329 6412244,710392 6412244))',2154) and ( ("insee"= 43130) )
^
HINT: Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
) executing query: select "gid","idurba","libelle","typesect","fermreco","destdomi","nomfic","urlfic","insee","datappro","datvalid",encode(AsBinary(force_collection(force_2d("the_geom")),'NDR'),'hex') as geom,"gid" from (select * from n_secteur_cc_043) as foo where the_geom && GeomFromText('POLYGON((710392 6412244,710392 6479162,811329 6479162,811329 6412244,710392 6412244))',2154) and ( ("insee"= 43130) )

Sauf erreur de ma part que vous voudrez bien alors rectifier, il semblerait que le paramètre <literal> ne soit pas pris en compte par votre service WFS.
Pourriez-vous donc soit l’intégrer dans votre configuration (mapfile ou autre), soit m’indiquer la méthode pour passer outre ?

**mga_geo** · 10/10/2013, 14h02

J'ai une page qui fonctionne avec une couche wfs et une autre couche wfs+filtre sur le serveur de GeoBretagne : http://mga.alwaysdata.net/geoportail...obretagne.html
L'API permet donc bien d'utiliser ce type de service lorsqu'il est bien configuré !

**cmail** · 22/10/2013, 10h45

@Gilles

1. la requête GetCapabilities sur l'url ../mapservwfs? retourne un document xml incomplet (interruption brutale en plein milieu du document).

En effet, et en analysant la chose (enfin!), je m'aperçois que le retour xml bascule en mode erreur sur le premier "é" rencontré dans la séquence "Géolocalisation des stockages de gaz naturels". Cela en wfs 1.1.0.
Par contre en wfs 1.0.0 (donc avec http://carto.test.prodige-auvergne.f...fs?SERVICE=WFS&version=1.0.0&REQUEST=GetCapabilities), il me semble que le retour xml est correct et complet. Non?
Question:
1/ Il n'y a bien que le gestionnaire du mapserver qui peut agir sur l'encodage (actuellement ISO-8859-1 du xml retourné) autorisé? Ou puis-je intervenir dans ma requête envoyé par l'API en paramétrant quelque chose?

Je soupçonne alors que si j'attaque le mapserver en "version=1.0.0" , j'aurai une réponse positive...
Dans :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 wfsLayer = viewer.getMap().addLayer(
    "WFS",
    "WFS DDT43",
    "http://carto.test.prodige-auvergne.fr/cgi-bin/mapservwfs?",
    {
      typename:'LesCartesCommunalesApprouveese'
    },
    {
     protocolOptions:{
        featureNS:'http://mapserver.gis.umn.edu/mapserver',
       version: "1.0.0"
        },

1/ Que représente ce protocolOptions>version? Apparemment ce n'est pas la version du wfs puisqu'avec j'ai toujours l'erreur décrite ci-dessus sur le getcapabilities...

2/ J'essaye bien d'attaquer le service wfs avec cette url bidouillée dans mon addlayer: "http://carto.test.prodige-auvergne.fr/cgi-bin/mapservwfs?SERVICE=WFS&version=1.0.0&", mais si cela supprime bien mon erreur relative aux accents, cela ne semble pas compris par le mapserver puisque je n'ai pas de réponse....

Mes problèmes de filtrage viendront ensuite...

**cmail** · 21/11/2013, 08h29

J'avance lentement dans les dédales de la gestion d'un mapserver par l'administration régionale....

Avec cette page d'essai qui fait appel au service wfs de la DREAL Auvergne de la manière suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  wfsLayer = viewer.getMap().addLayer(
    "WFS",
    "WFS DDT43",
 "http://carto.test.prodige-auvergne.fr/cgi-bin/mapserv?service=wfs&version=1.1.0&request=GetFeature&TYPENAME=LesCartesCommunalesApprouveese",

    {
      typename:'LesCartesCommunalesApprouveese'
    },
    {
     protocolOptions:{
        featureNS:'http://mapserver.gis.umn.edu/mapserver',
       version: "1.0.0"
        },
      projection:'EPSG:2154',
      units:'m',
  //    units:'meters',
      minZoomLevel:8,
      maxZoomLevel:15,
      styleMap:wfsStyleMap,
	//   filter:wfsFilter,
      visibility: true
    }
  );

Ma connexion semble (enfin!) aboutir, par contre la réponse du mapserver est négative (voir pièce jointe).
Je ne doute pas qu’il manque des paramètres (voire une mauvaise syntaxe) mais je n'arrive pas à avoir de retour de l'hébergeur du mapserver. Avez-vous quelques idées?

Quelques remarques qui me laissent perplexe:
En attaque directe dans un navigateur avec http://carto.test.prodige-auvergne.f...lesApprouveese le serveur me retourne : « msWFSDispatch(): WFS server error. WFS Server does not support VERSION 1.1.1. ». Alors qu’avec http://carto.test.prodige-auvergne.f...lesApprouveese le serveur me renvoie bien un fichier de coordonnées.
Fort de ce constat, j’essaye d’attaquer via l’api geoportail en version 1.1.0 (ou même 1.0.0), mais le retour est identique à la pièce jointe. Donc, il n’y a pas qu’une question de version, ou je me perds dans mes réflexions

Deuxième question:
Que représente le paramètre "version" dans "protocolOptions"? Est-ce là que je dois indiquer "1.1.0"?

**cmail** · 17/12/2013, 10h55

Pourrait-on reprendre cette discussion?
1/ En me donnant votre avis sur les différents points évoqués dans ma réponse précédente.

2/ Si la connexion au mapserver de la Dreal Auvergne est maintenant effective (ce que je crois), pourrait-on m'indiquer comment faire pour charger la couche wfs dans l'API? Mes essais demeurent infructueux. D'où viendrait le problème?

WFS pour débutants bis

IGN API Géoportail

Discussions similaires

Partager

Partager