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

[osm . sanspourriel]

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

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


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

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

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

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

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

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

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

[osm . sanspourriel]

Ceci est un bel exemple de mini-giratoire.

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

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

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

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

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

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

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

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

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

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

Christian R.

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

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

[osm . sanspourriel]

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

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

Les giratoires, ce sont les anneaux de circulation modernes avec
priorité à gauche.
Les ronds-points ce sont les anciens à priorité à droite (même si tu
peux encore trouver cette dénomination sur le terrain
).

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

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

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

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

franchissables par tout véhicule

C'est le cas /potentiellement/ des mini-giratoires, ils sont par nature
 franchissables,
d'où la discussion.

Mais attention l'article Article R110-2

du Code de la route précise :

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

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

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

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

Et au suivant
,
tu mangeras un peu la galette, c'est de saison.

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

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

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

[osm . sanspourriel]

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

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

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

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

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

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


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

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


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


Sauf que du coup je reviens sur le truck apron:

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

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

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

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

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

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

Quelqu'un peut trouver un nom commun en anglais ?

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

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

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

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

Quant aux détails on peut aussi envisager

apron=separate.

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

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

Et revenir ensuite pour plus de détails.

Jean-Yvon

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

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

|crossing_strip| - Bande franchissable (tablier pour camions)


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

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


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

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

[osm . sanspourriel]

Bonjour,

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

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

|crossing_strip| - Bande franchissable (tablier pour camions)

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

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

Résumé de la discussion :

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

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

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

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

(et est réservé au ponctuel)

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

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

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

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

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

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

Tantôt comme Mini giratoire

(carrefour suivant). Mapillary


En fait légalement

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

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

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

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

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

Des opinions ?

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

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

[osm . sanspourriel]

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

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

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

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

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

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

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

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

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

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

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

Jean-Yvon



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

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

[osm . sanspourriel]

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

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

J'ai mis :

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

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

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

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

Le plus simple :

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

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

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

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

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

Avec collecte sélective à côté :

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

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

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

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

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

On n'y met pas notamment :

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

Justification :

amenity=recycling
recycling_type=container

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

opening_hours=24/7

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

recycling:marine_litter=only

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

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

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

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

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

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

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

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

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

Jean-Yvon

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

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

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

amenity=waste_disposal

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


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

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

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

[osm . sanspourriel]

Bonjour,

Tu as peut-être raté cette information :

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

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

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

[osm . sanspourriel]

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


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


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

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

Jean-Yvon

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

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

[osm . sanspourriel]

Christian veut dire :

library:for=general public.

(sans accents).

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

Jean-Yvon

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

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

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

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

[osm . sanspourriel]

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


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


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

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

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

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

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

Bref entre personnes de bonne foi, ça passe.

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

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

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

[osm . sanspourriel]

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

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


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


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


Il y a d'autres,

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

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

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

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

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

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

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

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

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

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

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

Jean-Yvon


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


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

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

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

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


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

Volker
(Padoue, Italie)

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


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

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

en passant leur certificat ssl n'est pas/plus valable pour cette url
c'esthttps://street-co.com/fr/



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


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


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

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

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

[osm . sanspourriel]

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

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

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


Ça c'est facile :

lane = 1

;-)


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


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

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

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

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


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


De facto ou affichage dynamique ? Info accessible par TMC ?

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

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

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

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

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

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

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

[osm . sanspourriel]

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

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

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

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

Mieux que overtake = no

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

Jean-Yvon

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

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

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

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

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


Eric

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

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

[osm . sanspourriel]

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


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


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

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

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

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

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

Tu coupes

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

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

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

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

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

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

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

[osm . sanspourriel]

Seulement si la source de la vitesse est rural.

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

des notes/fixme quand le statut actuel est inconnu ?

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

Jean-Yvon

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

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

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

Bonne soirée

Eric

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

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

[osm . sanspourriel]

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

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

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


montre bien que

turn:lanes=none|none|slight_right

est correct.

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

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

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

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

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

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

Jean-Yvon


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

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

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


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

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


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

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

[osm . sanspourriel]

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


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

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

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

Elle est... classiquement mal mappée.

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

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

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

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

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

Oui

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

Oui, enfin non (voir ci-dessous)

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

Oui

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

Non (voir ci-dessous)

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

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

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

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

Marc Mongenet


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

Or :

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

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

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


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

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

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

Donc pourquoi pas mais il faudrait un exemple clair :

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

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

D'autres avis plus éclairés ?

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

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

[osm . sanspourriel]

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

lanes=2

turn:lanes=through|through;slight_right

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

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

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

110|110;90 serait incompréhensible.


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



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



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

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


Bonsoir,

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

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




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


+1

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


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

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

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

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

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


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

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

[osm . sanspourriel]

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

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


Bonsoir,

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

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




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


+1

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


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

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

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

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

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

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

[osm . sanspourriel]

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

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

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

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

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

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

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

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

Jean-Yvon

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

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



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


Le rendu français permet cela

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

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


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

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

Bonjour,

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

au

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

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

comme

source d'information.

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

pour

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

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

des

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

les

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

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

questions

que je me pose déjà :

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

un

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

certains

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

suggéré

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

les

informations d'accessibilité ?

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

une

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

budget

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

avoir

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

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

OpenStreetMap,

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

mappée,

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

mairie a

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

manquait

de

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

pas

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

veut

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

ou

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

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


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


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

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

[osm . sanspourriel]

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

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

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

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

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

> maxspeed:type

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

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

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



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

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

[osm . sanspourriel]

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


Bonjour,

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

- le tag "capital" pourrait être utilisé

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


Un coup de mou Marc ?

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


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

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


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

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

Jean-Yvon



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

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

[osm . sanspourriel]

Bonjour,

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

avec un lien c’est plus lisible :

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

> Pourquoi ne pas simplement supprimer le label?

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

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

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

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

CyclOSM : niveau 10 aussi

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

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

Jean-Yvon

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

Bonjour,

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

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

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




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

Re: [OSM-talk-fr] nommage dans un campus

[osm . sanspourriel]

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

[...]

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

peut-être plutôt local_ref ?

-Ralf.


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

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

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

Christian R.


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

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

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

ref:FR:FANTOIR:none=yes

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

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

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

Jean-Yvon



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

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

[osm . sanspourriel]

Bonjour,

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

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

En France par contre...

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

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

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

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

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

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

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

Jean-Yvon

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



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

Bonjour à tous,


Bonsoir,


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


La Bible :

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


Nicolas


Jacques




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

[OSM-talk-fr] nommage dans un campus

[osm . sanspourriel]

Bonjour,

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

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

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

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

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

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

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

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

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

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

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

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

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


   Après :

building
  yes

name 
Jean-François de La Pérouse

*Avant :*

building
  yes



   et

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


   Après :

name  Dyneco
office 
research

ref    514


   *Avant :*

addr:housename
   Dvneco
addr:housenumber

514



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

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

[osm . sanspourriel]

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

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

Paris celle de la France ? Métropolitaine ?

Jean-Yvon

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

Bonjour,

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

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


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

quelle source vas-tu utilisé pour cela ?

Cordialement,
Marc



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




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

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

[osm . sanspourriel]

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

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

Jean-Yvon

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

Bonjour

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

Françoise


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




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

[OSM-talk-fr] HTH

[osm . sanspourriel]

/hope this helps
/.

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

Jean-Yvon

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


HTH

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



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

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

[osm . sanspourriel]

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

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

JOSMID

P2




Anomalies



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

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

c'est comme pour l'Impasse des Vergers
.

Jean-Yvon

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

Bonjour

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

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

cordialement

leni


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




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

Re: [OSM-talk-fr] bano fantoir

[osm . sanspourriel]

Bonjour,

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

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

Et oui :

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

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

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

Jean-Yvon

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


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

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

[osm . sanspourriel]

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

Bonjour,

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

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


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

Cordialement,
Marc


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

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

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


Absent du wiki.

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

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

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

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

pourquoi ne pas encoder cette nuance dans son propre tag ?

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

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

Jean-Yvon



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

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

[osm . sanspourriel]

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


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


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


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

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

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


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

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

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


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

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

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

Notamment pour AERIEN, location=surface semble adapté.

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

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

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

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

Jean-Yvon



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

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

[osm . sanspourriel]

Bonjour,

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

il manque plusieurs points fondamentaux :

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

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

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

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

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

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

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

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

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

Jean-Yvon

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

Bonjour à tous,

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

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

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

A la prochaine !
StrMrp
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




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

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

[osm . sanspourriel]

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

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

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

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

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

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

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

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

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

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

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

Au fait David :

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

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

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

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

landuse=forest
leaf_cycle=deciduous
leaf_type=broadleaved

par exemple :

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

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

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

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

Jean-Yvon

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

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

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

Bonjour David,

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

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


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


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


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

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

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

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

[osm . sanspourriel]

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

Jean-Yvon

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

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

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


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






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

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

[osm . sanspourriel]

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

Jean-Yvon

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

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

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

Marc Mongenet

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


Bonjour,

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

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

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


Le plus logique serait un grand landuse=forest

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


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

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

Cordialement,
Marc



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


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




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

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

[osm . sanspourriel]

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

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


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


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

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

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

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

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

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

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

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

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

Jean-Yvon



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

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

[osm . sanspourriel]

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


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



Aux messagers précédents j'ajoute :

artwork_type =graffiti

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

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

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

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

Ici je ne sais si inscription=A bad place convient

Jean-Yvon



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

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

[osm . sanspourriel]

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


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



Aux messagers précédent j'ajoute :

artwork_type =graffiti

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

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

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

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

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

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

[osm . sanspourriel]

Merci Adrien.

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

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

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

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

Jean-Yvon

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

Bonjour,

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

Cordialement,

Adrien P.

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

Bonjour,

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

Merci !

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


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




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

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

[osm . sanspourriel]

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


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


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

No support for (Geo)TIFF

Jean-Yvon



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

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

[osm . sanspourriel]

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

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

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

Jean-Yvon

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


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



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



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

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

[osm . sanspourriel]

Bonjour,

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

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

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



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

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

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

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

Sauf que là ce serait plutôt

ruins:building=church

et

historic=church

Car le problème de building=ruins c'est que ça dénature la clé.

> précieusement préservés en l'état, mais ce n'est pas le sujet

Par exemple l'église dont le toit n'a pas été reconstruit mais les
tuiles pour protéger les murs ont été posés :

https://commons.wikimedia.org/wiki/File:France_NA_87_Oradour-sur-Glane_04.jpg

Donc des ruines entretenues. Je pense utile de faire la distinction.
historic=ruins ?

https://wiki.openstreetmap.org/wiki/Tag:historic%3Druins

La question est juste pour le bâti ordinaire devenu d'importance
historique par l'histoire.

La clé heritage doit pouvoir être ajoutée sur plusieurs bâtis. Donc
https://www.pop.culture.gouv.fr/notice/merimee/PA8742 mais c'est la
nouvelle église.

https://www.pop.culture.gouv.fr/notice/merimee/PA00100409

www.culture.gouv.fr/Wave/image/merimee/PDF/PA00100409_CMH_1946.pdf

En fait c'est tout le village qui est protégé en tant que tel et pas
chaque bâti.

Une question (ouverte) : Il y a un champ de foire et c'est :

https://www.openstreetmap.org/way/621736555/history (ou à peu près) mais
sans nom dans OSM.

or

https://www.openstreetmap.org/way/271765705/history à un nom faisant
croire que c'est l'actuelle Place du Champ de Foire. Je ne sais si c'est
à laisser ainsi.

Jean-Yvon

Le 19/08/2022 à 19:14, deuzeffe - opensm@deuzeffe.org a écrit :


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

Re: [OSM-talk-fr] historique des vues aériennes était : Vue aérienne Bing de meilleure résolution que l'Ortho HR

[osm . sanspourriel]

Bonjour, dans le droit fil des images qui peuvent être mieux ou moins
bien suivant les cas, je suis tombé sur Living Atlas.

Déjà une bonne info : devrait être intégrable sous peu à OSM SmartMenu.
Si vous voulez accélérer :
https://github.com/vannizhang/wayback/issues/68 (un volontaire pour un
PR en js pour utiliser un système plus classique zoom/lat/lon ?).

Déjà en cliquant on sait de quand date l'image et quelle est la source.

Permet de comparer différentes images côté à côte (avec un curseur),
animation (en excluant certaines images), téléchargement de gif animé...

Des candidats pour brancher les wms usuels d'Ortho HR pour faciliter le
travail de recherche de la meilleure image ?

Vu le système actuel (utilisation de BBox), je vous pointe sur un
endroit et vous pourrez vous déplacer avec la loupe pour choisir un endroit.

https://livingatlas.arcgis.com/wayback/#ext=-3.54559,47.76023,-3.51195,47.77549=true=16245=2

Oui l'endroit n'est pas pris par hasard. Outre que le coin est beau ;-)
il bouge vite : ici l'agrandissement du port au nord a modifié
l'écoulement en aval mais déjà sans... Dans d'autres endroits j'ai vu
des différences qui venaient de traitement différents sur les mêmes
images brutes.

Pour les parties stables on voit qu'une vue en hiver peut être mieux
qu'une vue plus récente en été.

Rien d'extraordinaire sauf que voyant les dates de prises de vue, on
peut déjà avoir une idée.

Le gif animé ou l'animation permet aussi de repérer les images possédant
des objets temporaires (ici carrousel et point de surveillance).

Jean-Yvon

P. S. : à votre avis, le bunker au sud, dans combien de temps il se
trouve au milieu du fleuve ?

Sur l'image de 2020, une belle baïne. Cette année là une personne avait
été récupérée (vivante) à 500 m du rivage. Respectez les panneaux
d'interdiction, ce n'est pas juste de la déco ! Oui dans OSM il y a des
swimming=no qui vont bien.

Le 04/08/2022 à 20:39, Jean-Yvon Landrac a écrit :

Bonjour,

version courte : varier les sources pour trouver la meilleure pour la
problématique donnée.



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

Re: [OSM-talk-fr] Une note qui fait partie d'une relation ?

[osm . sanspourriel]

Bonjour toutes et tous,

Oui, on ne va pas laisser des notes pour dire qu'il faut taguer
correctement ^^.

Jean-Yvon

Le 10/08/2022 à 17:13, laurent-38 - laurent.riffard+...@free.fr a écrit :

(on peut enlever la note si on considère que cela va de soi…)

Cordialement
~~
laurent



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

Re: [OSM-talk-fr] question sur un nouveau nom de rue et procédures BANO

[osm . sanspourriel]

> Sans rapport avec OSM mais tout de même avec le sujet :-)

Pas tout à fait : normalement BAN, BANO et OSM ont un certain lien^^.

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

Comme tu verras ce n'est pas le seul endroit où le cadastre indique
"ilôts" :

https://www.openstreetmap.org/search?query=Rue%20des%20Il%C3%B4ts%2C%2063#map=19/45.90023/3.01673

https://www.openstreetmap.org/edit?editor=id=107287601#map=20/45.06789/4.83180
:-(

J'aurais mis :

name=Rue des Îlots

official_name=Rue des Ilôts (si tu trouves la décision du Conseil Municipal)

alt_name=Rue des Ilôts (si le CM dit Îlots ou Ilots et que seul le
panneau indique le contraire)

source:alt_name=sign (pas de note, un "vrai" attribut c'est plus
clair/utilisable/cherchable)

À noter que ilots est aussi correct en français depuis 1990.

Et j'aurais demandé à la mairie :

http://www.charbonniereslesvarennes.fr/fr/questions-publiques

Perso, je en mets local_name que pour un nom "localisé" ainsi. C'est à
dire une dénomination utilisée par les locaux.

Jean-Yvon

Le 09/08/2022 à 12:27, Cyrille37 OSM - cyrille+talk...@giquello.fr a écrit :

Bonjour,

Sans rapport avec OSM mais tout de même avec le sujet :-)

L'État fourni un outil et de l'accompagnement aux communes pour gérer
leur base adresses : https://adresse.data.gouv.fr/gerer-mes-adresses.
Tu peux peut-être demander à la mairie si elle est informée de cette
démarche, qui me semble importante pour contribuer à ce commun ;-)

Cyrille37.

On 09/08/2022 12:12, Pierre Beyssac wrote:

Bonjour à tous,

Récemment la commune d'un petit village que je connais au fin fond
du Puy de Dôme a ajouté des noms de rues. Les ayant vus cet été,
je les ai ajoutés dans OSM.

Cependant l'un des panneaux de rue me pose un problème.

Le panneau porte l'inscription "Rue des Ilôts" (j'en ai pris la
photo).

Si c'est une référence au mot français, l'orthographe correcte
serait plutôt "Îlots", ou "Ilots" avec la réforme de 1990. J'ai mis
cette dernière orthographe dans OSM en attendant d'y voir plus
clair.

Sinon, c'est peut-être une référence à un nom propre, lieu-dit ou
autre. Les autres noms de rues de la commune correspondent à des
zones identifiées sur le cadastre et pour la plupart reportées sur
la carte IGN, mais je n'ai pas trouvé de zone à ce nom.

Faut-il reporter telle quelle l'orthographe du panneau dans OSM ?

Sinon, comment faire pour trouver une autre référence ?

Peut-on vérifier dans une autre base publique servant de source pour
BANO ?
J'ai regardé hier l'extraction IGN pour le Puy de Dôme mais le nom
n'y figure pas encore, pas plus que les autres noms de rues.

Faut-il appeler la mairie ?

On m'a dit qu'ultérieurement, la commune allait attribuer des numéros
aux habitations, mais ce n'est pas encore fait.

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




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

Re: [OSM-talk-fr] Vue aérienne Bing de meilleure résolution que l'Ortho HR

[osm . sanspourriel]

Bonjour,

version courte : varier les sources pour trouver la meilleure pour la
problématique donnée.

Ce n'est pas la même endroit, il n'y a pas les mêmes voitures^^.

Si iD et JOSM permettent de changer de couche aérienne c'est que
certains ont une meilleure résolution (et c'est effectivement souvent le
cas de BD Ortho), pour l'âge, Maxar est souvent meilleur.

Après tu as d'autres critères : verticalité, absence de nuages. Tout ça
fait qu'il n'y a pas a priori de "bonne" source.

Aussi floutage (regarde mon exemple :  un futur évadé faisant faire de
la reconnaissance ?^^).

Si tu es dans un endroit stable, Maxar tu peux oublier (quoique, ils ont
par endroit de bonnes résolutions).

Tiens l'ortho 2016 de Loire-Atlantique (20 cm) qui est aussi Ortho HR
2016 mais avec un autre traitement semble fabriquer du crénelage sur les
traits de parking.

J'ai eu la flemme de convertir des numéros de tuiles en lat, lon, donc
j'ai pris un autre parking au nord de Nantes au hasard.

https://www.openstreetmap.org/#map=19/47.26653/-1.59136

Sur Bing
(https://www.bing.com/maps?v=2=47.26709~-1.59145=21=s) ils
indiquent deux sources :

- TomTom (et hop on va chercher les sources de TomTom).

- Vexcel Imaging (et là tu as ta réponse :
https://www.vexcel-imaging.com/products/)

Les exemples de Vexcel Imaging sont par aéronef mais rien n'interdit
d'utiliser des drones. Cependant s'ils en avaient connaissance ils
devraient en faire mention.

J'ai peut-être mal cherché, bonne chasse aux œufs (hors saison).

Jean-Yvon

Le 04/08/2022 à 19:02, Baptiste Jonglez - bapti...@bitsofnetworks.org a
écrit :



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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[osm . sanspourriel]

flood_prone (avec un souligné) et effectivement tidal.

Par contre c'est surtout utile là où le chemin passe au dessus de la
PM95 (trait de côte) et la PM120 (limite ordinaire des plus grandes
marées).
https://www.openstreetmap.org/way/1083321965#map=19/48.23098/-4.43089

Le cas n'est pas exceptionnel y compris pour des routes avec des
panneaux temporaires (ouvrables) ou permanents.

Par contre pour l'altitude je suis très réservé.

En effet c'est un point en zone marine. Le 0 des cartes marines c'est la
plus basse mer ordinaire.

Les altitudes sont faites pour qu'un bateau sache s'il passe tout le temps.

Donc avec des altitudes marines et des abaques (maree.info, produits
marée du Shom) on peut savoir si le chemin est submergé. Pas trivial
mais faisable.

Par contre avec une altitude terrestre (mi-marée) tu va devoir trouver
le demi marnage pour te ramener au cas précédent.

Je doute que quiconque s'en serve (pas grave) sauf si ça apparait sur la
carte et alors c'est probablement mal interprété.

Le but d'OSM n'est pas de nourrir les poissons avec les touristes et
autres badauds ;-).

Jean-Yvon


Le 02/08/2022 à 17:53, Eric SIBERT - courr...@eric.sibert.fr a écrit :

En complément des autres réponses, indiquer l'altitude des points de
la route devrait permettre de savoir pour quelle marée on peut passer.

Et un floodprone=yes (voir=tidal) pour aider à savoir que la route est
inondable. Même si le trait de côte permet de se douter que la route
est inondable, elle pourrait passer sur un pont ou un remblais.

Eric



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




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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[osm . sanspourriel]

Tu peux éventuellement ajouter intermittent=yes si tu veux être plus
explicite.

Le 01/08/2022 à 17:01, whatis moss - whatism...@hotmail.com a écrit :

Dans mon cas j'ai un chemin accessible seulement lorsque la marée est 
inférieure à 3 mètres.


http://maree.info/68

Tu veux dire qu'il y a moins de 3 m au dessus du 0 des cartes marines ?
Ou que le marnage doit être inférieur à 3 m pour que ce ne soit pas
intermittent ?

Étant donné que les gens se baignent et se noient parce qu'ils vont de
baigner là où c'est interdit et que c'est expliqué pourquoi (baïnes,
courant portant au large), baliser un chemin rarement accessible, est-ce
une bonne idée ?

Vraie question.

Jean-Yvon



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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[osm . sanspourriel]

Bonjour,

je croyais qu'avec la corruption, un ancien maire de Trébeurden
avait résolu le problème en bétonnant la côte...

- Tu peux comme JP indiquer comme ici
https://www.openstreetmap.org/way/180645171, un fjord au niveau de la
traversée usuellement ou toujours submergée.

- Pour le reste comme ici https://www.openstreetmap.org/way/180645190
rien de spécifique car la limite du trait de côté implique que c'est
submergé à marée haute. Et on se doute que c'est dans la zone
intertidale ! Tu peux dessiner l'estran et préciser tidal=yes. Ce sui se
trouve à ce niveau sera de facto submergé à marée haute.

- Ou comme ici ne rien mettre :
https://www.openstreetmap.org/#map=19/48.30599/-4.55048

Il y a certes un panneau sur le coté gauche de la cale pour indiquer
qu'on peut rejoindre la pointe suivante par la grève à marée basse mais
c'est le seul signe tangible du "chemin".

Jean-Yvon

Le 01/08/2022 à 17:01, whatis moss - whatism...@hotmail.com a écrit :

Bonjour, j'aurais besoin d'aide pour savoir quelle clés utiliser pour un chemin 
qui est accessible seulement lors de la basse marée. La clé tidal=yes semble 
être répandue mais d'après le wiki, cette clé serait pour les étendues d'eau 
soumises à la marée plutôt que pour les chemins accessibles lors de la basse 
marée. Après cela, il y aurait t-il aussi une clé pour indiquer à quel niveau 
de marée le chemin est accessible ? Dans mon cas j'ai un chemin accessible 
seulement lorsque la marée est inférieure à 3 mètres.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




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

Re: [OSM-talk-fr] [édition mécanique/de masse] nettoyage du tag surface (aussi possible en manuel dans votre zone de confort)

[osm . sanspourriel]

Dans ma ZdCÉ (zone de confort élargie ;-), ça me semble bon :

- des landuse avec surface=yes (je préviens le contributeur car les
landuse ne peuvent être que surfacique et dans la sens area=yes)
- des scories, mais autant les virer à la main :
https://www.openstreetmap.org/way/926177590, ou à cartographier
correctement https://www.openstreetmap.org/way/719518005

Donc c'est peut-être utile de se donner le temps de regarder disons dans
les 8 jours qui viennent ?

Maintenant ta manip automatique ne va rien perdre d'utile

N. B. : sur la 40aine de landuse, j'ai galéré pour virer ceux qui se
chevauchaient. Car à vouloir exclure de temps en temps la voirie des
zones agricoles...

Jean-Yvon

Le 28/07/2022 à 14:45, Marc_marc - marc_m...@mailo.com a écrit :


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

Re: [OSM-talk-fr] Itinéraire vélo non balisé

[osm . sanspourriel]

> Le 23/07/2022 à 10:32, Marc_marc - marc_m...@mailo.com a écrit :

td;dr : +1

> Le 23/07/2022 à 19:17, lejun - le...@gmx.fr a écrit :

Si seuls des nœuds et non le cheminement précis existent, il existe la
modélisation par carrefours mais là il y a un GPX, donc la relation en
filaire, ça me va (mais en partant des chemins OSM comme tu l'as fait).

email, email:operator : ni l'un ni l'autre, ce sont juste les mentions
légales du site. Si tu crèves, tu ne vas pas demander assistance à cette
personne, si c'est dû à la piètre qualité du revêtement, tu vas
t'adresser à l'opérateur de la voirie en question.

smoothness : sans intérêt car tu dis qu'il y a de tout et si un membre
passe à very_bad ou horrible, vas-tu mettre à jour la relation ? La
réponse est dans la question.

Quant à la possibilité de protéger un GPX par un copyright... La FFRP
arrive bien dans certains cas à valider ses itinéraires comme œuvres de
l'esprit, donc oui.

Est-ce bien raisonnable ? Certains tribunaux répondent par l'affirmative.

Jean-Yvon


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

Re: [OSM-talk-fr] [édition mécanique/de masse] post_office:type=* -> `post_office=*

[osm . sanspourriel]

Je suppose que tu veux dire que les éventuellement conflits seront
détectés à ce moment-là.

Deux attributs différents, je ne vois pas comme une édition automatique
pourrait proprement résoudre le conflit.

À la rigueur par étude du dernier attribut ajouté.

Je doute que ça concerne moult cas.

OK pour l'édition de masse.

Jean-Yvon

Le 22/07/2022 à 12:03, Marc_marc - marc_m...@mailo.com a écrit :

les éventuels conflits entre l'info donnée par post_office:type=*
et post_office=* se feront hors de l'édition de masse



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

Re: [OSM-talk-fr] equivalence subtance=* -> utility=* sur les pipeline=marker dépréciés

[osm . sanspourriel]

Bonjour,

remplacer les contenus par les types d'opérateurs, je ne sais qui a eu
cette idée saugrenue mais il n'est pas étonnant que ça ne marche pas bien.

Par exemple de l'eau ça peut servir pour un réseau de chauffage
(utility=heating) ou de l'adduction d'eau (utility=water) ou encore de
la collecte d'eaux usées (utility=sewerage) ou de l'eau pour les
pompiers (utility=hydrant).

Pas de soucis pour ajouter utility= par contre remplacer... Quand on ne
sait pas on supprime ?

Jean-Yvon

Le 19/07/2022 à 19:34, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

le déprécié pipeline=marker utilisait parfois erronément
subtance=* pour décrire ce que contenait le pipeline concerné.
cela a été remplacé par marker=* + utility=*

la conversion est triviale pour certaines valeur, exemple :
subtance=gas/oil -> utility=gas/oil
mais pour les autres ?
les 9 valeurs existante en france métropolitaine
substance=brine
substance=brine;water
substance=ethylene
substance=fuel
substance=gas -> subtance=gas
substance=hydrogen
substance=measurement
substance=oil -> subtance=oil
substance=water

Cordialement,
Marc



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




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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural

[osm . sanspourriel]

Le 12/07/2022 à 21:58, Volker Schmidt - vosc...@gmail.com a écrit :


Ou de l'incompétence de ceux qui ont importé les Landcover Corinne (je

parlerais plus de choix discutable).


Avec CORINE  il y a un problème de base: les données se basent sur des
images satellitaires de résolution insuffisante pour OpenStreetMap:

*CLC1990* *CLC2000* *CLC2006* *CLC2012* *CLC2018*
*Geometric accuracy, satellite data* ≤ 50 m ≤ 25 m ≤ 25 m ≤ 25 m ≤ 10 m
(Sentinel-2) *(source:
https://land.copernicus.eu/pan-european/corine-land-cover
)*


Pas forcément. C'est la source *satellitaire*, elle *peut* être
complétée par d'autres sources. Insuffisant pour un import, mais à la
date de l'import, c'était de qualité suffisante.

Avec les landuse il y a d'autres soucis comme ces landuse jouxtant
d'autres landuse de même nature
https://www.openstreetmap.org/way/676097710#map=15/48.8430/2.0737 ce qui
fait perdre la vision d'ensemble de la zone.

Jean-Yvon




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

Re: [OSM-talk-fr] Aide OSMAND ?

[osm . sanspourriel]

Salut,

un truc que j'avais remarqué c'est que les mises à jour automatiques
(toutes les heures, OSM Live) finissent par ralentir.

Donc quand tu dis le jour et la nuit, si tu installes sur carte externe
tu vas peut-être dire que c'est rapide (ou que tu as une carte mémoire
de faible classe).

Heureux d'avoir un vieil Androïd acceptant de mettre les cartes sur
support externe car j'ai 20 Go de cartes.

Jean-Yvon

Le 13/07/2022 à 23:33, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Salut tout le monde,

C'est un peu hors sujet, mais je viens de faire une mise à jour de mes
cartes sur OSMAND~ et ça me plante l'appli. Apparemment c'est
l'indexation de grand-est France, qu'il a d'ailleurs renommé "great
east", on se demande bien pourquoi, qui fait planter. Et toutes mes
autres cartes disparaissent de la vue.

Où puis-je trouver de l'aide pour résoudre ça ? J'ai rien trouvé sur
osmand.net, j'ai rien vu sur forum.openstreetmap.org...

En plus quand je vais sur l'onglet "télécharger", parfois j'ai la liste
"afrique, amérique, asie, europe,..." et parfois j'ai une liste
ultralongue qui commence par "afghanistan région 1, etc"


Merci !

Bonne soirée,

Jean-Pierre




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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Le 12/07/2022 à 19:19, Marc Mongenet - marc.monge...@gmail.com a écrit :

Je suppose que ça s'appelle mapper pour la maintenance.:-)  A moins que ce
soit dû à mon incompétence avec les multipolygon. Je ne sais pas.


+1 par rapport à JB sur ce point.

Ou de l'incompétence des outils pour gérer facilement ces multipolygones.

Ou de l'incompétence de ceux qui ont importé les Landcover Corinne (je
parlerais plus de choix discutable).

Oui c'est le bordel dans ce cas.

Pour le côté maintenance, c'est un problème d'outils pour séparer
facilement les deux parties communes. Conceptuellement ce que l'on veut
faire est simple. Bien plus simple que de créer des chemins parallèles.

Le 12/07/2022 à 19:40, Marc Mongenet - marc.monge...@gmail.com a écrit :

Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de
précision sur les limites de forest dans le canton de Genève.


Tu as de la chance de vivre dans une zone ou le contraste peut être fort
en hiver, où les arbres en hiver offrent une telle transparence et
d'avoir une telle ortho.

Si tu peux le faire proprement, je n'ai rien contre.

Ce qui me déplait c'est de fabriquer de la fausse information au
prétexte que c'est plus rigoureux d'un point de vue topologique.

Un autre soucis c'est qu'on n'a pas une rigueur constante concernant les
landuse, on le voit souvent au niveau des residential en zone rurale où
les limites sont les parcelles ou le bâti ou quelque chose d'approximatif.

On va à vous suivre éviter les routes. Donc une route coupe un landuse
forest mais pas un residential ?

Ou quand la route sert à la gestion forestière l'intégrer ?

> Oui, le width manque à la plupart des routes, c'est bien dommage,
mais c'est sans rapport avec les landuse.

Pas vraiment car dans les cas simples (je ne parle pas d'autoroute mais
de route de campagne, de chemins), la largeur de la route définit l'emprise.

Jean-Yvon





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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Avec cette logique, pour une rue bordée d'immeubles, il faudrait
prolonger la surface des immeubles jusqu'à l'axe central de la voie...
On ne le fait pas, au moins parce que notre source pour le bâti est de
qualité correcte, et que souder les bâtiments aux highways serait à la
fois chronophage et synonyme de dégradation de la qualité, vue la
déformation manifeste qu'on ferait subir aux géométries de bâtiments.
Bref, ça ne vient à l'idée de personne je pense.


Non le landuse en question c'est le residential.

Et il ne viendrait à personne l'idée d'exclure les routes de ce landuse,
ni les jardins, ni les...

Pourtant personne ne réside sur la rue. Sous les ponts etc... oui hélas
mais c'est un autre sujet.


Par analogie, la seule raison que je vois pour coller les landuses aux
filaires de voies est l'absence d'une source géométrique assez
précise, combiné au temps que prend le dessin de ces surfaces. Ça
n'est donc (pour moi) qu'une version intermédiaire de dessin des
landuse, et surtout pas une bonne pratique. La fonctionnalité de copie
parallèle dispo dans JOSM [1] est un bon compromis pour dessiner du
1er coup une limite de landuse non collée au filaire mais approximant
l'emprise de la chaussée.


OK pour la première partie. Par contre pas pour la seconde : on fabrique
de la fausse précision.

En restant au landuse surfacique / route filaire (mais éventuellement
avec une largeur), on ne crée pas de fausses données.

C'est imparfait, OK mais entre imparfait et faux...

Raffiner le tracé de la route si tu passes les landuse en traits
approximativement parallèles à la route, ça va vite être un cauchemar.

Sans rien apporter sauf le confort intellectuel d'arrêter le landuse à
peu près au bon endroit.

Sauf à prendre le tracé surfacique des routes du cadastre, je ne vois
pas de manière raisonnable de faire du travail propre surfacique tout en
affinant les tracés des routes. Et il s'agira de l'emprise de la route
et non de la route.

Jean-Yvon



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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[osm . sanspourriel]

Le 11/07/2022 à 16:41, Marc_marc - marc_m...@mailo.com a écrit :


et qu'on ai ou pas un tag approuvé, cela n'empeche pas d'arreté
la géométrie du champs/forêt au bon endroit et non pas au milieu de la
route : on ne culture pas sur la route même si certain roulent comme
des patates mais ca c'est une autre histoire :)

PS: on le fait correctement avec les landuse=railway : le champs ne va
pas jusqu'au milieu des rails

niveau pratique : faire une bonne géométrie pour la route, dupliquer
2x la route et décaler les copies de la largeur de l'emprise routière,
cela fait souvent une très bonne géométrie de départ en peu de temps


Pas trop d’accord. Le « problème » est celui soulevé par David : la
route est modélisée en filaire et les landuse en surfacique.

Tant qu’on fait ça, la représentation la plus logique est de faire aller
les landuse jusqu’à la route. Et c'est parce que du as des
landuse=railway que tu ne vas pas jusqu'au rails.

Et si plus tard on veut faire du surfacique pour la route, alors on va
arrêter le surfacique des côtés au surfacique de la route (comme c’est
fait pour les rails).

Mettre une largeur (width=) à une route tout en conservant le filaire me
semble préférable : la cartographie c’est une modélisation du monde, pas
du dessin.

Et cette approximation est plus juste que de dupliquer la géométrie et
de la décaler.

Je mets au défi quiconque de faire proprement du surfacique quand la
route longe une forêt : pour que ce soit propre vous allez partir du
centre de la route et dériver les limites via la largeur
(essentiellement constante) de la route, vous n’allez pas essayer
d’estimer la limite de la forêt par les troncs ou le houppier.

Bref, par analogie 2D/2,5D/3D, on fait du 1,5D.

Ce n’est que si on a besoin de cartographie fine que la modélisation de
la chaussée (avec les différents éléments cités par David) a du sens.

Mais si on se met à raffiner les tracés de routes, il faut faire suivre
les landuse, les fossés et tutti quanti ce qui rend les mises à jours
plus problématiques.

Et vous modélisez une rue avec trottoir avec sidewalk=both ou vous
mettez du surfacique pour le trottoir, le caniveau, la bordure du
trottoir, la dalle podotactile, etc. ?

Jean-Yvon




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

Re: [OSM-talk-fr] JOSM : traduction du logiciel - erreur due aux caractères d'échappement ?

[osm . sanspourriel]

J’allais répondre en privé mais comme j’ai compris où était le problème
j’en fait profiter la communauté.

> Vous êtes sur le point d'écraser le fichier de session "{0}".
Voulez-vous continuer ?

Est ce que tu as écrit.

Comme indiqué dans la page d’aide... et par toi les apostrophes sont
« problématiques » dans le sens où ils doivent être doublés ou mieux
substitués par l’apostrophe typographique.


Apostrophe informatique :

> d'écraser

à doubler :

> d''écraser

ou à remplacer par l’apostrophe typographique :

> d’écraser

Grammalecte est ton ami.

Jean-Yvon

Le 10/07/2022 à 18:12, leni - lenny.li...@orange.fr a écrit :


Le 10/07/2022 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour Lenny,

Est-ce que tu n'as pas une correction automatique des caractères
typographiques style Grammalecte ?

J'ai fait un copier/coller de ton texte, utilisé Grammalecte pour mettre
une apostrophe typographique et c'est passé.


Où as-tu mis l'apostrophe (ta modif est bien passée) peux-tu m'envoyer
le texte avec l'apostrophe typographique ?


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




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

Re: [OSM-talk-fr] JOSM : traduction du logiciel - erreur due aux caractères d'échappement ?

[osm . sanspourriel]

Bonjour Lenny,

Est-ce que tu n'as pas une correction automatique des caractères
typographiques style Grammalecte ?

J'ai fait un copier/coller de ton texte, utilisé Grammalecte pour mettre
une apostrophe typographique et c'est passé.

Donc non la correction automatique est peu probablement le souci, et
c'est tombé en marche.

Merci pour toutes les traductions ;-)

Jean-Yvon

Le 10/07/2022 à 15:10, leni - lenny.li...@orange.fr a écrit :

Bonjour,



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

Re: [OSM-talk-fr] Bon usage (ou bonne définition) des multipolygones ?

[osm . sanspourriel]

Nous sommes d'accord sur le fond et oui cette contiguïté par poser
souci, par exemple quand un une clairière comporte une maison qui est en
bord de forêt : tu dois créer un inner comme étant l'enveloppe de la
clairière et de la maison.

C'est un exemple théorique, normalement tu ne mets pas une maison au
droit des arbres ! J'ai déjà eu un cas différent mais similaire.

Non, faire des trous pour dire que les bâtiments ne font pas partie du
centre de loisir n'a aucun sens.

Jean-Yvon

Le 07/07/2022 à 19:14, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Bonsoir,

Je viens de commencer le défi 27912 de Marjan de Tomtom, "Polygon has
self intersection". Un petit dessin valant mieux qu'un grand baratin,
j'ai regardé https://www.openstreetmap.org/relation/2143328 et
https://www.openstreetmap.org/relation/12789892.

Dans les deux cas on a une grande surface "outer" qui définit la nature
de la zone, respectivement landuse=retail et leisure=resort. Mais dans
les deux cas l'auteur du multipolygone en a exclu les bâtiments, en en
faisant des membres "inner". Et comme certains de ces bâtiments sont
contigus, la requête de Marjan les sort en erreur en y voyant une "self
intersection".

Je n'ai aucune connaissance du type de requête qu'il y a derrière ça.
Première hypothèse : la requête de Marjan serait mal brêlée car la
contigüité n'est pas une intersection. Qu'en pensent les spécialistes ?
Si effectivement c'est le cas je lui expliquerai (avec les
éclaircissements des spécialistes...) qu'elle doit corriger sa requête.
Si c'est le fonctionnement normal... bin tant pis !


Mais sur le principe je trouve absurde d'exclure les bâtiments du
multipolygone. Autant quand il y a une grande clairière dans une plus
grande forêt je trouve logique que le petit polygone
"natural=grassland", ou "landuse=meadow", soit mis en membre inner du
"landuse=forest", autant pour moi, logiquement, les magasins font partie
de la "fonction" retail, comme les appartements et le restaurant font
partie ingégrante du "leisure=resort". Car après tout le terrain occupé
par le magasin est bien de type "retail" !

Et pour ma part quand je définis un landuse=retail je me garde bien d'en
exclure les magasins !


Y a-t-il un guide d'utilisation pour ces cas ? Quelle est la bonne
pratique ?

Merci de votre attention, bonne soirée (et bonnes vacances, si c'est le cas)


Jean-Pierre





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

Re: [OSM-talk-fr] [édition mécanique/de masse] wood=* -> leaf_type=*/leaf_cycle=*

[osm . sanspourriel]

Autant en langage naturel, la distinction bois/bosquet a un sens autant
avec OSM ça n'en a pas.

Car la différence c'est la surface, surface qui est tracée dans OSM.

> Ce taggage est proposé par iD.

Très mauvais justificatif parce que iD prend ce qu'il trouve en base, y
compris les erreurs.

Dans l'exemple passé par Marc les arbres sont distincts et font plus
penser à deux alignements d'arbres (tree_row), voir des natural=tree car
on les distinguent et ils ont visiblement été plantés à distance régulière.

Rein contre le fait de créer des nouveaux tags mais seulement quand ils
apportent quelque chose. Là je cherche encore.

Jean-Yvon, aussi peu convaincu que Marc

Le 06/07/2022 à 12:51, Christian Rogel -
christian.ro...@club-internet.fr a écrit :



Le 5 juil. 2022 à 21:55, blef via Talk-fr  a écrit :
En lisant ton message, j'ai d'abord cru à un lapsus de ta part, mais après recherches 
je vois qu'il existe bien des occurrences 
 de 
natural=tree_group .
Par contre, je ne vois qu'une seule mention dans le wiki 
 dans les 
propositions avec le statut "draft".
Est-il judicieux d'utiliser un nouveau tag n'ayant fait l'objet d'aucune discussion et 
non documenté parmi les tag "en usage"?

Ce taggage est proposé par iD.
Je l’ai adopté, car il correspond à une lacune évidente : un bouquet d’arbres 
n’est pas un « wood » et distinguer chaque arbre, alors qu’il est imbriqué dans 
ses voisins, c’est induire en erreur, un taggage pour le non rendu.

Christian R.

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



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

Re: [OSM-talk-fr] hierarchie routière - port de Calais

[osm . sanspourriel]

Bonjour,

je trouve que c'est bon car tous les accès sont bien des voies de
services, la voie principale c'est celle qui te conduit à ton ferry.

Et ça va dépendre des arrivées et des départs des bateaux.

Tu veux récupérer le trafic AIS pour en fonction des quais prévus par la
capitainerie modifier en temps réel les voies principales ?^^

Actuellement c'est le quai 10 avec le Spirit of Brittany ;-)

https://map.openseamap.org/?zoom=15=50.9761=1.8767=BFTFFTF0TF

Jean-Yvon

Le 05/07/2022 à 13:01, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

https://www.openstreetmap.org/node/9484428895
une idée d'amélioration ?
il y a un peu trop de highway=service, le cheminement principal
mériteraient d'être remonté mais en quoi ? unclassified ?

Cordialement,
Marc



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




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

Re: [OSM-talk-fr] [édition mécanique/de masse] wood=* -> leaf_type=*/leaf_cycle=*

[osm . sanspourriel]

Aussi pour les éditeurs qui utilisent ce qui est en base (et non ce qui
est dans le wiki) pour proposer les valeurs.

Et oui iD utilise l'imitation contrairement à JOSM qui utilise
l'intelligence collective.

Chacun son truc ;-).

Donc pour, évidemment pour.

Jean-Yvon

Le 01/07/2022 à 16:31, Cyrille37 OSM - cyrille+talk...@giquello.fr a écrit :

Bonjour,

Je vote "Pour" :-)

C'est bénéfique pour les nouveaux, ou comme moi qui cherche souvent en
regardant comment les autres ont fait.

Merci !

Cyrille37.



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

Re: [OSM-talk-fr] Flopées de highway=pedestrian qui n'en sont pas

[osm . sanspourriel]

Le 28/06/2022 à 14:19, deuzeffe - opensm@deuzeffe.org a écrit :


J'ai bon ?


Mouais, pas convaincu de l'intérêt car représenter le trottoir (même
large, ça reste essentiellement un trottoir).

Ça me semble toujours mieux que dessiner des chemins parallèles aux
routes pour représenter des trottoirs !


Perso, je ne supprimerais pas car les logiciels de routage ne savent
pas tous router sur du surfacique...


Mmmh, mauvais argument, changer :p On ne taggue pas pour les logiciels
de routage, c'est à eux de prendre en compte les évolutions d'osm.
enfin, c'est ce que j'ai lu maintes fois, à côté de "on ne taggue pas
pour le rendu"


+1, autant dire que la rue principal a sidewalk=both.

Comme ça un routeur piéton saura router par défaut sur la voie.

Sur la difficulté des routeurs d'utiliser du surfacique, certains le
gèrent : les routeurs des bateaux car en mer, hormis les DST
(Dispositifs de Séparation du Trafic, style Rail d'Ouessant) la
navigation est assez libre.

Par contre un routeur ayant pour but d'aller d'un point à un autre en
optimisant certains critères, la combinatoire annoncée par Marc est
théorique : en théorie, tu peux traverser une place en parcourant des
boucles, des spirales, etc... Dans la pratique tu vas aller "au plus
droit" (d'où l'importance d'exclure les obstacles), au plus confortable
(limiter les escaliers), etc...

Comme le surfacique et le filaire représentent le même objet, on doit
avoir un seul objet OSM.

https://www.openstreetmap.org/way/251906311#map=19/48.39012/-4.50176

et

https://www.openstreetmap.org/way/801670856#map=19/48.39012/-4.50176

représentent tous deux le Cours Aimé Césaire à Brest.

On voit que bien des tags sont dupliqués (noms et source du nom), on
pourrait ajouter des infos qui ne sont que sur un modèle (éclairage,
surface) ou pas encore (origine du nom - odonymie).

https://wiki.openstreetmap.org/wiki/FR:Relation:associatedStreet) ou
assimilé ne serait pas préférable ?

Le fait que les éléments soient surfaciques ou pas font qu'on pourrait
utiliser street comme rôle dans les deux cas (mais autant séparer le
surfacique, non ?)

Jean-Yvon.



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

Re: [OSM-talk-fr] 3 pour le prix d'une.

[osm . sanspourriel]

Il suffirait que name soit traduit par nom propre pour limiter les dégâts.

J'ai dégommé de la forêt à un arbre appelé cerisier.

Je n'ai pas eu la patience de contacter ce contributeur.

Le 06/06/2022 à 19:28, Jacques Lavignotte - jacq...@lavignotte.org a écrit :

name=Gymnase


Le name= cet éternel sujet.



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

Re: [OSM-talk-fr] 3 pour le prix d'une.

[osm . sanspourriel]

Oui encore une confusion bâtiment et POI, de plus pour une mairie de
quartier.

Le 06/06/2022 à 18:07, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Le 06/06/2022 à 17:34, Jacques Lavignotte a écrit :

Vous confirmez que 3 amenity=townhall

https://www.openstreetmap.org/#map=19/46.57711/0.30555

c'est pas une bonne idée ?

J.

C'est une très mauvaise idée...

Ce serait-y pas des annexes ? La vraie mairie me semble bien être
https://www.openstreetmap.org/node/7985542385 .

Bonne soirée,

JP






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

Re: [OSM-talk-fr] JOSM - Désignation des shop=farm

[osm . sanspourriel]

Le 06/06/2022 à 11:31, Rpnpif - rpn...@trob.eu a écrit :

Aucun soucis pour que je fasse changer la traduction JOSM de
shop=farm en "Produits de la ferme" ?

Cordialement,

Bonne idée aussi de modifier mais je verrais plutôt : Vente à la
ferme, afin d'éviter la confusion avec un stand sur un marché externe
ou de vente de produits fermiers dans un hypermarché (oui ça se voit).


Bof (ni pour ni contre).

Car oui primeur est clairement mauvais mais "Produits de la ferme"
indique que les produits viennent de la ferme. Un hypermarché n'est pas
une ferme, "Produits fermiers" serait ambigu.

"Vente à la ferme" ne dit pas si ces produits viennent de la ferme en
question (je pense à des marchés de producteurs à la ferme).

Donc au final je botte en touche.

Jean-Yvon



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

Re: [OSM-talk-fr] Revert des données de camping car ?

[osm . sanspourriel]

Les données ont été supprimées :

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

Si vous en voyez est-ce que la page est à jour ?

Sur ton exemple effectivement ce n'est pas OK.

Si on y va à coup de MapRoulette on va foutre la mouise pour les
annulations.

Si vous voulez, vous cherchez les changeset des objets non encore
annulés, les triez par numéro décroissant et vous utilisez le greffon
Reverter de JOSM.

Voir
https://forum.openstreetmap.fr/t/lieux-de-stationnement-pour-camping-car-pollution-de-la-base/8709/24

Jean-Yvon


Le 27/05/2022 à 11:46, Georges Dutreix via Talk-fr -
talk-fr@openstreetmap.org a écrit :


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

Re: [OSM-talk-fr] Route des Vins d'Alsace dupliquée

[osm . sanspourriel]

Herzlich willkommen.

Du côté d'Obernai je dirais même qu'elles sont assez complémentaires ;-).

https://www.openstreetmap.org/relation/1116830#map=16/48.4583/7.4746

https://www.openstreetmap.org/relation/2144151#map=16/48.4583/7.4746


16 morceaux pour la première, 17 pour la seconde : autant compléter la
première.

http://ra.osmsurround.org/analyzeRelation?relationId=1116830

Là elles sont aussi bancales :

https://www.openstreetmap.org/relation/1116830#map=12/48.0291/7.2675

Je vois que les contributeurs sont très souvent les mêmes dont un
certain Denis auteur d'une des deux.

Peut-être que ceux qui maintiennent la relation abusent des boissons
fermentées sur le parcours et trouvent que deux c'est mieux.

Il y a peut-être une subtilité mais comme toi je sèche. Denis, abus de
boissons fermentées ou bonne raison ?^

Jean-Yvon

Le 21/05/2022 à 19:00, Volker Schmidt - vosc...@gmail.com a écrit :

Bonjour.

Voici mon premier post sur la liste française OSM. Je suis un mappeur OSM
allemand de Padoue en Italie.
Par hasard j'ai remarqué qu'il existe deux relations apparemment identiques
pour la Route des Vins d'Alsace: relations 1116830
 et 2144151
.
Je suis à peu près sûr qu'il n'y a qu'une seule Route des Vins d'Alsace
(mes ancêtres sont alsaciens) !

Volker
___
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] Revert des données de camping car ?

[osm . sanspourriel]

Salut,

tu n'est pas le premier à le signalé, je l'avais fait sur la liste et
avant d'autres l'avaient fait sur le forum :

https://forum.openstreetmap.fr/t/lieux-de-stationnement-pour-camping-car-pollution-de-la-base/8709/5

Notre membre du DWG de compète (*) et en train de nous scripter tout ça
car il y a 1928 changesets à annuler !

Donc oui la suppression est bien prévue.

Jean-Yvon

(*) Lucas Longour membre du DWG (Groupe de travail sur les données de la
Fondation)

Le 20/05/2022 à 21:08, Ras Elased Borealis via Talk-fr -
talk-fr@openstreetmap.org a écrit :

BonjourUn utilisateur a ajouté énormément d'emplacements de 
camping-carshttps://www.openstreetmap.org/user/lem38/historysemble-t-il depuis 
une source non-libre et je ne suis pas sûr par ailleurs que ce genre de donnée 
soit pertinente pour OSM sous cette forme.Il a été bloqué par le DWG 
https://www.openstreetmap.org/user_blocks/5997mais les données subsistent...Un 
moyen pour tout supprimer ?Cordialement
___
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] Ajout/Homogénéisation des tags brand sur les grandes enseignes

[osm . sanspourriel]

Le 18/05/2022 à 22:50, Hippalectryon via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Écomarché (118697552): brand=Écomarché->Intermarché
Pas bien sûr car la marque c'est Écomarché je suppose.

En effet, j'ai fait ce choix à cause du problème de convention suivant : en effet, la  devrait être 
Écomarché. Cependant, il n'existe pas de wikidata/wikipedia pour Écomarché, qui fait partie du groupe Intermarché. 
Doit-on alors mettre 1 : =Écomarché et , 2 : =Écomarché et 
, ou bien 3 : =Intermarché et  ? Il me semble que ce doit être soit l'option 1 soit l'option 3 par soucis de cohérence, mais je n'ai 
pas trouvé de page wiki qui tranche clairement et l'usage ne tranche pas non plus. Qu'en pense la communauté ?


Je ne sais, je peux te dire ce que j'en pense, si d'autres répondent on
saura.

Je penche pour 1a et 2b.

Ce dont je suis sûr c"est que brand=Écomarché si les magasin existent
encore (Cf. l'article
https://fr.wikipedia.org/wiki/Intermarch%C3%A9#%C3%89comarch%C3%A9).

1a Pour le wikipédia, tu peux mettre wikipedia=fr:Intermarché#Écomarché ou

1b avec ta casquette Wikipédia créer une page Écomarché dont tu
devineras le contenu^^ avec un lien vers cette page depuis Intermarché.
Puis avec ta casquette OSM, wikipedia=fr:Écomarché.

Ce sont des alternatives viables à 1.

3 est faux donc exclu (ceci dit il ne semble plus y avoir d'enseigne à
ce nom :
http://enseignesdisparues.e-monsite.com/pages/enseignes/ecomarche.html
et dans ce cas il s'agit d'un ensemble vide donc c'est possible ;-)).

Typiquement : un challenge pour vérifier si le nom est toujours actuel ?
Le magasin existant ?


Pour les remplacements de Wikipédia en: en fr: je suis pour mais il faut 
exclure la France du NSI pour Système U (ou mettre la version française).
NSI = Name Suggestion Index, ce qui aide à l'homogénéisation. Créer un ticket 
ou faire directement la modif sur github.

Je ne suis pas du tout familier, ça ne me parle pas... Que/Où faut-il faire, 
concrètement ?


https://nsi.guide/?t=brands

https://nsi.guide/index.html?t=brands=shop=supermarket=Super%20U

Bon, il semble qu'iD tienne compte d'une remarque faite : il n'impose
plus le en: et laisse le fr: (soit parce qu'il n'essaye plus d'ajouter
le lien Wikipédia soit parce qu'il tient compte du fait que l'enseigne
est basée en France).

Donc ici, tu n'as rien à faire^^ mais pour info voici un exemple :
https://github.com/osmlab/name-suggestion-index/issues/6595 pour
Deutsche Telekom.


Sinon côté boites aux lettres tu va pouvoir faire de même !

De même, je ne suis pas sûr de voir de quoi tu parles ?


Je disais bàl mais en fait la manip sur Osmose concerne les bureaux de
poste :

https://osmose.openstreetmap.fr/fr/map/#zoom=13=48.3925=-4.4881=8020%2C8022=1%2C2%2C3

Là je vois que Pimms Médiation Quatre Moulins,
https://localiser.laposte.fr/finistere/brest/brest-quatre-moulins-pimms-299380
pour La Poste,

https://www.pimms.org/associations-pimms-mediation/pimms-brest/ en
adresse semi-générique (il y a bien les infos spécifiques à ce site mais
pas que), se voit proposer d'ajouter les infos suivantes :

brand=La Poste
brand:wikipedia=fr:La Poste (entreprise française)

Mais pas que (attention : potentiellement on peut avoir plusieurs
marques, style La Poste et Chronopost).

Tiens je pensais qu'Omose utilisait le NSI mais pas ici.


NB: Que pensez-vous d'aussi rajouter, *lorsqu'il n'est pas déjà indiqué* 
(parfois les liens sont vers l'enseigne locale), le lien vers le site web 
générique de l'enseigne ? Y a-t-il d'autres champs que j'ai loupés qui 
bénéficieraient du même traitement ?

Hippa00


Contre, explicitement déconseillé par le wiki : on doit mettre le lien
vers le magasin, pas vers l'enseigne. Si l'enseigne a une adresse
générique, elle sera renseignée par le wikidata.

Par contre coucou Florian, je pense que tu vois à quoi je pense^^.

Et d'accord avec Marc.

Jean-Yvon



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

Re: [OSM-talk-fr] Ajout/Homogénéisation des tags brand sur les grandes enseignes

[osm . sanspourriel]

City et non Carrefour City ?

La Vie Claire magasin bio et non La Vie Claire ?

Super U - Drive/U Drive

(idem pour Express, un seul doit être correct)

Écomarché (118697552): brand=Écomarché->Intermarché

Pas bien sûr car la marque c'est Écomarché je suppose.


Pour les remplacements de Wikipédia en: en fr: je suis pour mais il faut
exclure la France du NSI pour Système U (ou mettre la version française).

NSI = Name Suggestion Index, ce qui aide à l'homogénéisation. Créer un
ticket ou faire directement la modif sur github.

Sinon côté boites aux lettres tu va pouvoir faire de même !

D'une manière générale, Osmose suggère de telles modifications.
Attention aux faux amis ! Là je n'ai pas vu de gag.

Jean-Yvon


Le 18/05/2022 à 14:29, Hippalectryon - hippalectr...@protonmail.com a
écrit :

Inspiré par https://maproulette.org/browse/challenges/13052 ("Ajout de
tags brand sur les supermarchés en France"), j'ai étudié la
faisabilité d'automatiser l'ajout de tags brand, brand:wikipedia,
brand:wikidata sur les supermarchés en France, pour les grandes
enseignes bien connues.

En explorant les données, il apparaît que non seulement beaucoup de
tags manquant, mais en plus il y a une grand diversité de tags pour un
même type d'enseigne (typos, utilisation de la maise mère ou maison
fille comme brand, mise à jour du nom d'une enseigne mais pas de sa
brand, etc.).

Une analyse préliminaire semble montrer que ~1600 supermarchés peuvent
être modifiés de la sorte *[Changelog prévisionnel en PJ]*.

Qu'en pensez-vous ?

Hippa00



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

Re: [OSM-talk-fr] OSRM n'aime pas les pistes cyclables ?

[osm . sanspourriel]

En cernant le problème :

https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=44.08151%2C6.21869%3B44.08362%2C6.22288#map=18/44.08269/6.22049=Y

(j'ai juste déplacé le marqueur de départ pour éliminer le cas de la
marche arrière au départ) je constate que rien n'interdit OSRM
d'utiliser la piste cyclable.

Par contre il semble avoir considéré que la vitesse d'un vélo sur une
cette piste cyclable était moindre que sur une route résidentielle à 30
km/h.

segregated=no en 2 m de large avec smoothness=intermediate ?
Effectivement vu la définition de intermediate

https://wiki.openstreetmap.org/wiki/FR:Key:smoothness?uselang=fr#Smoothness

j'irais sur la rue.

De plus ce n'est pas une piste cyclable mais un chemin mixte piétons/vélos.

Vu le nom de la voie c'est plutôt highway=cycleway (et foot=yes ?).

Donc je dirais plus un problème de données que de moteur.

Jean-Yvon

Le 18/05/2022 à 07:55, Arnaud Champollion -
arnaud.champoll...@linux-alpes.org a écrit :

Bonjour,

Je me demande si c'est OSRM qui n'aime pas les pistes cyclables, ou
s'il y a quelque-chose qui cloche dans les données sur mon itinéraire.

Trajet vélo avec GraphHopper, 3 km

https://www.openstreetmap.org/directions?engine=graphhopper_bicycle=44.0810%2C6.2204%3B44.1007%2C6.2341#map=14/44.0912/6.2392


Même trajet avec OSRM, 3.1 km, et la piste cyclable est tout à fait
ignorée.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=44.0810%2C6.2204%3B44.1007%2C6.2341#map=14/44.0909/6.2280


Je me demande si OSRM n'a pas un paramétrage par défaut qui lui fait
éviter certains passages s'il rencontre tel ou tel attribut, mais je
n'arrive pas à voir quoi;

Merci

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




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

Re: [OSM-talk-fr] Modifications automatiques de operator:type sur les ecoles francaises

[osm . sanspourriel]

> Comme je ne connaissais pas encore cette mailinglist, j'ai déjà créé
un challenge avec le jeu de données MAJ ici
https://maproulette.org/browse/challenges/27551, je le garde ou je le
supprime ?

Autre erreur de débutant (*) : si une quête n'est plus à jour il est
préférable de demander à l'auteur initial de la mettre à jour que d'en
créer une nouvelle.

Sinon d'autres risques de répondre à de vieilles questions répondues
entre temps.

Ce qui n'est pas vraiment le but, on a assez de travail de jardinage
(maintenance de l'actualité des données) sans faire de fausses mises à jour.

Jean-Yvon

(*) on est tous débutants, plus ou moins, ça dépend des domaines !



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

Re: [OSM-talk-fr] Modifications automatiques de operator:type sur les ecoles francaises

[osm . sanspourriel]

En théorie tu ne dois avoir que des cas pathologiques puisque tous les
autres ont été réglés par ton robot.

Un exemple :

https://www.openstreetmap.org/way/231217067#map=19/47.81407/-3.62614

C'est à côté de l'école élémentaire et il y a fort à parier que les
écoles maternelles et primaires ont été fusionnées en école élémentaire.

Bingo : l'UAI est faux. Laisser en public (je parle de la quête) ne fera
que corriger en apparence mais en laissant l'erreur.

https://osmose.openstreetmap.fr/fr/map/#zoom=18=47.81407=-3.625336==1%2C2%2C3

La correction consiste par exemple à créer une relation site en
factorisant ce qu'il y a lieu et en supprimant ce qui n'est pas spécifique.

Exemple : https://www.openstreetmap.org/relation/10053442

Tu gagnes le droit de mettre ta quête en privé et d'installer le greffon
OSM Smart Menu sur ton navigateur favori pour passer facilement d'une
position à Osmose.

Jean-Yvon

Le 17/05/2022 à 22:26, Hippalectryon via Talk-fr -
talk-fr@openstreetmap.org a écrit :

J'oubliais : LeTopographeFou, tu peux a minima mettre à jour ta quête
MapRoulette ?
https://www.openstreetmap.org/node/4566756072 a été mis à jour il y a
plus d'un an et maintenant le taux doit être proche de 100 % de fait.

Comme je ne connaissais pas encore cette mailinglist, j'ai déjà créé un 
challenge avec le jeu de données MAJ ici 
https://maproulette.org/browse/challenges/27551, je le garde ou je le supprime ?

Hippa00

___
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] Modifications automatiques de operator:type sur les ecoles francaises

[osm . sanspourriel]

J'oubliais : LeTopographeFou, tu peux a minima mettre à jour ta quête
MapRoulette ?

https://www.openstreetmap.org/node/4566756072 a été mis à jour il y a
plus d'un an et maintenant le taux doit être proche de 100 % de fait.

Jean-Yvon



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

Re: [OSM-talk-fr] Modifications automatiques de operator:type sur les ecoles francaises

[osm . sanspourriel]

Bonjour, c'est moi qui ai commenté ta modif ;-).

Le 17/05/2022 à 19:14, Hippalectryon via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Dois-je revert mes changesets ou les modifier ?


Non, ils ne semblent pas mauvais en soi.

Reste à voir si on doit avoir le "public" ou "privé" dans le nom. Ce que
l'analyse osmose suggère proprement (du coup je ne sais ce que va dire
Osmose, rien je suppose).

> Dois-je partager son code ?

Il n'y a pas d'obligation mais partager le code dans le monde du libre
est une bonne pratique.

> Quelle est ma procédure à suivre à l'avenir ?

En discuter ici (au moins). Et éviter de faire des modifs dépassant la
France. Sinon tu vas avoir des gardiens du temple en plus.

D'une manière générale :
- vérifier la qualité des données
- éviter les duplicatas
- ne pas casser les données existantes
- et avoir un compte spécifique (pour taper sur le bot et non le
contributeur^^)

> 3. J'ai par erreur (problème de cache) uploadé plusieurs fois le même
tag pour le même node, ce qui créée des historiques sans changements (ex
https://osmlab.github.io/osm-deep-history/#/node/493411743). Est-ce
grave ? Dois-je y faire quelque chose ?

Grave : pas trop (car c'est exceptionnel)

Dois-je y faire quelque chose ? : un revert (non je déconne ;-)).

Rassure-toi, des bots à la con je bien d'en voir passer un (bot ou
utilisateur ayant de mauvaises pratiques je ne sais). Voir mon prochain
message.

Jean-Yvon



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

Re: [OSM-talk-fr] JOSM et version de Java ?

[osm . sanspourriel]

Le 14/05/2022 à 14:18, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :


OK, merci. Les LTS je suppose que c'est les versions impaires ?


Non ce sont les versions *8* (3 + 5, deux impaires^),

4 ans plus tard 11,

3 ans plus tard la 17

2 ans plus tard la 21.

Peut-être que la 22 sera une LTS car ce sera 1 an plus tard ;-).

Les 9, 13, 15 comme la future 17 ne seront pas des LTS.

Le rythme des version Java a augmenté (2 par an) par la volonté
d'Oracle. Pour les LTS, Oracle n'a plus l'air d'en faire : comme tu
payes pour le support, tant que ça leur rapporte... Mais avec une
incitation à passer à des versions plus récentes. Et ils vont sans doute
augmenter le prix des support des anciennes versions.

Les LTS, c'est plus un fonctionnement du monde du libre. L'idée c'est
que les entreprises ont besoin de visibilité et de stabilité. Et que les
bénévoles ne veulent pas avoir à maintenir 36 versions.

D'un côté une version qui sort tous les 6 mois et de l'autre côté des
LTS qui restent valables des années. La 8 date de 8 ans, Oracle vient
d'arrêter le support commercial mais les autres garantissent mars 2026
(soit 12 ans) ou décembre 2030. Ce qui fait pour certains 3 et bientôt 4
LTS à maintenir et une courante (en plus d'une en cours de développement).

Pour Azul c'est le point fort qu'ils mettent en avant.

Jean-Yvon



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

Re: [OSM-talk-fr] JOSM et version de Java ?

[osm . sanspourriel]

Comme ce n'est pas une LTS - Long Term Support -, tu vas avoir le droit
de migrer (aussi simplement) en septembre prochain (pour espérer que les
trous de sécurités soient comblés).

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

Version Release
dateEnd of Free
Public Updates
Java SE 11 (LTS)September 2018  September 2026 for Azul
October 2024 for IBM Semeru
At least October 2024 for Eclipse Adoptium
At least September 2027 for Amazon Corretto
At least October 2024 for Microsoft

Java SE 17 (LTS)September 2021  September 2029 for Azul
At least September 2027 for Microsoft^[14]


At least September 2027 for Eclipse Adoptium
*Java SE 18*March 2022  *September 2022* for OpenJDK and Adoptium
Java SE 19  September 2022  March 2023 for OpenJDK
Java SE 21 (LTS)September 2023  September 2028

*Legend:*
Old version
Older version, still maintained
*Latest version*
Future release


Le 14/05/2022 à 10:25, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Bonjour,

Finalement j'ai installé OpenJDK 18, c'est simplissime et ça marche bien.

Merci à tous pour vos explications et conseils, bonne fin de semaine

Jean-Pierre



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

Re: [OSM-talk-fr] Places PMR et fond OSM France KO

[osm . sanspourriel]

Le 11/05/2022 à 14:09, Denis Bigorgne - denis.bigor...@wanadoo.fr a écrit :

Aux zooms considérés, 17 à 19, ce n'est absolument pas le cas pour les
places PMR, ni pour les places vélo.


C'est surtout que les problématiques sont fort différentes : les places
PMR et les places vélo sont pour des publics bien distincts, des cartes
thématiques permettent de conserver une carte lisible. Si on met tout ce
qu'on a dans la base, sauf à aller à des niveaux de zoom très forts, ça
va coincer.

On a deux rendus vélo sur la page osm.org. C'est du luxe.

Et rien côté handicap.

Marc veut handicaper les daltoniens pour la recherche des places PMR :-(.

Le 11/05/2022 à 11:42, Marc_marc - marc_m...@mailo.com a écrit :


par contre pour le zoom, je trouve plutôt logique qu'une place
individuelle PMR apparaissent à un zoom + fort qu'un parking vélo de
plusieurs places.


Ça se discute, les parkings multiplaces vélo (et pas juste un arceau
biplace) sont sans doute dans des endroits typiques (gares, lieux
d'enseignement...) et donc leur emplacement "devinable" : près de
l'entrée principale. Devoir zoomer dans ce coin ne devrait pas être une
forte contrainte.

De plus un véhicule motorisé se déplaçant plus vite, le niveau de zoom
adapté est plus petit.

Un besoin me semble d'être de trouver une place (vélo, PMR) "au plus près".

Je croyais que Nominatim permettait de trouver par exemple les aéroports
près d'un lieu.

Soit je ne trouve plus la syntaxe (et Sarah va nous donner la réponse,
merci^^) soit j'ai rêvé.

Mais c'est plus du boulot de routage. et une fois arrivé près, on peut
l'afficher sur une carte à un fort niveau de zoom.

Jean-Yvon



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

Re: [OSM-talk-fr] JOSM et version de Java ?

[osm . sanspourriel]

Le 11/05/2022 à 20:49, pepilepi...@ovh.fr - pepilepi...@ovh.fr a écrit :

Et si oui lequel tu me conseilles ? Celui d'Oracle ou OpenJDK ? (Bon,
j'ai un peu honte de devoir l'avouer, mais je suis sur des windows...)

Merci, bonne soirée

JP


Pas de soucis, pour les Windozes, on essaye d'être accueillant pour les
personnes handicapées ;-).

Si tu comptes utiliser le greffon Kendzi3d vise la 11 :

https://josm.openstreetmap.de/ticket/21348

D'une manière générale si tu utilises la version utilisée pour compiler,
c'est minimiser les ennuis potentiels.

OpenJDK ? Heu c'est passé chez Adoptium et ça s'appelle Temurin, tant
pour le JDK que le JRE.

Trivial, non ?

https://adoptium.net/download,

https://adoptium.net/temurin/archive si tu ne veux pas le JDK 17 mais
par exemple le JRE 11 Windows.

Si tu n'as pas besoin du JDK, contente-toi du JRE.

Oracle ou une solution libre, tu te poses la question ? Ma réponse est
ci-dessus. De plus à chaque nouvelle version Oracle, de nouvelles
restrictions d'utilisation sans payer.

Professionnellement j'utilise les deux. Mais Oracle c'est juste pour
vérifier que ça tourne aussi dessus.

Je pense que don-vip ;-) confirmera que les développeurs utilisent pour
la plupart la version libre.


Si tu veux faire simple tu peux aussi utiliser josm.exe qui embarque une
JVM :

https://josm.openstreetmap.de/wiki/Download

Ou utiliser le jnlp. Là encore kle wiki comporte son tuto en étranger^^.

Jean-Yvon



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

Re: [OSM-talk-fr] Tag pour un transformateur RC ou RS ?

[osm . sanspourriel]

Merci Florent, je n'avais pas vu ta réponse.

Par contre j'avais mis RC comme rural compact sur le poste photographié
(celui que j'indiquais ci-dessous). ça correspond à la description du
fichier.

C'est indiqué à la page
https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques

Et RS est indiqué pour le même poste sur

https://wiki.openstreetmap.org/wiki/Power_networks/France

Par contre sur cette page il y a aussi un RC qui ne correspond pas.

François, qui de François et de François a raison ? ;-)

Jean-Yvon

Le 30/04/2022 à 20:51, Jean-Yvon Landrac a écrit :

RC : c'est un poste de distribution rural compact.
Je pensais que François avait mis ça sur le wiki (je lui avais passé
une photo).
Car non, sans François et si je n'avais pas vu ça, je n'aurais pas su
te renseigner.
Inspiré donc de :
https://www.openstreetmap.org/node/5716114593

Jean-Yvon

Le 29/04/2022 à 18:03, Ludovic Hirlimann - lhirlim...@free.fr a écrit :

Salut,


aujourd'hui dans ma tournée de je chope des données je suis tombé sur
ça
https://drop.chapril.org/download/c1be2086bcd58db3/#JVFFgtuDsREzkdopj9HceA
.


Y a rien dans le wiki qui s'en approche, je le tag comment ?


Ludovic




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

Re: [OSM-talk-fr] Tag pour un transformateur

[osm . sanspourriel]

design:ref
   RC
location
  green
man_made  street_cabinet

operator
  Enedis

power 
substation

ref:FR:gdo

street_cabinet  power
substation

minor_distribution

transformer

distribution


utility 
power 
voltage:primary

2
voltage:secondary

400


green : pas sûr : je vois pas trop si c'est sur un mur, un poteau.
RC : c'est un poste de distribution rural compact.
Je pensais que François avait mis ça sur le wiki (je lui avais passé une
photo).
Car non, sans François et si je n'avais pas vu ça, je n'aurais pas su te
renseigner.
Inspiré donc de :
https://www.openstreetmap.org/node/5716114593

Jean-Yvon

Le 29/04/2022 à 18:03, Ludovic Hirlimann - lhirlim...@free.fr a écrit :

Salut,


aujourd'hui dans ma tournée de je chope des données je suis tombé sur
ça
https://drop.chapril.org/download/c1be2086bcd58db3/#JVFFgtuDsREzkdopj9HceA
.


Y a rien dans le wiki qui s'en approche, je le tag comment ?


Ludovic




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

Re: [OSM-talk-fr] Base de donnée nationale des bâtiments

[osm . sanspourriel]

Pourquoi utilises-tu alors OSM ?

OSM est une source secondaire voir tertiaire ou plus.

L'avantage c'est que des erreurs de la base primaire (telle que les
boîtes postales passées à plus d'un km de leur lieu réel) sont corrigés.

Que des trous (avec d'autres données possiblement de qualité moindre)
sont complétés. En quoi je comprends Christian : il faut que la source
soit claire et la confiance dans la validité des données aussi.

Je ne dis pas que tu as forcément tort. Mais si comme tu le penses c'est
toujours valable, je ne comprends pas pourquoi tu contribues à OSM
puisque selon toi ce sera toujours moins bon.

Jean-Yvon (un peu provocateur mais pas vraiment)

Le 20/04/2022 à 19:37, Yannick - yann...@voyeaud.org a écrit :

Le 20/04/2022 à 19:21, Christian Quest a écrit :


Attention, la qualité du contenu de cette base n'est pas bien
clair... je ne l'utiliserai pas comme source pour OSM, il vaut mieux
utiliser les bases qui lui servent de source.


Bonsoir,

Il faut toujours utiliser la source primaire même si la secondaire
semble être de meilleure qualité.
Il faut toujours s'adresser au bon dieu plutôt qu'à ses saints.

Et ceci est vrai quelque soit le domaine.

Amitiés

___
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] Dégradations à annuler (dont voie ferrée)

[osm . sanspourriel]

C'était plus de boulot que prévu car j'ai fait une passe sur les objets
modifiés en dernier par ce vandale.

Denis, tu pourras vérifier https://www.openstreetmap.org/way/341777352 ?

J'ai fait l'hypothèse que ce que tu avais fait était mieux que ce qu'il
avait trouvé avant de vandaliser.

J'ai même trouvé son compte précédent :
https://www.openstreetmap.org/user/Joyeux%20Bernard

Il n'y a plus trace d'aucune de ses contributions. 100 % de déchets !

Et merci au DWG au passage.

Jean-Yvon

Le 20/04/2022 à 20:24, Jean-Yvon Landrac a écrit :

Volontaire !

;-)

Je fais ça dans la foulée.

Le 20/04/2022 à 19:42, Francois Gouget - fgou...@free.fr a écrit :

Je suis tombé sur un groupe de changesets douteux :
https://www.openstreetmap.org/changeset/103961825
https://www.openstreetmap.org/changeset/103961280

Ils ajoutent des bureaux Google France, Microsoft France et Samsung
France dans une petite rue de Saint-Émilion.

Il se trouve que leur auteur, joyeuxbernard687, a été banni pour 9 ans
encore. Mais les changesets ci-dessus n'ont pas été annulés. Comme je ne
sais pas faire de revert si je m'y colle ça ne sera probablement pas
bien fait. Du coup quelqu'un pourrait-il se porter volontaire pour
annuler les changesets ci-dessus ?

J'ai l'impression que la plupart de ses autres changesets (il n'y en a
que 20) ont été annulés manuellement (pas via un revert).





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

Re: [OSM-talk-fr] Dégradations à annuler

[osm . sanspourriel]

Volontaire !

;-)

Je fais ça dans la foulée.

Le 20/04/2022 à 19:42, Francois Gouget - fgou...@free.fr a écrit :

Je suis tombé sur un groupe de changesets douteux :
https://www.openstreetmap.org/changeset/103961825
https://www.openstreetmap.org/changeset/103961280

Ils ajoutent des bureaux Google France, Microsoft France et Samsung
France dans une petite rue de Saint-Émilion.

Il se trouve que leur auteur, joyeuxbernard687, a été banni pour 9 ans
encore. Mais les changesets ci-dessus n'ont pas été annulés. Comme je ne
sais pas faire de revert si je m'y colle ça ne sera probablement pas
bien fait. Du coup quelqu'un pourrait-il se porter volontaire pour
annuler les changesets ci-dessus ?

J'ai l'impression que la plupart de ses autres changesets (il n'y en a
que 20) ont été annulés manuellement (pas via un revert).





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

Re: [OSM-talk-fr] Base de donnée nationale des bâtiments

[osm . sanspourriel]

Tout simplement peut-être parce que la BDTOPO n'est qu'une de la
vingtaine de sources.

https://gitlab.com/BDNB/base_nationale_batiment/-/wikis/M%C3%A9thodologie/methodologie-de-croisement

---

La BDNB est le fruit du *croisement* géospatial d'une *vingtaine de
bases de données* issues d'organismes publics.

Elle contient une carte d'identité pour plus de 21.4 millions de
bâtiments, résidentiels ou tertiaires.

Cette carte d'identité comprend plus de 250 informations relatives à :

 * la morphologie des bâtiments (volumes 2.5D, surfaces, hauteurs)
 * les usages hébergés par le bâtiment,
 * les matériaux constitutifs et les équipements techniques,
 * les consommations énergétiques,
 * la performance énergétique (étiquette DPE, consommation simulée, etc…)
 * des données administratives et économiques.

La BDNB couvre la France métropolitaine, y compris la Corse.


Le 19/04/2022 à 16:16, Serge Faraut - serge.far...@toulouse.archi.fr a
écrit :

Bonjour à tous,

Je regarde personnellement de près ce projet ambitieux du CSTB participant, 
entre autres, à un projet portant sur la rénovation des bâtiments utilisant une 
autre approche d'analyse.

Par contre concernant le renseignement de la hauteur des bâtiment, pourquoi ne 
pas utiliser directement la donnée source nationale qu'est la BDTOPO de l'IGN?
Surtout que celle-ci est désormais également en OpenData...

Bien à vous,
Serge.

April 7, 2022 11:20:22 PM CEST "Sébastien Dinot"  
wrote:Bonjour à tous,

Je ne suis la liste nationale que de très loin ces derniers mois, mais
je n'ai pas vu passer l'annonce de la libération Base de Données
Nationale des Bâtiments (BDNB) :

https://www.data.gouv.fr/fr/datasets/base-de-donnee-nationale-des-batiments-version-0-6/

Je viens de tomber sur une image utilisant cette base ici :

https://gitlab.com/BDNB/base_nationale_batiment/-/wikis/home

De quoi alimenter la hauteur ou le nombre d'étages des bâtiments dans
OSM.

Sébastien




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

Re: [OSM-talk-fr] audio mapping et smartphone

[osm . sanspourriel]

Si le calibrage est persistant d'une fois sur l'autre, tu peux une fois
être accompagné et laisser la personne qui n'est pas au volant calibrer
l'appareil.

Et sans doute suivant la vitesse prévue plusieurs calibrages.

Deux autres pistes sans doute plus aléatoires :

 * Il existe des commandes vocales, certes tu vas devoir démarrer avant
   (le temps de dire "enregistre") et à grande vitesse ça risque d'être
   problématique.

 * Tu peux toujours, dans les idées qui ne sont pas forcément
   opérationnelles mais qui théoriquement peuvent marcher, avoir un
   anti-bruit de casque audio pour annuler le bruit moteur. Je doute
   que de telles applis existent mais un casque anti-bruit dynamique
   c'est efficace.

Le 07/04/2022 à 11:30, Marc_marc - marc_m...@mailo.com a écrit :

c'est pas sur que calibrer à l'arrêt soie valide pour le bruit
de roulage... sauf à lancer le calibrage en roulant ce qui moyen
(pas pire que d'appuyer sur un bouton de l'autoradio sans regarder,
mais pas mieux non plus)



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

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[osm . sanspourriel]

Non pour les mêmes raisons : pas forcément lié à la géographie,
générique, faux amis...

Reste donc catchment_area déjà proposé par Florian (spécifique, non
ambigu et de plus en anglais britannique).

https://www.linguee.fr/anglais-francais/traduction/coverage.html


 couverture
 
 f

This radio station provides the best coverage of current events. Cette
station de radio fournit la meilleure couverture de l'actualité.
The hockey tournament will be given limited media coverage. Le tournoi
de hockey recevra une couverture médiatique limitée.


 assurance
  f

My job gives me access to good health coverage. Mon travail me donne
accès à une bonne assurance maladie.


 reportage
  m

The journalist tried to keep his coverage neutral. Le journaliste a
essayé de rester neutre dans son reportage.
plus rare :
garantie
 f
·
protection
 f
·
portée
 f
·
champ  m
·
retransmission
 f



Le 06/04/2022 à 16:45, Philippe Verdy - ver...@gmail.com a écrit :

Plutôt "coverage" qui est à mon sens le seul mot désignant une étendue
géographique, voire "service:coverage" si on veut limiter les dégâts futurs.



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

Re: [OSM-talk-fr] Mise en valeur des canaux de communication sur Id

[osm . sanspourriel]

OSM est un projet ouvert, il est donc normal de favoriser les
plateformes libres.

Qu'en fin de liste on mette un canal non GAFAM(*), pourquoi pas.

(*) mais le seul encore autorisé dans une dictature (ce qui sous-entend
que le côté crypté... mais bon c'est un canal public)

Le 29/03/2022 à 17:29, Pierre Doucineau - pierre.do...@gmail.com a écrit :

À propos des plateformes propriétaires, je ne considère pas du tout leur
utilisation comme une aberration (surtout Telegram qui n'appartient pas à
un GAFAM).



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

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[osm . sanspourriel]

J'aurais dû préciser que j'avais exclu target pour la raison que tu
indiques : une clé dont les valeurs possibles et le sens dépendent du
contexte rendent a minima les outils de validations plus compliqués. Là
le sens car target por les services consulaires c'est un critère de
nationalité, peu importe le lieu alors qu'ici c'est un critère de lieu
peu importe la distance.

catchment_area a l'avantage d'être vraiment non ambigu mais comme toi je
crois que range est suffisamment clair.

On peut à la limite voir une différence (la première est la zone
d'influence alors que range serait la limite théorique) qu peut être
différente en cas de chaine qui fera distribuer par le plus proche - ou
celui qui n'est pas débordé).

range a l'avantage en étant moins spécifique de pouvoir être étendu (par
exemple pour libérer la partie équivalente de la clé network des réseaux
cyclistes).

Comme tu dis visibility n'est pas la bonne clé mais c'est le même concept.

Donc range ou catchment_area, les deux me vont.

D'autres avis ? Des compléments ?

Après on verra si Marc ou quelqu'un d'autre veut affronter^^ la liste
tagging. Dans ce cas faire voter la clé pour les entrepôts, ne proposer
de l'étendre qu'après histoire de favoriser la probabilité que l'idée
soit approuvée.

Jean-Yvon

Le 26/03/2022 à 20:00, Florian LAINEZ - winner...@free.fr a écrit :

warehouse=local pour distinguer des plateformes logistiques livrant sur
une région / un pays ?

Là on commence à parler !

En marking il existe un concept de "zone de chalandise" qui est l'aire
couverte par la livraison ou le lieu d'habitation des clients.
Du coup, peut-être *target=local;regional;national;international* ? target
 étant déjà utilisé sur les
ambassades pour désigner le pays cible.
Néanmoins target n'est pas très spécifique, peut être :
- catchment_area (qui est la traduction de zone de chalandise)
- range (mon choix préféré)
- reach
- scope

Il existe aussi visibility
 pour panneaux
d'affichage : visibilty=house;street;area qui est similaire mais pas
applicable en l'état.

Le ven. 25 mars 2022 à 18:12,  a écrit :


Par ailleurs Florian, quand tu disais qu'Amazon n'était pas de la
vente au détail, si, c'est de la vente au détail.

Marc se sera reconnu.

Philippe, dark store est bien un terme anglais :

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

The term *dark store*, *dark shop*, *dark supermarket* or *dotcom
centre* refers to a retail outlet or distribution centre
 that caters
exclusively for online shopping

Aux nuisances avérées :
  > In January 2022 the city of Amsterdam froze the opening of new dark
stores because of noise and increased scooter traffic near stores, also
the appearance of the stores was considered unkempt.

Mais ce qui est proposé (sans réinventer la poudre) a ma préférence.

Peut-être ajouter une clé

warehouse=local pour distinguer des plateformes logistiques livrant sur
une région / un pays ?

(ou delivery, range... : range c'est utilisé pour les golfs,
https://www.openstreetmap.org/way/404843925#map=16/41.3302/-96.0157 !),
là on est plus proche des concepts de classification des réseaux
cyclistes : local; regional, national...).

Jean-Yvon



___
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] [OSM-Talk-fr] tagger les dark store

[osm . sanspourriel]

Par ailleurs Florian, quand tu disais qu'Amazon n'était pas de la
vente au détail, si, c'est de la vente au détail.


Marc se sera reconnu.

Philippe, dark store est bien un terme anglais :

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

The term *dark store*, *dark shop*, *dark supermarket* or *dotcom
centre* refers to a retail outlet or distribution centre
 that caters
exclusively for online shopping

Aux nuisances avérées :
> In January 2022 the city of Amsterdam froze the opening of new dark
stores because of noise and increased scooter traffic near stores, also
the appearance of the stores was considered unkempt.

Mais ce qui est proposé (sans réinventer la poudre) a ma préférence.

Peut-être ajouter une clé

warehouse=local pour distinguer des plateformes logistiques livrant sur
une région / un pays ?

(ou delivery, range... : range c'est utilisé pour les golfs,
https://www.openstreetmap.org/way/404843925#map=16/41.3302/-96.0157 !),
là on est plus proche des concepts de classification des réseaux
cyclistes : local; regional, national...).

Jean-Yvon



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

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[osm . sanspourriel]

De plus avec l'exemple de Monoprix utilisant son sous-sol comme base
logistique d'Amazon, c'est criant : on est bien dans la partie logistique.

Par ailleurs Florian, quand tu disais qu'Amazon n'était pas de la vente
au détail, si, c'est de la vente au détail.

La vente au détail veut dire que le client peut acheter une ou quelques
pièces, par opposition au grossiste qui va se réapprovisionner en grande
quantités (ou pas d'ailleurs masi à moindre coût), c'est à dire que dans
le cas de la ventre en détail, c'est le client final (ou son
installateur) qui va acheter, sans contrainte forte sur le nombre de
pièces à acheter en une seule fois.

Jean-Yvon

Le 25/03/2022 à 07:53, Florian LAINEZ - winner...@free.fr a écrit :

la logistique du dernier km est une activité industrielle ?
c'est une bonne remarque : c'est à la croisée d'une activité industrielle
et de "retail". Néanmoins, si je devais choisir, étant donné que l'accès
est interdit au public, je pencherai du côté industriel/logistique

Du coup, j'ai l'impression qu'on est toujours sur :
- industrial=warehouse
-
operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango;Deli;Zapp;Rohlik;Bam
Courses



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

Re: [OSM-talk-fr] Bilan 2021 de la convention Enedis / OSM France

[osm . sanspourriel]

> Absolument génial de voir un tel engouement pour un sujet qui paraît au
> premier abord très technique.

Au second aussi ;-)

> Bravo à tous !

+1

> J'ajoute un retour positif : +1 félicitations pour tout ce travail !

+1 mais j'ajouterais un bémol : il manque des outils pour que l'on
puisse dérouler ça plus facilement.

Par exemple par chez moi j'ai une terminaison de ligne 20 kV sur un
poste électrique, c'est un truc classique mais je ne sais pas trop le
faire en OSM, du coup j'ai Osmose qui braille deux fois.

Jean-Yvon



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

Re: [OSM-talk-fr] Comment tagguer un 'local à vélo'

[osm . sanspourriel]

Le 27/02/2022 à 19:21, Vincent Bergeot - vinc...@bergeot.org a écrit :


Le 27/02/2022 à 17:59, Vincent Bergeot a écrit :

PS : Comment tagguer un 'local à vélo', j'ai failli répondre "avec
une bombe de peinture" ...

J'ai failli répondre comme un mur^^

Je trouve que bicycle_parking=building, shed sont vraiment surprenants
en fait (dans ma représentation :) )


Oui bicycle_parking=building n'a guère de sens : on dit building=*, avec
le * correspondant à l'architecture, donc à la limite
building=bicycle_parking.

Ceci dit pour les parkings de véhicules légers, on met bien parking=surface.

La localisation me semble suffisante pour savoir si le parking est à
l'intérieur, sous un abri, etc...

Et donc j'ai tendance à penser que bicycle_parking doit plus décrire
l'accroche que le lieu.

Jean-Yvon



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

Re: [OSM-talk-fr] MS BOT

[osm . sanspourriel]

Le 25/02/2022 à 23:31, Christian Rogel -
christian.ro...@club-internet.fr a écrit :


Les rédacteurs de plaques de rue ont généralement suivi ces règles et les 
graveurs et émailleurs aussi.


À BON, ILS CONNAISSENT AUTRE CHOSE QUE LES MAJUSCULES ? Actuellement il
est encore courant de voir la partie principale du nom ENTIÈREMENT en
majuscules. Mais contrairement à Fantoir ils ont de plus en plus les
majuscules accentuées.

Puisses-tu avoir raison ! Hélas sur le terrain les règles typographiques
ne sont pas toujours appliquées, souvent ignorées (il suffit de voir les
noms de communes nouvelles qui ont dû être corrigés, sans parler des
coquilles tel ce fondateur de l'Europe fait musicien sur le terrain -
Robert Schuman(n) à Guidel).

Wokisme : non à la Blankérisation des esprits !

Jean-Yvon



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