[OSM-ja] バスルートの追加（高岡市、広島県）作業完了報告

2023-04-25 Thread OKADA Tsuneo 
岡田です。

2022/2/2にこのMLにてアナウンスしました、高岡市と広島県のバスルートの登録
について、ほぼほぼ作業が完了しましたので報告します。

高岡市：31ルートの登録
広島県：12事業者で1,382ルートの登録・更新
(いずれもマスターリレーションは含まない数)

残件：
広島県で複数事業者で共同運行するルートがあるのですが、
状況によっては複数事業者をまとめて1つのリレーションにしようと思っています。


残件について、リレーションを統合するかの検討と、
統合する場合はバス停ノードも統合が必要になり、データの確認などに時間がかかりそう
なので、ひとまず現段階での報告で一区切りとします。

各々のwikiページ：
https://wiki.openstreetmap.org/wiki/Import/Catalogue/TakaokaCityBusImport
https://wiki.openstreetmap.org/wiki/Import/Catalogue/HiroshimaWestAreaBusImport

-- 
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Vincent de Château-Thierry 



Le 25/04/2023 à 21:10, Marc_marc a écrit :

Bonjour,

Le 25.04.23 à 14:46, Vincent de Château-Thierry a écrit :


La certification n'est hélas en aucun cas un critère de qualité.


bien noté, je pensais que c'était quand même une indication
que quelqu'un avait revu ces données et que donc, en moyenne,
c'était mieux des adresses certifiés que non certifiée (qui
peuvent avoir des années sans revue humaine).
pq on a cette info dans le pifomètre si tu estimes
que cela n'a aucun impact ?


Tu inverses cause et conséquence... L'info a été demandée pour 
Pifomètre, je l'y ai mise. Une fois disponible, elle a permis à des 
contributeurs de se concentrer sur les adresses certifiées, pour 
finalement constater que la qualité n'était pas au rendez-vous, en tout 
cas pas de manière constante.




Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import


la valeur ajoutée de l'import est de transformer des données opendata
existante en donnée utilisable dans tous les outils osm, tout en se
gardant la possibilité de détecter les données venant de l'opendata
de celle ayant été améliorée dans osm
Dis comme ça je n'y vois aucun intérêt, ça donne juste à OSM le rôle 
d'un grand réservoir dans lequel on déverse de la donnée. L'intérêt avec 
OSM ça n'est pas de juste faire une compilation (j'allais dire une 
accumulation) de données, c'est d'harmoniser toutes ces données pour 
constituer un jeu cohérent. Le passage d'une compilation à un jeu de 
données cohérent se fait par les différents ajouts de valeur que nous 
apportons dans nos contributions.


- garantir la bonne orthographe des noms de voies (dans la BAN c'est 
un poème, défauts d'accents, défauts de majuscules, etc)


à partir du moment oü on n'importe que les no sur des rues rapprochées,
comment pourrait-il y avoir une erreur d'accent/majuscule du à l'import?
c'est le rapprochement de la route qui traite cela (et raison pour 
laquelle c'est proposé de ne pas traiter les routes non rapprochée)


Ok donc tu voudrais partir de BANO et non de la BAN



- assigner à chaque adresse une position cohérente


Quel est la position cohérente quand il n'y a pas de concensus ?
l'un positionera à l'endroit de la plaque "officielle"
l'autre en limite (parfois suposée) de propriété public/privé
le 3ieme la mettre à l'entrée correspondante
et surtout le 4ieme ferra un import sans en parler à personne et
les mettra là oü le dit l'opendata sans aucun moyen de les retrouver,
cfr le contributeur qui a importé à ce jour 1.6 millions d'adresses
par 10k, brut de décoffrage, majuscule et toute erreur compris,
y compris celle renseignée dans bano ou y compris des addr:street
ne correspondant pas à la voie [1]


Et donc parce qu'un contributeur a fait n'importe quoi, cela 
justifierait qu'on ne se pose pas de questions et qu'on garde tel quelle 
la position de chaque adresse prise dans la BAN à l'avenir ? Le fait est 
que certaines positions d'adresse sont totalement farfelues (certifiées 
ou non).


- filtrer les données sources : ne pas ajouter dans OSM des numéros 
assignés à une autre voie et totalement erronés dans leur affectation 
et leur position, sans parler des 5xxx et 9xxx


n'est-ce pas déjà ce que fais le pifomètre ?
si oui en quoi prendre importer depuis le pifomètre provoquerait-il
une moins bonne qualité que intégrer depuis le pifomètre ?


Ce qui compte ici ce n'est pas l'outil (Pifomètre ne sert pas pour de 
l'import massif) mais le contenu, donc BANO



si une rue est rapprochée, la seule chose à faire en intégration
est d'éventuelement regarder si les adresses pair/impair sont de
chaque côté de la rue et en ordre croissant, chose tout a fait
possible aussi en chargeant une donnée depuis osm qui aurait
le created_by=Import* non ?


C'est réducteur, le schéma pair/impair est loin d'être le seul. Si tu 
t'attends à juste vérifier la parité, tu vas déchanter avec les 
numérotations continues, métriques, anarchiques...



qui se base sur... 3 réponses


j'en compte 17 dans ma boite
mais 3 ou 17 n'est pas important, je ne fais que des opérations
de masse consensuelles donc soit la discussion permet d'aboutir
à un consensus sur un import (éventuellement encore plus) limité
soit je ne le ferrai pas... et d'autres continueront à importer
sous le radar avec une qualité bien moindre que ce que je pense
possible avec un import ciblé... et l'impossibilité de retrouver
ces objets pour celui qui souhaiterai faire des opérations
supplémentaire.


A te lire c'est "moi ou le chaos"... C'est moins manichéen dès qu'on 
considère aussi tous les contributeurs qui font de l'intégration 
d'adresses (et non de l'import), à leur rythme et avec le souci de bien 
faire.


vincent



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

Re: [OSM-talk-fr] Re :Re: [import] import partiel des adresses en France

2023-04-25 Thread Jean-Claude Repetto 

Le 25/04/2023 à 17:39, Bruno Remy via Talk-fr a écrit :

Bonjour,

Je comprends que l'outil pifométre fait du contrôle qualité mais je me demande 
encore pourquoi àjouter des relations ce qui semble être une spécialité 
française alors que la communauté OSM semble utiliser les clés correspondant au 
numéro et au nom de rue. Ce qui est géré nativement par ID.
Alors pourquoi réinventer la roue ?
Bruno




Bonsoir,

Parce que dupliquer le nom de la rue sur chaque point d'adresse est 
source d'erreur. Une des règles des bases de données est de ne jamais 
dupliquer des données.


Jean-Claude


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

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Marc_marc 

Bonjour,

Le 25.04.23 à 16:35, Cyrille37 OSM a écrit :
Et si on a besoin tout de suite et maintenant d'interroger des adresses 
sur toute la France il y a https://adresse.data.gouv.fr/ 


Mme Michou a décidé d'installer OsmAnd.
elle a rendez-vous avec sa copine au 1 rue de la gare.
elle recherche cela dans osmand : introuvable.

quel est la suite probable de l'histoire ?

1) elle va sur https://adresse.data.gouv.fr
trouve l'adresse, et copie lat qu'elle rentre dans osmand

2) elle ouvre GM, tape 1 rue de la gare et lui connait
toutes l'adresse sans se préoccuper si la plaque de rue
est 1 m à gauche ou à droite. Mme michou a des yeux,
elle trouvera la plaque elle-même, de toute façon
elle a du se garer a 42m de là.

j'ai l'impression qu'espérer que Mme michou sorte de son
appli "osm" pour chercher une info et y retourner, c'est
assez peu probable... et surement pas ergonomique.
on le fait nous parfois, parce qu'on est presque marié
à osm... mais nous ne sommes pas le comportement habituel.

PS: chez un client, géocodage inversé qui utilisait les données
osm puis GM quandd osm n'avait pas l'info, osm a pris la porte
lors d'une révision majeur du code,
le chef de projet a estimé que le cout du dev ne serrait jamais
amorti par le gain financier des données osm à cause du
faible taux de réponse en europe francophone, et qu'en plus
cela prennait moins de temps à avoir une api à interroger
au lieu de 2.
Je ne vais pas parler de mon resenti :)

Cordialement,
Marc



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

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Marc_marc 

Bonjour,

Le 25.04.23 à 14:46, Vincent de Château-Thierry a écrit :

Étendue de l'import de la première tranche
- le nom de la rue est présente dans osm, identique à celui
de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel
tel que visible avec la colonne "adresse BAN avec voie rapprochée %"
sur le pifomètre [1]
- le taux de certification de 100% tel que visible avec la colonne "%
adresses certifiées BAN" sur le pifomètre [1]
- j'avais proposé "la rue dans osm ne contient aucune addr" : certains
ont suggéré de commencer avec ce critère sur l'étendue de la commune.
le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm

A voir s'il y a beaucoup de communes avec 100% adresses certifiées +
100% voies adressée rapprochée + pas d'adresse dans osm :)
mais c'est une première tranche

Questions :

- faut-il ajouter des critères de qualité ? par ex dans le passé,
ce n'était pas rare d'avoir plusieurs adresses au même endroit.
il n'y a pas eu de retour sur ce point que je propose de supprimer
sauf si quelqu'un souhaite le conserver.
J'espère que ce problème a disparu avec la certification
mais un retour est bienvenu si ce n'est pas le cas.


La certification n'est hélas en aucun cas un critère de qualité.


bien noté, je pensais que c'était quand même une indication
que quelqu'un avait revu ces données et que donc, en moyenne,
c'était mieux des adresses certifiés que non certifiée (qui
peuvent avoir des années sans revue humaine).
pq on a cette info dans le pifomètre si tu estimes
que cela n'a aucun impact ?


- la position des addr est souvent flottante tandis que d'autres
voudraient les voir au moins en bordure du bâtiments concernées.
Il avait été proposé de sortir cette question hors de l'import
et d'importer avec la position actuelle de l'opendata


Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import


la valeur ajoutée de l'import est de transformer des données opendata
existante en donnée utilisable dans tous les outils osm, tout en se
gardant la possibilité de détecter les données venant de l'opendata
de celle ayant été améliorée dans osm


- garantir la bonne orthographe des noms de voies (dans la BAN c'est un poème, 
défauts d'accents, défauts de majuscules, etc)


à partir du moment oü on n'importe que les no sur des rues rapprochées,
comment pourrait-il y avoir une erreur d'accent/majuscule du à l'import?
c'est le rapprochement de la route qui traite cela (et raison pour 
laquelle c'est proposé de ne pas traiter les routes non rapprochée)



- assigner à chaque adresse une position cohérente


Quel est la position cohérente quand il n'y a pas de concensus ?
l'un positionera à l'endroit de la plaque "officielle"
l'autre en limite (parfois suposée) de propriété public/privé
le 3ieme la mettre à l'entrée correspondante
et surtout le 4ieme ferra un import sans en parler à personne et
les mettra là oü le dit l'opendata sans aucun moyen de les retrouver,
cfr le contributeur qui a importé à ce jour 1.6 millions d'adresses
par 10k, brut de décoffrage, majuscule et toute erreur compris,
y compris celle renseignée dans bano ou y compris des addr:street
ne correspondant pas à la voie [1]


- filtrer les données sources : ne pas ajouter dans OSM des numéros assignés à 
une autre voie et totalement erronés dans leur affectation et leur position, 
sans parler des 5xxx et 9xxx


n'est-ce pas déjà ce que fais le pifomètre ?
si oui en quoi prendre importer depuis le pifomètre provoquerait-il
une moins bonne qualité que intégrer depuis le pifomètre ?
si une rue est rapprochée, la seule chose à faire en intégration
est d'éventuelement regarder si les adresses pair/impair sont de
chaque côté de la rue et en ordre croissant, chose tout a fait
possible aussi en chargeant une donnée depuis osm qui aurait
le created_by=Import* non ?


qui se base sur... 3 réponses


j'en compte 17 dans ma boite
mais 3 ou 17 n'est pas important, je ne fais que des opérations
de masse consensuelles donc soit la discussion permet d'aboutir
à un consensus sur un import (éventuellement encore plus) limité
soit je ne le ferrai pas... et d'autres continueront à importer
sous le radar avec une qualité bien moindre que ce que je pense
possible avec un import ciblé... et l'impossibilité de retrouver
ces objets pour celui qui souhaiterai faire des opérations
supplémentaire.

Cordialement,
Marc

[1] https://www.openstreetmap.org/node/6021861199 dans un changeset
de 10k, un commentaire https://openstreetmap.org/changeset/63979400
un lieu Est parmi d'autre https://www.openstreetmap.org/node/5571931546



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

Re: [OSM-talk-fr] Sur quel objet mettre les tags des passages piétons ?

2023-04-25 Thread Marc_marc 

Bonjour,

Le 25.04.23 à 16:36, Noémie Lehuby via Talk-fr a écrit :
quand vous cartographiez un passage piéton en chemin (way),  
les attributs du passage piéton (zébra, ilôt de refuge,  
feux sonores, bande podotactile, etc), vous les mettez plutôt :

1) sur le noeud higwhay=crossing
2) sur le chemin highway=footway + footway=crossing
3) sur les deux


sur le noeud permet de les rendre dispo pour les 2 (un cheminement 
piéton peux favoriser un itinéraire plus sécurisant par ex,

un cheminement voiture peux rajouter X secondes en cas de feux
pour choisir l'itinéraire le plus rapide).

du coup j'ajoute en premier sur le noeud, je ne le fais sur le way
que si je fais du "micro-mapping" en coupant précisément la traversée
ce qui fait 3 way au minimum, 5 en cas d'ilôt.

la bande pédotactile ne se met à mon avis pas sur le way, c'est
très rare que celle-ci fasse la traversée, je la met soit en attribut
sur le noeud highway=crossing soit sur un noeud à sa position précise
proche de la bordure du trottoir


StreetComplete par exemple n'est pas de cet avis : les quêtes semblent porter 
toujourssur le noeud, et même lorsque les infos sont déjà renseignées sur le 
chemin, on a une quête qui re-pose la question sur le noeud.


ca c'est par contre dommage.
peux-être que (les outils à) la contribution devrait pousser
à gérer la paire noeud+way... mais c'est couper un chemin en 5
prend évidement plus de temps que de traiter un noeud

Cordialement,
Marc



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

Re: [OSM-talk-fr] Sur quel objet mettre les tags des passages piétons ?

2023-04-25 Thread Bernard Lefrançois via Talk-fr 
A partir du moment où je cartographie la traversée avec highway=footway 
+ footway=crossing, je place les attributs qui concernent ce chemin sur 
celui-ci (proposition 2) et je place les éléments tels que les kerb (1), 
tactile paving (2) sur un nœud à leur place réelle.
Par rapport à ton exemple, je laisse sur le nœud commun highway=crossing 
les attributs:

crossing=uncontroled/traffic_signals (je n'aime pas ce marked!)
crossing_island=yes
crossing_ref éventuellement s'il existe déjà (bien que j'estime, d'après 
la description, que ces zebra, toucan etc. signifient davantage que le 
simple marquage)

Ces attributs sont utiles aussi aux voitures il me semble.

Par contre sur le chemin highway=footway + footway=crossing, je décris 
le marquage avec crossing_markings.


Effectivement, les éditeurs / réutilisateurs ont du mal à traiter ces 
infos, mais ne serait-ce pas à eux de s'adapter.
La difficulté vient peut-être du fait que le wiki ne décrit pas cette 
méthode 2.


(1) A propos de kerb, je m'interroge sur la nécessité du barrier=kerb. 
D'après la page wiki sur kerb, kerb=lowered/flush.. suffit)


(2) tactile_paving sur le nœud highway=crossing est à mon sens ambigu: 
on voit maintenant des passages piétons avec un pavé podotactile 
transversal au bord de la chaussée, mais aussi une bande tactile 
longitudinale qui traverse toute la chaussée au milieu du marquage. La 
méthode 2 permet d'indiquer les deux.



Le 25/04/2023 à 16:36, Noémie Lehuby via Talk-fr a écrit :

Bonjour,

Dites, quand vous cartographiez un passage piéton en chemin (way), les 
attributs du passage piéton (zébra, ilôt de refuge, feux sonores, 
bande podotactile, etc), vous les mettez plutôt :

1) sur le noeud higwhay=crossing
2) sur le chemin highway=footway + footway=crossing
3) sur les deux
?

Exemple illustré pour que ça soit plus clair : 
https://i.imgur.com/4IsT37m.png


J'ai tendance à faire plutôt le deuxième.
En effet, ça me semble plus cohérent (après tout, c'est utile pour les 
piétons, pas pour les voitures) et plus précis.


Mais l'inconvénient est que la donnée n'est pas uniforme, il faut 
parfois chercher l'info sur un noeud, parfois sur un chemin, et tous 
les éditeurs / réutilisateurs ne feront pas cet effort.
StreetComplete par exemple n'est pas de cet avis : les quêtes semblent 
porter toujours sur le noeud, et même lorsque les infos sont déjà 
renseignées sur le chemin, on a une quête qui re-pose la question sur 
le noeud.


Qu'en pensez-vous ?


___
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

[OSM-talk-fr] Nouveau Défi MapRoulette- nouvelles routes

2023-04-25 Thread Salim Baidoun 
Bonjour,

Nous avons créé un nouveau défi Maproulette concernant de nouvelles voies 
potentielles sur Marseille: France - Add Highways - Provence-Alpes-Côte 
d’Azur. Il y a 200 cas, pour 
le moment, obtenus à partir d’une comparaison du référentiel TomTom sur la 
ville avec le réseau routier OSM. Si ce défi est un succès, nous l’alimenterons 
de cas supplémentaires et il sera étendu à toute la région PACA.

La page GitHub, 
ainsi que la description du défi, donne plus de détails sur le challenge.
Nous serons à Marseille, aux côtés de l’équipe TomTom, pour le State of the Map 
du 9 au 11 juin (Venez nombreux). Ce sera l’occasion d’échanger sur ce défi (et 
d’aller vérifier sur le terrain les cas restants avec les collègues) et les 
précédents.

Mais avant cela, n’hésitez pas à commenter sur ce forum et nous dire si ces cas 
sont pertinents, si vous avez des suggestions d’amélioration, des propositions 
d’autres challenges ou du même challenge sur d’autres régions. Tous les retours 
sont les bienvenus !
Salim A. Baidoun / Community & Partnerships - Global / Community Engagement


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

[OSM-talk-fr] Re :Re: [import] import partiel des adresses en France

2023-04-25 Thread Bruno Remy via Talk-fr 
Bonjour,

Je comprends que l'outil pifométre fait du contrôle qualité mais je me demande 
encore pourquoi àjouter des relations ce qui semble être une spécialité 
française alors que la communauté OSM semble utiliser les clés correspondant au 
numéro et au nom de rue. Ce qui est géré nativement par ID.
Alors pourquoi réinventer la roue ?
Bruno



Bruno REMY

 
 
  Le mar., avr. 25, 2023 à 16:41, Cyrille37 OSM a 
écrit:   Bonjour,

Faisant beaucoup d'adressage dans OSM je confirme que la BAN n'est pas 
assez qualitative pour faire de l'import automatique.

L'outil Pifometre cité par Vincent est super, il permet d'intégrer bout 
par bout, ce qui me semble la volumétrie suffisante et nécessaire pour 
la qualité attendue dans OSM.

Et si on a besoin tout de suite et maintenant d'interroger des adresses 
sur toute la France il y a https://adresse.data.gouv.fr/ ;-)

Cyrille37.

On 25/04/2023 14:46, Vincent de Château-Thierry wrote:
> Bonjour,
>
>> De: "Marc_marc"
>>
>> Suite à l'accueil favorable sur le principe, je poursuis
>> la discussion entamé [2] il y a quelques mois lié à la procédure
>> https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines
>
>> je propose de diviser l'import en plusieurs tranches
>> et de discuter uniquement de la première tranche :
>>
>> Étendue de l'import de la première tranche
>> - le nom de la rue est présente dans osm, identique à celui
>> de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel
>> tel que visible avec la colonne "adresse BAN avec voie rapprochée %"
>> sur le pifomètre [1]
>> - le taux de certification de 100% tel que visible avec la colonne "%
>> adresses certifiées BAN" sur le pifomètre [1]
>> - j'avais proposé "la rue dans osm ne contient aucune addr" : certains
>> ont suggéré de commencer avec ce critère sur l'étendue de la commune.
>> le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm
>>
>> A voir s'il y a beaucoup de communes avec 100% adresses certifiées +
>> 100% voies adressée rapprochée + pas d'adresse dans osm :)
>> mais c'est une première tranche
>>
>> Questions :
>>
>> - faut-il ajouter des critères de qualité ? par ex dans le passé,
>> ce n'était pas rare d'avoir plusieurs adresses au même endroit.
>> il n'y a pas eu de retour sur ce point que je propose de supprimer
>> sauf si quelqu'un souhaite le conserver.
>> J'espère que ce problème a disparu avec la certification
>> mais un retour est bienvenu si ce n'est pas le cas.
> La certification n'est hélas en aucun cas un critère de qualité. Il y a eu 
> différents retours d'expérience là-dessus, notamment sur le canal OSM-Fr 
> matrix/telegram et aussi sur le forum où ce post couvre le même sujet [1].
> En version courte : la certification est auto-déclarative et l'aspect 
> géométrique est loin d'être au cœur des préoccupations des communes, plus 
> focalisées sur l'inventaire. Donc partir sur ce critère comme un filtre 
> d'adresses fiables et sujettes à import est biaisé dès le départ : on se 
> trompe de postulat.
>
>> - la position des addr est souvent flottante tandis que d'autres
>> voudraient les voir au moins en bordure du bâtiments concernées.
>> Il avait été proposé de sortir cette question hors de l'import
>> et d'importer avec la position actuelle de l'opendata
> Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import, on 
> photocopie l'OpenData de la BAN. C'est vraiment regrettable je trouve. Parmi 
> nos valeurs ajoutées sur le sujet des adresses par rapport à la BAN il y a :
> - garantir la bonne orthographe des noms de voies (dans la BAN c'est un 
> poème, défauts d'accents, défauts de majuscules, etc)
> - assigner à chaque adresse une position cohérente avec notre propre graphe 
> et nos bâtiments, donc potentiellement retoucher les coordonnées 
> (manuellement, car non il n'y a aucune magie pour ce genre d'opération)
> - filtrer les données sources : ne pas ajouter dans OSM des numéros assignés 
> à une autre voie et totalement erronés dans leur affectation et leur 
> position, sans parler des 5xxx et 9xxx
>
> Donc je tempère l'accueil favorable dont tu parles au début, et qui se base 
> sur... 3 réponses. Personnellement je ne suis pas favorable à un tel import, 
> mais ça ne devrait pas étonner par ici : si j'ai conçu Pifomètre c'est 
> justement pour ne pas encourager les imports, tout en proposant un outil pour 
> mécaniser le travail d'intégration sans verser dans l'ingestion aveugle 
> d'open data. On peut largement faire évoluer Pifomètre pour changer d'échelle 
> (la commune au lieu de la rue, etc) mais en aucun cas ça ne nous dispensera 
> de contrôler finement ce qu'on fait, en s'interdisant les uploads aveugles 
> par un bot. Parlons *d'intégration* massive dans ce cas, ou tout autre terme 
> non ambigu, mais tant que le sujet sera un *import* avec tes postulats 
> actuels, je n'y souscrirai pas.
>
> merci
>
> vincent
>
> [1] 
> :https://forum.openstreetmap.fr/t/a-quand-des-imports-automatiques-des-bal/9012
>
>

Re: [OSM-talk-fr] présentation

2023-04-25 Thread rpnpif 

Le 25/04/2023 à 16:34, Christian Rogel a écrit :




Le 25 avr. 2023 à 12:08, Bernard Lefrançois via Talk-fr 
 a écrit :

Le 24/04/2023 à 22:48, Christian Rogel a écrit :

C’est comme qu’on peut voir qu’ « associated_street » ne fait « l’unanimité » 
qu’en France (c’est un gimmick Fr de se précipiter sur ce qui semble plus 
malin).


L'unanimité, c'est pas un peu vite dit?
Bon, c'était entre guillemet. Ironique?


Oui, c’était ironique, mais, c’est pour marquer qu’on a lu des plaidoyers pour 
associated_street, mais pas pour la manière originelle.
Dans la vraie vie, c’est iD est largement utilisé et son interface favorise la 
« tradition », car mettre une relation est un poil plus compliqué.
On a eu ouï dire qu’une majorité de la communauté d’Allemagne (quid des 
Autrichiens ou des Suisses ?) préférait ne pas mettre de relation.
Je rattache les numéros manquants à une relation, s’il y en a une, et je fais 
les nouveaux adressages à la paresseuse.

Christian R.


Bienvenue.
Il y a aussi le troll, pardon la concurrence, natural=wood versus 
landuse=forest. :3


--
Rpnpif

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

[OSM-talk] (small) automated edit of name:fiu-vro -> name:vro

2023-04-25 Thread Jules Bouton 

Dear all,*
*

*-**--Context---*

As a consequence of a misunderstanding of the Code of Conduct, I did 
today my first automated edit without previously informing the talk 
mailing-list.This message is something like a "fix", thanks a lot to 
marc_marc for the changeset review and for his kind advices.As the 
concerned edit has a relatively limited impact, I can easily revert the 
changeset if anyone has critics to do : just let me know.Sorry, now I am 
aware of the right conduct.


 * The planned edit was previously discussed on the community forum
   :https://community.
   
openstreetmap.org/t/name-vro-or-name-fiu-vro/
   
 * There is also a (new) wiki log:https://wiki.
   
openstreetmap.org/wiki/Automated_edits/TabulaPeutingeriana
   
 * See the whole changeset discussion here :
   https://www.openstreetmap.org/changeset/135337586

*-**--Edit description---*

10 years ago, many multilingual country names were imported from 
wikipedia/wikidata.This is esp. the case for country names translated in 
Võro (a language of South Estonia).At that time, there was no ISO code 
for Võro and Wikipedia used fiu-vro.During the import, the 
'name:fiu-vro' tag has been kept in OSM.There are still manyremnants of 
this 'name:fiu-vro' in OSM for country names..


Since 2009, there is a brand new ISO-code for Võro and it's widely used 
by the local community (name:vro is the only tag you may find in South 
Estonia).


So I planned to change all remaining name:fiu-vro to name:vro (also 
alt_name, official_name, etc.), and unfortunately, I did it before 
writing this email.I can of course undo the changes if necessary.


For further details and comments, please refer to the forum discussion 
or the wiki log.


Sorry again for this misunderstanding of beginner,

Best regards,

Jules

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

[OSM-talk-fr] Sur quel objet mettre les tags des passages piétons ?

2023-04-25 Thread Noémie Lehuby via Talk-fr 

Bonjour,

Dites, quand vous cartographiez un passage piéton en chemin (way), les 
attributs du passage piéton (zébra, ilôt de refuge, feux sonores, bande 
podotactile, etc), vous les mettez plutôt :

1) sur le noeud higwhay=crossing
2) sur le chemin highway=footway + footway=crossing
3) sur les deux
?

Exemple illustré pour que ça soit plus clair : 
https://i.imgur.com/4IsT37m.png


J'ai tendance à faire plutôt le deuxième.
En effet, ça me semble plus cohérent (après tout, c'est utile pour les 
piétons, pas pour les voitures) et plus précis.


Mais l'inconvénient est que la donnée n'est pas uniforme, il faut 
parfois chercher l'info sur un noeud, parfois sur un chemin, et tous les 
éditeurs / réutilisateurs ne feront pas cet effort.
StreetComplete par exemple n'est pas de cet avis : les quêtes semblent 
porter toujours sur le noeud, et même lorsque les infos sont déjà 
renseignées sur le chemin, on a une quête qui re-pose la question sur le 
noeud.


Qu'en pensez-vous ?

--
Noémie Lehuby



OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Cyrille37 OSM 

Bonjour,

Faisant beaucoup d'adressage dans OSM je confirme que la BAN n'est pas 
assez qualitative pour faire de l'import automatique.


L'outil Pifometre cité par Vincent est super, il permet d'intégrer bout 
par bout, ce qui me semble la volumétrie suffisante et nécessaire pour 
la qualité attendue dans OSM.


Et si on a besoin tout de suite et maintenant d'interroger des adresses 
sur toute la France il y a https://adresse.data.gouv.fr/ ;-)


Cyrille37.

On 25/04/2023 14:46, Vincent de Château-Thierry wrote:

Bonjour,


De: "Marc_marc"

Suite à l'accueil favorable sur le principe, je poursuis
la discussion entamé [2] il y a quelques mois lié à la procédure
https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines



je propose de diviser l'import en plusieurs tranches
et de discuter uniquement de la première tranche :

Étendue de l'import de la première tranche
- le nom de la rue est présente dans osm, identique à celui
de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel
tel que visible avec la colonne "adresse BAN avec voie rapprochée %"
sur le pifomètre [1]
- le taux de certification de 100% tel que visible avec la colonne "%
adresses certifiées BAN" sur le pifomètre [1]
- j'avais proposé "la rue dans osm ne contient aucune addr" : certains
ont suggéré de commencer avec ce critère sur l'étendue de la commune.
le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm

A voir s'il y a beaucoup de communes avec 100% adresses certifiées +
100% voies adressée rapprochée + pas d'adresse dans osm :)
mais c'est une première tranche

Questions :

- faut-il ajouter des critères de qualité ? par ex dans le passé,
ce n'était pas rare d'avoir plusieurs adresses au même endroit.
il n'y a pas eu de retour sur ce point que je propose de supprimer
sauf si quelqu'un souhaite le conserver.
J'espère que ce problème a disparu avec la certification
mais un retour est bienvenu si ce n'est pas le cas.

La certification n'est hélas en aucun cas un critère de qualité. Il y a eu 
différents retours d'expérience là-dessus, notamment sur le canal OSM-Fr 
matrix/telegram et aussi sur le forum où ce post couvre le même sujet [1].
En version courte : la certification est auto-déclarative et l'aspect 
géométrique est loin d'être au cœur des préoccupations des communes, plus 
focalisées sur l'inventaire. Donc partir sur ce critère comme un filtre 
d'adresses fiables et sujettes à import est biaisé dès le départ : on se trompe 
de postulat.


- la position des addr est souvent flottante tandis que d'autres
voudraient les voir au moins en bordure du bâtiments concernées.
Il avait été proposé de sortir cette question hors de l'import
et d'importer avec la position actuelle de l'opendata

Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import, on 
photocopie l'OpenData de la BAN. C'est vraiment regrettable je trouve. Parmi 
nos valeurs ajoutées sur le sujet des adresses par rapport à la BAN il y a :
- garantir la bonne orthographe des noms de voies (dans la BAN c'est un poème, 
défauts d'accents, défauts de majuscules, etc)
- assigner à chaque adresse une position cohérente avec notre propre graphe et 
nos bâtiments, donc potentiellement retoucher les coordonnées (manuellement, 
car non il n'y a aucune magie pour ce genre d'opération)
- filtrer les données sources : ne pas ajouter dans OSM des numéros assignés à 
une autre voie et totalement erronés dans leur affectation et leur position, 
sans parler des 5xxx et 9xxx

Donc je tempère l'accueil favorable dont tu parles au début, et qui se base 
sur... 3 réponses. Personnellement je ne suis pas favorable à un tel import, 
mais ça ne devrait pas étonner par ici : si j'ai conçu Pifomètre c'est 
justement pour ne pas encourager les imports, tout en proposant un outil pour 
mécaniser le travail d'intégration sans verser dans l'ingestion aveugle d'open 
data. On peut largement faire évoluer Pifomètre pour changer d'échelle (la 
commune au lieu de la rue, etc) mais en aucun cas ça ne nous dispensera de 
contrôler finement ce qu'on fait, en s'interdisant les uploads aveugles par un 
bot. Parlons *d'intégration* massive dans ce cas, ou tout autre terme non 
ambigu, mais tant que le sujet sera un *import* avec tes postulats actuels, je 
n'y souscrirai pas.

merci

vincent

[1] 
:https://forum.openstreetmap.fr/t/a-quand-des-imports-automatiques-des-bal/9012

___
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] présentation

2023-04-25 Thread Christian Rogel 


> Le 25 avr. 2023 à 12:08, Bernard Lefrançois via Talk-fr 
>  a écrit :
> 
> Le 24/04/2023 à 22:48, Christian Rogel a écrit :
>> C’est comme qu’on peut voir qu’ « associated_street » ne fait « l’unanimité 
>> » qu’en France (c’est un gimmick Fr de se précipiter sur ce qui semble plus 
>> malin). 
> 
> L'unanimité, c'est pas un peu vite dit?
> Bon, c'était entre guillemet. Ironique?

Oui, c’était ironique, mais, c’est pour marquer qu’on a lu des plaidoyers pour 
associated_street, mais pas pour la manière originelle.
Dans la vraie vie, c’est iD est largement utilisé et son interface favorise la 
« tradition », car mettre une relation est un poil plus compliqué.
On a eu ouï dire qu’une majorité de la communauté d’Allemagne (quid des 
Autrichiens ou des Suisses ?) préférait ne pas mettre de relation.
Je rattache les numéros manquants à une relation, s’il y en a une, et je fais 
les nouveaux adressages à la paresseuse.

Christian R.

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

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Vincent de Château-Thierry 
Bonjour,

> De: "Marc_marc" 
> 
> Suite à l'accueil favorable sur le principe, je poursuis
> la discussion entamé [2] il y a quelques mois lié à la procédure
> https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines


> je propose de diviser l'import en plusieurs tranches
> et de discuter uniquement de la première tranche :
> 
> Étendue de l'import de la première tranche
> - le nom de la rue est présente dans osm, identique à celui
> de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel
> tel que visible avec la colonne "adresse BAN avec voie rapprochée %"
> sur le pifomètre [1]
> - le taux de certification de 100% tel que visible avec la colonne "%
> adresses certifiées BAN" sur le pifomètre [1]
> - j'avais proposé "la rue dans osm ne contient aucune addr" : certains
> ont suggéré de commencer avec ce critère sur l'étendue de la commune.
> le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm
> 
> A voir s'il y a beaucoup de communes avec 100% adresses certifiées +
> 100% voies adressée rapprochée + pas d'adresse dans osm :)
> mais c'est une première tranche
> 
> Questions :
> 
> - faut-il ajouter des critères de qualité ? par ex dans le passé,
> ce n'était pas rare d'avoir plusieurs adresses au même endroit.
> il n'y a pas eu de retour sur ce point que je propose de supprimer
> sauf si quelqu'un souhaite le conserver.
> J'espère que ce problème a disparu avec la certification
> mais un retour est bienvenu si ce n'est pas le cas.

La certification n'est hélas en aucun cas un critère de qualité. Il y a eu 
différents retours d'expérience là-dessus, notamment sur le canal OSM-Fr 
matrix/telegram et aussi sur le forum où ce post couvre le même sujet [1].
En version courte : la certification est auto-déclarative et l'aspect 
géométrique est loin d'être au cœur des préoccupations des communes, plus 
focalisées sur l'inventaire. Donc partir sur ce critère comme un filtre 
d'adresses fiables et sujettes à import est biaisé dès le départ : on se trompe 
de postulat.

> - la position des addr est souvent flottante tandis que d'autres
> voudraient les voir au moins en bordure du bâtiments concernées.
> Il avait été proposé de sortir cette question hors de l'import
> et d'importer avec la position actuelle de l'opendata

Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import, on 
photocopie l'OpenData de la BAN. C'est vraiment regrettable je trouve. Parmi 
nos valeurs ajoutées sur le sujet des adresses par rapport à la BAN il y a :
- garantir la bonne orthographe des noms de voies (dans la BAN c'est un poème, 
défauts d'accents, défauts de majuscules, etc)
- assigner à chaque adresse une position cohérente avec notre propre graphe et 
nos bâtiments, donc potentiellement retoucher les coordonnées (manuellement, 
car non il n'y a aucune magie pour ce genre d'opération)
- filtrer les données sources : ne pas ajouter dans OSM des numéros assignés à 
une autre voie et totalement erronés dans leur affectation et leur position, 
sans parler des 5xxx et 9xxx

Donc je tempère l'accueil favorable dont tu parles au début, et qui se base 
sur... 3 réponses. Personnellement je ne suis pas favorable à un tel import, 
mais ça ne devrait pas étonner par ici : si j'ai conçu Pifomètre c'est 
justement pour ne pas encourager les imports, tout en proposant un outil pour 
mécaniser le travail d'intégration sans verser dans l'ingestion aveugle d'open 
data. On peut largement faire évoluer Pifomètre pour changer d'échelle (la 
commune au lieu de la rue, etc) mais en aucun cas ça ne nous dispensera de 
contrôler finement ce qu'on fait, en s'interdisant les uploads aveugles par un 
bot. Parlons *d'intégration* massive dans ce cas, ou tout autre terme non 
ambigu, mais tant que le sujet sera un *import* avec tes postulats actuels, je 
n'y souscrirai pas.

merci

vincent

[1] : 
https://forum.openstreetmap.fr/t/a-quand-des-imports-automatiques-des-bal/9012

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

Re: [OSM-talk-fr] [import] import partiel des adresses en France

2023-04-25 Thread Marc_marc 

Bonjour,

Suite à l'accueil favorable sur le principe, je poursuis
la discussion entamé [2] il y a quelques mois lié à la procédure
https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines

je propose de diviser l'import en plusieurs tranches
et de discuter uniquement de la première tranche :

Étendue de l'import de la première tranche
- le nom de la rue est présente dans osm, identique à celui
de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel
tel que visible avec la colonne "adresse BAN avec voie rapprochée %"
sur le pifomètre [1]
- le taux de certification de 100% tel que visible avec la colonne "% 
adresses certifiées BAN" sur le pifomètre [1]
- j'avais proposé "la rue dans osm ne contient aucune addr" : certains 
ont suggéré de commencer avec ce critère sur l'étendue de la commune.

le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm

A voir s'il y a beaucoup de communes avec 100% adresses certifiées + 
100% voies adressée rapprochée + pas d'adresse dans osm :)

mais c'est une première tranche

Questions :

- faut-il ajouter des critères de qualité ? par ex dans le passé,
ce n'était pas rare d'avoir plusieurs adresses au même endroit.
il n'y a pas eu de retour sur ce point que je propose de supprimer
sauf si quelqu'un souhaite le conserver.
J'espère que ce problème a disparu avec la certification
mais un retour est bienvenu si ce n'est pas le cas.

- il utile de pouvoir différentier les addr ayant été importée
de celle ayant été manipulée par un contributeur osm
pour cela je propose d'utiliser le tag volatil created_by=import.
l'avantage de ce tag comparé à la veille méthode du tag source
sur l'objet, c'est qu'il est volatil et donc dès qu'un contributeur
modifiera l'objet osm, l'ancienne source "bal" disparaîtra
automatiquement au lieu de garder des source=bal sur des objets
ayant des infos différente de celle de la source renseigné.
le côté volatil de ce tag est supporté par iD, josm et sûrement
d'autres éditeurs.
il avait été signalé que cela ne respecte le sens du tag
que si on y met le nom du programme ayant servit à l'import,
par ex AddrFranceBot

- on importe avec des addr:street (plus facile pour l’utilisateur
dans l'état actuel des outils) ou en associatedStreet (beaucoup
plus facile pour permettre de trouver les addr ayant + d'un
nom de voie (soit différent noms en attendant de lever l’incertitude,
soit des noms multilingue comme certains rues en Bretagne)
les avis étaient mitigés, la relation associatedStreet garde
les faveurs mais il faudra voir si c'est possible de générer
ces relations dans le cadre d'un import comme le fait le pifomètre.

- la position des addr est souvent flottante tandis que d'autres
voudraient les voir au moins en bordure du bâtiments concernées.
Il avait été proposé de sortir cette question hors de l'import
et d'importer avec la position actuelle de l'opendata

Quand ces questions seront traitées, je créerai la page wiki
de doc nécessaire à la procédure

[1] https://bano.openstreetmap.fr/pifometre/stats_dept.html#dept=01
[2] 
https://lists.openstreetmap.org/pipermail/talk-fr/2022-August/105638.html


Cordialement,
Marc



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

Re: [OSM-talk-fr] présentation

2023-04-25 Thread Bernard Lefrançois via Talk-fr 

Le 24/04/2023 à 22:48, Christian Rogel a écrit :
C’est comme qu’on peut voir qu’ « associated_street » ne fait « 
l’unanimité » qu’en France (c’est un gimmick Fr de se précipiter sur 
ce qui semble plus malin). 


L'unanimité, c'est pas un peu vite dit?
Bon, c'était entre guillemet. Ironique?


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

Re: [OSM-talk-fr] Import d'adresses à Andernos (relation associated-street)

2023-04-25 Thread Vincent de Château-Thierry 
Bonjour,

> De: "Cyrille37 OSM" 
 
> J'utilise le plugin "cadastre" de JOSM qui gère très bien les relations
> associated-street.
> 
> On sélectionne l'outil dans la barre ce qui ouvre une petite fenêtre
> pour paramètrer la numérotation. On clique sur un way ce qui commence
> (ou réutilise) une relation associated-street, puis on clique sur les
> emplacements pour créer les housenumber.
> 
> La doc :
> https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/Cadastre-fr#Utilitaire_de_saisie_des_adresses

> On 25/04/2023 11:21, Bruno Remy via Talk-fr wrote:
>> Bonjour,
>> Je lis que vous suggérez d'utiliser la relation associated-street.Je suis 
>> plus
>> partisan du tag addr:street.
>> Rajouter une relation à chaque noeud nécessite une opération manuelle sur 
>> chaque
>> noeud, ce qui est laborieux quand on travaille sur un ensemble de noeuds par
>> exemple à l'échelle d'une ville. Je me vois mal créer des centaines de
>> relations une par une à la main...
>> En manipulant les données d'un fichier JSON ou CSV on peut plus facilement
>> attribuer au noeud le tag addr:street correspondant au nom de la rue présent
>> dans le fichier source de BANO.
>> Vous voyez ce que je veux dire?
>> Je cherche une solution qui associe l'intégrité des données (donc le numéro 
>> et
>> le nom de la rue je suis d'accord avec vous) et la simplicité de manipulation
>> des données.

Bienvenue Bruno
Pour ajouter des adresses j'ai conçu l'outil "Pifomètre" dont un des buts est 
d'éviter les nombreuses opérations manuelles et clics que peut générer la 
saisie des adresses.
Pifomètre est organisé par commune. Pour Andernos voici le lien : 
https://bano.openstreetmap.fr/pifometre/index.html#insee=33005=0
Pour une présentation des fonctionnalités il existe entre autres cette 
description : 
https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Interface_de_contr%C3%B4le_et_de_saisie_Fantoir/OSM
 et cette video de présentation : 
https://peertube.openstreetmap.fr/w/viNLdwLGw3AMdcUT1V8ba2

merci
vincent

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

Re: [OSM-talk-fr] Import d'adresses à Andernos (relation associated-street)

2023-04-25 Thread Cyrille37 OSM 

Bonjour

J'utilise le plugin "cadastre" de JOSM qui gère très bien les relations 
associated-street.


On sélectionne l'outil dans la barre ce qui ouvre une petite fenêtre 
pour paramètrer la numérotation. On clique sur un way ce qui commence 
(ou réutilise) une relation associated-street, puis on clique sur les 
emplacements pour créer les housenumber.


La doc : 
https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/Cadastre-fr#Utilitaire_de_saisie_des_adresses


Cyrille37.

On 25/04/2023 11:21, Bruno Remy via Talk-fr wrote:

Bonjour,
Je lis que vous suggérez d'utiliser la relation associated-street.Je suis plus 
partisan du tag addr:street.
Rajouter une relation à chaque noeud nécessite une opération manuelle sur 
chaque noeud, ce qui est laborieux quand on travaille sur un ensemble de noeuds 
par exemple à l'échelle d'une ville. Je me vois mal créer des centaines de 
relations une par une à la main...
En manipulant les données d'un fichier JSON ou CSV on peut plus facilement 
attribuer au noeud le tag addr:street correspondant au nom de la rue présent 
dans le fichier source de BANO.
Vous voyez ce que je veux dire?
Je cherche une solution qui associe l'intégrité des données (donc le numéro et 
le nom de la rue je suis d'accord avec vous) et la simplicité de manipulation 
des données.
Cordialement


---
Bruno REMY
bruno.r...@ymail.com
06 87 44 65 81
___
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: [Talk-it-lazio] Incontro dei mappatori romani e laziali - 3 maggio 2023

2023-04-25 Thread Martin Koppenhoefer 


sent from a phone

> On 25 Apr 2023, at 11:16, Flaminia Tumino  wrote:
> 
> Il mapping party e' spostato di una settimana a mercoledì prossimo, 3 maggio.


ottimo, grazie Flaminia, io ci sarò. 
https://osmcal.org/event/2019/___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

[OSM-talk-fr] Import d'adresses à Andernos

2023-04-25 Thread Bruno Remy via Talk-fr 
Bonjour,
Je lis que vous suggérez d'utiliser la relation associated-street.Je suis plus 
partisan du tag addr:street.
Rajouter une relation à chaque noeud nécessite une opération manuelle sur 
chaque noeud, ce qui est laborieux quand on travaille sur un ensemble de noeuds 
par exemple à l'échelle d'une ville. Je me vois mal créer des centaines de 
relations une par une à la main... 
En manipulant les données d'un fichier JSON ou CSV on peut plus facilement 
attribuer au noeud le tag addr:street correspondant au nom de la rue présent 
dans le fichier source de BANO.
Vous voyez ce que je veux dire?
Je cherche une solution qui associe l'intégrité des données (donc le numéro et 
le nom de la rue je suis d'accord avec vous) et la simplicité de manipulation 
des données.
Cordialement


---
Bruno REMY
bruno.r...@ymail.com
06 87 44 65 81
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it-lazio] Incontro dei mappatori romani e laziali - 3 maggio 2023

2023-04-25 Thread Flaminia Tumino 
Ciao a tutt*,
errata corrige.
Il mapping party e' spostato di una settimana a mercoledì prossimo, 3
maggio.

A presto,
Flaminia

Il giorno mar 25 apr 2023 alle ore 09:15 Flaminia Tumino <
flaminiatum...@gmail.com> ha scritto:

>
> Ciao a tutt*,
> vi ricordo l'appuntamento di domani.
>
> Flaminia
>
>
> Ciao a tutt*,
> con le temperature miti ricominciamo a mappare in giro!
> Malgrado Monti sia abbastanza mappato, all'ultimo mapping party abbiamo
> trovato che ci sono tanti cambiamenti che non sono stati riportati su
> openStreetMap, quindi continuiamo in quella zona.
> Appuntamento come al solito ai piedi della fontana in piazzetta alle 19.30
> Qui sotto il link dell'evento:
>
> https://osmcal.org/event/2019/
>
>  A presto,
> Flaminia
>
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

[Talk-it-lazio] Fwd: Incontro dei mappatori romani e laziali - 26 aprile 2023

2023-04-25 Thread Flaminia Tumino 
Ciao a tutt*,
vi ricordo l'appuntamento di domani.

Flaminia


Ciao a tutt*,
con le temperature miti ricominciamo a mappare in giro!
Malgrado Monti sia abbastanza mappato, all'ultimo mapping party abbiamo
trovato che ci sono tanti cambiamenti che non sono stati riportati su
openStreetMap, quindi continuiamo in quella zona.
Appuntamento come al solito ai piedi della fontana in piazzetta alle 19.30
Qui sotto il link dell'evento:

https://osmcal.org/event/2019/

 A presto,
Flaminia
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio