[OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne

Yann Kacenelen ykacenelen at sdis91.fr
Lun 16 Fév 10:49:51 UTC 2015


Bonjour à tous,

Avis aux pressés : message copieux - mais non dénué d'interêts. 

++ Préambule ++
Professionnellement (et succinctement) je suis le responsable de la cartographie opérationnelle pour les sapeurs-pompiers de l'Essonne (Service Départemental d'Incendie et de Secours de l'Essonne ou "SDIS 91"). Personnellement, je suis un très modeste contributeur OSM depuis juin 2011 suite à ma rencontre avec Gaël Musquet.
En octobre de la même année, qq jours avant la création de l'asso OSM FR, je rencontre la communauté OSM au nom du SDIS 91 pour signifier mes velléités de faire du SDIS un contributeur collectif voire un partenaire donc d'une perspective d'apports gagnant-gagnant (données, outils, méthodes). Parmi ces velléités figure en 1ère ligne l'ouverture de nos données SIG via mise à dispo dans OSM. Les données : points d'eau incendie (hydrants), défibrillateurs (en cours de constitution) et nos établissements répertoriés (établissements recevant du public et industriels).
Par ailleurs je suis à l'origine de la traduction française d'OsmHydrant.

Le message ci-dessous est une partie des propos que j'ai déjà échangés récemment avec quelques éminents contributeurs OSM (Vincent, Romain, Pierre, François) qui m'ont orienté vers la liste Talk-FR pour poursuivre nos réflexions et leur mise en oeuvre.

++ Modélisation des PEI (hydrants) ++

Avant de commencer, le terme "hydrant" est un anglicisme, "officiellement" utilisé en BE et CH mais pas en FR même s'il n'y est pas inconnu. On lui préférera celui plus officiel, technique et généraliste de "points d'eau incendie" (PEI) -> cf. un petit laïus http://www.long-tweet.com/t/oBADm.

* Base de données nationale ?
La Défense Extérieure Contre l'Incendie (DECI) est réglementairement sous la responsabilité des maires. Toutefois, sur les questions de maintenance et d'implantation, la réglementation doit être actualisée mais attend de l'être depuis plusieurs années. Les SDIS, principaux utilisateurs des infrastructures et par définition experts en DECI, conseillent les mairies qui suivent ou pas (généralement et pratiquement c'est le cas, mieux vaut pour elles). La gestion des PEI peut en outre être confiée à un gestionnaire privé par DSP, ou assurée par une intercommunalité. Bilan : us et coutumes diffèrent d'un département à l'autre, d'un "territoire" à l'autre, sans cadre réglementaire national. On est assez loin d'une BD nationale et ouverte des PEI sur laquelle certains "fantasment" via Twitter avec le hashtag #BHYNO ;) Mais qui sait, avec un coup "pionnier" et l'effet domino... d'autant que nombreux sont les SDIS sensibles à OSM et favorables à l'ouverture de leur données.

* Numérotation / identifiant :
Les méthodes ne sont pas "normalisées" ni homogènes sur tout le pays. Néanmoins la numérotation la plus courante est celle consistant à concaténer le code INSEE de la commune avec le n° du PEI affecté par la collectivité (commune, interco) ou le gestionnaire de réseaux local en DSP (sté des eaux). Généralement ce numéro est visible car collé sur le PEI et a 4 chiffres car il y a (très très) rarement plus de 9999 PEI dans une même commune. Le problème, au moins rencontré en Essonne, est qu'il peut y avoir plusieurs gestionnaires de réseaux sur une même commune et donc 2 ou plus PEI ayant le même numéro... d'où une numérotation parallèle du SDIS qui utilise souvent la concaténation précitée comme identifiant unique pour ses PEI dans ses bases de données (SIG et Prévision).
Cette numérotation effectivement visible sur les PEI par n'importe qui - dont les mappeurs - peut être consignée dans un tag "ref=*" mais ne peut servir d'identifiant sauf à la coupler avec une emprise géographique (contour de commune) ou la clé "addr:city=*".
Le sujet des identifiants ("ref") est typiquement à traiter, s'il ne l'a pas déjà été par la communauté, dans une perspective d'utilisation professionnelle des données OSM, tant dans l'exploitation que dans la contribution. En effet, les PEI sont utilisés voire géolocalisés essentiellement par les SDIS mais les gestionnaires de réseaux qui en ont la maintenance détiennent également des tableaux voire une couche SIG de ces mêmes objets avec des identifiants différents. Ce sont ces utilisations parallèles et croisées (!) que doit, à mon sens, permettre OSM. D'où ce modèle de clé qui pourrait donner du "ref:FR:SDISxx", du "ref:FR:Lyonnaise", "ref:FR:CommAggloZZ", etc. En actant (si possible) que ces identifiants dans OSM ne soient touchés par qq1 d'autre que les gestionnaires, il serait permis à ces derniers de suivre l'évolution de leurs objets dans OSM et de la comparer avec celle des mêmes objets dans leur base SIG ("conflation").

++ Import or not import ? ++

* Philosophie
Lorsque j'ai "approché" OSM fin 2011, mon intention (modeste ou ambitieuse ?) était de créer une synergie entre cette communauté et ma collectivité voire celles que je pouvais représenter, à savoir les SDIS de France. Hormis d'organiser des cartoparties ou de générer des vocations de mappeurs parmi les sapeurs-pompiers, il était question de verser les données publiques produites par le SDIS 91.
L'import en masse n'est pas en odeur de sainteté chez OSM ou doit apporter une certaine plus-value (cadastre, etc) et être menée avec précaution. En tant que contributeur individuel, je comprends également les rétiscences des mappeurs passionnés qui ne veulent pas voir débouler des flots de données dans OSM sur "leur" zone géographique, comme un cheveu sur la soupe, ces données "désincarnées" ;) dont la qualité peut être difficilement estimable (sur un grand nombre d'objets). Et des données qui retirent en outre une ou plusieurs opportunités de sorties avec son "logger" ou son "smartphone"... ;) Toutefois en tant que contributeur "collectif"/"public", je milite pour une plus forte contribution des services publics, tout comme vraisemblablement certains mappeurs fonctionnaires territoriaux comme moi. Certaines collectivités se focalisent sur l'opendata alors que la contribution OSM, via l'import de données avec l'étape de la concertation avec la communauté, crée du lien. Et du lien, on en a besoin ;) L'intelligent rapprochement d'OSM et de l'IGN va d'ailleurs dans ce sens ainsi que dans celui d'une collaboration où chacun y gagne; la renommée et les intérêts que suscite OSM, dans le monde et en France, auprès du grand public mais aussi voire surtout auprès des professionnels vont grandissants malgré une couverture non homogène des zones à cartographier par les mappeurs; se priver d'apports comme ceux des données SIG des collectivités est à mon sens maladroit, a fortiori si ces contributeurs jouent le jeu de la transparence. Et ce n'est pas retirer du taf aux mappeurs dominicaux que d'intégrer des données exogènes qu'ils pourront bonifier ! Sachant que la microcartographie est aussi une spécificité OSM qui a du présent et de l'avenir, c'est un niveau de détails dans lequel certains mappeurs s'illustrent et trouvent de quoi agrémenter les cartes existantes alors que les collectivités doivent être peu nombreuses à pouvoir s'y impliquer.

* Cas du SDIS 91 (et certainement d'autres collectivités)
Le préalable au versement de données dans OSM est bien entendu l'aval de l'autorité publique, ce qui implique une sensibilisation patiente à ce qu'est OSM et à l'ouverture des données de l'établissement. C'est chose "acquise" au SDIS 91. Se pose alors la question des modalités techniques : 1. modèles de données et 2. outils d'import.

1. Pour ce qui est du modèle : s'il y a de fortes latitudes côté OSM toutefois cadrées par des consensus pour éviter le n'importe quoi, côté SDIS il y a un modèle plus figé car en partie imposé par le système de traitement de l'alerte et par la thématique métier. J'ai effectué en juillet 2014 un travail de rapprochement ("mapping") entre le modèle "SDIS 91" - attributs majoritairement similaires à ceux SDIS des autres départements, à l'intitulé près - et les tags existants dans OSM. En résultent les 2 documents que vous pouvez télécharger via les liens suivants : http://ovh.to/wgcNvmK et http://ovh.to/BhegvK.
L'un fait correspondre les attributs/valeurs principaux et présentant un intérêt pour OSM avec les clés/valeurs en usage; l'autre doc va un peu plus loin dans la caractérisation et la description des PEI dans OSM, a minima dans le cas français. Mon objectif, je le rappelle, est d'inciter mes collègues de SDIS à contribuer à OSM mais aussi, pour cela, à rendre compatible l'usage des données OSM avec les besoins professionnels des SDIS.
N'est pas mentionné dans mon doc le cas particulier des bornes de puisage (vertes) dont il a été question dans certains échanges que j'ai eus sur Twitter et qui n'est pas une infra de lutte contre l'incendie -> la proposition : amenity=hydrant | (hydrant:)type=pillar | (hydrant:)pressure=suction | fee=yes

2. Pour ce qui est des outils : dans la perspective de l'import en masse des 14 600 PEI du SDIS 91 - après avis préalable et favorable de la communauté -, j'ai commencé à travailler avec le plugin ArcGIS Editor for OSM car le SDIS utilise les solutions Esri depuis 1999 et j'envisageais un circuit import/export entre le SIG-SDIS91 et OSM pour suivre les modifications des objets de part et d'autre et les répercuter de part et d'autre. Cet outil permet l'import/export mais mon expérience montre qu'il n'est pas opérationnel pour ce qui est des objets "emergency=fire_hydrant". J'ai eu à personnaliser les scripts Python fournis voire à en créer d'autres pour récupérer l'intégralité des tags notamment. Investissement nécessaire mais souhaitable ?
J'ai lorgné du côté de QGIS. La version 2.6 a certainement ses défauts mais est bluffante. Possibilité de gérer de nbx formats (Esri SHP et Géoconcept étant largement répandus côté SDIS) dont les formats ouverts en export (GeoJSON voire .osm ?). On reste toutefois encore essentiellement dans l'univers SIG.
Une alternative est JOSM. On pénètre un peu plus dans le monde OSM. Expérience personnelle rudimentaire sur ce logiciel. Possibilité de "conflation" et de transformation en masse des attributs/valeurs en clés/valeurs (testé avec C. QUEST). Conservation en l'état ou modification des objets existants dans OSM mais non remplacement systématique par les objets du SIG-SDIS91.
Enfin certains contributeurs m'avaient soufflé l'opportunité d'exploiter Osmose. Bien que non hermétique à la ligne de commande, cet outil me paraît assez touffu et je réserverais donc son utilisation à des experts le cas échéant...

Merci pour votre lecture attentive et vos retours constructifs.
De même que j'attends vos réponses, je suis tout à fait prompt à en apporter à d'autres de vos questions que je suivrai sur la liste.

Cordialement,
---
Yann KACENELEN
Chef du service Cartographie & Information Géographique

Service Départemental d'Incendie et de Secours de l'Essonne (SDIS 91)
Groupement Prévision-Cartographie
114 allée des Champs Elysées - 91080 COURCOURONNES
Tél.: 01 60 91 23 66
Courriél : ykacenelen at sdis91.fr


Respectons l'environnement : n'imprimez ce courriel que si cela est indispensable...
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150216/18825de9/attachment-0001.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/bmp
Taille: 49334 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150216/18825de9/attachment-0001.bin>


Plus d'informations sur la liste de diffusion Talk-fr