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?
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?
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.
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?
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é
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?
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 !
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...avec 'ZonehumideRAMSARdeRhoneAlpes' et cela passe
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?
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 ...
Tu dis bien WFS??sur des requêtes wfs
Quelles requêtes? Tout cela pour essayer de transmettre une info étayée aux DREAL....
Merci Marc.
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>
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" :
et j'ai obtenu des résultats.
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>
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
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 ?
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é !
@Gilles
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.1. la requête GetCapabilities sur l'url ../mapservwfs? retourne un document xml incomplet (interruption brutale en plein milieu du document).
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 :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...
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" },
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...
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:
Ma connexion semble (enfin!) aboutir, par contre la réponse du mapserver est négative (voir pièce jointe).
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 } );
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"?
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?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager