Par défaut tous les chemins fermés (ways ou collections de ways
membres d'une même relation) sont interprétés comme des surfaces, sauf
si le type d'objet désigne une route/rue/sentier (highway=*) ou une
ligne de chemin de fer (railway=*), ou une ligne de transport en
général (type=route, que ce soit pour des bus, des taxis, des
sentiers), ou les lignes électriques.
Ce sont ces lignes de transports qui seules nécessitent area=yes si on
veut que ça désigne toute la surface délimitée par ce chemin (le plus
souvent on le trouve pour les places et secteurs piétonniers), et pas
seulement une zone tampon ("buffer") située de part et d'autre du
chemin (la largeur de ce chemin est souvent implicitement estimée mais
ignorée dans le rendu qui peut tracer la ligne avec une épaisseur plus
grande comparaitivement à l'échelle; l'estimation de largeur de la
zone tampon est dépendante du moteur de rendu, mais on peut l'etimer à
3 mètres de part et d'autre, ou tenir compte d'autres attributs comme
l'indication du nombre de voies de circulation, ou utiliser
l'indication de la largeur avec width=* qui est rarement employé car
souvent pas homogène sur la longueur du chemin dont on n'a tracé
qu'une ligne centrale souvent suffisante pour la plupart des rendus
aux échelles courantes).
En pratique malgré tout, même les rues ou routes ont une largeur qui
devrait pouvoir être cartographiée pour préciser la disposition des
voies, des trottoirs, bandes cyclables, voies bus, zones de
stationnement, ilots directionnels et positionner divers équipements
plus précisément. Et de fait presque tout devrait devenir des surfaces
à terme. Mais le travail de cartographie est plus long et plus
compliqué pour ces objets qui sont nettement plus longs que leur
largeur. On peut regretter toutefois que les moteurs de routage (pour
calculer un itinéraire) se débrouillent très mal avec les surfaces
(ils ne savent pas comment interconnecter correctement une surface
avec un chemin) et nécessitent de tracer malgré tout au moins une
ligne centrale en plus de cette surface et il n'y a pas encore de
modèle stable pour avoir les deux.
En principe on devrait pouvoir déduire automatiquement la géométrie de
cette ligne centrale virtuelle à partir de la géométrie de la surface
délimitée mais le calcul géométrique est un peu compliqué et trop
lourd pour nombre de petits appareils portables ou mobiles. La
solution serait de pouvoir préparer les données selon le dispositif
afin de leur faire satisfaire certaines contraintes, mais à l'heure
actuelle cela ne semble pas encore marcher avec les outils d'exports
et préparation de données. Donc en fin de compte on utilise des routes
tracées avec un seul trait, le moteur de rendu utilise une largeur un
peu arbitraire pour le rendu de l'épaisseur du tracé afin de ne pas
couvrir une surface trop grande ni trop petite relative à l'échelle de
rendu.
Mais si la capacité de calcul des appareils de navigation s'améliore
(par exemple avec un rendu 3D montrant les bâtiments autour, le
relief, et divers équipement ou même des façades de commerce et les
trottoirs et toutes les voies), la donnée de la seule ligne centrale
virtuelle pourra devenir insuffisante pour faire de la navigation avec
une indication précise des voies de circulation qui ne recouvrent pas
ce qui est à afficher autour. Le modèle actuel est plutpot adapté à
un rendu sous forme de plan en projection vu de dessus et ne montrant
au mieux une précision décamétrique. Pour la précision métrique ou
décimétrique la modélisation (ou l'approximation par estimation des
largeurs de "buffer" prenant en compte d'autres attributs) des routes
par surfaces d'occupation pourrait devenir nécessaire.
On n'en est pas encore là mais le besoin se fait de plus en plus
sentir dans les zones urbaines denses avec une navigation compliquée,
où l'estimation des largeurs de "buffer" ne suffit plus à préciser
correctement les positions relatives des divers objets à représenter.
Pour le reste (hors des voies et lignes de transport), area=no ne
semble pour l'instant servir à rien de connu, et area=yes est alors
inutile puisque c'est l'interprétation par défaut (bâtiments, et même
les murs, frontières administratives ou physiques, parcs et jardins,
zones de culture, forêts, eaux). Il doit y avoir des exceptions par
endroit pour certains tags peu employés (par exemple les pipelines).
Et plutôt que d'avoir à maintenir une liste de plus en plus longue
d'exceptions (et pas facile à mettre à jour car l'information est
disséminée et on pourrait trouver des cas contradictoires) c'est vrai
que la séparation des types géométriques serait bienvenue pour lever
cette ambiguïté de façon plus propre.
En attendant c'est à ça que doit servir l'attribut area=yes/no, mais
cela ne facilite pas la validation automatique de la géométrie des
objets et on doit alors utiliser des outils externes de surveillance
de la qualité (par exemple Osmose) pour trouver ces ambiguïtés ou
possibles anomalies liées le plus souvent à des données incomplètes ou
devenues incomplètes suite à certaines modifications :
* Par exemple quand un chemin est coupé en deux ou deux chemins sont
fusionnés, mais que le nouveau morceau n'est pas mis à jour
simultanément dans toutes les relations qui ont ce nouveau en membre
(ce qui arrive assez souvent car on ne charge pas toujours assez de
données pour trouver les dépendances et parce que la base de données
ne retourne pas toujours la liste exhaustive de ces dépendances quand
on charge pour le modifier un chemin ou même un seul noeud, même en
téléchargeant tous les objets dans un rectangle car un chemin peut y
passer sans qu'on le voit dans ce rectangle, ou parce qu'il peut aussi
en déborder avec une partie seulement de ses noeuds dans le
rectangle).
* Un jour ou l'autre il va bien falloir que la base de données
permette de charger directement la liste exhaustive des objets qui
référencent un objet donné (même si ces objets référents ne sont pas
chargés en totalité), sans avoir besoin de chercher autour par une
requête de type purement géométrique (qui a le défaut de télécharger
trop d'objets autour qui ne référencent pourtant pas l'objet demandé),
afin d'éviter ces oublis lors des modifications mais aussi économiser
des tonnes de requêtes infructueuses. Cela arrivera avant
l'introduction d'un type géométrique séparé pour les surfaces.
Cette particularité des données OSM qui confonds lignes et surfaces
par une détermination automatique et un peu informelle constitue
pourtant une difficulté sérieuse (qui doit être prise en compte dans
les outils d'exportations (utilisés par les moteurs de rendu) tels que
osm2pgspl, et qui utilisent pour la plupart une modélisation GIS plus
standard.
Ce sont ces outils de transformation automatique qui justement
cherchent à résoudre les ambiguïtés et permettent de les lister dans
un rendu d'analyse (par exemple Osmose). Jusqu'à présent cela suffit
mais c'est dommage de faire ça en deux étapes (d'autant plus que ces
étapes sont séparées dans le temps), car il n'est as toujours facile
de réparer une géométrie cassée le plus souvent de façon totalement
involontaire (surtout si cela nécessite de restaurer des objets
fusionnés ou supprimés à tord ou de façon incohérente entre plusieurs
modifications de nature différente).
Le 26 juillet 2012 11:13, Ab_fab <gamma....@gmail.com> a écrit :
> Ah, sauf si c'est implicite avec le tag amenity=school comme le dit Vincent
>
> Le 26 juillet 2012 11:11, Ab_fab <gamma....@gmail.com> a écrit :
>
>> Si si, il fallait bien !
>>
>> Le 26 juillet 2012 10:53, Francescu GAROBY <windu...@gmail.com> a écrit :
>>
>>> OK, merci pour vos explications.
>>> Et oui, c'est moi qui ai ajouté le tag "area". Fallait pas ?
>>>
>>> Francescu
>>>
>>> Le 26 juillet 2012 10:47, Ab_fab <gamma....@gmail.com> a écrit :
>>>
>>>> Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
>>>> l'introduire si l'API évolue.
>>>> Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
>>>> incluent des tags supplémentaires tels que "area = yes", quand cela n'est
>>>> pas déjà sous-entendu par le tag principal comme "building = yes", pour
>>>> indiquer qu'il s'agit de surfaces
>>>>
>>>> A ce propos, est-ce toi qui a ajouté le "area = yes" dans la dernière
>>>> révision de l'objet le 24/07 ?
>>>>
>>>> Le 26 juillet 2012 07:53, Francescu GAROBY <windu...@gmail.com> a écrit
>>>> :
>>>>>
>>>>> Bonjour,
>>>>> En tagguant les établissement scolaires de ma commune, j'ai eu la
>>>>> surprise de m'apercevoir que certains bâtiments, déjà identifiés depuis
>>>>> plusieurs mois, avaient été représentés non pas par une area mais par un
>>>>> way
>>>>> ! Ex : http://www.openstreetmap.org/browse/way/149706281/history
>>>>>
>>>>> Mes questions sont donc les suivantes :
>>>>> * sachant que la page du wiki portant sur le tag "amenity=school"
>>>>> indique bien que cela ne peut se faire que sur un node ou une area, est-il
>>>>> possible de transformer ces ways en areas, sans avoir à tout retracer ?
>>>>> * ne faudrait-il pas que ce genre de vérifications, somme toute assez
>>>>> faciles, soient effectuées au moment de la validation des modifications ?
>>>>> Soit en renvoyant un message d'erreur et en refusant l'update des données,
>>>>> soit (mais je suis moins emballé) en remplaçant automatiquement le way par
>>>>> un area ?
>>>>>
>>>>> --
>>>>> Cordialement,
>>>>> Francescu GAROBY
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-fr mailing list
>>>>> Talk-fr@openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ab_fab
>>>> "Il n'y a pas de pas perdus"
>>>>
>>>> _______________________________________________
>>>> Talk-fr mailing list
>>>> Talk-fr@openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>
>>>
>>>
>>> --
>>> Cordialement,
>>> Francescu GAROBY
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>> ab_fab
>> "Il n'y a pas de pas perdus"
>
>
>
>
> --
> ab_fab
> "Il n'y a pas de pas perdus"
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
