[OSM-talk-fr] Mapping d'intérieur

[Vincent de Chateau-Thierry]

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