il manque juste un pseudo-attribut dans l'élément racine: <WMT_MS_Capabilities version="1.1.1">
changé en: <WMT_MS_Capabilities version="1.1.1" xmlns:inspire_vs="&inspire_vs;" > avec la déclaration de l'entité dans le DTD inclus: <!ENTITY inspire_vs "http://inspire.ec.europa.eu/schemas/inspire_vs/1.0";> On peut aussi combiner sans nécessairement définir cette entité nommée (bien que nommer une entité pour les URI réutilisées partout dans une DTD soit une pratique courante pour l'usage au sein de la DTD, m^me si on ne le fait pas dans le corps du document pour ses éléments): <WMT_MS_Capabilities version="1.1.1" xmlns:inspire_vs=" http://inspire.ec.europa.eu/schemas/inspire_vs/1.0";> En gros c'est du "quasiment" Inspire standard mais il y a des "VendorSpecificCapabilities", essentiellement pour les langues européennes supportées. Un processeur WMS qui ne connait pas ces extensions ne sait pas quoi en faire quand il tombe sur ces éléments ou attributs d'extension utilisant ce préfixe " inspire_vs:". Les autres préfixes "inspire_common:" présents dans les noms d'élements et d'attributs sont déclarés dans la DTD, mais en XML il vaut mieux aussi les déclarer avec un espace de nom XML (qui permet ensuite de se passer de la DTD incluse dans le fichier XML, si le processeur final du fichier WMS connait déjà ce schéma intégré dans la version indiquée par l'URI, au lieu de faite la liaison élément par élément dans leur déclaration de la DTD): <WMT_MS_Capabilities version="1.1.1" xmlns:inspire_vs=" http://inspire.ec.europa.eu/schemas/inspire_vs/1.0"; xmlns:inspire_common=" http://inspire.ec.europa.eu/schemas/inspire_vs/1.0 "> Visiblement un développeur de l'ONF a bidouillé "à la main" l'entête XML de ce fichier qui n'est visiblement pas créé entièrement par un outil automatique, si on regarde simplement l'indentation changeante et inconsistante (qu'un outil automatique n'aurait pas généré comme ça). A la base c'était généré par un outil, mais il y a eu du copier-coller manuel de bouts de code (pour ajouter ces extensions facultatives dans un espace de noms spécifique "inspire_vs", et aussi pour modifier les valeurs des "boundingbox"). On fait ça localement pour du test en développement avec ses outils internes, mais on ne déploie pas ça en prod sans tester la conformité complète et la compatibilité avec les autres outils réutilisateurs, justement dans le cadre ouvert d'Inspire. Le jeu. 23 janv. 2020 à 21:54, Romain MEHUT <romain.me...@gmail.com> a écrit : > Merci Thomas pour l'alternative. > > Je viens d'envoyer un mél à l'ONF en expliquant le problème d'accès et le > souhait que ce soit corrigé. > > Romain > > Le jeu. 23 janv. 2020 à 21:33, Thomas Gratier <osgeo.mailingl...@gmail.com> > a écrit : > >> Salut Romain, >> >> Tu peux tricher avec l'URL suivante >> https://gist.githubusercontent.com/ThomasG77/a1af86730d6b0051d6781199364f2d42/raw/b8064ac7164333d80c31e8d0fe70e0a57bd52c8f/onf-capabilities.xml >> dans la partie "2. Entrer l'URL GetCapabilities" dans la section pour >> l'ajout de couches WMS dans JOSM >> C'est le même contenu que >> http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities >> mais j'ai nettoyé les tags XML et la déclaration liée au namespace inspire >> J'ai vérifié et cela permet de contourner le problème. Pas propre mais >> pas bloqué. >> >> Thomas Gratier >> > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
