Re: [OSM-talk-fr] Tagger (ou pas?) la compétence voirie à Paris (mairie vs. prefecture)

[Marc_marc via Talk-fr]

Bonjour,

Le 02.04.24 à 11:57, Tristram Gräbener a écrit :

Est-ce qu’une telle information aurait donc sa place dans OSM ? Si
vous pensez que oui, quelle tête auraient les tags?


Je ne sais pas s'il faudrait tager cela, invisible sur l'espace public 
(mais après tout, on a plein de chose invisible sur le terrain dans osm)

mais si tu veux le faire, c'est le tag operator=*

et vu le volume, je te conseille de lire la page wiki des imports

Cordialement,
Marc




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

Re: [OSM-talk-fr] Banc de sable visible seulement l'été dans un fleuve

[Marc_marc via Talk-fr]

Bonjour,

Le 04.03.24 à 10:13, rpnpif a écrit :

https://www.openstreetmap.org/#map=17/47.38079/-0.63932

Je propose que les bancs de sable de ce genre de fleuve et seulement 
dans ce cas ne soient pas représentées par un attribut


natural=shoal
seasonal=dry_season
surface=sand
comme élément indépendant 


je pense qu'il y a un problème de rendu :
l'aspect intermittent de natural=shoal n'est pas rendu.
Le rendu eau par intermittence te parait mieux ?
ce serrait une amélioration/correction à proposer


mais sous la forme :
natural=river
shoal=yes
seasonal=dry_season
(facultativement surface:dry_season=sand)


sémantiquement, un banc de sable intermittent n'est pas une rivière,
mais une partie de la rivière.
je trouverai + logique de faire comme pour les places de parking
ou les parties de bâtiments : avoir un tag qui dit que c'est
une sous-partie.
Quelque chose du genre (à affiner) :
natural=river_part
intermittent=yes
seasonal=dry_season

+ éventuellement
dry_season=water ou river ?
wet_season=sand
éventuellement avec le prefixe surface

Cordialement,
Marc



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

Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Marc_marc via Talk-fr]

Le 04.03.24 à 10:17, Eric SIBERT a écrit :
Pour le longue distance, je ne vois pas ce que ça apporte de dire que le 
bus par l'autoroute et la rue qu'il prend pour desservir la gare routière.


j'imagine que d'autres vont trouver interessant de pouvoir lister
les trajets récurrent sur une voie donnée.

Et comme il n'y a aucune obligation de contribuer à un sujet,
si l'itinétaire Paris-Lisbonne n'est pas à jour avant d'éditer
une route à Poitiers, je vois aucun soucis à ce que tu édites
la route sans éditer la relation



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

Re: [OSM-talk-fr] Lieux de fraîcheurs

[Marc_marc via Talk-fr]

Le 01.03.24 à 14:33, rpnpif a écrit :
Je suis aussi d'accord avec Marc. La fraîcheur est une notion subjective 
sauf si elle est repérée par un panneau, de la municipalité par exemple. 
Sinon, je ne vois pas comment la qualifier.


en utilisant les mêmes genres de critères que la commune ? :)
Mais j'ignore lesquels.
ou simplement en renseignant que cela lieu est agréablement + frais
que la moyenne en cas de canicule. cela pourrait se faire sur 3 niveaux 
(oui non limité) comme pour d'autres clefs tout aussi subjective.

ou si quelqu'un veux aller + loin, on pourrait imaginer renseigner
une différence de température en canicule (tu mesures dehors
et dans la bibliothèque, et tu mets la différence.

cette clef ne devrait être à mon avis pas être utilisé quand
c'est une climatisation qui est à l'oeuvre, vu le caractère inprévisible 
de l'activation de la clim et de son règlage




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

Re: [OSM-talk-fr] Lieux de fraîcheurs

[Marc_marc via Talk-fr]

Bonjour,

Le 29.02.24 à 21:54, Sébastien Dinot a écrit :

https://wiki.openstreetmap.org/wiki/FR:Key:air_conditioning


le gros soucis de ce tag c'est que cela ne dit ni la température,
ni le besoin du batiment.
un local vitré plein sud climatisé et bien éblouissant,
ce n'est pas nécessairement + "rafraichisant" qu'une veille chapelle

Inversément le supermarché à 20°, c'est, de mon point de vue,
à fuir quand il fait 35° sauf si vous souhaitez y rester jusqu'à
2h du mat : en sortant de là, c'est coup de bambou assuré telement
que l'écart de température est important


Auriez-vous connaissance de tags dédiés ?


il y a aussi shade
https://wiki.openstreetmap.org/wiki/Key%3Ashade
mais qui a le défaut de mal juger la qualité que cela apporte :
une terrase sur une place betonnée/asphalté, même ombragé,
c'est beaucoup moins bien qu'une entourée d'arbre

Cordialement,
Marc



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

Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Marc_marc via Talk-fr]

Bonjourr,

Le 15.02.24 à 08:40, Nicolas Dumoulin a écrit :

est-ce que vous savez si ça a déjà été évoqué quelquepart ?


j'ai vu cela pour des relations de bus titanesque,
de mémoire celle de Flexibus. elles sont découpés par pays.
mais j'imagine qu'aucun outil ne gère cela.
Je ne le ferai pas pour un bout de rue

Cordialement,
Marc



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

Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI

[Marc_marc via Talk-fr]

Le 14.02.24 à 15:55, Bruno Remy via Talk-fr a écrit :

je ne vois toujours pas comment techniquement faire ce remplacement automatisé?


overpass turbo pour récupérer tous les objets pole emploi
export vers josm
sélection de tous les noms pole emploi
vérifier que tu n'as pas des choses tordues (ex un arret de bus)
remplacer le nom
envoyer en n'oubliant pas les tags de changeset vers ta page wiki de 
l'opération




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

Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI

[Marc_marc via Talk-fr]

Bonjour,

Le 14.02.24 à 11:17, Bruno Remy via Talk-fr a écrit :

Pôle emploi est devenu France Travail depuis le 1er janvier 2024
Y-a-t-il un moyen d'industrialiser le changement sur tous les POI de France?
J'ai regardé avec JOSM mais on est obligé de sélectionner une zone de 
modification sur la carte.
Vos idées sont les bienvenues.


techniquement il suffit de faire la recherche sur la France
et faire la procédure d'édition de masse [1]
mais tu as déjà une objection/question pour le changement du name
Pour ma part, le fait qu'un bureau n'a pas encore changé le nom
sur son écriteaux ne devrait pas empêcher de changer name=*
l'inscription sur le batiment, si on veux ce nniveau de détail,
serrait pour inscription. si on téléphone, je suppose qu'il
s'annonce avec le nouveau nom et non avec ce qui est inscrit
sur le panneau

[1] 
https://wiki.openstreetmap.org/wiki/FR:Politique_de_modification_automatis%C3%A9e




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

Re: [OSM-talk-fr] Zone atterrissage pour parapentes

[Marc_marc via Talk-fr]

Pour être plus précis,
- virer le tag operateur, qui est incorrect

- pour le site web :
d'autres sports ont un objet "utilisateur"
par ex club=sport qui pourrait conserver le tag
du site web si du moins il y a quelque chose
sur place et que c'est pas un simple "passage",
cad si ce n'est pas j' atterris et je m'en vais
Dans ce cas je ne vois pas de raison de garder
le tag du site web, par comparaison on ne met
pas sur les chemins de rando un tag du site web
de toute les clbus qui s'y baladent

Cordialement,
Marc

Le 17.01.24 à 09:23, Marc_marc a écrit :

Bonjour,

si le club de parapente utilise le stade de foot,
il n'en sont pas l'opérateur, donc le tag initial
me semble incorrect, ils ne sont que usager.

Cordialement,
Marc

Le 16.01.24 à 17:05, Arnaud Champollion a écrit :

Bonjour,

Merci pour vos réponses.

J'envisage donc de supprimer cet objet :

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

Cependant il faudrait que je transfère avant les attributs pertinents 
vers le vrai polygone du stade pour ne pas perdre trop d'information.


Pour ceux-là :

operator:website=http://bleonailes.free.fr
operator=Bleon'ailes
website=https://federation.ffvl.fr/terrain/1129

,difficile de les conserver car ils s'appliqueraient alors au stade, 
ce qui n'est pas la réalité.


Comment faire ?


Le 14/01/2024 à 19:09, Christian Quest a écrit :

Le 14/01/2024 à 16:06, Marc_marc via Talk-fr a écrit :


Si si, il y a des atterrissages officiels sur des terrains de foot, 
avec convention et tout le bazar.


je n'ai pas dis que ce n'est pas le cas :)
je dis que la partie sport du parapente se passe en l'air,
le décolage/atterisage n'est, à mes yeux, que l'entrée/sortie
du terrain.
si tu veux mesurer l'étendue de la zone sportive, cela n'a
pas de sens de mesurer l'aire d'attérisage

pour prendre une autre comparaison : un plongoir n'est pas un 
leisure=pitch sport=swimming... on nage après être parti du plongoir

mesurer le plongoir comme étendue sportive n'aurait pas + de sens
que mesurer le terrain d'atérisage du parapente

c'est pourrquoi contrairement au wiki, je pense que le tag
principal n'est pas bon 



Ah ok, c'était pas clair... terrain faisant référence au sol, pour le 
reste, c'est l'espace de pratique et là les limites sont l'espace 
aérien et sa réglementation... et les compétences du pilote et les 
conditions aérologiques du jour !


La FFVL établi des conventions avec les propriétaires de terrains de 
décollage et d'atterrissage, donc la part "terrain" c'est juste ça 
dans le vocabulaire libériste, pareil que pour les terrain 
d'aviation. Dans la base de la fédé, on a la notion de "site", avec 
un ou plusieurs déco et atterro qui sont liés.


Les sports qui se pratiquent en milieu naturel ont en général des 
points de départ/arrivée à peu près identifiés, le reste au milieu 
est difficilement cartographiable car potentiellement non limité.


Avec ces tags, on peut savoir où des parapentes (ou delta) décollent 
et posent, c'est déjà ça !





___
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] Zone atterrissage pour parapentes

[Marc_marc via Talk-fr]

Bonjour,

si le club de parapente utilise le stade de foot,
il n'en sont pas l'opérateur, donc le tag initial
me semble incorrect, ils ne sont que usager.

Cordialement,
Marc

Le 16.01.24 à 17:05, Arnaud Champollion a écrit :

Bonjour,

Merci pour vos réponses.

J'envisage donc de supprimer cet objet :

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

Cependant il faudrait que je transfère avant les attributs pertinents 
vers le vrai polygone du stade pour ne pas perdre trop d'information.


Pour ceux-là :

operator:website=http://bleonailes.free.fr
operator=Bleon'ailes
website=https://federation.ffvl.fr/terrain/1129

,difficile de les conserver car ils s'appliqueraient alors au stade, ce 
qui n'est pas la réalité.


Comment faire ?


Le 14/01/2024 à 19:09, Christian Quest a écrit :

Le 14/01/2024 à 16:06, Marc_marc via Talk-fr a écrit :


Si si, il y a des atterrissages officiels sur des terrains de foot, 
avec convention et tout le bazar.


je n'ai pas dis que ce n'est pas le cas :)
je dis que la partie sport du parapente se passe en l'air,
le décolage/atterisage n'est, à mes yeux, que l'entrée/sortie
du terrain.
si tu veux mesurer l'étendue de la zone sportive, cela n'a
pas de sens de mesurer l'aire d'attérisage

pour prendre une autre comparaison : un plongoir n'est pas un 
leisure=pitch sport=swimming... on nage après être parti du plongoir

mesurer le plongoir comme étendue sportive n'aurait pas + de sens
que mesurer le terrain d'atérisage du parapente

c'est pourrquoi contrairement au wiki, je pense que le tag
principal n'est pas bon 



Ah ok, c'était pas clair... terrain faisant référence au sol, pour le 
reste, c'est l'espace de pratique et là les limites sont l'espace 
aérien et sa réglementation... et les compétences du pilote et les 
conditions aérologiques du jour !


La FFVL établi des conventions avec les propriétaires de terrains de 
décollage et d'atterrissage, donc la part "terrain" c'est juste ça 
dans le vocabulaire libériste, pareil que pour les terrain d'aviation. 
Dans la base de la fédé, on a la notion de "site", avec un ou 
plusieurs déco et atterro qui sont liés.


Les sports qui se pratiquent en milieu naturel ont en général des 
points de départ/arrivée à peu près identifiés, le reste au milieu est 
difficilement cartographiable car potentiellement non limité.


Avec ces tags, on peut savoir où des parapentes (ou delta) décollent 
et posent, c'est déjà ça !





___
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] Zone atterrissage pour parapentes

[Marc_marc via Talk-fr]

Le 14.01.24 à 11:40, Christian Quest a écrit :

Le 14/01/2024 à 11:00, Marc_marc via Talk-fr a écrit :

Le 23.12.23 à 10:09, Capello13 via Talk-fr a écrit :
La documentation sur le wiki est disponible ici : 
https://wiki.openstreetmap.org/wiki/FR:Tag:sport%3Dfree_flying


j'ai un peu du mal à considérer que le terrain de sport du parapente 
est l'attérisage, cad après qu'on ai finit de jouer en l'air...


ce serrait comme décrire que le terrain de sport du foot,
c'est le vestiaire 



Si si, il y a des atterrissages officiels sur des terrains de foot, avec 
convention et tout le bazar.


je n'ai pas dis que ce n'est pas le cas :)
je dis que la partie sport du parapente se passe en l'air,
le décolage/atterisage n'est, à mes yeux, que l'entrée/sortie
du terrain.
si tu veux mesurer l'étendue de la zone sportive, cela n'a
pas de sens de mesurer l'aire d'attérisage

pour prendre une autre comparaison : un plongoir n'est pas un 
leisure=pitch sport=swimming... on nage après être parti du plongoir

mesurer le plongoir comme étendue sportive n'aurait pas + de sens
que mesurer le terrain d'atérisage du parapente

c'est pourrquoi contrairement au wiki, je pense que le tag
principal n'est pas bon



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

Re: [OSM-talk-fr] Zone atterrissage pour parapentes

[Marc_marc via Talk-fr]

Le 23.12.23 à 10:09, Capello13 via Talk-fr a écrit :
La documentation sur le wiki est disponible ici : 
https://wiki.openstreetmap.org/wiki/FR:Tag:sport%3Dfree_flying


j'ai un peu du mal à considérer que le terrain de sport du parapente est 
l'attérisage, cad après qu'on ai finit de jouer en l'air...


ce serrait comme décrire que le terrain de sport du foot,
c'est le vestiaire

c'est ce préconise le wifi mais cela me semble pas être
un schéma logique



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

Re: [OSM-talk-fr] Zone atterrissage pour parapentes

[Marc_marc via Talk-fr]

Le 23.12.23 à 10:09, Capello13 via Talk-fr a écrit :

ça ne résout pas le conflit de nom


alt_name permet de résoudre cela :)



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

Re: [OSM-talk-fr] Magasin temporairement fermé ?

[Marc_marc]

Le 10.12.23 à 20:45, LeJun via Talk-fr a écrit :

Le 10/12/2023 à 18:59, pepilepi...@ovh.fr a écrit :

   * marqué "boulangerie",
   * avec une vitrine qui laisse deviner que c'est effectivement une
 boulangerie,
   * mais qui ne sert à rien vu s'elle n'est jamais ouverte.

Comment on peut tagguer ça ?


Dans un cas général je fais partie des gens qui utilisent `shop=vacant` 
pour un local commercial vide.


mais cela n'a pas l'air d'être viide d'après ce qu'il décrit :)

j'aurais séparé en 2 objects :
un objet building=*
un objet occupation décrivant une boulangerie présente mais non ouverte 
: disused:shop=bakery + disused:name=* si tu souhaites le garder ou 
inscription=... si tu souhaites renseigner qu'il y a une inscription,
puisque ce n'est plus le nom de la boulangerie puis qu'elle n'est plus 
utilisée


was:* est aussi possible (c'est même ce que j'utilise le plus souvent)
mais ne permet pas de décire finement le fait que ce n'est parce que
non utilisé. pour ma part je pense pas que la description du pourquoi
est une info pour osm



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

Re: [OSM-talk-fr] Tuiles manquantes à zoom=17

[Marc_marc]

Le 17.11.23 à 19:01, Rpnpif a écrit :

Par exemple, ces tuiles ou dalles ici :
https://c.tile.openstreetmap.fr/osmfr/17/65209/45793.png


ce n'est pas un soucis du à ton leaflet ni à un ban,
la tuile est absente du cache et pour une raison que j'ignore,
le serveur ne la produit pas.
à priori c'est soit une saturation de la file d'attente
soit une erreur de config qui fait que le n71 n'arrive
nulle part

je regarde dès que j'ai un peu de temps



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

Re: [OSM-talk-fr] Tuiles manquantes à zoom=17

[Marc_marc]

Le 16.11.23 à 20:37, Marc_marc a écrit :
d'autant + élevé que tu n'es pas authentifié et que tu ne les visualises 
pas depuis osm.org


je vpulais dire : d'autant + sévère (donc d'aautant + basse)



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

Re: [OSM-talk-fr] Tuiles manquantes à zoom=17

[Marc_marc]

Bonsoir,

Le 16.11.23 à 17:07, rpnpif a écrit :
Savez vous s'il y a une limite au nombre de chargement des tuiles 
identiques d'une même zone et une même adresse IP ?


Quel style ?
osmcarto (le style principal sur osm.org) a une limite, d'autant + élevé 
que tu n'es pas authentifié et que tu ne les visualises pas depuis osm.org

osm-fr n'a pas de limite automatique, quand un abus est détecté,
c'est le ban (et la limite est sympa puisque nécessite
une intervention humaine)

Cordialement,
Marc



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

Re: [OSM-talk-fr] Rond-point dupliqués et découpés suite à l'utilisation de OSM-relatify

[Marc_marc]

Bonjour,

Le 24.10.23 à 07:16, Baptiste Jonglez a écrit :

On 24-10-23, Vincent Bergeot wrote:

2) voir l'état à une date donnée
[date:"2023-06-22T00:00:00Z"];
way[highway]({{bbox}});
out geom;
https://overpass-turbo.eu/s/1AHa



Je réponds un peu tard, mais merci du tuyau, je viens de tester et c'est
très pratique !  Seul bémol, ça n'a pas l'air de charger les relations de 
l'époque.



 Dans la requête, seul les 'way' sont demandés à la date donnée (way[]),
 la même chose fonctionne pour une relation, il me semble.



En effet, merci, il suffit d'ajouter un « relation({bbox}); » et ça charge
toutes les relations dont un membre est présent dans la bbox.  Par contre
ça charge également tous les membres de toutes ces relations, ça peut vite
faire beaucoup de données, mais en tout cas ça répond au besoin.


c'est la récursion (la mienne en demandant la géométrie ou la tienne
en ayant demandé à la réparation automatique) qui est la cause
du chargement de tous les membres des relations. mais
c'est évitable :)

voici une requête qui charge les way+relations mais sans
ses membres hors vue
[date:"2023-06-22T00:00:00Z"];
way[highway]({{bbox}});
out geom;
relation({{bbox}});
out ;
https://overpass-turbo.eu/s/1Ct6

Cela fait quelques effets comiques pour les relations incomplètes,
par ex la relation administrative au SO, mais cela ne charge pas
les membres hors de la vue
il est également possible de limiter les types de relation, par
exemple en remplaçant la ligne avec relation[type=route]({{bbox}});

Cordialement,
Marc



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

Re: [OSM-talk-fr] Sens unique et double sens

[Marc_marc]

Bonjour,

Le 04.10.23 à 10:12, Luke Patwell a écrit :
Le sens de circulation d'une rue de mon quartier vient de changer : 
sens unique pour les voitures et double-sens pour les vélos. 
Comment l'indiquer sur la carte ?


oneway=yes (pour les voiture)
oneway:bicycle=no (pour les vélos)
ne pas oublier de regarder si le sens est dans la bonne direction

Cordialement,
Marc




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

Re: [OSM-talk-fr] Absence de crédit sur le site de la Fédération Française de Généalogie

[Marc_marc]

Le 26.09.23 à 10:26, rpnpif a écrit :

Le 25/09/2023 à 23:32, Yannick a écrit :
https://genefede.com/genealogis/archive. Vous omettez de créditer les 



désormais la page en question s'orne d'un avertissement
« L'attribution n'est pas une option «.


c'est une configuration qui se fait sur le serveur frontal servant
les tuiles produite sur l'infra osm-fr




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

Re: [OSM-talk-fr] Absence de crédit sur le site de la Fédération Française de Généalogie

[Marc_marc]

Bonjour,

Le 25.09.23 à 20:01, Yannick a écrit :
La Fédération Française de Généalogie utilise OSM sur son site 
https://genefede.com

Je n'ai pas vu le crédit sur la carte.
Il faudrait réagir fermement car c'est un prestataire qui a fait le site.


C’est une très bonne idée ». tu t'en occupes ? :)

Cordialement,
Marc




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

Re: [OSM-talk-fr] Rond-point dupliqués et découpés suite à l'utilisation de OSM-relatify

[Marc_marc]

Bonjour,

Le 17.09.23 à 21:43, Baptiste Jonglez a écrit :

Je ne sais pas comment voir l'état de ces rond-points
et relations avant la modification


le plus simple est overpass avec l'instruction [date:
tu donnes la date avant la modif et tu auras l'état
à ce moment là

plus précisement, je vais qlq chose genre :

1) centrer overpass sur la zone en prenant l'id d'un vieil objet
way(id:...);
out geom;
https://overpass-turbo.eu/s/1AH9
exécuter et centrer sur les données, zoomer

2) voir l'état à une date donnée
[date:"2023-06-22T00:00:00Z"];
way[highway]({{bbox}});
out geom;
https://overpass-turbo.eu/s/1AHa

PS: si tu as besoin des meta,
change out geom par out geom meta;
si tu as besoin de charger cela dans josm,
change out geom par out meta;>;out meta;

une autre solution est d'utiliser josm,
charger la zone et faire un revert du changeset
en question
s'il n'y a pas de conflit, tu vois alors
la zone tel qu'elle était avant la modif

Cordialement,
Marc



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

Re: [OSM-talk-fr] Route payante en été

[Marc_marc]

Bonjour,

Le 02.09.23 à 22:07, GarenKreiz a écrit :

piste forestière dont l'accès est payant de 9h à 16h30
en juillet-août pour cause d'affluence touristique 
( https://www.openstreetmap.org/way/206820611)



toll=yes


cela dépend si tu considères que c'est payant en temps normal ou pas (et 
si tu préfères que les applications ne gérant pas les cas complexes 
considère que c'est payant ou pas).

cela me semble une bonne idée de mettre le cas défavorable par défaut


toll:bicycle=no


les piétons payent ?


toll:services=no


qu'est-ce que cela signifie ?
services dans osm me fait penser à highway=services,
une aire de services (disposant généralement d'une
station-service, restaurant, boutique...)
ce n'est probablement pas ce que tu voulais renseigner :)


toll:opening_hours=..


cela décrirait quand le péage est ouvert...
ce qui est ambigu pour décrire que le péage
a lieu de tel à tel heure


Est-ce la bonne approche?


j'aurais plutôt fait ainsi :
toll=yes
toll:conditional= no @ ...

Cordialement,
Marc



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

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

[Marc_marc]

Bonjour,

merci pour cet interessant message

Le 08.08.23 à 23:05, LeTopographeFou a écrit :
Comment faciliter la vie des fournisseurs de service en faisant 
abstraction des limites du modèle de stockage OSM


et j'ajouterais : comment faire pour que ce projet
ne résulte pas en un Xieme "standard" de plus ?
car les entreprises font deja cela (et meme en partie
la maj bdd des serveurs de rendu) mais chacune partiellement
dans son coin.
on voit bien que meme niveau fr, l'idée a déjà forké
par rapport à ce qui avait discuté il y a des années
sans qu'aucun des 2 n'ai abouti réelement.


deux manières de gérer les adresses


voir 2x3 :) 2=addr:street<>associatedStreet 3 = noeud flotant, noeud sur 
l'outer, batiment


c'est le soucis qui a provoqué l'abandon d'osm chez un client :
le client avait besoin de pouvoir faire un reverse de qualité
cad si une position dans un batiment donne l(es) adresse(s) du batiment
(ou pour ceux qui veulent l'autre version : l'adresse de la porte
du batiment ou des portes)
cela impliquait un pré-traitement lourd des adresses flotantes (celle 
qui sont positionné hors de l'empreinte du batiment)

et quand tu as 2 adresses en bord de rue pour 2 batiments
l'un devant l'autre par rapport à la rue, rien ne permet
de connaitre ainsi l'adresse du batiment (j'en ferrai
un autre sujet si cela interesse quelqu'un ce vieux problème)

évidement d'autres ont peut-être un besoin différent

donc tu te retrouves à faire 2 versions ou avoir un moyen
en bdd pour choisir l'un ou l'autre

et tu extrapoles cela à tout :
faut-il pouvoir identifier l'accessibilité des bureaux de poste
selon que l'info vient d'osm, de l'opendata ou de 
l'opendata-pseudo-intégré-dans-osm ?


le code pour le prétraitement des addr est malheureusement fermé (quelle 
bétise de garder un code abandonné fermé) mais l'algo est facile

je serrai ravi de progresser sur ce point avec qui le souhaite

j'ai aussi sur la pile de pouvoir prétraité les données
pour convertir les tags déprécié lorsqu'il y a une relation 1:1
avec un nouveau tag

et le dernier sur la pile : virer les tags jettables des extraits osm-fr

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.


le soucis est le temps
qui va passer des heures à aider l'utilisation d'osm en entreprise ?
moi cela me motive... mais l'adn d'osm est l'artisanat bénévole axé
contribution. on (sous-)entend trop souvent que l'utilisation
de la donnée est presque sans importance

Cordialement,
Marc



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

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

[Marc_marc]

Le 28.07.23 à 15:19, Marc_marc a écrit :

la prochaine fois qu'un structure (par ex un office du tourisme)
voudra rendre dispo ses données, peut-être que celui-ci
s’effarera à les publier dans un format "pour Overture"
et non plus passer des heures pour les intégrer dans osm...


s'efforcera :)



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

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

[Marc_marc]

Bonjour,

cela parle partout d'Overture depuis 24h :)

Le 28.07.23 à 13:31, Francois Gouget a écrit :

Overture Maps est une fondation


mettons "fondation" entre "" puisque le but est vénal
c'est comme l'association non lucrative "lutte contre
le piratage de Microsoft" qui a été requalifié comme
lucrative par la justice à plusieurs reprises


qui ont été vérifiés


je préférerais dire "qui ont passé certains filtres" :

ce matin sur matrix/irc, un contributeur a trouvé
un noeud "pacific ocean", categories
{"main": "beach", "alternate": ["structure_and_geography", 
"landmark_and_historical_building"]}

websites
["http://en.wikipedia.org/wiki/pacific_ocean;]
socials
["https://www.facebook.com/1012436518820283;]

personne n'a évidement vérifié ce poi :)
PS: l'erreur est dans le profil FB du poi
on peux donc supposer que la base des poi
d'overture contient probablement au moins
un dump des poi FB


et sont prêts à être utilisés en production.


osm est tout aussi prêt :) et utilisé en prod :)
je comparerais plutôt Overture au maj "lente"
existant par exemple dans le monde OpenSource
soit tu veux quelque chose très vite à jour,
soit tu veux quelque chose qui est passé
à travers plus de tests donc + lent.
tu as moins d'erreur... et aussi moins de nouveauté.


ils ne font pas confiance aux données d'OpenStreetMap


on peux supposer plein de choses  :

p'tre que c'est parce qu'ils en ont eu assez de la difficulté
d'importer leur données dans osm (on se rapelle leurs tentatives
précédentes de faire changer les règles... on se rappelle les échecs 
quasi systématique des imports mondiaux avec la raison "on ferra

mieux en intégrant"... sauf qu'on n'a pas intégré les jeux dont
on a refusé l'import... on se rappelle aussi que dans certains pays
il est impensable d'importer le no 1 associé au boulevard de la 
république parce que "cela doit se faire à la main",

d'ici là Mme Michou se voyant proposer d'aller piocher les
coordonnées dans l'opendata puis l'écrire dans son app, ce
qu'elle ne ferra évidement pas, elle basculera sur GM..
en tout cas moi je ne fais pas ce genre d'utilisation
non ergonomique de l'opendata)

p'tre que c'est aussi une simple mutualisation des tests QA (alors
que niveau osm, on voit bien la difficulté par exemple a partager
des règles de validation entre iD et josm... "partager"
entre "" puisque le partage consiste à l'écrire 2x

ou bien ils c'est avant tout du marketing : c'est mieux
de prétendre qu'on a lancé un nouveau produit, plutôt que
dire qu'on a basculé vers un produit existant...
et c'est là mon principal soucis, si vous regardez les annonces
sur un agrégateur de nouvelles (par ex Google News), aucun
titre d'article sur le sujet ne mentionne osm, osm est devenu
un détail technique d'Overture d'une ligne dans un article
de 3 pages
la prochaine fois qu'un structure (par ex un office du tourisme)
voudra rendre dispo ses données, peut-être que celui-ci
s’effarera à les publier dans un format "pour Overture"
et non plus passer des heures pour les intégrer dans osm...

pour éviter cette relégation en 3ieme zone, je pense qu'il
faudrait une remise en question et analyser ce qui pourrait
être importé (oups intégré) afin que osm redeviennent
l'endroit principal et non pas un détail marginal et technique 
permettant à certains fonctionnalité d'Overture de fonctionner



après validation bien sûr (via Osmose par exemple).


c'est là où le bât blesse : dans le "pays d'osmose",
les signalements osmose n’intéressent pas assez de monde.

Cordialement,
Marc



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

Re: [OSM-talk-fr] Pifomètre v3 arrive...

[Marc_marc]

Le 12.07.23 à 12:51, Marc_marc a écrit :

Bonjour,

Le 12.07.23 à 10:11, Bruno Remy via Talk-fr a écrit :

Depuis hier soir Pifomètre V3 ne répond plus.


c'est reparti depuis 12h30 environ à priori




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

Re: [OSM-talk-fr] Pifomètre v3 arrive...

[Marc_marc]

Bonjour,

Le 12.07.23 à 10:11, Bruno Remy via Talk-fr a écrit :

Depuis hier soir Pifomètre V3 ne répond plus.


un gars a appuyé sur le mauvais bouton
https://github.com/osm-fr/infrastructure/issues/480
PS: le gars c'est moi :)

en attente d'un autre gars (un employé free sur place)
pour rappuyer sur le bouton car ce serveur n'a pas d'accès
à distance pour cela

Cordialement,
Marc



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

[OSM-talk-fr] améliorer OpenLayerss - présentoir carte

[Marc_marc]

Bonjour,

2 présentoirs carte d'osm-fr utilisent OpenLayer (une veille
version qu'il faudrait probablement mettre à jour)
https://tile.openstreetmap.fr axé "voir les rendus"
https://layers.openstreetmap.fr axé "contributeur"

j'ai fais un test d'ajouter une image pour le lien "Améliorer dans Osm"
sur les 2
https://github.com/osm-fr/presentoir-carte/issues/12
(sur layers ce n'est pas encore assez visible, la liste est devenue
trop longue)

j'ai aussi fait un test sur la partie en bas à gauche 
https://layers.openstreetmap.fr en remplaçant le logo+texte par
un logo avec balise alt + title (au survol) et en remplaçant le texte 
"qu'est-ce que ce service" par le logo osm-fr

avant cela ressemblait à https://tile.openstreetmap.fr

A suivre : trouver un plugin ou un icone pour ajouter "voir dans osm"
suggestion reçue sur 
https://github.com/osm-fr/infrastructure/issues?q=is%3Aissue+is%3Aopen+layers


qu'en pensez-vous ? critique bienvenue :)

Cordialement,
Marc



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

Re: [OSM-talk-fr] Encore une question sur les noms de rues

[Marc_marc]

Le 11.06.23 à 18:06, Daniel Garcia a écrit :

Ce lycée a comme "source" la valeur
"data.gouv.fr:Éducation
Nationale - 03/2018". Donc, ça me donne l'impression que, si j'essaie de
corriger l'orthographe, il sera sans doute remis à la mauvaise valeur à
l'avenir. Ou qu'il faudrait demander à l'Éducation Nationale de corriger
ses informations.


he non :) c'est le piège des tags source à l'ancienne sauce
cela dit juste qu'un jour quelqu'un a ajouté des infos de cette source 
sur cet objet... et l'opendata via osmose ne contient à ma connaissance 
pas de addr:street, c'est plutot le nom de l'établisement et 
éventuelement une ref

donc corrige à ton aise et vire cette source qui ne veux rien dire
sur un objet multi-source



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

Re: [OSM-talk-fr] Encore une question sur les noms de rues

[Marc_marc]

Le 10.06.23 à 15:29, Daniel Garcia a écrit :

Est-ce que FANTOIR est forcément juste, dans ce cas ?


ho non hélas

ce que tu pourrais faire dans un premier temps, c'est mettre la 
ref:FR:FANTOIR sur l'objet, cela permetttra de lier le nom version osm 
au nom version FAANTOIR




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

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc_marc]

Bonjour,

Le 09.06.23 à 11:03, Patchi Atwork a écrit :
Etant un des 2 opposants dans cette médiation 
je précise tout de suite que bien entendu mon opinion 
n’est pas neutre.


elle est justement d'autant plus interessante à lire :)


éventuellement  public_transport=stop_position sur la route
éventuellement  une relation public_transport=stop_area


Pourquoi un « éventuellement » pour un public_transport=stop_position 
sur la route ? 


éventuelement est à lire dans le sens "rien n'oblige quelqu'un a créer 
un objet".. si tu fais un shop=* le nom me semble obligatoire.
Si tu ajoutes les portes d'un batiment, j'aurais tendance à dire 
"éventuelement ajoute le magasin du rez tant que tu y es"



Each stop is included with two elements (if available):


si disponible :) donc parfois il ne l'est pas et ce n'est pas
une erreur.

Plus haut dans la section Stop Position [1] de cette même proposition : 
public_transport=stop_position recommendation mandatory.


tu parles de 
https://wiki.openstreetmap.org/w/index.php?oldid=1550843#Stop_position ?

si oui pour faire un objet avec la position du véhicule en PTv2,
c'est évidement obligatoire de mettre le tag principal donc 
public_transport=stop_position

cela ne dit pas "interdit de créer un public_transport=plateform
sans aussi créer un public_transport=stop_position et interdit aussi
si vous ne créer pas le public_transport=stop_area"
c'est dans ce sens que j'utilise le "éventuelement", c'est un autre
objet.

on en déduit quoi finalement ? Pour moi (mais je peux me tromper)  
le PTv2 définit pour chaque arrêt 2 éléments :

·un public_transport=stop_position où le véhicule s’arrête (sur la voie)
·un public_transport=platform où les passagers attendent (à côté de la 
voie)


j'en déduis qu'il y a 2 éléments possibles... et si tu en ajoutes un,
tu as la majorité des infos (dans le sens les plus importante à mes
yeux... un chauffeur de bus trouvera sans doute plus importannt
le stop_position)
si tu ajoutes les 2, c'est parfaitement correct.
je comparerais cela à "si tu ajoutes un batiment sans porte,
le batiment n'est pas réelement complet mais l'existance du batiment
est une info qui se suffit à être elle-même"

Quant à la limpidité franchement on peut faire mieux. Voici quelques 
extraits de la page Wiki highway=bus_stop française [2] :

L'approche la plus courante consiste […]
Cette clef est largement utilisée […]


ce n'est effectivement pas des plus limpide. je vais relire.

Si on considère la définition « endroit  
où les passagers peuvent monter ou descendre d'un 
bus » cela semble plus logique de le mettre à l’endroit où s’arrête le 
véhicule (public_transport=stop_position).


ce serrait un peu tiré par les cheveux parce que le passager
ne monte pas sur la route, il monte dans un véhicule par la porte de 
droite dans un véhicule qui se trouve sur la bande la plus à droite

mais je comprend l'ambiguité que tu soulignes (ambiguité qu'il n'y
a pas dans la PTv2 approuvée).

Quant à la distance entre les deux tout dépend de l’arrêt mais parfois 
cette distance n’est pas négligeable. Voici un exemple dans le 
Vaucluse : 
il y dans ce cas au moins 20 mètres entre l’abri et l’avant du bus.


plus que la distance, mon critère est "est-ce ambigu ?"
si la position du bus est "la route la plus proche de l'arret"
et si la position d'attente correspondant à cet arrêt est "l'arrêt
le plus proche de la position du véhicule", perso je ne prends pas
souvent le temps de mettre stop_position
mais c'est que mon comportement. l'ajouter est parfaitement justement
et aucune raison de le supprimer si présent.

Il s’agit de la statistique pour le tag public_transport=stop_position 
[3] on trouve (à ce jour) 120 638 bus=yes (ce sont ces arrêts qui nous 
intéressent car il n’y a pas de malentendu avec les autres arrêts de 
transports en commun type tram ou train) dont 35 717 avec 
highway=bus_stop ce qui fait un taux de presque 30%.


dans ce sens là d'accord : stop_position est donc soit moins utilisé
soit moins bien utilisé et 35 717 objets au moins sont à corriger


en France  (j'allais dire "partout sauf peut-être en Allemagne),

Genève


je suis aussi activé de l'autre côté de la frontière
et la bonne pratique est identique à celle en France :
highway=bus_stop pubblic_transport=plateform à la position passager
je suis en contact régulier avec des contributeurs suisse de langue
allemande (par ex de la région de Zurich, et c'est pareil.

il n'y a pas de tag PTv1 ni PTV2 pour faire 
la  différence entre les 2 endroits passager selon qu'ils

faire  attentent ou  montent danss le bus)


Certes il n’y a pas de différenciation officielle entre l’endroit où les 
passagers attendent et où il montent/descendent dans le véhicule mais 
dans la mesure où ces 2 endroits ne sont pas identiques voire distants 
de plusieurs dizaines de mètres pourquoi ne pas vouloir faire la 
différence d’autant plus que le schéma PTv2 nous demande de le faire ? 


je ne comprend pas ce que tu veux dire : PTv2 a 

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc_marc]

Le 08.06.23 à 18:37, Erwan K a écrit :

Bonjour à tous,

Je synthétiserais de la manière suivante :

- Snusmumriken cartographie comme cela a été fait historiquement sur OSM,
donc assez simple à comprendre.


et pourtant la PTv2 est encore plus simple à comprendre puisque son tag
est identique pour tous les modes de transports (bus, tram, train, ...)
et tous les pays
là où justement la PTv1 était différente selon le mode (l'arrêt se met 
sur le rail pour les trains) et selon les pays (l'allemagne a longtemps

mis les bus_stop sur la route, contrairement à ailleurs.


comment cohabitent la PTv2 avec le taggage historique


quel est le soucis ?
en France (j'allais dire "partout sauf peut-être en Allemagne),
c'est très limpide/trivial : highway=bus_stop + 
public_transport=plateform à l'endroit où les passager attendent

éventuellement public_transport=stop_position sur la route
éventuellement une relation public_transport=stop_area
l'article de Noémie le décrit bien.


'Un arrêt de bus est un endroit où les passagers peuvent
monter ou descendre d'un bus' mais aussi 'là où les passagers attendent',


c'est quel page ?
la distance entre les 2 ne doit pas être bien grande :)


(également écrit que bus=yes remplace la clé highway=bus_stop).


ca par contre est très controversé (et à mes yeux totalement faux et 
illogique) et absent de la PTv2 approuvée

https://wiki.openstreetmap.org/w/index.php?oldid=1550843#Platform
certains se sont mis à ajouter ce tag d'accès (pourtant le bus ne roule 
pas sur la zone passager) parce que d'autres (mainteneur de rendu) ont
prétendu être incapable de faire un rendu sans savoir le mode de 
transport (pourtant fournit par la relation).

Depuis qu'il a été ajouté en masse via iD, le rendu n'a pas toujours
pas suivit.


En effet, highway=bus_stop montre un taux de combinaison de 80% avec
public_transport=platform. Mais dans l'autre sens, 30% des arrêts de bus 
au format PTv2 (bus=yes) 


ce n'est pas un arrêt de bus (au sens l'endroit des passagers),
donc stat erroné :)
stop_position décrit l'arrêt au sens véhicule
cettee information n'existant pas en PTv1, il y a 0% de "stop position 
PTv1" n'ayant pas le tag PTv2 :)
et bus=yes étant un tag d'accès, il est utilisé aussi pour d'autres 
chose (par ex 5000 highway=service)



ont la combinaison public_transport=stop_position avec highway=bus_stop, ce qui 
n'est pas négligeable non plus.


c'est/c'était la pratique courante en Allemagne de mettre l'arrêt
sur la route donc en combinaison avec "stop_position + bus=yes"


- Comment tagger lorsque l'endroit où les gens attendent le bus est
différent de là où les gens montent dans le bus ?


l'endroit où les gens attendent : public_transport=plateform + 
highway=bus_stop

l'endroit oü les gens montent dans le bus : le véhicule
s'arretant à public_transport=stop_position, les gens sont
à cet endroit là à ce moment là... je pense pas très
utile de mettre un objet pour redire qu'on monte dans le bus
à l'endroit oü il est (et il n'y a pas de tag PTv1 ni PTV2 pour
faire la différence entre les 2 endroits passager selon qu'ils
attentent ou montent danss le bus)


- Clarification du wiki FR sur la signification précise de highway=bus_stop
et comment les tags PTv2 remplacent les tags historiques (ou pas).


sur quelle page ce n'est pas clair ?
ils ont à mon avis vocation à remplacer vu la simplification que cela 
apporte... mais tant qu'il n'y aura pas de rendu, c'est vain de croire

que les gens ne vont pas ajouter le tag rendu


- Dans le futur, comment vont cohabiter les tags PTv2 et le taggage
historique ? Lequel des deux standards prendra le pas sur l'autre à terme ?


oeuf et la poule : on voit bien que PTv2 est adopté même sans rendu
mais le rendu principal a comme politique d'immobilité de ne pas rendre
un tag moins courant qu'un autre.. donc suffira d'un objet PTv1 sans 
PTv2 pour maintenir l'immobilisme



Ou faut-il un double taggage même si ce n'est pas une très bonne solution ?
(voir ici :
https://wiki.openstreetmap.org/wiki/Proposal:Refined_Public_Transport#Rationale
  > "it made mappers put nodes both on tracks and beside them", mais je n'ai
pas de chiffre par contre)


la proposition est viciée dans son constat initial :
PTv2 a créé stop_position parce que justement c'est pas tjs possible
de le deviner automatiquement (perso je ne le crée que dans ce cas là)
ou c'est l'objet principal pour les trains... donc dire qu'on
va supprimer l'objet principal des trains pour faire plus simple,
c'est assez tordu.
tag en doublon : il n'y a aucune obligation en PTv2 de créer 2 objets 
(passager+véhicule) ni même de mettre les tags sur les 2 (la tendance
est plutôt en France et ailleurs de les mettre uniquement sur 
public_transport=plateform... assez logique car les autres infos tel

que la présence d'une poubelle ou d'un panneau d'affichage concerne
le passager, pas le véhicule

pour moi les vrais soucis du PTv2 actuels sont :
- pas de rendu (et pas de rendu non plus du bus sur une surface)

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc_marc]

Bonjour,

Le 05.06.23 à 13:33, Yannick a écrit :

Une plate-forme a obligatoirement un arrêt mais l'inverse est faux


tout a fait, hélas il y a une confusion entre le tag et ce qu'il décrit
public_transport=plateform ne décrit pas un arrêt avec une plateforme
il décrit l'endroit oü le passager attend pour monter dans le véhicule,
qu'il y ai ou non une plateforme.

on aurait été bien inspiré d'appeller cela 
public_transport=passenger_position par analogie avec 
stop_position/vehicule_position ou un truc du genre

je crains que c'est quasi impossible à rectifier,
sauf à améliorer la doc si besoin

Cordialement,
Marc



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

Re: [OSM-talk-fr] problème avec recherche sur la carte osm à Tomba kanssa, Guinée

[Marc_marc]

Le 05.06.23 à 12:41, leni a écrit :

Bonjour

Je me permet de relayer sur la liste un problème signalé sur le forum 
(https://forum.openstreetmap.fr/t/localisation-incorrect/15249/1) que 
Berete_Baba n'arrive pas à résoudre en Guinée : problème de Nominatim ou 
de manque d'attributs ou d'objets ?


un exemple de soucis :
https://www.openstreetmap.org/search?whereami=1=11.7286%2C-10.1870#map=15/11.7252/-10.1885
dans la zone de residential de Tomba kanssa mais la réponse
est celle de Tomba doula, un village plus loin
https://www.openstreetmap.org/node/3065712332

j'ai vu au moins 2 problèmes de données :

le WP qui devrait être en français vu que c'est la langue officielle
et non l'anglais (mais sans rapport avec ce problème)

l'admin_level : selon la page wiki [1] les sous-préfectures
sont au niveau 8 comme les communes (étrange choix,
cela aurait pu être mis en niveau 7)
du coup mettre le village en niveau 10 pourrait aider

[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_Guinea#Admin_Levels_in_Guinea


Cordialement,
Marc



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

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc_marc]

Bonjour,

Le 05.06.23 à 12:52, Erwan K a écrit :

Concernant l'habitude en France de mettre highway=bus_stop /
public_transport=platform, est-ce définit ou écrit quelque part par hasard
(cela aiderait beaucoup je pense) ?


c'est pas écrit noir sur blanc mais indirectement
https://wiki.openstreetmap.org/wiki/FR%3ATag%3Ahighway%3Dbus_stop#Cartographier
L'approche la plus courante consiste à placer les arrêts de bus à 
l'écart de la voie dont il dépend, c'est-à-dire avec un point ne faisant 
pas partie de la voie


et aussi les stats montrant un taux de combinaison de 80% en France
https://taginfo.openstreetmap.fr/tags/highway=bus_stop#combinations
contre environ 16% qui ont une autre valeur et 4% qui n'en ont pas
ou qui ont 2 objets (lorsque le contributeur a fait un highway=buus_stop 
sur un noeud et un public_transport=plateform sur une ligne dont fait

partie ce noeud, pas très conseillé vu que cela fait 2 objets
pour un arrêt logique, mais lié au non rendu de highway=bus_stop
sur une ligne)

Cordialement,
Marc



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

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc_marc]

Bonjour Frederik,

Le 05.06.23 à 01:21, Frederik Ramm a écrit :
Patchi insists to be "highway=platform" and Snusmumriken wants 
"highway=bus_stop": https://www.openstreetmap.org/node/277447606/history


sur le fond, l'habitude en France est de mettre highway=bus_stop
avec public_transport=platform (comme c'était le cas à la version #14) 
et non pas au milieu de la route.

ceci dit, il faut évidement que la guerre d'édition s'arrête.

Cordialement,
Marc



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

Re: [OSM-talk-fr] Utilisation (ou pas) des données du "catalogue des sculptures des jardins de Versailles et Trianon"

[Marc_marc]

Le 24.05.23 à 22:40, Christian Perrier a écrit :

"Archimole, dit aussi Morphée"


c'est un nom ? j'ai l'impression que c'est 2 noms



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

Re: [OSM-talk-fr] Utilisation (ou pas) des données du "catalogue des sculptures des jardins de Versailles et Trianon"

[Marc_marc]

Bonjour,

Le 24.05.23 à 13:32, Christian Perrier a écrit :

la licence de cette source d'information n'est pas, pour moi, totalement claire.
La seule info que je trouve sur le site est
https://sculptures-jardins.chateauversailles.fr/infos/legal.php


Ce qui est clair, c'est qu'il n'y a pas de licence te permetant
de copier leur base pour l'injecter dans osm :)
après le socis c'est la notion de base de donnée :
- si tu recopies le numéro de téléphone d'un restaurant depuis son site, 
c'est clairement pas unne copie d'un (extrait de) base,

et donc peu importe leur condition générale, tu as le droit
de recopier le numéro que tu as lu (ouf)
- si tu copies l'annuaire, c'est clairement une copie de base,
impossible sans licence excplicite et compatible.

j'aime bien l'idée de se constituer un "source=local knowledge"
permettant de contribuer ainsi à osm.
j'ai cependant du mal à croire que quelqu'un puisse
rapidement avoir la connaissance des statues du parc
s'il ne l'avait pas avant.
ce serrait plutôt un moyen pour faire contribuer
les guides du parc ou quelqu'un passionné depuis
longtemps par le sujet.

perso je demanderai une autorisation au chateau, quitte
à bien brosser dans le sens du poil pour montrer l'avantage
qu'ils ont à faire connaitre leur patrimoine-
si c'est si proche de toi, rajouter un wikidata aux éléments
permet d'avoir une notification "wikidata sans photo"
dans l'application (wikipedia) Commons, ce qui permettra
à son tour d'enrichir facilement osm avec ces photos.
hélas je n'ai pas encore trouvé de méthode pratique
pour créer des wikidata en masse, maix peut-être ceux-ci
existent-ils déjà sur les éléments majeurs du patrimoine.

Cordialement,
Marc



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

Re: [OSM-talk-fr] Noms des rues : qui a raison ?

[Marc_marc]

Bonjour,

Le 24.05.23 à 10:51, Daniel Garcia a écrit :
En regardant l'historique sur JOSM, je vois que le nom était le bon 
jusqu'à 2016, puis quelqu'un l'a changé, et depuis, il est resté "faux". 
C'est marqué comme source "survey; cadastre"


cela pourrait être une bonne chose de demander à ce contributeur
https://www.openstreetmap.org/changeset/39919440
s'il a vu un panneau "Rue de Corbeville"


(avant c'était "survey +  osmose")


la notion de source est parfois mal comprise :s
osmose est un outil qualité, il donne des pistes de réflexion,
ce n'est pas une source.

Je ne sais pas comment chercher efficacement la source "officielle"  
des noms.


le terrain et le conseil communal


Est-ce qu'il y a d'autres sources ?


l'existance d'adresse avec ce nom est une piste pour croiser les sources
à ce sujet,
ce qui a d'étrange c'est que pigomètre trouve un Chemin de Corbeville
là http://www.openstreetmap.org/#map=18/48.709365/2.19229
https://bano.openstreetmap.fr/pifometre/index.html#insee=91471=1
Perso je ne le vois pas, j'ai besoin de lunette :)

En plus, je croyais naïvement qu'il y avait une sorte de vérification 
(semi-)automatique des informations, par exemple quand une nouvelle mise 
à jour via le cadastre est effectuée. Comment puis-je augmenter la 
fiabilité d'OSM, à part vérifier manuellement tous les noms de rues ?


- installer un flux RSS pour relecture des contributions dans son/ses 
zones de confort

- plus spécifiquement le pifomètre aide pour la qualité des adresses
(même si parfois au final, depuis son pc, on n'a la possibilité
que de mettre une ref fantoir dans un premier temps pour lier
les différentes variantes de noms, avant d'aller vérifier "qui a raison")

Cordialement,
Marc



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

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

[Marc_marc]

Bonjour,

Le 03.05.23 à 22:40, Bernard Lefrançois via Talk-fr a écrit :
je ne vois plus l'utilité de conserver ce crossing_ref qui ne correspond 
à aucune "ref" en vigueur chez nous


un passage piéton avec des lignes blanches peintes parallelement
au trotoir, je pense qu'on référence cela de manière non ambigue
par un zebre :)
je n'ai rien contrre qu'on l'abandonne, je signale juste
que crossing_ref=zebra n'est pas égal à crossing:markins=zebra
parce que cette dernière valeur ne représente qu'un des cas
possible de marquage zebré (cfr les autres cas dans taginfo fr)

une correspndance 1:1 aurait permit de virer un schéma
immédiatement au lieu de cohabiter avec un schéma supplémentaire
pendant des années.

Cordialement,
Marc



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

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

[Marc_marc]

Le 03.05.23 à 09:23, Philippe Verdy a écrit :

À ce sujet il semble que "crossing_ref=zebra" (et  plus généralement
"crossing_ref=*" ) soit maintenant déprécié et à remplacer par
"crossing:marking=zebra"


malheureusement ce n'est pas le cas (ni voté ni en pratique)
crossing_ref=zebra dit qu'il y a un zebra, peu importe
la sorte ce qui peux être selon les cas (tous existant
dans osm en France)

crossing:marking=zebra un zebra mono ligne mono couleur,
de loin le plus courant.
il aurait suffit d'inventer crossing:markings=zebra:simple
pour ce cas afin de garder crossing:markings=zebra
comme valeur générique, hélas cela n'a pas été le cas.

crossing:markings=zebra:double un zebra double rangée,
ce qui arrive occcasionalement sur les passages très large

crossing:markings=zebra:bicolour bicouleur (et sa variante
oubliée d'un zebra blanc "enrobé" dans un fond d'un autre couleur
(ce que j'ai vu était sur un revetement peint en rouge),
certainsn semblent utiliser surface;zebra pour cela

du coup les 2 vont coexister pendant longtemps ou
crossing:marking=zebra va perdre le sens voté
pour devenir une valeur générique.

perso je détail de la peinture m'interesse moins
c'est pourquoi je renseigne crossing_ref=zebra
et non crossing:markings=*
mais chacun son envie bien évidement.



___
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

[Marc_marc]

Bonjour,

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


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

quel est la suite probable de l'histoire ?

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

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

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

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

Cordialement,
Marc



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

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

[Marc_marc]

Bonjour,

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

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

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

Questions :

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


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


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


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


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


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


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


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



- assigner à chaque adresse une position cohérente


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


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


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


qui se base sur... 3 réponses


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

Cordialement,
Marc

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



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

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

[Marc_marc]

Bonjour,

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

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


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

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

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

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


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


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

Cordialement,
Marc



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

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

[Marc_marc]

Bonjour,

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

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

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

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

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

mais c'est une première tranche

Questions :

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

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

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

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

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

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


Cordialement,
Marc



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

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

[Marc_marc]

Le 24.04.23 à 10:46, Bruno Remy via Talk-fr a écrit :

les rajouter un par un avec ID en utilisant le calque BANO est long et 
fastidieux


il y a le site bano très très utile
https:/bano.openstreetmap.fr
non seulement il te propose les no addr:housenumber mais détecte aussi 
les noms de voies manquant ou ayant une différente dans leur nom.



https://www.openstreetmap.org/changeset/135219152
Un import à l'échelle d'une ville est-il considéré comme un import massif?


c'est un import :)
soit tu fais de l'intégration : vérifier la cohérence avec le nom de 
rue, vérifier la plausabilité de no (pas de gros tas avec plein de no

comme cela arrive de temps à autre, à l'échelle d'une ville,
c'est vite fait d'intégrer.
soit il faudrait suivre la procédure des imports et le soucis
est la qualité variable des données (les fameux tas de points
et les nom de voie)

j'avais lancé cette procédure il y a quelques mois, puis c'est
parti en discussion privée et cela n'a pas encore abouti.
je remet le sujet sur le haut de ma pille (que j'ai fortement
élagé récement)

Cordialement,
Marc



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

Re: [OSM-talk-fr] Formater les horaires d'ouvertures de POI - Avec l'aide de ChatGPT ?

[Marc_marc]

Bonjour,

Le 23.04.23 à 10:52, Erwan K a écrit :

je vérifie/compare visuellement toutes les infos qui sortent de ChatGPT
Ma question est donc, est-ce OK de contribuer ainsi ?
Est-ce considéré comme une modification automatisée ?


si tu vérifies une à une pour faire les corrections, c'est simplement 
une contribution à distance (on dit parfois de salon) et c'est ok

cela devient une modification automatisé ou mécanisé à partir du
moment oü tu appliques un correctif en aveugle et à ce moment
il faut l'accord de la communauté, ce qui implique de proposer
la logique de correction et l'étendue du territorie

David Faure avait aussi fait un outil d'aide à la correction
qui était assez blufant dans sa capacité à décoder des horaires,
y compris avec des bouts de français.
Je me demande si cela n'a pas été intégré dans osmose [1]
mais je n'en suis plus certain

[1] https://osmose.openstreetmap.fr

Cordialement,
Marc



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

[OSM-talk-fr] Fwd: Maintenance - 26 April 2023 00h-16h CEST 2x20min environ

[Marc_marc]

Bonjour,

pour les nocturnes, il y aura une maaintenance
affectant le site web osm.org, l'api et d'autres
services lié le 00h-16h 2x20min environ

Cordialement,
Marc
 Message transféré 
Sujet : [OSM-talk] Upcoming Maintenance - 26 April 2023
Date : Fri, 21 Apr 2023 10:55:20 +0100
De : Grant Slater 
Pour : Talk Openstreetmap , 
annou...@openstreetmap.org


Hi OpenStreetMap,

The OpenStreetMap.org website, API and some related services will be
unavailable for short periods between 00:00 CEST (GMT/UTC+2) and 06:00
CEST on Wednesday 26th April 2023 due to scheduled network
maintenance.

It is likely there may be 2 outages during the window which could last
up to 20mins.

Sorry for the short notice. Our ISP only recently notified us of the
upcoming maintenance.

Twitter announcement:
https://twitter.com/OSM_Tech/status/1649349339800633344
Follow us for updates.

Kind regards,

Grant
Part of OpenStreetMap Operations Team

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



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

[OSM-talk-fr] [édition mécanique] supprimer barrier=kerb sur highway=crossing en France

[Marc_marc]

Bonjour,

sur la liste talk, un utilisateur signale un problème avec barrier=kerb
après analyse, tant StreetComplete que iD ont dans le passé
ajouté erronément barrier=kerb sur les objets ayant l'attribut kerb=*
décrivant les caractéristiques d'un passage piéton highway=crossing
Les bugs sont entre temps corrigé dans les 2 éditeurs.

cela pose problème parce que cela donne décrit
qu'il y a une bordure à franchir sur la voie "véhicule".
c'est d'autant plus problématique avec kerb=raised
que je ne voudrais pas franchir à vélo :)

proposition : supprimer barrier=kerb sur les objets highway=crossing
en France

Avis ?

Cordialement,
Marc



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

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

[Marc_marc]

Le 20.04.23 à 17:03, Vincent de Château-Thierry a écrit :

Marc qui a voté sur le forum https://localhost, 
ben quoi faut fragmenter...


Je rebondis sur cette remarque (pique ?) de Marc au sujet du forum et de la 
fragmentation


ce n'est pas une pique, la vie est trop courte et le temps trop précieu 
que pour passer du temps à cela.

c'est une désolation de voir qu'on se tire une balle dans le pied
trop souvent.

quand je parle de fragmentation, je ne joue pas à qui à la plus grande 
(ce qui est évidement facile quand on spam à tout va, j'ai moi-même

un compte sur le forum qui me spam de "résumé des sujets" alors
que je ne m'y suis jamais inscrit, comportement digne des spammeurs pro)
ou du fait que le moi passé une entreprise me signalait qu'on leur
avait signé que cette liste oü j'écris en ce moment avait été fermé (!)

non je parle plutot du fait :
osmf a une liste de diffusion... osm-fr a la sienne
osmf avait un forum... osm-fr avait le sien
osmf a décidé de basculer sur discourse... osm-fr installe vite le sien
osmf a un canal de discussion irc bridgé sur Element... un groupuscule 
fait un 2ieme canal exactement identique

chacun dans son coin, ne surtout pas se regrouper.

pendant ce temps à l'avant dernier CA, l'asso se demande comment
faire pour sortir de la saturation des sysadmins. un exemple parmi 
d'autres :

le rendu humanitaire a ses maj cassé depuis... 6 mois !
non c'est pas une erreur de frappe, c'est en mois, pas en jours !
c'est un sysadmin osmf qui est venu le signaler parce qu'en interne
on est sous-eau.
on parle de faire appel à une entreprise externe pour gérer l'infra.

mais si on arretait ce concours de "il nous faut une copie
de ce que le monde a sans plusvalue ?"
est-ce que osm-be a un serveur de liste de diffusion ?
non ils utilisent celui d'osmf.
et un discourse ? non ils utilisent celui d'osmf
est-ce qu'ils ont 2 canaux Element ? non un
est-ce que bzh a une serveur de diffusion ? non c'est chez osmf
est-ce que la liste de transport internationale a son serveur ?
non c'est sur celui d'osmf
Si on se concentrait sur ajouter de la plusvalue au lieu
de dupliquer pour en avoir "un à soi" ?

en plus discourse est prévu pour fusionner l'interface web-email
pour un même contenu, bien plus malin que d'avoir des discussions
fragmentée entre 2 lieux sur 2 interfaces incompatibles.
mais pour cela il fallait laisser un peu de temps au temps,
rien ne pressait d'ajouter une interface web (que j'appelle
mickey-mouse non pas péjorativement mais parce que je trouve
que cela met la mise en forme devant le contenu) à ce qui existait.
du moins pas si en même temps on est sous-eau avec des
choses qui me semble, à mon avis, prioritaires.

il y a quelques jours je découvre une nouvelle appli...
qui demande elle aussi de traduire à nouveau les mêmes
clefs que plein d'autre applis... chaque appli se doit
d'avoir son propre transiflex, on va quand même pas
faire confiance à la traduction de kerb=* faite ailleurs,
faut tout recommencer encore et encore depuis 0.

demain je suis interviewé par des étudiants.
l'une des question : Comment cette situation peut être améliorée / 
renforcée dans deux ans. Avec quels moyens et pratiques ? (en lien
avec la question précédente Comment le citoyen (individu, entité privée 
ou publique) participe et contribue en 2023 à cette initiative ?),


cela me fait pennser à l'exemple que j'avais déjà posté du temps
de "cro" :
on a plein d'éditeurs dans tous les sens (ce qui est aussi une richesse)
et aucun n'est finit pour que l'entrepreneur référence son commerce
de manière éfficace, iD n'a pas d'éditeur d'horaire, osmmybiz
n'a pas accès à l'opendata, et plein d'autre sont relégé aux 
connaisseurs, invisible depuis osm.org qui ne renseigne que id/josm

même les règles de validation sont à dupliquer dans tous
les éditeurs, seul osmose partager une partie des règles avec josm.

je leur dit quoi ?
j'espère sincement que la commuanuté puisse un jour réalisé
qu'elle est elle-même son propre fossoyeur, trop oqp à
savoir si highway=track est une piste agricole ou autre chose,
trop oqp à courrir après avoir "la plus grosse" dans n'importe
quel domaine...

et pendant ce temps Ouverture parle d'une même voix
à ses utilisateurs de données...
ils ont même réussit, pour une entreprise américaine,
à normaliser height=* en mètre, c'est quand même plus facilement
utilisable que de laisser chaque utilisateur faire les conversions...
faite une utilisation de la hauteur des batiments pour rigoler...


inscrits (pour un total de 3000


tu compares des pommes et des poires
1) je ne suis pas inscrit mais je compte dans tes 3000
combien d'autres ont été inscrit contre leur volontée ?
2) si 1000 personnes s'inscrive sur le forum et meurent,
cela te fait +1000 dans tes stats.
sur la liste, ils vont se faire désincrire automatiquement
et cela fait +0
Je parle aussi des messages style "je ne sais pas mais je l'écris"
du forum ? ou "salut moi c'est Jean"
bref, la course au nombre... ce qui ne 

[OSM-talk-fr] rendu humanitaire KO

[Marc_marc]

Bonjour,

Suite é 3 problème simultanés :
- prooblème avec osmosis dans la récupérationn des diff pour mettre à 
jour la base

- saturation de l'espace disque du à une régresssion dans la gestion
des fichiers d'expiration
- problème réseau entre le serveur de rendu et la 2ieme base de donnée
de secours

le rendu humanitaire est en état dégradé :
- les tuiles existantes continuent d'êtrre disponible
- les nouvelles tuiles et les maj de tuiles existantes est 
temporairement arreté


https://github.com/osm-fr/infrastructure/issues/438

Cordialement,
Marc



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

Re: [OSM-talk-fr] traduction de "tag" en français dans JOSM

[Marc_marc]

Le 17.04.23 à 10:19, leni a écrit :

https://forum.openstreetmap.fr/t/traduction-de-tag-en-francais-dans-josm/14078
J'ai donc créé le sondage avec « Choix multiple à plusieurs tours » 


j'ai peur de comprendre...
la communauté fr mondiale utilise le terme attribut (au contraire
d'une partie des trauctions josm... un partie l'utilisant aussi)

et donc en ce moment la communauté fr-fr (ce qui n'est déjà qu'une 
partie de la communauté francophone mondiale) utilisant le forum

(ce qui n'est à nouveau qu'une partie de la communauté fr-fr) et
votant (à nouveau) va décider si elle utilise ou pas le meme terme
que les autres ?

si le choix est le même tant mieux
si le chhoix n'est pas le même, c'est quoi la suite ?
une locale fr-fr pour traduire ce terme autrement que les autres ?
ou plutot une locale fr-fr-forum ?
il y a un argument pour un autre choix autre que "ho moi j'aime
mieux un autre" ?

j'ai l'impresssion qu'on se tire une balle dans le pied

Marc qui a voté sur le forum https://localhost, ben quoi
faut fragmenter...



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

Re: [OSM-talk-fr] traduction de "tag" en français dans JOSM

[Marc_marc]

Le 10.04.23 à 14:22, Jean-Claude Repetto a écrit :

Un sentier ne peut pas être carrossable, contrairement au chemin.


tout a fait

mais regarde la description de highway=path
https://wiki.openstreetmap.org/wiki/FR%3ATag%3Ahighway%3Dpath
il te parle de chemin générique au lieu de sentier
en ajoutant en plus de la confusion en parlant
de la motorisation, hors
- c'est la largeur qui fait la différence (véhicule à essieu ou non)
- il est techniquement possible de faire de la moto sur un sentier
mais techniquement impossible d'y passer avec un attelage de cheveaux



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

Re: [OSM-talk-fr] traduction de "tag" en français dans JOSM

[Marc_marc]

Le 10.04.23 à 18:34, leni a écrit :

quand un mot n'est pas traduit sur JOSM, je vais 
d'abord chercher la traduction sur le wiki si elle existe


dans ce cas-ci elle existe :)
https://wiki.openstreetmap.org/w/index.php?title=FR:Tags

je sais que ce n'est pas à notre portée
mais je pense que ce serrait quand même utile
- soit de penser regarder sur le wiki et mettre les outils
en cohérence avec le wiki
- soit proposer à chaque fois aux devs de récupérer automatiquement
la traduction faite sur le wiki

Cordialement chocolaté :)
Marc



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

Re: [OSM-talk-fr] traduction de "tag" en français dans JOSM

[Marc_marc]

Bonjour,

Le 10.04.23 à 12:54, leni a écrit :
utiliser un seul terme pour "tag" 


attribut ?

c'est tout l'écosystème osm qui a ce soucis.
ce serrait quand même pratique que la traduction
des clefs se fasse une seule fois sur le wiki.
autre exemple du même soucis : chemin <> sentier

Cordialement,
Marc




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

Re: [OSM-talk-fr] JOSM version stable 18700 traduction du Journal des modification

[Marc_marc]

Le 03.04.23 à 18:47, leni a écrit :

JOSM vient de passer à la version stable 18700

Voici la traduction en français du Journal des modifications 


Merci Leni

quelqu'un comprend l'intéret du passage du plugin au core
pour la lecture d'un pbf ?
je vois une (micro) augmentation de la consomation mémoire
et +50% en cycle cpu
https://josm.openstreetmap.de/ticket/22603




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

Re: [OSM-talk-fr] 118 valeur de surface=* en français à traduire :)

[Marc_marc]

Le 04.04.23 à 00:02, Marc_marc a écrit :

- la voie contient des revêtements différent dans sa largeur.
je pense surtout à concrete:lanes
pour le moment il n'y a pas de moyen de renseigner proprement
le revêtement entre les bandes oü roulent les pneus gauches
et droites des véhicules à 4 roues. c'est un manque pour
les vélos cargos où le vélo roule fatalement au milieu.
j'ai vu des asphalt-grass-asphalt qui représente probablement
la même chose.


en cherchannt dans tagino, je viens de trouver surface:middle
https://wiki.openstreetmap.org/wiki/Key%3Asurface%3Amiddle

les 3 cas "connus" sont résoluble :)



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

Re: [OSM-talk-fr] 118 valeur de surface=* en français à traduire :)

[Marc_marc]

Bonsoir,

Le 03.04.23 à 21:06, George Kaplan a écrit :

on devrait éviter les valeurs multiples.
pour qui une valeur multiple serait utile ?


je vois 3 cas pour lequel cela arrive :

- le voie change de surface -> il faut améliorer/éviter les valeurs 
multiples en découpant le chemin à chaque changement de surface,

du moins si ces changements concernent une "certaine" distance

- la voie comportent plusieurs matériaux mélangés -> c'est souvent
un mauvais choix de valeur. exemple gravel;sand -> cela pourrait
être compacted (ou autre choix possible, c'est un exemple)

- la voie contient des revêtements différent dans sa largeur.
je pense surtout à concrete:lanes
pour le moment il n'y a pas de moyen de renseigner proprement
le revêtement entre les bandes oü roulent les pneus gauches
et droites des véhicules à 4 roues. c'est un manque pour
les vélos cargos où le vélo roule fatalement au milieu.
j'ai vu des asphalt-grass-asphalt qui représente probablement
la même chose.

si du monde est motivé, nous pourrions déjà diminuer
les 2 premiers cas puisqu'ils sont résoluble

Cordialement,
Marc



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

Re: [OSM-talk-fr] 118 valeur de surface=* en français à traduire :)

[Marc_marc]

Bonjour,

Le 28.03.23 à 23:57, Marc_marc a écrit :

j'ai finis par faire une liste de 118 valeurs en français
https://mensuel.framapad.org/p/osm-surface-a-traduire


Merci à tous ceux qui y ont participé
j'ai transmis à Mateusz
Je referrai une 2ieme passe quand son bot
sera passé corriger tout cela

Cordialement,
Marc



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

[OSM-talk-fr] 118 valeur de surface=* en français à traduire :)

[Marc_marc]

Bonjour,

Mateusz prépare un bot pour corriger des valeurs erronées
de surface au niveau monndial

au fil de la discussion sur la liste talk,
j'ai finis par faire une liste de 118 valeurs en français   
https://mensuel.framapad.org/p/osm-surface-a-traduire

aide bienvenue pour mettre à coté de chacun d'elle
la bonnne valeur en anglais :)
pour vous aider 
https://wiki.openstreetmap.org/wiki/Template:FR:Map_Features:surface


évidement certains valeur sont à ce point précise
que j'ignore un peu ce qu'on va en faire...
genre gazon ras... qui n'est p'tre plus ras entre temps...
sauf si c'est un golf ou un endroit de prestige

Cordialement,
Marc



___
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

[Marc_marc]

Bonjour,

Le 15.03.23 à 09:56, Volker Schmidt a écrit :

C'est un tag fréquent: taginfo 200k
Pourquoi l'éliminer en France ?


parce qu'il est déprécié, incohérent
et que la valeur cohérente "no" (974k)
est 5x plus courante.

il n'y avait que StreetComplete qui avait
un preset et cela a été corrigé en 2021
pour faire comme les autres éditeurs
https://github.com/streetcomplete/StreetComplete/pull/3194/commits/32e9531c40da13fdc82156d3b5d77e3edbd39bfd

migrer les tags dépréciés en un seul schéma
cohérent rend les données plus facile tant
pour la contribution que pour l'utilisation

Je proposerai dans quelques temps la même chose
au niveau mondial, mais on a l'habitude d'avancer
plus vite ici, car c'est parfois lent au niveau mondial

Cordialement,
Marc



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

[OSM-talk-fr] [édition mécanique] sidewalk=none -> sidewalk=no en France

[Marc_marc]

Bonjour,

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

cette modification est cohérente avec le wiki,
les habitudes d'osm (=no pour l'absence)
et les préset de josm (iD n'a pas de preset
à ce sujet et ne fait que fournir les valeurs
de taginfo si on ajoute le tag à la main)

Avis ?

Cordialement,
Marc



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

Re: [OSM-talk-fr] Mapbox contribute ?

[Marc_marc]

Le 13.03.23 à 14:42, Sergey Beliamei via Talk-fr a écrit :

Les POI cliquables visibles sur la carte ne sont pas extraits de l'OSM.
Mapbox utilise une variété de sources pour maintenir 
les points d'intérêt à jour.


dans ma zone de confort, mapbox a quelques POI supplémentaires
par rapport à osm, mais ils sont soit faux (commerce fermé)
soit douteux (des noms de personnes sans aucune information
de profession ni téléphone/web et inconnu des annuaires)

je pense que cela démontre qu'osm est entrain de dépasser
de plus en plus de base de données propriétaires.
il ne vous reste plus qu'à autoriser osm à utiliser vos données
pour contribuer à osm, comme cela vous pourriez abandonner
votre base propriétaire peu à jour et peu précise :)

Mais j'avoue que c'est peu intuitif : en cliquant sur contribuer
sur votre site, on ne s'attend pas à contribuer à une base propriétaire.
et cela n'a à mon avis aucun intérêt pour un contributeur
OpenStreetMap de contribuer à une base propriétaire



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

[OSM-talk-fr] comment aider ?

[Marc_marc]

Bonjour,

en aidant les utilisateurs, je recois de temps à autre
une demande en retour "comment aider ?" de la part
de personne relativement loin du "coeur" d'osm,
souvent des personnes créateurs d'une umap

je me demande s'il ne serrait pas utile de faire
une page décrivant les aides possibles
- adhérer à osm.org (la page en français
mériterait une mise à jour
https://wiki.openstreetmap.org/wiki/FR:Fondation )
- contribuer aux données
- utiliser les données (routage, ...)
- faire connaitre

ou bien est-ce que vous renseignez l'url
principale du wiki ?
https://wiki.openstreetmap.org/wiki/FR:Page_principale

Cordialement,
Marc



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

Re: [OSM-talk-fr] Sculpture d'enfant sur passage piéton

[Marc_marc]

Bonsoirr,

Le 22.02.23 à 19:34, Lionel Allorge a écrit :

https://www.ville-lesquin.fr/actualites/vie-locale/zoe-et-arthur/

Faut-il les noter sur OSM 


rien n'est obligatoire à renseigner dans osm :)


et si oui comment ?


tourism=artwork
artwork_subject=child
artwork_type=statue ?

Cordialement,
Marc



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

Re: [OSM-talk-fr] panne 18/02 umap.openstreetmap.fr

[Marc_marc]

Les données d'avant panne ont été remise en place

Le 19.02.23 à 21:06, Marc_marc a écrit :

Bonjour,
hier un serveur du cluster hébergeant umap.openstreet.fr a connu
une défaillance, le service a été migré, normalement les données
sont synchronisée entre les serveurs avec une maj inférieur à 2h
cependant les différents messages montrent qu'il y a un quelque
chose de non prévu et que les donnes ont quelques jours de retard
au moins
j'ai transmis à la personne ayant fait l'opération pour voir ce
qu'il est possible de faire
Cordiaalement,
Marc





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

[OSM-talk-fr] panne 18/02 umap.openstreetmap.fr

[Marc_marc]

Bonjour,
hier un serveur du cluster hébergeant umap.openstreet.fr a connu
une défaillance, le service a été migré, normalement les données
sont synchronisée entre les serveurs avec une maj inférieur à 2h
cependant les différents messages montrent qu'il y a un quelque
chose de non prévu et que les donnes ont quelques jours de retard
au moins
j'ai transmis à la personne ayant fait l'opération pour voir ce
qu'il est possible de faire
Cordiaalement,
Marc



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

Re: [OSM-talk-fr] Comment mapper/taguer des cabinets médicaux/avocats/etc

[Marc_marc]

Bonjour,

Le 18.02.23 à 09:41, Daniel Garcia a écrit :

3. Que je n'aie pas besoin de rentrer physiquement dans chaque cabinet
médical de la ville pour savoir comment il est structuré à l'intérieur.


le plus pratique que j'ai trouvé est de se baser sur le telephone :
si le no de téléphonique est commun, je considère que c'est un cabinet
avec plusieurs praticien, ce qui je renseigne avec un objet (comme une 
clinique ou un hopital) même si évidement celui qui le souhaite pourrait

faire de l'indoor plus précis
si le no de téléphone est différent, je considère que c'est comme
un batiment avec difféérentes société et je fais un objet par praticien
oui le rendu ne pourra pas faire tout apparaitre, mais je ne vois
pas quoi faire de mieux


points un peu "au pif",


je les aligne de façon artificielle, cela montre bien que c'est pas
la position indoor, cela aide aussi le rendu à en faire apparaitre
plus qu'un


avocats, je ne sais même pas s'il existe un tel tag.


office=lawyer lawyer=barrister

Cordialement,
Marc



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

Re: [OSM-talk-fr] Mapbox mapping activity

[Marc_marc]

Bonjour,

Le 14.02.23 à 21:06, Sergey Beliamei via Talk-fr a écrit :

https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/missing_roundabouts_France



des informations locales qui, selon vous, nous aideront à
mieux comprendre les données.


merci d'avoir présenté l'opération avec une traduction en français :)

Sur la pge wiki vous parlez des couches d'imageries sat
Satellite Imagery: Bing, Maxar, Esri 


En France, la couche la plus récente et de meilleur qualité
est souvent la BD Ortho, disponible dans iD

attention à l'existance rare de junction=circular
qu'il faut  transformer en junction=roundabout
uniquement si vous avez une image "street level"
avec un panneau giratoire ou la présence des triangles
de priorités sur toutes les entrées

Cordialement,
Marc



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

Re: [OSM-talk-fr] Comment tagguer une façade "rescapée" ?

[Marc_marc]

Bonjour,

Le 15.02.23 à 11:28, pepilepi...@ovh.fr a écrit :

Quand un immeuble est détruit


si c'est détruit, il n'y a plus vraiement d'immeuble
et il ne devrait plus y avoir de building=* (si tu comptes
le nombre de batiment dans cette rue, tu le comptes ou pas ?)
et donc éviter le trollotag (le 2ieme tag qui contredit le premier)
avec ruins:building=yes

https://wiki.openstreetmap.org/wiki/Trolltag

Cordialement,
Marc



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

Re: [OSM-talk-fr] Sticker "fauteuil roulant" sur commerce et tag wheelchair

[Marc_marc]

Bonjourr,

Le 12.02.23 à 16:35, Daniel Garcia a écrit :

Sur deux commerces de mon centre-ville, qui ont chacun 2 bonnes marches
devant l'entrée (totalement inaccessibles en fauteuil roulant), j'ai vu un
sticker "fauteuil roulant" bleu à côté de l'entrée. Dans l'un des
commerces, il y avait un bouton en dessous, mais pas dans l'autre.


peut-être faut-il appeler


Je n'ai pas trouvé sur Internet à quoi exactement ça correspond


leur demander ? :)


je ne vois pas comment ça aiderait quelqu'un en fauteuil roulant à y accéder
(j'ai déjà vu des stickers/boutons similaires dans des agences bancaires,
mais elles avaient un dénivelé moins important et une partie métallisée
indiquant la présence d'une rampe amovible).


même sans partie métallisée fixe, il est possible d'installer une rampe
sur les marches... mais 2 marches, cela fait généralement une bonne 
pente et j'espère que le commerçant a de bons muscles :)



Sur https://wiki.openstreetmap.org/wiki/FR:Key:wheelchair j'ai l'impression
que cela pourrait correspondre à "wheelchair=designated", mais je n'en suis
pas sûr. Quelqu'un aurait plus de connaissances sur le sujet ?


hum je trouve pas.
"designated_" signifie que cela a été conçu pour cela (par exemple une 
rampe en U pour avoir une + grande longueur et donc une pente plus faible.

ici de ce que tu décris il n'y a rien de conçu spécifiquement,
c'est même tout le contraire puisque tu doutes de l'accessibilité.

si tu souhaites ajouter une donnée, je pense que wheelchair=yes
sur le poi avec source=local knwoledge sur le changeset :
le POI se dit comme étant accessible, tu rapportes l'info
de quelqu'un, sans l'avoir vu (l'accessibilité) sur place.

il serrait à mon avis utile d'ajouter wheelchair:description=présence 
d'un sticker fauteuil roulant bleu et/ou bouton d'appel

l'utilisateur a ainsi les infos (lui connaît sans doute) pour
choisir en connaissance de cause la fiabilité de cette affirmation

Cordialement,
Marc



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

Re: [OSM-talk-fr] Réseau spéléologique

[Marc_marc]

Bonjour,

Le 05.02.23 à 13:32, Eric SIBERT a écrit :

Vous tagueriez ça comment dans OSM? Une relation?


oui une relation site qui contient idéalement au moins les entrées.

les galleries si tu es très motivé :) c'est deja galère de faire le 
cheminement d'accès aux quais du métro :)


Cordialement,
Marc



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

Re: [OSM-talk-fr] Area pour trottoirs

[Marc_marc]

Bonjour,

Le 03.02.23 à 09:12, Zimmy ZIMMERMANN a écrit :

commune de référence sur les bonnes
pratiques en accessibilité.
https://www.openstreetmap.org/#map=19/44.13529/4.81083


S'auto-proclamer bonne pratique n'en est pas une !
highway=pedestrian est une rue piétonne
Mais un trottoir n'est pas une rue piétonne

donc si tu veux faire du surfacique, area:highway=path
ou même highway=path path=sidewalk area=yes
mais ce n'est pas fait parce que pas rendu.

Le choix d'Orange est donc tager quelque chose de faux
pour forcer un rendu, l'opposé de la bonne pratique !

Cordialement,
Marc



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

Re: [OSM-talk-fr] Area pour trottoirs

[Marc_marc]

Le 02.02.23 à 18:01, Lamourec Alain a écrit :

https://www.openstreetmap.org/#map=19/48.02902/-3.09202


lien direct vers l'un d'eux
https://www.openstreetmap.org/way/305281048#map


Pensez-vous que faire des area pour des trottoirs soit la bonne méthode ?


non


Sinon comment cartographier les trottoirs ?


le soucis c'est qu'il n'y a pour l'instant pas réelement de bon schéma
il y a :
1) highway=pedestrian area=yes mais un trottoir n'est pas une rue 
piétonne ne fusse que par sa largueur (routage des véhicules d'urgence 
par ex)
c'est selon moi typiquement un taag pour le rendu (seul valeur de 
highway=* qui soie rendu en surfacique pour une raison qui m'échappe)

en plus il est très compliqué de connecter cette surface à tout
ce qui doit l'être (même dans la commune française championne
de ce tag pour le rendu, le routage sur ces surfaces échouait
souvent vers les entrées des batiments)

2) highway=residential (ou autre) + sidewalk=left/right/both
assez bon pour le routage mais non rendu sauf 
https://map.atownsend.org.uk/maps/map/map.html#21/51.50368/-0.10454


3) highway=residential (ou autre) + sidewalk=separated + highway=path 
path=sidewalk rendu mais cassse le routage hors des passages piétons : 
dans de nombreux pays, il est permit

de traverser n'importe tout si on est à plus de X mètres
d'un passage piéton, cette info est impossible à représenter
avec le schéma actuel

4) un mix des 2 :
utiliser highway=residential + sidewalk=left/right/both
pour les tronçons entre 2 passages piéton
utiliser highway=residential + sidewalk=separated + highway=path 
path=sidewalk pour le cheminement entre les passages piétons

d'un carrrefour
C'est ce que j'utilise pour l'instant à défaut de mieux

Cordialement,
Marc




___
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

[Marc_marc]

Bonjourr,

Le 22.01.23 à 20:32, Daniel Garcia a écrit :

il faut en discuter quelque part ?


c'est ce que tu fais ici :)
ta modification me semble pertinante.
Mais de mémoire Nominatim ne lit pas cette page fréquement,
il faudra peut-être ouvrir un ticket pour prise en compte de la modif.

Cordialement,
Marc



___
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 ?

[Marc_marc]

Bonjour,

Le 07.01.23 à 23:51, osm.sanspourr...@spamgourmet.com a écrit :

https://en.wikipedia.org/wiki/Truck_apron


si l'anglais britanique n'a pas d'autre terme,
je trouve que cela n'a que des avantages d'utiliser
exactement le même terme, la seule vrai question
étant de oü se classera le rond-point "rétrécit à la peinture"

je verrais bien truck_apron=yes/no/hard/soft
à défaut apron=*
à voir donc les réactions pour la peinture.

Cordialement,
Marc



___
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 ?

[Marc_marc]

Le 07.01.23 à 07:42, lejun a écrit :
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


je partage ton vis : il n'y a rien de "crossing" dans cette spécificité,
on ne croise pas un autre cheminement



___
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 ?

[Marc_marc]

étant sur plusieurs pays, je ne suis plus certains si
le code de la route est le même partout :)

mais à 200m d'ici, il y a 2 ronds-point avec au centre une sculture
ensuite un cercle légèrement en pente
puis un cercle plat que 99% des gens utilisent
il n'y a aucune ligne blanche entre les 2 et ce ne sont
pas non plus 2 bandes de circulation mais une seule.

quand je vais tout droit, j'ai le choix entre
freinner fortement et utiliser le cercle à plat
ou rouler en partie sur la zone en pente, ce qui
permet de diminuer le gaspillage énérgétique freiner-accélérer

du coup je tagerais cela simplement avec width:carriageway
ou maxwidth:physical

Le 07.01.23 à 14:08, Volker Schmidt a écrit :

En GB, si je touche la ligne centrale du mini-roundabout j'échoue à
l'examen de conduite. Est que je vous comprends bien, vous dites ici qu'en
France il y un type de rond-point légalement attraversable?

On Sat, 7 Jan 2023, 12:18 Christian Rogel, 
wrote:


Le 7 janv. 2023 à 08:04, lejun  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.

Je rejoins ce point de vue, car il y a 3 grandes catégories de RP : avec
cercle central non franchissable, franchissables par tout véhicule,
franchissables par les poids-lourds, s’ils empiètent sur un anneau
spécifique que pourrait décrire « crossing_strip ».
Il reste d’autres cas à répertorier et classer. En ce moment, la mode est
la ligne en anneau continue qui réduit la surface carrossable.

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





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

Re: [OSM-talk-fr] problème avec mes envois

[Marc_marc]

Le 06.01.23 à 16:28, leni a écrit :

Bonjour et Bonne Année 2023

Avez-vous eu un problème  similaire ?


je n'ai pas vu tes 2 messages (ou alors Alzaimer)
je n'ai rien vu en anomalie (je recois copie des messages d'erreurs 
tordues que la liste revoit parfois)


Cordialement,
Marc



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

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

[Marc_marc]

Bonsoir,

Le 02.01.23 à 19:52, osm.sanspourr...@spamgourmet.com a écrit :

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).


un conteneur mais qui n'est pas un dispositif de recyclage
donc perso cela me semble plutôt être
amenity=waste_basket
waste=marine_litter

d'ailleurs l'url de la proposition parle elle aussi de déchet

Cordialement,
Marc




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

Re: [OSM-talk-fr] coupure de l'édition 22/01/2023 10:00 - 15:00 UTC

[Marc_marc]

2023 évidement

Le 24.12.22 à 00:17, Marc_marc a écrit :

Bonjour,

pour info : coupure de l'édition pour cause de maintenance le 22/01/2022 
10:00 - 15:00 UTC (rajoutez une heure pour l'heure Paris)

on essayera de se le rappeler la veille :)

Cordialement,
Marc
 Message transféré 
Sujet : [OSM-talk] Upcoming downtime on 2022-01-22
Date : Fri, 23 Dec 2022 12:11:05 -0800
De : Paul Norman 
Pour : t...@openstreetmap.org
Copie à : OSM dev 

Dear OpenStreetMappers,

On Sunday January 22nd 2022 between 10:00 and 15:00 UTC/GMT the API 
database servers will be unavailable due to maintenance. You can see 
this in your local time zone at 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStreetMap+API+Maintenance=20230122T10=%3A=6


We are planning to upgrade the software which runs the main 
OpenStreetMap database. Unfortunately, we cannot do this without some 
downtime.


The following services WILL be affected:

- www.openstreetmap.org web site WILL NOT allow edits,
- API will NOT allow map editing (using iD, JOSM, etc), and
- replication updates will be paused (minutely updates and changeset 
replication).


We expect that the database upgrade will not take the full duration, and 
we will try as far as possible to keep the API available in read-only 
mode, but the API may be briefly unavailable.


At times you may be unable to login to services which requires 
openstreetmap.org authentication (e.g. community, forum, and help)


Other OpenStreetMap provided services should not be affected except for 
login - all of the following are expected to function normally:


- Map viewing on www.openstreetmap.org
- nominatim (search)
- standard tile layer
- wiki
- taginfo
- mailing lists
- Distribution of planet file and existing diffs

Services not run by the OSMF will not be impacted, except there will be 
no updates from OSM.


Technical details are at 
https://github.com/openstreetmap/operations/issues/548



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





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

[OSM-talk-fr] coupure de l'édition 22/01/2022 10:00 - 15:00 UTC

[Marc_marc]

Bonjour,

pour info : coupure de l'édition pour cause de maintenance le 22/01/2022 
10:00 - 15:00 UTC (rajoutez une heure pour l'heure Paris)

on essayera de se le rappeler la veille :)

Cordialement,
Marc
 Message transféré 
Sujet : [OSM-talk] Upcoming downtime on 2022-01-22
Date : Fri, 23 Dec 2022 12:11:05 -0800
De : Paul Norman 
Pour : t...@openstreetmap.org
Copie à : OSM dev 

Dear OpenStreetMappers,

On Sunday January 22nd 2022 between 10:00 and 15:00 UTC/GMT the API 
database servers will be unavailable due to maintenance. You can see 
this in your local time zone at 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStreetMap+API+Maintenance=20230122T10=%3A=6


We are planning to upgrade the software which runs the main 
OpenStreetMap database. Unfortunately, we cannot do this without some 
downtime.


The following services WILL be affected:

- www.openstreetmap.org web site WILL NOT allow edits,
- API will NOT allow map editing (using iD, JOSM, etc), and
- replication updates will be paused (minutely updates and changeset 
replication).


We expect that the database upgrade will not take the full duration, and 
we will try as far as possible to keep the API available in read-only 
mode, but the API may be briefly unavailable.


At times you may be unable to login to services which requires 
openstreetmap.org authentication (e.g. community, forum, and help)


Other OpenStreetMap provided services should not be affected except for 
login - all of the following are expected to function normally:


- Map viewing on www.openstreetmap.org
- nominatim (search)
- standard tile layer
- wiki
- taginfo
- mailing lists
- Distribution of planet file and existing diffs

Services not run by the OSMF will not be impacted, except there will be 
no updates from OSM.


Technical details are at 
https://github.com/openstreetmap/operations/issues/548



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



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

Re: [OSM-talk-fr] le ver est dans la pomme ? alliance style AFAM pour un "osm validé" - overture

[Marc_marc]

réaction de l'osmf
https://blog.openstreetmap.org/2022/12/22/views-from-the-openstreetmap-foundation-on-the-launch-of-overture/
je le traduis sous peu

Le 16.12.22 à 06:38, Vincent Bergeot a écrit :

Bonjour,
ce qui m'intrigue le plus c'est :
- la double licence pour les contributions, permettant la privatisation des 
données depuis leurs outils (rapidID en est 1),
- et cela toujours avec son compte OSM car je suppose qu'il ne doit pas être 
compliqué de séparer les contributeurs autorisant le domaine public (si si la 
case à cocher autorisant le domaine public lors de la création d'un compte, 
effectif depuis X années),
https://wiki.osmfoundation.org/wiki/Licence_and_Legal_FAQ/Why_would_I_want_my_contributions_to_be_public_domain


Je ne suis pas juriste mais cela me donne l'impression que le compte osm peut 
servir à alimenter overture si l'outil utilisé le permet (rapidID de facebook 
est parait-il super (et je suis prêt à croire que quelques millions doivent 
aider à améliorer un logiciel) mais les données bientôt elles alimenteront 
seulement osm  humhum)

un peu en vrac, pas très cohérent peut être, mais belles discussions à venir






Le 15 décembre 2022 22:20:31 GMT+01:00, Georges Dutreix via Talk-fr 
 a écrit :

J'ai du mal à cerner ce qu'ils veulent faire, mais ça fait mal de voir la fondation linux 
avec "Amazon Web Services (AWS), Meta, Microsoft, and TomTom"



Le 15/12/2022 à 21:07, Marc_marc a écrit :

Bonjour,

lecture du jour :
https://www.linuxfoundation.org/press/linux-foundation-announces-overture-maps-foundation-to-build-interoperable-open-map-data

à force de ne jamais résoudre les incohérents landuse=grass et de ne pas traquer les 
erreurs de manière massive, j'ai l'impression qu'on va perdre le controle sur ce qu'est 
un bon schéma de donnée et sur ce qu'est "validé". les AAFAM décideront donc 
entre eux.

triste jour... même si cela augmentera l'utilisation des données osm (à mettre 
en corélation avec l'annonce par TomTom de sa migration vers osm)

votre 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



___
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 ver est dans la pomme ? alliance style AFAM pour un "osm validé"

[Marc_marc]

Le 16.12.22 à 08:57, Vincent Bergeot a écrit :
il ne doit pas être compliqué de séparer les contributeurs autorisant  
le domaine public


je pense que c'est quasi impossible
en effet tu fais un batiment sous OdBl, un gars rajoute la hauteur en 
domaine publique, un autre corrige l'espace manquant dans la valeur sous 
OdBl... tu as quoi au final sous domaine public ? une hauteur de 
batiment incorrect mais sans le batiment :)
est-ce que le batiment auraait été ajouté par le 2ieme contributeur dans 
le domaine public s'il n'était pas deja présent ? impossible à savoir
idem avec par ex le déplacement d'un noeud : le contributeur a-t-il 
validé les autres tags ou uniquement la possition ?


ce qui m'ennuie le plus dans cette histoire c'est les données externes 
(on le voit parfois avec umap) : certains entreprises ne sont plus

se compliqué la vie a intégrer leur donnée à osm puisqu'il suffit
de les mettre à ddisposition des AFAM pour que ceux-ci les utilisent
avec un "fond osm"



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

Re: [OSM-talk-fr] le ver est dans la pomme ? alliance style AFAM pour un "osm validé"

[Marc_marc]

Le 15.12.22 à 22:20, Georges Dutreix via Talk-fr a écrit :
J'ai du mal à cerner ce qu'ils veulent faire, mais ça fait mal de voir 
la fondation linux avec "Amazon Web Services (AWS), Meta, Microsoft, and 
TomTom"


j'imagine (comme d'autres entreprise) qu'il veuvlent :
- aavoir une version oü les grosses modifs sont validées avant d'être 
epoussée vers les prograammes qui les utilisent (la sncf le fafit deja 
avec une vvalidaation des modifs faite dans leur gare)

- avoir un schéma plus cohérent (parce que la feuille de style par
exemple pour les surface au sol est totalement fantaisiste/incohérennte
donc migrer des landuse=grass vers landcover=grass entraine une 
simplification de l'utilisation des données
- avoir une base quii authorise les imports plus facilement (c'est hélas 
un remaque de wikidata)





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

[OSM-talk-fr] le ver est dans la pomme ? alliance style AFAM pour un "osm validé"

[Marc_marc]

Bonjour,

lecture du jour :
https://www.linuxfoundation.org/press/linux-foundation-announces-overture-maps-foundation-to-build-interoperable-open-map-data

à force de ne jamais résoudre les incohérents landuse=grass et de ne pas 
traquer les erreurs de manière massive, j'ai l'impression qu'on va 
perdre le controle sur ce qu'est un bon schéma de donnée et sur ce 
qu'est "validé". les AAFAM décideront donc entre eux.


triste jour... même si cela augmentera l'utilisation des données osm (à 
mettre en corélation avec l'annonce par TomTom de sa migration vers osm)


votre avis ?

Cordialement,
Marc



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

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

[Marc_marc]

Le 14.12.22 à 14:45, Daniel Garcia a écrit :
Si vous connaissez mieux les développeurs, et vous pensez 
que ces bugs méritent d'être rapportés


je pense que tous les bugs méritent d'être reporté même si cela ne veux 
pas dire qu'ils serront résolu.
au moinss cela permet aux devs de voir les soucis et de choisir en 
connaissance de cause, cela permet aussi aux autres utilisateurs de 
confirmer que le bug qui les affecte esst connu




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

Re: [OSM-talk-fr] Photos pour Wheelmap ou OSM

[Marc_marc]

Bonjour,


On Sun, 11 Dec 2022, 17:21 Daniel Garcia,  wrote:

auriez-vous des recommandations sur quelle application utiliser,
ou comment les lier/"donner" à OSM ?


les 3 plus classiques :
. mapillary
avantage : très bien pour la prise de vue en "brut" (tu actives,
fait x km, tu arrêtes la prise de vue, upload et finit)
techniquement c'est aussi possible de prendre une photo après l'autre,
par exemple la vitrine puis la porte du magasin
est aussi utile à la contribution osm via osmose (détection de panneau 
et d'obbjets)

désavantage :
appartient aux Gafam (va savoir ce qu'ils font de ta geoloc...)
cliché haut-résolution non accessible à l'utilisateur final

- application commons (ou leur site web)
avantage :
meilleur confiance dans le respect de la vie privée
photo probablemennt mieux utilisable hors osm
avantage-désavantage :
il faut tager les photos avec des mots clefs, un titre etc
cela prend donc plus de temps tout en rendant les photos
plus utilisable
désavantage : pas adpaté à mon avis pour photographier une sortiee au 
rythem de 1 photo/sec


- Kartaviey (ex-OpenStreetCam)
un peu semblable à mapillary, le soucis du propriétaire en moins

PS: ce n'est pas interdit d'uploader sur 2-3 sites

Cordialement,
Marc



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

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

[Marc_marc]

Le 08.12.22 à 11:33, Daniel Garcia a écrit :
J'ai installé Wheelmap, mais de base le nom de la ville ne donne 
pas son adresse (on finit à Paris ; c'est dommage


par défaut il s'ouvre sur ta position
c'est pas le cas ? la localisation est permise ?



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

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

[Marc_marc]

Le 07.12.22 à 17:04, Daniel Garcia a écrit :

j'ai cherché "mediatheque"


Je pense qu'une bonne partie des problèmes pourrait être résolue 
en supprimant tout résultat qui ne soit pas dans la ville


c'est pour cela que je te proposais de faire mediatheque, ville :)
mais mediathèque n'est pas un bon exemple pour commencer vu l'absence de 
tag précis dans osm pour cela

fait des tests avec bibliothèque



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

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

[Marc_marc]

Le 07.12.22 à 14:09, Daniel Garcia a écrit :

Est-ce qu'il y a des solutions, peut-être payantes, pour aider à avoir plus
de précision dans les recherches textuelles ? Par exemple, en filtrant des
noms extérieurs à la ville et aux villes voisines ?


sur osm.org recherche : trucmuch, ville

si "médiathèque, ville" n'abouti pas, le soucis principal est le tag :s
il y a un dictionnaire (je ne sais plus si c'est sur le wiki ou le 
github de nominatim) qu'il suffira de completer pour lui faire le lien 
entre médiathèque et les tags osm


non testé sur osmand mais j'espère qu'ils ont la même chose
et sinon je veux bien leur faire un ticket pour leur proposer :)
mais je ne comprend pas exaactement le soucis que tu as :
une recherche médiatheque dans osm retournent des résultats triés
par distance, l'utilisateur souhaite une recherche éloignée de lui ?



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

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

[Marc_marc]

Le 07.12.22 à 14:04, Daniel Garcia a écrit :

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


le soucis n'est pas que le fond de carte, le soucis est également
les données : j'ai testé StreetCo dans une de mes zones de cartographie:
Streetco n'a aucune donnée alors qu'osm a l'acecessibilité de
la majorité des commerces et des portes d'entrées de batiments
recevant du public.
c'est le soucis dont je te parlais avec les bases propriétaires :
leur solution ne fonctionne que si des personnnes leur donnent
gratuitement les données qu'ils onnt besoin <> osm les mutualise
entre plusieurs utilisations
water-map par exemple utilise malheureusement un fond GoogleMap
mais les données viennent d'osm et sont donc mutualisées et libres



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

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

[Marc_marc]

Le 07.12.22 à 14:04, Daniel Garcia a écrit :

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.


si tu ajoutes wheelchair=limited (+wheelchair:description) sur une voie 
dont la pente est trop forte que pour être gravi seul en fauteil,

j'espère bien que les outils spécialisé le prennent en compte

les itinéraires vélos utilisent les courbes de niveaux,
p'tre que des outils PMR font de même (et sinon leur suggérer)

idéalement mettre des ele=* aux carrefours et en déduire incline=*
pourrait aussi être pris en compte, avec en plus le gain d'une 
personalisation selon ce que le critère de l'utilisateur




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

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

[Marc_marc]

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'est https://street-co.com/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

[Marc_marc]

Bonjour,

mes conseils :
- demander voir "exiger" que les données soie opendata
- plaidiyer pour qu'elle soie dans osm afin à la fois que le projet 
bénéficie des données osm existante et qu'osm bénéficie de "vos" données
- parler de la non résilience des données propriétaires (si la boite 
ferme, si le contrat n'est pas renouveler)
- je ne comprend pas ce que tu veux par "souhaite une solution sytle app 
wheelmap" : wheelmap a une app
- pour encoder des données d'accessibilité de base dans osm, 
StreetComplete sur Android est facile

- plaidoyer pour des données plus large que simplement l'accesibilité :
savoir qu'un commerce est accessible PMR c'est bien... mais si t'as
pas le nom ou un moyen de contact ou un horaire, c'est un peu limite.
l'utilisateur va devoir sortir de l'application pour les données 
manquantes (et croire qu'un projet axé accessibilité aura une 
contribution tel qu'elle va tout récolter, c'est un peu idéaliste)


Cordialement,
Marc

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

Bonjour,

J'ai eu enfin plus d'informations à propos de la solution que veut employer
ma ville. Apparemment c'est un partenariat avec Street-Co (
https://www.street-co.com/fr/).

N'ayant jamais entendu parler de cette société, et ne voyant aucune mention
à un fond de carte quelconque sur leur site (et il faut créer un login pour
faire la moindre action sur l'application), je me demande si quelqu'un en a
déjà entendu parler, et aurait des recommandations complémentaires à ma
demande d'octobre.

D'ailleurs, si quelqu'un ici aurait des connaissances capables de fournir à
une ville d'environ 20k habitants une solution du style Handimap ou une
version "app" de Wheelmap, j'aimerais le suggérer à la ville (j'ai des
connaissances qui participent à une commission citoyenne créée par la
mairie). Je crains toujours quand je vois une application d'une "startup"
où la seule action possible c'est "créez un login ou sortez d'ici".


On Sun, Oct 23, 2022 at 10:34 PM  wrote:


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<

osm.jlzimmerm...@gmail.com>

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 

Re: [OSM-talk-fr] Rue aux écoliers?

[Marc_marc]

Le 18.11.22 à 17:36, BEGUIN,Bruno a écrit :


Dans ma collectivité, de nombreuses rues aux 
écoliers sont déployées.
En gros ce sont des tronçons de rue rendus piétons seulement les matins et les 
soirs en semaine, hors vacances.
J'ai vu qu'à Bordeaux, ça s'appelle rue au enfants
Quelqu'un a une idée du taggage à employer ?



c'est courant en Belgique, voici un exemple trouvé
motor_vehicle:conditional = no @ (Mo-Th 08:15-09:00,15:30-16:15; We 
08:15-09:00,11:15-12:00; PH off; SH off)


le "off" ne me semble pas être la bonne syntaxe
peut-être plutot yes @ SH



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

Re: [OSM-talk-fr] BlaBlaCar exploite des données OSM sans attribution ?

[Marc_marc]

Le 12.11.22 à 10:24, Léo El Amri a écrit :
lors de la planification, le moteur de routage semble être celui de 
GMaps, avec les données de GMaps 
(https://www.dropbox.com/s/tgn38ux6vlrkyk3/?dl=0). Mais une fois le 
trajet planifié, le rendu du tracé ressemble aux données de OSM.


cela me donne l'impreession que la planification de l'itinéraire
utilise GM en ligne.
mais que cela bascule ensuite vers osm hors ligne

un petit email au support BlaBlaCar ? :)



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

[OSM-talk-fr] [édition mécanique] suppression tracks=1 en France

[Marc_marc]

Bonjour,

Suite à explication de Denis ci-dessous,
je propose l'édition de masse suivante :
suppression de detail=track sur tous les objets en France

Les objets ayant une autre valeur ne sont pas concernés.
si quelqu'un souhaite s'en occuper, avant ou après l'édition de masse, 
l'aide est bienvenue https://overpass-turbo.eu/s/1nCA


Cordialement,
Marc
 Message transféré 
Sujet : Re: [OSM-talk-fr] Fwd: [Tagging] Railway tagging: detail key
Date : Thu, 10 Nov 2022 11:06:12 +0100
De : Denis Helfer 
Répondre à : Discussions sur OSM en français 
Pour : talk-fr@openstreetmap.org

Bonjour,

Vieillerie à supprimer. A priori, toutes les lignes ferroviaires sont 
décrites à la voie.


A vos tromblons


Le 10/11/2022 à 10:05, blef via Talk-fr a écrit :

Bonjour,

L'ajout de ce tag semble provenir principalement de @Denis_Helfer 
<https://www.openstreetmap.org/user/Denis_Helfer>.

Le mieux serait sans doute de lui demander.


Le 09/11/2022 à 15:03, Marc_marc a écrit :

Bonjour,

un contributeur se demande la signification de la clef detail
plus particulièrement il se demande en quoi detail=track
est différent des façons plus courante de tager cela

quelqu'un a une idée ? cela a l'air d'être majoritairement utilisé
en France

Cordialement,
Marc
 Message transféré 
Sujet : [Tagging] Railway tagging: detail key
Date : Wed, 9 Nov 2022 09:59:41 +
De : Nathan Case 
Répondre à : Tag discussion, strategy and related tools 


Pour : tagg...@openstreetmap.org

Hi all,

I've noticed substantial use (99,297 instances) of the "detail" key, 
but it is undocumented on the Wiki.


Nearly all uses (99.96%) of this key are detail=track [1], which is 
associated with railways [2]. The key is predominantly used in France 
(77.6% of uses [3]) but also elsewhere across central Europe.


I have concerns about this key (it's ambiguous and perhaps redundant 
if all "correct" uses are for the same value) but, nevertheless, it 
would be good to document its usage if possible. I haven't found 
anything in the railway=*, railways, or OpenRailwayMap/Tagging 
documentation [4,5,6].


Does anybody know the background to this key, or what its intended 
values might be?


Many thanks,

Nathan


[1] https://taginfo.openstreetmap.org/keys/detail#values

[2] https://taginfo.openstreetmap.org/keys/detail#combinations

[3] https://overpass-turbo.eu/s/1nzc

[4] https://wiki.openstreetmap.org/wiki/Key:railway

[5] https://wiki.openstreetmap.org/wiki/Railways

[6] https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging



___
Tagging mailing list
tagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
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] Fwd: [Tagging] Railway tagging: detail key

[Marc_marc]

Merci Denis, je lance la prodécure d'édition de masse dans un message 
séparé pour plus de lisibilité


Le 10.11.22 à 11:06, Denis Helfer a écrit :

Bonjour,

Vieillerie à supprimer. A priori, toutes les lignes ferroviaires sont 
décrites à la voie.


A vos tromblons


Le 10/11/2022 à 10:05, blef via Talk-fr a écrit :

Bonjour,

L'ajout de ce tag semble provenir principalement de @Denis_Helfer 
<https://www.openstreetmap.org/user/Denis_Helfer>.

Le mieux serait sans doute de lui demander.


Le 09/11/2022 à 15:03, Marc_marc a écrit :

Bonjour,

un contributeur se demande la signification de la clef detail
plus particulièrement il se demande en quoi detail=track
est différent des façons plus courante de tager cela

quelqu'un a une idée ? cela a l'air d'être majoritairement utilisé
en France

Cordialement,
Marc
 Message transféré 
Sujet : [Tagging] Railway tagging: detail key
Date : Wed, 9 Nov 2022 09:59:41 +
De : Nathan Case 
Répondre à : Tag discussion, strategy and related tools 


Pour : tagg...@openstreetmap.org

Hi all,

I've noticed substantial use (99,297 instances) of the "detail" key, 
but it is undocumented on the Wiki.


Nearly all uses (99.96%) of this key are detail=track [1], which is 
associated with railways [2]. The key is predominantly used in France 
(77.6% of uses [3]) but also elsewhere across central Europe.


I have concerns about this key (it's ambiguous and perhaps redundant 
if all "correct" uses are for the same value) but, nevertheless, it 
would be good to document its usage if possible. I haven't found 
anything in the railway=*, railways, or OpenRailwayMap/Tagging 
documentation [4,5,6].


Does anybody know the background to this key, or what its intended 
values might be?


Many thanks,

Nathan


[1] https://taginfo.openstreetmap.org/keys/detail#values

[2] https://taginfo.openstreetmap.org/keys/detail#combinations

[3] https://overpass-turbo.eu/s/1nzc

[4] https://wiki.openstreetmap.org/wiki/Key:railway

[5] https://wiki.openstreetmap.org/wiki/Railways

[6] https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging



___
Tagging mailing list
tagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
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