Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-21 Par sujet Christian Quest 
Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
écrit :

> on parle beaucoup des transport public en ce moment, ça serait bien que
> les arrets de bus, tram metro ... soit rendu qu'avec des tag
> public_transport= et aussi si ce n'est pas un node mais un way ou
> multipolygon.
>

>

Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
adopter un modèle bien complexe pour le contributeur lambda.

Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
outils de QA comme osmose, pas avec un rendu assez généraliste.


Pour la prise en compte des polygones, je vais regarder ce qu'il est
possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
prendre en compte le schéma public_transport au niveau du rendu.

On met quoi sur le rendu ? public_transport=stop_position ou
public_transport=platform ?

Si on a un highway=bus_stop comment on évite d'avoir un doublon ?

Heureusement que postgis a maintenant de quoi générer des cluster... ça va
peut être être la solution: on met tout ensemble et on fait un cluster ;)

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-21 Par sujet Christian Quest 
Le 21 décembre 2016 à 23:56,  a écrit :

> Niveau 10
> 
> :
>
> les zones militaires et zones protégées me semblent trop mises en avant.
>

La zone en elle même n'a pas changé, il n'y a que le texte qui a changé
(taille et couleur)... je vais l'assombrir un peu


> Niveau 11
> 
> :
>
> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
> Lann-Bihoué mais sur Guidel-Plages.
>
>
?? lien ??


> Pourtant le nom déborde de la zone militaire.
>

ça , les noms peuvent déborder si la forme est très allongée. La taille du
texte varie avec la surface du polygone, mais pas en prenant compte sa
largeur et/ou hauteur.


> Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les
> outils ne doivent pas être assez précis :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/47.8569/-3.5315
> Pour les dédoublement de noms, soit les tuiles sont trop petites soit il y
> a encore des progrès à faire (appliquer l'algo des ref ?) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#17/48.38764/-4.46565
>

Difficile avec les voies à chaussées séparées. Ce sont deux lignes
distinctes et pas facile de les fusionner en une seule...



>
> En regardant là :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.39598/-4.44701
> On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection
> inutile de répéter (sauf si très éloignés). Et si intersection alors si au
> début on met le nom, à la fin aussi, on en déduit qu'entre c'est le même
> nom.
> On peut aussi vouloir privilégier les tronçons ouest-est (rue
> Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après).
> Oui ce n'est plus du peaufinage, c'est de l'art ;-).
>
>
C'est surtout un équilibre à trouver car si on ne répète pas du tout les
noms, comme on ne sait pas quelle partie de la care est visualisée sur une
petite surface (genre mobile ou petite carte en ligne), on peut très bien
ne pas avoir de nom visible pour une voie qui traverse la carte.

Aller dans le détail des intersections comme tu le suggère n'est pas simple
non plus... j'imagine la complexité des requêtes pour obtenir ces infos !



> Là aussi, mais c'est sans doute un pb côté données (une relation associant
> les différents bâtiments du collège) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39819/-4.45559
>
>
Oui, clairement un problème de données...

chaque polygone de bâti a son tag amenity=school et school:FR=collège... on
a donc 4 collèges !

Un polygone englobant toute l'emprise du collège est bien sûr la solution
parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est une cour, un
parking, des terrains de sport, etc... j'ai corrigé.



> Rendu ou données incorrectes ?
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39896/-4.40997
> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>
>
Là je sèche...

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-21 Par sujet Jérôme Amagat 
on parle beaucoup des transport public en ce moment, ça serait bien que les
arrets de bus, tram metro ... soit rendu qu'avec des tag public_transport=
et aussi si ce n'est pas un node mais un way ou multipolygon.


Le 21 décembre 2016 à 23:56,  a écrit :

> Niveau 10
> 
> :
>
> les zones militaires et zones protégées me semblent trop mises en avant.
>
> Niveau 11
> 
> :
>
> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
> Lann-Bihoué mais sur Guidel-Plages.
>
> Pourtant le nom déborde de la zone militaire.
>
> Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les
> outils ne doivent pas être assez précis :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/47.8569/-3.5315
> Pour les dédoublement de noms, soit les tuiles sont trop petites soit il y
> a encore des progrès à faire (appliquer l'algo des ref ?) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#17/48.38764/-4.46565
> En regardant là :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.39598/-4.44701
> On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection
> inutile de répéter (sauf si très éloignés). Et si intersection alors si au
> début on met le nom, à la fin aussi, on en déduit qu'entre c'est le même
> nom.
> On peut aussi vouloir privilégier les tronçons ouest-est (rue
> Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après).
> Oui ce n'est plus du peaufinage, c'est de l'art ;-).
>
> Là aussi, mais c'est sans doute un pb côté données (une relation associant
> les différents bâtiments du collège) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39819/-4.45559
>
> Rendu ou données incorrectes ?
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39896/-4.40997
> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>
>
> 
> Le 21/12/2016 à 19:45, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] fiber=yes ?

2016-12-21 Par sujet François Lacombe 
Bonjour Jean-Yvon,

Le 18 décembre 2016 à 20:49,  a écrit :

> Je vais te proposer de mettre fin à ton dilemme :
> telecom:medium:fiber=yes
> telecom:medium:coax=yes
>
> Pas de soucis pour les armoires à usage multiple.
> Et comme il y a trois et non deux cas (yes, no, absence de tag)
>

En fait le dilemme se situait entre les listes à ; :
telecom:medium=fiber;coax et les tag "yes" : telecom:medium:fiber=yes +
telecom:medium:coax=yes
J'avais d'ailleurs reproché ça à une proposition d'extension du modèle des
écoles/universités en début d'année où trop de clés avec pour seule valeur
yes étaient utilisées.

Vu qu'il n'y a pas de solution parfaite, à mon avis les clés =yes sont
meilleures que des listes difficiles à manipuler.


> Tu veux dire : du réseau à l'armoire en fibre et de l'armoire à l'abonné
> en coax, pas que l'armoire gère des réseaux basés sur deux technologies
> différentes.
>
C'est ça, mais si l'armoire se situe à la connexion entre la fibre qui
arrive du "central" (le cmts) et le coax qui dessert les abonnés, il y a
bien deux medium différents à l'intérieur.



> Intéressant mais je ne vois pas ça dans le schéma. Non, je ne propose pas
> d'ajouter cette information mais je suis prêt à te l'entendre dire.
> Ce serait par exemple :
> telecom:service_level:FTTH pour l'armoire fibre et FTTLa pour l'armoire
> fibre/coax.
> Comme ça on n'aurait pas de valeurs multiples ? Je dis peut-être une
> connerie, ne pas hésiter à le dire, j'aurais encore appris qqc ce soir.
> Par exemple, est-ce quelque chose distingue le FTTH (H=Home, prise
> individuelle) et le FTTB (B=building, fibre à l'immeuble, autre techno
> ensuite) d'une point de vue réseau ? Est que le  FTTB n'est pas un FTTH
> suivi d'un FTTLa  (ou plutôt FTTC) dans l'immeuble ?
> http://www.ariase.com/fr/guides/fibre-optique.html
>

Intéressante cette clé telecom:service_level
En France ça peut marcher, parce qu'il n'y a pas de cas où les boucles
locales sont mélangées, certains font du FTTH, d'autres FTTLa et c'est
étanche
Par contre je crois savoir que dans d'autres pays d'Europe du nord, il
mélangent les deux dans les mêmes armoires, on va avoir le même problème
que fibre/coax.

Il est certain qu'un FTTB s'accompagne d'une techno quelconque pour rallier
l'abonné en bout de réseau (peut-être du coax via DocSis ou même du VDSL).

On ne souhaitais pas descendre à ce niveau de détail là pour l'instant
La solution avec telecom:medium:fiber=yes est la plus polyvalente.
Peut-on se risquer à utiliser medium:fiber=yes, sans telecom: ?


Bonne soirée
François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-21 Par sujet osm . sanspourriel 
Niveau 10 
 
:


les zones militaires et zones protégées me semblent trop mises en avant.

Niveau 11 
 
:


et sans doute ailleurs : pas de repliement de ligne sue la BAN de 
Lann-Bihoué mais sur Guidel-Plages.


Pourtant le nom déborde de la zone militaire.

Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les 
outils ne doivent pas être assez précis :


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/47.8569/-3.5315

Pour les dédoublement de noms, soit les tuiles sont trop petites soit il 
y a encore des progrès à faire (appliquer l'algo des ref ?) :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.38764/-4.46565
En regardant là :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.39598/-4.44701
On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection 
inutile de répéter (sauf si très éloignés). Et si intersection alors si 
au début on met le nom, à la fin aussi, on en déduit qu'entre c'est le 
même nom.
On peut aussi vouloir privilégier les tronçons ouest-est (rue 
Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après). 
Oui ce n'est plus du peaufinage, c'est de l'art ;-).


Là aussi, mais c'est sans doute un pb côté données (une relation 
associant les différents bâtiments du collège) :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39819/-4.45559

Rendu ou données incorrectes ?
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39896/-4.40997
http://www.openstreetmap.org/#map=19/48.39886/-4.40977

Le 21/12/2016 à 19:45, Christian Quest - cqu...@openstreetmap.fr a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles bornes Trilib'

2016-12-21 Par sujet osm . sanspourriel 
> name 
=Trilib' 



Fin du monologue ;-).

Tu veux sans doute dire brand=Trilib' car ce n'est pas la borne qui 
s'appelle comme ça.


Jean-Yvon


Le 21/12/2016 à 19:26, Florian LAINEZ - winner...@free.fr a écrit :
Je crois que je prends le sujet beaucoup trop au sérieux, j'ai même 
fait une page wiki sur le sujet : 
https://wiki.openstreetmap.org/wiki/WikiProject_France/FR:Trilib


Le 19 décembre 2016 à 12:41, Florian LAINEZ > a écrit :


Bon ben on a une réponse : ça sera dispo bientôt ;)
https://twitter.com/EcoEmballagesSA/status/810810802412408833


Du coup, quitte à faire un monologue sur cette liste, je pense que
je vais également me féliciter en sus.
Et bonne journée à tous !

Le 19 décembre 2016 à 12:30, Florian LAINEZ mailto:winner...@free.fr>> a écrit :

Hello,
De nouvelles bornes de recyclages Trilib' sont actuellement
installées dans les rues de Paris. Plus de détails sur ces
bornes : http://www.ecoemballages.fr/trilib

J'en ai rajouté une ici :
https://www.openstreetmap.org/node/4561625761


Les emplacements (sans précision sur la licence) sont ici :

https://www.google.com/maps/d/u/0/viewer?mid=1I4BmDUuK6_BhAygXB_KqT2hmiOA&ll=48.8571767956718%2C2.36557134982&z=12



J'ai envoyé un tweet et un email au contact indiqué sur le
flyer pour obtenir une précision sur la licence ... avec un
peu de chance on aura ça dans OSMOSE d'ici noël ;)

Je vous tiens au courant si j'ai un retour
++

-- 


*Florian Lainez*

@overflorian 




-- 


*Florian Lainez*

@overflorian 




--

*Florian Lainez*

@overflorian 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-12-21 Par sujet lenny.libre 

h


Le 16/12/2016 à 17:36, Florian LAINEZ a écrit :


Le 16 décembre 2016 à 13:01, lenny.libre > a écrit :


Ne faudrait-il pas quelque part, une récapitulation


Un genre de Base d'Arrêts de Transport Ouverte ? ^^
Contributions bienvenues : https://github.com/BATO-FR/bato_inventaire
je ne pensais pas à quelque chose d'aussi immense ; mais je pensais, 
suite au mail de réponse de Jean-Yvon à Noémie à un tableau 
récapitulatif dans le wiki qui permettrait de choisir l'éventuelle ville 
à traiter après STIF ou à Osmose.


Mais là je viens de découvrir bato. C'est tellement vaste... je ne 
comprends pas tout et je ne vois pas où je pourrais contribuer avec mes 
petits moyens : je prends une ligne, je la complète si nécessaire, 
j'aboute les tronçons avec JOSM, je corrige les giratoires (que certains 
découpent pour leur besoin sans se préoccuper des autres lignes) je 
complète les arrêts si nécessaire (avec l'aide des openData ou ce que je 
vois sur place).


Les transports scolaires sont-ils compris dans bato ?
Dans les slides du Cerema, je trouvé un point qui me parait difficile à 
obtenir :
"IMPORTANT : attribution des identifiants pérennes !(id OSM et id 
Transport)"


Je ne vois pas comment l'id OSM peut être pérenne : prés de chez moi, 
j'ai trouvé deux arrêts, qui en fait n'en était qu'un (un contributeur à 
créé l'arrêt initial, entre temps l'opérateur à changé et un autre 
contributeur à créé un autre arrêt) je suis allé vérifier sur place, 
j'ai mis à jour l'un des deux et j'ai supprimé l'autre : quel était 
celui qui avait un id pérenne ???


cordialement
Léni


*Florian Lainez*

@overflorian 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cartes.xyz / bad request

2016-12-21 Par sujet Guillaume AMAT 

Pas mieux, merci Éric pour la réponse.

Je profite de ce fil de discussion sur MapContrib pour vous dire que la 
version 1.0.0 pourrait arriver par la cheminée ce week-end, mais chut ^^


Bon réveillon à tous,
Guillaume


Le 21/12/2016 à 20:39, Éric Gillet a écrit :
Le 21 décembre 2016 à 19:53, Florian LAINEZ > a écrit :


Désolé de relancer le sujet mais j'ai créé une nouvelle carte des
bornes Trilib' à Paris
https://www.cartes.xyz/t/fcd984-Bornes_Trilib

Cette fois j'ai bien retenu la leçon et je n'ai pas mis de requête
overpass-turbo mais bien une requête API overpass.
J'ai toujours le même soucis : bad request ... help !


Il faut mettre la requête Overpass en elle-même et pas une URL vers 
l'API Overpass :

https://www.cartes.xyz/t/34563d-MapContrib


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cartes.xyz / bad request

2016-12-21 Par sujet Éric Gillet 
Le 21 décembre 2016 à 19:53, Florian LAINEZ  a écrit :

> Désolé de relancer le sujet mais j'ai créé une nouvelle carte des bornes
> Trilib' à Paris https://www.cartes.xyz/t/fcd984-Bornes_Trilib
> Cette fois j'ai bien retenu la leçon et je n'ai pas mis de requête
> overpass-turbo mais bien une requête API overpass.
> J'ai toujours le même soucis : bad request ... help !
>

Il faut mettre la requête Overpass en elle-même et pas une URL vers l'API
Overpass :
https://www.cartes.xyz/t/34563d-MapContrib
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cartes.xyz / bad request

2016-12-21 Par sujet Florian LAINEZ 
Désolé de relancer le sujet mais j'ai créé une nouvelle carte des bornes
Trilib' à Paris https://www.cartes.xyz/t/fcd984-Bornes_Trilib
Cette fois j'ai bien retenu la leçon et je n'ai pas mis de requête
overpass-turbo mais bien une requête API overpass.
J'ai toujours le même soucis : bad request ... help !

Le 13 décembre 2016 à 12:00, Jean-Claude Repetto  a écrit
:

> Le 13/12/2016 à 09:09, Vincent Bergeot a écrit :
> > Je pense que l'on doit arrêter les aspects techniques mapcontrib sur
> > cette liste, je ne suis pas sur que cela soit à sa place ? Avis ?
>
> Bonjour,
>
> Pour les discussions techniques, il y a la liste dev-fr.
>
> Jean-Claude
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-21 Par sujet Christian Quest 
Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements:
https://github.com/cquest/osmfr-cartocss/commits/master

Après avoir passé pas mal de temps sur les optimisations pour accélrer le
rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.

Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
les abords de certaines gares ;) Pour ça, le rendu considère tout objet
avec un level=* négatif comme indoor.

Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
regroupe les différents tronçons ayant le même highway+ref car vu qu'on
tronçonne de plus en plus il faut en passer par là !

Résultat visible sur
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186

Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
peut nécessiter un délais de génération...


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles bornes Trilib'

2016-12-21 Par sujet Florian LAINEZ 
Je crois que je prends le sujet beaucoup trop au sérieux, j'ai même fait
une page wiki sur le sujet :
https://wiki.openstreetmap.org/wiki/WikiProject_France/FR:Trilib

Le 19 décembre 2016 à 12:41, Florian LAINEZ  a écrit :

> Bon ben on a une réponse : ça sera dispo bientôt ;)
> https://twitter.com/EcoEmballagesSA/status/810810802412408833
>
> Du coup, quitte à faire un monologue sur cette liste, je pense que je vais
> également me féliciter en sus.
> Et bonne journée à tous !
>
> Le 19 décembre 2016 à 12:30, Florian LAINEZ  a écrit :
>
>> Hello,
>> De nouvelles bornes de recyclages Trilib' sont actuellement installées
>> dans les rues de Paris. Plus de détails sur ces bornes :
>> http://www.ecoemballages.fr/trilib
>> J'en ai rajouté une ici : https://www.openstreetmap.org/node/4561625761
>>
>> Les emplacements (sans précision sur la licence) sont ici :
>> https://www.google.com/maps/d/u/0/viewer?mid=1I4BmDUuK6_BhAy
>> gXB_KqT2hmiOA&ll=48.8571767956718%2C2.36557134982&z=12
>>
>> J'ai envoyé un tweet et un email au contact indiqué sur le flyer pour
>> obtenir une précision sur la licence ... avec un peu de chance on aura ça
>> dans OSMOSE d'ici noël ;)
>>
>> Je vous tiens au courant si j'ai un retour
>> ++
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-21 Par sujet Christian Quest 
Un peu d'explication: Rennes Métropole différencie en fait la notion
d'adresse et de bâtiment aussi pour une raison réglementaire très simple:
- les numéros d'adresses (y compris bis/ter) sont attribué officiellement
par le maire de la commune
- les autres extensions (A/B/C/D pour différencier des bâtiments) ne sont
pas forcément attribuées par le maire.

Est-ce que des A/B/C/D sont attribués par des maires ? OUI, aussi, donc on
ne peut pas généraliser ce qui se fait à Rennes.

Il n'y a aucun règle en la matière, malheureusement.


Le 21 décembre 2016 à 16:50, Julien Lepiller  a écrit :

> Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il n'y
> a pas de consensus concernant l'espace ou non. Concernant l'import depuis
> les données de Rennes Métropole, il faudrait le corriger pour qu'il inclue
> aussi les lettres (A, B, ...) des bâtiments. Dans l'immédiat, est-il
> possible de rendre osmose insensible aux espaces dans le numéro ?
>
> En parlant d'adresses en double et d'anecdote, je connais un cas où
> plusieurs bâtiments distincts ont la même adresse postale.
> https://www.openstreetmap.org/way/269025821 et
> https://www.openstreetmap.org/way/26902 sont tous les deux situés au
> 420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est
> d'ailleurs même pas le nom du chemin auquel ces bâtiments sont rattachés,
> mais d'un autre plus loin. Les boîtes aux lettres sont toutes regroupées
> plus loin, au niveau du croisement entre le chemin du Pélissier et le
> chemin sans nom qui donne à ces maisons. Comment devrais-je m'y prendre
> pour ajouter ces adresses ? Un point par maison, ou un seul point au niveau
> des boîtes aux lettres ?
>
> Le 2016-12-21 16:07, Mathias Jérôme a écrit :
>
>> Bien sûr des contre exemples il y aura à la pelle..j'énonçais
>> seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
>> 10-4 à la place de ce que voulez.
>> Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
>> ce qui plaide pour le mettre tout ce qui est numérotation avec la
>> numérotation (ou dans le même "mot" ce qui reviens au même).
>>
>> -
>>  DE : Florian_G 
>> À : Discussions sur OSM en français 
>> ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
>> OBJET : Re: [OSM-talk-fr] osmose et adresses bis
>>
>> Hello,
>>
>> Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
>>
>> Les bis, ter etc... sont des indices de répétitions, mais les
>>> A,B,C etc... sont plutôt ce que j'appellerais des indices de
>>> déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
>>> existait) et est (était)  vraiment distinct, tandis que le 36A il
>>> est souvent situé au situé au 36, de même que le 36B se situera
>>> aussi au 36 , de fait les A,B,C,etc... sont souvent de la
>>> numérotation d'ordre "privative" : accès ou cages d'escaliers).
>>>
>>
>> Petit contre-exemple :
>>
>> *
>> OSM :
>> http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
>> * Google :
>> https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.
>> 26h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!
>> 7i13312!8i6656!6m1!1e1
>>
>> Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A, autonome,
>> distinct et non dépendant du 13 (qui est bien une autre maison). Les
>> parcelles cadastrales sont d'ailleurs différentes, mais ce n'est pas
>> déterminant (au mieux un indice).
>> En fait, c'est, selon moi, juste une norme de numérotation
>> différente ; que ce soit numéro "n bis" ou numéro "n A", les
>> bâtiments numérotés "n" et "n+1" étant déjà construits ou
>> prévus, il fallait donc bien trouver une astuce au moment de la mise
>> en place du numéro entre les deux. Pour l'anecdote, il existe même
>> un 0 bis à Metz, avant le 2, mais pas de 0 ! →
>> http://www.openstreetmap.org/way/72882228#map=19/49.11648/6.18358
>> Mes 2 centimes... 😊
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-21 Par sujet Julien Lepiller 
Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il 
n'y a pas de consensus concernant l'espace ou non. Concernant l'import 
depuis les données de Rennes Métropole, il faudrait le corriger pour 
qu'il inclue aussi les lettres (A, B, ...) des bâtiments. Dans 
l'immédiat, est-il possible de rendre osmose insensible aux espaces dans 
le numéro ?


En parlant d'adresses en double et d'anecdote, je connais un cas où 
plusieurs bâtiments distincts ont la même adresse postale. 
https://www.openstreetmap.org/way/269025821 et 
https://www.openstreetmap.org/way/26902 sont tous les deux situés au 
420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est 
d'ailleurs même pas le nom du chemin auquel ces bâtiments sont 
rattachés, mais d'un autre plus loin. Les boîtes aux lettres sont toutes 
regroupées plus loin, au niveau du croisement entre le chemin du 
Pélissier et le chemin sans nom qui donne à ces maisons. Comment 
devrais-je m'y prendre pour ajouter ces adresses ? Un point par maison, 
ou un seul point au niveau des boîtes aux lettres ?


Le 2016-12-21 16:07, Mathias Jérôme a écrit :

Bien sûr des contre exemples il y aura à la pelle..j'énonçais
seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
10-4 à la place de ce que voulez.
Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
ce qui plaide pour le mettre tout ce qui est numérotation avec la
numérotation (ou dans le même "mot" ce qui reviens au même).

-
 DE : Florian_G 
À : Discussions sur OSM en français 
ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
OBJET : Re: [OSM-talk-fr] osmose et adresses bis

Hello,

Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :


Les bis, ter etc... sont des indices de répétitions, mais les
A,B,C etc... sont plutôt ce que j'appellerais des indices de
déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
existait) et est (était)  vraiment distinct, tandis que le 36A il
est souvent situé au situé au 36, de même que le 36B se situera
aussi au 36 , de fait les A,B,C,etc... sont souvent de la
numérotation d'ordre "privative" : accès ou cages d'escaliers).


Petit contre-exemple :

*
OSM :
http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
* Google :
https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.26h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i13312!8i6656!6m1!1e1

Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A, autonome,
distinct et non dépendant du 13 (qui est bien une autre maison). Les
parcelles cadastrales sont d'ailleurs différentes, mais ce n'est pas
déterminant (au mieux un indice).
En fait, c'est, selon moi, juste une norme de numérotation
différente ; que ce soit numéro "n bis" ou numéro "n A", les
bâtiments numérotés "n" et "n+1" étant déjà construits ou
prévus, il fallait donc bien trouver une astuce au moment de la mise
en place du numéro entre les deux. Pour l'anecdote, il existe même
un 0 bis à Metz, avant le 2, mais pas de 0 ! →
http://www.openstreetmap.org/way/72882228#map=19/49.11648/6.18358
Mes 2 centimes... 😊

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-21 Par sujet Mathias Jérôme 
Bien sûr des contre exemples il y aura à la pelle..j'énonçais seulement des 
généralités et on aura aussi les 10-1 , 10-2 , 10-3 , 10-4 à la place de ce que 
voulez.Ce qui est sûr c'est que c'est de la numérotation dans tous les cas, ce 
qui plaide pour le mettre tout ce qui est numérotation avec la numérotation (ou 
dans le même "mot" ce qui reviens au même).


  De : Florian_G 
 À : Discussions sur OSM en français  
 Envoyé le : Mercredi 21 décembre 2016 14h20
 Objet : Re: [OSM-talk-fr] osmose et adresses bis
   
Hello,
 
 Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
Les bis, ter etc... sont des indices de répétitions, mais les A,B,C etc... sont 
plutôt ce que j'appellerais des indices de déclinaisons (dans le cas du 36bis 
c'est que le 36 existe (ou existait) et est (était)  vraiment distinct, tandis 
que le 36A il est souvent situé au situé au 36, de même que le 36B se situera 
aussi au 36 , de fait les A,B,C,etc... sont souvent de la numérotation d'ordre 
"privative" : accès ou cages d'escaliers).
Petit contre-exemple :   
   - OSM : http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
   - Google : 
https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.26h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i13312!8i6656!6m1!1e1
Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A, autonome, distinct 
et non dépendant du 13 (qui est bien une autre maison). Les parcelles 
cadastrales sont d'ailleurs différentes, mais ce n'est pas déterminant (au 
mieux un indice).En fait, c'est, selon moi, juste une norme de numérotation 
différente ; que ce soit numéro "n bis" ou numéro "n A", les bâtiments 
numérotés "n" et "n+1" étant déjà construits ou prévus, il fallait donc bien 
trouver une astuce au moment de la mise en place du numéro entre les deux. Pour 
l'anecdote, il existe même un 0 bis à Metz, avant le 2, mais pas de 0 ! → 
http://www.openstreetmap.org/way/72882228#map=19/49.11648/6.18358Mes 2 
centimes... 😊 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


   ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données du STIF sur Osmose

2016-12-21 Par sujet Frédéric Rodrigo 

Le 20/12/2016 à 02:35, Jérôme Amagat a écrit :
peut être baisser le paramètre conflationDistance, là pour les bus 
elle est à 100 (mètres?) la baisser à 10 voir à 5 mètres comme ça 
moins de proposition d'intégration mais on est (pratiquement) sur que 
c'est le même arrêt dans osm et dans la source. Pour les arrêts ou il 
y a plus de 5 mètre mais que c'est bien le bon et bien il faudra 
l'envoyer dans josm et, en vérifiant avec les photos aériennes, faire 
la fusion des points.
par contre est ce que osmose va continuer à proposer un nouvel arrêt 
même si il y en a déjà un avec le bon ref mais qu'il est plus loin que 
la conflationDistance?



S'il y a la ref c'est bon, pas de conflation en distance.

Florian ton avis sur la distance de conflation ? Ou la suppression des 
arrêts de bus stif d'osmose



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-21 Par sujet Florian_G 
 
Hello,

Le 20/12/2016 à 20:44, Mathias Jérôme a écrit : 

> Les bis, ter etc... sont des indices de répétitions, mais les A,B,C etc... 
> sont plutôt ce que j'appellerais des indices de déclinaisons (dans le cas du 
> 36bis c'est que le 36 existe (ou existait) et est (était) vraiment distinct, 
> tandis que le 36A il est souvent situé au situé au 36, de même que le 36B se 
> situera aussi au 36 , de fait les A,B,C,etc... sont souvent de la 
> numérotation d'ordre "privative" : accès ou cages d'escaliers).

Petit contre-exemple : 

* OSM :
http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980 [1]
* Google :
https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.26h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i13312!8i6656!6m1!1e1
[2]

Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A, autonome,
distinct et non dépendant du 13 (qui est bien une autre maison). Les
parcelles cadastrales sont d'ailleurs différentes, mais ce n'est pas
déterminant (au mieux un indice). 

En fait, c'est, selon moi, juste une norme de numérotation différente ;
que ce soit numéro "n bis" ou numéro "n A", les bâtiments numérotés "n"
et "n+1" étant déjà construits ou prévus, il fallait donc bien trouver
une astuce au moment de la mise en place du numéro entre les deux. Pour
l'anecdote, il existe même un 0 bis à Metz, avant le 2, mais pas de 0 !
→ http://www.openstreetmap.org/way/72882228#map=19/49.11648/6.18358 [3] 

Mes 2 centimes... 😊 
 

Links:
--
[1] http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
[2]
https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.26h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i13312!8i6656!6m1!1e1
[3] http://www.openstreetmap.org/way/72882228#map=19/49.11648/6.18358
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données du STIF sur Osmose

2016-12-21 Par sujet Philippe Verdy 
En revanche les données fournies par l'Open Data de la STAR à Rennes sont
excellentes (en terme de géolocalisation et complétude)... sauf qu'Osmose
insiste pour changer les tags de numéros de référence et ne produit
actuellement presque uniquement 100% de faux positifs sur tous les arrêts
(pour ajouter des tags redondants ou faux à des arrêts pourtant déjà
intégrés et qu'il trouve bien dans la base).

La géolocalisation peut cependant être un peu améliorée pour placer les
plateformes d'arrêt sur le bon côté de la route, mais dans la plupart des
cas j'ai vu que la faute ne vient pas de l'OpenData mais d'une précision
insuffisante du tracé des rues et routes dans OSM (ce qui a pour effet de
mettre les deux arrêts normalement de chaque côté du'une rue tous les deux
du même côté). Les tracés vectoriels du cadastre de Rennes et de son
opendata sont excellents, la solution est donc de recaler les rues; les
ajustements des platformes d'arrêts sont minimes: juste le mettre sur le
trottoir plutôt que sur le côté de la chaussée (dans certains cas on peut
voir norn seulement la plaforme (avec les zébrures sur la chaussée) mais
aussi les abris bus (l'orthophoto fournie par Bing reprend les clichés
haute précision réalisés par Rennes Métropole et l'IGN, leur alignement est
excellent, on peut donc largement augmenter la précision des anciens tracés
OSM initialement dessinés sur des clichés de moins bonne précision et faits
souvent un peu à la va-vite au moment où on traçait les limites communales
et quelques rues).

J'en profite en ce moment pour ajouter les sous-quartiers (là encore sur
les données OpenData de Rennes Métropole) : ils sont au niveau 11; jusqu'à
présent on n'avait que les 12 quartiers administratifs au niveau 10 et les
6 unités administratives au niveau 9.

Et je nettoie des tracés parasites quand j'en trouve. Autant que possible
ces tracés de quartiers aux niveaux 9,10,11 sont fusionnés avec ceux des
cantons (qui ont été tracés au béut par estimation sur des noms de rues
mais sans le calage précis des rues qui est maintenant dans l'OpenData de
Rennes Métropole). J'atteint la précision quasi-centimétrique, les rues
sont profilées, il n'y a plus de rues qui coupent les bordures de chaussées
ou les trottoirs dans ce que je touche, ce qui permet de poser correctement
les éléments voisins sur le trottoir comme les poubelles, abris bus, et
positions des feux ou encore des arbres et les emplacements de
stationnement latéral.

Pour certains grands carrefours ou ronds-points je les reprofile de façon
moins approximative, j'ajoute les pelouses et zones plantées et certains
chemins piétons. Cependant je ne touche pas aux notations d'accessibilité
des bordures de trottoirs surbaissés pour les usagers en fauteuil. Et il
manque certainement des tas de ralentisseurs près des passages pétons (eux
je les ajoute aussi quand ils manquent quand ils sont bien visibles et que
je recale eux aussi). Les rues en courbes ont réellement des formes en
courbe avec des rayons de courbure corrects et non un seul angle (ça c'est
utile pour la navigation des véhicules larges, notamment bus et camions).

La moitié des 45 sous-quartiers sont faits: au centre, sud-gare, nord,
ouest et sud-ouest. Je continue les autres...


Le 21 décembre 2016 à 09:58, Florian LAINEZ  a écrit :

> Merci Fred, Noémie pour ces outils.
> Je rejoins les critiques : c'est pour l'instant un peu galère voir
> trompeur.
> Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ...
>
> En ce moment j'aborde le problème de qualité avec divers acteurs du
> transport et j'ai fait un petit comparatif rapide sur deux quartiers
> exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6
> Des suggestions d'amélioration ?
>
> Y aurait-il moyen de générer des stats plus poussées ? Je cherche par
> exemple l'écart moyen de la distance entre les données STIF et OSM, les
> valeurs max/min, voir l'écart-type.
> Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé.
> J'aimerai également détailler ça par gestionnaire de réseau, étant donné
> qu'il y en a 75 dans les données du STIF.
>
> Bonne journée
>
>
> Le 20 décembre 2016 à 21:32, Noémie Lehuby 
> a écrit :
>
>> Bonjour,
>>
>> Bonne idée Christian !
>> j'ai créé une page de débug qui précise, dans OSM et dans l'opendata,
>> pour chaque arrêt avec une ref STIF, les lignes desservies :
>> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=472985886
>>
>> il faut lui passer en paramètre l'id OSM du noeud correspondant à l'arrêt.
>>
>> Ça gère aussi les cas où un arrêt OSM correspond à plusieurs arrêts dans
>> l'opendata (dont certains pas forcément du bon côté de la route ...) :
>> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=928458342
>>
>> N'hésitez pas à l'utiliser pour vérifier vos ajouts de références STIF ;)
>>
>> Noémie
>>
>> Date: Mon, 19 Dec 2016 18:42:52 +0100
>>> From: Christian Quest 
>>> To: Discussions sur OSM en français  
>>> Subject: Re: [OSM-talk-fr] Données du STIF sur O

Re: [OSM-talk-fr] Données du STIF sur Osmose

2016-12-21 Par sujet Frédéric Rodrigo 

Le 21/12/2016 à 09:58, Florian LAINEZ a écrit :

Merci Fred, Noémie pour ces outils.
Je rejoins les critiques : c'est pour l'instant un peu galère voir 
trompeur.

Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ...

En ce moment j'aborde le problème de qualité avec divers acteurs du 
transport et j'ai fait un petit comparatif rapide sur deux quartiers 
exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6

Des suggestions d'amélioration ?

Y aurait-il moyen de générer des stats plus poussées ? Je cherche par 
exemple l'écart moyen de la distance entre les données STIF et OSM, 
les valeurs max/min, voir l'écart-type.

Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé.

Oui Osmose génère en même temps des CSV, mais je ne retrouve pas l'URL


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données du STIF sur Osmose

2016-12-21 Par sujet Florian LAINEZ 
Merci Fred, Noémie pour ces outils.
Je rejoins les critiques : c'est pour l'instant un peu galère voir trompeur.
Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ...

En ce moment j'aborde le problème de qualité avec divers acteurs du
transport et j'ai fait un petit comparatif rapide sur deux quartiers
exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6
Des suggestions d'amélioration ?

Y aurait-il moyen de générer des stats plus poussées ? Je cherche par
exemple l'écart moyen de la distance entre les données STIF et OSM, les
valeurs max/min, voir l'écart-type.
Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé.
J'aimerai également détailler ça par gestionnaire de réseau, étant donné
qu'il y en a 75 dans les données du STIF.

Bonne journée


Le 20 décembre 2016 à 21:32, Noémie Lehuby 
a écrit :

> Bonjour,
>
> Bonne idée Christian !
> j'ai créé une page de débug qui précise, dans OSM et dans l'opendata, pour
> chaque arrêt avec une ref STIF, les lignes desservies :
> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=472985886
>
> il faut lui passer en paramètre l'id OSM du noeud correspondant à l'arrêt.
>
> Ça gère aussi les cas où un arrêt OSM correspond à plusieurs arrêts dans
> l'opendata (dont certains pas forcément du bon côté de la route ...) :
> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=928458342
>
> N'hésitez pas à l'utiliser pour vérifier vos ajouts de références STIF ;)
>
> Noémie
>
> Date: Mon, 19 Dec 2016 18:42:52 +0100
>> From: Christian Quest 
>> To: Discussions sur OSM en français  
>> Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose
>> Message-ID:
>> > gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> C'est trompeur en effet...
>>
>> J'ai intégré des arrêts sur ma commune et il manque quelques infos de
>> contexte pour savoir qu'on ajoute bien le bon ID quand il y a ambiguité.
>> Il
>> faudrait par exemple le N° des lignes et la direction sinon deux arrêts
>> proches peuvent être intervertis très facilement.
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr