Re: [OSM-talk-fr] Zone naturelle protégée, chemin à accès restreint

2017-10-27 Par sujet marc marc 
Le 16. 10. 17 à 08:22, Nicolas Toublanc a écrit :

> Question 1)*
> Actuellement, on a les tags:
>   * highway: path
>   * foot: yes
pas de sens d'avoir foot=yes vu que c'est le cas par défaut.

> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France
>  , 
> je suppose qu'il faut explicitement ajouter:
>   * bicycle: yes
pas celui là vu que c'est le cas par défaut

> Ou est-ce même plutôt designated qu'il faut utiliser, au lieu de yes 
> (au moins pour les piétons) ?
designed précise que le piéton doit prendre ce chemin (panneau ahdoc)
http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging#Voies_pi.C3.A9tonnes.2C_pistes_cyclables

> Dans quel cas doit-on plutôt utiliser highway: footway ? 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway 
lorsqu'il y a un panneau "chemin piéton"

 > des chemins pour piétons et cyclistes,
 > explicitement interdits aux chevaux et véhicules motorisés,
 > mais accessibles au tracteur de service pour l'entretien.

j'aurais mis
highway=track (parce qu'il a la largeur pour accueillir les tracteurs)
horse=no
motor_vehicle=private

> *Question 2) *
> 
> Une partie des chemins sont interdits au public, et appelés "Zone de 
> quiétude", pour protéger la faune.
> 
> Comment indiquer cette restriction d'accès?

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

Re: [OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

2017-10-27 Par sujet osm . sanspourriel 

En théorie, je vois bien les raisons de JB.

En pratique vu que ce sont notamment des Allemands qui parlent sur le 
ticket de demander à talk-de, je ne vois pas trop le souci.


Je n'ai pas de problème de langue (pour l'allemand s'entend) mais un 
gros problème de temps pour pouvoir me proposer de faire l'interface.


Jean-Yvon


Le 27/10/2017 à 21:29, JB - jb...@mailoo.org a écrit :

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588


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

Re: [OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

2017-10-27 Par sujet JB 

Franchement, je pense que ce n'est pas une bonne idée.
La communauté allemande est bien structurée.
Ils ont apparemment identifié le problème.
Ça peut sembler long pour un Français, mais ça ne me choque pas qu'ils 
prennent plusieurs mois pour aboutir à la modification.

Tu (nous) n'es pas en liaison régulière avec la liste talk-de.
Tu ne pourras pas interagir avec leurs réponses en allemand.
Tu vas passer pour le *** français donneur de leçons qui ferait mieux de 
rester de son côté de la frontière.
Voilà voilà pour ce soir, le coté mondial, je le laisse de côté pour 
l'instant.

JB.

Le 27/10/2017 à 21:15, marc marc a écrit :

Bonsoir,

comme déjà effectué en France et en Suisse, j'aimerai lancer une édition
mécanique pour harmoniser et nettoyer les typos et erreur relatif à
toilets:wheelchair ce qui nécessite de demander l'avis de la communauté
via la mailing allemande talk-de

Mon soucis est la langue.. Je ne parle malheureusement pas allemand.
Je peux bien sur poster en anglais mais je trouve cela peu agréable pour
les allemands qui ne le parlent pas nécessairement tous.
Je peux bien sur passer mon message dans un traducteur automatique
et faire de même avec les réponses.
Ce serrait cependant mieux si quelqu'un parlant allemand pouvait
accompagner ma démarche tant pour le premier message (les traducteur
automatiques ne sont pas toujours parfait) que dans le cas (encore
hypothétique) où il y aurait discussion sur l'opération.

Quelqu'un de motivé ? je n'ai pas l'impression que cela devrait
générer beaucoup de volume.

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588

PS2: l'étape d'après, c'est au niveau mondial, mais j'espère que ce
serra une formalité vu que les pays les plus concernés l'auront fait.

Cordialement,
Marc
___
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] Devenir mandataire d'OpenStreetMap France

2017-10-27 Par sujet marc marc 
Le 06. 10. 17 à 14:52, Vincent de Château-Thierry a écrit :
> On parle peu de l'association OpenStreetMap France sur ce canal. Je prends 
> l'occasion aujourd'hui pour aborder le sujet des mandataires.

bonne initiative :)

> Les demandes sont de tous ordres : dépannage technique, devis, participation 
> à une réunion ou à un événement, annonce.

est-ce qu'il y a une liste des demandes passées ?
cela pourrait permettre de se faire une idée de ce qui est demandé
est-ce qu'il y a un endroit où le suivit est fait ?
cela permettrait de se faire une idée du type de demandes pour 
lesquelles il manque du monde
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

2017-10-27 Par sujet marc marc 
Bonsoir,

comme déjà effectué en France et en Suisse, j'aimerai lancer une édition 
mécanique pour harmoniser et nettoyer les typos et erreur relatif à 
toilets:wheelchair ce qui nécessite de demander l'avis de la communauté 
via la mailing allemande talk-de

Mon soucis est la langue.. Je ne parle malheureusement pas allemand.
Je peux bien sur poster en anglais mais je trouve cela peu agréable pour
les allemands qui ne le parlent pas nécessairement tous.
Je peux bien sur passer mon message dans un traducteur automatique
et faire de même avec les réponses.
Ce serrait cependant mieux si quelqu'un parlant allemand pouvait 
accompagner ma démarche tant pour le premier message (les traducteur 
automatiques ne sont pas toujours parfait) que dans le cas (encore 
hypothétique) où il y aurait discussion sur l'opération.

Quelqu'un de motivé ? je n'ai pas l'impression que cela devrait
générer beaucoup de volume.

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588

PS2: l'étape d'après, c'est au niveau mondial, mais j'espère que ce 
serra une formalité vu que les pays les plus concernés l'auront fait.

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

[OSM-talk-fr] Rapprochement Bano

2017-10-27 Par sujet gergero 

> Date: Thu, 26 Oct 2017 19:13:13 +0200
> From: gergero 

> J'ai une question par rapport aux données suivantes :
>
>   > (Message de Christian Quest Mer 25 Oct 13:55:58 UTC 2017 :)
>
>   > "Pour les points en violet, ce sont des adresses issues des 
fichiers du
>   > cadastre désormais en opendata. C'est un peu expérimental, mais 
ça peut

>   > être utile."
>
> Comment retrouver les données/fichiers à l'origine de ces adresses
> (points en violet) ?

Je trouve bien les coordonnées des points d'adresse en gris dans les 
fichiers BAN et BANO , mais les mêmes chiffres (adresses ? ) en violet 
me semblent plus à jour.



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

Re: [OSM-talk-fr] Directions signalisations verticales

2017-10-27 Par sujet Philippe Verdy 
Vous faites comment avec la signalisation au dessus de la route (accrochée
à un câble comme on en voit souvent aux USA, ou sur le tablier d'un pont,
ou sur une potence horizontale liée au seul des deux côtés de la route) ?
Noter aussi qu'un feu peut parfois être de l'autre côté du carrefour, avec
un seul poteau ayant des feux dans les deux directions.

D'une façon générale le feu n'est pas la seule signalisation, il y a aussi
le marquage au sol (un feu éteint pour une raison quelconque ne dispense
pas de respecter au moins les priorités à droite ou le stop s'il est marqué
d'une ligne continue, certains feux ayant en plus les panneaux
correspondants)

Ce que vous matérialisez sur le côté de la route ce n'est que le mobilier
qui supporte la signalisation, pas la signalisation elle-même. Dans ce cas
là pourquoi ne pas juste matérialiser le poteau (car il n'y en a pas
toujours pour tous les feux) ?

Le 27 octobre 2017 à 12:18, François Lacombe  a
écrit :

> Je pensais plus aux limitations de vitesse
>
> Pour les feux, comme les panneaux stop c'est un peu compliqué oui.
> Il faudrait mapper l'objet feu avec un nœud dédié, et la ligne
> matérialisant l’arrêt au sol sur la voie. On évite la redondance et on
> garde bien toutes les infos.
> Ça permettrait de tracer les sas velo devant les feux par exemple, auquel
> cas le feu n'est pas à la hauteur d'arret des voitures etc...
>
> Il y a aussi les panneaux périphériques, comme à l'approche d'un panneau
> stop pour prévenir les automobilistes, qui n'ont parfois aucun effet
> concret.
>
>
>
> Le 27 octobre 2017 à 12:09, marc marc  a écrit
> :
>
>> Bonjour,
>>
>> @Axelos:
>> Dans le cas de feux, la page dit que le tag direction permet de savoir
>> dans quel direction le feu s'applique, cela n'a donc pas de lien avec le
>> fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui
>> s'applique.
>> c'est plutot pour faire la distinction entre (apparement aux us) le cas
>> oü ils tag un carrefour avec un feu sur le croisement et le cas (partout
>> en europe ?) ou le feu est posé avant le carrefour et s'applique dans
>> une direction (qu'ils peux nécessaire de renseigner lorsque le feu se
>> trouve par exemple entre un rond-point et un passe piéton :
>> s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui
>> en sortent pour laisser passer les piétons)
>> par contre le préfix traffic_signals est un peu inutile (vu que sur un
>> feu, il ne peu s'applique qu'aux feux)
>> mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi
>>
>> @Francois j'ai pas compris comment tu met l'effet du feu sur le highway.
>> tu remet un 2ieme noeud avec les mêmes infos ?
>>
>> Le 27. 10. 17 à 11:55, François Lacombe a écrit :
>> > Bonjour Axelos,
>> >
>> > Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous
>> > les panneaux routiers pour indiquer la direction du trafic impactée.
>> > Si le panneau stop est cartographié à sa position réelle, direction=*
>> > s'applique.
>> >
>> > D'un point de vue perso, je cartographie les panneaux physiques à leur
>> > position réelle que dans c'est possible, et leurs effets sur la highway
>> > (ou sur ses noeuds)
>> >
>> >
>> > A+
>> >
>> > François
>> >
>> > Le 27 octobre 2017 à 11:03, Axelos a écrit :
>> >
>> > Coucou,
>> >
>> > J'ai dessellé une contradiction en ce qui concerne l'indication de
>> la
>> > direction concernant les signalisations verticales (feux, stop
>> > cédez-le-passage)
>> >
>> > En effet, si on prend l'exemple du feu de signalisation, on nous
>> demande
>> > d'utiliser le préfixe traffic_signals devant le tag direction pour y
>> > indiquer forward ou backward.
>> >
>> > Est alors expliqué que direction=* est utilisé pour indiquer les
>> points
>> > cardinaux si la signalisation n'est pas placée sur un chemin.
>> >
>> > https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
>> > 
>> >
>> > En toute logique, pour un stop, on devrait utiliser
>> stop:direction=*,
>> > hors c'est direction=* qui est indiqué.
>> > Pas de points cardinaux pour les stops ?
>> >
>> > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>>
>> ___
>> 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] Directions signalisations verticales

2017-10-27 Par sujet François Lacombe 
Je pensais plus aux limitations de vitesse

Pour les feux, comme les panneaux stop c'est un peu compliqué oui.
Il faudrait mapper l'objet feu avec un nœud dédié, et la ligne
matérialisant l’arrêt au sol sur la voie. On évite la redondance et on
garde bien toutes les infos.
Ça permettrait de tracer les sas velo devant les feux par exemple, auquel
cas le feu n'est pas à la hauteur d'arret des voitures etc...

Il y a aussi les panneaux périphériques, comme à l'approche d'un panneau
stop pour prévenir les automobilistes, qui n'ont parfois aucun effet
concret.


Le 27 octobre 2017 à 12:09, marc marc  a écrit :

> Bonjour,
>
> @Axelos:
> Dans le cas de feux, la page dit que le tag direction permet de savoir
> dans quel direction le feu s'applique, cela n'a donc pas de lien avec le
> fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui
> s'applique.
> c'est plutot pour faire la distinction entre (apparement aux us) le cas
> oü ils tag un carrefour avec un feu sur le croisement et le cas (partout
> en europe ?) ou le feu est posé avant le carrefour et s'applique dans
> une direction (qu'ils peux nécessaire de renseigner lorsque le feu se
> trouve par exemple entre un rond-point et un passe piéton :
> s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui
> en sortent pour laisser passer les piétons)
> par contre le préfix traffic_signals est un peu inutile (vu que sur un
> feu, il ne peu s'applique qu'aux feux)
> mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi
>
> @Francois j'ai pas compris comment tu met l'effet du feu sur le highway.
> tu remet un 2ieme noeud avec les mêmes infos ?
>
> Le 27. 10. 17 à 11:55, François Lacombe a écrit :
> > Bonjour Axelos,
> >
> > Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous
> > les panneaux routiers pour indiquer la direction du trafic impactée.
> > Si le panneau stop est cartographié à sa position réelle, direction=*
> > s'applique.
> >
> > D'un point de vue perso, je cartographie les panneaux physiques à leur
> > position réelle que dans c'est possible, et leurs effets sur la highway
> > (ou sur ses noeuds)
> >
> >
> > A+
> >
> > François
> >
> > Le 27 octobre 2017 à 11:03, Axelos a écrit :
> >
> > Coucou,
> >
> > J'ai dessellé une contradiction en ce qui concerne l'indication de la
> > direction concernant les signalisations verticales (feux, stop
> > cédez-le-passage)
> >
> > En effet, si on prend l'exemple du feu de signalisation, on nous
> demande
> > d'utiliser le préfixe traffic_signals devant le tag direction pour y
> > indiquer forward ou backward.
> >
> > Est alors expliqué que direction=* est utilisé pour indiquer les
> points
> > cardinaux si la signalisation n'est pas placée sur un chemin.
> >
> > https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> > 
> >
> > En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> > hors c'est direction=* qui est indiqué.
> > Pas de points cardinaux pour les stops ?
> >
> > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>
> ___
> 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] Directions signalisations verticales

2017-10-27 Par sujet marc marc 
Bonjour,

@Axelos:
Dans le cas de feux, la page dit que le tag direction permet de savoir 
dans quel direction le feu s'applique, cela n'a donc pas de lien avec le 
fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui 
s'applique.
c'est plutot pour faire la distinction entre (apparement aux us) le cas 
oü ils tag un carrefour avec un feu sur le croisement et le cas (partout 
en europe ?) ou le feu est posé avant le carrefour et s'applique dans 
une direction (qu'ils peux nécessaire de renseigner lorsque le feu se 
trouve par exemple entre un rond-point et un passe piéton : 
s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui 
en sortent pour laisser passer les piétons)
par contre le préfix traffic_signals est un peu inutile (vu que sur un 
feu, il ne peu s'applique qu'aux feux)
mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi

@Francois j'ai pas compris comment tu met l'effet du feu sur le highway. 
tu remet un 2ieme noeud avec les mêmes infos ?

Le 27. 10. 17 à 11:55, François Lacombe a écrit :
> Bonjour Axelos,
> 
> Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous 
> les panneaux routiers pour indiquer la direction du trafic impactée.
> Si le panneau stop est cartographié à sa position réelle, direction=* 
> s'applique.
> 
> D'un point de vue perso, je cartographie les panneaux physiques à leur 
> position réelle que dans c'est possible, et leurs effets sur la highway 
> (ou sur ses noeuds)
> 
> 
> A+
> 
> François
> 
> Le 27 octobre 2017 à 11:03, Axelos a écrit :
> 
> Coucou,
> 
> J'ai dessellé une contradiction en ce qui concerne l'indication de la
> direction concernant les signalisations verticales (feux, stop
> cédez-le-passage)
> 
> En effet, si on prend l'exemple du feu de signalisation, on nous demande
> d'utiliser le préfixe traffic_signals devant le tag direction pour y
> indiquer forward ou backward.
> 
> Est alors expliqué que direction=* est utilisé pour indiquer les points
> cardinaux si la signalisation n'est pas placée sur un chemin.
> 
> https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> 
> 
> En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> hors c'est direction=* qui est indiqué.
> Pas de points cardinaux pour les stops ?
> 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop

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

Re: [OSM-talk-fr] Directions signalisations verticales

2017-10-27 Par sujet François Lacombe 
Bonjour Axelos,

Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous les
panneaux routiers pour indiquer la direction du trafic impactée.
Si le panneau stop est cartographié à sa position réelle, direction=*
s'applique.

D'un point de vue perso, je cartographie les panneaux physiques à leur
position réelle que dans c'est possible, et leurs effets sur la highway (ou
sur ses noeuds)


A+

François

Le 27 octobre 2017 à 11:03, Axelos  a écrit :

> Coucou,
>
> J'ai dessellé une contradiction en ce qui concerne l'indication de la
> direction concernant les signalisations verticales (feux, stop
> cédez-le-passage)
>
> En effet, si on prend l'exemple du feu de signalisation, on nous demande
> d'utiliser le préfixe traffic_signals devant le tag direction pour y
> indiquer forward ou backward.
>
> Est alors expliqué que direction=* est utilisé pour indiquer les points
> cardinaux si la signalisation n'est pas placée sur un chemin.
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
>
> En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> hors c'est direction=* qui est indiqué.
> Pas de points cardinaux pour les stops ?
>
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>
> Cordialement.
>
> --
>
> Comment les entreprises surveillent notre quotidien ?
> https://frama.link/8XtqSFYU
>
> ___
> 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] Hiérarchie des relations d’itinéraire cyclistes

2017-10-27 Par sujet Axelos 
Coucou,

Le 07/10/2017 à 20:33, Adrien Grellier a écrit :
> J'ai procédé de la même manière pour l'Euro-vélo 1, qui inclut le Canal
> de Nantes à Brest, et l'Euro-vélo 6, qui inclut la Loire à Vélo.
> 
> Il me semble que c'est une bonne manière de procéder, simple et qui
> évite là duplication de données. En plus ça respecte totalement l'esprit
> des grands circuits, qui se reposent en pratique sur les tracés plus locaux.


Merci pour ton retour.
J'ai donc mis en pratique cette logique sur deux véloroutes, dont la
seconde que partiellement, et depuis j’attends les retours pour éviter
des guerres d’éditions.

On m'a remonté l'info que OpenCycleMap n'affiche pas les routes
internationales, après vérification je confirme et j'ai demandé la cause
à Thunderforest par courriel (au cas où il s'agit d'un simple oublie).

À plus.

-- 

Comment les entreprises surveillent notre quotidien ?
https://frama.link/8XtqSFYU

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

[OSM-talk-fr] Directions signalisations verticales

2017-10-27 Par sujet Axelos 
Coucou,

J'ai dessellé une contradiction en ce qui concerne l'indication de la
direction concernant les signalisations verticales (feux, stop
cédez-le-passage)

En effet, si on prend l'exemple du feu de signalisation, on nous demande
d'utiliser le préfixe traffic_signals devant le tag direction pour y
indiquer forward ou backward.

Est alors expliqué que direction=* est utilisé pour indiquer les points
cardinaux si la signalisation n'est pas placée sur un chemin.

https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction

En toute logique, pour un stop, on devrait utiliser stop:direction=*,
hors c'est direction=* qui est indiqué.
Pas de points cardinaux pour les stops ?

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop

Cordialement.

-- 

Comment les entreprises surveillent notre quotidien ?
https://frama.link/8XtqSFYU

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-27 Par sujet Christian Quest 
Le 27 octobre 2017 à 04:56, Francois Gouget  a écrit :

> Le jeudi 26 octobre 2017 à 10:45 +0200, Christian Quest a écrit :
> > Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
> > compléter avec d'autres sources (BANO en est une).
> [...]
> > On va aussi pouvoir bien mieux exploiter les données du cadastre dans
> > un avenir très proche, vu qu'on a accès depuis quelques semaines aux
> > données EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on
> > peut faire de mieux que ce qui a été fait jusque maintenant avec les
> > extractions faites uniquement à partir de fichiers PDF sur
> > cadastre.gouv.fr
>
> Donc ce que je retiens :
> * Priorité aux noms de rues.
>   Tout à fait d'accord. Mais c'est pas évident de contribuer si on
> n'est pas sur place. Quelles sont vos techniques ?
>

Le rendu BANO permet de se faire une très bonne idée dans la majorité des
cas.


  A-t-on une idée du temps que vont prendre les 16 dernières voies
> ? Si elles restent c'est qu'il n'y a pas de contributeur dans ces
> villes ?
>

Le rythme s'est pas mal ralentit ces derniers temps. Si on s'y remet
sérieusement comme au début de la dispo de BANO, ces 160.000 voies peuvent
quasi disparaitre d'ici un an. Bien sûr, il y aura un résidu qui résistera
sur les cas tordus et particuliers qui nécessitent d'aller sur le terrain.


  Enfin, si on arrive effectivement au bout de cet aspect, je pense que
> ça a du sens de revisiter comment va s'organiser la suite.
>
> * Attendre voir si on peut mieux faire avec le nouveau cadastre.
>   Mieux = import massif ? Points "adresse manquante" dans Osmose ? (20
> millions de points ça va être joli ;-)
>
>
Le mieux c'est un peu plus d'adresses et peut être un meilleur calage
géographique.

* En l'absence d'import massif alors on continue avec une intégration
> manuelle qui prendra 10 à 15 ans.
>

L'import massif n'est pas souhaitable de mon point de vue ou alors c'est
qu'on privilégie la quantité à la qualité, et je ne suis pas pour.

  Peut-on déveloper des stratégies pour maximiser le rendement des
> efforts d'intégration ?
>   - Par exemple si un contributeur ajoute un commerce / restaurant et
> pointe vers son site web, il aura probablement vu son adresse quelque
> part. Donc on pourrait recommander l'ajout de l'adresse dans les pages
> Wiki de amenity, shop et office. Mais cela fera quelques rues
> commerçantes avec plein d'adresses et pas grand chose ailleurs.
>

Ouille... tout comme un bâtiment n'a pas de lien 1/1 avec une adresse, un
commerce n'a pas de lien 1/1 non plus.
Il est préférable de mettre son adresse en contact:*=*, l'adresse est un
objet à part entière.

Ces adresses en contact:* sont de toute façon exploitables si on en a
besoin, mais au moins on sait que ce n'est pas l'adresse elle même qu'on a
renseigné.


  - Ajouter les adresses aux intersections. Je pense qu'avoir ces
> données dans OSM serait presque suffisant pour les usages courants.
> Mais pour un contributeur ce n'est pas le cas le plus simple à traiter
> : à chaque fois la question se pose de savoir sur quelle rue est le
> numéro. Aussi, un contributeur gagne-t-il en temps à se concentrer sur
> les intersections ?
>

J'avais commencé comme ça sur ma commune, avec des interpolations. A
l'époque le plan cadastral était en image et pas vectoriel.
J'ai ensuite remplacé ces interpolations par les points adresse (toujours à
partir du plan image).

Qu'on ajoute les points ou qu'on mette des interpolations, la question
reste la source: terrain ou pas, donc amélioration/contrôlé ou juste copie
d'une source (le cadastre dans la majorité des cas).

  - Ajouter une adresse par rue bordant un paté de maison. Là on évite
> le problème des intersections mais on répond un peu moins bien à la
> question "je tourne à droite ou à gauche ?".
>   - Se concentrer sur les rues couvertes par Mapillary. Ca permet de
> gagner du temps et de couvrir une zone plus étendue en évitant d'avoir
> à aller sur place. Mais la couverture Mapillary est très loin d'être
> complète mais j'ai l'impression qu'assez peu de numéros sont lisibles
> et donc si je compte le temps passé à chercher une image où un numéro
> est lisible je ne suis pas sûr que le rendement soit si bon.
>
>
Il faudrait des photos latérales... or c'est souvent des photos frontales
qui sont prises et versées et oui, ça prend un temps fou.


* Les outils peuvent s'appuyer sur la BANO.
>   Si on table sur une intégration qui prend 10 ans ou plus alors
> effectivement les outils ont plutôt intérêt à ajouter du support pour
> la BANO afin d'être utilisables. Mais dans ce cas il faudrait les en
> informer clairement.
>   Ca veut aussi dire qu'ils devront intégrer du code spécifique pour la
> France, soit au niveau de l'outil même, soit au niveau de la
> préparation des fichiers OSM qu'ils utilisent en faisant leur propre
> 'import massif' de la BANO.
>
>
Non, ce n'est pas du code spécifique pour la France, c'est du code
spécifique pour les