Re: [OSM-talk-fr] Ancestris

[Philippe Verdy]

Maintenant j'ai de gros doute si je lis cette page, concernant les échanges
de données:
https://docs.ancestris.org/books/mode-demploi/page/informations-partag%C3%A9es

Il n'y est fait strictement aucune mention du droit des personnes vivantes
ou décédées depuis peu de temps. Hors les données sont riches: profession,
religion, enfants, alliances, numéro d'identité ou de sécurité sociale,
célébrations religieuses, divorces, requêtes en divorce, certifications ou
autorisations, diplômes, immigration/émigration, caste, résidence,
retraite, propriété ou patrimoine. Il ne manque plus que les revenus et les
préférences ou pratiques sexuelles, ou encore si la personne préfère la
vanille ou la fraise, ou quelle chaine TV elle regarde: pratiquement toute
la vie ou le CV découvert sur une personne est étalé, "outé" publiquement,
et partagé sans aucune forme de restriction (et sans droit à l'oubli, au
moins le temps de la vie de cette personne) :
https://docs.ancestris.org/books/mode-demploi/page/les-%C3%A9v%C3%A9nements
Le seule critère exigé c'est la conformité à un format technique GEDCOM
pour ces échanges, ce qui ne limite en fin de compte pas grand chose.
Et absolument rien dans GEDCOM ne permet de qualifier les données pour
savoir celles soumises à des restrictions d'usage, c'est totalement passé à
la trappe. Cette spécification technique semble être née dans des pays qui
se fichent pas mal de la protection de la vie privée (mais même dans nombre
d'entre eux c'est en train de changer, y compris aux USA); en l'état et
sans le protocole qu'elle devrait imposer dans les applications conformes,
l'usage de cette pseudo-norme seule est aujourd'hui illégal dans plein de
pays; mais rien dans cette appli ne met en garde les utilisateurs sur le
fait qu'ils ont une responsabilité et ne devraient pas échanger n'importe
quoi à n'importe qui sans autorisation explicite et vérifiable (et sans
sous-délégation à des tiers non autorisés, comme ce peut-être le cas pour
le seul logiciel mais pas les données manipulées)





Le sam. 30 mai 2020 à 03:44, Philippe Verdy  a écrit :

> J'ai du mal à croire à une "généalogie libre" si elle met en base de
> données "libre" des personnes vivantes (sans leur accord) ou décédées
> depuis moins de 70 ans (ou leurs ayant-droits).
>
> Une telle base de données nominative devrait faire l'objet d'une
> déclaration à la CNIL, surtout si en plus on y attache des infos comme les
> dates de naissance, lieu de naissance, liens avec d'autres personnes
> vivantes, professions, lieux de travail, écoles ou entreprises,
> mariages/partenariats/concubinages, enfants, et en aucun cas une
> distribution libre, mais un accord de licence personnelle pour un usage
> bien précis encadré par la loi et interdisant l'exploitation en masse (à
> des fins commerciales par exemple). Hors si on doit restreindre l'usage de
> ces données, ces données ne sont nécessairement pas libres.
> En revanche cela peut être utile seulement pour les recherches sur les
> personnes décédées depuis longtemps et sans ayant-droit, dont les données
> peuvent alors devenir publiques.
>
> Bref toute personne mentionnée qui n'est pas décédée avant 1950
> (aujourd'hui) ne devrait pas être du tout dans cette base de données, et
> pour avoir les données, il faudrait faire des démarches personnelles auprès
> de l'Insee ou l'état-civil, précisant la finalité, et avec un engagement
> contractuel (et pénal) signé auprès de l'autorité, contre les mauvaises
> utilisations: le respect de la vie privée s'impose...
>
> Je ne sais pas trop quels sont vos termes d'utilisation et ce que
> contiennent les bases de données que vous développez, et encore mois si
> c'est légal d'échanger entre "généalistes autodéclarés" sur des forums
> publics pour obtenir de telles informations sans l'accord des personnes
> nommées (et même si ces personnes figurent dans un annuaire publié, leur
> exploitation à cette fin est aussi soumise aux règles de droit et
> contractuelles de ces annuaires que ce soit l'annuaire téléphonique
> universel, les fichiers postaux, des adresses mail ou liens vers des pages
> perso sur des réseaux sociaux, eux aussi protégés par leur éditeur selon
> leurs termes d'utilisation).
>
> Quelles précautions prenez-vous? Le copyright concernant les données OSM
> ou les illustrations n'est pas la seule condition, ou la licence de votre
> logiciel, c'est une partie seulement des droits à respecter.
> Bref espérons que ce soit déjà étudié.
>
> Le ven. 29 mai 2020 à 22:02, Yannick  a écrit :
>
>> Bonsoir,
>>
>> La carte des utilisateurs d'Ancestris, logiciel de généalogie, vient
>> d'être mise à jour avec OSM.
>> Dans le coin bas droite il a été mis un lien vers la page de la licence
>> j'espère que cela suffit.
>>
>> Maintenant Ancestris est entièrement OSM dans le logiciel ET sur le site.
>>
>> Amitiés
>>
>> --
>> Yannick VOYEAUD
>> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
>> (Camille JOUFFRAY 1841-1924, maire de Vienne)
>> 

Re: [OSM-talk-fr] Ancestris

[Philippe Verdy]

J'ai du mal à croire à une "généalogie libre" si elle met en base de
données "libre" des personnes vivantes (sans leur accord) ou décédées
depuis moins de 70 ans (ou leurs ayant-droits).

Une telle base de données nominative devrait faire l'objet d'une
déclaration à la CNIL, surtout si en plus on y attache des infos comme les
dates de naissance, lieu de naissance, liens avec d'autres personnes
vivantes, professions, lieux de travail, écoles ou entreprises,
mariages/partenariats/concubinages, enfants, et en aucun cas une
distribution libre, mais un accord de licence personnelle pour un usage
bien précis encadré par la loi et interdisant l'exploitation en masse (à
des fins commerciales par exemple). Hors si on doit restreindre l'usage de
ces données, ces données ne sont nécessairement pas libres.
En revanche cela peut être utile seulement pour les recherches sur les
personnes décédées depuis longtemps et sans ayant-droit, dont les données
peuvent alors devenir publiques.

Bref toute personne mentionnée qui n'est pas décédée avant 1950
(aujourd'hui) ne devrait pas être du tout dans cette base de données, et
pour avoir les données, il faudrait faire des démarches personnelles auprès
de l'Insee ou l'état-civil, précisant la finalité, et avec un engagement
contractuel (et pénal) signé auprès de l'autorité, contre les mauvaises
utilisations: le respect de la vie privée s'impose...

Je ne sais pas trop quels sont vos termes d'utilisation et ce que
contiennent les bases de données que vous développez, et encore mois si
c'est légal d'échanger entre "généalistes autodéclarés" sur des forums
publics pour obtenir de telles informations sans l'accord des personnes
nommées (et même si ces personnes figurent dans un annuaire publié, leur
exploitation à cette fin est aussi soumise aux règles de droit et
contractuelles de ces annuaires que ce soit l'annuaire téléphonique
universel, les fichiers postaux, des adresses mail ou liens vers des pages
perso sur des réseaux sociaux, eux aussi protégés par leur éditeur selon
leurs termes d'utilisation).

Quelles précautions prenez-vous? Le copyright concernant les données OSM ou
les illustrations n'est pas la seule condition, ou la licence de votre
logiciel, c'est une partie seulement des droits à respecter.
Bref espérons que ce soit déjà étudié.

Le ven. 29 mai 2020 à 22:02, Yannick  a écrit :

> Bonsoir,
>
> La carte des utilisateurs d'Ancestris, logiciel de généalogie, vient
> d'être mise à jour avec OSM.
> Dans le coin bas droite il a été mis un lien vers la page de la licence
> j'espère que cela suffit.
>
> Maintenant Ancestris est entièrement OSM dans le logiciel ET sur le site.
>
> Amitiés
>
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris http://www.ancestris.org
>
>
> ___
> 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-au] [OSGeo Oceania] resignation from OSGeo Oceania

[adam steer]

Hi John

Thanks for all your hard work and steady navigation of many complex issues.
I’m sorry to see you step down, I really appreciate your ‘radical
open-ness’ approach - which I think is critical for this organisation - and
ethical stance. I (selfishly) hope you find the energy to help with the
outreach and comms working group when you can!

Regards,

Adam



On Sat, 30 May 2020 at 08:39, John Bryant  wrote:

> Hi folks, just a quick note to let you know that I decided yesterday to
> resign from the OSGeo Oceania board of directors. I won't be continuing
> with board business, but I'll continue to contribute as a community member
> however I can.
>
> Looking forward to continuing to work on this awesome community with you
> all.
>
> Cheers
> John
> ___
> Oceania mailing list
> ocea...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/oceania
>


-- 
Dr. Adam Steer
http://spatialised.net
https://www.researchgate.net/profile/Adam_Steer
http://au.linkedin.com/in/adamsteer
http://orcid.org/-0003-0046-7236
+61 427 091 712 ::  @adamdsteer

Suits are bad for business: http://www.spatialised.net/business-penguins/
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] resignation from OSGeo Oceania

[Edoardo Neerhut]

Very sad to hear the news John, but you've been an incredibly positive
force in the community.

Thanks for making OSGeo Oceania possible. Thank you also for your
positivity, willingness to hear all points of view, and tireless
persistence.




On Sat, 30 May 2020, 08:40 John Bryant,  wrote:

> Hi folks, just a quick note to let you know that I decided yesterday to
> resign from the OSGeo Oceania board of directors. I won't be continuing
> with board business, but I'll continue to contribute as a community member
> however I can.
>
> Looking forward to continuing to work on this awesome community with you
> all.
>
> Cheers
> John
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Philippe Verdy]

La question peut se poser sur le rendu des nœuds place=* (qui sont toujours
une approximation et jamais non plus tous affichés: lesquels sont les plus
pertinents c'est une question de choix ou de goût, mais effacer les noms
des nœuds des communes déléguées pour les replacer par les noms des
communes nouvelles est un mauvais choix: je préfère nettement qu'on sépare
ces nœuds, même s'ils sont très proches car le chef-lieu est le même; mais
en tout cas ne pas toucher aux relations des communes déléguées qui doivent
conserver leur intégrité géométrique, juste changer leurs attributs, et
garder leur nœud place là où il est; puis créer d'autres relations pour les
communes nouvelles avec leur propre nœud place=*)

Reste ensuite à savoir comment différencier les nœuds place=* ?

Ou quels autres attributs si ce sont tous les deux des "place=village" par
exemple, alors que pour nombre de communes nouvelles, cela reste un
ensemble de villages, séparés par un espace hors agglomération ?
Que dire alors des nœuds place dans les grandes agglomérations où les
communes se touchent ? Le noeud place=* ne désigne pas là non plus le
centre de population (pas plus qu'il ne représentent les enclaves externes
au polygone dit "principal" où se situe la "mairie" dans la relation, et
qui n'est pas nécessairement partout non plus le plus grand!) et est
toujours une approximation grossière, assez subjective.

Quelle priorité de rendu alors entre les nœuds (selon leurs autres
attributs), c'est selon le moteur de rendu de cartographie et ce qu'on a
voulu représenter ou pas.

Au final il n'y a que les relations qui sont exactes, pas les nœuds
"place=*" qui sont juste de vagues "centroïdes" et pas non plus exactement
le lieu du centre administratif (qui peut lui-même être éclaté sur
plusieurs sites: ancien hôtel de ville de prestige, salle de réunion du
conseil municipal, accueil du public dans plusieurs sites ou quartiers avec
les mairies annexes, pôles administratifs internes, éventuellement même
installé hors du territoire communal et partagé sur un site partagé par
plusieurs communes, par exemple dans l'hôtel intercommunal, qui finalement
va gérer aussi les points d'accueil des quartiers et communes membres,
pôle de communication sur Internet, qui peut aussi être externalisé sur un
site régional, ou même chez un prestataire technique même pas
nécessairement français mais européen en raison des conditions des marchés
publics...).

Si on devait retenir une utilité encore aux nœuds "place" ce serait non pas
pour désigner les communes au sens administratif (ou toute autre entité),
mais les pôles urbains au sens du découpage urbain de l'Insee, sans tenir
compte strictement du découpage communal ou des autres niveaux de
collectivités. Mais là encore on peut faire mieux et cartographier la
géométrie des découpages urbains (cela a déjà commencé pour la
signalisation routière des "agglomérations" au sens du code de la route).



Le ven. 29 mai 2020 à 15:29, Yann-Gaël LARGILLET  a
écrit :

> Merci pour vos retours !
>
> Je regarde ce que je peux faire avec tous vos messages ! Car j'ai donc
> fait des erreurs !
>
> Concernant le débat "communes nouvelles pas dans les moeurs" ou autres, ça
> reste des interprétations individuelles non ?
>
> Si le panneau est présent, on modifie selon la réalité du terrain ? J'en
> étais resté sur ce principe de base...
>
> Bonne journée à vous,
>
> Yann-Gaël
> ---
> "Lentius, Profundius, Suavius" (A.Langer)
>
>
> Le 29/05/2020 13:11, Marc M. a écrit :
>
> Bonjour,
>
> Le 29.05.20 à 11:37, Rpnpif via Talk-fr a écrit :
>
> Va falloir forker la carte OSM ;).
>
>
> plus modestement : regarder la visibilité sur le rendu fr et hot
> et proposer des tickets ou mieux des PR pour l'améliorer.
>
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[talk-au] resignation from OSGeo Oceania

[John Bryant]

Hi folks, just a quick note to let you know that I decided yesterday to
resign from the OSGeo Oceania board of directors. I won't be continuing
with board business, but I'll continue to contribute as a community member
however I can.

Looking forward to continuing to work on this awesome community with you
all.

Cheers
John
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-legal-talk] Legal questions about using OSM

[Kathleen Lu via legal-talk]

My personal take (not official guidance):

Question 1:
If I store calculated results based on OSM data in a database table
(without the actual OSM data itself), such as the number of specific
POIs, travel times, travel distances and so on - the database is then a
collective database, a derivative database, a "produced work", or none of
them?

For a count of the number of specific POIs in an area, travel times between
two points, or travel distances between two points, I would say "none of
them", because these types of calculated data points would not actually
contain any data from the OSM database, and thus not be covered by
copyright or database rights law, the rights that ODbL licenses.

Question 2:
Does the calculation of the above described results complies with the
statement: "you geocoded your data"?

No. Geocoding and Geocoding Results have specific meanings, as indicated in
the Geocoding Guidelines.

Question 3:
If I reference other data with the data from this result database, do I
have to put the referenced data under the ODBL license? For the case
that the answer to Question 1 would be collective or a "produced work"?
In case of derivative, I guess the database must be under ODBL...

Your reasoning is correct, but of course, since my answer to 1 is "none of
them", the answer to this question would be "no"



On Mon, May 25, 2020 at 6:42 AM "Birger Schütte" via legal-talk <
legal-talk@openstreetmap.org> wrote:

> Hello to all!
>
> I would like to apologize for asking again, but unfortunately the answer
> did not help me.
> I realize that the use cases are not the ultimate recommendation.
> Therefore I had additionally relied on the
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines.
> I am examining the use of OSM in various tools - this is where these
> questions came up.
> And therefore it would be important for me to understand from when on
> which kind of use of the data leads to the cases mentioned in the questions
> (collective, derivative and so on).
> I have even interviewed a lawyer, but so far with rather little success.
> :-(
>
> So here are my 3 most important still open questions again:
> Question 1:
> If I store calculated results based on OSM data in a database table
> (without the actual OSM data itself), such as the number of specific
> POIs, travel times, travel distances and so on - the database is then a
> collective database, a derivative database, a "produced work", or none of
> them?
>
> Question 2:
> Does the calculation of the above described results complies with the
> statement: "you geocoded your data"?
>
> Question 3:
> If I reference other data with the data from this result database, do I
> have to put the referenced data under the ODBL license? For the case
> that the answer to Question 1 would be collective or a "produced work"?
> In case of derivative, I guess the database must be under ODBL...
>
> Since I haven't had any luck deriving answers to my questions from the
> Community_Guidelines so far, I hope it wouldn't be too much trouble if I
> could possibly get answers to every single question?
> Many thanks for every effort in advance!
>
> Kindly Regards
> Birger
>
> Date: Mon, 18 May 2020 11:14:14 +0200
> From: Simon Poole 
> To: legal-talk@openstreetmap.org
> Subject: Re: [OSM-legal-talk] Legal questions about using OSM
> Message-ID: <9c917920-39c1-03c0-59a4-d0f47fc0e...@poole.ch>
> Content-Type: text/plain; charset="utf-8"
>
> You are unnecessarily making your life hard. There is a big red warning
> at the top of the "Use Cases" page, simply take it seriously (the
> content of that page was written in 2012 a rather long time ago and
> before any of the guidelines existed). The current relevant guidelines
> are available from
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines
>
> In your specific case, as it seems you are not actually geocoding your
> data (that would be extracting address or location information from OSM
> with 3rd party data), that would be the Produced Work and Collective
> Database guidelines.
>
> Simon
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Florimond Berthoux]

Le ven. 29 mai 2020 à 16:09, Éric Gillet  a
écrit :

> Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :
>
> Il me semble important de rappeler qu’OpenStreetMap n’est pas une base de
> donnée légale, on ne tag pas la lois.
> On ne tag pas la loi parce que nous ne sommes pas des juges et que si les
> juges existent c’est parce que la loi est interprétative.
>
> Bien entendu qu'on taggue la loi, et heureusement ! Physiquement rien
> n'empêche un vélo d'utiliser une autoroute, c'est juste dangereux et
> illégal. Donc on cartographie l'interdiction via highway=motorway.
>
> Idem pour les limites de vitesse, les zones privées, les bases militaires,
> et limites administratives etc etc.
>
> Et j’aimerai qu’on évite de s’embarquer dans des débats de juriste stérile.
>
> Moi aussi c'est ma plus grande volonté, cf mon dernier message du
> changeset.
>
> Est-ce qu’il y a un panneau qui interdit d’y pédaler ? -> non
>
> Pas besoin, c'est interdit par défaut en agglomération (trottoirs et
> assimilés). Ce serait inimaginable de mettre un panneau interdiction de
> pédaler sur tous les trottoirs.
>
> Est-ce que les cyclistes y roulent sans jamais se faire verbaliser ? -> oui
> -> bicycle=yes
>
> Les forces de l'ordre ne connaissent pas trop le code de la route sur
> l'utilisation des aménagements vélo. Bon nombre circulent sans avertisseurs
> (gyrophare/sirène) dans les voies bus/vélo.
> Mais aussi de très nombreux cyclistes grillent des feux/stop, utilisent
> des téléphones sans jamais se faire verbaliser. Cela rends la chose pas
> moins illégale ou dangereuse.
>
Il y a une différence j'ai vu plusieurs fois des cyclistes se faire
verbaliser pour grillage de feu, y-a-t-il eu une seule fois une
verbalisation pour avoir roulé sur cette espace ?

> Il me semble que footway+bicycle=yes indique bien qu’il y a un problème
> d’aménagement (normalement ça ne devrait pas exister sur un axe de transit
> vélo).
>
> Oui en effet ça indique que l'axe de transit n'est pas continu, mais en
> soit c'est pas gravissime si c'est correctement signalisé et qu'il n'y a
> pas de dangers. Là ce n'est ni correctement signalisé, ni sécurisé.
>
> Mettre bicycle=yes masque ce problème, et empêche les cyclistes d'avoir
> cette info et d'emprunter d'éventuels chemins plus sécurisés/rapides.
>
Non, bicycle=yes signifie que c'est "légalement" (de facto) possible ça ne
dit rien de la dangerosité de la chose.
Pour dire que ce n'est pas sécurisé faudra utiliser un ou des autres tag.

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

Salut Nicolas,

Voilà la version complète:

http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson

Antonin

On 29/05/2020 17:07, Nicolas Bétheuil wrote:
> Les évolutions / correctifs avancent. Je pousse régulièrement.
> Écrivez moi directement, je verrais si je fais une diffusion
> spécifique pour vous gardez informé des nouveautés.
>
> Christian a ajouté od2osm au proxy IGN ! Merci !
>
> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent plus
> qu'on cause ensemble, je te propose de continuer en issue github
> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
> points, loin des 12 000 points que tu avais évoqué.
>
> Le mer. 27 mai 2020 à 12:02, Yves P.  > a écrit :
>
>> Les "name" ont été enlevés du jeu de données et l 'outil affiche
>> maintenant soit name soit ref (en fonction de ce qui existe)
>> J'ai ajouté le fond de carte BD Ortho
> Merci :)
>
>>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
>> proxy
>> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
> ici ça marche aussi ;)
>
> Pour info, MyOSMatic (maposmatic) sort des carte
>  des PEIs : le
> résultat est plutôt bien :)
> Il faut revoir la taille des réserves incendie et des DAE, et
> éventuellement l'adapter avec les symboles utilisés en France.
>
> __
> Yves
> ___
> 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


pEpkey.asc
Description: application/pgp-keys
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Ancestris

[Yannick]

Bonsoir,

La carte des utilisateurs d'Ancestris, logiciel de généalogie, vient
d'être mise à jour avec OSM.
Dans le coin bas droite il a été mis un lien vers la page de la licence
j'espère que cela suffit.

Maintenant Ancestris est entièrement OSM dans le logiciel ET sur le site.

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org




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

Re: [Talk-it] [Import] civici Bergamo

[Lorenzo Mastrogiacomi]

Faccio notare che gli indirizzi sugli edifici a volte sono
proprietà  di negozi, hotel, farmacie, eccetera. Sono utili e vanno
preservati in qualche modo.https://overpass-turbo.eu/s/UwK

Lorenzo

Il giorno ven, 29/05/2020 alle 10.07 +0200, Andrea Musuruane ha
scritto:
> Cascafico, apprezzo la buona volontà, però,
> prima di fare QA, 
> possiamo concordare sul sistemare l'esistente, secondo quanto scritto
> sulla wiki?  
> 
> Una volta che siamo concordi (servono delle risposte da parte di
> molti a questa mail) bisogna informare la ML di import (mi prendo io
> questo onere).
> Altrimenti continuiamo a fare lo stesso errore che ha fatto gigi2037
> e ci avviamo a fare un revert.
> 
> Grazie,
> Andrea
> 
> 
> 
> 
> 
> On Fri, May 29, 2020 at 9:55 AM Cascafico Giovanni <
> cascaf...@gmail.com> wrote:
> > Adesso overpass dice 87, umap tutta verde :-)
> > 
> > Il giorno gio 28 mag 2020 alle ore 13:56 Andrea Musuruane <
> > musur...@gmail.com> ha scritto:
> > > Prima di continuare a fare QA, possiamo concordare sul sistemare
> > > l'esistente, secondo quanto scritto sulla wiki e di conseguenza
> > > informare la ML di import?
> > > 
> > > Per quanto riguarda gli esponenti numerici, sono 87 nel dataset
> > > del comune ma in OSM ce ne sono solo 66. Quindi ne mancano 21.
> > > 
> > > [out:json][timeout:25];
> > > area[name="Bergamo"][admin_level=8]->.searchArea;
> > > node["addr:housenumber"~"[0-9]+\/[0-9]+"](area.searchArea);
> > > out body;
> > > >;
> > > out skel qt;
> > > 
> > > Ciao,
> > > 
> > > Andrea
> > > 
> > > 
> > > 
> > > On Thu, May 28, 2020 at 1:37 PM Cascafico Giovanni <
> > > cascaf...@gmail.com> wrote:
> > > > Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap
> > > > dipo che mapnik ha aggiornato ci vorrebbe
> > > > 
> > > > Il gio 28 mag 2020, 12:08 Andrea Musuruane 
> > > > ha scritto:
> > > > > Li hai corretti tu?
> > > > > 
> > > > > Ciao,
> > > > > 
> > > > > Andrea
> > > > > 
> > > > > 
> > > > > 
> > > > > On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni <
> > > > > cascaf...@gmail.com> wrote:
> > > > > > Subalterni numerici dovrebbero essere risolti. Vedi wiki e
> > > > > > umap linkata.
> > > > > > 
> > > > > > Il mer 27 mag 2020, 11:08 Andrea Musuruane <
> > > > > > musur...@gmail.com> ha scritto:
> > > > > > > Ciao a tutti,
> > > > > > > ho provato a documentare questo import sulla wiki:
> > > > > > > https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
> > > > > > > 
> > > > > > > Se concordate, per procedere e mantenere i dati importati
> > > > > > > in OSM, bisogna fare tanta QA. I casi che ho trovato sono
> > > > > > > elencati nella wiki. Non escludo che lavorandoci più
> > > > > > > attivamente sopra, se ne scoprano altri.
> > > > > > > 
> > > > > > > Ciao,
> > > > > > > 
> > > > > > > Andrea
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane <
> > > > > > > musur...@gmail.com> wrote:
> > > > > > > > Ciao,
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni <
> > > > > > > > cascaf...@gmail.com> wrote:
> > > > > > > > > Ho standardizzato i civici, rimuovendo la barra e
> > > > > > > > > portando a maiusolo l'esponente.
> > > > > > > > 
> > > > > > > > Perché in maiuscolo?
> > > > > > > > 
> > > > > > > > Prima di continuare (chiunque), possiamo almeno
> > > > > > > > scrivere una pagina di import che descrivere le cose
> > > > > > > > fatte/da fare?
> > > > > > > > 
> > > > > > > > Lato mio posso: a) fare uno script di conversione con
> > > > > > > > ogr2osm b) suggerire di usare come modello la pagina di
> > > > > > > > import che avevo fatto per Biella 
> > > > > > > > https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
> > > > > > > > 
> > > > > > > > Grazie,
> > > > > > > > 
> > > > > > > > Andrea
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > ___
> > > > > > > 
> > > > > > > Talk-it mailing list
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Google Plus Code

[emmexx]

On 5/29/20 8:51 PM, Andrea Albani wrote:
> il codice di per sé è una bella idea, ma visto che è ricavabile in modo
> diretto da coordinate WGS84 con un semplice algoritmo, qual è il
> vantaggio di metterlo in un tag?

Avrei dovuto leggere con più attenzione, pensavo si trattasse di un
qualche codice ricavato dall'indirizzo più altro.
Se si tratta solo delle coordinate, ci penseranno i consumatori di dati.

grazie
maxx

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

Re: [Talk-it] Google Plus Code

[Andrea Falco]

 Se ti riferisci agli Open Location Code guardati questa conversazione:
https://lists.openstreetmap.org/pipermail/talk/2018-August/081120.html
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Google Plus Code

[Andrea Albani]

Ciao,

il codice di per sé è una bella idea, ma visto che è ricavabile in modo
diretto da coordinate WGS84 con un semplice algoritmo, qual è il vantaggio
di metterlo in un tag?

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

[Talk-it] Google Plus Code

[emmexx]

Google Plus Code è il sistema che genera un codice univoco che,
utilizzato in Google Maps, permette di identificare facilmente gli
indirizzi:

https://tech.slashdot.org/story/20/05/29/1457208/google-makes-sharing-plus-codes-easier-in-a-push-to-simplify-addressing-system-globally

Forse lo si può aggiungere a addr.

ciao
maxx

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

Re: [Talk-it] State of the Map 2020 - Call for Posters

[Anisa Kuci]

Ciao a tutti,

grazie Marco per aver condiviso il link.

Riporto l'attenzione su questo argomento perché penso che è importante 
avere presenza di OSM Italia a State of the Map.


Sarebbe bello avere un poster che rappresenti come la comunità italiana 
ha gestito l'intero periodo di pandemia, o che mostri le statistiche dei 
contributi, magari possiamo condividere e promuovere progetti come 
restiamoaperti.it o su.openstreetmap.it


Vedo molti altri progetti interessanti che i membri di OSM Italia hanno 
realizzato attivamente: progetti con le scuole, mappatura in bici, 
importazione di dati ecc.


Se qualcuno ha anche solo un'idea è più che benvenuto a condividerla e 
poi possiamo lavorare come comunità per portarla avanti.


Buona serata,

Anisa


On 5/21/20 9:01 PM, Marco Minghini wrote:

Ciao a tutti,
per chi non fosse già iscritto alla newsletter di State of the Map, 
segnalo che oggi è stata pubblicata la Call for Posters con scadenza 
30 giugno: https://2020.stateofthemap.org/calls/posters


I poster sono come sempre un'ottima occasione per pubblicizzare le 
attività e i progetti di cui ciascuno si occupa. Approfittate!

Ciao,
Marco

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


--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Nicolas Bétheuil]

Les évolutions / correctifs avancent. Je pousse régulièrement.
Écrivez moi directement, je verrais si je fais une diffusion spécifique
pour vous gardez informé des nouveautés.

Christian a ajouté od2osm au proxy IGN ! Merci !

@Jean-Yvon j'ai des mails qui reviennent, les machinent veulent plus qu'on
cause ensemble, je te propose de continuer en issue github
@Antonin Le jeu de données que tu m'avais envoyé avait moins de 90 points,
loin des 12 000 points que tu avais évoqué.

Le mer. 27 mai 2020 à 12:02, Yves P.  a écrit :

> Les "name" ont été enlevés du jeu de données et l 'outil affiche
> maintenant soit name soit ref (en fonction de ce qui existe)
>
> J'ai ajouté le fond de carte BD Ortho
>
> Merci :)
>
>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le proxy
> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
>
> ici ça marche aussi ;)
>
> Pour info, MyOSMatic (maposmatic) sort des
> carte
>  des PEIs : le résultat
> est plutôt bien :)
> Il faut revoir la taille des réserves incendie et des DAE, et
> éventuellement l'adapter avec les symboles utilisés en France.
>
> __
> Yves
> ___
> 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] Fwd: Re: Désaccord sur un highway=footway

[Éric Gillet]

Le 29/05/2020 à 17:26, Éric Gillet a écrit :

Le 29/05/2020 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :


S'ils avaient voulu signaler l'interdiction de continuer ils auraient 
mis un panneau d'interdiction "circulation interdite" B0 
.


Pas nécessaire, les vélo sont interdits par défaut pour les trottoirs. 
Autre exemple que j'ai capturé :


Pas de B0, mais j'invite un vélo à essayer d'aller à droite, ça envoie 
dans les passages piétons et ça débouche sur rien [1]



Je me suis trompé de lien, le voici :

[1] https://www.mapillary.com/map/im/xm3Vc9meCZXJKbGtFevM_w

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

Re: [OSM-talk-fr] Fwd: Re: Désaccord sur un highway=footway

[Éric Gillet]

Le 29/05/2020 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :

Je garderais le bicycle=yes, voire en designated.
Rien ne désigne le vélo comme autorisé sur cette place piétonne, ce 
serait encore moins adapté qu'un bicycle=yes. 


-1 : si on dit qu'ils ne sont pas prioritaires c'est qu'_ils sont 
autorisés_. A minima tolérés.


Alors oui le panneau n'est pas explicitement dans le code de la route 
mais c'est bien un panneau de signalisation routière de danger.


> Ce panonceau n'a aucune existence légale.

https://www.mapillary.com/map/im/6lubeDufWJhvkUBhpeADyA

C'est le panneau de danger A14 
. 
complété par le panneau M9 précisant le danger :


CYCLISTES
ATTENTION :
PIÉTONS PRIORITAIRES

J'ai pas été très clair. Le panneau existe bien dans le code de la 
route, mais son utilisation n'enclenche aucune obligation ou restriction 
particulière. C'est juste une information.



On termine aussi l'obligation de voie cyclable.

Qui est également une fin d'interdiction pour les piétons. Sans ça le 
trottoir/accotement/"zone piétonne" ne serait pas autorisée aux piétons.


S'ils avaient voulu signaler l'interdiction de continuer ils auraient 
mis un panneau d'interdiction "circulation interdite" B0 
.


Pas nécessaire, les vélo sont interdits par défaut pour les trottoirs. 
Autre exemple que j'ai capturé :


Pas de B0, mais j'invite un vélo à essayer d'aller à droite, ça envoie 
dans les passages piétons et ça débouche sur rien [2]


On peut aussi noter les bandes rugueuses au sol signalant qu'on entre 
dasn une autre zone.


Bien vu, j'avais pas pensé aux bandes comme séparateur ! Il y a aussi le 
changement de matière au sol.


Si l'autorité avait voulu marquer la fin de l'aménagement "complet", 
ils auraient demandé de mettre pied à terre, voir mis une micro 
bordure de début de trottoir.


Il n'y a rien de tout ça.

Le panneau fin de piste cyclable est quand même assez "fort" comme 
séparation, en plus des autres critères.


> /S'ils avaient voulu faire une continuité légale, ils auraient eu 
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un 
choix actif de leur part./


> /Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le 
choix de faire un "trottoir/accotement/zone piéton" partagé 
vélos/piétons [2]/


Et donc ils ont voulu une continuité à la légalité douteuse car plus 
loin il y aurait un problème de place.


On est d'accord : plus on représentera les choses telles qu'elles sont 
dans OSM, plus on arrivera à montrer les problèmes sans aller 
nécessairement sur le terrain.



+1


> /À 50m à l'[ouest] de cette photo les piétons sont obligés de 
marcher sur la piste cyclable [3], un autre problème d'aménagement de 
cette zone.../


> [3] /https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA/

De manière symétrique je mettrais :
highway=cycleway
foot=permissive

(segregated=no ? Ça me semble implicite)

C'est d'ailleurs un problème : on dit aux cyclistes (qui selon 
Florimond ne peuvent être arrivés là sauf à pied) qu'ils doivent 
continuer là. Mais on ne dit rien aux piétons (alors qu'on le dit 
ailleurs).
Peut être ajouter les photos en référence comme images mapillary dans 
OSM histoire de voir le pourquoi des choix et monter aussi les 
problèmes aux aménageurs.



+1


Et si Éric et Simon ne sont pas d'accord sur la manière de le 
représenter, je crois que vous êtes d'accord pour dire que ce n'est 
pas un bon aménagement. Idéalement rencontrer les élus et venir avec 
des propositions pour améliorer l'existant.


Oui il faudrait, j'ai pas trop la fibre "politique" mais tu as 
entièrement raison.


J'ai remarqué qu'ils ont mis une interdiction piétonnes B9a 
 
au niveau de la voie du tram. L'ont-ils mises au début du panneau B22a 
 
(je suppose) de piste cyclable ? Sans doute que non.


Il n'y a pas besoin : B22a et C113 tous deux deux interdisent par défaut 
les piétons.


Le 29/05/2020 à 10:44, Florimond Berthoux - 
florimond.berth...@gmail.com a écrit :
Il me semble que footway+bicycle=yes indique bien qu’il y a un 
problème d’aménagement (normalement ça ne devrait pas exister sur un 
axe de transit vélo).


Non, il y a plein d'endroits où la densité de piétons et de cycles 
ainsi que la largeur de la voie permet une cohabitation apaisée. Par 
exemple d'anciennes voies ferrées transformées en voies vertes : ça 
peut être un axe de transit vélo avec des piétons de temps en temps.


Là on est plus au niveau d'une tolérance que d'une utilisation normale 
(comme cette cycle cyclable sans voie piétonne parallèle qui devient 
une 

[OSM-talk-fr] Fwd: Re: Désaccord sur un highway=footway

[osm . sanspourriel]

Eric, merci effectivement c'était une erreur (initialement je ne pensais
réagir que sur un point), cette fois-ci à la liste et non à toi seul !

Jean-Yvon

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :


Le 28/05/2020 à 17:27, Florimond Berthoux a écrit :

On peut s'amuser à être légaliste lorsque l'infra est correctement
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.


Je souhaite juste que les infras cyclistes et leurs défauts soient
correctement représentées. Cela permet d'informer les cyclistes sur
les zones pas pratiques voir dangereuses et pouvoir remonter les
problèmes de continuité aux municipalités afin que ça bouge. Si l'on
masque tous ces problèmes à coup de bicycle=yes afin que le routeur
soit content ça fait pas avancer les choses.


+1

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :

Je garderais le bicycle=yes, voire en designated.

Rien ne désigne le vélo comme autorisé sur cette place piétonne, ce
serait encore moins adapté qu'un bicycle=yes.


-1 : si on dit qu'ils ne sont pas prioritaires c'est qu'_ils sont
autorisés_. A minima tolérés.

Alors oui le panneau n'est pas explicitement dans le code de la route
mais c'est bien un panneau de signalisation routière de danger.

> Ce panonceau n'a aucune existence légale.

https://www.mapillary.com/map/im/6lubeDufWJhvkUBhpeADyA

C'est le panneau de danger A14
.
complété par le panneau M9 précisant le danger :

CYCLISTES
ATTENTION :
PIÉTONS PRIORITAIRES

On termine aussi l'obligation de voie cyclable.

S'ils avaient voulu signaler l'interdiction de continuer ils auraient
mis un panneau d'interdiction "circulation interdite" B0
.

On peut aussi noter les bandes rugueuses au sol signalant qu'on entre
dasn une autre zone.

Si l'autorité avait voulu marquer la fin de l'aménagement "complet", ils
auraient demandé de mettre pied à terre, voir mis une micro bordure de
début de trottoir.

Il n'y a rien de tout ça.

> /Autre exemple de ce panonceau [1], là encore pas utile car aux
passages piétons les piétons sont dans tous les cas prioritaires./

Exact mais si tu supprimes les panneaux inutiles, tu vas pouvoir créer
ton entreprise de recyclage de panneaux^^.

> /S'ils avaient voulu faire une continuité légale, ils auraient eu
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un choix
actif de leur part./

> /Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le
choix de faire un "trottoir/accotement/zone piéton" partagé
vélos/piétons [2]/

Et donc ils ont voulu une continuité à la légalité douteuse car plus
loin il y aurait un problème de place.

On est d'accord : plus on représentera les choses telles qu'elles sont
dans OSM, plus on arrivera à montrer les problèmes sans aller
nécessairement sur le terrain.

> /À 50m à l'est de cette photo les piétons sont obligés de marcher sur
la piste cyclable [3], un autre problème d'aménagement de cette zone.../

> [3] /https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA/

De manière symétrique je mettrais :
highway=cycleway
foot=permissive

(segregated=no ? Ça me semble implicite)

C'est d'ailleurs un problème : on dit aux cyclistes (qui selon Florimond
ne peuvent être arrivés là sauf à pied) qu'ils doivent continuer là.
Mais on ne dit rien aux piétons (alors qu'on le dit ailleurs).

Peut être ajouter les photos en référence comme images mapillary dans
OSM histoire de voir le pourquoi des choix et monter aussi les problèmes
aux aménageurs.

Et si Éric et Simon ne sont pas d'accord sur la manière de le
représenter, je crois que vous êtes d'accord pour dire que ce n'est pas
un bon aménagement. Idéalement rencontrer les élus et venir avec des
propositions pour améliorer l'existant.

Le strict minimum c'est d'indiquer aux piétons qu'ils peuvent croiser
des cycles sur ce qui leur semble un trottoir et aux cyclistes qu'ils
peuvent croiser des piétons sur la piste cyclable.

Ou interdire les deux.

J'ai remarqué qu'ils ont mis une interdiction piétonnes B9a

au niveau de la voie du tram. L'ont-ils mises au début du panneau B22a

(je suppose) de piste cyclable ? Sans doute que non.

Le 29/05/2020 à 10:44, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Il me semble que footway+bicycle=yes indique bien qu’il y a un
problème d’aménagement (normalement ça ne devrait pas exister sur un
axe de transit vélo).


Non, il y a plein d'endroits où la densité de piétons et de cycles ainsi
que la largeur de la voie permet une cohabitation apaisée. Par exemple
d'anciennes voies ferrées transformées en voies vertes : ça peut être un
axe de transit 

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Éric Gillet]

Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :
Il me semble important de rappeler qu’OpenStreetMap n’est pas une base 
de donnée légale, on ne tag pas la lois.
On ne tag pas la loi parce que nous ne sommes pas des juges et que si 
les juges existent c’est parce que la loi est interprétative.


Bien entendu qu'on taggue la loi, et heureusement ! Physiquement rien 
n'empêche un vélo d'utiliser une autoroute, c'est juste dangereux et 
illégal. Donc on cartographie l'interdiction via highway=motorway.


Idem pour les limites de vitesse, les zones privées, les bases 
militaires, et limites administratives etc etc.


Et j’aimerai qu’on évite de s’embarquer dans des débats de juriste 
stérile.


Moi aussi c'est ma plus grande volonté, cf mon dernier message du changeset.


Est-ce qu’il y a un panneau qui interdit d’y pédaler ? -> non


Pas besoin, c'est interdit par défaut en agglomération (trottoirs et 
assimilés). Ce serait inimaginable de mettre un panneau interdiction de 
pédaler sur tous les trottoirs.


Est-ce que les cyclistes y roulent sans jamais se faire verbaliser ? 
-> oui

-> bicycle=yes


Les forces de l'ordre ne connaissent pas trop le code de la route sur 
l'utilisation des aménagements vélo. Bon nombre circulent sans 
avertisseurs (gyrophare/sirène) dans les voies bus/vélo.
Mais aussi de très nombreux cyclistes grillent des feux/stop, utilisent 
des téléphones sans jamais se faire verbaliser. Cela rends la chose pas 
moins illégale ou dangereuse.


Il me semble que footway+bicycle=yes indique bien qu’il y a un 
problème d’aménagement (normalement ça ne devrait pas exister sur un 
axe de transit vélo).


Oui en effet ça indique que l'axe de transit n'est pas continu, mais en 
soit c'est pas gravissime si c'est correctement signalisé et qu'il n'y a 
pas de dangers. Là ce n'est ni correctement signalisé, ni sécurisé.


Mettre bicycle=yes masque ce problème, et empêche les cyclistes d'avoir 
cette info et d'emprunter d'éventuels chemins plus sécurisés/rapides.






Le ven. 29 mai 2020 à 08:32, Éric Gillet > a écrit :


Le 28/05/2020 à 22:47, osm.sanspourr...@spamgourmet.com
 a écrit :


c'est donc un footway.


On est d'accord.


[si les piétons] sont prioritaires c'est que d'autres usagers
ceux à qui s'adresse le panneau, ici les cyclistes, sont
autorisés _en tant que tels_ et donc sans mettre pied à terre :
malgré les apparence ce n'est pas un trottoir !


Ce panonceau n'a aucune existence légale. À mon avis il s'adresse
aux vélos qui s'autorisent contre la signalétique/loi de continuer
à circuler, afin de réduire les accidents. Autre exemple de ce
panonceau [1], là encore pas utile car aux passages piétons les
piétons sont dans tous les cas prioritaires.

S'ils avaient voulu faire une continuité légale, ils auraient eu
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un
choix actif de leur part.

Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le
choix de faire un "trottoir/accotement/zone piéton" partagé
vélos/piétons [2]


On ne demande pas aux cyclistes de mettre pied à terre donc ils
ont le droit de rester, donc :

bicycle
=yes


Du coup non, pas adapté.


ou plutôt permissive. "Where bicycles do not have a legal
right-of-way, but the land owner has indicated that bicycles are
allowed".


On est sur la bonne voie (pun intended), mais non ce n'est
toujours pas autorisé, et puni par une amande classe 4.


Est-ce que sur ce qui semble être un trottoir il y a un panneau
avertissant les piétons de la circulation de cycles ? Rien vu
depuis Mapillary.


Bonne remarque ! Malheureusement il n'y a rien, ni à proximité de
la pharmacie qui fait un angle mort, ni à la pointe est où le
passage et étroit et semé de bollards.


Par contre ce n'est pas sur cette liste mais avec la mairie ou la
com com qu'il faudrait voir afin d'avoir une continuité dans de
bonnes conditions.


Entièrement d'accord. D'ailleurs OSM est une base de données
géographiques représentant le terrain et ses problèmes, pratique
pour exposer les problèmes à la comcom non ? Sauf si l'on masque
ces problèmes à coup de bicycle=yes là où il n'y a pas continuité.
Dans ce cas ni les usagers, ni les comcoms peuvent voir les problèmes.


En cas d'accident il serait possible de se retourner contre
l'aménageur car il semble que le piéton puisse de bonne foi se
croire sur un trottoir. Et le cycliste sur une voie qui lui est
ouverte.


Exactement. C'est d'ailleurs pour ça je pense qu'ils ne se
risquent pas à autoriser les vélos, le passage est dangereux dans
cette zone.


Mais à côté on voit aussi des piétons sur la voie cyclable

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Éric Gillet]

Le 29/05/2020 à 10:31, Yves P. a écrit :


Par contre ce n'est pas sur cette liste mais avec la mairie ou la 
com com qu'il faudrait voir afin d'avoir une continuité dans de 
bonnes conditions.



Entièrement d'accord.


D'ailleurs OSM est une base de données géographiques représentant le 
terrain et ses problèmes, pratique pour exposer les problèmes à la 
comcom non ?
Sauf si l'on masque ces problèmes à coup de bicycle=yes là où il n'y 
a pas continuité.

Dans ce cas ni les usagers, ni les comcoms peuvent voir les problèmes.


Il y a cette outil 
https://carto.parlons-velo.fr/#18.02/45.75278/4.869234 pour voir les 
points noirs à vélo (cliquer sur la couche "Points noirs").


Joli outil ! Bon dommage apparemment il n'est pas possible d'y 
contribuer hors campagnes baromètres si j'ai bien compris. Le côté 
"point noir" est assez limitant en terme d'expression possible par 
rapport à OSM.


Mais surtout c'est difficilement intégrable avec une carte, ou un moteur 
d'itinéraire pour adapter les trajets et informer les usagers. Et il me 
semble que parlons-vélo/la FUB ne couvre que la France.


Et cette page pour les signaler à Lyon : 
https://www.maisonduvelolyon.org/signaler-incident-velo/


J'ai fait un signalement très simple à corriger (1 panonceau manquant, 
interdisant un contre-sens-cyclable) il y a bientôt 1 an, toujours rien 
de fait [1]. Si j'ai la motivation je le ferais pour le sujet de ce fil 
aussi.


[1] https://demarches.toodego.com/signalements/voirie-et-signalisation/2246/


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

Re: [Talk-it] Fwd: Re: [Coordinamento WMI] Wiki Loves Monuments - Wikigite

[Volker Schmidt]

Cari amici,

vorrei descrivervi un approccio che Il Comune di Padova e FIAB Padova hanno
scelto per completare un ciclo di gite in bici in città con il titolo
"Padova Invisible" che è una tradizione "antica" a Padova.
Quest'anno abbiamo dovuto cancellare le ultime due gite causa coronavirus.
Queste due gite abbiamo successivamente "eseguite" in teleconferenza
(avevamo giù un po' di esperienza con delle conferenze, tipicamente di
viaggi, con presentatori in presenza virtuale via videoconferenza)
Per questi due eventi abbiamo fatto tutto in telepresenza via Zoom.
Un team di presentatori, che includeva gli operatori della videconferenza,
le guide (che normalmente avrebbero guidato i ciclisti) che commentavano il
percorso con l'aiuto di mappe, e presentavano gli oggetti che "visitavamo"
con foto (d'archivio), e due attori professioniali che leggevano testi
relativi ai posti "visitati" da documenti di archivio che furono trasmessi
via schermo in contemporaneo.
Erano eventi ben graditi con più di 90 partecipanti melle teleconferenze.

Mi sembra un modello da considerare per quello che avete in mente.

Le persone chi avevano l'idea e chi hanno fatto tutto il lavoro ci leggono
in copia.

Cordiali saluti

Volker






On Tue, 26 May 2020 at 15:22, Anisa Kuci  wrote:

> Ciao a tutti,
>
> vi giro queste mail dalla mailing list di Coordinatori Wikipedia.
>
> È un progetto interessante e se qualcuno avesse piacere di organizzarlo
> nel suo paese è benvenuto!
>
> Per qualsiasi informazione non esitate a contattarmi!
>
> Buona giornata,
>
> Anisa
>
>
>  Forwarded Message 
> Subject: Re: [Coordinamento WMI] Wiki Loves Monuments - Wikigite
> Date: Tue, 26 May 2020 12:31:51 +0200
> From: Maria Pia Dall'Armellina 
> 
> To: Coordinatori Regionali Wikipedia
> 
> 
> CC: Luca Landucci 
> 
>
> Io auspico che al più presto si possa ritornare in presenza a fare le
> wikigite.
> Tuttavia nel frattempo credo che potremmo potenziare l'aspetto digitale a
> cui il covid ci ha costretto.
> Suggerisco, in collaborazione con gli osmer, di creare delle *wikigite
> virtuali*.
> Tale operazione può essere condotta *all'esterno* dove si traccia su
> openstreetmap un percorso turistico e si inseriscono i monumenti con un
> link alle voci di Wikipedia. Potremmo in questo modo creare dei percorsi di
> "*realtà aumentata*" da sottoporre agli uffici turistici o alle
> amministrazioni comunali del territorio o semplicemente da veicolare nei
> nostri canali social.
> L'altra versione potrebbe essere condotta all'interno di un museo dove si
> crea un percorso soffermandoci e creando dei collegamenti a Wikipedia sulle
> opere principali in esso raccolte.
> Ovviamente per questa azione sarà opportuno fare una ricognizione tra le
> voci di Wikipedia per vedere se all'interno del territorio c'è materiale
> sufficiente per creare un percorso.
> Credo sia un ottimo modo per diffondere la conoscenza superando i limiti
> fisici che le misure di sicurezza ci impongono.
> Un saluto
>
> Il giorno mar 26 mag 2020 alle ore 09:39 Candida Mati <
> candida.m...@wikimedia.it> ha scritto:
>
>> Buongiorno Coordinatori,
>>
>> Il concorso internazionale WLM si avvicina e torniamo a parlare di
>> wikigite. Con Luca stiamo ragionando su come coinvolgere maggiormente i
>> soci e volontari nell'organizzazione delle wikigite. Conoscete qualcuno sul
>> vostro territorio di riferimento che potrebbe organizzare delle wikigite o
>> ha espresso la volontà di farlo? ovviamente daremo il supporto necessario
>> per la buona riuscita dell'iniziativa. Fermo restando che se persistono le
>> restrizione da covid, dovremo ripensare il modello organizzativo.
>>
>> Sulla pagina in wikina ci sono tutte le indicazioni su come organizzarlo
>> https://wiki.wikimedia.it/wiki/Wiki_Loves_Monuments/WikiGite
>> Questo invece è il link delle wikigite organizzate in passato:
>> https://www.wikimedia.it/tag/wikigite/
>>
>> Riassumendo gli step potrebbero essere:
>>
>>- Contatto con il comune per chiedere:
>>   - patrocinio
>>   - guida turistica gratuita
>>   - contributo spese per pubblicità
>>
>>
>>- Prima della wikigita:
>>   - pubblicità sui social
>>   - pubblicità sui giornali locali
>>   - pubblicità sui volontari locali ed ex partecipanti
>>
>>
>>- Ritrovo sabato ore 15 davanti al municipio (o luogo molto
>>conosciuto)
>>- Partecipazione di 1-2 wikipediani organizzatori e di un contatto
>>del comune
>>- Raccolta email dei partecipanti piano piano che arrivano
>>- Breve descrizione di Wikimedia, WLM e della giornata
>>- Visita guidata (1 ora, massimo 2)
>>- Ricordo dei prossimi eventi in zona
>>- Spostamento in una sala per presentazione di WLM e del caricamento
>>foto e dei prossimi eventi in zona (mezz'ora)
>>
>>
>> Grazie a tutti e buona giornata
>>
>>
>> --
>>
>> Candida Mati
>> Coordinatrice programmi
>> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
>> Via Bergognone 34 - 

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Éric Gillet]

Le 28/05/2020 à 18:48, Yves P. a écrit :
Ici, surtout avec le panneau "attention aux piétons" et les logos de 
sorties/entrées


Si c'était le cas, pourquoi mettre ce panneau plutôt que le B54 et 
B55, ou C113/C114 ?
Je vois les B54 et B55 signalant une aire piétonne 
 quand 
je circule en voiture sur une voie qui devient ou croise une aire.


Les panneaux C113/C114 indiquants une piste ou bande cyclable 
conseillée et réservée aux cycles 
 ne 
sont pas adaptés ici : c'est fait à la base pour les piétons :)


En effet B54/B55 (aire piétonne) serait plus adapté que C113/C114 vu 
qu'il n'y a pas la place d'avoir une piste/bande réservées aux cycles. 
Bien vu !


Pour moi, cette zone *est* une *aire piétonne.* Voir ici 
.


Malheureusement ça n'en est pas une. Comme inscrit dans l'article 
R110-2, et présenté dans la plaquette que tu partage :


« [...] Les entrées et sorties de cette zone sont annoncées par une 
signalisation [...] »


Ce n'est pas le cas ici, pas de B54/B55. Par défaut c'est donc assimilé 
à un (grand) trottoir en agglomération, avec les interdictions que ça 
implique pour les vélos.


Mais je suis d'accord avec toi, c'est ce que la ville devrait faire ici.

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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Yann-Gaël LARGILLET]

Merci pour vos retours ! 

Je regarde ce que je peux faire avec tous vos messages ! Car j'ai donc
fait des erreurs ! 

Concernant le débat "communes nouvelles pas dans les moeurs" ou autres,
ça reste des interprétations individuelles non ? 

Si le panneau est présent, on modifie selon la réalité du terrain ? J'en
étais resté sur ce principe de base... 

Bonne journée à vous, 

Yann-Gaël

---
"Lentius, Profundius, Suavius" (A.Langer) 

Le 29/05/2020 13:11, Marc M. a écrit :

> Bonjour,
> 
> Le 29.05.20 à 11:37, Rpnpif via Talk-fr a écrit : 
> 
>> Va falloir forker la carte OSM ;).
> 
> plus modestement : regarder la visibilité sur le rendu fr et hot
> et proposer des tickets ou mieux des PR pour l'améliorer.
> 
> 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

[talk-cz] Zase nefunguje tracer LPIS

[Zdeněk Pražák]

Zase přestal fungovat tracer LPIS___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-es] Día & Go, ¿supermarket or convenience?

[hugo]

Transmití a los que llevan el repositorio cuál son las principales 
discrepancias que hay en la comunidad española al respecto, y la 
última respuesta que obtuve sea quizás un poco tajante:
Dia & Go es siempre un supermarket Dia & Go es siempre una convenience 
store Dia & Go puede ser ambas, pues agregamos al índice ambas.
Actualmente el sondeo vía Telegram se ha girado a favor de 
convenience, 55% vs 45%


En mi opinión la mayor conflictividad que trae esta etiqueta radica en 
la traducción que se hizo en su día de convenience como ultramarinos. 
En el mundo de la alimentación sí que se discriminan los distintos 
tipos de supermercados aunque en el día a día, el común de las 
personas, los sigamos llamando /supers/. A modo de comparatoria, en OSM 
se dintiguen highway=residential, living_street, pedestrian... sin 
embargo, en el día a día decimos /calle./

/
/
La principal diferencia está en torno a la banda horaria que puede 
abrir, y en menor medida tamaño del establecimiento o precios. Sin 
mencionar ya que la regulación será distinta para este tipo de 
comercios. En el caso concreto del /Dia & Go/, el hecho que en su 
propio blog  se denominen como tienda 
de conveniencia (como ya he dicho, en el mundillo esa es la 
denominación) hace más difícil incluso hacer que acepten la etiqueta 
supermercado.


Un saludo

El mar, 26 de may de 2020 a las 11:38, Alejandro Moreno 
 escribió:
Yo solo conozco un Dia así que mi opinión se basa solo en ese 
establecimiento. Para mí es un supermarket porque tiene sección de 
frescos, es decir, charcutería, carnicería y pescadería con su 
charcutero, carnicero y pescadero; además de tener un tamaño medio. 
Además es bastante similar a los Opencor y Supercor que conozco y 
que también se etiquetan como supermarket.


Yo, el tener charcutería, carnicería y pescadería es el argumento 
que daría para insistir en que es un supermarket.


El dom., 24 may. 2020 a las 16:37, Crashillo (>) escribió:
Supongo que gran parte de la comunidad OSM de españa ya estaréis 
al tanto de

 la /polémica/ pero hago un resumen rápido:

 - El objetivo es poder controlar los brands /Dia & Go/
 - Se ha propuesto una incorporación al registro oficial, se puede 
seguir en
 este enlace 

 - El sondeo de opinión en el telegram es 44% a favor de 
*convenience* VS.

 54% a favor de *supermarket*
 - Los que llevan el repositorio en Github se muestran reticentes a 
aceptar

 *supermarket*

 Pido opinión de la comunidad, ¿qué hacemos?
 - Se puede aceptar lo que sugieren
 - Se pueden insistir en *supermarket* (ruego ayuda en este tema)
 - Se puede desestimar la incorporación, no incluirlo en el 
registro.


 La no-actuación conlleva que desestimen ese elemento, por tanto no 
se

 incluya.

 Saludos



 --
 Sent from: 

 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 



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

Re: [Talk-es] Demarcaciones sanitarias

[hugo]

Como bien dice David, es más fácil usar /admin_level/ sobre todo si 
el número a añadir es un nivel administrativo. Por eso, y por 
simplicidad con lo ya existente, en la wikipedia 
 ya están 
actualizadas.


Por otro lado, has añadido los límites religiosos, te quería 
preguntar si tienes alguna fuente de referencia para incluirlo en la 
página. Las referencias de Wikipedia están rotas ya, y lo único que 
he encontrado es 
 
pero no es descargable, y desconozco si podemos usarlo como fuente.


Respecto al etiquetado de la propuesta, he creado la discusión aquí 
 para 
tenerlo al lado del propio artículo. Veréis que ya he comentado sobre 
la posible confusión healthcare=specialities con 
helthcare:specialities=*


Por último, cómo veis las fuentes son de Castilla y León en su 
mayoría. Si sois de otra comunidad, y disponéis/conocéis las 
fuentes, por favor, añadidlas para poder mapearlas.


Un saludo

El jue, 28 de may de 2020 a las 08:37, David Marín Carreño 
 escribió:
Mi pregunta es por qué se están proponiendo distintas etiquetas de 
nivel (healthcare_level, environment_level) en lugar de la ya 
existente admin_level.


Esta etiqueta ya está siendo usada por 
boundary=religious_administration tanto en Polonia como Alemania.


--
David Marín Carreño mailto:dav...@gmail.com>>



El mié., 27 may. 2020 a las 20:20, hugo (>) escribió:
Respecto a lo de proponerlo sin duda es el camino, pero antes 
queríamos tenerlo un poquito más organizado. Para ello he creado 
esta página: 
.


Mi idea es que podamos editar en esta página (quién quiera) 
algunas ideas tanto de tags, como de fuentes (mayoritariamente son 
de CyL ahora) antes de elaborar una propuesta formal (como aquí se 
describe ). Si 
alguien no sabe editar en wikipedia o no tiene cuenta o lo que sea, 
puede mandar un correo aquí para que se agregue el contenido.


Saludos

El mar, 26 de may de 2020 a las 11:25, Alejandro Moreno 
mailto:almo...@gmail.com>> escribió:
Yo no puedo aportar mucho al etiquetado pero os dejo un par de 
propuestas. La primera es proponerlo en la lista de etiquetado 
global ya que ahí pueden proponer otras opciones de etiquetado y 
la segunda es documentar en la wiki la solución que finalmente se 
use, de manera que quede reflejado las etiquetas a usar como 
documentación para el futuro.


Un saludo.

El lun., 25 may. 2020 a las 12:04, Jorge Sanz Sanfructuoso 
(mailto:sanc...@gmail.com>>) escribió:

Buenas.

A lo mejor se puede hacer igual que en las zonas administrativas 
que se añade en la relación un admin_center. Añadir en estas 
zonas algo parecido con el centro de salud principal de la 
demarcación sanitaria.


Un saludos.


El lun., 25 may. 2020 a las 2:43, Diego Cruz (>) escribió:

Hola, Rafael:

Muchas gracias por tu respuesta.

Un compañero me ha advertido de que el único país donde estaba 
mapeado esto era el Congo, y allí utilizaban "health". Sin 
embargo, yo diría que "health" en inglés es más bien la salud 
de uno mismo, mientras que "healthcare" se refiere a la sanidad o 
atención sanitaria. Por eso había optado por esto último 
(además de que está el grupo de etiquetas "healthcare").


Acabo de subir la primera zona básica de salud (rural) como 
ensayo piloto (changeset #85697721) y al hacerlo me he dado 
cuenta de algunos fallos en lo que había propuesto, como el tema 
de la referencia que mencionas. Coincido en que es una tontería 
inventarse "health_ref", así que había puesto ref:healthcare, 
pero si basta con "ref" a secas, por mí no hay problema, lo 
cambio. No soy muy experto en el tema de las referencias.


Es decir, me parece perfecto lo que dices (*boundary=healthcare + 
healthcare_level=X*) con ref a secas, pero cambiando health por 
healthcare (aunque se esté usando ya health, yo creo que si se 
propone a nivel mundial la gente de habla inglesa no va a aceptar 
health, aunque todo es cuestión de ver qué pasa).


En cuanto al etiquetado de los centros, teniendo en cuenta el 
conflicto existente entre amenity=x y healthcare=x que han 
mencionado algunos compañeros, he optado por poner las dos, y 
que se borre automáticamente después la que quede en desuso.


También he visto que para los consultorios de atención primaria 
sería "doctors" y no "doctor" como había puesto.


Un saludo
Diego


El lun., 25 may. 2020 a las 1:59, Rafael Avila Coya 
(mailto:ravilac...@gmail.com>>) escribió:

Hola, Diego:

En la República Dem. del Congo se están mapeando las zonas 
sanitarias del país. Hace unos años atrás colaboré con 
Claire Halleux de la comunidad local congolesa sobre el tagging 
para esas entidades, pues no teníamos referencia en otros 
países.


Por 

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Marc M.]

Bonjour,

Le 29.05.20 à 11:37, Rpnpif via Talk-fr a écrit :
> Va falloir forker la carte OSM ;).

plus modestement : regarder la visibilité sur le rendu fr et hot
et proposer des tickets ou mieux des PR pour l'améliorer.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Philippe Verdy]

Le ven. 29 mai 2020 à 11:38, Rpnpif via Talk-fr 
a écrit :

> Ma réponse dans le texte.
>
> Le 29/05/2020 à 08:15, Philippe Verdy a écrit :
> > Ce n'est pas exact: si les noeuds représentent les place=* pour les
> > noms locaux, les noms des relations sont visibles le long des
> > frontières (il suffit de zoomer pour les voir). si on dézoome, le
> > noeud va être trop petit par rapport à la relation, et la relation
> > prend le pas, masquant le noeud représentant une relation plus petite
> > quand on ne peut pas afficher les deux.
>
D'abord je ne parlais que de rendu.
>

Et j'en ai parlé aussi au début.

Tu oublies qu'il n'y a pas que la carte: les noms de communes nouvelles
c'est surtout pour un usage administratif. Le "pékin" moyen (et même les
livreurs) lui voit le terrain et les nom locaux. Et pouyr eux encore le
nom local prévaut même si la commune nouvelle se déclare sous un autre nom
et a installé quelques panneaux (mais sans supprimer les anciens noms
auxquels tiennent les résidents et qui servent encore à beaucoup de
distinctions de lieux). De plus des communes nouvelles sont une
organisation plus ou moins temporaire, qui peut changer au cours du temps,
et assez contestée. Les réformes administratives successives se font dans
tous les sens, n'aboutissent pas toujours ou font marche arrière.

La commune de base reste l'entité comprise par tout le monde: on
connait son village par son clocher. Ceci dit on le connaissait aussi par
sa mairie, son école, ses services. Mais comme de plus en plus de choses
disparaissent des villages (église, mairie, école, poste, bar, commerces de
base comme boulangerie et boucherie), les villages d'aujourd'hui sont
méconnaissables, on connait mieux les quartiers résidentiels, mais on
travail lde plus en plus loin, il n'y a pas toujours un moyen de transport
public aisé, donc les villageois dépendent de la route et du réseau des
départementales.

Mais quand ils font quelques dizaines de kilomètres vers un autre endroit
(pour le travail ou les services), on ne connait plus le village ni même la
commune nouvelle: on leur demandera juste une adresse postale, sinon les
mieux formés à la géographie ne connaissent encore que les noms historiques
qui situent mieux les choses que des communes nouvelles, au contour
changeant et qui perturbe tout le monde.

Franchement en plus parler de "forker la carte" c'est trop: on a plusieurs
possibilités
* zoomer (c'est général de toute façon pour chercher quoi que ce soit sur
la carte, même un pays entier pour qui ne connait pas la géographie. C'est
vrai que tous les noeuds ne sont pas représentés, mais de toute façon on ne
peut pas, et zoomer est la seule façon si on fait une recherche "visuelle"
(ce qui est possible mais nécessite de la part de celui qui utilise cette
méthode de déjà savoir ce qu'il cherche et avoir une idée d'où ça devrait
se trouver)
* l'outil de recherche : c'est le plus simple, et Nominatim fournit la
réponse et situe pas mal de choses sur la carte


Ceci-dit il est vrai que Nominatim peut encore être amélioré car il exige
des orthographes exactes et ne sait pas trouver autre chose (un problème ne
cas de disputes sur un nom, ou si le nom est compliqué et a pas mal de
variantes: Nominatim peut ignorer les différences de casse, mais pas les
traits d'union, les accents, les abréviations courantes). OSM permet de
mettre quelques noms et abréviation d'usage mais il n'y a pas de
constitution automatique d'un jeu de noms "canoniquement simplifié" avec
différentes "notes" de pertinence selon le degré de ressemblance, qui lui
permettrait de trouver plus de chose et tout de même répondre de façon
pertinente et ordonnée. Mais là ça lui demande un base de données
d'indexation plus volumineuse et plus de travail. (On peut rapprocher cet
effort de celui des moteurs de recherche qui font eux-même les
rapprochements par des analyses statistiques pour évaluer la pertinence des
termes)


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

Re: [OSM-talk] Search results quality (and some testing on Elasticsearch)

[Simon Poole]

Hi Jose

Maybe you should have a look at  https://github.com/komoot/photon which
is the go to ES based solution for OSM data (I'm not quite sure how you
missed it with the large amount of research you did, but anyway).

The other bit to understand is that the design goals of Nominatim, at
least historically, were not "return a result at all cost" but, "return
a result if the object is tagged correctly", which goes hand in hand
with the target audience and goals of the openstreetmap.org. In any case
the main reason we're not running photon on openstreetmap.org are mainly
operational, not technical (aka somebody needs to volunteer to a)
integrate it in to the web site, b) integrate it in to our chef
deployment, c) provide operational support).

Simon

Am 29.05.2020 um 04:19 schrieb José Juan Montes:
>
> Hi all,
>
> This is my first message to the list so I take the opportunity to say
> hello to all and thanks to the community for the awesome
> software, data, and organisation.
>
> Now to the point. At the ES comunity, we've been discussing how
> difficult is to obtain useful results from OSM. Too many times results
> are odd or surprising: ordering puts better results down, sometimes it
> misses obvious matches entirely... Specifically, we are referring
> about the search engine of OSM front page, and other Nominatim
> bsaed services. 
>
> After some anaysis, issues seem related to:
>
> - stop words usage (prepositions, articles...)
> - result scoring and ordering (a perfect match placed below far and
> unrelated results)
> - word matching when there are tildes or non-unicode chars
> - synonyms / ignoring for some categories and common nouns (street /
> road...)
> - lack of autocompletion (helps users finding a result when they don't
> quite know the exact term)
> - lack of cross-langugae search (eg. in regions with several official
> languages, people mixes street names and road types between languages)
> - support for typo errors
>
> Part of the problem is that every language requires particular
> considerations, which impacts most of the points above. So in my view,
> a suitable solution would need to have good i18n support bottom up.
>
> We think that other communities (language-wise) may be hitting the
> same issues according to Github issues. I list some references at the
> bottom, but they don't seem to get much attention.
>
> Ultimately, the technology stack Nominatim is built upon is not state
> of the art. I have done a quick test with Elasticsearch and a simple
> default installation with naive data loading already produces decent
> results. I later found that alternative search engines exist, for
> example "Pelias", which are implemented on top of newer technologies,
> and their demo seems to work fine... 
>
> Has any alternative to the current geocoder been tested? What would it
> take for this to be improved? If alternatives exist, can the search
> engine at the front page be changed? or provide options so users can
> choose their preferred search engine? maybe even from specialized
> local/themed search providers? Perhaps something like that would pave
> the way for alternative search software and services, and foster
> innovation. 
>
> Cheers!
>
> Refs:
>
> - https://github.com/osm-search/Nominatim/issues/1811
> - https://github.com/osm-search/Nominatim/issues/333
> - https://github.com/osm-search/Nominatim/issues/1208
> - https://wiki.openstreetmap.org/wiki/Search_engines
> - source code of my
> tests: https://github.com/jjmontesl/cubetl/tree/master/examples/osm
>
>
> Jose Juan Montes
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Rpnpif via Talk-fr]

Ma réponse dans le texte.

Le 29/05/2020 à 08:15, Philippe Verdy a écrit :
Ce n'est pas exact: si les noeuds représentent les place=* pour les 
noms locaux, les noms des relations sont visibles le long des 
frontières (il suffit de zoomer pour les voir). si on dézoome, le 
noeud va être trop petit par rapport à la relation, et la relation 
prend le pas, masquant le noeud représentant une relation plus petite 
quand on ne peut pas afficher les deux.


D'abord je ne parlais que de rendu.

Comme je l'écrivais, les noms des relations sont affichés en petit le 
long des frontières mais ne sont plus visibles nulle part à zoom 14 et 
moins.


Comme les communes nouvelles n'ont théoriquement pas de nœud place=*, 
rien n'est rendu sur la carte OSM au-dessous de zoom 14.


Pour les communes nouvelles, comme elles conservent la toponymie des 
communes membres, le nom de la commune nouvelle ne remplace pas celui 
des communes membres, qui conservent également leur code INSEE propre 
à 5 chiffres (même si ces communes ne sont plus de "plein exercice" en 
tant que personnes morales séparées, le code INSEE à 5 chiffres est un 
code géographique, pas un code sur la personne morale qui, elle, est 
codée avec le code SIREN). La commune nouvelle adopte simplement le 
code INSEE à 5 chiffres d'une de ses communes membres, celle de son 
chef-lieu, les "anciens" codes INSEE à 5 chiffres ne sont pas 
"supprimés", il restent en vigueur et même liés aux communes membres. 
L'association du code INSEE à 5 chiffres avc la commune nouvelle est 
seulement une "facilité".


Tu parles de contraintes administratives, moi je parlais de terrain et 
d'utilisateurs (habitants, livreurs, voyageurs) qui ont besoin de 
connaître où se trouve la commune qui est mentionné sur leur bon de 
livraison ou qui est la destination de leur voyage. De plus en plus le 
nom de la commune nouvelle apparaît seule sur les adresses. Les noms des 
communes anciennes tendent à disparaître des adresses postales et des 
bons de livraison (les doublons sont pourchassés et progressivement 
éliminés par une numérotation différenciés des maisons, exemple : de 1 à 
30 sur telle rue et de 40 à 60 sur une homonyme).


Si on laisse en l'état, la seule solution est de faire un autre rendu, 
ce qui est hors de portée du pékin moyen. La recherche Nominatim 
fonctionne bien mais ne change rien au rendu utile pour se situer dans 
les derniers km.


La distinction entre entités administratives de niveau différent est 
pertinente pour l'administration (et pour les cartographes et autres 
spécialistes) mais beaucoup moins pour le citoyen moyen. De plus 
certaines mairies seraient bien intéressées par une meilleure visibilité 
de leur commune pour leurs propres services, pour la cohésion de leurs 
habitants et pour la promotion de leur commune à l'extérieur.


En résumé, le problème est l'utilisabilité et la visibilité de la carte 
OSM pour le terrain. Ce n'est ni un problème administratif, ni un 
problème de structure de la BDD d'OSM, quoique des changements mineurs 
pourraient aider.


Va falloir forker la carte OSM ;).

--
Rpnpif


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

Re: [Talk-lv] Fona karšu nobīdes

[Marat]

Tieši tā. Importēt ir viegli, bet kā noņemt iezīmētos un pēc tam vēl
savienot importu ar citiem ceļiem un objektiem?

Tāpēc arī prasīju par WMS ar kuru ir vieglāk salīdzināt izmaiņas un
pārklājumu.

On Fri, 29 May 2020, 12:25 LVMGEO,  wrote:

> LVM ceļus un dabas takas servēt kā WMS īsti nav jēgas, jo nekad nevarēs
> noformēt tā, lai visiem der, labāk tiešām paņemt vektorus un pašiem
> apstrādāt pēc saviem ieskatiem.
> Par visu ceļu (un varbūt tad arī citiem datiem, saskaņojot?) importu OSM
> esam izrunājuši ar Iļju Zverevu un atliek tikai atrast tam laiku un
> izdarīt. Ticams, ka varam arī atrast veidu kā iepriekš iezīmētos noņemt,
> aizstāt ar aktualizētajiem. Ja vien community neradīsies kādi jauni
> iebildumi.
>
> Jā, skaidras licences pielikt varam, kaut kad tam pieķersimies. Par LVM
> datiem nav nekādu problēmu, bet par LĢIA datiem to izdarīt traucē arī
> pretrunīgais LĢIA licences līgumu saturs, kuru gan plānots drīzumā
> pārskatīt un salabot, cerams.
>
> -Original Message-
> From: Maris Nartiss 
> Sent: Friday, May 29, 2020 8:31 AM
> To: Marat 
> Cc: talk-lvopenstreetmap.org 
> Subject: Re: [Talk-lv] Fona karšu nobīdes
>
> Kam Tev WMS? Paņem no viņu datu sadaļas gatavus vektorus. Vienīgi nezinu
> cik labi parastie OSM redaktori spēj nodrošināt vektordatu nolasīšanu.
> Josmam laikam vispirms vajag tos ESRI Shapefile uz GeoJSON vai ko
> tamlīdzīgu pārdzīt. Masveida imports gan būs problemātisks, jo daudz kur
> tie ceļi jau ir sazīmēti — tad tur reāli jāvingro, lai importējot nenonestu
> jau esošos (iespējams, ne tik precīzos) datus.
>
> Vienīgi LVM GEO varētu pie datiem pielikt skaidras licences klāt.
> Citādi šobrīd sanāk, ka saka jau ka drīkst izmantot, taču beigsies vēl kā
> Pētera Valmieras datu importam — Valmiera teica, ka ņem un lieto droši,
> taču papīra, ko parādīt citiem OSMistiem nav. Tā arī tas datu imports
> aizgāja pa skuju taku.
>
> Māris.
>
> ceturtd., 2020. g. 28. maijs, plkst. 14:29 — lietotājs Marat
> () rakstīja:
> >
> > Wow! Nezināju ka LVM piedalās OSM :)
> > Off topic jautājums: vai ir iespējams dabūt LVM ceļu slāni ar
> nosaukumiem un dabas takas WMSā?
> >
> > On Thu, 28 May 2020, 14:21 LVMGEO,  wrote:
> >>
> >> JS izmanto mūsu, LVM GEO ortofoto karšu servisus. Pērkam attēlus no
> LĢIA, publicējam visiem par brīvu izmantojamus, tai skaitā JS. Viss ir
> legāli, un to droši var lietot, vienīgi šobrīd mums ir tikai WMS serviss,
> diemžēl.
> >>
> >> -Original Message-
> >> From: Rihards 
> >> Sent: Wednesday, May 27, 2020 3:00 PM
> >> To: talk-lvopenstreetmap.org 
> >> Subject: Re: [Talk-lv] Fona karšu nobīdes
> >>
> >> On 27.05.20 13:47, Ivars wrote:
> >> > Pēc maniem novērojumiem gan Esri, gan Jāņa sētas orto, gan LĢIA orto
> ir viens un tas pats attēls, pāris atsevišķās Latvijas vietās paskatoties.
> >> > Tā kā avots ir viens un tas pats, pieļauju, ka arī precizitātei
> vajadzētu būt vienādai? Ja vien Esri nav kaut ko paši nepareizi pārbīdījuši.
> >>
> >> Var jau būt, ka Esri ir nomainījuši, tagad pamatā lietoju LKS un Maxar
> slāņus.
> >> Paskatījos šībrīža rediģējamajā vietā - bilde tā pati, LKS vs Esri
> nedaudz virs metra atšķirība. Sīkums.
> >> Kas ir JS orto nezinu, bet man ir lielas aizdomas, ka mēs to
> >> nedrīkstam lietot :)
> >>
> >> > Paldies par saiti uz LVM, visādi interesanti dati un servisi, ko
> >> > līdz šim nezināju. iD editorā gan laikam tos nevar pielikt, jo tur
> custom maps vajag TMS, nevis WMS...
> >> > 99% esmu darbojies tikai iD, bet varbūt jāpamēģina vairāk ar JOSM
> >>
> >> Ja kādi jautājumi par JOSM (un par iD jau arī), droši šajā listē
> jāprasa.
> >>
> >> > - Reply to message -
> >> > Subject: Re: [Talk-lv] Fona karšu nobīdes
> >> > Date: Wed, 27 May 2020, 08:18
> >> > From:  Rihards 
> >> > To:  talk-lv@openstreetmap.org 
> >> >> On 27.05.20 01:10, Ivars via Talk-lv wrote:
> >> >>> Sveiki!
> >> >>> Vai ir kaut kur informācija par to, kādas nobīdes ir pieejamajiem
> >> >>> fona aero/satfoto slāņiem Latvijā?
> >> >>> Vai Esri aerofoto (kas taču ir 1:1 tas pats JS aerofoto) var
> >> >>> uzskatīt par visprecīzāko?
> >> >>> Cik novēroju, Maxar uzņēmumi bieži ir vissvaigākie, bet tiem ir
> >> >>> pamatīga nobīde, ko tad jāmēģina pielīdzināt.
> >> >
> >> >> ESRI šur tur ir labi foto, bet nobīde mēdz būt manāma.
> >> >> Visprecīzākie tiešām līdz šim ir bijuši LVM publicētie LKS orto un
> >> >> LIDAR slāņi - https://www.lvmgeo.lv/dati -> servisi.
> >> >
> >> >>> Un, ja, piemēram, esri ir precīzs vienā vietā, vai ir garantija,
> >> >>> ka 3km tālāk tas joprojām būs tikpat precīzs?
> >> >
> >> >> Nē, pāris km tālāk var būt labi - bet var būt arī citādāka nobīde.
> >> >
> >> >>> Gps trasēm arī ne vienmēr var uzticēties un daudzviet viņu ir par
> >> >>> maz (vai nav), lai pēc tām spriestu, cik metru pa labi, pa kreisi
> taka ir.
> >> >
> >> >> GPX treisi ir manta, ja to ir daudz - tad pēc vidus var pieregulēt.
> >> >> Ja tuvumā ir kāds lielāks krustojums, tad pa abām asīm var.
> >> >
> >> >>> Vai ir kaut kāds etalons, pēc kā var 

Re: [Talk-lv] Fona karšu nobīdes

[LVMGEO]

LVM ceļus un dabas takas servēt kā WMS īsti nav jēgas, jo nekad nevarēs 
noformēt tā, lai visiem der, labāk tiešām paņemt vektorus un pašiem apstrādāt 
pēc saviem ieskatiem.
Par visu ceļu (un varbūt tad arī citiem datiem, saskaņojot?) importu OSM esam 
izrunājuši ar Iļju Zverevu un atliek tikai atrast tam laiku un izdarīt. Ticams, 
ka varam arī atrast veidu kā iepriekš iezīmētos noņemt, aizstāt ar 
aktualizētajiem. Ja vien community neradīsies kādi jauni iebildumi.

Jā, skaidras licences pielikt varam, kaut kad tam pieķersimies. Par LVM datiem 
nav nekādu problēmu, bet par LĢIA datiem to izdarīt traucē arī pretrunīgais 
LĢIA licences līgumu saturs, kuru gan plānots drīzumā pārskatīt un salabot, 
cerams.

-Original Message-
From: Maris Nartiss  
Sent: Friday, May 29, 2020 8:31 AM
To: Marat 
Cc: talk-lvopenstreetmap.org 
Subject: Re: [Talk-lv] Fona karšu nobīdes

Kam Tev WMS? Paņem no viņu datu sadaļas gatavus vektorus. Vienīgi nezinu cik 
labi parastie OSM redaktori spēj nodrošināt vektordatu nolasīšanu. Josmam 
laikam vispirms vajag tos ESRI Shapefile uz GeoJSON vai ko tamlīdzīgu pārdzīt. 
Masveida imports gan būs problemātisks, jo daudz kur tie ceļi jau ir sazīmēti — 
tad tur reāli jāvingro, lai importējot nenonestu jau esošos (iespējams, ne tik 
precīzos) datus.

Vienīgi LVM GEO varētu pie datiem pielikt skaidras licences klāt.
Citādi šobrīd sanāk, ka saka jau ka drīkst izmantot, taču beigsies vēl kā 
Pētera Valmieras datu importam — Valmiera teica, ka ņem un lieto droši, taču 
papīra, ko parādīt citiem OSMistiem nav. Tā arī tas datu imports aizgāja pa 
skuju taku.

Māris.

ceturtd., 2020. g. 28. maijs, plkst. 14:29 — lietotājs Marat
() rakstīja:
>
> Wow! Nezināju ka LVM piedalās OSM :)
> Off topic jautājums: vai ir iespējams dabūt LVM ceļu slāni ar nosaukumiem un 
> dabas takas WMSā?
>
> On Thu, 28 May 2020, 14:21 LVMGEO,  wrote:
>>
>> JS izmanto mūsu, LVM GEO ortofoto karšu servisus. Pērkam attēlus no LĢIA, 
>> publicējam visiem par brīvu izmantojamus, tai skaitā JS. Viss ir legāli, un 
>> to droši var lietot, vienīgi šobrīd mums ir tikai WMS serviss, diemžēl.
>>
>> -Original Message-
>> From: Rihards 
>> Sent: Wednesday, May 27, 2020 3:00 PM
>> To: talk-lvopenstreetmap.org 
>> Subject: Re: [Talk-lv] Fona karšu nobīdes
>>
>> On 27.05.20 13:47, Ivars wrote:
>> > Pēc maniem novērojumiem gan Esri, gan Jāņa sētas orto, gan LĢIA orto ir 
>> > viens un tas pats attēls, pāris atsevišķās Latvijas vietās paskatoties.
>> > Tā kā avots ir viens un tas pats, pieļauju, ka arī precizitātei vajadzētu 
>> > būt vienādai? Ja vien Esri nav kaut ko paši nepareizi pārbīdījuši.
>>
>> Var jau būt, ka Esri ir nomainījuši, tagad pamatā lietoju LKS un Maxar 
>> slāņus.
>> Paskatījos šībrīža rediģējamajā vietā - bilde tā pati, LKS vs Esri nedaudz 
>> virs metra atšķirība. Sīkums.
>> Kas ir JS orto nezinu, bet man ir lielas aizdomas, ka mēs to 
>> nedrīkstam lietot :)
>>
>> > Paldies par saiti uz LVM, visādi interesanti dati un servisi, ko 
>> > līdz šim nezināju. iD editorā gan laikam tos nevar pielikt, jo tur custom 
>> > maps vajag TMS, nevis WMS...
>> > 99% esmu darbojies tikai iD, bet varbūt jāpamēģina vairāk ar JOSM
>>
>> Ja kādi jautājumi par JOSM (un par iD jau arī), droši šajā listē jāprasa.
>>
>> > - Reply to message -
>> > Subject: Re: [Talk-lv] Fona karšu nobīdes
>> > Date: Wed, 27 May 2020, 08:18
>> > From:  Rihards 
>> > To:  talk-lv@openstreetmap.org 
>> >> On 27.05.20 01:10, Ivars via Talk-lv wrote:
>> >>> Sveiki!
>> >>> Vai ir kaut kur informācija par to, kādas nobīdes ir pieejamajiem 
>> >>> fona aero/satfoto slāņiem Latvijā?
>> >>> Vai Esri aerofoto (kas taču ir 1:1 tas pats JS aerofoto) var 
>> >>> uzskatīt par visprecīzāko?
>> >>> Cik novēroju, Maxar uzņēmumi bieži ir vissvaigākie, bet tiem ir 
>> >>> pamatīga nobīde, ko tad jāmēģina pielīdzināt.
>> >
>> >> ESRI šur tur ir labi foto, bet nobīde mēdz būt manāma.
>> >> Visprecīzākie tiešām līdz šim ir bijuši LVM publicētie LKS orto un 
>> >> LIDAR slāņi - https://www.lvmgeo.lv/dati -> servisi.
>> >
>> >>> Un, ja, piemēram, esri ir precīzs vienā vietā, vai ir garantija, 
>> >>> ka 3km tālāk tas joprojām būs tikpat precīzs?
>> >
>> >> Nē, pāris km tālāk var būt labi - bet var būt arī citādāka nobīde.
>> >
>> >>> Gps trasēm arī ne vienmēr var uzticēties un daudzviet viņu ir par 
>> >>> maz (vai nav), lai pēc tām spriestu, cik metru pa labi, pa kreisi taka 
>> >>> ir.
>> >
>> >> GPX treisi ir manta, ja to ir daudz - tad pēc vidus var pieregulēt.
>> >> Ja tuvumā ir kāds lielāks krustojums, tad pa abām asīm var.
>> >
>> >>> Vai ir kaut kāds etalons, pēc kā var mēģināt vadīties, ja arī tas 
>> >>> nav pieejams kā fons, bet tā, lai var paskatīties uz to un uz 
>> >>> iekartēto osm un saprast, ir nobīde vai nav? Piemēram, Vzd 
>> >>> kadastrā redzamajām māju un ceļu kontūrām taču vajadzētu atbilst "zemes 
>> >>> apstākļiem" par 99.9%?
>> >>>
>> >>> P.s. Nebiju līdz šim ar citiem LV kartētājiem kontaktējis - vai 
>> >>> šis ir primārais saziņas 

[OSM-talk-fr] heatmap des informations OSM

[Baptiste Lemoine - Cipher Bliss]

Salut les talk-fr,
je me demandais si vous sauriez comment faire une carte de la densité 
d'informations  (nodes et tags surtout) sur une zone géographique.
y'a https://yosmhm.neis-one.org/ qui fait des heatmap comme j'en cherche pour 
un utilisateur en particulier, mais ce que je cherche ce serait pour tous 
utilisateurs confondus.
merci!

Baptiste LEMOINE - Dirigeant de Cipher Bliss.com , N° SIRET: 79942416300035
Tel 0185461173  / Signal 0627130837 , Telegram: Tykayn , Mastodon: @tykayn, 
Riot: @tykaynchu:matrix.org
GPG: 64A8 9B18 65E6 6523 FD86 7CB5 8796 1FCA F978 54FF
clé publique monnaie-libre Duniter / Ğ1: 
8c4mVVPAHd4yLYcxWM4U8Z3zUb4WpRX1iGtX5T7tbEFE - tykayn

Sent with ProtonMail Secure Email.

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

Re: [Talk-it] [Import] civici Bergamo

[Andrea Albani]

Non ho messo mano su questi dati e quindi ringrazio anch'io chi si è
sbattuto per salvarli. Concordo con l'approccio proposto da Andrea
Musuruane e la procedura descritta nella wiki.
Ciao

Il giorno ven 29 mag 2020 alle ore 10:09 Andrea Musuruane <
musur...@gmail.com> ha scritto:

> Cascafico, apprezzo la buona volontà, però, prima di fare QA,
> *possiamo concordare sul sistemare l'esistente, secondo quanto scritto
> sulla wiki?  *
>
> Una volta che siamo concordi (*servono delle risposte da parte di molti a
> questa mail*) bisogna informare la ML di import (mi prendo io questo
> onere).
>
> Altrimenti continuiamo a fare lo stesso errore che ha fatto gigi2037 e ci
> avviamo a fare un revert.
>
> Grazie,
>
> Andrea
>
>
>
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Florimond Berthoux]

Il me semble important de rappeler qu’OpenStreetMap n’est pas une base de
donnée légale, on ne tag pas la lois.
On ne tag pas la loi parce que nous ne sommes pas des juges et que si les
juges existent c’est parce que la loi est interprétative.
Et j’aimerai qu’on évite de s’embarquer dans des débats de juriste stérile.

Donc revenons à la réalité du terrain :
Est-ce que ça ressemble à un trottoir-place piétonne ? -> oui -> footway
Est-ce qu’il y a un panneau qui interdit d’y pédaler ? -> non
Est-ce que les cyclistes y roulent sans jamais se faire verbaliser ? -> oui
-> bicycle=yes

Il me semble que footway+bicycle=yes indique bien qu’il y a un problème
d’aménagement (normalement ça ne devrait pas exister sur un axe de transit
vélo).



Le ven. 29 mai 2020 à 08:32, Éric Gillet  a
écrit :

> Le 28/05/2020 à 22:47, osm.sanspourr...@spamgourmet.com a écrit :
>
> c'est donc un footway.
>
> On est d'accord.
>
> [si les piétons] sont prioritaires c'est que d'autres usagers ceux à qui
> s'adresse le panneau, ici les cyclistes, sont autorisés *en tant que tels*
> et donc sans mettre pied à terre : malgré les apparence ce n'est pas un
> trottoir !
>
> Ce panonceau n'a aucune existence légale. À mon avis il s'adresse aux
> vélos qui s'autorisent contre la signalétique/loi de continuer à circuler,
> afin de réduire les accidents. Autre exemple de ce panonceau [1], là encore
> pas utile car aux passages piétons les piétons sont dans tous les cas
> prioritaires.
>
> S'ils avaient voulu faire une continuité légale, ils auraient eu plein
> d'autres moyens explicites. Ils ne l'ont pas fait, c'est un choix actif de
> leur part.
>
> Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le choix
> de faire un "trottoir/accotement/zone piéton" partagé vélos/piétons [2]
>
> On ne demande pas aux cyclistes de mettre pied à terre donc ils ont le
> droit de rester, donc :
>
> bicycle =yes
>
> Du coup non, pas adapté.
>
> ou plutôt permissive. "Where bicycles do not have a legal right-of-way,
> but the land owner has indicated that bicycles are allowed".
>
> On est sur la bonne voie (pun intended), mais non ce n'est toujours pas
> autorisé, et puni par une amande classe 4.
>
> Est-ce que sur ce qui semble être un trottoir il y a un panneau
> avertissant les piétons de la circulation de cycles ? Rien vu depuis
> Mapillary.
>
> Bonne remarque ! Malheureusement il n'y a rien, ni à proximité de la
> pharmacie qui fait un angle mort, ni à la pointe est où le passage et
> étroit et semé de bollards.
>
> Par contre ce n'est pas sur cette liste mais avec la mairie ou la com com
> qu'il faudrait voir afin d'avoir une continuité dans de bonnes conditions.
>
> Entièrement d'accord. D'ailleurs OSM est une base de données géographiques
> représentant le terrain et ses problèmes, pratique pour exposer les
> problèmes à la comcom non ? Sauf si l'on masque ces problèmes à coup de
> bicycle=yes là où il n'y a pas continuité. Dans ce cas ni les usagers, ni
> les comcoms peuvent voir les problèmes.
>
> En cas d'accident il serait possible de se retourner contre l'aménageur
> car il semble que le piéton puisse de bonne foi se croire sur un trottoir.
> Et le cycliste sur une voie qui lui est ouverte.
>
> Exactement. C'est d'ailleurs pour ça je pense qu'ils ne se risquent pas à
> autoriser les vélos, le passage est dangereux dans cette zone.
>
> Mais à côté on voit aussi des piétons sur la voie cyclable
> ...
>
> À 50m à l'est de cette photo les piétons sont obligés de marcher sur la
> piste cyclable [3], un autre problème d'aménagement de cette zone...
>
>
>
> [1] https://www.mapillary.com/map/im/969md9UGZr2oD37Ivqbdsw
> [2] https://www.mapillary.com/map/im/LJ4yfEmq6v3tUR65ku3cIA
>
> [3] https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Assemblée générale 13/06

[PanierAvide]

D'après les statuts, entre 5 et 15 : 
https://wiki.openstreetmap.org/wiki/France/Projet_d%27association_en_France/Statuts#Article_9_.E2.80.94_Conseil_d.27administration


Adrien P.

Le 29/05/2020 à 10:40, Yves P. a écrit :


Le lien n'a pas été mentionné, mais de souvenir il est bienvenu de 
compléter également le wiki pour les candidats au CA : 
https://wiki.openstreetmap.org/wiki/France/OSM-FR/AGO_2020-06-13



Merci Adrien.

8 candidatures, et combien de places ?

__
Yves

___
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] Assemblée générale 13/06

[Yves P.]

> Le lien n'a pas été mentionné, mais de souvenir il est bienvenu de compléter 
> également le wiki pour les candidats au CA : 
> https://wiki.openstreetmap.org/wiki/France/OSM-FR/AGO_2020-06-13 
> Merci 
> Adrien.

8 candidatures, et combien de places ?

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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Yves P.]

>> Par contre ce n'est pas sur cette liste mais avec la mairie ou la com com 
>> qu'il faudrait voir afin d'avoir une continuité dans de bonnes conditions.
>> 
> Entièrement d'accord.

> D'ailleurs OSM est une base de données géographiques représentant le terrain 
> et ses problèmes, pratique pour exposer les problèmes à la comcom non ?
> Sauf si l'on masque ces problèmes à coup de bicycle=yes là où il n'y a pas 
> continuité.
> Dans ce cas ni les usagers, ni les comcoms peuvent voir les problèmes.

Il y a cette outil https://carto.parlons-velo.fr/#18.02/45.75278/4.869234 
 pour voir les points 
noirs à vélo (cliquer sur la couche "Points noirs").

Et cette page pour les signaler à Lyon : 
https://www.maisonduvelolyon.org/signaler-incident-velo/

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

Re: [OSM-talk-fr] Assemblée générale 13/06

[PanierAvide]

Bonjour,

Le lien n'a pas été mentionné, mais de souvenir il est bienvenu de 
compléter également le wiki pour les candidats au CA : 
https://wiki.openstreetmap.org/wiki/France/OSM-FR/AGO_2020-06-13


Cordialement,

Adrien P.

Le 28/05/2020 à 22:02, Donat ROBAUX a écrit :

Bonsoir à tous-tes,

Juste un petit rappel des échéances.
Il vous reste jusqu'à demain soir donc le *vendredi 29 mai minuit* pour
- proposer des motions et sujets de discussion pour l'AG
- présenter votre candidature au CA.

Pour tout ca, envoyez un mail à associat...@listes.openstreetmap.fr 



Donat
Pour le CA



___
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] [Import] civici Bergamo

[Lorenzo Stucchi]

Ciao,

Grazie ad entrambi per il lavoro fatto per mantenere queste dati. Ho letto la 
wiki e sono d’accordo con la procedura.

Ciao,
Lorenzo Stucchi

Il giorno 29 mag 2020, alle ore 10:07, Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:

Cascafico, apprezzo la buona volontà, però, prima di fare QA, possiamo 
concordare sul sistemare l'esistente, secondo quanto scritto sulla wiki?

Una volta che siamo concordi (servono delle risposte da parte di molti a questa 
mail) bisogna informare la ML di import (mi prendo io questo onere).

Altrimenti continuiamo a fare lo stesso errore che ha fatto gigi2037 e ci 
avviamo a fare un revert.

Grazie,

Andrea



On Fri, May 29, 2020 at 9:55 AM Cascafico Giovanni 
mailto:cascaf...@gmail.com>> wrote:
Adesso overpass dice 87, umap tutta verde :-)

Il giorno gio 28 mag 2020 alle ore 13:56 Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:
Prima di continuare a fare QA, possiamo concordare sul sistemare l'esistente, 
secondo quanto scritto sulla wiki e di conseguenza informare la ML di import?

Per quanto riguarda gli esponenti numerici, sono 87 nel dataset del comune ma 
in OSM ce ne sono solo 66. Quindi ne mancano 21.

[out:json][timeout:25];
area[name="Bergamo"][admin_level=8]->.searchArea;
node["addr:housenumber"~"[0-9]+\/[0-9]+"](area.searchArea);
out body;
>;
out skel qt;

Ciao,

Andrea


On Thu, May 28, 2020 at 1:37 PM Cascafico Giovanni 
mailto:cascaf...@gmail.com>> wrote:
Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap dipo che mapnik 
ha aggiornato ci vorrebbe

Il gio 28 mag 2020, 12:08 Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:
Li hai corretti tu?

Ciao,

Andrea


On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni 
mailto:cascaf...@gmail.com>> wrote:
Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.

Il mer 27 mag 2020, 11:08 Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:
Ciao a tutti,
ho provato a documentare questo import sulla wiki:
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import

Se concordate, per procedere e mantenere i dati importati in OSM, bisogna fare 
tanta QA. I casi che ho trovato sono elencati nella wiki. Non escludo che 
lavorandoci più attivamente sopra, se ne scoprano altri.

Ciao,

Andrea


On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
mailto:musur...@gmail.com>> wrote:
Ciao,

On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni 
mailto:cascaf...@gmail.com>> wrote:
Ho standardizzato i civici, rimuovendo la barra e portando a maiusolo 
l'esponente.

Perché in maiuscolo?

Prima di continuare (chiunque), possiamo almeno scrivere una pagina di import 
che descrivere le cose fatte/da fare?

Lato mio posso: a) fare uno script di conversione con ogr2osm b) suggerire di 
usare come modello la pagina di import che avevo fatto per Biella 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses

Grazie,

Andrea

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

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

Re: [Talk-it] [Import] civici Bergamo

[Andrea Musuruane]

Cascafico, apprezzo la buona volontà, però, prima di fare QA,
*possiamo concordare sul sistemare l'esistente, secondo quanto scritto
sulla wiki?  *

Una volta che siamo concordi (*servono delle risposte da parte di molti a
questa mail*) bisogna informare la ML di import (mi prendo io questo onere).

Altrimenti continuiamo a fare lo stesso errore che ha fatto gigi2037 e ci
avviamo a fare un revert.

Grazie,

Andrea



On Fri, May 29, 2020 at 9:55 AM Cascafico Giovanni 
wrote:

> Adesso overpass dice 87, umap tutta verde :-)
>
> Il giorno gio 28 mag 2020 alle ore 13:56 Andrea Musuruane <
> musur...@gmail.com> ha scritto:
>
>> Prima di continuare a fare QA, possiamo concordare sul sistemare
>> l'esistente, secondo quanto scritto sulla wiki e di conseguenza informare
>> la ML di import?
>>
>> Per quanto riguarda gli esponenti numerici, sono 87 nel dataset del
>> comune ma in OSM ce ne sono solo 66. Quindi ne mancano 21.
>>
>> [out:json][timeout:25];
>> area[name="Bergamo"][admin_level=8]->.searchArea;
>> node["addr:housenumber"~"[0-9]+\/[0-9]+"](area.searchArea);
>> out body;
>> >;
>> out skel qt;
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Thu, May 28, 2020 at 1:37 PM Cascafico Giovanni 
>> wrote:
>>
>>> Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap dipo che
>>> mapnik ha aggiornato ci vorrebbe
>>>
>>> Il gio 28 mag 2020, 12:08 Andrea Musuruane  ha
>>> scritto:
>>>
 Li hai corretti tu?

 Ciao,

 Andrea


 On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni <
 cascaf...@gmail.com> wrote:

> Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap
> linkata.
>
> Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha
> scritto:
>
>> Ciao a tutti,
>> ho provato a documentare questo import sulla wiki:
>>
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
>>
>> Se concordate, per procedere e mantenere i dati importati in OSM,
>> bisogna fare tanta QA. I casi che ho trovato sono elencati nella wiki. 
>> Non
>> escludo che lavorandoci più attivamente sopra, se ne scoprano altri.
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
>> wrote:
>>
>>> Ciao,
>>>
>>> On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni <
>>> cascaf...@gmail.com> wrote:
>>>
 Ho standardizzato i civici, rimuovendo la barra e portando a
 maiusolo l'esponente.

>>>
>>> Perché in maiuscolo?
>>>
>>> Prima di continuare (chiunque), possiamo almeno scrivere una pagina
>>> di import che descrivere le cose fatte/da fare?
>>>
>>> Lato mio posso: a) fare uno script di conversione con ogr2osm b)
>>> suggerire di usare come modello la pagina di import che avevo fatto per
>>> Biella
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
>>>
>>> Grazie,
>>>
>>> Andrea
>>>
>>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] [Import] civici Bergamo

[Cascafico Giovanni]

Adesso overpass dice 87, umap tutta verde :-)

Il giorno gio 28 mag 2020 alle ore 13:56 Andrea Musuruane <
musur...@gmail.com> ha scritto:

> Prima di continuare a fare QA, possiamo concordare sul sistemare
> l'esistente, secondo quanto scritto sulla wiki e di conseguenza informare
> la ML di import?
>
> Per quanto riguarda gli esponenti numerici, sono 87 nel dataset del comune
> ma in OSM ce ne sono solo 66. Quindi ne mancano 21.
>
> [out:json][timeout:25];
> area[name="Bergamo"][admin_level=8]->.searchArea;
> node["addr:housenumber"~"[0-9]+\/[0-9]+"](area.searchArea);
> out body;
> >;
> out skel qt;
>
> Ciao,
>
> Andrea
>
>
> On Thu, May 28, 2020 at 1:37 PM Cascafico Giovanni 
> wrote:
>
>> Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap dipo che
>> mapnik ha aggiornato ci vorrebbe
>>
>> Il gio 28 mag 2020, 12:08 Andrea Musuruane  ha
>> scritto:
>>
>>> Li hai corretti tu?
>>>
>>> Ciao,
>>>
>>> Andrea
>>>
>>>
>>> On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni 
>>> wrote:
>>>
 Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.

 Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha
 scritto:

> Ciao a tutti,
> ho provato a documentare questo import sulla wiki:
>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
>
> Se concordate, per procedere e mantenere i dati importati in OSM,
> bisogna fare tanta QA. I casi che ho trovato sono elencati nella wiki. Non
> escludo che lavorandoci più attivamente sopra, se ne scoprano altri.
>
> Ciao,
>
> Andrea
>
>
> On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
> wrote:
>
>> Ciao,
>>
>> On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni <
>> cascaf...@gmail.com> wrote:
>>
>>> Ho standardizzato i civici, rimuovendo la barra e portando a
>>> maiusolo l'esponente.
>>>
>>
>> Perché in maiuscolo?
>>
>> Prima di continuare (chiunque), possiamo almeno scrivere una pagina
>> di import che descrivere le cose fatte/da fare?
>>
>> Lato mio posso: a) fare uno script di conversione con ogr2osm b)
>> suggerire di usare come modello la pagina di import che avevo fatto per
>> Biella
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
>>
>> Grazie,
>>
>> Andrea
>>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Éric Gillet]

Le 28/05/2020 à 22:47, osm.sanspourr...@spamgourmet.com a écrit :


c'est donc un footway.


On est d'accord.


[si les piétons] sont prioritaires c'est que d'autres usagers ceux à 
qui s'adresse le panneau, ici les cyclistes, sont autorisés _en tant 
que tels_ et donc sans mettre pied à terre : malgré les apparence ce 
n'est pas un trottoir !


Ce panonceau n'a aucune existence légale. À mon avis il s'adresse aux 
vélos qui s'autorisent contre la signalétique/loi de continuer à 
circuler, afin de réduire les accidents. Autre exemple de ce panonceau 
[1], là encore pas utile car aux passages piétons les piétons sont dans 
tous les cas prioritaires.


S'ils avaient voulu faire une continuité légale, ils auraient eu plein 
d'autres moyens explicites. Ils ne l'ont pas fait, c'est un choix actif 
de leur part.


Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le choix 
de faire un "trottoir/accotement/zone piéton" partagé vélos/piétons [2]


On ne demande pas aux cyclistes de mettre pied à terre donc ils ont le 
droit de rester, donc :


bicycle =yes


Du coup non, pas adapté.


ou plutôt permissive. "Where bicycles do not have a legal 
right-of-way, but the land owner has indicated that bicycles are allowed".


On est sur la bonne voie (pun intended), mais non ce n'est toujours pas 
autorisé, et puni par une amande classe 4.


Est-ce que sur ce qui semble être un trottoir il y a un panneau 
avertissant les piétons de la circulation de cycles ? Rien vu depuis 
Mapillary.


Bonne remarque ! Malheureusement il n'y a rien, ni à proximité de la 
pharmacie qui fait un angle mort, ni à la pointe est où le passage et 
étroit et semé de bollards.


Par contre ce n'est pas sur cette liste mais avec la mairie ou la com 
com qu'il faudrait voir afin d'avoir une continuité dans de bonnes 
conditions.


Entièrement d'accord. D'ailleurs OSM est une base de données 
géographiques représentant le terrain et ses problèmes, pratique pour 
exposer les problèmes à la comcom non ? Sauf si l'on masque ces 
problèmes à coup de bicycle=yes là où il n'y a pas continuité. Dans ce 
cas ni les usagers, ni les comcoms peuvent voir les problèmes.


En cas d'accident il serait possible de se retourner contre 
l'aménageur car il semble que le piéton puisse de bonne foi se croire 
sur un trottoir. Et le cycliste sur une voie qui lui est ouverte.


Exactement. C'est d'ailleurs pour ça je pense qu'ils ne se risquent pas 
à autoriser les vélos, le passage est dangereux dans cette zone.


Mais à côté on voit aussi des piétons sur la voie cyclable 
...


À 50m à l'est de cette photo les piétons sont obligés de marcher sur la 
piste cyclable [3], un autre problème d'aménagement de cette zone...




[1] https://www.mapillary.com/map/im/969md9UGZr2oD37Ivqbdsw

[2] https://www.mapillary.com/map/im/LJ4yfEmq6v3tUR65ku3cIA

[3] https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA

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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Philippe Verdy]

Le jeu. 28 mai 2020 à 17:04, Rpnpif via Talk-fr 
a écrit :

> Le 28/05/2020 à 15:29, Jean-Claude Repetto a écrit :
> > Bonjour,
> >
> > Je réponds partiellement:
> >
> > Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit :
> >>
> >> Je me permets d'écrire sur cette liste, merci de me dire si ce n'est
> >> pas le bon endroit. J'ai envoyé un message sur le forum, mais j'ai
> >> l'impression que ma question aura peut-être plus de chances de
> >> réponses sur cette liste !
> >
> > Oui, cette liste est beaucoup plus active que le forum.
> >
> >> "Saint-M'Hervon" a été engloutie par la commune de
> >> "Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit,
> >> est-ce ok ?
> >
> > Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus
> > approprié.
>
> Bonjour,
>
> Un lieu-dit, mot générique, peut avoir des habitants ou pas car place
> signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant,
> c'est place=locality.
>
> Et bien se souvenir que il n'y a malheureusement aucun rendu pour le
> moment des communes nouvelles issues de la fusion sur la carte
> officielle https://www.openstreetmap.org/ sauf, comme dans ce cas, si la
> commune ne change pas de nom.


Ce n'est pas exact: si les noeuds représentent les place=* pour les noms
locaux, les noms des relations sont visibles le long des frontières (il
suffit de zoomer pour les voir). si on dézoome, le noeud va être trop petit
par rapport à la relation, et la relation prend le pas, masquant le noeud
représentant une relation plus petite quand on ne peut pas afficher les
deux.

Pour les communes nouvelles, comme elles conservent la toponymie des
communes membres, le nom de la commune nouvelle ne remplace pas celui des
communes membres, qui conservent également leur code INSEE propre à 5
chiffres (même si ces communes ne sont plus de "plein exercice" en tant que
personnes morales séparées, le code INSEE à 5 chiffres est un code
géographique, pas un code sur la personne morale qui, elle, est codée avec
le code SIREN). La commune nouvelle adopte simplement le code INSEE à 5
chiffres d'une de ses communes membres, celle de son chef-lieu, les
"anciens" codes INSEE à 5 chiffres ne sont pas "supprimés", il restent en
vigueur et même liés aux communes membres. L'association du code INSEE à 5
chiffres avc la commune nouvelle est seulement une "facilité".

C'est pour ça qu'on a mis en plus dans OSM l'attribut
"admin_type:FR=commune [nouvelle/déléguée]" pour distinguer deux
utilisations du même code INSEE à 5 chiffres qui permet de distinguer deux
entités "communes" selon leur type et qui se partagent le même code INSEE à
5 chiffres.

L'atrtibut "end_date=*" ne signifie pas la "fin" d'une commune membre,
seulement son changement de statut en tant que commune de plein exercice,
mais la commune (déléguée) existe toujours sous son nouveau statut (sans
personnalité morale, donc plus avec un code SIREN puisqu'elle devient un
ensemble d'établissements (SIRET) parties de la commune nouvelle. L'ancien
SIREN est terminé, pas leur code INSEE à 5 chiffres, et les anciens SIRET
de l'ancienne commune pleine devenue commune déléguée sont donc modifiés
(si les établissements existent encore, ce qui est souvent le cas pour
nombre d'établissements) en créant de nouveaux établissements dans le
nouveau code SIREN de la commune nouvelle (ce nouveau code SIREN est basé
sur le code INSEE à 5 chiffres de la commune déléguée chef-lieu)



> Dans ce cas et autrement, on ne voit que
> les communes anciennes sur la carte, marquées par un point place=village
> ou bien place=* (autre). Alors que pour toutes les communes anciennes
> fusionnées ou pas, un point place=* est placé traditionnellement en plus
> de la frontière sous forme de relation même si la commune ancienne
> comprend plusieurs place=village (agglomérations de plus de 200
> habitants). La raison est que les relations comportant le nom de la
> commune nouvelle ne sont pas malheureusement non plus rendues (sauf le
> long de la frontière de la commune en tout petit).
>
> La carte https://www.openstreetmap.org/ a choisi de ne pas représenter
> les surfaces place=* pour une raison qui m'est inconnue contrairement à
> l'application OsmAnd.
>
> Comme la communauté française a choisi de ne pas ajouter de point
> place=* pour les communes nouvelles (alors que pour les habitants de
> plus en plus celles-ci sont entrées dans la vie quotidienne entre autres
> pour des raisons postales et de transports) et bien ces communes sont
> invisibles sur ce rendu comme sur celui de openstreetmap.fr.
>

Il ne faut pas confondre les noms des collectivités territoriales
(personnes morales) avec les noms géographiques (qui n'ont aucune
obligation de désigner la même chose). L'organisation
adminsitrative/fiscale/comptable/électorale est indépendante de
l'organisation territoriale qui conserve sa finesse et sa pertinence.

Personnellemment je vois les noms des communes nouvelles de la même façon
que les noms des enseignes