Re: [OSM-talk-fr] Accès très limité à BD Carthage

[Cyrille37 OSM]

Bonjour et Merci Thomas.

Je n'arrive pas à obtenir les tuiles avec ce réglage de base dans JOSM :

Merci

Cyrille37

Le 17/04/2024 à 00:07, Thomas Gratier a écrit :

Bonjour,

Je n'ai pas de réponse à te donner concernant la BD Carthage. Néanmoins, si
tu travailles sur les plans d'eau, tu peux te tourner vers l’inventaire
national des plans d’eau (INPE) qui date de 2023 et est donc plus récent
que la BD Carthage.
Il est disponible soit sous forme fichiershttps://geoservices.ign.fr/inpe
(converti les GPKG en shp pour un usage JOSM) soit en ajoutant le WMTS
depuishttps://data.geopf.fr/wmts, soit le WMS
https://data.geopf.fr/wms-v/ows  (utile, en particulier si tu utilises JOSM)


Thomas Gratier

Le lun. 15 avr. 2024 à 10:25, rpnpif  a écrit :


Bonjour,
J'ai depuis quelques jours, un accès très limité et très lent à BD
Carthage (plans et cours d'eau). J'ai ai vraiment besoin pour ajouter
des plans d'eau peu visibles à OSM. (L'accès au forum est aussi assez
lent chez moi).
Je me demandais si cela venait de mes accès DNS ou bien si c'est dû aux
serveurs OpenStreetmap.fr. J'ai vu plusieurs rapports de problèmes sur
Github.
Serais-ce lié ?

--
Rpnpif



___
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] Serveur OSM-FR en vrac ?

[Cyrille37 OSM]

Hello

Il y a un ticket créé hier 
https://github.com/osm-fr/infrastructure/issues/547


Le 31/03/2024 à 12:04, Stéphane MARTIN via Talk-fr a écrit :

Bonjour,

Problème avec le serveur de tuiles ?

https://{s}.tile.openstreetmap.fr/osmfr/{z}/{x}/{y}.png; n’affiche plus
de rendu (site web, QMapShack).

@+

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

[Talk-bd] OSMBD Community Election 2024 Result Announcement! ✨️

[OSM Bangladesh EC]

Dear Community Members,

We're thrilled to announce the results of the OSMBD Community Election!

   - Afia Tahmin Jahin
   - Atikur Rahman
   - Laila Sharmin Nova
   - Md Nahid Ferdous
   - Md Samsul Arafin
   - Mehedi Hasan Ovi
   - Sawan Shahriar

emerged as the winner, with a total of *58%* of the votes cast, showcasing
OSMBD Community Executive Members.
Thank you to everyone who participated and made their voices heard. Your
engagement is what makes our community vibrant and inclusive.

Best regards,
OpenStreetMap Bangladesh Election Commission
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

[Talk-bd] New Election Date Announcement 

[OSM Bangladesh EC]

Dear Voting Members of OpenStreetMap Bangladesh Community,

We sincerely apologize for difficulties caused by the unanticipated
technical issue with the voting procedure on the scheduled date. We work
through the technical issues and aim to cause no further disruptions.

Rescheduled election date : 17 February 2023 (Saturday)

Cast your votes on the specified date to elect the representatives who will
shape the future of OpenStreetMap Bangladesh.

=

 Important Dates:
Election Day: February 17, 2024️ (Saturday)
Results Announcement: February 17, 2024


 Voting Process Overview:
Voting process demonstrate here:
https://www.facebook.com/share/v/tmpjyZVYTpCshyJD/?mibextid=oFDknk


 The Election Process:
Visit here to know more about the election process-
https://drive.google.com/drive/folders/1c8yiPrm8gTEZUWW2SB3aqMK3dfuwO_wj?usp=sharing


Share your vision for OpenStreetMap Bangladesh.


Dear eligible voting members, please check your email to know in details.

If you have any queries, reach the Chair of EC
+8801713120157 (Whats app text only)
azizulalamto...@gmail.com (Email)

Best regards,
OpenStreetMap Bangladesh Election Commission ️
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

[Talk-bd] OSMBD Election Manifesto Presentation & Q/A Session and Voting Process Demonstration

[OSM Bangladesh EC]

Dear Voting Members of OpenStreetMap Bangladesh Community,

Hope this mail finds your well. We are delighted to inform you that the
Manifesto Presentation & Q/A Session date fixed on 3 Feb, 2024. Election
Commission also demonstrate about the voting platform and the voting
process. All voting members are invited to attend the meeting.


link will provide before the meeting.

 Important Dates:
Manifesto Presentation & Q/A Session: 3 Feb, 2024
Election Day: February 10, 2024️
Results Announcement: February 10, 2024

 Election Process Overview:
The election platform will be introduce with you soon.
Engage in community meetings and campaign where voting members discuss and
deliberate on candidates' contributions, visions, and goals. (Manifesto
Presentation & Q/A Session: 3 Feb, 2024)

Cast your votes on the specified date to elect the representatives who will
shape the future of OpenStreetMap Bangladesh.

 The Election Process:
Visit here to know more about the election process-
https://drive.google.com/drive/folders/1c8yiPrm8gTEZUWW2SB3aqMK3dfuwO_wj?usp=sharing

Share your vision for OpenStreetMap Bangladesh.

Dear eligible voting members, please check your email to know in details.

If you have any queries, reach the Chair of EC
azizulalamto...@gmail.com (Email)

Best regards,
OpenStreetMap Bangladesh Election Commission ️
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

[Talk-bd]  OpenStreetMap Bangladesh Election 2024 Election Dates Rescheduled⏳ ️

[OSM Bangladesh EC]

Election Dates Rescheduled⏳

 OpenStreetMap Bangladesh Election 2024 ️

Dear Voting Members of OpenStreetMap Bangladesh Community,

We have rescheduled the election dates. We would like to inform you of the
important dates in this mail. And the candidates names and symbols will
inform you soon.


 Important Dates:
Manifesto Presentation & Q/A Session: 3 Feb, 2024
Election Day: February 10, 2024️
Results Announcement: February 10, 2024

 Election Process Overview:
The election platform will be introduce with you soon.


Engage in community meetings and campaign where voting members discuss and
deliberate on candidates' contributions, visions, and goals. (Manifesto
Presentation & Q/A Session: 3 Feb, 2024)

Cast your votes on the specified date to elect the representatives who will
shape the future of OpenStreetMap Bangladesh.

 The Election Process:
Visit here to know more about the election process-
https://drive.google.com/drive/folders/1c8yiPrm8gTEZUWW2SB3aqMK3dfuwO_wj?usp=sharing

Share your vision for OpenStreetMap Bangladesh.


Dear eligible voting members, please check your email to know in details.

If you have any queries, reach the Chair of EC
azizulalamto...@gmail.com (Email)

Best regards,
OpenStreetMap Bangladesh Election Commission ️
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

[Talk-bd]  OpenStreetMap Bangladesh Election 2024 Election Dates Rescheduled⏳ ️

[OSM Bangladesh EC]

Election Dates Rescheduled⏳

 OpenStreetMap Bangladesh Election 2024 ️

Dear Voting Members of OpenStreetMap Bangladesh Community,

We have rescheduled the election dates. We would like to inform you of the
important dates in this mail. And the candidates names and symbols will
inform you soon.


 Important Dates:
Manifesto Presentation & Q/A Session: 3 Feb, 2024
Election Day: February 10, 2024️
Results Announcement: February 10, 2024

 Election Process Overview:
The election platform will be introduce with you soon.


Engage in community meetings and campaign where voting members discuss and
deliberate on candidates' contributions, visions, and goals. (Manifesto
Presentation & Q/A Session: 3 Feb, 2024)

Cast your votes on the specified date to elect the representatives who will
shape the future of OpenStreetMap Bangladesh.

 The Election Process:
Visit here to know more about the election process-
https://drive.google.com/drive/folders/1c8yiPrm8gTEZUWW2SB3aqMK3dfuwO_wj?usp=sharing

Share your vision for OpenStreetMap Bangladesh.


Dear eligible voting members, please check your email to know in details.

If you have any queries, reach the Chair of EC
azizulalamto...@gmail.com (Email)

Best regards,
OpenStreetMap Bangladesh Election Commission ️
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

Re: [OSM-talk-fr] Une carte pour Pifomètre

[Cyrille37 OSM]

Bonjour

Waouh, merci !

Cyrille37

On 14/10/2023 20:14, Vincent de Château-Thierry wrote:

Bonjour,

J'ai mis en ligne il y a quelques jours une version cartographique de 
Pifomètre, afin d'accéder autrement à l'analyse des voies et adresses 
manquantes dans OSM en vue de leur intégration. J'en ai parlé sur le 
forum : 
https://forum.openstreetmap.fr/t/pifometre-a-sa-carte-pifomap/18040 et 
le service se consulte à : 
https://bano.openstreetmap.fr/pifometre/pifomap.html


Pour démarrer, entrer un code INSEE de commune en haut à gauche ou 
bien baladez vous sur la carte jusqu'à voir le nom de la commune que 
vous voulez analyser, puis cliquez dessus.


Vous reconnaîtrez le code couleur rouge du rendu BANO, sans lequel on 
ne dégommerait rien. Pour les autres couleurs, une légende (en haut à 
droite) vous donnera quelques billes.


merci

vincent


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

Re: [OSM-talk] When two bots go to war

[Robert Whittaker (OSM lists)]

Maybe there should be a general good-practice recommendation / policy
that bots running in this fashion to keep things in sync should only
automatically add/update/remove a tag that they've previously set if
the current state/value in OSM is unchanged from the last state/value
that the bot set. This way, bots could be used to keep things up to
date automatically, but would not automatically override any manually
applied changes by other mappers between runs. (A sensible bot owner
would have the bot send them a report of any tags that couldn't be
updated for manual review.)

Robert.

On Thu, 14 Sept 2023 at 08:41, Cj Malone
 wrote:
>
> On Tue, 2023-09-12 at 15:06 +0200, Snusmumriken via talk wrote:
> > My speculation is that Distriktstandvården (a chain of dental
> > clinics)
> > has taken "ownership" of "their" nodes and once a day check that the
> > values in osm database correspond to that of their internal database.
>
> I've added a more specific website tag to test this. If they restore it
> (Probably 03:00) to the generic home page I agree with you. They need
> to be informed that 1) there data needs improving (eg covid opening
> hours, POI specific not brand specific contact details) 2) they don't
> own these nodes, other people can edit them.
>
> CJ
>
> https://www.openstreetmap.org/changeset/141243391


-- 
Robert Whittaker

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

Re: [OSM-talk-fr] Données Overture Maps - export OSM normalisé

[Cyrille37 OSM]

Bonjour

On 08/08/2023 23:05, LeTopographeFou wrote:
A mon avis (et comme j'ai déjà eu l'occasion de l'évoquer de manière 
sporadique) OSM gagnerait à disposer d'un service facilitant la mise à 
disposition des données qu'il agrège. En entrée ce service prendrait 
la base OSM avec ses forces et ses faiblesses, en sortie il 
proposerait une (ou plusieurs...) bases de données propres et 
pré-processées, aux schémas clairs et pensés pour être efficace et 
sans interprétation.


Il me semble que quelques coder français (@panierAvide ? @cquest ? @vdct 
? ...) ont fait une telle proposition il y a qlqs années, un export osm 
simplifié et normalisé.


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

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

[Cyrille37 OSM]

Bonjour,

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


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


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


Cyrille37.

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

Bonjour,


De: "Marc_marc"

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



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

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

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

Questions :

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

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


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

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

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

merci

vincent

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

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

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

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

[Cyrille37 OSM]

Bonjour

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


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


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


Cyrille37.

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

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


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

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

Re: [OSM-talk-fr] Le forum et la liste

[Cyrille37 OSM]

Bonjour,

Merci pour ces comptages qui nous éclairent.

Et une belle journée à toutes et tous.

Cyrille37.

On 20/04/2023 17:03, Vincent de Château-Thierry wrote:

Bonjour,

- Mail transféré -

De: "Marc_marc"
À: "Discussions sur OSM en français"
Envoyé: Lundi 17 Avril 2023 12:54:43
Objet: Re: [OSM-talk-fr]  traduction de "tag" en français dans JOSM
Marc qui a voté sur le forumhttps://localhost, ben quoi
faut fragmenter...

Je rebondis sur cette remarque (pique ?) de Marc au sujet du forum et de la 
fragmentation, pour donner quelques éléments factuels sur le 
forumhttps://forum.openstreetmap.fr/

En 1 année glissante (20 avril 2022 -> 20 avril 2023) le forum a vu :
- la création de 4400 sujets, soit environ 12/jour
- l'arrivée de 600 nouveaux inscrits (pour un total de 3000, soit 4x plus que 
la liste talk-fr)
- la publication de 11000 posts soit environ 30/jour

Sur la même période on compte 1062 messages sur cette liste, à peine 3/jour.

Évidemment chacune, chacun a ses habitudes de lecture, ses préférences en 
termes d'ergonomie, et je ne suis pas là pour en juger. Mais poster sur le 
forum, en 2023, n'est pas fragmenter, au contraire : c'est aller à la rencontre 
du plus grand nombre, se donner le plus de chances de recevoir avis, arguments, 
conseils.

Voilà, sans polémique, mais pour mettre un peu à jour le paysage de nos canaux 
de communication, notamment pour celles et ceux qui ne consultent que la liste.

merci
vincent

___
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] Why set coast line to nation park or, administrative boundaries?

[OSM via Talk-au]

I looked at the separation of park boundaries and coastlines down in 
Wilson's Prom a while ago and asked the #oceania discord at the time but 
never ended up changing anything. If you look at the legal definition of 
many national parks, their boundaries are defined by the high water 
mark. Since the coastline tag is also supposed to represent the high 
water mark then I would say that they should be snapped together (since 
they then represent the same feature - that is, the high water mark). 
This would mean that the boundary data already in OSM from the 
government basemaps would just be their own mapping of the high water 
mark, and probably be less up to date or refined as our own.
The other issue I wasn't sure about was the copyright of the government 
maps that declare these national parks as following the high water mark. 
You could argue that its a legal fact and therefore can't be copyrighted 
but it is also hard to find that information outside of government run 
archives. (The parks are usually represented on maps of the area by the 
Surveyor General and make references to the high water mark, at least in 
Vic).


This is my first time responding on talk-au, lmk if I've messed up any 
formatting to link to the original question.


On Tue, 28 Mar 2023, at 10:58 AM, Warin wrote:


Hi


Looks like some are setting natural features to government boundaries.


A recent case along the WA south coast has been going on for some years..

The coast line looks very confused and the National Park boundaries are
being changed to the coast line in reverse of what is stated on the
change sets... (bangs head on wall).


I was altered to it by OSMInspector identifying the National Park
boundary being broken by the 'adjustment' of the 'coastline' ... that
broke the National Park boundary...

The National Park boundary looks, in some places, to be the low tide
mark and then in other places to be the hi tide mark, so it is not
consistent.


I do understand where the two (natural feature and government boundary)
coincide that it is easier to use the same way. But every now and then
someone moves it to conform to the latest imagery of the natural feature
.. thus moving the government boundary .. unintended but there we go. My
only solution si to have them as separate ways .. making it easier to
divorce the new nodes added for the new nature feature addition from the
old government boundary.


Any other ideas???



___
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] Fédération des pros d'OSM

[Cyrille37 OSM]

Bonjour à toutes et tous

Merci beaucoup Séverin d'aborder aussi clairement ce sujet qui 
aujourd'hui est "cool" mais qui peut à terme de devenir un pot à 
embrouilles, comme tu l'expliques clairement dans ta publication.


Évoluant dans le monde de l'économie "privée" je constate qu'à la 
naissance une Fédération professionnelle (/aka: business/) est une 
démarche bienveillante et plébiscitée, mais que le marché croissant 
(/aka: le pognon arrivant/) naissent fréquemment des conflits de pouvoir 
(/aka: de concurrence/)/, /avec in fine des combats juridiques et/ou 
financiers inégaux.


Je trouve ta proposition de "sous-titre" un bon compromis / consensus 
que pourrait adopter la Fondation OSM.


Ceci n'est qu'un témoignage (/aka: je botte en touche/), ne m'impliquant 
ni dans ce projet de fédé des pros, ni dans les aspects juridiques de la 
Fondation OSM (/je n'ai carrément pas le niveau/).


Bien à vou⋅e⋅s

Cyrille37

On 25/03/2023 19:41, severin.menard via Talk-fr wrote:

Bonsoir,

Je viens de publier [ce billet de journal 
OSM](https://www.openstreetmap.org/user/SeverinGeo/diary/401231) en lien avec un point à 
l'ordre du jour la semaine prochaine lors de la réunion mensuelle du Conseil 
d’administration de la Fondation OpenStreetMap concernant le projet "Fédération des 
pros d'OSM".

Pour celles et ceux qui ne seraient pas au fait de la marque déposée 
OpenStreetMap, [voici le 
lien](https://wiki.osmfoundation.org/wiki/Trademark_Policy) vers la page 
concernée sur le site de la Fondation OSM.

Bon WE,

Séverin
___
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] [édition mécanique] sidewalk=none -> sidewalk=no en France

[Cyrille37 OSM]

Bonjour,

On 15/03/2023 01:29, Marc_marc wrote:

je propose l'édition de masse suivante :
remplacement de sidewalk=none par sidewalk=no
sur les objets way ayant un tag highway
en France
...

Avis ?


Positif. Let's go :-)

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

Re: [OSM-talk-fr] adresse - numéros en double entre Chanceaux-sur-Choisille et Notre-Dame-D'Oé (Indre-et-Loire)

[Cyrille37 OSM]

Merci Vincent,
C'est tout simple et ça passe bien la validation josm :-)

Deux relations avec le même nom de rue ; je verrais dans qlqs jours 
comment Nominatim s'en sort ...


- 
https://www.openstreetmap.org/relation/3405917#map=19/47.46618/0.70194=D
- 
https://www.openstreetmap.org/relation/15421895#map=19/47.46602/0.70215=D


Cyrille.

On 02/02/2023 12:37, Vincent de Château-Thierry wrote:

De: "Cyrille37 OSM"

La Rue de Bretagne est à cheval en les communes de
Chanceaux-sur-Choisille et Notre-Dame-D'Oé et étrangement de chaque côté
de la rue on retrouve les mêmes numéros: les 2, 4 et 6. Du coup Josm
n'est pas content et il ne doit pas être le seul.

J'ai forcé l'envoi des données malgré l'erreur de validation.

Existe-t-il une façon de taguer correctement ce cas atypique ?

Si la rue est à cheval sur les 2 communes tu devrais composer une relation 
associatedStreet par commune. On y trouverait à chaque fois le filaire de voie, 
mais pour les numéros, chaque relation n'incluerait que ceux de sa commune. Par 
suite, plus de souci de validation ni de modélisation.

vincent

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

[OSM-talk-fr] adresse - numéros en double entre Chanceaux-sur-Choisille et Notre-Dame-D'Oé (Indre-et-Loire)

[Cyrille37 OSM]

Bonjour

La Rue de Bretagne est à cheval en les communes de 
Chanceaux-sur-Choisille et Notre-Dame-D'Oé et étrangement de chaque côté 
de la rue on retrouve les mêmes numéros: les 2, 4 et 6. Du coup Josm 
n'est pas content et il ne doit pas être le seul.


J'ai forcé l'envoi des données malgré l'erreur de validation.

Existe-t-il une façon de taguer correctement ce cas atypique ?

C'est là : 
https://www.openstreetmap.org/relation/3405917#map=19/47.46618/0.70194=D


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

Re: [OSM-talk-fr] Mise à jour de Nominatim/Special_phrases/FR

[Cyrille37 OSM]

Bonjour Daniel,

Après avoir consulté la page FR:Tag:amenity=library 
 et sa 
page de discussion je trouve ta proposition pertinente, car la 
distinction entre Bibliothèque et Médiathèque ne se fait que sur le nom.


Tu peux toujours poser un argumentaire sur la page de discussion de 
Nominatim/Special Phrases/FR 
 qui 
est probablement suivi par quelques-uns (page's watchlist).


Cyrille37.

On 22/01/2023 20:32, Daniel Garcia wrote:

Bonjour,

Suite à ma discussion à propos de l'efficacité de Nominatim pour trouver
des médiathèques, je viens d'apprendre (grâce à l'hebdoOSM)
l'existence des *special
phrases* (https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/FR).

Il me semblerait utile de dupliquer les phrases liées à "Bibliothèque" pour
ajouter la forme "Médiathèque", vu que, au moins dans ma région, *toutes*
les bibliothèques publiques sont appelées Médiathèques (sauf des *Bibliothèques
Universitaires*).

Est-ce que, avant de faire une telle modification, il faut en discuter
quelque part ? La page de discussion sur le wiki n'a pas été modifiée
depuis 2013, donc j'imagine qu'elle n'est pas utilisée.

Cordialement,
Daniel

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

Re: [OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Le 08/01/2023 à 01:55, Christian Rogel -
christian.ro...@club-internet.fr a écrit :

Ce « Rond-point des Séminaristes » est doté de panneaux, « Cédez le passage » 
(en français et en breton, « Lezit da dremen ») , c’est donc un giratoire.
Mais sa surface me fait hésiter à dire que c’est un mini-giratoire


Regarde les liens passés : la réponse est évidemment oui.

En effet la forme doit être une calotte sphérique, c'est bon.

Et la structure compatible avec le passage des poids-lourds, et tu as
dit toi-même que c'était fait pour les bus.

Quelle est la surface en question ? Du béton ? Je ne vois pas ce qui te
fait douter, comme je dis au contraire c'est un très bon exemple.

Sinon comme prévu apron est trop proche de aeroway=apron, c'est le
retour des Allemands.

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

Re: [OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Ceci est un bel exemple de mini-giratoire.

Comme je disais en France un mini giratoire peut faire 16 m de diamètre
de bordure de trottoir à bordure de trottoir.

Et donc stricto-sensu il est actuellement mal tagué (même je préfère
dire que les mini-giratoires peuvent avoir une description surfacique
ceci est actuellement interdit).

> Je le franchis aussi en ligne droite avec mon tricycle.

Si tu /peux/ faire le tour tu /dois/ faire le tour. Je parle du code de
la route, version avril 2022.

> Il existe aussi, dan un autre quartier, un RP dans lequel un anneau
de ciment entoure la partie non carrossable, mais avec une élévation de
2 cm par rapport à la bande roulante.

C'est ce qui s'appelle un tablier de camion.

Si tu peux faire des photos et les publier avec la licence qui va bien,
ça pourra servir d'illustration.

Là soit on dit juste apron=yes (voir apron:height=0.02 m) soit
apron=separate et sur la zone en question highway:area=apron;height=0,02 m).

Le 08/01/2023 à 01:19, Christian Rogel via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Oui, je pense à un rond-point, dit "des Séminaristes 
»https://osm.org/go/erISPPXnt  que j’emprunte souvent. L’anneau central est 
constitué d'un renflement de ciment. Le diamètre est plus grand que les « mini 
roundabout » (entre 2 m et 2,50 ?). Cela a a été fait pour permettre aux bus de 
passer sans avoir à virer.
Je le franchis aussi en ligne droite avec mon tricycle.
Il existe aussi, dan un autre quartier, un RP dans lequel un anneau de ciment 
entoure la partie non carrossable, mais avec une élévation de 2 cm par rapport 
à la bande roulante. C’est là aussi pour que les PL virent plus facilement, les 
autres véhicules, vélos inclus, ne montent pas sur l’anneau surélevé.

Christian R.

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

Re: [OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Je n'avais pas vu vos nouvelles réponses mais j'ai tenu
"involontairement" compte de certaines remarques.

Christian, on parle de giratoires pas de ronds-points. Tu vas avoir des
soucis pour repasser le code^^.

Les giratoires, ce sont les anneaux de circulation modernes avec
priorité à gauche.
Les ronds-points ce sont les anciens à priorité à droite (même si tu
peux encore trouver cette dénomination sur le terrain
<https://www.mapillary.com/app/?lat=47.800138685833=-3.478138018=17=photo=645433909654516>).

Oui dans le langage courant on continue à tort de parler de rond-point
(ou on a a tort gardé des ronds-points priorité à droite).

Ceci dit dans ma réponse je précise qu'on peut mettre l'info en
propriété ou faire un objet séparé.

En ce moment, la mode est
la ligne en anneau continue qui réduit la surface carrossable.

Là ce sont pour de grands giratoires, pas forcément pertinent pour OSM
(lane= le fait bien et c'est infranchissable).

franchissables par tout véhicule

C'est le cas /potentiellement/ des mini-giratoires, ils sont par nature
<https://www.securite-routiere-az.fr/m/mini-giratoire/> franchissables,
d'où la discussion.

Mais attention l'article Article R110-2
<https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI45650507?dateVersion=07%2F01%2F2023=UZ41kg%3D%3D=1=franchissable=ALL_selection=code=date>
du Code de la route précise :

/- carrefour à sens giratoire : place ou carrefour comportant un
terre-plein central matériellement infranchissable, ceinturé par une
chaussée mise à sens unique par la droite sur laquelle débouchent
différentes routes et annoncé par une signalisation spécifique.
Toutefois,, les carrefours à sens giratoire peuvent comporter un
terre-plein central matériellement franchissable, qui peut être
chevauché par les conducteurs lorsque l'encombrement de leur véhicule
rend cette manoeuvre *indispensable* ;/

Volker, oui comme en Allemagne ou en Grande-Bretagne, les
mini-giratoires sont forcément traversants.

Si tu /dois/ le faire tu peux le faire (cas des véhicules
surdimensionnés comme les camions ou les bus ainsi, c'est à ça que doit
penser Christian, les plots de peinture au milieu d'un carrefour).
Sinon, ça dépend s'il y a un gendarme ou un policier ou si tu passes ton
permis^^.

Là
<https://www.mapillary.com/app/?z=17=48.38670806=-4.46306305608=820296985578730>,
si tu es suivi par une voiture, que le portail est (comme toujours)
fermé, je te conseille vivement de... passer à gauche (sans toucher
l'îlot central^^) car sinon tu risques de surprendre la personne et te
trouver nez-à-nez avec lui. Voiture HS ou pire deux-roues au tapis mais
rassures-toi, tu ne perdras pas de points (en France on commence avec 12
points).

Et au suivant
<https://www.mapillary.com/app/?z=17=48.38799972=-4.460258056=139447271493519=0.47751202296643264=0.854347449360849=2=photo>,
tu mangeras un peu la galette, c'est de saison.

Mais je rappelle, initialement le but est de savoir ce ce qu'on fait des
mini-giratoires et de la franchissabilité de tout ou partie du giratoire
pour savoir si c'est adapté aux poids-lourds.

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

Re: [OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Oui ça ressemble comme /traversée piétonne/ ressemble à /giratoire
traversant/.

Du coup je peux proposer truck_apron qui me faisait penser aux approches
sur un aéroport/voies de taxi) (taxi_apron= qui font penser aux... taxis
;-).

Deepl me proposait les deux mais en fait Wikipédia appelle ça
https://en.wikipedia.org/wiki/Truck_apron

J'avais pris bande franchissable car ça me semblait plus compréhensible
que tablier pour camion.

L'un adressant le moyen, l'autre le but (permettre le passage de camions).

Mais dans tous les cas c'est l'éditeur qui va afficher le nom (preset
JOSM ou iD). Donc sans grand enjeu français (si on est au niveau de
l'attribut brut, on peut supposer une certaine dextérité pour trouver de
quoi il en retourne, notamment via les liens wiki).


Rien n'a été envisagé sur les détails. Le but était de régler un conflit
d'usage, pas d'étendre les possibilités.

Le retour d'expérience sur les évolutions de tag c'est : avancer d'un
pas, penser 2 pas avant mais ne voter que sur le premier pas.


Maintenant truck_apron:surface=sett si tu veux dire que ce sont des
pavés, à la manière de ce qui se fait sur les trottoirs, ça semble
logique, compatible avec ce qui se fait déjà par ailleurs.


Sauf que du coup je reviens sur le truck apron:

/Both in roundabouts and slip lanes the truck apron is *raised
slightly*, in an attempt to keep light vehicles on the main road
surface. The truck apron is *constructed of reinforced concrete*./

Ben non, ce n'est pas le cas. On veut inclure les rond-points peints en
blanc.

Je ne sais si l'article est trop restrictif ou pas.

Donc en gardant le nom plus générique crossing_strip on n'a pas le souci
? Heu, si, certains semblent faire des différences et nomment "spiral
striping" du marquage au sol et "extended truck apron" si c'est en dur.

Et c'est trop générique :
https://www.everythingupland.com/Driveway-Crossing-Strip_DTS-1.html ;-)

En fait en français, tablier a aussi un sens "plat surélevé" qui ne
convient pas ici.

Quelqu'un peut trouver un nom commun en anglais ?

J'ai aussi trouvé mountable curb mais toujours pour les mêmes raisons ça
ne convient pas.

Potentiellement juste apron (définition des ronds-points Apron selon
NCHRP - NATIONAL COOPERATIVE HIGHWAY RESEARCH PROGRAM REPORT 672
Roundabouts: An Informational Guide
](), page 1-4 (oui, sans s) :

/An apron is the traversable portion of the central island adjacent to
the circulatory roadway that may be needed to accommodate the wheel
tracking of large vehicles. An apron is sometimes provided on the
outside of the circulatory roadway./

 Colle bien mais un tablier, n'est-ce pas rehaussé ? N'est-plat pas
plat ? En France les mini-giratoires ont forcément un centre en forme de
calotte sphérique.

Quant aux détails on peut aussi envisager

apron=separate.

Et après highway:area=apron avec tous les détails que tu veux ?

Donc je suis pour ajouter simplement une clé (apron ou autre).

Et revenir ensuite pour plus de détails.

Jean-Yvon

Le 07/01/2023 à 07:42, lejun - le...@gmx.fr a écrit :

Le 06/01/2023 à 23:24, osm.sanspourr...@spamgourmet.com a écrit :

|crossing_strip| - Bande franchissable (tablier pour camions)


L’idée me plaît, mais est-ce qu’on est sûr de vouloir partir sur cette
clé ? J’ai peur que le sens soit trop obscur et que ce soit rapproché
du highway=crossing.

En second point, est-ce qu’il a été envisagé une extension pour
détailler la bande ? J’y connais rien mais je suppose qu’on en trouve
différent types qui peuvent être catalogués.


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

[OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Bonjour,

une discussion sur le sujet a eu lieu sur
https://community.openstreetmap.org/t/mini-roundabout/7524/51

Au final je propose et ça à l'air de plaire :

|crossing_strip| - Bande franchissable (tablier pour camions)

Avec no comme valeur par défaut sur les "vrais" giratoires et yes sur
les mini-giratoires.

Comme ça les Anglais gardent les mini giratoires et sur le continent on
peut cartographier les giratoires accessibles aux poids lourds malgré
leur taille.

Résumé de la discussion :

elle fait suite à
https://lists.openstreetmap.org/pipermail/tagging/2019-October/thread.html#48852

Les définitions FR/EN/DE sont cohérentes :

https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dmini_roundabout

/Le tag //highway
=mini_roundabout//désigne
un micro giratoire où le terre-plein central est franchissable, soit car
il est absent (peinture au sol), soit car il dépasse très peu du sol. /

(et est réservé au ponctuel)

Les Anglais utilisent mini_roundabout pour des giratoires de petite
taille sur lesquels figurent le panneau même s'ils ne peuvent être
franchis (contraire à la définition du wiki). Ils doivent avoir
(contrairement aux autres giratoires) le panneau bleu à 3 flèches
blanches (dans le sens horaire car ils roulent à gauche).

Pour les Allemands un mini giratoire c'est de 13 à 22 m (taille
extérieure). Comme tous les giratoires il est signalé par le même
panneau (inversés, les Allemands roulant à droite). DE:215 (l'équivalent
de notre FR:AB25
).

Pour les Français moins de 24 m (bande roulante jusqu'aux bordures
intérieures de trottoir (le cas échant).

Partout ce sont les mêmes priorités aux véhicules sur le rond-point.

Malgré des échanges, les Anglais ne veulent pas supprimer les
mini-giratoires et les Allemands ayant de grands giratoires
potentiellement traversants veulent pouvoir signaler qu'un giratoire est
traversant si nécessaire. Comme ça le routage classique est bon (prenez
la 3e à droite), la géométrie est respectée. Et voulaient virer les mini
giratoires, ajouter la propriété d'être traversants aux ronds-points.

En France on a des machins tantôt définis comme giratoire
. Mapillary

Tantôt comme Mini giratoire

(carrefour suivant). Mapillary


En fait légalement

ce n'est pas un mini giratoire (la forme n'est pas une calotte sphérique).
Ici il y a un “Bande franchissable (tablier pour camions)” côté
intérieur./Crossing strip (truck apron)/ en anglais
.

D'où mon idée de |crossing_strip=yes| par défaut pour les
|highway=mini_roundabout| et les cas pathologiques comme ci-dessus.
|crossing_strip=no| pour les |junction=roundabout| et les cas
pathologiques comme ici  -
Mapillary

(ici légalement c'est un mini-giratoire).

Les anglais seraient contents, et continueraient à cartographier
contrairement au wiki.

Et sur le continent on pourrait cartographier proprement ;-).

Des opinions ?

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

Re: [OSM-talk-fr] bac à marée

[osm . sanspourriel]

Un gros conteneur à déchets ménagers se tague aussi avec :
amenity=recycling
recycling_type=container

Si tu regardes la liste, tu trouveras un certain Marc_marc utilisant ça
pour les composteurs qui font du sous-cyclage ;-).

À la rigueur un amenity=waste_disposal (ce n'est pas une poubelle mais
un conteneur cependant Brice je ne suis pas pour, voir plus loin).

Mais comme disait Yves, recycling:waste=yes est proposé par JOSM.

D'un point de vue usager, qu'au final ce soit recyclé ou pas, ne change
rien (d'ailleurs en cas de hausse du prix de l'énergie des plastiques ou
papiers recyclables ont dû être brûlés, on a aussi vu un remélange après
tri car les contrats de tris n'étant pas prêts ça partait à
l'incinérateur...).

Souvent les bacs à marée sont à côté de simples poubelles jaunes
(recyclables) ou bleues (déchets ultimes).

amenity=waste_basket ou amenity=waste_disposal c'est pour de la collecte
indifférenciée.

Là c'est de l'apport volontaire *différencié*, on ne doit surtout pas
confondre avec une poubelle vrac ou un conteneur vrac.

Il ne faut mettre *que* des déchets ayant mariné ;-), d'origine
anthropique, solides et non dangereux.

Donc mettre la même clé que des déchets qui non par essence non triés
est une mauvaise idée, notamment parce si les touristes (principalement)
mettent d'autres déchets les métriques sont faussées.

D'où l'enlèvement de certains bacs en été. Si en plus avec la clé vous
voulez les tromper ;-)

Jean-Yvon



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

Re: [OSM-talk-fr] bac à marée

[osm . sanspourriel]

(message mis à jour grâce au retour de pulsati0n sur une de mes
modifications).

Bonjour, vu l'inhomogénéité des données dans OSM, j'ai fait une passe.

J'ai mis :

amenity=recycling
recycling_type=container
opening_hours=24/7
description=Bac à marée (pour les déchets marins d'origine anthropique
récoltés sur le littoral)
recycling:marine_litter=only

Dans la plupart des cas on doit pouvoir ajouter :
material=wood
voir operator=, colour=...

https://overpass-turbo.eu/s/1pAK

Qu'est-ce ? des conteneurs à déchets anthropiques solides non organiques.

Le plus simple :

https://www.lechateaudoleron.fr/wp-content/uploads/2016/02/bac-%C3%A0-mar%C3%A9e.jpg
(5 palettes renforcées : fond et 4 côtés)

Version améliorée avec un couvercle en contreplaqué qu'on espère marine :

https://saintclementdesbaleines.fr/wp-content/uploads/2020/12/IMG_20201209_154313-1200x900.jpg

Avec panneau informatif détaillé (attention, faute de goût : les films
plastiques vont s'échapper) :

https://www.villeintelligente-mag.fr/photo/art/grande/24238121-26149997.jpg?v=1533229976

Avec collecte sélective à côté :

https://www.saintnazaire.fr/fileadmin/images/180108_Bacs_maree_plage_Hulot.JPG

Le plus esthétique du fait de la présence d'un bâtiment classé au
patrimoine de l'humanité à proximité (condition non indispensable, du
coup tous les nouveaux conteneurs de la Presqu'île de Crozon sont
esthétiques) :

https://presqu-ile-de-crozon.com/environnement/bac-a-maree-001.php

On y met : ce qui est sur le littoral d'origine humaine et non organique :

- verres
- plastiques
- pneus
- cordage
- déchets ostréicoles
- métal

On n'y met pas notamment :

- déchets dangereux (même si un obus est d'origine humaine et non
organique -:))
- laisse de mer "normale" (végétaux, bois)
- ordures ménagères

Justification :

amenity=recycling
recycling_type=container

car ce sont des conteneurs. Ceux qui collectent ne font pas la
différence suivant l'usage ultime (recyclage peu probable ici !
valorisation thermique ou enfouissement).

opening_hours=24/7

car ces sites de collecte sont ouverts en permanence (situés sur la voie
publique). Attention cependant : opening_hours=Sep-May par exemple et
intermittent=yes peuvent être plus adaptés (voir le bon article
https://www.ouest-france.fr/bretagne/crozon-29160/en-images-le-precieux-et-necessaire-retour-des-bacs-a-maree-sur-la-cote-d75771e2-4922-11ec-a0b7-64a183ad6699
pour les explications).

recycling:marine_litter=only

only car seuls ces déchets sont collectés, à l'exclusion d'autres
déchets de même type mais "neufs" (sans vieillissement par la mer).

marine_litter : car malgré le nom, le PNUE précise dans :

https://www.unep.org/explore-topics/oceans-seas/what-we-do/working-regional-seas/marine-litter

Marine litter is any persistent, manufactured or processed solid
material discarded, disposed of or abandoned in the marine and coastal
environment.

C'est à dire (merci Deepl, pas mieux ;-), commentaires entre crochets) :
Les déchets marins sont des matières solides [pas de pétrole]
persistantes, fabriquées ou transformées, jetées, éliminées ou
abandonnées [pas de laisse de mer naturelle] dans l'environnement marin
ou [bon Deepl disait et] côtier.

Qu'en pensez-vous, je mets ça sur le wiki ? On fait une proposition en
bonne et due forme ? En fait Philippe a déjà mis à jour :
https://wiki.openstreetmap.org/wiki/Proposed_features/Marine_litter_waste_disposal

Astuce : si vous voyez des déchets ostréicoles nombreux (liens
plastiques, caoutchouc, disques, grilles plastiques...), pensez à
appeler le Conservatoire du Littoral ou une association de protection du
littoral, ils sauront expliquer à l'ostréiculteur/-trice du coin que ça
dévalorise son produit.
Pour les billes de bois, remontez-les à l'abri de la mer, les marins
apprécieront.

N. B. : certaines décharges proches de la mer après avoir formé des
"plasticroûtes" relarguent du fait de l'érosion. Ces déchets ménagers
"historiques" sont à mettre dans les bacs à marée !

N. B.2 : je n'ai pas pris contact avec la SCIC éditrice de
https://bacamaree.app/, Il faudra le faire et pas seulement parce qu'ils
utilisent un fond OpenStreetMap non attribué ;-).

Jean-Yvon

Le 02/04/2019 à 10:57, marc marc - marc_marc_...@hotmail.com a écrit :

il me semble que le sujet a déjà été abordé
sur la liste, recherche les archives, cela évitera
de refaire à 0 :)
et on aurait intérêt à mettre la conclusion sur le wiki.

Le 02.04.19 à 07:53, erwan salomon a écrit :

amenity=waste_disposal

ok de premier abord, mais le wiki dit que ce ne sont pas poubelle de
passage mais qui servent à récolter en qlq sorte d'autres poubelles.
du coup amenity=waste_basket est put-être + adapté, éventuellement
complété par + capacity=*


waste=mixed (47 selon taginfo, mais pas spécifique)

c'est ce que j'aurais mis.
c'est spécifiquement du non trié :)
ou est-ce que tu veux préciser qu'on peux mettre des déchets n'ayant
pas transité par la mer ? (ce serrait un pe

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[osm . sanspourriel]

Bonjour,

Tu as peut-être raté cette information :

https://forum.openstreetmap.fr/t/cartomobilite-dispo-en-france-cartographier-laccessibilite-fauteuil-roulant-des-lieux-et-remonter-les-obstacles/11579

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

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations (inclinomètre)

[osm . sanspourriel]

Le 12/12/2022 à 18:45, Volker Schmidt - vosc...@gmail.com a écrit :


- Pour mesurer les pentes, il te faut un inclinomètre.


Pas forcément. Un niveau à bulle tout bête... permet de calibrer Bubble,
https://f-droid.org/fr/packages/org.woheller69.level/

Donc ceux qui ont un Android n'ont pas besoin impératif d'inclinomètre
en tant que tel, ils peuvent utiliser les capteurs de leur téléphone.

Jean-Yvon

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

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[osm . sanspourriel]

Christian veut dire :

library:for=general public.

(sans accents).

Mais sur le fond, l'audience que ce soit pour une bibliothèque ou un
centre social c'est pareil.
Pourquoi l'enfermer dans un espace de nommage ? Oui social_facility:for
 l'est !

Jean-Yvon

Le 11/12/2022 à 23:20, Christian Rogel -
christian.ro...@club-internet.fr a écrit :

  Dans mon schéma provisoire de tagage cela correspond à amenity=library et à 
library:for= général public.

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

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[osm . sanspourriel]

Le 08/12/2022 à 11:33, Daniel Garcia - dhe...@gmail.com a écrit :


Ensuite, j'ai
(étrangement) des endroits comme la mairie qui sont marqués comme
inaccessibles, alors qu'elle est bien accessible (j'ai même vu quelqu'un en
fauteuil roulant au 1er étage, donc ils ont des ascenseurs).


Attention : avoir vu un handicapé PMR à l'étage n'implique pas que
l'étage soit accessible aux handicapés.

Dans ma mairie, il y a un monte-charge pas un ascenseur, donc une témoin
de mariage PMR a pu être témoin de mon mariage.

Il n'empêche, l'étage ne doit pas être considéré comme accessible aux
handicapés.

Par contre noter une accessibilité partielle, c'est utile, surtout si la
description précise la restriction en question.

Il suffisait que la témoin exige une vraie accessibilité (un handicapé
n'est pas une marchandise) ou que la conseillère municipale rappelle que
seuls le personnel municipal (et peut être les élus) ont le droit
d'utiliser le monte-charge. Et encore, je ne sais si l'assurance ne peut
dire que le monte charge doit être utilisé uniquement avec des charges
et sans personne dedans.

Bref entre personnes de bonne foi, ça passe.

Mais la bonne foi est un concept que certaines assurances ont du mal à
comprendre.

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

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[osm . sanspourriel]

Le 07/12/2022 à 14:09, Daniel Garcia - dhe...@gmail.com a écrit :

Pardon, j'ai oublié un autre point sur lequel j'aimerais un avis :
Nominatim, ou un équivalent.
Actuellement, moi-même je finis par utiliser Google Maps quand j'ai besoin
de chercher un endroit par nom, car la recherche de OsmAnd est... moyenne,
pour ne pas en dire plus.


En cas d'accès internet, tu peux essayer
https://demo.addok.xyz/#12/48.8500/2.3500


Car ce point-là risque d'être pris par l'entreprise comme un de leurs
avantages, et je n'ai pas beaucoup d'arguments pour le contrer.


Il y a d'autres,

Plus généralement : https://wiki.openstreetmap.org/wiki/Geocoding

OSMand n'est pas parfait mais au moins il est libre et disponible hors
ligne. Tu peux aussi demander d'afficher les POI de type bibliothèque.

Dernièrement je peux enfin prendre la fibre. Je vais donc sur le site
d'un opérateur portant le nom d'une couleur.

Voici près de 4 ans, notamment à la demande de cet opérateur, le hameau
a été numéroté.

Mais pourtant l'entreprise en question utilise Grosse Merde, célèbre
pour ses cartes "gratuites" (ici : réserve de """ car il
en faut beaucoup) qui n'a toujours pas intégré ces données.

Du coup j'ai dû cliquer sur un fond satellitaire sur une carte GM pour
sélectionner une étiquette.

C'est ainsi que l'installateur et le contrôleur avaient par défaut juste
mon nom, le nom de mon hameau et celui de ma commune.

Et l'adresse pour la facture est affublée d'un "bâtiment N21" (bâtiment
qui n'existe pas, il y a un numéro 21 mais pas là) et d'un "étage 0".
Par contre GM a une localisation précise pour moi...

Bon le fond satellitaire est moins pourri que le fond "cartographique"
de GM car chez eux les maisons poussent sur les chemins...

Faire de l'accessibilité sur des fonds comme ça ?

Sont-ils sérieux ? Ou ton coin est-il bien décrit et ils ont une
alliance avec GM pour que les données puissent être réutilisées en dehors ?

Jean-Yvon


On Wed, Dec 7, 2022 at 2:04 PM Daniel Garcia  wrote:


Ne vous inquiétez pas ! J'ai demandé à l'entreprise, et ils m'ont confirmé
: "Nous utilisons effectivement le fond de carte de Google Maps sur
Streetco". 

Je sens qu'il va falloir beaucoup de pédagogie...

Pour l'instant, le seul point qui m'inquiète un peu comment l'expliquer et
mettre en oeuvre facilement, c'est la question des pentes : la ville se
situe des deux côtés d'une vallée, et il y a plusieurs passages qui
deviennent inaccessibles aux fauteuils à cause de cela. Je ne sais pas à
quel point Wheelmap & similaires arrivent à prendre ça en compte.

On Tue, Dec 6, 2022 at 3:29 PM Volker Schmidt  wrote:


Je pense que Mapillary pourrait être très utile dans ce contexte.
Je l'utilise pour documenter l'infrastructure pour vélo, y inclus les
barrières architectoniques sur les parcours. L'insertion des données je la
fais a temps différé à base des images Mapillary directement avec JOSM sur
le calculateur.
Une idée pourrait être de monter une caméra 360° en haut sur un fauteuil
roulant. ça te donnerait aussi la possibilité de faire un peu de
publicité,
autre que de stabiliser la caméra.

Volker
(Padoue, Italie)

Il giorno mar 6 dic 2022 alle ore 12:19 Marc_marc
ha
scritto:


Le 06.12.22 à 10:38, Daniel Garcia a écrit :

https://www.street-co.com/fr/

en passant leur certificat ssl n'est pas/plus valable pour cette url
c'esthttps://street-co.com/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-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] Bretelles d'autoroutes

[osm . sanspourriel]

Le 08/11/2022 à 19:10, Eric SIBERT - courr...@eric.sibert.fr a écrit :

Dans certains cas, il y a une zone sans marquage :

https://www.mapillary.com/app/?pKey=368476664619944


Ça c'est facile :

lane = 1

;-)


Disons que si on a une façon non équivoque de placer le way, derrière,
width:lanes devrait suffire. Déjà, j'aurais tendance à modifier ta
proposition en moins KISS textuellement parlant mais pouvant tenir
compte du fait que toutes les voies n'ont pas la même largeur:
- si nombre pair de voies, tracer le way sur la ligne médiane;
- si nombre impair de voies, tracer le way au milieu de la voie médiane.


+1, reste à voir ce qu'on entend par voie. J'ai tendance à penser voie
"", "none", "through".

Question subsidiaire : que les voies tous véhicules ? Si on exclut les
voies bus, ne faut-il pas exclure les voies 2+ (interdites aux personnes
seules) ?

Donc je mettrais l'ensemble des voies "permanentes" allant tout droit. KISS.

Question subsidiaire : allant exclusivement tout droit ? KISS : les deux
sont aussi simples mais je n'ai pas de réponse sûre.


Toujours à l'entrée de Grenoble, sur l'A48, la BAU se transforme en
voie de bus quand il y a embouteillage.


De facto ou affichage dynamique ? Info accessible par TMC ?

Mais je ne le compterais pas car pas une voie permanente (shoulder=right
avec des règles éventuelles pour en faire une voie bus mais je vois mal
le critère dans OSM - on a bien les route=detour
<https://wiki.openstreetmap.org/wiki/Tag:route%3Ddetour> mais là on ne
change guère le trajet pour les usagers du bus).

Espérons pour les urgences que les hélicoptères sont en nombre suffisant.

Pour les largeurs de voies des nationales, quelqu'un a jeté un œil sur
https://www.data.gouv.fr/fr/datasets/largeur-de-routes-sur-le-reseau-routier-national/
? Et surtout regardé si un import (projet du mois, Osmose...) serait
possible et intéressant ?

Je ne suis pas convaincu mais si d'autres trouvent ça bien, let's go.

La largeur est centimétrique (de 2,5 à 50 m) mais largeur de quoi ?
https://www.data.gouv.fr/fr/datasets/largeur-de-routes-sur-le-reseau-routier-national/#discussion-62559acd28fdada464c15297
il va falloir regarder soi-même ! Et si le producteur ne répond pas
c'est peut-être que suivant le concessionnaire la réponse varie.

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

Re: [OSM-talk-fr] Bretelles d'autoroutes

[osm . sanspourriel]

Attention ici la modélisation n'est pas correctement, ce ne sont pas des
chaussées séparées :

https://www.openstreetmap.org/#map=18/45.20626/5.79256

Ici on a déjà une solution pour le marquage au sol : change = no.

https://wiki.openstreetmap.org/wiki/Key:change

Mieux que overtake = no

https://wiki.openstreetmap.org/wiki/Key:overtaking

Jean-Yvon

Le 08/11/2022 à 19:25, Eric SIBERT - courr...@eric.sibert.fr a écrit :

https://www.mapillary.com/app/?pKey=2822941664665018

Si on est sur la file de droite et qu'on veut aller à gauche, on n'a
pas le droit même si on est loin de la séparation des deux branches et
de la ligne continue qui la précède.

Il va falloir modéliser le marquage au sol. Un peu de lecture sur la
signalisation routière horizontale :

https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale_en_France


Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[osm . sanspourriel]

Le 07/11/2022 à 14:08, Eric SIBERT - courr...@eric.sibert.fr a écrit :


Je continue à mettre des source:maxspeed=FR:rural sur ces machins là
mais en posant la question du sens.


Pour ma part je ne mets du rural que sur du 80 km/h. Ou plutôt je
laisse. Car les 90 sont toujours explicites. Maintenant les 80 souvent
aussi !

https://www.mapillary.com/app/?pKey=175706105115780

Là on est d'accord : fin de 90 explicite (source:maxspeed=sign) sans
panneau de limitation. On est en Ardèche, sur une départementale.

On passe donc à... 90 km/h.

source:maxspeed
=FR-07:rural
???

Tu coupes

https://www.openstreetmap.org/way/250800754#map=16/44.5834/4.4613

en deux en virant la scorie oneway
=no ?^^

Je ne sais qui a fumé la moquette. Ils avaient un panneau qui trainait ?

Oui ajouter les clés style mapillary=482658663647816 permettent de
suivre plus facilement les modifications.

Si, 1 000 objets potentiellement modifiés c'est une édition de masse.
C'est bien d'en parler et encore mieux de l'expliciter dans le titre.

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[osm . sanspourriel]

Seulement si la source de la vitesse est rural.

Sinon ça peut être une limite explicite (j'en doute)... et comme à peu
près partout des 80 ont été placés explicitement là où en théorie ça
pouvait rester implicite.

des notes/fixme quand le statut actuel est inconnu ?

Car changer la vitesse et pas dans le sens de la sécurité me semble douteux.

Jean-Yvon

Le 06/11/2022 à 23:56, Eric SIBERT - courr...@eric.sibert.fr a écrit :

Le conseil départemental de l'Ardèche a décidé de repasser la vitesse
par défaut à 90 km/h sur toutes les départementales [1]. Et, de
passage, j'ai constaté que la signalisation avait effectivement été
adaptée y compris sur les petites routes (mais pas sur la N102 qui est
une nationale). Je fais une remplacement systématique à l'échelle du
département de toutes les limites sur départementale à 80 km/h en 90
km/h?

[1] :
https://www.lemonde.fr/societe/article/2022/08/11/retour-aux-90-km-h-en-ardeche-on-ne-parle-pas-en-kilometres-mais-en-temps_6137726_3224.html

Bonne soirée

Eric

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)

[osm . sanspourriel]

J'allais dire "Hélas les turn:lanes sont inapplicables en l'état car il
n'y a pas de signalisation horizontale dans ce cas précis."

En fait la version anglaise insiste sur le fait que ce soit signalé mais
in fine n'indique pas que le marquage au sol.

https://www.mapillary.com/app/?z=17=48.701982=2.595105=172038741799101=photo


montre bien que

turn:lanes=none|none|slight_right

est correct.

J'ai mis à jour en conséquence, les flèches sont bien apparues sur
https://osm.janmichel.eu/lanes/render.pl?relref=N%20104=1=be

(oui il n'y a pas de style fr mais le style be est assez proche).

J'ai aussi placé la sortie 21 au niveau du bout du pont. C'est
discutable, j'ai suivi la recommandation de "dernier moment pour changer
de file en sécurité" et pour éviter le point d'inflexion sur le tracé
filaire. Oui le second point est un peu pour le rendu mais n'est pas
tordre la réalité non plus.

placement=transition sert à indiquer la partie qui est ici entre 2 et 3
voies. Ce n'est pas strictement nécessaire mais permet de faire du
travail propre. Sinon on ne distingue pas entre 2 à 3 voies et 3 voies.

Avant : inutile, c'est le milieu de la bande de roulement.Marc : tu
parles du milieu de chaussée, en fait c'est de la bande de roulement -
il doit y avoir un terme plus exact -, on ne tient pas compte des bandes
d'arrêt d'urgence shoulder=right).

Après placement = right_of:1. Certes avec le
turn:lanes=none|none|slight_right tu peux le déduire.

Jean-Yvon


Le 04/11/2022 à 10:50, Georges via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Bonjour,
j'approuve totalement cette façon de faire. Elle rend d'autre part inutile la 
clé placement=* qui est très peu utilisée et inutile, car elle ne résoud 
absolument rien pour une voie de sortie dont la largeur augmente régulièrement. 
Les turn:lanes suffisent.

4 nov. 2022 00:28:36 Marc Mongenet:


Pour ma part je trace les traits comme dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
plutôt que
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_2.jpeg
car:
- c'est plus simple
- l'autoroute ne tourne pas
- je trouve que le turn:lanes=none|none|slight_right est suffisamment
explicite

___
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] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)

[osm . sanspourriel]

Le 03/11/2022 à 21:34, Marc Mongenet - marc.monge...@gmail.com a écrit :


Le jeu. 3 nov. 2022 à 20:21,  a écrit :

La vitesse de la voie
https://www.openstreetmap.org/way/623900993#map=19/48.70338/2.59662  est

J'ai une question sans rapport immédiat avec la vitesse, mais avec la façon
bizarre dont la voie de sortie est mappée.

Elle est... classiquement mal mappée.

Pourquoi dans les cas d'entrée/sortie, et uniquement dans ces cas à ma
connaissance, voit-on souvent un virage en S être inventé à la jonction
avec la voie principale?

C'est un souci dû au nombre de voies. Ceci dit il existe réellement
(mais nettement moins accentué : tu vires légèrement à droite pour te
placer dans la nouvelle voie puis aussi légèrement à gauche pour revenir
parallèle à la voie principale).

Ça crée des virages qui n'existent pas et donne l'impression erronée qu'il
faut brusquement tourner à droite puis à gauche pour sortir (ou à gauche
puis à droite en arrivant sur la route principale).

C'est toi qui vois, certains ont eu des problèmes^^.

L'observation de l'orthophoto donne l'impression que la ligne continue
blanche entre la voie principale et l'entrée/sortie est considérée comme
une séparation de voie. Et dès la fin de la ligne continue, un angle plus
ou moins arbitraire (disons entre 30° et 60°) est imprimé pour rejoindre la
voie principale. Je devine d'ailleurs que le mappeur ne met pas un angle de
90° car il se rend bien compte qu'il est en train de faire qqch d'inélégant.

Oui

La règle de mapper le centre de la chaussée, et pas les lignes blanches, me
semble pourtant aussi vieille que OSM.

Oui, enfin non (voir ci-dessous)

Il me semble aussi que la règle des jonctions de routes est très ancienne :
on conserve l'angle à l'intersection pour poursuivre tout droit les lignes
représentant le centre des routes.

Oui

Bref, il me semble que les règles disent depuis toujours qu'il faut mapper
comme dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg

Non (voir ci-dessous)

Dans la même région, on voit d'ailleurs sur
https://www.openstreetmap.org/#map=19/48.67452/2.54959  que l'intersection
entre la rue de Quincy et l'avenue de Jarcy est mappée selon les règles.

Rien à voir : il n'y a pas de nombre de voies différents.

Enfin, je suppose qu'avec la généralisation des tags lanes et turn:lanes
(et peut-être placement dans le futur) cela va être progressivement
corrigé, et les lignes blanches ne seront plus utilisées comme
pseudo-séparations de voies.

Les lignes blanches sont des vraies séparations de voies. Mais on est
plus d'accord que ce que ne semble indiquer cette phrase.

Marc Mongenet


Ce qui est important c'est le placement=*.

Or :

- c'est une proposition (qui date de 2012, inchangée par l'auteur depuis
plus de 7 ans !)

- tu donnes une règle (les lignes représentant le centre des routes)
sauf que tu donnes l'image du haut et non celle du bas qui précise "If
one tries to draw the OSM-way as often as possible in the middle of the
road".

https://wiki.openstreetmap.org/wiki/Proposed_features/placement#Simple_transition_from_three_to_two_lanes


Donc d'accord avec le fait que c'est mal fait dans la bretelle indiquée
par contre pour la solution je suis dubitatif.

Est-ce que la sortie 21 devrait être à la hauteur de la séparation de la
voie avec "placement=transition" en amont sur la partie entre  2 et 3
voies ?

Où est le "milieu de la voie" : pour la voie qui continue et a deux
voies c'est le trait pointillé centre de ces deux voies.

Donc pourquoi pas mais il faudrait un exemple clair :

- ou place-t-on le motorway_junction (sortie) : où la voie commence à se
diviser ? Quand elle se divise ? ÀMHA quand elle commence. Ainsi dans ce
cas précis la voie principale reste à deux voies.
- et placement=transition sur la partie entre les deux (implicitement on
passe de 2 à 3 voies).

Avoir un simple trait quasi parallèle pour aller de l'endroit où il y a
2 voies à l'endroit ou il y en a 2 + 1 serait graphiquement très proche
et placement=transition et serait suffisant.

D'autres avis plus éclairés ?

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[osm . sanspourriel]

Stéphane, pour la voie que tu as mise à jour ce serait plutôt :

lanes=2

turn:lanes=through|through;slight_right

selon le wiki. Ou plutôt none|none car il n'y a pas de marquage au sol.

Il faudrait utiliser
https://wiki.openstreetmap.org/wiki/Relation:connectivity :-(.

Et donc pas de place pour 110|110|90.

110|110;90 serait incompréhensible.


https://osm.mueschelsoft.de/lanes/render.pl?wayid=444238531=1=FR



Le 03/11/2022 à 20:17, Jean-Yvon Landrac a écrit :



Le 03/11/2022 à 19:24, Christian Perrier -
christian.perrier.1...@gmail.com a écrit :

Le jeu. 3 nov. 2022 à 19:13, didier  a écrit :


Bonsoir,

Ce que je recherche, ce n'est pas la vitesse de la voie de droite.
Cfwww.mapillary.com/app/?pKey=172038741799101

Dans ce cas, 110 tout droit et 90 pour ceux qui vont emprunter la
sortie.




Bin, pour moi, pile à l'endroit où est la photo, y'a rien à tagguer. C'est
la voie de sortie qui doit être tagguée avec maxspeed=90 à partir du moment
où elle commence en tant que segment séparé. Selon le Code de la Route, la
vitesse n'est pas, dans ce cas, limitée à 90 à partir du panneau, mais à
partir du moment où le véhicule est sur la voie de sortie annoncée par le
panneau. En d'autres termes, le panneau est, de facto, est panneau
d'annonce.


+1

La vitesse de la voie
https://www.openstreetmap.org/way/623900993#map=19/48.70338/2.59662
est limitée à 50, panneau
https://www.openstreetmap.org/node/6175718019#
map=19/48.70338/2.59662
.
Avant la voie de droite est à 70
https://www.openstreetmap.org/way/32929129#map=19/48.70338/2.59662 et
https://www.openstreetmap.org/way/444238530#map=19/48.70275/2.59612


https://www.mapillary.com/app/?z=19=48.70338=2.59662=523955995281678

(correctement taguée 110|110|70).

Le 90 est marqué ici :
https://www.openstreetmap.org/way/444238531#map=19/48.70275/2.59612

110|110|90 mais ça me semble discutable (hein Stéphane ;-) ?).

https://www.openstreetmap.org/way/444238530#map=19/48.70338/2.59662


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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[osm . sanspourriel]

Le 03/11/2022 à 19:24, Christian Perrier -
christian.perrier.1...@gmail.com a écrit :

Le jeu. 3 nov. 2022 à 19:13, didier  a écrit :


Bonsoir,

Ce que je recherche, ce n'est pas la vitesse de la voie de droite.
Cfwww.mapillary.com/app/?pKey=172038741799101

Dans ce cas, 110 tout droit et 90 pour ceux qui vont emprunter la
sortie.




Bin, pour moi, pile à l'endroit où est la photo, y'a rien à tagguer. C'est
la voie de sortie qui doit être tagguée avec maxspeed=90 à partir du moment
où elle commence en tant que segment séparé. Selon le Code de la Route, la
vitesse n'est pas, dans ce cas, limitée à 90 à partir du panneau, mais à
partir du moment où le véhicule est sur la voie de sortie annoncée par le
panneau. En d'autres termes, le panneau est, de facto, est panneau
d'annonce.


+1

La vitesse de la voie
https://www.openstreetmap.org/way/623900993#map=19/48.70338/2.59662 est
limitée à 50, panneau https://www.openstreetmap.org/node/6175718019#
map=19/48.70338/2.59662
.
Avant la voie de droite est à 70
https://www.openstreetmap.org/way/32929129#map=19/48.70338/2.59662 et
https://www.openstreetmap.org/way/444238530#map=19/48.70275/2.59612


https://www.mapillary.com/app/?z=19=48.70338=2.59662=523955995281678

(correctement taguée 110|110|70).

Le 90 est marqué ici :
https://www.openstreetmap.org/way/444238531#map=19/48.70275/2.59612

110|110|90 mais ça me semble discutable (hein Stéphane ;-) ?).

https://www.openstreetmap.org/way/444238530#map=19/48.70338/2.59662
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[osm . sanspourriel]

Exact mais comme dit précédemment, il vaut mieux avec un moteur de
recherche qui permettre de trouver une place PMR à proximité d'un lieu
ou un routage PMR.

Et comme la personne concernée sait où elle a pu garer sa voiture c'est
"seulement" trouver une place à proximité de la destination.

Place PMR près de XXX (disabled parking space near XXX)? Sarah nous dira
peut-être ce qu'elle pense de la facilité et de l'intérêt d'avoir ça au
niveau de Nominatim.

Après un zoom suffisant permet de visualiser la place.

Un rendu spécialisé et un moteur de routage spécialisé serait un plus.

Car les places "ordinaires" sont sans doute sans intérêt (je ne connais
pas la règle, peut-être que si les places PMR sont toutes occupées, les
forces dites de l'ordre auront une tolérance si un handicapé se gare sur
deux places ordinaires).

Un routage spécialisé car si entre la place et le lieu de destination il
faut faire un grand détour parce que l'entrée la plus proche n'est pas
accessible aux handicapés...

N. B. : http://www.handimap.org/ est un exemple de carte spécialisée
(données non uniquement OpenStreetMap). Cliquez sur Rennes plutôt que
sur Lorient... Oui le copyright OpenStreetMap est très limite !

Jean-Yvon

Le 23/10/2022 à 22:00, Denis Bigorgne - denis.bigor...@wanadoo.fr a écrit :

  Rendu PMR effectif avec un  fort zoom, inexploitable pour *trouver *une
place, malheureusement !



Le dim. 23 oct. 2022 à 16:58, Zimmy ZIMMERMANN
a écrit :


Le rendu français permet cela

https://tile.openstreetmap.fr/?zoom=20=44.13517=4.81071=BFF

Le dim. 23 oct. 2022 à 14:40, Hélène PETIT  a écrit :


C'est dur à dire, mais je ne sais toujours pas comment les gens peuvent
consulter simplement la carte OpenStreetMap pour trouver une place PMR.
Par exemple il y en a une, cartographiée correctement, sur la place
Henri de Gorssse, à Toulouse (c'est le petit espace vert à côté de la
Dalbade) mais sur le rendu standard, on la voit pas ;
Y a-t-il un rendu spécifique ?
Merci !

Le 20/10/2022 à 12:08, Daniel Garcia a écrit :

Bonjour,

Le conseil municipal de ma ville souhaite effectuer des actions liées

au

handicap, et une des actions mentionnées a été de faire une carte de
l'accessibilité physique de la ville.

Évidemment, j'ai pensé à wheelmap.org, et à utiliser OpenStreetMap

comme

source d'information.

Il y aura une réunion du conseil municipal et je voudrais me préparer

pour

proposer l'utilisation d'OSM/Wheelmap, qui me semblent une solution
efficace et maintenable à bas coût.

Auriez-vous des indications d'autres villes ayant déjà fait cela, ou

des

présentations/éléments de communication pour m'aider à leur présenter

les

bénéfices d'OSM dans ce cadre ?

Aussi, des éléments techniques seraient également bienvenus, comme par
exemple des suggestions de démarches pratiques. Voici quelques

questions

que je me pose déjà :

- Comment faire une "cartoparty" pour l'accessibilité ? Est-ce qu'avoir

un

fauteuil roulant pour monter dessus et "tester" l'accessibilité de

certains

établissements serait utile ?
- Faut-il prendre des photos de chaque entrée de commerce, comme

suggéré

par Wheelmap ?
- Est-ce Street Complete la meilleure application mobile pour compléter

les

informations d'accessibilité ?

Ensuite, une fois que l'information est présente dans OSM, comment la
récupérer pour la rendre utilisable par le grand public ? Faut-il faire

une

carte simplifiée de la ville, et si oui, comment ? Y a-t-il des
personnes/entreprises à contacter ? Je ne sais pas s'il y aura un

budget

alloué pour cela (c'est une démarche "citoyenne"), mais au cas où,

avoir

une idée des coûts et possibilités est toujours utile.

Au cas où, voici quelques informations complémentaires :
- Apparemment, les conseillers et élus ne connaissent pas

OpenStreetMap,

donc il faudra sans doute le présenter d'abord ;
- La plupart des commerces de la ville (15k habitants) a déjà été

mappée,

mais il manque le tag "wheelchair" un peu partout ;
- La ville est assez dénivelée. L'élu en charge du handicap à la

mairie a

mentionné un souci concret qui lui est arrivé cette année : un chemin
piéton qui était trop pentu pour les fauteuils roulants, et qui

manquait

de

panneaux pour indiquer le dénivelé. À part le tag 'incline', je ne sais

pas

s'il y a des outils dans OSM pour cela (il me semble que les courbes de
niveau ne soient pas assez précises pour ces informations). Et si on

veut

ajouter un 'incline=X%', est-ce qu'un mappeur peut le mesurer lui-même,

ou

il se limite à copier l'information présente sur des panneaux ?

Merci,
Daniel
___
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] Accessibilité d'une ville : recommandations

[Cyrille37 OSM]

Bonjour



Le 20.10.22 à 12:08, Daniel Garcia a écrit :
- Comment faire une "cartoparty" pour l'accessibilité ? Est-ce 
qu'avoir un
fauteuil roulant pour monter dessus et "tester" l'accessibilité de 
certains

établissements serait utile ?


Il y quelques années, à Chemillé en Anjou, nous avions fait promenade 
avec fauteuil roulant avec un gros Tux en passager.


https://www.mapillary.com/app/?lat=47.21933889=-0.7274916667=17=5646890518661954=0.5774323259473103=0.5792719984703913=0.7853042479908152=photo

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

Re: [OSM-talk-fr] taginfo source:maxspeed

[osm . sanspourriel]

Comme Marc aime bien les éditions automatiques (à bon escient), je pense
qu'on pourrait lui proposer des éditions automatiques, exemple :

source:maxspeed=mapillary : on récupère avec Overpass par exemples les
objets l'ayant et on crée des changeset :

suppression de source:maxspeed=mapillary au niveau des objets, report au
niveau du changeset

(plus court : déport des méta données source:maxspeed=mapillary au
niveau du changeset).

Et on précise dans le wiki qu'en France il ne faut pas l'utiliser ainsi.

> maxspeed:type

Je pense que tout créateur de clé comportant "type" devrait avoir une
pénalité ;-). maxspeed:origin aurait été plus clair.

Le 15/10/2022 à 12:09, Marc_marc - marc_m...@mailo.com a écrit :

maxspeed:type est une donnée : il y a un panneau sur le troncon
ou un panneau de zone ou on est dans une aglo ou hors aglo
source:maxspeed est soit une donnée (cfr le cas précédent)



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

Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6

[osm . sanspourriel]

Le 12/10/2022 à 23:18, Marc_marc - marc_m...@mailo.com a écrit :


Bonjour,

Le 12.10.22 à 22:55, Rene Chalon a écrit :

- le tag "capital" pourrait être utilisé

c'est l'admin_center dans l'autre sens, jamais compris l'intérêt de
dupliquer.


Un coup de mou Marc ?

capital c'est non pas l'inverse, mais le max des niveaux de relation
ayant ce nœud comme admin_centre. Oui en théorie on peut reconstituer.


- il y avait aussi une proposition d'ajouter le tag "rank"

presque la même duplication, avec éventuelement des nuances en plus
mais totalement subjectif : sur base de quoi ? population ? importance
économique ? etc


Si c'est fourni par d'autres dont c'est le boulot, pourquoi pas. Ici
personne ne conteste que si on ne peut afficher Lyon et Villeurbanne,
c'est Lyon qu'il faut afficher et capital suffit.

Le niveau capital a permis de résoudre le conflit Vannes - Saint-Avé, un
des algorithmes étant tout chose égales par ailleurs d'afficher du nord
ouest au sud est s'il y a de la place.

Jean-Yvon



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

Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6

[osm . sanspourriel]

Bonjour,

Lyon s’est pris le tapis dans le mille-feuille administratif ?

avec un lien c’est plus lisible :

https://www.openstreetmap.org/#map=6/45.758/4.835

> Pourquoi ne pas simplement supprimer le label?

Car que justement ça sert à placer le texte à un endroit pas trop con.

Et ici pour éviter que Lyon et ARA ne soient affichés au même endroit.

Sans doute faut-il décaler plus le texte vers le sud-ouest (autant
laisser les locaux juger où le placer).

https://www.openstreetmap.org/node/3925295239.

CyclOSM : niveau 10 aussi

https://www.openstreetmap.org/relation/120989#map=10/45.7718/4.8903=Y

Sans doute qu'ils exigent de de vide entre deux textes et sont trop
souples quant au positionnement.

Jean-Yvon

Le 12/10/2022 à 21:47, Marc Mongenet - marc.monge...@gmail.com a écrit :

Bonjour,

J'ai remarqué que le rendu par défaut de https://www.openstreetmap.org au
niveau de zoom 6 affichait "Villeurbanne" au lieu de "Lyon". Je suppose que
c'est dû au fait que la place de "Lyon" est prise par
"Auvergne-Rhône-Alpes". Est-il possible de déplacer le texte
"Auvergne-Rhône-Alpes"? J'ai l'impression que c'est positionné par un
label. Pourquoi ne pas simplement supprimer le label?

Toujours à propos de "Villeurbanne", le rendu CyclOSM place "Villeurbanne"
un vingtaine de kilomètres au sud de "Lyon" en zoom 8. Mais je suppose
qu'il s'agit là d'un bug dans l'algorithme de placement, n'est-ce pas?

Marc Mongenet
___
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] nommage dans un campus

[osm . sanspourriel]

Le 10/10/2022 à 21:25, Ralf Treinen - trei...@fdn.fr a écrit :

[...]

- soit sur name et ref. Plus proche de la réalité mais alors il serait

peut-être plutôt local_ref ?

-Ralf.


Je ne vois pas l'intérêt de local_ref tant qu'il n'y a pas conflit avec ref.

Le 09/10/2022 à 00:19, Christian Rogel via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Pourquoi ne référer addr:xxx uniquement à un service postal extérieur ? Dans un 
groupe de bâtiments numérotés, il y a, presque à chaque fois un service de 
vaguemestre, qui utilise donc cet adressage.
Et s’il n’y a pas, ça ne change pas dans le principe. D’ailleurs, les adresses 
officielles ont été établies, en premier lieu, pour la perception des impôts 
et, maintenant pour la fibre optique.

Christian R.


Ce n'est pas que je sois contre, mais a priori on parle d'adresses
postales et ce n'est pas une adresse postale.

Si on veut étendre le modèle il faut pouvoir distinguer l'adressage
public (et l'adresse postale est publique) de l'adressage interne.

https://fr.wikipedia.org/wiki/Adresse_postale#France

ref:FR:FANTOIR:none=yes

(Vincent ou Deuzeffe seront sans doute plus inspiré) : bof, c'est du
franco-français.

Ou : addr:public=no, pour signifier que les valeurs n'ont de sens que
pour cette associatedStreet.

Peut-être addr:visibility=intern histoire d'étendre plus facilement
(avec postal/public comme valeur par défaut). J'avais pensé à quelque
chose de plus parlant style campus mais je crains que pour des hôpitaux
on puisse avoir des adressages similaires.

Jean-Yvon



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

Re: [OSM-talk-fr] Trottoir : voie indépendante ou caractéristique de la route ?

[osm . sanspourriel]

Bonjour,

Étant athée, la bible... :-).

Aux États-Unis, dans les zones résidentielles, il est fréquent que le
trottoir soit séparé de la chaussée principale par une zone herbue,
auquel cas un chemin séparé a un intérêt, indiquant où on peut traverser
sans marcher sur l'herbe..

En France par contre...

Sauf dans certains cas précis, par exemple quand il existe un tracé
podotactile.

Pire que sans intérêt quand sur nombre de rendu il n'existe pas de
distinction entre un chemin piéton et un trottoir : du coup on
défavorise les tracés les plus agréables (chemin en site propre).

Et du coup pour retrouver la continuité du réseau on fabrique des
artefacts comme ici :

https://www.openstreetmap.org/way/1046073714 (alors que le passage
piéton manque et que la personne se trouve donc routée en plein milieu
de la route et au sud il y a un trottoir des deux côtés de la route).

Et pourquoi pas un tracé propre pour le caniveau, la bordure de
trottoir... ?

Donc pourquoi pas mais seulement quand ce n'est pas un vulgaire
trottoir. Sinon passer en modèle surfacique.

Mais oui si dans le coin les gens font comme ça...

Jean-Yvon

Le 09/10/2022 à 21:17, Jacques Lavignotte - jacq...@lavignotte.org a écrit :



Le 09/10/2022 à 19:49, Nicolas d a écrit :

Bonjour à tous,


Bonsoir,


Est-ce :
- une possibilité,
- la bonne manière,
- une erreur ?


La Bible :

https://wiki.openstreetmap.org/wiki/FR:Trottoirs


Nicolas


Jacques




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

[OSM-talk-fr] nommage dans un campus

[osm . sanspourriel]

Bonjour,

ça a été déjà discuté ici de mémoire mais impossible de mettre la main
dessus.

Dans un campus (universitaire, recherche...) il arrive que les bâtiments
aient un nom et un numéro.

Ce numéro n'est pas un numéro de rue car l'adresse est globale ou
certains labos vont avoir des CEDEX (par exemple).

Certains utilisent addr:housename alors que name me semble indiqué pour
le nom du bâtiment. En effet ce nom ne sert pas à la poste pour
distribuer le courrier.

Et de la même façon un addr:housenumber pour afficher le numéro.

Pour la même raison ref me semble préférable.

Je vois deux possibilités mais vous avez sans doute mieux :

- soit on part sur l'associatedStreet en précisant qu'il n'y a pas de
code Fantoir et donc name et addr:housenumber. Affichage des noms et
numéros sur la carte (on ne tague pas pour le rendu mais si en tordant
peu le système ça marche, c'est peut-être acceptable.

- soit sur name et ref. Plus proche de la réalité mais alors il serait
bon de demander aux moteurs de rendus d'ajouter le rendu de ref (en fait
suivant les rendus, le nom ou la ref s'affiche : la carte humanitaire
affiche les ref).

Exemple sur le campus du centre de l'Ifremer à Plouzané :

Plan : https://www.euro-argo.eu/content/download/116279/file/Ifremer-map.pdf

Ci-dessous le ref n'est pas sur le bâtiment mais à côté. Certaines fois
il est dessus (ex : https://www.openstreetmap.org/way/253775675).

https://www.openstreetmap.org/way/42622630/history


   Après :

building
  yes

name 
Jean-François de La Pérouse

*Avant :*

building
  yes



   et

https://www.openstreetmap.org/node/291974524/history


   Après :

name  Dyneco
office 
research

ref    514


   *Avant :*

addr:housename
   Dvneco
addr:housenumber

514



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

Re: [OSM-talk-fr] Population des viles

[osm . sanspourriel]

Plus précisément on avait viré toutes les populations sur les nœuds car
ça ne veut rien dire.

Prenons Rennes, la population sur le nœud, serait-ce la population de la
ville ? du département ? De la région ?

Paris celle de la France ? Métropolitaine ?

Jean-Yvon

Le 06/10/2022 à 16:23, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

Le 06.10.22 à 15:38, Arnaud Champollion a écrit :

Est-ce que ça vaudrait le coup de répliquer massivement cette donnée
de l'un à l'autre, tout au moins pour les cas où elle est absente
dans l'un des deux ?


uniquement si la ville a la meme population que la commune, cad que tu
n'as pas le moindre batiment habité hors de la ville, pas d'hameau,
pas de ferme hors de la ville, etc

quelle source vas-tu utilisé pour cela ?

Cordialement,
Marc



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




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

Re: [OSM-talk-fr] Population des villes - cq94 ?

[Cyrille37 OSM]

Bonjour

Il me semble qu'il y a une mise à jour de "population" sur la relation, 
effectuée par cq94 à chaque nouvelle publication de l'INSEE.


@cq94 tu confirmes ?

Cyrille.

On 06/10/2022 15:38, Arnaud Champollion wrote:

Bonjour,

On trouve la clé "population" à la fois dans les place_town (noeuds 
"centraux") et dans les boundary_administrative (contours de commune).


Parfois la clé est absente de l'un des deux, comme ici :

https://www.openstreetmap.org/node/26691545
https://www.openstreetmap.org/relation/365373

Je m'en suis rendu compte en éditant une carte de mon département ; le 
filtre par population lnagissait pas pareil selon que je l’appliquais 
sur le point central ou la surface communale.


Est-ce que ça vaudrait le coup de répliquer massivement cette donnée 
de l'un à l'autre, tout au moins pour les cas où elle est absente dans 
l'un des deux ?


Merci de vos avis,

Bonne journée,

Arnaud


___
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] JOSM version 18565 traduction du Journal des modifications

[Cyrille37 OSM]

Bonjour
et encore
et encore
merci !

Pour ce chouette logiciel <3

On 04/10/2022 13:19, leni wrote:

Bonjour

Mise à jour de JOSM

Voici la traduction du Journal des modifications correspondant à la 
version 18565 
https://josm.openstreetmap.de/wiki/Fr%3AChangelog#stable-release-22.09 
(le lien vers l’original anglais est en haut à droite)


cordialement

leni

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

Re: [OSM-talk-fr] Osmose : erreur dans certains pointeurs

[osm . sanspourriel]

Salut, ça c'est quand le JSON généré est vide, typiquement quand
l'erreur a disparu.

Erreur classique de JSON parse sans vérification si le retour est vide
avant d'analyser.

Jean-Yvon

Le 26/09/2022 à 10:12, FR via Talk-fr - talk-fr@openstreetmap.org a écrit :

Bonjour

Depuis quelque jours il y ce message dans certains pointeurs d'Osmose,
pas tous :
"JSON.parse: unexpected character at line 1 column 1 of the JSON data"

Françoise


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




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

[OSM-talk-fr] HTH

[osm . sanspourriel]

/hope this helps
/.

En espérant que ça te sera utile (tu veux dire les vieux qui n'ont pas
accès à internet ;-) - sérieusement autant éviter les acronymes surtout
d'origine étrangère).

Jean-Yvon

Le 20/09/2022 à 09:40, leni - lenny.li...@orange.fr a écrit :


HTH

tu peux traduire aux vieux qui ne savent pas "HTH" ?



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

Re: [OSM-talk-fr] Pifomètre : Dans OSM et inconnu de FANTOIR - que je ne trouve pas dans OSM

[osm . sanspourriel]

https://bano.openstreetmap.fr/pifometre/#insee=31079=1 trouve :

310790112C  1998-02-25  RUE DE LA VOIE FERREE   Rue de la Voie Ferrée
ORG  FR
BANO

JOSMID

P2




Anomalies



Il ne propose rien, mais tu as déjà fait le boulot :

https://www.openstreetmap.org/relation/7455487

c'est comme pour l'Impasse des Vergers
.

Jean-Yvon

Le 19/09/2022 à 16:48, leni - lenny.li...@orange.fr a écrit :

Bonjour

Est-ce que Pifomètre utilise les alt-name pour placer des voies dans
cette liste ?

J'ai la commune de Bouloc (31079) dans laquelle je trouve "Rue Ferrée"
alors que je ne trouve cette valeur que dans le alt-name de la "Rue de
la Voie Ferrée" https://www.openstreetmap.org/way/35399575 ou je n'ai
pas su chercher !!!

cordialement

leni


___
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] bano fantoir

[osm . sanspourriel]

Bonjour,

ça ne peut pas faire de mal mais tu peux encore te faire rattraper par
la patrouille car toutes les lettres ne sont pas autorisées :

https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_fantoir.py

Et oui :

https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR

la validité dépend aussi de la nature de l'objet portant le code.

Et pour la dernière lettre, ni I, O ou Q et surtout c'est une clé de
contrôle : c'est ça qui sert à lutter contre les fautes de frappe (je
n'ai pas vu l'algo sur
https://www.collectivites-locales.gouv.fr/files/Comp%C3%A9tences/5.%20am%C3%A9nagement%20de%20mon%20espace/1-cadastre/La%20description%20du%20fichier%20FANTOIR.pdf
mais je n'ai pas cherché non plus).

Jean-Yvon

Le 17/09/2022 à 11:26, didier - didier2...@free.fr a écrit :


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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[osm . sanspourriel]

Le 08/09/2022 à 17:17, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

Le 07.09.22 à 21:02, Marc Mongenet a écrit :

type=site qui représente et fait exactement
ce qu'il faut.


https://wiki.openstreetmap.org/wiki/Relation:site#Rationale
pour les cas oü l'objet ne peux pas être représenté
par une géométrie ou par des multipolygone :)
ex : les noeuds d'un parc éolien

Cordialement,
Marc


1) taginfo dit qu'il y a autant de membres qui sont des nœuds que des
chemins. Donc le wiki ne reflète pas l'usage.
2) taguer chaque arbre, ça va prendre du temps^^.

Le 08/09/2022 à 18:28, Marc_marc - marc_m...@mailo.com a écrit :

cela me fait penser qu'il y a aussi la relation group


Absent du wiki.

https://wiki.openstreetmap.org/wiki/Types_of_relation

Du coup côté usage et représentation, j'ai des doutes.

Conceptuellement la différence avec site serait laquelle ? Selon
taginfos, les relations type=group comportent deux fois plus de nœuds
que de chemins !

Le 08/09/2022 à 17:01, Marc_marc - marc_m...@mailo.com a écrit :

pourquoi ne pas encoder cette nuance dans son propre tag ?

Parce que personne c'est capable de définir ce qu'est une forêt
exploitée d'une autre.

C'est facile d'ajouter une clé oui/non mais si les gens ne sont pas
d'accord quand mettre oui et quand mettre non...

Jean-Yvon



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

Re: [OSM-talk-fr] Collecte des points de recyclables à partir de l'API Nice-Cote-d'Azur

[osm . sanspourriel]

Le 06/09/2022 à 12:05, Erwan K - e.kergr...@gmail.com a écrit :


Merci pour tous vos retours, je réponds aux 2 emails en même temps car je
n'ai reçu que le résumé groupé (aucun mail séparé):


Tu dois être en mode digest, tu peux changer ça via l'interface de la liste.


Ah et je viens de voir BDOrtho dans la liste, c'est nouveau comme fond ?
https://www.openstreetmap.org/node/9963915006/history#map=20/44.20876/6.97873

Si quelques années c'est récent, oui ;-)

Concernant la date, à moins que je loupe quelque chose, j'ai bien mis le
source:date en 2020


Autant pour moi, tu as raison, il était temps que j'aille me coucher !

Le 06/09/2022 à 12:05, Erwan K - e.kergr...@gmail.com a écrit :

Juste petite question, je ne comprends pas le fait que la conversion
opendata -> tag osm mériterait d'être faite à un seul endroit, Ca veut dire
quoi ?


Ça veut dire que tu as réfléchi par exemple à traduire SEMI-ENTERRE par
location=underground.

Que si on veut faire une analyse avec Osmose on devra définir encore
cette même conversion.

Si on a un endroit unique où pour un type de fichier on a cette
conversion, c'est plus simple.

Notamment pour AERIEN, location=surface semble adapté.

Autant ne pas avoir à le définir à 2, 3, 4 endroits différents.

Là il est déjà dans le wiki (en "clair") et dans github. Et Osmose
redéfinirait encore.

Marc, tu as réfléchi à un endroit ? format ? Déjà les deux sont en Python.

Erwan je vois que tu enlèves les signes diacritiques à la main. Il n'y a
pas de fonction en Python pour le faire ?

Jean-Yvon



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

Re: [OSM-talk-fr] Collecte des points de recyclables à partir de l'API Nice-Cote-d'Azur

[osm . sanspourriel]

Bonjour,

oui c'est le bon endroit pour commencer à en discuter.

il manque plusieurs points fondamentaux :

- qualité de la donnée en entrée, en particulier de la position
géographique. A minima prendre des échantillons et regarder.

- que faire si un point existe déjà dans OSM mais avec d'autres attributs ?

- quelle fréquence de mise-à-jour de la source (j'ai regardé :
occasionnelle).

Ce que je comprends c'est que tu prépares un fichier et qu'on importe à
la main dans JOSM, ça me semble raisonnable.

Par contre je vois que tu as déjà ajouté :

https://www.openstreetmap.org/node/9963915006/history#map=20/44.20876/6.97873

Or si je regarde BDOrtho, la position ne me semble pas terrible (pas
mauvaise non plus) mais différente de celle de l'OD. Donc ce n'est pas
un import bête (bien) mais un meilleur fond pourrait être utilisé.

La source date de 2020 mais tu mets 2022 comme date.

Pourquoi ne pas importer ID_NCA (ici 1461120V) en ref ? Ca permettrait
de faire un meilleur suivi, par exemple savoir ce qui est dans OSM et ce
qui ne l'est pas.

Jean-Yvon

Le 05/09/2022 à 15:05, Erwan K - e.kergr...@gmail.com a écrit :

Bonjour à tous,

Première fois que je travaille avec une API Open Data pour ajouter des POIs
sur OSM
Suite à une remarque de Marc_ch, je poste ici les infos pour en parler avec
la communauté et continuer avec votre accord.

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/strerylmreepsemibot
https://github.com/erwanstermrp/nicecotedazur_recyclage

J'ai envie de continuer sur ce genre de réutilisation d'open data à
l'avenir donc n'hésitez pas à me corriger, je prends tous les conseils ;)

A la prochaine !
StrMrp
___
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] usage de landuse - was: Comment faire? forêt broadleaved & needleleaved

[osm . sanspourriel]

Je pense que le problème est plus large que les espaces boisés et porte
sur les landuse en général.

Certains sont "larges" au sens où les residential, retail, etc...
incluent des espaces non explicitement dédiés à cela, je pense à la
voirie qui en fait partie alors qu'on n'y vend rien (hormis exceptions
comme ce week-end dans une grande ville du Grand Nord, pardon des Hauts
de France ;-)), où qu'on n'y habite pas (quoique...).

Certains sont ambigus, je pense à forest et à farmland.

Car sur la page citée dans l'approche 1 c'est au sens large, dans les
approches 3, 4 au sens restreint (là où il y a de la forêt).

Si on reprend l'exemple de David, on voit que les forêts
(landuse=forest) incluent les chemins. Donc une version "large",
inclusive de la forêt : les chemins, drains, etc. font partie de la forêt.

Pour farmland j'ai la même approche (je vais au droit des voies car la
voirie est modélisée de manière linéaire), d'autres qui pourtant ne
remettent pas l'usage de residential par exemple en question (en mettant
les jardins et la voirie dedans), ont une approche plus stricte (mais
j'aimerais savoir comment ils fixent la limite quand on passe
directement de l'asphalte au champ mais où les véhicules pour se croiser
mordent sur le champ : quand c'est en herbe, l'agriculteur sème le
raygrass en bord de route, quand c'est en oléagineux, maïs, etc, il
évite de semer trop près de la route : va-ton regarder ce qu'il sème
pour délimiter le farmland/meadow ? Oui ma réponse est dans la question).

Et sur l'orthophoto, on va voir les arbres déborder de leur emprise au
sol. Si c'est le critère on va supprimer des routes ;-). Et vu le
décalage du cadastre, l'emprise cadastrale de la route (en surfacique
donc) n'est pas utilisable.

Donc pour moi j'ai d'un côté un bois et de l'autre un champ, entre une
route, la route étant modélisée en linéaire ses points d'accroche sont
partagés - oui JB ! Celui voulant faire de la micro cartographie pourra
par endroit ajouter un fossé côté bois.

Il me semble intéressant de voir si on peut arriver à un consensus sur
les limites des "landuse" : stricts et on vire tout ce qui n'est pas
directement liés à l'usage donné ou plus souple (zone dédiée à la
sylviculture, à l'agriculture, à l'habitat, au commerce, à l'industrie...) .

Pour le sens strict un landcover me semble plus adapté.

Typiquement un coupe-feu
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcutline
man_made=cutline, cutline=firebreak fait partie de la forêt alors qu'il
est dépourvu d'arbres. C'est explicite que tel doit être le cas dans le
wiki (ne pas interrompre la forêt).

Au fait David :

> Un exemple ici : https://www.openstreetmap.org/relation/13897472

Non, n'importe qui dira au vu du wiki que la forêt est plus étendue et
là on ne voit que la partie gérée par l'ONF.

Taguer pour mettre un nom ? Une relation de type site me semble plus
justifiée dans ton cas.

Et dedans on a des zones contigües taguées de manière identique :

landuse=forest
leaf_cycle=deciduous
leaf_type=broadleaved

par exemple :

https://www.openstreetmap.org/way/576053516#map=15/48.3557/6.1327

et
https://www.openstreetmap.org/way/576053516#map=15/48.3557/6.1327

Ce qui d'un point de vue modélisation correspond à une scorie
équivalente au découpage arbitraire de bâtis par le cadastre.

JB, je ne vois pas par rapport à ton besoin en quoi la relation site ne
convient pas. Ajouter un schéma spécifique pour un cas qui reste
général, je ne comprends pas.

Jean-Yvon

Le 05/09/2022 à 20:59, JB - jb...@mailoo.org a écrit :

Bonsoir à tous,
Pour rééquilibrer, pour moi, ce tag boundary=forest (ou un équivalent)
était nécessaire depuis longtemps, pour faire la différence entre la «
zone avec des arbres dessus » et la « zone nommée » forêt domaniale de
Cetteville, qui peut contenir des clairières, des étangs…
De la page Forest du wiki https://wiki.openstreetmap.org/wiki/Forest,
je ne tire pas les mêmes conclusions. Il y est proposé, entre-autres,
que wood est plus ou moins égal à forest, avec un aspect zone sauvage
ou entretenu plus ou moins marqué. Ta conclusion ne me semble pas
unanime.
JB.

Le 05/09/2022 à 08:53, Marc_marc a écrit :

Bonjour David,

Le 05.09.22 à 07:19, David Marchal via Talk-fr a écrit :

C’est précisément pour ce genre de cas que j’avais conçu le tag
boundary=forest


tu sais bien que pour moi ce tag est un abération qui ne fait
que rajouter de la confusion
si on veux tager un landuse, la bonne clef est... landuse
et non boundary


un (multi)polygone type=boundary + boundary=forest + name=… pour
représenter le fait que l’ensemble est une seule et unique forêt,


ton utilisation est encore pire que ce qui a été voté !

la surface de "foret de ABC" n'est pas la même que la surface
de l'exploitation forestière
il suffit d'un étang, une place Pique-nique au milieu de cet endroit
: il est compris dans la foret de ABC, mais personne n'utilise l'endroit
pour la sylviculture

donc ce tag mal connu ne résout pas le soucis ici,
puis le 

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[osm . sanspourriel]

C'est justement parce que c'est le même couple attribut/valeur principal
qu'il n'y a pas de souci.
Si ce n'était que la clé on serait d'accord.
Sinon par rapport au tag de David, le problème c'est que ça n'apporte
rien ici de plus par rapport à une relation site et pose éventuellement
les mêmes problèmes de contrôle que les multi-polygones (dont les
éléments doivent être disjoints).

Jean-Yvon

Le 05/09/2022 à 08:59, Marc_marc - marc_m...@mailo.com a écrit :

Le 04.09.22 à 21:40, osm.sanspourr...@spamgourmet.com a écrit :

Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des
sous-parties sans nom et de même clé principale avec les deux types de
plantations ?


tu as donc 2 objets décrivant la meme chose (le meme tag principal)
au meme endroit, c'est donc que l'un des 2 n'est pas bon (tu voulais
décrire un surface composée de zone boisée et éveneutlement non boisée
tel un étang)






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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[osm . sanspourriel]

Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des
sous-parties sans nom et de même clé principale avec les deux types de
plantations ?

Jean-Yvon

Le 04/09/2022 à 21:07, Marc Mongenet - marc.monge...@gmail.com a écrit :

Mouais, le place=locality n'est pas du tout satisfaisant. Déjà, c'est un
tag pour le rendu.
Et en plus ça ne donne pas le bon rendu aussi bien au niveau taille que
couleur des caractères.

Pour ce qui est du landuse=forest vs natural=wood, comme je m'occupe
énormément d'occupation des sols, j'utilise landuse pour residential,
vineyard, farmland, farmyard, meadow, quarry... du coup je reste dans le
landuse pour forest par habitude. Cela dit, j'utilise occasionnellement
natural=wood lorsqu'il y a des arbres si serrés dans un autre landuse que
ça forme un petit bois. Par exemple dans du residential.

Marc Mongenet

Le dim. 4 sept. 2022 à 20:19, Marc_marc  a écrit :


Bonjour,

Le 04.09.22 à 20:07, Marc Mongenet a écrit :

Comment mapper une forêt dont certaines parties sont broadleaved et
d'autres needleleaved?
Tout cela en donnant un nom unique à la forêt.

un place=locality pour le nom
des natural=wood pour les zones boisées broadleaved et needleleaved


Le plus logique serait un grand landuse=forest

non landuse=forest n'a rien de logique :)
landuse c'est forestry ou loisir ou chasse ou un peu tout cela à la fois


même question se pose pour une zone humide natural=wetland
avec des parties wetland=swamp et d'autres wetland=reedbed.

des natural=wetland pour les différents sous-type
et un objet place=locality pour héberger le nom

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

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

[osm . sanspourriel]

D'accord avec tout ce que dit Georges et en particulier :

Le 31/08/2022 à 12:55, Georges Dutreix via Talk-fr -
talk-fr@openstreetmap.org a écrit :


À titre personnel, je préfère faire ces imports avec associatedStreet,
cela permet en particulier de faire ressortir pour une rue toutes les
adresses existantes.


Il arrive que la culture nourricière soit remplacée par le nourrissage
de promoteurs immobiliers avec en conséquence la prolongation des rues
sur de nouveaux lotissements, auquel cas il arrive que les rues se
trouvent prolongées sans changer de nom : une partie avant sans nom
(juste la ref de la voie) prend le nom de la voie et les super-outils de
Vincent et de Fred ne voient pas pas la soucis. Avec des adresses
ajoutées en bout, l'associatedStreet te pète à la gueule.

Contre le fait de mettre les noms de rue sur le PDA en plus car dans ce
cas on a double maintenance, l'associatedStreet c'est pour faciliter la
vie alors si on met en plus la modélisation pourrie, on n'a rien gagné.

N. B : en fait avec Osmose les adresses trop loin de la rue sont
détectées. Pas forcément les plus proches du changement de nom précédent.

> - la position des addr est souvent flotante tandis que d'autres
voudraient les voir au moins en bordure du batiments concernées. c'est
envisagable ou on est toujours dans un non-consensus

Concernant les adresses préexistantes placées sur des immeubles/maisons,
que fait on : on place sur un point du bâti au plus près du PDA de la
BAL/BAN/BANO... ? On prend le way malgré tout ? On prend le PDA de la
BAL/BAN/BANO...

Flottant c'est ce qui est fait par défaut sur les sources importées, non ?

Si très proche d'une limite du bâti je suis pour coller au bâti (car de
l'habitat urbain).

Pour l'habitat plus dispersé avec des adresses plus loin des maisons, je
mets en général des voies privées allant de la rue principale aux
maisons en question afin de lever tout ambiguïté. Car pour rappel les
adresses servent avant tout à aller à la propriété en question. Et si
vous dites où est la maison mais que les gens ne savent pas par où y
accéder... Je vois juste quelques cas comme des résidences où cette
approche pourrait ne pas marcher.

Non je ne propose pas que l'import trace les voiries privées manquantes^^.

Jean-Yvon



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

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

[Cyrille37 OSM]

Bonjour

Je vous rejoins sur le fait qu'il faut faire qlq chose avec ces adresses.

Sur la forme:
- préférence pour relation associatedStreet
- non pas rue par rue, mais adresse par adresse (cf Adrien)
- points flottants (tels quels)

Merci pour cette initiative, pas facile à poser devant le collectif :-)

Cyrille37.

On 31/08/2022 18:09, PanierAvide wrote:

Bonjour,

+1 pour aller dans ce sens, ça sera d'autant plus facile d'aborder les 
territoires et services de l'État pour coopérer avec eux si les 
adresses certifiées sont déjà dans OSM.


Sur les questions, cf ci-dessous

Adrien P.

Le 31/08/2022 à 12:15, Marc_marc a écrit :

- on importe avec des addr:street (plus facile pour l'utilisteur
dans l'état actuel des outils) ou en associatedStreet (beaucoup
plus facile pour permettre de trouver les addr ayant + d'un
nom de voie (soit différent noms en attendant de lever l'invertitude,
soit des noms multilangue comme certains rues en Bretagne)
Partisan du plus simple pour le contributeur, donc addr:street. Mais 
pas opposé à associatedStreet, voire faire les deux.
- on importe d'abord les 100% certifiée ou un taux + faible est 
acceptable ? deuzeffe parlait de 75%
J'aurais eu tendance à prendre l'approche non pas rue par rue, mais 
adresse par adresse : si c'est certifié, on importe dans tous les cas 
(hormis n° déjà présent). Si ça ne l'est pas, sans doute une condition 
intelligente pour pas se priver de données pertinentes : si l'adresse 
est très récente, logique vis à vis du reste (pas  alors que tout 
le reste est entre 1 et 30)...

- faut-il ajouter des critères de qualitée ? par ex dans le passé,
ce n'était pas rare d'avoir plusieurs addr au même endroit

Oui :-)

- il serrait utile de pouvoir différentier les addr ayant
été importée de celle ayant été manipulée paar un contributeur osm
pour cela je propose d'utiliser le tag volatif created_by=import.
l'avantage de ce tag comparé à la veille méthode du tag source
sur l'objet, c'est qu'il est volatif et donc dès qu'un contributeur
modifiera l'objet osm, l'ancienne source "bal" disparaitra 
automatiquement au lieu de garder des source=bal sur des objets

ayant des infos différente de celle de la source renseigneé.
le côté volatif de ce tag est supporté par iD, josm et surement
d'autres éditeurs.
Techniquement ça marche, mais ça me semble (ab)user d'une 
fonctionnalité des éditeurs qui n'est pas prévue pour ça. Un bon tag 
source + filtre sur n° de version pourrait permettre de faire la même 
chose (comme on le fait sur Corine Land Cover).
- la position des addr est souvent flotante tandis que d'autres 
voudraient les voir au moins en bordure du batiments concernées.

c'est envisagable ou on est toujours dans un non-consensus ?
Question intéressante mais on est trop longtemps restés bloqués sur 
les adresses, il est temps qu'on importe même si ce n'est pas parfait. 
Tant qu'il est possible pour les personnes rigoureuses de mettre ça 
ailleurs par la suite, on ne devrait pas s'interdire un import.


Cordialement,
Marc



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

Re: [OSM-talk-fr] Inscription étrange sur OrthoHR : A bad place

[osm . sanspourriel]

Le 29/08/2022 à 15:42, leni - lenny.li...@orange.fr a écrit :


Il s'agit d'une œuvre
https://officiel-galeries-musees.fr/tradition-de-lavant-garde-au-chateau-de-montsoreau/



Aux messagers précédents j'ajoute :

artwork_type <https://wiki.openstreetmap.org/wiki/FR:Key:artwork
type?uselang=fr>=graffiti

Exemple : https://www.openstreetmap.org/node/4081669006

Exemple d'œuvre temporaire : (bon là il faut un was:)

https://www.openstreetmap.org/way/825168087

À l'époque il y avait pairie et gazon, du coup dans OSM il état
physiquement visible dans certains rendus.

Ici je ne sais si inscription=A bad place convient

Jean-Yvon



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

Re: [OSM-talk-fr] Inscription étrange sur OrthoHR : A bad place

[osm . sanspourriel]

Le 29/08/2022 à 15:42, leni - lenny.li...@orange.fr a écrit :


Il s'agit d'une œuvre
https://officiel-galeries-musees.fr/tradition-de-lavant-garde-au-chateau-de-montsoreau/



Aux messagers précédent j'ajoute :

artwork_type <https://wiki.openstreetmap.org/wiki/FR:Key:artwork
type?uselang=fr>=graffiti

Exemple : https://www.openstreetmap.org/node/4081669006

Exemple d'œuvre temporaire : (bon là il faut un was:)

https://www.openstreetmap.org/way/825168087

À l'époque il y avait pairie et gazon, du coup dans OSM il état
physiquement visible dans certains rendus.

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

Re: [OSM-talk-fr] édition mécanique/de masse] car=* -> motorcar=*

[Cyrille37 OSM]

Bonjour Marc

Oui, merci :-)

Cyrille37.

On 25/08/2022 18:06, Marc_marc wrote:

Bonjour,

en 2020 le tag car a été déprécié en faveur de motorcar.
il était surtout utilisé sur les bornes de recharge.
Dans la pratique motorcar=* est 100x plus courant
que car=* et ce même pour les bornes de recharge.
aucun projet n'a renseigné l'utilisé encore selon taginfo

je propose de convertir ceux encore présent en France.

Comme d'habitude en cas de conflit (car et motorcar présent
avec des valeurs différente), l'objet serra ignoré par
l'édition mécanique et serra traité à la main (moins de 7 cas)
Pour ceux souhaitant les traiter https://overpass-turbo.eu/s/1ll4

Avis ?

Cordialement,
Marc



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

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

Re: [OSM-talk-fr] josm : ajouter un fond de carte jpg

[osm . sanspourriel]

Merci Adrien.

Hélène, pour compléter tu peux avoir besoin/envie de recaler le fond de
carte.

Pour ça https://mapwarper.net/ n'est pas mal : tu le fais en ligne et
après tu peux y accéder en WMS via JOSM.

Ou récupérer le GeoTIFF georectifié et l'utiliser.

Les deux outils peuvent se compléter, pour une carte c'est sans doute
MapWarper qui va être le plus pratique. Pour un plan plutôt PicLayer je
pense.

Jean-Yvon

Le 25/08/2022 à 09:28, PanierAvide - panierav...@riseup.net a écrit :

Bonjour,

C'est avec l'extension PicLayer que tu peux faire ça :
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PicLayer

Cordialement,

Adrien P.

Le 25/08/2022 à 09:23, Hélène PETIT a écrit :

Bonjour,

J'ai un fond de carte fait à la main que je veux mettre dans un
calque de josm, pour comparer, je ne retrouve pas comment faire,

Merci !

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


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




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

Re: [OSM-talk-fr] josm : ajouter un fond de carte jpg

[osm . sanspourriel]

Le 25/08/2022 à 13:02, Jean-Yvon Landrac a écrit :


Ou récupérer le GeoTIFF georectifié et l'utiliser.


Il faudra dans ce cas le convertir car
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PicLayer signale la
restriction:

No support for (Geo)TIFF

Jean-Yvon



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

Re: [OSM-talk-fr] Points géodésiques disparus ?

[osm . sanspourriel]

Disons qu'a minima on n'est pas à 100 m près. Là c'est à 23 cm.

Mettre une vérification n'est pas stupide, si ça peut éviter de mettre
un point à côté même si je suppose que celui qui intègre fait attention.

Remplacer un test >0 par >100, ça devrait être dans les cordes de celui
qui maintient l'analyseur ;-).

Jean-Yvon

Le 24/08/2022 à 22:15, Jean-Claude Repetto - jrepe...@free.fr a écrit :


Yep, C'est ce que j'ai fini par déduire. Peut-être faire un
signalement (hum) voire un ticket sur le backend d'osmose ?



Je suis d'accord, je pense que cette vérification n'est pas pertinente.



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

Re: [OSM-talk-fr] Village en ruines : quels tags /

[osm . sanspourriel]

Bonjour,

avec l'interdiction d'arrosage c'est effectivement un bon repli pour le
jardinage^^.

J'avais écrit en // de Marc (et pas expédié).

building=ruins bof, voir ci-dessous, pour le centre de mémoire c'est
déjà le cas : https://www.openstreetmap.org/way/109155437



Grosso modo je suis d'accord avec toi. Sauf que les "murs" datent de 2019.

Et de plus avec des trucs bizarres comme ceci :
https://www.openstreetmap.org/relation/9900584

Un regroupement des murs non mitoyens d'un pâté de maisons !

Certains sont déjà tagués comme tu le veux :
https://www.openstreetmap.org/way/176596588/history

Sauf que là ce serait plutôt

ruins:building=church

et

historic=church

Car le problème de building=ruins c'est que ça dénature la clé.

> précieusement préservés en l'état, mais ce n'est pas le sujet

Par exemple l'église dont le toit n'a pas été reconstruit mais les
tuiles pour protéger les murs ont été posés :

https://commons.wikimedia.org/wiki/File:France_NA_87_Oradour-sur-Glane_04.jpg

Donc des ruines entretenues. Je pense utile de faire la distinction.
historic=ruins ?

https://wiki.openstreetmap.org/wiki/Tag:historic%3Druins

La question est juste pour le bâti ordinaire devenu d'importance
historique par l'histoire.

La clé heritage doit pouvoir être ajoutée sur plusieurs bâtis. Donc
https://www.pop.culture.gouv.fr/notice/merimee/PA8742 mais c'est la
nouvelle église.

https://www.pop.culture.gouv.fr/notice/merimee/PA00100409

www.culture.gouv.fr/Wave/image/merimee/PDF/PA00100409_CMH_1946.pdf

En fait c'est tout le village qui est protégé en tant que tel et pas
chaque bâti.

Une question (ouverte) : Il y a un champ de foire et c'est :

https://www.openstreetmap.org/way/621736555/history (ou à peu près) mais
sans nom dans OSM.

or

https://www.openstreetmap.org/way/271765705/history à un nom faisant
croire que c'est l'actuelle Place du Champ de Foire. Je ne sais si c'est
à laisser ainsi.

Jean-Yvon

Le 19/08/2022 à 19:14, deuzeffe - opensm@deuzeffe.org a écrit :


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

Re: [OSM-talk-fr] édition mécanique/de masse] wood=* -> leaf_type=*/leaf_cycle=*

[Cyrille37 OSM]

On 11/08/2022 11:32, Marc_marc wrote:

Bonjour,

lors de l'édition de masse précédente [1] pour la France métropolitaine,
je n'avais pas fais attention que ce tag déprécié était aussi présent
à la réunion et en polynésie.
je propose donc d'étendre l'édition de masse aux dom-tom.

avis ?


Pour. Merci :-)

Cyrille37



[1] 
https://lists.openstreetmap.org/pipermail/talk-fr/2022-July/105407.html


Cordialement,
Marc


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

Re: [OSM-talk-fr] historique des vues aériennes était : Vue aérienne Bing de meilleure résolution que l'Ortho HR

[osm . sanspourriel]

Bonjour, dans le droit fil des images qui peuvent être mieux ou moins
bien suivant les cas, je suis tombé sur Living Atlas.

Déjà une bonne info : devrait être intégrable sous peu à OSM SmartMenu.
Si vous voulez accélérer :
https://github.com/vannizhang/wayback/issues/68 (un volontaire pour un
PR en js pour utiliser un système plus classique zoom/lat/lon ?).

Déjà en cliquant on sait de quand date l'image et quelle est la source.

Permet de comparer différentes images côté à côte (avec un curseur),
animation (en excluant certaines images), téléchargement de gif animé...

Des candidats pour brancher les wms usuels d'Ortho HR pour faciliter le
travail de recherche de la meilleure image ?

Vu le système actuel (utilisation de BBox), je vous pointe sur un
endroit et vous pourrez vous déplacer avec la loupe pour choisir un endroit.

https://livingatlas.arcgis.com/wayback/#ext=-3.54559,47.76023,-3.51195,47.77549=true=16245=2

Oui l'endroit n'est pas pris par hasard. Outre que le coin est beau ;-)
il bouge vite : ici l'agrandissement du port au nord a modifié
l'écoulement en aval mais déjà sans... Dans d'autres endroits j'ai vu
des différences qui venaient de traitement différents sur les mêmes
images brutes.

Pour les parties stables on voit qu'une vue en hiver peut être mieux
qu'une vue plus récente en été.

Rien d'extraordinaire sauf que voyant les dates de prises de vue, on
peut déjà avoir une idée.

Le gif animé ou l'animation permet aussi de repérer les images possédant
des objets temporaires (ici carrousel et point de surveillance).

Jean-Yvon

P. S. : à votre avis, le bunker au sud, dans combien de temps il se
trouve au milieu du fleuve ?

Sur l'image de 2020, une belle baïne. Cette année là une personne avait
été récupérée (vivante) à 500 m du rivage. Respectez les panneaux
d'interdiction, ce n'est pas juste de la déco ! Oui dans OSM il y a des
swimming=no qui vont bien.

Le 04/08/2022 à 20:39, Jean-Yvon Landrac a écrit :

Bonjour,

version courte : varier les sources pour trouver la meilleure pour la
problématique donnée.



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

Re: [OSM-talk-fr] Une note qui fait partie d'une relation ?

[osm . sanspourriel]

Bonjour toutes et tous,

Oui, on ne va pas laisser des notes pour dire qu'il faut taguer
correctement ^^.

Jean-Yvon

Le 10/08/2022 à 17:13, laurent-38 - laurent.riffard+...@free.fr a écrit :

(on peut enlever la note si on considère que cela va de soi…)

Cordialement
~~
laurent



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

Re: [OSM-talk-fr] question sur un nouveau nom de rue et procédures BANO

[osm . sanspourriel]

> Sans rapport avec OSM mais tout de même avec le sujet :-)

Pas tout à fait : normalement BAN, BANO et OSM ont un certain lien^^.

https://www.openstreetmap.org/way/255320841

Comme tu verras ce n'est pas le seul endroit où le cadastre indique
"ilôts" :

https://www.openstreetmap.org/search?query=Rue%20des%20Il%C3%B4ts%2C%2063#map=19/45.90023/3.01673

https://www.openstreetmap.org/edit?editor=id=107287601#map=20/45.06789/4.83180
:-(

J'aurais mis :

name=Rue des Îlots

official_name=Rue des Ilôts (si tu trouves la décision du Conseil Municipal)

alt_name=Rue des Ilôts (si le CM dit Îlots ou Ilots et que seul le
panneau indique le contraire)

source:alt_name=sign (pas de note, un "vrai" attribut c'est plus
clair/utilisable/cherchable)

À noter que ilots est aussi correct en français depuis 1990.

Et j'aurais demandé à la mairie :

http://www.charbonniereslesvarennes.fr/fr/questions-publiques

Perso, je en mets local_name que pour un nom "localisé" ainsi. C'est à
dire une dénomination utilisée par les locaux.

Jean-Yvon

Le 09/08/2022 à 12:27, Cyrille37 OSM - cyrille+talk...@giquello.fr a écrit :

Bonjour,

Sans rapport avec OSM mais tout de même avec le sujet :-)

L'État fourni un outil et de l'accompagnement aux communes pour gérer
leur base adresses : https://adresse.data.gouv.fr/gerer-mes-adresses.
Tu peux peut-être demander à la mairie si elle est informée de cette
démarche, qui me semble importante pour contribuer à ce commun ;-)

Cyrille37.

On 09/08/2022 12:12, Pierre Beyssac wrote:

Bonjour à tous,

Récemment la commune d'un petit village que je connais au fin fond
du Puy de Dôme a ajouté des noms de rues. Les ayant vus cet été,
je les ai ajoutés dans OSM.

Cependant l'un des panneaux de rue me pose un problème.

Le panneau porte l'inscription "Rue des Ilôts" (j'en ai pris la
photo).

Si c'est une référence au mot français, l'orthographe correcte
serait plutôt "Îlots", ou "Ilots" avec la réforme de 1990. J'ai mis
cette dernière orthographe dans OSM en attendant d'y voir plus
clair.

Sinon, c'est peut-être une référence à un nom propre, lieu-dit ou
autre. Les autres noms de rues de la commune correspondent à des
zones identifiées sur le cadastre et pour la plupart reportées sur
la carte IGN, mais je n'ai pas trouvé de zone à ce nom.

Faut-il reporter telle quelle l'orthographe du panneau dans OSM ?

Sinon, comment faire pour trouver une autre référence ?

Peut-on vérifier dans une autre base publique servant de source pour
BANO ?
J'ai regardé hier l'extraction IGN pour le Puy de Dôme mais le nom
n'y figure pas encore, pas plus que les autres noms de rues.

Faut-il appeler la mairie ?

On m'a dit qu'ultérieurement, la commune allait attribuer des numéros
aux habitations, mais ce n'est pas encore fait.

___
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] question sur un nouveau nom de rue et procédures BANO

[Cyrille37 OSM]

On 09/08/2022 12:39, Vincent de Château-Thierry wrote:
Si finalement la plaque se trompe, tu peux ajouter le nom constaté sur 
la plaque via un tag note=* pour éviter que quelqu'un après toi 
veuille rétablir dans le tag name le nom erroné. 


Dans ce cas j'utilise les tags name=* (délibération) ET local_name=* 
(panneau).


Et éventuellement le tag note=* pour expliquer ;-)

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

Re: [OSM-talk-fr] question sur un nouveau nom de rue et procédures BANO

[Cyrille37 OSM]

Bonjour,

Sans rapport avec OSM mais tout de même avec le sujet :-)

L'État fourni un outil et de l'accompagnement aux communes pour gérer 
leur base adresses : https://adresse.data.gouv.fr/gerer-mes-adresses. Tu 
peux peut-être demander à la mairie si elle est informée de cette 
démarche, qui me semble importante pour contribuer à ce commun ;-)


Cyrille37.

On 09/08/2022 12:12, Pierre Beyssac wrote:

Bonjour à tous,

Récemment la commune d'un petit village que je connais au fin fond
du Puy de Dôme a ajouté des noms de rues. Les ayant vus cet été,
je les ai ajoutés dans OSM.

Cependant l'un des panneaux de rue me pose un problème.

Le panneau porte l'inscription "Rue des Ilôts" (j'en ai pris la
photo).

Si c'est une référence au mot français, l'orthographe correcte
serait plutôt "Îlots", ou "Ilots" avec la réforme de 1990. J'ai mis
cette dernière orthographe dans OSM en attendant d'y voir plus
clair.

Sinon, c'est peut-être une référence à un nom propre, lieu-dit ou
autre. Les autres noms de rues de la commune correspondent à des
zones identifiées sur le cadastre et pour la plupart reportées sur
la carte IGN, mais je n'ai pas trouvé de zone à ce nom.

Faut-il reporter telle quelle l'orthographe du panneau dans OSM ?

Sinon, comment faire pour trouver une autre référence ?

Peut-on vérifier dans une autre base publique servant de source pour BANO ?
J'ai regardé hier l'extraction IGN pour le Puy de Dôme mais le nom
n'y figure pas encore, pas plus que les autres noms de rues.

Faut-il appeler la mairie ?

On m'a dit qu'ultérieurement, la commune allait attribuer des numéros
aux habitations, mais ce n'est pas encore fait.

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

Re: [OSM-talk-fr] Vue aérienne Bing de meilleure résolution que l'Ortho HR

[osm . sanspourriel]

Bonjour,

version courte : varier les sources pour trouver la meilleure pour la
problématique donnée.

Ce n'est pas la même endroit, il n'y a pas les mêmes voitures^^.

Si iD et JOSM permettent de changer de couche aérienne c'est que
certains ont une meilleure résolution (et c'est effectivement souvent le
cas de BD Ortho), pour l'âge, Maxar est souvent meilleur.

Après tu as d'autres critères : verticalité, absence de nuages. Tout ça
fait qu'il n'y a pas a priori de "bonne" source.

Aussi floutage (regarde mon exemple :  un futur évadé faisant faire de
la reconnaissance ?^^).

Si tu es dans un endroit stable, Maxar tu peux oublier (quoique, ils ont
par endroit de bonnes résolutions).

Tiens l'ortho 2016 de Loire-Atlantique (20 cm) qui est aussi Ortho HR
2016 mais avec un autre traitement semble fabriquer du crénelage sur les
traits de parking.

J'ai eu la flemme de convertir des numéros de tuiles en lat, lon, donc
j'ai pris un autre parking au nord de Nantes au hasard.

https://www.openstreetmap.org/#map=19/47.26653/-1.59136

Sur Bing
(https://www.bing.com/maps?v=2=47.26709~-1.59145=21=s) ils
indiquent deux sources :

- TomTom (et hop on va chercher les sources de TomTom).

- Vexcel Imaging (et là tu as ta réponse :
https://www.vexcel-imaging.com/products/)

Les exemples de Vexcel Imaging sont par aéronef mais rien n'interdit
d'utiliser des drones. Cependant s'ils en avaient connaissance ils
devraient en faire mention.

J'ai peut-être mal cherché, bonne chasse aux œufs (hors saison).

Jean-Yvon

Le 04/08/2022 à 19:02, Baptiste Jonglez - bapti...@bitsofnetworks.org a
écrit :



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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[osm . sanspourriel]

flood_prone (avec un souligné) et effectivement tidal.

Par contre c'est surtout utile là où le chemin passe au dessus de la
PM95 (trait de côte) et la PM120 (limite ordinaire des plus grandes
marées).
https://www.openstreetmap.org/way/1083321965#map=19/48.23098/-4.43089

Le cas n'est pas exceptionnel y compris pour des routes avec des
panneaux temporaires (ouvrables) ou permanents.

Par contre pour l'altitude je suis très réservé.

En effet c'est un point en zone marine. Le 0 des cartes marines c'est la
plus basse mer ordinaire.

Les altitudes sont faites pour qu'un bateau sache s'il passe tout le temps.

Donc avec des altitudes marines et des abaques (maree.info, produits
marée du Shom) on peut savoir si le chemin est submergé. Pas trivial
mais faisable.

Par contre avec une altitude terrestre (mi-marée) tu va devoir trouver
le demi marnage pour te ramener au cas précédent.

Je doute que quiconque s'en serve (pas grave) sauf si ça apparait sur la
carte et alors c'est probablement mal interprété.

Le but d'OSM n'est pas de nourrir les poissons avec les touristes et
autres badauds ;-).

Jean-Yvon


Le 02/08/2022 à 17:53, Eric SIBERT - courr...@eric.sibert.fr a écrit :

En complément des autres réponses, indiquer l'altitude des points de
la route devrait permettre de savoir pour quelle marée on peut passer.

Et un floodprone=yes (voir=tidal) pour aider à savoir que la route est
inondable. Même si le trait de côte permet de se douter que la route
est inondable, elle pourrait passer sur un pont ou un remblais.

Eric



___
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] Clés pour chemin sous marée

[osm . sanspourriel]

Tu peux éventuellement ajouter intermittent=yes si tu veux être plus
explicite.

Le 01/08/2022 à 17:01, whatis moss - whatism...@hotmail.com a écrit :

Dans mon cas j'ai un chemin accessible seulement lorsque la marée est 
inférieure à 3 mètres.


http://maree.info/68

Tu veux dire qu'il y a moins de 3 m au dessus du 0 des cartes marines ?
Ou que le marnage doit être inférieur à 3 m pour que ce ne soit pas
intermittent ?

Étant donné que les gens se baignent et se noient parce qu'ils vont de
baigner là où c'est interdit et que c'est expliqué pourquoi (baïnes,
courant portant au large), baliser un chemin rarement accessible, est-ce
une bonne idée ?

Vraie question.

Jean-Yvon



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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[osm . sanspourriel]

Bonjour,

je croyais qu'avec la corruption, un ancien maire de Trébeurden
avait résolu le problème en bétonnant la côte...

- Tu peux comme JP indiquer comme ici
https://www.openstreetmap.org/way/180645171, un fjord au niveau de la
traversée usuellement ou toujours submergée.

- Pour le reste comme ici https://www.openstreetmap.org/way/180645190
rien de spécifique car la limite du trait de côté implique que c'est
submergé à marée haute. Et on se doute que c'est dans la zone
intertidale ! Tu peux dessiner l'estran et préciser tidal=yes. Ce sui se
trouve à ce niveau sera de facto submergé à marée haute.

- Ou comme ici ne rien mettre :
https://www.openstreetmap.org/#map=19/48.30599/-4.55048

Il y a certes un panneau sur le coté gauche de la cale pour indiquer
qu'on peut rejoindre la pointe suivante par la grève à marée basse mais
c'est le seul signe tangible du "chemin".

Jean-Yvon

Le 01/08/2022 à 17:01, whatis moss - whatism...@hotmail.com a écrit :

Bonjour, j'aurais besoin d'aide pour savoir quelle clés utiliser pour un chemin 
qui est accessible seulement lors de la basse marée. La clé tidal=yes semble 
être répandue mais d'après le wiki, cette clé serait pour les étendues d'eau 
soumises à la marée plutôt que pour les chemins accessibles lors de la basse 
marée. Après cela, il y aurait t-il aussi une clé pour indiquer à quel niveau 
de marée le chemin est accessible ? Dans mon cas j'ai un chemin accessible 
seulement lorsque la marée est inférieure à 3 mètres.
___
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] [édition mécanique/de masse] nettoyage du tag surface (aussi possible en manuel dans votre zone de confort)

[osm . sanspourriel]

Dans ma ZdCÉ (zone de confort élargie ;-), ça me semble bon :

- des landuse avec surface=yes (je préviens le contributeur car les
landuse ne peuvent être que surfacique et dans la sens area=yes)
- des scories, mais autant les virer à la main :
https://www.openstreetmap.org/way/926177590, ou à cartographier
correctement https://www.openstreetmap.org/way/719518005

Donc c'est peut-être utile de se donner le temps de regarder disons dans
les 8 jours qui viennent ?

Maintenant ta manip automatique ne va rien perdre d'utile

N. B. : sur la 40aine de landuse, j'ai galéré pour virer ceux qui se
chevauchaient. Car à vouloir exclure de temps en temps la voirie des
zones agricoles...

Jean-Yvon

Le 28/07/2022 à 14:45, Marc_marc - marc_m...@mailo.com a écrit :


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

Re: [OSM-talk-fr] Itinéraire vélo non balisé

[osm . sanspourriel]

> Le 23/07/2022 à 10:32, Marc_marc - marc_m...@mailo.com a écrit :

td;dr : +1

> Le 23/07/2022 à 19:17, lejun - le...@gmx.fr a écrit :

Si seuls des nœuds et non le cheminement précis existent, il existe la
modélisation par carrefours mais là il y a un GPX, donc la relation en
filaire, ça me va (mais en partant des chemins OSM comme tu l'as fait).

email, email:operator : ni l'un ni l'autre, ce sont juste les mentions
légales du site. Si tu crèves, tu ne vas pas demander assistance à cette
personne, si c'est dû à la piètre qualité du revêtement, tu vas
t'adresser à l'opérateur de la voirie en question.

smoothness : sans intérêt car tu dis qu'il y a de tout et si un membre
passe à very_bad ou horrible, vas-tu mettre à jour la relation ? La
réponse est dans la question.

Quant à la possibilité de protéger un GPX par un copyright... La FFRP
arrive bien dans certains cas à valider ses itinéraires comme œuvres de
l'esprit, donc oui.

Est-ce bien raisonnable ? Certains tribunaux répondent par l'affirmative.

Jean-Yvon


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

Re: [OSM-talk-fr] [édition mécanique/de masse] post_office:type=* -> `post_office=*

[osm . sanspourriel]

Je suppose que tu veux dire que les éventuellement conflits seront
détectés à ce moment-là.

Deux attributs différents, je ne vois pas comme une édition automatique
pourrait proprement résoudre le conflit.

À la rigueur par étude du dernier attribut ajouté.

Je doute que ça concerne moult cas.

OK pour l'édition de masse.

Jean-Yvon

Le 22/07/2022 à 12:03, Marc_marc - marc_m...@mailo.com a écrit :

les éventuels conflits entre l'info donnée par post_office:type=*
et post_office=* se feront hors de l'édition de masse



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

Re: [OSM-talk-fr] equivalence subtance=* -> utility=* sur les pipeline=marker dépréciés

[osm . sanspourriel]

Bonjour,

remplacer les contenus par les types d'opérateurs, je ne sais qui a eu
cette idée saugrenue mais il n'est pas étonnant que ça ne marche pas bien.

Par exemple de l'eau ça peut servir pour un réseau de chauffage
(utility=heating) ou de l'adduction d'eau (utility=water) ou encore de
la collecte d'eaux usées (utility=sewerage) ou de l'eau pour les
pompiers (utility=hydrant).

Pas de soucis pour ajouter utility= par contre remplacer... Quand on ne
sait pas on supprime ?

Jean-Yvon

Le 19/07/2022 à 19:34, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

le déprécié pipeline=marker utilisait parfois erronément
subtance=* pour décrire ce que contenait le pipeline concerné.
cela a été remplacé par marker=* + utility=*

la conversion est triviale pour certaines valeur, exemple :
subtance=gas/oil -> utility=gas/oil
mais pour les autres ?
les 9 valeurs existante en france métropolitaine
substance=brine
substance=brine;water
substance=ethylene
substance=fuel
substance=gas -> subtance=gas
substance=hydrogen
substance=measurement
substance=oil -> subtance=oil
substance=water

Cordialement,
Marc



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




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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural

[osm . sanspourriel]

Le 12/07/2022 à 21:58, Volker Schmidt - vosc...@gmail.com a écrit :


Ou de l'incompétence de ceux qui ont importé les Landcover Corinne (je

parlerais plus de choix discutable).


Avec CORINE  il y a un problème de base: les données se basent sur des
images satellitaires de résolution insuffisante pour OpenStreetMap:

*CLC1990* *CLC2000* *CLC2006* *CLC2012* *CLC2018*
*Geometric accuracy, satellite data* ≤ 50 m ≤ 25 m ≤ 25 m ≤ 25 m ≤ 10 m
(Sentinel-2) *(source:
https://land.copernicus.eu/pan-european/corine-land-cover
)*


Pas forcément. C'est la source *satellitaire*, elle *peut* être
complétée par d'autres sources. Insuffisant pour un import, mais à la
date de l'import, c'était de qualité suffisante.

Avec les landuse il y a d'autres soucis comme ces landuse jouxtant
d'autres landuse de même nature
https://www.openstreetmap.org/way/676097710#map=15/48.8430/2.0737 ce qui
fait perdre la vision d'ensemble de la zone.

Jean-Yvon




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

Re: [OSM-talk-fr] Aide OSMAND ?

[osm . sanspourriel]

Salut,

un truc que j'avais remarqué c'est que les mises à jour automatiques
(toutes les heures, OSM Live) finissent par ralentir.

Donc quand tu dis le jour et la nuit, si tu installes sur carte externe
tu vas peut-être dire que c'est rapide (ou que tu as une carte mémoire
de faible classe).

Heureux d'avoir un vieil Androïd acceptant de mettre les cartes sur
support externe car j'ai 20 Go de cartes.

Jean-Yvon

Le 13/07/2022 à 23:33, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Salut tout le monde,

C'est un peu hors sujet, mais je viens de faire une mise à jour de mes
cartes sur OSMAND~ et ça me plante l'appli. Apparemment c'est
l'indexation de grand-est France, qu'il a d'ailleurs renommé "great
east", on se demande bien pourquoi, qui fait planter. Et toutes mes
autres cartes disparaissent de la vue.

Où puis-je trouver de l'aide pour résoudre ça ? J'ai rien trouvé sur
osmand.net, j'ai rien vu sur forum.openstreetmap.org...

En plus quand je vais sur l'onglet "télécharger", parfois j'ai la liste
"afrique, amérique, asie, europe,..." et parfois j'ai une liste
ultralongue qui commence par "afghanistan région 1, etc"


Merci !

Bonne soirée,

Jean-Pierre




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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Le 12/07/2022 à 19:19, Marc Mongenet - marc.monge...@gmail.com a écrit :

Je suppose que ça s'appelle mapper pour la maintenance.:-)  A moins que ce
soit dû à mon incompétence avec les multipolygon. Je ne sais pas.


+1 par rapport à JB sur ce point.

Ou de l'incompétence des outils pour gérer facilement ces multipolygones.

Ou de l'incompétence de ceux qui ont importé les Landcover Corinne (je
parlerais plus de choix discutable).

Oui c'est le bordel dans ce cas.

Pour le côté maintenance, c'est un problème d'outils pour séparer
facilement les deux parties communes. Conceptuellement ce que l'on veut
faire est simple. Bien plus simple que de créer des chemins parallèles.

Le 12/07/2022 à 19:40, Marc Mongenet - marc.monge...@gmail.com a écrit :

Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de
précision sur les limites de forest dans le canton de Genève.


Tu as de la chance de vivre dans une zone ou le contraste peut être fort
en hiver, où les arbres en hiver offrent une telle transparence et
d'avoir une telle ortho.

Si tu peux le faire proprement, je n'ai rien contre.

Ce qui me déplait c'est de fabriquer de la fausse information au
prétexte que c'est plus rigoureux d'un point de vue topologique.

Un autre soucis c'est qu'on n'a pas une rigueur constante concernant les
landuse, on le voit souvent au niveau des residential en zone rurale où
les limites sont les parcelles ou le bâti ou quelque chose d'approximatif.

On va à vous suivre éviter les routes. Donc une route coupe un landuse
forest mais pas un residential ?

Ou quand la route sert à la gestion forestière l'intégrer ?

> Oui, le width manque à la plupart des routes, c'est bien dommage,
mais c'est sans rapport avec les landuse.

Pas vraiment car dans les cas simples (je ne parle pas d'autoroute mais
de route de campagne, de chemins), la largeur de la route définit l'emprise.

Jean-Yvon





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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Avec cette logique, pour une rue bordée d'immeubles, il faudrait
prolonger la surface des immeubles jusqu'à l'axe central de la voie...
On ne le fait pas, au moins parce que notre source pour le bâti est de
qualité correcte, et que souder les bâtiments aux highways serait à la
fois chronophage et synonyme de dégradation de la qualité, vue la
déformation manifeste qu'on ferait subir aux géométries de bâtiments.
Bref, ça ne vient à l'idée de personne je pense.


Non le landuse en question c'est le residential.

Et il ne viendrait à personne l'idée d'exclure les routes de ce landuse,
ni les jardins, ni les...

Pourtant personne ne réside sur la rue. Sous les ponts etc... oui hélas
mais c'est un autre sujet.


Par analogie, la seule raison que je vois pour coller les landuses aux
filaires de voies est l'absence d'une source géométrique assez
précise, combiné au temps que prend le dessin de ces surfaces. Ça
n'est donc (pour moi) qu'une version intermédiaire de dessin des
landuse, et surtout pas une bonne pratique. La fonctionnalité de copie
parallèle dispo dans JOSM [1] est un bon compromis pour dessiner du
1er coup une limite de landuse non collée au filaire mais approximant
l'emprise de la chaussée.


OK pour la première partie. Par contre pas pour la seconde : on fabrique
de la fausse précision.

En restant au landuse surfacique / route filaire (mais éventuellement
avec une largeur), on ne crée pas de fausses données.

C'est imparfait, OK mais entre imparfait et faux...

Raffiner le tracé de la route si tu passes les landuse en traits
approximativement parallèles à la route, ça va vite être un cauchemar.

Sans rien apporter sauf le confort intellectuel d'arrêter le landuse à
peu près au bon endroit.

Sauf à prendre le tracé surfacique des routes du cadastre, je ne vois
pas de manière raisonnable de faire du travail propre surfacique tout en
affinant les tracés des routes. Et il s'agira de l'emprise de la route
et non de la route.

Jean-Yvon



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

Re: [OSM-talk-fr] Bon usage (ou bonne définition) des multipolygones ?

[TomTom OSM]

Bonjour,

Merci d'avoir jeté un coup d'œil au défi "Polygon has self intersection". Si 
possible, pourriez-vous partager l'ID d'une tâche ou de quelques tâches du défi 
contenant la situation que vous décrivez ? De cette façon, nous pouvons 
analyser ces cas et rechercher pourquoi ils sont détectés comme des problèmes. 
Merci de votre aide!

Marjan

-Original Message-
From: Christian Quest  
Sent: Friday 8 July 2022 12:12
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Bon usage (ou bonne définition) des multipolygones ?

Le 08/07/2022 à 00:56, osm.sanspourr...@spamgourmet.com a écrit :
>
> Non, faire des trous pour dire que les bâtiments ne font pas partie du 
> centre de loisir n'a aucun sens.


Pareil pour l'autre cas... il n'y a pas de raison de mettre les bâtiments en 
inner du landuse où ils se trouvent.

Une analyse révèle souvent des erreurs autres que celles qu'elle cherche à la 
base.

Sur le challenge concernant les relations "restriction", ça m'a remonté des 
intersections inutilement complexifiées par l'ajout de way pour les voies pour 
tourner alors qu'elles ne sont pas séparées, donc à mapper en
turn:lanes=* et pas avec des objets séparés.

On cherche des aiguilles dans la meule de foin et on trouve aussi des épingles 
;)

--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-frdata=05%7C01%7Cosm%40tomtom.com%7C9bdc8c866895489aa7dd08da60caacd2%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637928720841323966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=p%2Fj83E422cUdAkFXiM9ywTfZF9%2FcllGw8npy5yYlrk8%3Dreserved=0

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

Re: [OSM-talk-fr] Défis MapRoulette pour contrôles de qualité

[TomTom OSM]

Hi Christian,

Our "Not connected highway" challenge does exclude cases where 
highway=rest_area, but currently we are not yet able to exclude cases where 
there's a rest area but it is not tagged as such, like in the example you 
shared.

Marjan

-Original Message-
From: Christian Quest  
Sent: Friday 8 July 2022 12:01
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Défis MapRoulette pour contrôles de qualité

Ways with highway=rest_area should not be checked for connectivity... 
the wiki confirms that this tag is used only on areas and nodes, not unclosed 
ways.

Here is an example: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaproulette.org%2Fchallenge%2F27918%2Ftask%2F132558893data=05%7C01%7Cosm%40tomtom.com%7C4b937e71fb1c4855a50308da60c95cdd%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637928715207969268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=DgXvyDAU53pR%2BagslMXS9XV%2BjgpE1WkhP8%2FQKFCJhZQ%3Dreserved=0

--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-frdata=05%7C01%7Cosm%40tomtom.com%7C4b937e71fb1c4855a50308da60c95cdd%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637928715207969268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0djXxQlzfSabsRGwUEfT7ruCFQLGKNfYpvxi3UR0IYk%3Dreserved=0

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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Le 11/07/2022 à 16:41, Marc_marc - marc_m...@mailo.com a écrit :


et qu'on ai ou pas un tag approuvé, cela n'empeche pas d'arreté
la géométrie du champs/forêt au bon endroit et non pas au milieu de la
route : on ne culture pas sur la route même si certain roulent comme
des patates mais ca c'est une autre histoire :)

PS: on le fait correctement avec les landuse=railway : le champs ne va
pas jusqu'au milieu des rails

niveau pratique : faire une bonne géométrie pour la route, dupliquer
2x la route et décaler les copies de la largeur de l'emprise routière,
cela fait souvent une très bonne géométrie de départ en peu de temps


Pas trop d’accord. Le « problème » est celui soulevé par David : la
route est modélisée en filaire et les landuse en surfacique.

Tant qu’on fait ça, la représentation la plus logique est de faire aller
les landuse jusqu’à la route. Et c'est parce que du as des
landuse=railway que tu ne vas pas jusqu'au rails.

Et si plus tard on veut faire du surfacique pour la route, alors on va
arrêter le surfacique des côtés au surfacique de la route (comme c’est
fait pour les rails).

Mettre une largeur (width=) à une route tout en conservant le filaire me
semble préférable : la cartographie c’est une modélisation du monde, pas
du dessin.

Et cette approximation est plus juste que de dupliquer la géométrie et
de la décaler.

Je mets au défi quiconque de faire proprement du surfacique quand la
route longe une forêt : pour que ce soit propre vous allez partir du
centre de la route et dériver les limites via la largeur
(essentiellement constante) de la route, vous n’allez pas essayer
d’estimer la limite de la forêt par les troncs ou le houppier.

Bref, par analogie 2D/2,5D/3D, on fait du 1,5D.

Ce n’est que si on a besoin de cartographie fine que la modélisation de
la chaussée (avec les différents éléments cités par David) a du sens.

Mais si on se met à raffiner les tracés de routes, il faut faire suivre
les landuse, les fossés et tutti quanti ce qui rend les mises à jours
plus problématiques.

Et vous modélisez une rue avec trottoir avec sidewalk=both ou vous
mettez du surfacique pour le trottoir, le caniveau, la bordure du
trottoir, la dalle podotactile, etc. ?

Jean-Yvon




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

Re: [OSM-talk-fr] JOSM : traduction du logiciel - erreur due aux caractères d'échappement ?

[osm . sanspourriel]

J’allais répondre en privé mais comme j’ai compris où était le problème
j’en fait profiter la communauté.

> Vous êtes sur le point d'écraser le fichier de session "{0}".
Voulez-vous continuer ?

Est ce que tu as écrit.

Comme indiqué dans la page d’aide... et par toi les apostrophes sont
« problématiques » dans le sens où ils doivent être doublés ou mieux
substitués par l’apostrophe typographique.


Apostrophe informatique :

> d'écraser

à doubler :

> d''écraser

ou à remplacer par l’apostrophe typographique :

> d’écraser

Grammalecte est ton ami.

Jean-Yvon

Le 10/07/2022 à 18:12, leni - lenny.li...@orange.fr a écrit :


Le 10/07/2022 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour Lenny,

Est-ce que tu n'as pas une correction automatique des caractères
typographiques style Grammalecte ?

J'ai fait un copier/coller de ton texte, utilisé Grammalecte pour mettre
une apostrophe typographique et c'est passé.


Où as-tu mis l'apostrophe (ta modif est bien passée) peux-tu m'envoyer
le texte avec l'apostrophe typographique ?


___
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] JOSM : traduction du logiciel - erreur due aux caractères d'échappement ?

[osm . sanspourriel]

Bonjour Lenny,

Est-ce que tu n'as pas une correction automatique des caractères
typographiques style Grammalecte ?

J'ai fait un copier/coller de ton texte, utilisé Grammalecte pour mettre
une apostrophe typographique et c'est passé.

Donc non la correction automatique est peu probablement le souci, et
c'est tombé en marche.

Merci pour toutes les traductions ;-)

Jean-Yvon

Le 10/07/2022 à 15:10, leni - lenny.li...@orange.fr a écrit :

Bonjour,



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

Re: [OSM-talk-fr] Défis MapRoulette pour contrôles de qualité

[TomTom OSM]

Merci, Christian! Happy to hear that you like the challenge.

-Original Message-
From: Christian Quest  
Sent: donderdag 7 juli 2022 12:19
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Défis MapRoulette pour contrôles de qualité

Le 04/07/2022 à 14:38, TomTom OSM a écrit :
> Bonjour,
>
> C'est Marjan de TomTom. Je ne parle pas le français régulièrement, donc je 
> m'excuse si ce message contient des erreurs. La version anglaise de ce 
> message que j'ai traduite avec l'aide de DeepL Translate est incluse 
> ci-dessous.
>
> J'ai quelques défis MapRoulette que j'aimerais partager avec vous. Ces défis 
> peuvent vous aider à résoudre différents types de problèmes de données en 
> France. Vous pouvez les trouver tous dans ce projet 
> MapRoulette<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaproulette.org%2Fbrowse%2Fprojects%2F48741data=05%7C01%7Cosm%40tomtom.com%7C6e35a17d11924b3966b308da60027b8a%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637927861021689359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=aTLILF%2F89lKcXtJUHjEmFLpeo4k53DKuC%2FsgeQQ68NA%3Dreserved=0>.
>
> Les tâches des défis ont été générées à l'aide d'instances publiques d'outils 
> d'assurance qualité OSM tels que Atlas et Osmose, et de contrôles de qualité 
> développés et validés en interne. Vous pouvez parcourir les défis une tâche à 
> la fois, évaluer les données et corriger des erreurs de qualité si nécessaire.
>
> Vous trouverez plus de détails sur nos activités d'amélioration des données 
> en France sur notre page 
> GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftomtom-international%2Fopen-data%2Fissues%2F145data=05%7C01%7Cosm%40tomtom.com%7C6e35a17d11924b3966b308da60027b8a%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637927861021689359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hrlHILPVxhEDE5XlIYJ3JFvz8MemAGMZY7klAlJwcYk%3Dreserved=0>.
>
> Sentez-vous libre d'essayer ces défis. Notre équipe y travaillera aussi dans 
> quelques semaines. Faites-moi savoir si vous avez des questions ou des 
> commentaires.
>
> Bonne journée!
>
> Marjan
>
> -
>
> I have a couple of MapRoulette challenges that I would like to share with 
> you. These challenges can help you fix different types of data issues in 
> France. You can find all of them in this MapRoulette 
> project<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaproulette.org%2Fbrowse%2Fprojects%2F48741data=05%7C01%7Cosm%40tomtom.com%7C6e35a17d11924b3966b308da60027b8a%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637927861021689359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=aTLILF%2F89lKcXtJUHjEmFLpeo4k53DKuC%2FsgeQQ68NA%3Dreserved=0>.
>
> The tasks in the challenges were generated using public instances of OSM 
> quality assurance tools such as Atlas and Osmose, and internally developed 
> and validated quality checks. You can go through the challenges one task at a 
> time, assess the data and correct quality errors where needed.
>
> More details about our data improvement activities in France are on our 
> GitHub 
> page<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftomtom-international%2Fopen-data%2Fissues%2F145data=05%7C01%7Cosm%40tomtom.com%7C6e35a17d11924b3966b308da60027b8a%7C374f80267b544a3ab87d328fa26ec10d%7C0%7C0%7C637927861021689359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hrlHILPVxhEDE5XlIYJ3JFvz8MemAGMZY7klAlJwcYk%3Dreserved=0>.
>
> Feel free to try out these challenges. Our team will also work on them in a 
> couple of weeks. Let me know if you have any questions or comments.
>
> Have a nice day!
>
> Marjan
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.openstreetmap.org%2Flistinfo%2Ftalk-frdata=05%7C01%7Cosm%40tomt
> om.com%7C6e35a17d11924b3966b308da60027b8a%7C374f80267b544a3ab87d328fa2
> 6ec10d%7C0%7C0%7C637927861021689359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7Csdata=%2Fcb9krC0%2F8fOzzCYILKVfHxFWVAql5CDFDTlSiN0onk%3Dre
> served=0

Bonjour Marjan,

The "invalid turn restriction" challenge is very nice.

I'm surprised by some weird restrictions added by users using iD... I suspect 
some problem at the editor level.

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Bon usage (ou bonne définition) des multipolygones ?

[osm . sanspourriel]

Nous sommes d'accord sur le fond et oui cette contiguïté par poser
souci, par exemple quand un une clairière comporte une maison qui est en
bord de forêt : tu dois créer un inner comme étant l'enveloppe de la
clairière et de la maison.

C'est un exemple théorique, normalement tu ne mets pas une maison au
droit des arbres ! J'ai déjà eu un cas différent mais similaire.

Non, faire des trous pour dire que les bâtiments ne font pas partie du
centre de loisir n'a aucun sens.

Jean-Yvon

Le 07/07/2022 à 19:14, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Bonsoir,

Je viens de commencer le défi 27912 de Marjan de Tomtom, "Polygon has
self intersection". Un petit dessin valant mieux qu'un grand baratin,
j'ai regardé https://www.openstreetmap.org/relation/2143328 et
https://www.openstreetmap.org/relation/12789892.

Dans les deux cas on a une grande surface "outer" qui définit la nature
de la zone, respectivement landuse=retail et leisure=resort. Mais dans
les deux cas l'auteur du multipolygone en a exclu les bâtiments, en en
faisant des membres "inner". Et comme certains de ces bâtiments sont
contigus, la requête de Marjan les sort en erreur en y voyant une "self
intersection".

Je n'ai aucune connaissance du type de requête qu'il y a derrière ça.
Première hypothèse : la requête de Marjan serait mal brêlée car la
contigüité n'est pas une intersection. Qu'en pensent les spécialistes ?
Si effectivement c'est le cas je lui expliquerai (avec les
éclaircissements des spécialistes...) qu'elle doit corriger sa requête.
Si c'est le fonctionnement normal... bin tant pis !


Mais sur le principe je trouve absurde d'exclure les bâtiments du
multipolygone. Autant quand il y a une grande clairière dans une plus
grande forêt je trouve logique que le petit polygone
"natural=grassland", ou "landuse=meadow", soit mis en membre inner du
"landuse=forest", autant pour moi, logiquement, les magasins font partie
de la "fonction" retail, comme les appartements et le restaurant font
partie ingégrante du "leisure=resort". Car après tout le terrain occupé
par le magasin est bien de type "retail" !

Et pour ma part quand je définis un landuse=retail je me garde bien d'en
exclure les magasins !


Y a-t-il un guide d'utilisation pour ces cas ? Quelle est la bonne
pratique ?

Merci de votre attention, bonne soirée (et bonnes vacances, si c'est le cas)


Jean-Pierre





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

Re: [OSM-talk-fr] [édition mécanique/de masse] wood=* -> leaf_type=*/leaf_cycle=*

[osm . sanspourriel]

Autant en langage naturel, la distinction bois/bosquet a un sens autant
avec OSM ça n'en a pas.

Car la différence c'est la surface, surface qui est tracée dans OSM.

> Ce taggage est proposé par iD.

Très mauvais justificatif parce que iD prend ce qu'il trouve en base, y
compris les erreurs.

Dans l'exemple passé par Marc les arbres sont distincts et font plus
penser à deux alignements d'arbres (tree_row), voir des natural=tree car
on les distinguent et ils ont visiblement été plantés à distance régulière.

Rein contre le fait de créer des nouveaux tags mais seulement quand ils
apportent quelque chose. Là je cherche encore.

Jean-Yvon, aussi peu convaincu que Marc

Le 06/07/2022 à 12:51, Christian Rogel -
christian.ro...@club-internet.fr a écrit :



Le 5 juil. 2022 à 21:55, blef via Talk-fr  a écrit :
En lisant ton message, j'ai d'abord cru à un lapsus de ta part, mais après recherches 
je vois qu'il existe bien des occurrences 
<https://taginfo.openstreetmap.org/tags/natural=tree_group> de 
natural=tree_group .
Par contre, je ne vois qu'une seule mention dans le wiki 
<https://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Dtree_group> dans les 
propositions avec le statut "draft".
Est-il judicieux d'utiliser un nouveau tag n'ayant fait l'objet d'aucune discussion et 
non documenté parmi les tag "en usage"?

Ce taggage est proposé par iD.
Je l’ai adopté, car il correspond à une lacune évidente : un bouquet d’arbres 
n’est pas un « wood » et distinguer chaque arbre, alors qu’il est imbriqué dans 
ses voisins, c’est induire en erreur, un taggage pour le non rendu.

Christian R.

___
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] Projet de cartographie des distributeur de preservatifs

[Cyrille37 OSM]

Salut

Ya ça: https://wiki.openstreetmap.org/wiki/OpenLoveMap

On 06/07/2022 11:32, Ludovic Hirlimann wrote:

Coucou,


je cherche le site qui permet de cartographier les distributeurs de 
capote, dans ma tête c'était à openstreetmap.xyz, mais a priori non, 
car cela ne répond pas. Qui peut me donner l'URL, mon 
qawnt/bing/google fu ne fonctionnant pas.



Merci

Ludo


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

Re: [OSM-talk-fr] hierarchie routière - port de Calais

[osm . sanspourriel]

Bonjour,

je trouve que c'est bon car tous les accès sont bien des voies de
services, la voie principale c'est celle qui te conduit à ton ferry.

Et ça va dépendre des arrivées et des départs des bateaux.

Tu veux récupérer le trafic AIS pour en fonction des quais prévus par la
capitainerie modifier en temps réel les voies principales ?^^

Actuellement c'est le quai 10 avec le Spirit of Brittany ;-)

https://map.openseamap.org/?zoom=15=50.9761=1.8767=BFTFFTF0TF

Jean-Yvon

Le 05/07/2022 à 13:01, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

https://www.openstreetmap.org/node/9484428895
une idée d'amélioration ?
il y a un peu trop de highway=service, le cheminement principal
mériteraient d'être remonté mais en quoi ? unclassified ?

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-ee] MapRoulette'i väljakutsed kvaliteedikontrolliks

[TomTom OSM]

Tere,

See on Marjan TomTomilt. Ma ei oska eesti keelt, seega tõlkisin selle 
postituse, kasutades DeepL Translate. Algne ingliskeelne versioon, millest ma 
alustasin, on lisatud allpool.

Mul on paar MapRoulette'i väljakutset, mida tahaksin teiega jagada. Need 
väljakutsed võivad aidata teil lahendada erinevaid andmeprobleeme Eestis. Kõik 
need leiate sellest MapRoulette'i 
projektist<https://maproulette.org/browse/projects/48742>.

Väljakutsete ülesanded on loodud OSMi kvaliteeditagamise vahendite, nagu Atlas 
ja Osmose, avalike instantside ning sisemiselt väljatöötatud ja valideeritud 
kvaliteedikontrollide abil. Saate väljakutseid ühe ülesande kaupa läbi vaadata, 
andmeid hinnata ja vajadusel kvaliteedivigu parandada.

Täpsem teave meie andmete parandamise tegevuste kohta Eestis on meie GitHubi 
lehel<https://github.com/tomtom-international/open-data/issues/146>.

Proovige neid väljakutseid julgelt läbi! Ka meie meeskond töötab nendega paari 
nädala jooksul. Andke mulle teada, kui teil on küsimusi või kommentaare.

Ilusat päeva!

Marjan

-

I'm Marjan from TomTom. I have a couple of MapRoulette challenges that I would 
like to share with you. These challenges can help you fix different types of 
data issues in Estonia. You can find all of them in this MapRoulette 
project<https://maproulette.org/browse/projects/48742>.

The tasks in the challenges were generated using public instances of OSM 
quality assurance tools such as Atlas and Osmose, and internally developed and 
validated quality checks. You can go through the challenges one task at a time, 
assess the data and correct quality errors where needed.

More details about our data improvement activities in Estonia are on our GitHub 
page<https://github.com/tomtom-international/open-data/issues/146>.

Feel free to try out these challenges! Our team will also work on them in a 
couple of weeks. Let me know if you have any questions or comments.

Have a nice day!

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

[OSM-talk-fr] Défis MapRoulette pour contrôles de qualité

[TomTom OSM]

Bonjour,

C'est Marjan de TomTom. Je ne parle pas le français régulièrement, donc je 
m'excuse si ce message contient des erreurs. La version anglaise de ce message 
que j'ai traduite avec l'aide de DeepL Translate est incluse ci-dessous.

J'ai quelques défis MapRoulette que j'aimerais partager avec vous. Ces défis 
peuvent vous aider à résoudre différents types de problèmes de données en 
France. Vous pouvez les trouver tous dans ce projet 
MapRoulette<https://maproulette.org/browse/projects/48741>.

Les tâches des défis ont été générées à l'aide d'instances publiques d'outils 
d'assurance qualité OSM tels que Atlas et Osmose, et de contrôles de qualité 
développés et validés en interne. Vous pouvez parcourir les défis une tâche à 
la fois, évaluer les données et corriger des erreurs de qualité si nécessaire.

Vous trouverez plus de détails sur nos activités d'amélioration des données en 
France sur notre page 
GitHub<https://github.com/tomtom-international/open-data/issues/145>.

Sentez-vous libre d'essayer ces défis. Notre équipe y travaillera aussi dans 
quelques semaines. Faites-moi savoir si vous avez des questions ou des 
commentaires.

Bonne journée!

Marjan

-

I have a couple of MapRoulette challenges that I would like to share with you. 
These challenges can help you fix different types of data issues in France. You 
can find all of them in this MapRoulette 
project<https://maproulette.org/browse/projects/48741>.

The tasks in the challenges were generated using public instances of OSM 
quality assurance tools such as Atlas and Osmose, and internally developed and 
validated quality checks. You can go through the challenges one task at a time, 
assess the data and correct quality errors where needed.

More details about our data improvement activities in France are on our GitHub 
page<https://github.com/tomtom-international/open-data/issues/145>.

Feel free to try out these challenges. Our team will also work on them in a 
couple of weeks. Let me know if you have any questions or comments.

Have a nice day!

Marjan

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

Re: [OSM-talk-fr] [édition mécanique/de masse] wood=* -> leaf_type=*/leaf_cycle=*

[osm . sanspourriel]

Aussi pour les éditeurs qui utilisent ce qui est en base (et non ce qui
est dans le wiki) pour proposer les valeurs.

Et oui iD utilise l'imitation contrairement à JOSM qui utilise
l'intelligence collective.

Chacun son truc ;-).

Donc pour, évidemment pour.

Jean-Yvon

Le 01/07/2022 à 16:31, Cyrille37 OSM - cyrille+talk...@giquello.fr a écrit :

Bonjour,

Je vote "Pour" :-)

C'est bénéfique pour les nouveaux, ou comme moi qui cherche souvent en
regardant comment les autres ont fait.

Merci !

Cyrille37.



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