Bonsoir,
Le 21/06/2011 15:44, Jean Millerat a écrit :
Le 21/06/2011 12:28, kimaidou a écrit :
JE suis complètement d'accord avec Pieren. Il va être très difficile de
gérer la modification et l'affichage des données OSM sur plusieurs
niveaux d'un bâtiment.
Pour moi, c'est ici que le côté libre d'OSM prend toute sa force : rien
n'empêche de créer une infrastructure similaire à OSM pour y mettre les
données d'intérieur. Ensuite il faudra bien sûr gérer le lien entre les
2, mais pourquoi pas ? Rien n'empêcherait par exemple une application de
routing d'utiliser les données OSM pour l'extérieur, et pour la
navigation dans le bâtiment, d'utilser les données de "OSM_indoor", bdd
dédiée à l'intérieur. On pourrait aussi très bien avoir un éditeur pour
les données d'intérieur qui intègre en fond les données OSM (pou le
repérage), et propose des fonctions pour vérifier les liens entre les 2
(par exemple l'osm_id du building OSM est bien présent dans le tag
"from_osm" des objets la bdd dédiée intérieur..
Je comprends bien que les moteurs de rendus actuels ne sont pas conçus
pour rendre du multi-niveaux. Et que les éditeurs non plus. Et qu'on n'a
pas de GPS pour se rassurer. Et qu'à ce niveau de détail, il faudra
attendre d'avoir 3 millions de contributeurs pour avoir une bonne
couverture...
Mais, pour me faire l'avocat du diable, la base de données et son
infrastructure me semblent très bien convenir pour l'intérieur et la
faible quantité de données d'intérieur ne me semble pas risquer de
pourrir les performances de l'usage habituel d'OSM. Quant au reste :
- pour les moteurs de rendus classiques : "yaka" leur demander d'ignorer
tout ce qui est indoor=yes et laisser ce job à des moteurs de rendus
conçus pour l'intérieur
- pour les éditeurs, c'est plus compliqué : ce qui pourrait être sympa,
c'est de pouvoir aussi filtrer facilement à l'affichage ce qui est
indoor=yes/no puis pouvoir filtrer ce qui est level=1/2/3... pour
n'afficher qu'un seul niveau ; une boîte de dialogue "filtres de
données" dans le menu affichage de JOSM...
+1
Si vous avez sous la main des threads récents qui font le point sur
cette controverse sur la liste OSM, je suis preneur (par curiosité et
pour mieux comprendre).
Je pense de mon côté que les données d'intérieur et/ou 3D, dès lors
qu'on parle d'accès public (hall de gare, galerie commerçante, monument)
ont toute leur place dans OSM, et non à côté. Qu'on se sente démuni pour
l'instant pour les mapper, c'est un fait : je ne connais pas d'éditeur
qui permette de distinguer les layers. Tant qu'on aura comme "outils" le
tag layer et des éditeurs qui considèrent comme une erreur la
superposition de 2 nodes, on ne fera pas de miracles en saisie 3D.
Comme facteurs limitants, je vois plus les éditeurs et le jeu de tags
actuels (les deux sont liés), que la légitimité de ces données. Ça n'est
pas parce que le CNIT et un réseau de fibre optique ont en commun le
besoin d'être modélisés en 3D, qu'ils ont en commun de ne pas devoir
être dans OSM. On parle dans un cas d'un réseau invisible pour le
piéton, et dans l'autre d'un espace public. C'est à ce dernier titre que
je trouve légitime de mettre certains espaces indoor et/ou 3D dans OSM.
Le jour où on saura sans s'arracher les cheveux mapper les différents
étages de la Tour Eiffel, les ascenseurs et les escaliers, ce sera bon
signe :-)
vincent
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
