Echirolles/Suivi stationnement
Présentation générale
Après avoir commencé un travail sur le suivi des arbres, la Ville d'Échirolles souhaite aussi mettre en place un dispositif de suivi du stationnement pour qu'à plus long terme il soit possible de suivre dans le temps l'évolution de l'offre de stationnement et l'impact de son emprise foncière, en particulier sur l'espace public.
La finalité de ce travail est d'offrir au service de l'aménagement un outil d'aide à la décision pour sensibiliser et guider les élu-es sur un sujet souvent complexe à étudier.
Un travail d'inventaire avant tout...
Il s'agit avant tout de faire un inventaire des places existantes pour être en mesure de quantifier l'offre de stationnement et de sortir quelques chiffres-clés permettant de nourrir la réflexion. Aujourd'hui, la base de données dont nous disposons est assez précise géométriquement mais pas forcément à jour : elle est issue de notre référentiel topographique mais n'est plus alimentée correctement depuis plusieurs années en raison de l'absence de marché de mise à jour des données topographiques.
Il existe donc des zones où les données sont obsolètes, en particulier sur les secteurs d'aménagements récents. Et ils sont plusieurs dans ce cas ! la Ville d'Échirolles est une ville urbaine où de nombreux projets urbains sont en cours. Les données provenant d'OpenStreetMap peuvent être un moyen de consolider cette base de données, et dans le même temps une opportunité de reverser ce qui n'y apparaît pas.
... Et des adaptations à proposer sur le plan méthodologique...
parking=surface dans OpenStreetMap (en vert)Sur l'emprise
La précision géométrique des données de notre base historique n'est pas toujours pertinente, notamment sur la question de l'emprise.
En effet, il est préférable de délimiter prioritairement un parking de surface en prenant en compte les allées de parking qui lui sont dédiées, plutôt que les emplacements de parkings seuls (amenity=parking_space). L'idéal serait de prendre en compte les deux, mais le travail est colossal !
La donnée provenant d'OpenStreetMap est donc parfois plus pertinente car elle est souvent numérisée de cette manière.
Sur la nature géométrique en fonction de l'usage
L'autre enjeu, c'est de pouvoir dissocier l'emprise des parkings et qualifier leur usage, plus précisément lorsqu'il s'agit de places réservées définies par un arrêté de voirie.
Le choix méthodologique proposé consiste à rattacher cette information à des objets ponctuels qui vont venir se superposer aux emprises.
Les raisons et avantages d'opter pour ce choix :
- La numérisation est simple car numériser une place de stationnement par un point est beaucoup plus simple que par un polygone
- Cela reste efficace et lisible d'un point de vue cartographique
- Cela reste conforme aux exigences des règles sémiologiques préconisées par la communauté OpenStreetMap
- Et plus spécifiquement pour Échirolles, l'information ponctuelle peut être remontée au niveau surfacique par simple croisement spatial
S'il fallait numériser les emprises de places réservées, cela rajoute encore plus de 700 objets actuellement identifiés sur notre territoire (!). Ce niveau de détail n'est pas encore atteignable pour le moment...
... Pour obtenir un référentiel synchronisé avec OpenStreetMap
Un jeu subtil d'hybridation est donc nécessaire pour fusionner les données OSM avec la base de données historique : il faut pouvoir prendre le meilleur des deux, c'est à dire aller au plus simple géométriquement pour les grands parkings de surface et aller plus dans la précision si l'occasion se présente, notamment les cas de parking de voirie (parking=street_side) qui sont parfois entrecoupés de massifs fleuris ou d'espaces de circulation piétonniers.
La plupart du temps, un contributeur dessine l'emprise de façon simplifiée tandis qu'une donnée topographique propose une géométrie beaucoup plus fine comme les limites des massifs fleuris. Qui par conséquent la rend plus intéressante.
Processus du cycle de vie des données
Le processus reprend le même paradigme que celui expliqué dans le cas du référentiel des arbres.
L'enjeu technique du téléversement d'objets surfaciques dans OSM
Contrairement au référentiel des arbres, il faut pouvoir être ici capable de téléverser des objets surfaciques d'une base de données qui ont déjà une existence dans OpenStreetMap . En somme, reverser une nouvelle version en améliorant leur géométrie et éventuellement enrichir leurs tags.
Dans le cas des arbres, le script python est relativement "simple", du moins pour la génération des coordonnées de chaque objet qui ne comporte qu'un nœud. Pour un objet surfacique, c'est plus compliqué puisque le format OSM est défini de la manière suivante :
- Tous les nœuds des polygones sont listés avec leur coordonnées XY et un identifiant leur est affecté
- Chaque polygone est listé avec la liste des nœuds à partir de leur identifiant
Le script python de conversion devient ici plus complexe...