[OSM-talk-fr] intégration des référentiels STIF

[Florian LAINEZ]

Hello,

Si on veut gérer la transition, il faut décider vers lequel de "platform"
> ou "stop_position" on doit basculer les "bus_stop" actuels. En majorité les
> "bus_stop" ont été mis sur ce qui devrait être des "plateform" en v2 (c'est
> à dire à côté des chemins de la relation "route"). Mais si on tague les 2
> ("platform" + "stop_position" ) en v2
>

Nous n'avons pas à décider, le modèle V2 a été créé en tant que tel sans
rétro-compatibilité, ce qui veut bien dire ce que ça veut dire. Chaque
amenity=bus_stop doit être complété ou remplacé à la mano par un platform
ou un stop_position.


>
> Et si on veut être compatible avec sketchline, les "bus_stop" devraient
> être déplacés vers les nouveaux noeuds "stop_position".
>

Je n'ai pas de préférence ni d'avis sur le sujet mais je pense qu'il vaut
mieux laisser un seul bus_stop par arrêt effectif.
Jusqu'à présent je laisse bus_stop sur la platform par habitude. Mais plus
ça va plus je pense que je vais me radicaliser et virer totalement le
modèle V1 là où je passe, quitte à impacter le rendu Mapnik.


>    - Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
>    (2504515) <https://www.openstreetmap.org/relation/2504515>
>    et fait partie de :
>    - Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
>    (2504515) <https://www.openstreetmap.org/relation/2504515>
>
> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
> Retrouver la relation maîtresse ?
>
C'est en effet une erreur que j'ai maintenant corrigée, merci.
ça confirme notre besoin d'un outil plus adapté pour faire ce boulot sans
erreur. J'ai un projet qui n'attend qu'à être lancé pour y parvenir ...
#WaitForIt

Le 13 décembre 2016 à 22:38, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> effectivement, les membres de relations ne devraient pas se lier l'un à
> l'autre, ce devrait être des parentés strictes dans une hiérarchie, donc
> sans boucle.
>
> Il y a cependant quelques cas où de telles boucles existent entre
> relations (mais pour des rôles différents), notamment pour les "default"
> values applicables à une région.
>
> Pour de tels cas, JOSM a inclus il y a maintenant près de 3 ans un "fix"
> lui évitant de créer une boucle infinie lors de l'énumération récursive des
> membres enfants: il détecte tout cas de retour d'un descendant vers un des
> ancêtres déjà en cours d'énumération et dans ce cas n'ira pas parcourir ce
> lien "descendant" qui en fait revient à un ascendant. Il utilise pour cela
> une simple pile, en empilant l'objet dont on va énumérer les enfants, puis
> en parcourant chacun les enfants (sans rien faire s'ils sont déjà présents
> quelque part dans la pile), puis une fois parcourus tous les enfants en
> dépilant le premier objet parent.
>
> C'est un garde-fou simple à implémenter (la pile est en fait non ordonnée,
> c'est une simple collection indexée par référence d'objet, l'index pouvant
> être très efficace si c'est une simple "hashtable"; de plus il ne sera
> jamais très grand car limité en taille à la longueur maximale de parcours
> hiérarchique d'un ancêtre vers le dernier de ses descendants, qui ne va
> jamais au delà d'un poignée: les parcours d'arbres de relation sont en fait
> beaucoup plus "larges" que "hauts" avec souvent beaucoup de membres dans
> une relation mais peu de niveaux de relations, je n'ai pas vu un seul cas
> où la profondeur atteint ou dépasse 16): si jamais on tombe sur un cas où
> en enfant est présent à la fois dans la liste des membres d'une relation et
> déjà dans la pile, on n'a aucun moyen de retraiter cet objet une deuxième
> fois, tout au plus on peut détecter une éventuelle incohérence de tags et
> journaliser ce cas, mais on ne doit pas traiter cet enfant à nouveau sans
> créer une boucle infinie: il suffit donc juste de savoir, si un objet qui
> peut avoir des descendants est déjà en cours de traitement dans la pile, si
> oui ne rien faire d'autre, sinon on commence à traiter l'objet en
> l'incluant d'abord dans la pile, puis en le retirant une fois le traitement
> de cet enfant terminé.
>
>
>
>
> Le 13 décembre 2016 à 22:17, Éric Gillet <gill3t.3ric+osm at gmail.com> a
> écrit :
>
>> Le 13 décembre 2016 à 21:27, <osm.sanspourriel at spamgourmet.com> a écrit :
>>
>>> J'ai peut-être la réponse à la longueur du traitement :
>>>
>>> https://www.openstreetmap.org/relation/6789691 a pour membre :
>>>
>>>    - Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>>    2504515) <https://www.openstreetmap.org/relation/2504515>
>>>    et fait partie de :
>>>    - Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>>    2504515) <https://www.openstreetmap.org/relation/2504515>
>>>
>>> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
>>> Retrouver la relation maîtresse ?
>>>
>>
>> Cela me semble être une erreur, il n'est pas nécessaire de "boucler"
>> comme ça les relations. Les outils, notamment Overpass, savent gérer les
>> liens de parenté entre les relations.
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161214/2aba891a/attachment.htm>