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

[JB]

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 soucis c'est : quel tag principal pour un endroit
composé de différente espace d'arbre, de zone ou pas
exploité en sylviculture, etc

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 ?

[JB]

Le 12/07/2022 à 19:19, Marc Mongenet a écrit :

  A moins que ce soit dû à mon incompétence avec les multipolygon. Je ne sais 
pas.

Non. Ou alors, on est nombreux à être incompétents par ici.
J'ai du mal à comprendre qu'on conseille encore d'utiliser les nœuds de 
la voirie pour aligner des landuses. À part pour l'idée esthétique de la 
carte, je ne comprends pas. C'est utile pour dégoûter de la maintenance 
par la suite.

JB.



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

Re: [OSM-talk-fr] Défis MapRoulette pour contrôles de qualité - highway=rest_area

[JB]

Bof, le genre de solution « tagguer pour le détecteur d'erreurs », qui 
augmente la complexité quand on veut retravailler la zone. Ça me 
rappelle les nœuds communs voirie/parking, une belle galère à reprendre 
par la suite.

JB.

Le 08/07/2022 à 18:27, pepilepi...@ovh.fr a écrit :

Le 08/07/2022 à 15:35, Christian Quest a écrit :

Le 08/07/2022 à 14:19, Marc_marc a écrit :

Bonjour,

Le 08.07.22 à 12:01, Christian Quest a écrit :

Ways with highway=rest_area should not be checked for
connectivity... the wiki confirms that this tag is used only on
areas and nodes, not unclosed ways.

je comprend pas le lien que tu fais entre les 2 :
une aire (une aire de repos d'autoroute, un parking dans un centre
commercial, ...) est connectable au réseau routier

d'ailleurs pour ce tag le wiki dit "The junction way from the highway
is mapped with highway=*_link"
s'il y a jonction, c'est que c'est connecté, router jusqu'à l'entrée
est quand même bien mieux que router à proximité en espérérant que
l'utilisateur trouve l'entrée par lui-même

Il n'y a pas forcément de noeud commun, un highway=* peut traverser
l'emprise de l'aire de service qui n'a rien de routable en elle même
donc les erreurs de connectivité me semblent être des faux positifs.


J'ai aussi commencé ce défi. La solution simple que j'ai trouvée pour
que tout le monde soit content est de créer un noeud d'intersection
entre le rest_area et la bretelle qui la dessert... exemple ici :
https://www.openstreetmap.org/way/459036377 . J'ai intégré au rest_area
https://www.openstreetmap.org/node/8033594814 qui existait sur
https://www.openstreetmap.org/way/23120179.

En toute rigueur topologiquement ça sert à rien, mais c'est pas faux, et
ça résoud le problème de connexion... (certes, ce serait plus propre
d'adapter la requête en excluant les "highway=rest_area", mais comme je
l'ai déjà dit je n'ai aucune connaissance de ces requêtes)


Bien évidemment s'il y a une levée de boucliers contre ma rustine
j'arrête...


Bonne fin de semaine,

JP






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

Re: [OSM-talk-fr] Tag tourism=alpine_hut

[JB]

Oui. Ou non. C'est un lieu pour passer une nuit au milieu d'une 
randonnée de plusieurs jours. Pour moi, ce n'est pas forcément opposé à 
alpine_hut. J'aime bien regarder l'idée du tag plutôt que sa définition 
précise, qui ne couvre jamais tous les cas.

JB.

Le 09/12/2020 à 23:24, mides.map a écrit :
C'est un peu là le problème, on ne s'attend pas à trouver une 
structure classée "refuge d'altitude" dans ce type de zone géographique.


Le 09/12/2020 à 22:57, Eric SIBERT via Talk-fr a écrit :

Et que dire du refuge CAF de Bonneval-sur-Arc?

http://www.refuges.info/point/110/cabane-non-gardee/Mont-Cenis-Grand-Paradis/Chalet-de-Bonneval-sur-Arc/ 


https://chaletbonnevalsurarc.ffcam.fr/

En zone résidentielle et à 50 m de la mairie ;-)

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





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

Re: [OSM-talk-fr] Offrir une une carte des adresses à Theizé

[JB]

Bonjour,
J'avais aussi regardé les données OSM pour voir s'il était possible et 
raisonnablement facile de produire un plan de ville semi-manuellement.
Et en fait, je n'ai pas approfondi : pour moi, ce n'est pas utile à ce 
stade. Trop de voies ont un nom erroné, trop de voies ne sont pas 
nommées (dans OSM). Trop de voies qui devraient être corrigées pour 
obtenir quelque chose de propre.
J'en retiens que la proposition de Vincent me semble plus raisonnable 
que celle de commencer à importer des points adresses dont une bonne 
partie ne correspondra à aucune voirie.

JB.

Le 26/11/2020 à 21:54, Brice a écrit :

Le 22/11/2020 à 17:59, Vincent de Château-Thierry a écrit :
Je ne suis pas sûr de partager ton diagnostic quand je vois la liste 
des noms de voies dans 
https://bano.openstreetmap.fr/fantoir/#insee=69246=0. Je serais 
donc plutôt partisan d'une revue des noms de voies de la commune, qui 
peut s'accompagner de l'import des adresses pour chacune en utilisant 
JOSM via un clic à droite de chaque ligne dans la colonne "Adresses à 
intégrer".


J'étais parti sur cette piste mais l'import tels quels et préalables 
des points adresses me semble préférable.
En effet je constate que des points adresses correspondent à des voies 
non existantes dans OSM mais aussi non existantes/nommées sur le 
cadastre, exemples (proches de la place de l'Eglise) : Rue Saint 
Antoine, Place des Tailleurs de Pierre, Impasse du Puits...
Je prévois donc d'importer les adresses, tracer les voies manquantes 
quand possible sans ambiguïté et pour les voies avec tracé inconnu les 
signaler à l'élu de l'article.
Peut-être se prendra t'il au jeu de les tracer lui-même dans OSM, qui 
sait ?





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

Re: [OSM-talk-fr] De la BAN dans BANO... enfin !

[JB]

Bonjour Vincent,
Merci pour le boulot de fond sur le sujet !
Un petit coup d'œil de mon coté, et je suis surpris de voir que des 
éléments rapprochés n'ont plus de nom FANTOIR indiqués, par exemple 
89368B091R (hamlet : La Bruyère) sur 
http://bano.openstreetmap.fr/fantoir/#insee=89368=5. Sans garantie, 
il me semble que j'avais forcé ces rapprochements avec une orthographe 
différente entre le terrain et FANTOIR.

JB.

Le 31/10/2020 à 22:53, Vincent de Château-Thierry a écrit :

Bonsoir,

Depuis quelques jours la base Adresses[1] produite par Etalab à partir 
de multiples sources est intégrée dans BANO. Le produit Adresses est 
une émanation de l'ancienne BAN, enrichie et diffusée sous licences LO 
et ODbL. On y retrouve entre autres le Cadastre, ce qui justifie côté 
BANO de ne plus intégrer le Cadastre en tant que tel.


Alimenter BANO avec la BAN, on en parle avec Christian depuis que 
la BAN existe, en gros. C'est donc mine de rien une étape symbolique 
importante, rendue possible par l'existence même de BANO. On peut être 
collectivement fiers d'en être là aujourd'hui, 6 ans après le début de 
ce graaand lobbying collaboratif libre ;)


Débrancher le Cadastre et alimenter BANO avec la BAN à la place a des 
implications à différents niveaux. Dans le détail :


- l'import de données. C'est l'étape initiale et elle est réalisée, 
c'est pour ça qu'on peut commencer à en parler :). La mise à jour BAN 
se fait sur un rythme hebdomadaire.


- l'export : cette étape reste à faire. Pour l'instant l'ajout de la 
BAN n'est pas visible pour les consommateurs de BANO. Les fichiers 
exportés chaque nuit sont encore branchés sur le mix OSM+Cadastre.


- les outils de contrôle "Fantoir" [2] tirent parti de la BAN depuis 
ce soir, d'où ce mail. Vous pourrez observer sur les communes que vous 
connaissez des changements pour les voies sans rapprochement. 
Certaines basculent côté "voies sans adresses" car leurs uniques 
adresses étaient des pseudo-adresses du Cadastre (les adresses en 5000 
et 9000) non reprises par la BAN. D'autres font le chemin inverse et 
deviennent des "voies avec adresse" car le Cadastre (trop ancien ?) ne 
leur connaissait aucun numéro alors que la BAN en fournit.


- le rendu carto. J'ai proposé une pull request [3] qui pourrait faire 
le job pour que le rendu soit à nouveau fonctionnel. Elle est 
maintenant dans les mains de Christian pour être prise en compte.


Pour info, une discussion (ouverte à tous) se passe à 
https://github.com/osm-fr/bano/issues/204 pour documenter les process 
BANO. Et enfin, un merci à Jérôme "Olyon" Amagat qui s'est plongé dans 
BANO côté traitements et côté rendu carto, avec plein de suggestions 
constructives.



vincent

[1] : https://adresse.data.gouv.fr/donnees-nationales

[2] : http://bano.openstreetmap.fr/fantoir/

[3] : https://github.com/osm-fr/bano-cartocss/pull/5


___
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] Services publics et administrations locales

[JB]

Hello,
Autant, pour une mairie, le tag amenity=townhall est suffisamment 
standardisé, clair pour que name = Mairie soit redondant (comme pour les 
bureaux de poste, les gares, par exemple).
Par contre, quand on s'éloigne d'un objet classique, pour des CAF, CPAM, 
Pole Emploi… dont la spécificité est française, il me semble « normal » 
de garder ces termes dans leurs noms. Les tags de principaux de l'objet 
sont trop peu connus, usités, standardisés, compris, « compréhensibles 
par un humain standard » pour le décrire clairement.
name = CAF (de X) / Pôle Emploi (de X) me semble normal, logique, 
acceptable.

JB.

Le 04/10/2020 à 12:26, Noémie Lehuby via Talk-fr a écrit :


Bonjour,

En effet, il y a un sujet sur le/les noms.
Je suis allé vérifier ce qu'il y a écrit sur la porte de quelques 
services près de chez moi : Sous-Préfecture de Torcy, Caf de 
Seine-et-Marne mais Pôle Emploi.
Pour les abréviations, certaines sont complètement passées dans le 
langage courant : il y a écrit Caf (pas CAF ou Caisse d'Allocations 
Familiales) sur la porte, et perso je ne sais pas ce que veut dire 
URSSAF...
On peut faire comme pour les gendarmeries et conserver le nom complet 
et explicite fourni notamment dans le fichier open data dans 
official_name (Caisse d'Allocations Familiales (Caf) de Seine-et-Marne 
- accueil de Lognes) ?


Autres questions :

  * que pensez-vous de la proposition d'Adrien d'utiliser
prioritairement office=government et governement=* (plutôt
notamment que social_facility=outreach) :
https://wiki.openstreetmap.org/wiki/Talk:France/Services_Publics
  * network = Pôle Emploi ou operator = Pôle Emploi ?

nlehuby

Le 03/10/2020 à 19:00, lejun a écrit :

L'idée me plaît, rien à redire dessus. Par contre l'usage de name de
dérange :
- D'une part je me demande dans quelle mesure on privilégie une valeur
explicite, name=CPAM de X, plutôt que name=X + network=CPAM
- D'autre part je crois que l'usage d'abréviation comme CAF ou CPAM
risque de poser problème.
Peut être que la solution serait d'utiliser la clé alt_name ou
local_name pour signaler qu'en pratique courante on parle effectivement
de la CPAM de X.

Le 03/10/2020 à 18:48, Noémie Lehuby via Talk-fr a écrit :

Hello,

Comment on cartographie une CAF ? un Pôle Emploi ? un centre des 
impots ?

J'ai initié la page de wiki suivante pour tenter de répondre à ces
questions : https://wiki.openstreetmap.org/wiki/France/Services_Publics

Comme vous pouvez le voir, pour le moment c'est plus un texte à trou
qu'une vraie page de wiki utile ;)

Pour la plupart de ces lieux, on a des bases open data existantes 
(voire

déjà une analyse Osmose) donc il y a de la matière pour un ou plusieurs
prochains projets du mois une fois qu'on sera d'accord sur la 
manière de

mapper tout ça.

nlehuby

--
Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté

___
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] Fontaine...

[JB]

amenity = fountain + drinking_water = no / conditional (eau non 
surveillée, parfois indiquée « non potable »)


Le 27/09/2020 à 15:47, Jacques Lavignotte a écrit :

Bonjour,

https://i.postimg.cc/CxTLyS41/IMG-20200926-184649.jpg

ne semble pas être une amenity=fountain selon le Saint Wiki..

Mais c'est quoi donc que ça se tagge ?

J.





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

Re: [OSM-talk-fr] comment taguer le stockage des déchets verts et agricoles?

[JB]

Je ne sais pas si c'est moi, JB.  Si vous insistez, je ne crois pas que 
je ferai mieux que Stéphane :
Ensilage : sous bâche lisse noire avec dessus boudins lourds ou pneus 
(il me semble que ce serait interdit maintenant, mais on en voit bien 
sur l'exemple de Stéphane). Les deux cellules de gauche semblent 
clairement de l'ensilage. Destiné à l'alimentation du bétail, 
probablement des bovins.
Enrubanné : cylindres vert clair à gauche de l'ensilage. Destiné à 
l'alimentation.
Cellule à droite de l'ensilage : difficile à dire, je pense du foin, 
peut-être de l'enrubanné. Peut-être paille, mais peu probable.
À gauche du bâtiment : probablement de la paille qui sera couverte aux 
premières pluies. Peut-être du foin qui sera également couvert.

Pas sûr d'apporter une grande plus-value ici.
JB.

Le 31/08/2020 à 14:31, osm.sanspourr...@spamgourmet.com a écrit :


Paille ou foin sur une orthophoto ce n'est pas évident.

Dans le coin sur une même parcelle il y a production alternative de 
céréales (donc avec comme sous-produit de la paille pour le blé et des 
bébés sans bras pour le maïs :-() et d'herbe (donc foin et ensilage) : 
blé/maïs/herbe.


Les ballots à gauche sont clairement du foin (ensilage par enrubannage 
pour reprendre la dénomination utilisée par Wikipédia).


Ici au moins la paille est plutôt retenue par un filet plastique pas 
par un film plastique.


La paille n'est pas toujours valorisée, donc un compostage ne me 
semble pas stupide (mais je n'ai vu cette installation que via 
l'orthophoto). Exemple de paille qui reste pourrir 
https://www.openstreetmap.org/edit?editor=id#map=21/47.81463/-3.49739 
(choisir le fond ESRI clarifié).


Au nord de l'installation précédente il semble y avoir suivant les 
saisons de l'ensilage par enrubannage (foin) et des balles de paille 
qui restent pourrir.


L'ensilage se fait plutôt dans des silos fermés (ça peut comme indiqué 
par l'article être un simple bâchage sur sol bétonné) ou des granges. 
Là ça semble être à l'air libre sur toutes les photos, donc peu 
probable sauf s'il existe de l'ensilage aérobie.


D'un autre côté vu l'aspect du sol dans la parcelle à l'ouest, on voit 
qu'il y a de l'élevage bovin.


J'ai bien dit bâché pas caché (ici on voit le béton au sud : 
l'ensilage laisse usuellement l'entrée vide donc on voit le sol à cet 
endroit s'il n'y a pas trop de matières dessus).


Si JB ou une autre personne peut nous aider à interpréter ces 
orthophotos, je suis preneur.


Jean-Yvon

Le 31/08/2020 à 13:43, Yves P. - yves.prat...@gmail.com a écrit :

https://www.openstreetmap.org/edit?editor=id#map=20/47.75009/-3.49276

C'est une zone de stockage, ici sur la droite on voit des bottes 
(rouleaux) de paille.

… de foin


A gauche soit de la paille compostée soit du fumier.
j'ai l'impression que c'est de l'ensilage 
<https://fr.wikipedia.org/wiki/Ensilage>


Souvent un sol bétonné (comme indiqué par Philippe), le dessus peut 
être bâché.

caché car ensilage


JB, peux-tu nous apporter tes lumières ?
:)


Yves, c'est du stockage, éventuellement de la maturation pas du 
recycling au sens usuel.

On est d'accord :)
Je parlais uniquement de la valeur, pas de la clé.

Si on a d'un côté recycling:*green_waste*=*, tant qu'à faire utiliser 
content=*green_waste* de l'autre (et non pas content=*green*)

;)

__
Yves

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


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


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

Re: [OSM-talk-fr] Après Facebook Cesium...

[JB]

Bonjour,
C'est passé sur la liste OSMF-talk : 
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006864.html 
et suivants.
Le problème de ce board, c'est qu'ils aiment beaucoup les discussions en 
tête-à-tête qui donnent l'impression d'être plus efficaces pour avancer, 
mais laissent beaucoup de monde sur le coté. Ils communiquent souvent a 
posteriori, sur une décision figée ou quasiment figée. Ils ne semblent 
pas non plus adeptes de la contradiction, et n'évoluent guère suite à 
des critiques, une de leur technique étant de faire l'autruche jusqu'à 
épuisement de la contradiction, puis de communiquer à nouveau, souvent à 
l'identique de leur premier message.
Le genre de souci que rencontre OSMbuildings n'est vu qu'après-coup, et 
n'est pas géré (et ne le sera probablement jamais).

JB.

PS : même si je critique la manière d'avancer du board sur certaines 
thématiques, je reconnais qu'au moins, « il se bouge ».


Le 31/08/2020 à 10:28, Christian Quest a écrit :

Le 31/08/2020 à 09:59, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour,

je suppose que vous avez vu passer ça dans hebdOSM :
https://medium.com/@osmbuildings/why-were-not-going-to-support-a-multimillion-dollar-company-bde6116a954d 

<https://medium.com/@osmbuildings/why-were-not-going-to-support-a-multimillion-dollar-company-bde6116a954d>. 



Alors que la fondation jusqu'ici voulait protéger les noms proches de
OpenStreetMap voici qu'il autorise une entreprise à préempter le nom
d'un projet libre (OSM Buildings) en accordant la marque “Cesium OSM
Buildings”... à Césium qui profite des données préparées par OSM 
Buildings.


Les bras m'en tombent.

Si ça vous choque aussi, il serait peut-être bon que l'association
proteste officiellement.

Jean-Yvon



Je ne vois pas vraiment d'annonce sur l'accord d'une marque 
particulière dans le post de la fondation.


Si c'est le cas, il y a peut-être un problème de process et de 
publicité de ces démarches liées aux marques "OSM" (process que je ne 
connais pas).


Quand quelqu'un fait une telle demande, ceci devrait être publié, 
discuté ouvertement avant que la fondation ne prenne une décision.


Est-ce le cas ?


Je tique plus sur le ton du communiqué, trop marketing de mon point de 
vue.







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

Re: [OSM-talk-fr] recherche d'adresses et POI, comment quitter Google ?

[JB]

Lui semble fonctionner, en tous cas :
http://photon.komoot.de/api/?q=Centre%20Hospitalier,%20Luynes
qui renvoie notamment : https://www.openstreetmap.org/relation/4130150
JB

Le 13/08/2020 à 18:26, Cyrille37 OSM via Talk-fr a écrit :

Bonjour,

Sujet récurent.

Avec Nominatim https://osm.org la recherche de "Centre Hospitalier, 
Luynes" ne donne aucun résultat, il faut saisir le nom complet "Centre 
Hospitalier Jean Pagès, Luynes".


Sur la base adresse data.gouv.fr https://adresse.data.gouv.fr/map 
aucun résultat pour "Centre Hospitalier Jean Pagès, Luynes" puisque ce 
n'est pas une adresse.


Heureusement, l'appli Smartphone OsmAnd trouve "Centre Hospitalier, 
Luynes".


Connaissez-vous un moteur de recherche sur le Web ou en API qui trouve 
les demandes raccourcies comme "Centre Hospitalier, Luynes" ?


Merci,
Cyrille37.



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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[JB]

Je profite de la discussion pour poser la question de la traduction de « 
etat_fonct » de GeoDAE, convertie dans OSM en :
operational_status=[[Tag:operational_status=operating/out_of_order/closed/short_term_absence/unknown|operating/out_of_order 
/closed/short_term_absence/unknown]] 
(https://wiki.openstreetmap.org/wiki/FR:Tag:emergency=defibrillator#Liste_des_donn.C3.A9es_obligatoires)

Est-ce vraiment une bonne idée ?
J'ai l'impression qu'on essaye de coller au plus près des données 
fournies. Si un défibrillateur est hors-service ou supprimé, je 
conseillerai plutôt de la cartographier en disused:emergency=defibrillator.
(Si je cherche un DAE, je cherche emergency=defibrillator, sans 
forcément filtrer sur les clés « secondaires » pour vérifier qu'il 
existe réellement.)

JB.

Le 06/08/2020 à 10:30, Christian Quest a écrit :

Le 06/08/2020 à 09:10, PanierAvide a écrit :


On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de 
maintenance...). Pour l'exploitant, au moins le nom ça me semble 
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop 
d'infos...).




ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique 
que la source est ce SIREN et pas quelle est la source du SIREN... 
donc plutôt ref:FR:SIREN:source ;)



Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une 
fiche web pour chaque DAE. Quasi toutes les infos exploitables sont 
celles qui ressortent dans Osmose.



Ça viendra d'une façon ou d'une autre, si facile à mettre en place.





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

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[JB]

So, with sarcasm (at least half-)on, and english not being my 
mothertongue: the osm2pgsql/Nomatim/Potlatch grants were just Troyan 
horses to enable the OSMF funding of (ex or not ex?) Mapbox developer, 
with contributors not screaming too loudly? And explaining the iD 
conflict resolution process that was proposed lately (and, surprise, 
accepted by Mapbox iD developers)?
Much thanks to the iD developers for having kept long, trustful and 
peaceful relationships with the community over the years of iD development.
Just saying out loud what some people may or may not think, but would 
not dare to write. It does not expect answers.

JB.

Le 02/08/2020 à 13:44, Mikel Maron a écrit :

Hello

The OSMF board is working to make OSM's core software and infrastructure more stable and 
sustainable by supporting paid roles for priority needs, such as the Senior Site 
Reliability role 
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html), and the 
pilot to fund "OSM Infrastructure" projects 
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html).

As part of this focus, we want to organise coordinated funding to support 
continued maintenance and development of the iD editor, as iD's strong 
continuous development over the past several years has served the OSM community 
well. Quincy Morgan is iD's maintainer and lead developer. Unfortunately, 
full-time support of his work recently ended. He'd very much like to continue, 
and the OSMF Board wants to see that happen. He has written up this proposal 
(https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
 with his ideal plans for iD over the next year, along with notes about how 
he'll organise, grow the developer base, communicate, and set priorities, and 
make iD better. The final priorities for the year will be made in consultation 
with the community.

To help fund this project, as well as the SSRE role, we're looking at earmarked 
donations from companies, chapters and organisations. Administratively, we 
believe this is easier than other methods of pooled funding, as the OSMF is 
already in most companies' procurement systems, and it would limit paperwork to 
one contract for iD. Initial contract would be for 1 year, and that's what the 
OSMF would look to raise now.

With the OSMF holding the contract, the Board would take a key accountability 
role, reviewing work done on the contract and assessing progress on the plans 
Quincy develops for the project. Additionally, the OSMF is working in 
cooperation with Quincy to establish a formal appeal process 
(https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
 for the relatively rare community issues iD cannot resolve itself.

The OSMF would not see its role as a traditional "boss", instructing iD to 
focus on this or that feature. We would not be prescriptive about priorities. This does 
not mean work in a vacuum. Our expectation is that Quincy, in addition to following our 
hiring framework's principles for transparent service to the community, would regularly 
convene stakeholders from the community to share their priorities and feedback. Quincy 
would assess all priorities holistically as he decides on a workable plan for the project.

Over the course of the year, we'll evaluate and learn from how the arrangement 
is working for all, as we look towards year 2 and beyond. For future years, we 
are looking at developing an overall plan for long-term support for all parts 
of the OSMF infrastructure. We want to be able to offer similar support to 
other OSM editors. Our early focus on iD is to ensure continued development.

We want to find out what you, the OSM community, think. Do you have any 
feedback?

If you know of an organisation that might want to fund this, please feel free 
to ask them to contact the OSMF Board.

-Mikel, for the OSMF Board

* Mikel Maron * +14152835207 @mikel s:mikelmaron

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




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

Re: [OSM-talk-fr] Fontaine fleurie

[JB]

Le 18/06/2020 à 13:56, Yves P. a écrit :


Quitte à modifier les logiciels de rendu, je préfèrerais garder 
amenity=fountain et lui rajouter un tag additionnel (cf. proposition 
de Marc).

Ainsi dans les 2 cas, la fontaine reste rendue.


S'il vous plait : non. Une fontaine, c'est un point d'eau.
Si tu cherches quelque chose pour le rendu, j'irais plutôt voir du coté 
de tourism=artwork (un truc pour faire joli, mais sans utilité 
"pratique". Ça y est, je me suis aussi mis à dos tout les métiers de l'art…)

JB.


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

Re: [OSM-talk-fr] "Échallier" pour VTT

[JB]

Hello,
Il y a aussi le barrier=cattle_grid, 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcattle_grid, souvent 
utilisé sur des voies plus larges (highway=track). Il ne semble pas 
contre-indiqué sur de la voirie plus étroite (highway=path). Il 
sous-entend que le cycliste n'aura pas à mettre pied à terre, que le 
piéton passera.

JB

Le 17/06/2020 à 11:56, Yves P. a écrit :

Bonjour,

Comment appeler et taguer une sorte de petite barrière canadienne 
permettant le passage d'un clôture ?

Il permet de ne pas descendre de vélo.

Il y en a dans le Doubs, le Jura…

J'ai mis une photo dans la discussion Tag:barrier=stile # Stile for 
bicycles <https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier=stile>.


__
Yves

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


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

Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

[JB]

Pour conclure, la prochaine fois, tu mets 28e (ou même 28ème) sans poser 
la question sur la liste de diffusion, ce sera plus clair pour tout le 
monde et personne ne râlera qu'il aurait fait autrement.
Un outil de traitement des données ne pourra pas faire sans traiter ces 
cas particuliers, ne te soucie pas d'eux.
Marc : tu remarqueras que la section que tu cites indique quelques cas, 
mais tous du genre Rte, Ch., Gal. Mais pas les x-ièmes, qui semblent un 
cas à part.

JB.

Le 14/06/2020 à 09:33, Marc M. a écrit :

Bonjour,

Le 13.06.20 à 20:25, Florimond Berthoux a écrit :

abréviation de vingt-huitième

https://wiki.openstreetmap.org/wiki/FR:Names#Abr.C3.A9viation_.28.C3.A0_ne_pas_faire.29

la règle est de ne pas mettre d'abréviation dans name


mais le terrain prime :)

ce n'est pas parce qu'une plaque de rue a une taille limitée,
que osm doit se limiter.
sinon supprimons 99% des noeuds des frontières administratives,
le terrain prime, et il n'y a rien sur le terrain ? :)

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] Point d'apport volontaire, point de collecte, point de regroupement

[JB]

Hello,
Je lis cette série de messages un peu en diagonale. Je donne mon point 
de vue de contributeur (la madame Michu qui n'a pas dit grand chose, 
j'ai l'impression).

J'ai un point à cartographier. Ils récoltent recyclage et déchets.
Je mets un nœud amenity=recycling + plusieurs recycling:*=yes. Et je 
mets un nœud amenity=waste_disposal.
La modélisation unique, idéale, que vous semblez rechercher, essaye de 
rassembler deux approches opposées. Même si vous arriviez finalement 
vous mettre d'accord, il ne faut pas en déduire que tout le monde va 
l'appliquer comme vous voudriez. Et vous aurez toujours des approches 
multiples sur le terrain.

JB.

Le 16/05/2020 à 09:39, Yves P. a écrit :

@David
Sur le principe un tag "point de collecte" c'est parfait et c'est ce 
qui correspond à la réalité métier.

Le terme "neutre" est un point important :)

Est-ce que les autres communautés OSM s'échauffent aussi sur ces termes ?

amenity=waste_disposal pourrait bien aller après tout.

Mais on casse tous les sites web de la planète qui utilisent 
recycling et waste_disposal du coup :-)

Les sites peuvent s'adapter ;)
Mais faire accepter une PR sur le site web OSM est un gros défis…

@Deuzeffe
Certes… mais les professionnels de santé doivent parfois s'y rendre 
pour jeter leur bacs jaunes ;)
De ce que j'ai compris, c'est le collecteur qui vient-t-a eux et non 
l'inverse. 


Pour éliminer ses DASRI, le professionnel de santé a plusieurs 
possibilités :


• Recourir à un prestataire de collecte, qui assurera la prise en 
charge et le transport
• L’apport volontaire des déchets sur un site de regroupement déclaré 
auprès de l’ARS (déchèterie, bornes automatiques,…). Vous pouvez 
transporter vos déchets dans votre véhicule personnel dans la limite 
des 15 kg.
(Source 
<https://www.urps-infirmiere-paca.fr/les-bonnes-pratiques/les-dechets-dactivites-de-soins/>)


Pour info, dans ma dernière boite (association sans gros budget) on 
allait déposer les DASRI de nos usagers au site de regroupement (un 
local au CH de Lons-le-Saunier).


Existe-t-il un tag qui décrit la réalité (genre 
amenity=waste_disposal mais en plus gros) ?

"mais en plus gros" ?
Ce n'est pas la taille qui compte parait-il :D


Oui ? -> On l'utilise.

c'est le cas (mais pas un, 2 avec 3 façons de faire)


Non ? -> On en crée un (un gros, donc).
on peut renommer amenity=recycling en amenity=collecting pour apaiser 
la communauté française ;)


S'il faut raffiner (colonne, support, couleur, toussa), c'est dans un 
2e temps. Non ?

On semble tous d'accord :)

__
Yves

PS: concernant amenity=waste_disposal, il y a peu encore, 
l'illustration sur la page FR du wiki était un panneau décrivant une 
vidange pour camping car.
Du coup, ce tag est mal utilisé, et à produit des valeurs de waste=* 
inadaptées.


Quelque soit le consensus, une grosse tâche (sans jeu de mot) est de 
nettoyer la base de donnée.



___
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] Points relay

[JB]

Le 04/04/2020 à 19:18, Frantz a écrit :

je verrais bien :
amenity=post_office

S'il vous plait, non…
amenity=post_office, chez nous, bien ancré, c'est la Poste, d'une 
manière ou d'une autre. On ne change pas le sens du tag principal par un 
tag secondaire…




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

Re: [OSM-talk-fr] Covid19 - Access tag

[JB]

Le 27/03/2020 à 12:38, Florimond Berthoux a écrit :

Bonjour,
Comme vous le savez les parcs, certaines routes (canal en Seine st 
Denis par exemple) ou plages sont fermés pendant le confinement.

Je vous propose de tagguer cela avec un simple :
access:conditional=no @ covid19
Vous ne préféreriez pas faire comme pour les horaires d'ouverture, 
histoire que le jour où on nettoiera tout ça, ce soit plus simple ? Du 
genre :

access:covid19=no (ou quelque chose du genre, avec une clé spécifique) ?

https://wiki.openstreetmap.org/wiki/Conditional_restrictions
Et joie de l’informatique, pour les routes et chemins si ça concerne 
le vélo (acccess:conditional, vehicle:conditional, 
bicycle:conditional) ça sera rendu en zoom 20 sur CyclOSM, exemple :

https://www.cyclosm.org/#map=20/48.89238/2.38817/cyclosm
Bien à vous.
--
Florimond Berthoux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ça reste ouvert : on a besoin de vous !

[JB]

Le 25/03/2020 à 19:44, PanierAvide a écrit :

Pour vous aider à passer en revue les notes, il y a l'outil NotesReview :
https://ent8r.github.io/NotesReview/?query=%23caresteouvert=1=2020-03-23=6%2F47.3691%2F1.0107 


Hello,
Ce serait imaginable d'avoir un bouton d'édition vers JOSM ? (pas fan 
d'iD, jamais utilisé Level0)

JB.


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

Re: [OSM-talk-fr] Identifier les marchés couverts #Covid19

[JB]

Oui. Et en même temps, pas forcément pratique : 
https://www.openstreetmap.org/node/1255719174 : le batiment porte le tag 
amenity=library, pour la bibliothèque qui est à l'étage (et ça me semble 
cohérent comme ça). indoor=* semble utilisé pour autre chose, mais 
est-ce qu'il existe un équivalent qui pourrait convenir ? covered (sans 
conviction) ?

JB.

Le 24/03/2020 à 07:59, Florian LAINEZ a écrit :

Hello,
Depuis ce matin, seuls les marchés couverts ont l'autorisation d'être 
ouverts durant le confinement.
Le wiki 
<https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dmarketplace> 
précise que ce sont les tags

amenity=marketplace et building=yes combinés qui définissent ces lieux.

Y aurait-il des personnes motivées pour monter en qualité sur ces tags 
en particulier ?


--

*Florian Lainez*

@overflorian <http://twitter.com/overflorian>


___
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] Proposition de Hack Weekend à Toulouse, 4 et 5 avril

[JB]

Pareil, je pense pouvoir venir, s'il reste de la place pour un sac de 
couchage, je prends.

Si trajet en commun depuis l'Yonne ou Paris, je suis intéressé aussi !
JB.

Le 09/03/2020 à 11:04, Sébastien Hinderer a écrit :

Bonjour,

Frédéric Rodrigo (2020/03/09 10:59 +0100):

Parmi ceux qui comptent venir au Hack Weekend il y a du monde qui cherche un
hébergement ou qui ne se sont pas encore organisé ?

  * |Lupini| lève la main :)

Oui, moi, pardon de ne pas m'être inscrit sur le wiki, j'essaie de faire
ça dès ce soir.

Cheers,

Sébastien.



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

Re: [OSM-talk-fr] Plans lignes RER?

[JB]

J'arrive avec un peu de retard, et je ne suis pas sûr de comprendre 
exactement le besoin : tracé « géographique » tel que sur le terrain, ou 
réseau plus ou moins analysé/simplifié, rassemblant les voies sur un 
seul axe ?
Si une simplification est recherchée, j'avais sorti ça à une époque : 
https://twitter.com/RandoCarto/status/1201458577799569408/photo/1, il y 
a possibilité d'arrêter le traitement une étape plus tôt, avant 
l'éclatement des lignes superposées, et de sortir la donnée brute. Comme 
c'est un peu de boulot, je ne me lance pas dans le travail pour l'instant.

JB.

Le 09/03/2020 à 01:17, Shohreh a écrit :

cquest wrote

Les tracés d'IDFM ne sont pas non plus parfait, loin de là ! La boucle de
terminus de la ligne 6 à Nation n'a sûrement pas cette allure. Données à
prendre avec du recul donc...

Ils sont un peu plus propres : avec la relation, je récupérais des ways et
des nodes en plus (plusieurs voies et points dans une gare).

J'ai eu le même genre de problème en récupérant des parcours vélos dans OSM
type Eurovelo etc. → il vaut mieux récupérer une vraie trace sur des sites
spécialisés.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] barrier=block infranchissable à vélo malgré bicycle=yes

[JB]

Oups, avec le lien, ça va mieux :
https://brouter.damsy.net/latest/#map=17/48.80057/2.35349/standard=2.351096,48.801974;2.353424,48.799585

Le 01/01/2020 à 20:37, JB via Talk-fr a écrit :

Euh, chez moi, il le prend bien.
Mais sur ton exemple, il préfère juste passer par ailleurs. Les goûts 
et les couleurs…

JB.

Le 01/01/2020 à 19:48, Shohreh a écrit :

Ça ne plait pas à BRouter, d'où ma question.

https://brouter.damsy.net/latest/#map=17/48.80017/2.35421/standard,Route%20quality%20coding=2.351096,48.801974;2.355012,48.7982 





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] barrier=block infranchissable à vélo malgré bicycle=yes

[JB via Talk-fr]

Euh, chez moi, il le prend bien.
Mais sur ton exemple, il préfère juste passer par ailleurs. Les goûts et 
les couleurs…

JB.

Le 01/01/2020 à 19:48, Shohreh a écrit :

Ça ne plait pas à BRouter, d'où ma question.

https://brouter.damsy.net/latest/#map=17/48.80017/2.35421/standard,Route%20quality%20coding=2.351096,48.801974;2.355012,48.7982



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] adresse mail rejetée

[JB]

Idem pour mailoo.org

Le 10/12/2019 à 13:29, Jacques Lavignotte a écrit :

Le 10/12/2019 à 13:19, lenny.libre a écrit :
> Bonjour

Bonjour,

Parfois un MTA a ses vapeurs (SPF/DKIM/DMARC/whatever).

Ca m'arrive aussi (très rarement)

J'envoie de chez Orange ou de chez Gandi, selon mon humeur.

Je réactive et basta.

J.

,


cela fait deux fois que je reçois un mail de la liste pour réactiver 
mon adresse après avoir été rejeté trop de fois (bounced)  vaut-il 
mieux que je modifie cette adresse (c'est une adresse en orage.fr) ?


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] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

[JB]

Je vais pas en faire un …, et puis aussi m'arrêter là pour ce soir, mais 
je lis bien dans le message de Richard :


   et peut-être aussi:
bicycle:seasonal=yes
   pour les routeurs qui ne parsent pas le (très compliqué) opening_hours?

Bonne nuit.

Le 26/11/2019 à 21:29, osm.sanspourr...@spamgourmet.com a écrit :


Bonjour, de nom oui, mais pas plus.

Certains ont des cultes (religions, ou culte de la personne).

Ça ne me dérange pas mais ce n'est pas mon cas. Je juge sur pièces. 
Toute personne aussi respectable soit-elle /peut/ dire une connerie.


Pour continuer dans ton ton : et avant de faire une remarque à la con, 
tu lis le message en question ?


Car Richard Fairhurst proposait *seasonal=yes* *pas* bicycle:seasonal=yes.

Et je critiquais bicycle:seasonal=yes *pas **seasonal=yes*.

Et pour info avant je disais à Jean-Christophe en MP :

 Message transféré ---
Sujet : 	Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les 
cyclistes sur des routes de montagne

Date :  Tue, 26 Nov 2019 21:06:45 +0100
Pour :  Jean-Christophe Becquet 


Ça oui !

Et tu peux ajouter :

note=Tronçons fermés du dernier du dernier vendredi de novembre au 
dernier vendredi d'avril.


Comme ça la gens savent que ce n'est pas la totalité qui est impraticable

Le 26/11/2019 à 18:32, Jean-Christophe Becquet - j...@apitux.com a écrit :

Je me dis : peut-être au moins mettre seasonal=yes sur les relations ?

Le 26/11/2019 à 21:04, JB - jb...@mailoo.org a écrit :

Euh, tu connais Richard Fairhurst ?
Je pense que s'il propose le tag, ce n'est pas pour rien. Et que 
quand il parle de tag pour vélo, on commence par l'écouter.
JB. 



___
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] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

[JB]

Euh, tu connais Richard Fairhurst ?
Je pense que s'il propose le tag, ce n'est pas pour rien. Et que quand 
il parle de tag pour vélo, on commence par l'écouter.

JB.

Le 26/11/2019 à 20:46, osm.sanspourr...@spamgourmet.com a écrit :


-1 pour bicycle:seasonal

Jusqu'à aujourd'hui il y a exactement 0 (zéro occurrences dans la base 
selon taginfo).


Le plus proche c'est cycleway=seasonal=winter.intermitent

Donc 0 chance pour que ce soit pris en compte par quoi que ce soit.

bicycle:conditional=no @ (Nov Fr[-1]-Apr Fr[-1]) pourra être 
interprété par une machine.


Et que  même si l'humain a du mal à comprendre il comprendra quand 
même qu'entre novembre et avril ça peut ne pas marcher. C'est au moins 
aussi informatif que bicycle:seasonal=yes qui ne dit même pas à quelle 
saison !


Avec bicycle et bicycle:conditional on a bien décrit la situation, 
pourquoi essayer d'enfumer tout le monde ?


Pour CyclOSM, je pense que la présence de bicycle:conditional doit 
suffire à changer le rendu (pointillé, transparence augmentée...).


Jean-Yvon

Le 26/11/2019 à 17:02, Jean-Christophe Becquet - j...@apitux.com a écrit :

Le 26/11/2019 13:36, Florimond Berthoux a écrit :

+1 pour le seasonal

Pour ce qui est de l’accès par défaut bicycle=yes ou no, je ne sais pas trop.
Pour mon cas pratique du rendu de CyclOSM (on va afficher les routes
fermées au vélo) et de routage. Je m’attendrais à ce que la valeur par
défaut soit bicycle=yes.
Parce que je vais plutôt faire de la grimpette en été qu’en hivers et
donc utiliser ces outils l’été. Et me douter que c’est plus facilement
fermé au vélo l’hiver.

OK du coup je pars sur :

bicycle=yes
bicycle:seasonal=yes
bicycle:conditional=no @ (Nov Fr[-1]-Apr Fr[-1])


Jean-Christophe, peux-tu nous montrer tes exemples concrets que je me
fasse une idée de la bonne manière de consommer ces données ?

Voici un exemple avec le Col de Corobin
https://www.openstreetmap.org/changeset/77585840

JC



___
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] Mirepoix sur Tarn, les ponts... et OSM

[JB]

Le 22/11/2019 à 13:41, marc marc a écrit :

cela peux se renseigner :
maxweigt=19 T
hgv=no
hgv=yes @ one-by-one ou qlq chose du genre
Mauvaise idée à mon sens, un logiciel qui lira les données commencera 
par maxweight, puis lira hgv=no, puis n'arrivera probablement pas à 
comprendre hgv=yes@ et s'arrêtera à la conclusion hgv=no, ce qui est 
contraire à ce qu'il devrait (bon, en plus qu'on ne peut pas mettre deux 
valeurs dans hgv).




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

[OSM-talk-fr] Élections au board de la Fondation OSM

[JB]

Hello,
Je ne sais pas quelle proportion de personnes suivent la liste 
OSMF-talk, mais les élections du board de la fondation OSM arrivent 
bientôt, et cette année il y a 4 postes à pourvoir sur sept. Les 
candidatures sont attendues dans deux jours au plus tard…
Et il faut dire que je suis un peu triste du choix qu'il y a pour 
l'instant : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board#Candidates
Combien de représentants de la communauté de contributeurs, plutôt que 
d'intérêts financiers/entrepreneuriaux/politiques ou autres.
Si vous ne savez pas quoi faire d'une partie de votre temps libre ces 
deux prochaines années, lancez-vous !

JB.


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[JB]

Merci, Adrien, pour ce message… Je me sens moins seul.
Je suis convaincu que toutes ces clefs externes sont du genre à rebuter 
un nouvel entrant qui, ne sachant pas ce qu'elles veulent dire, 
préfèreront ne rien toucher que de risquer de tout casser…

JB.

(Apparemment, en 2019, on n'arrive toujours pas à croiser les contrôles 
techniques issus d'OSM avec une base externe sans utiliser un 
identifiant unique ? La clef unique est vraiment la solution de facilité…)


Le 07/11/2019 à 16:14, Adrien André via Talk-fr a écrit :

Le 19-11-07 à 07 h 26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ?
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.


Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.

Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de

https://www.mapillary.com#gimme=pics=1.234=5.678=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables 
qui pourraient ressembler au brouillon suivant :


type | id| version | database | key
 | - | --- |  | ---
relation | 65606 | 289 | wikidata | Q84
 |   | |  |


database | url  | url_pattern
 |  | 

wikidata | https://www.wikidata.org | 
https://www.wikidata.org/entity/{key}

 |  |

Ceci pouvant également servir à des systèmes spécifiques pour lier 
leurs données avec celles d'OSM.


Les informations sémantiques sur les éléments restent ainsi séparées 
de la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).

Et je présume que la maintenance d'openstreetmap.org en serait allégée.





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

Re: [OSM-talk-fr] canaux de communication

[JB]

Le 04/11/2019 à 20:30, osm.sanspourr...@spamgourmet.com a écrit :

c'est pas l'association qui décide, c'est la communauté :)

+1 mais dans notre cas ça ne devrait pas trop changer l'ordre final ;-)

tri perso (en fct de l'aide possible) : talk-fr, irc, site web, forum
et virer le reste au lieu d'envoyer les gens vers des canaux
où il n'y a pas de communauté active pour les aider.
+1 

Hello,
Pour mieux me rendre compte, irc en France, c'est combien de personnes ?
Vu le trafic et les points abordés sur talk-fr en ce moment, je n'y 
enverrais pas des nouveaux qui ont besoin d'une aide extérieure pour 
découvrir les canaux de communications OSM.
Pour moi, le forum français est vraiment la porte d'entrée pour les 
arrivants. Pas besoin de grandes compétences techniques pour y accéder, 
moins de peur d'y poser une questions de débutant.

Les autres canaux sont déjà affaire de spécialistes.
Ce n'est toujours que mon points de vue.


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

Re: [OSM-talk-fr] Quand le plus est l'ennemi du raisonnable !

[JB]

Il n’y aurait pas la "un peu" de détournement du tag natural=cliff 
(https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
<https://wiki.openstreetmap.org/wiki/Tag:natural=cliff>) ?

https://www.openstreetmap.org/#map=16/50.8899/14.3052
Peut-être, peut-être pas. En tous cas, si problème il y a, ce serait aux 
Allemands de le résoudre, une action à distance d'un autre pays sera 
probablement mal vue, à juste titre il me semble.

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

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[JB]

shop=yes

Le 23/08/2019 à 20:53, marc marc a écrit :

et à part faire la gueule ce qui est signe que tu vas bien :)
que proposes-tu pour mieux les décrire ?

Le 23.08.19 à 20:17, JB a écrit :

J'ai lu quelques autres réponses, mais de mon point de vue :
   - si je cherche une épicerie, une supérette (shop=convenience) et que
je tombe sur une station service, je pense que je vais bien faire la
gueule.
   - si je cherche un marchand de journaux (shop=kiosk) et que je tombe
sur une station service, ma réaction sera à peu près la même.
JB.

Le 23/08/2019 à 10:17, Phyks a écrit :

Avec quel tags pour la boutique ? shop=yes en complément d'une station
service, ça me semblait bien défini :
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services


J'aurais mis shop=convenience (pour les boutiques) ou shop=kiosk (si
c'est uniquement un kiosque de paiement pour l'essence).

https://www.openstreetmap.org/node/25214143 par exemple.




___
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] fin à venir du rendu osm.org pour shop=yes

[JB]

J'ai lu quelques autres réponses, mais de mon point de vue :
 - si je cherche une épicerie, une supérette (shop=convenience) et que 
je tombe sur une station service, je pense que je vais bien faire la gueule.
 - si je cherche un marchand de journaux (shop=kiosk) et que je tombe 
sur une station service, ma réaction sera à peu près la même.

JB.

Le 23/08/2019 à 10:17, Phyks a écrit :

Avec quel tags pour la boutique ? shop=yes en complément d'une station
service, ça me semblait bien défini :
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services

J'aurais mis shop=convenience (pour les boutiques) ou shop=kiosk (si
c'est uniquement un kiosque de paiement pour l'essence).

https://www.openstreetmap.org/node/25214143 par exemple.





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

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[JB]

Le 22/08/2019 à 22:44, marc marc a écrit :

Le 22.08.19 à 21:18, Jacques Lavignotte a écrit :

J'en ai 2 qui sont des stations-service (essence/gas-oil) qui ont  une «
boutique » Dans ce cas shop=yes n'est-il pas de bon aloi ?

l'idéal c'est 2 objets, surtout qu'ils ont souvent des horaires
d'ouverture, des moyens de payement et une position différente "dehors"
<> dans un batiment
Avec quel tags pour la boutique ? shop=yes en complément d'une station 
service, ça me semblait bien défini : 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services



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

Re: [OSM-talk-fr] Panneaux de signalisation manquant

[JB]

Le 09/08/2019 à 09:59, Francois Gouget a écrit :

maxspeed=50;80
Souvent le résultat du « merge » de deux highway avec des maxspeed 
différents, rassemblés par défaut dans la clé finale avec un 
point-virgule en séparateur.



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

Re: [OSM-talk] [Osmf-talk] Anyone who likes to organize an ID discussion panel at SotM?

[JB]

We really have victims here, it seems.
Dear Christine, thank you for your work, thanks for your help, thanks 
for your ideas, thanks for your presence at many OSM events.
Il semble que des personnes n'arrivent pas à gérer des idées différentes 
des leurs. Leurs idées seront toujours les bonnes et les meilleures. Ein 
iD-Panel ist ein gute Idee, aber ich wird in SOTM nicht kommen dieses Jahr.
And yes, the message from this list non-reader confirms that having an 
updates-unwatched iD as default editor on osm.org is now really a bad 
idea. Unfortunately, I (and others probably) will just do nothing about it.

JB, a sometimes-reader, seldom-writer.

Le 29/05/2019 à 17:32, Heather Leson a écrit :

Dear Christine, Bryan and colleagues,

Thank you for this conversation. Christine, thanks for the 
consideration. Many people use ID. It is part of OSM.


Bryan, i will reach out to separately on this topic. My goal is really 
to understand using this example on how we might improve for all 
people. The negativity is hard for me to, so we can start with a chat? 
More in a separate note.
I have also had some interesting experiences and frankly, I think OSM 
deserves to really think and do more. Call me an ally, but I believe 
there is room for all of us. Community health is a big concern.


Thank you

Heather

Heather Leson
heatherle...@gmail.com <mailto:heatherle...@gmail.com>
Twitter/skype: HeatherLeson
Blog: textontechs.com <http://textontechs.com>


On Wed, May 29, 2019 at 5:23 PM Bryan Housel <mailto:bhou...@gmail.com>> wrote:


Christine..

We mustn't define “the community” as the few remaining handful of
people who have not yet been driven off the mailing lists by
persistent abusers and trolls.

I am very aware of what people are saying about iD on all
discussion channels.  I read all of it, even the stuff written in
other languages, and even archives of mailing lists that I’ve long
unsubscribed from.

I encourage everyone to not put too much stock into what “the
community” of mailing list haters thinks about iD.  It’s the same
dozen or so people who have never liked me or iD much anyway.

I meet with stakeholders every week about the improvements we’ve
made in iD, /and I’m proud of the work that our small team has
been able to accomplish with each new release/.  Right now there
are 1000s of people editing with iD (most volunteering, but some
paid) who will never stop by mailing list or a GitHub thread. 
They far outnumber the voices that you hear on `talk` or `tagging`.


In large part because of the escalating negativity, I will not be
attending State of the Map.

My strong recommendation to you is to fill the program with
content that encourages community health, inspires people to be
better to one another, and celebrates the great things people are
building with OpenStreetMap.

Thanks, Bryan
❤️, 




On May 29, 2019, at 5:55 AM, Christine Karch
mailto:christ...@hermione.de>> wrote:

Hi,

reading the discussions about the direction of ID development and how
the community wants the ID at the OSM website I had the idea that
there
could perhaps be a panel at SotM. Does anyone want to organize an ID
discussion panel at SotM? Please tell me or us (program committee
in CC)
and we can consider it. At the moment it would be sufficient to have
someone (or more) who wants to organize it. All details could be
defined
later.

As ID is a core feature at the OSM website I think this would be
suitable for the main program at SotM.

Additionally it is always possible to organize informal meetings,
panels
during SotM in the unconference space (we will provide a lot of it).

By the way ticket sales is open. The Early Bird phase is until 7
July.
Program announcement will be around 20 June.

We will have our schedule meeting at 8 June. So it would be good
to know
if an ID panel should be planned. Details for the program booklet
should
be provided until end of July.

Cheers

Christine

___
osmf-talk mailing list
osmf-t...@openstreetmap.org <mailto:osmf-t...@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/osmf-talk


___
osmf-talk mailing list
osmf-t...@openstreetmap.org <mailto:osmf-t...@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/osmf-talk



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


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

Re: [OSM-talk-fr] hauteur minimale de pont/tunnel

[JB]

C'est une question ? C'est de l'humour ?
Pour remettre au clair, il me semble :
 - qu'on ne met pas de valeur quand on ne la connait pas
 - qu'on ne met pas de valeur clairement fausse
 - qu'on ne met pas de valeur juste pour faire plaisir à Osmose
JB.

Le 26/04/2019 à 18:42, osm.sanspourr...@spamgourmet.com a écrit :


Bonjour,

Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.

D'après le code de la route un tel ouvrage doit disposer d'un panneau 
indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.


S'il n'y a pas de panneau :
- vous prenez votre pentamètre et mesurez ;-)
- mettez 4,3 m. Pour les ponts standard ça doit être bon
- vous mettez un faux positif dans Osmose. Dommage car vous savez 
qu'il n'a au moins 4,3 m

- vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
- autre

Jean-Yvon




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

Re: [OSM-talk-fr] Bano _numéro manquant

[JB]

Ce n'est probablement pas moi qui répondra sur le fond. Mais sur la 
forme, il est de bon ton d'indiquer des éléments concrets, sérieux, pour 
prendre le temps de rechercher une solution concrète, sérieuse. Par 
exemple, nom de la rue, ville, lat/lon me semble bien le minimum.

JB.

Le 02/04/2019 à 13:10, ades a écrit :

j’avais oublié le principal dans le titre…

Le 2 avr. 2019 à 11:46, ades  a écrit :

bonjour

Je viens de jeter un coup d’oeil sur bano, il manque un numéro dans la rue, 
numéro pourtant porté sur la maison. Ça passe du 15 au 19 alors que le 17 
existe bel et bien.
Comment rétablir la réalité ?
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] Problème OSRM

[JB]

Pour moi, si la route n'est plus continue, et que personne ne peut 
passer, on ne mets pas de nœud commun aux deux extrémités des chemins, 
on sépare les deux extrémités sur deux nœuds différents.
(Quoi, l'enrobé va jusqu'au mur, il faut absolument que le mur et les 
deux chemins aient un nœud commun ? On fait de la modélisation, hein. On 
pense aux réutilisateurs de la donnée, aussi.)

JB.

Le 27/02/2019 à 11:38, Jérôme Seigneuret a écrit :
Oui c'est suite à la construction de la résidence il y a un beau 
mur... J'ai rencontré plusieurs fois ce cas et je crois qu'il il a 
même eu une situation de fermeture de voie en Bretagne discuté sur OSM.


Le mar. 26 févr. 2019 à 22:13, marc marc <mailto:marc_marc_...@hotmail.com>> a écrit :


Le 26.02.19 à 22:06, osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com> a écrit :
> Est-ce à dire que le nœud 6132360251 devrait comporter
> barrier=wall ?

s'il y a bien un mur en travers de la route (?) c'est connu que
certains
routages ne détectent(aient) pas les barrière traversant
l'itinéraire en
l'absence de nœud commun et/ou de tag sur ce nœud
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr



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


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

Re: [OSM-talk-fr] Problème OSRM

[JB]

Probablement à cause de ça : 
https://www.openstreetmap.org/way/654438529/history

Après, la carto laisse fortement à désirer selon moi.
JB.

Le 26/02/2019 à 11:58, Jérôme Seigneuret a écrit :

Bonjour,

Avez-vous ce genre de problème avec OSRM.
Impossible de trouver une route entre ces deux lieux.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=43.44859%2C3.74357%3B43.44727%2C3.74199

Merci
Jérôme


___
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] Imprimer un plan à partir d'OSM ?

[JB]

Et puis avec de l'huile de coude, tu peux toujours produire ce que tu 
veux à partir de la donnée… QGis, Mapnik ou Maperitive sont tes amis…

http://randocarto.fr/demo/SaintGeorges_1240_par_900mm_300dpi.png
https://github.com/JBacc1/Village_map
JB.

Le 14/02/2019 à 14:16, osm.sanspourr...@spamgourmet.com a écrit :


QGIS sera plus particulièrement intéressant si tu veux afficher 
plusieurs plans (centre-ville, vue globale, quartiers...) : la 
fonction magique c'est Atlas.


Lien vers un tuto clair : 
http://www.sigterritoires.fr/index.php/faire-un-atlas-avec-qgis/


Jean-Yvon

Le 14/02/2019 à 13:58, Sylvain M via Talk-fr - 
talk-fr@openstreetmap.org a écrit :

Sinon, il y a aussi la possibilité de passer par le logiciel QGis, qui peut
très bien charger les données brutes OSM, et ensuite tu fais ta mise en page
et tes styles comme tu le souhaites, avec exports possible en image ou
vectoriel (SVG).

De plus en plus de styles pour les données OSM sont partagés en ligne.
Voici un exemple :
https://github.com/charlesmillet/qgis_osm_styles
https://github.com/anitagraser/QGIS-resources/tree/master/qgis2/osm_spatialite
(mais en cherchant, puis en adaptant, les possibilités sont infinies)

A+

Sylvain M.




--
Sent from:http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] Fusion de communes... LE chantier annuel ;)

[JB]

Question bête d'un gars dont ce n'est pas le métier :
Est-ce que c'est vraiment à conserver dans OSM ?
Avant, on avait juste les admin_level=8. On a transformé en =9 pour les 
anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en 
quelque chose d'autre parce qu'une commune a intégré la nouvelle commune 
pour faire une autre nouvelle commune ? Est-ce que le modèle de tags 
d'OSM est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra 
quelque chose ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur 
potentiel n'ira pas chercher les éléments dans une autre base de 
données, quitte à ajouter l'information spatiale à partir d'éléments 
simples d'OSM ?
Dubitatif, et toujours adepte de garder de l'information simple. Pour la 
comprendre quand on contribue. Moi, et surtout les nouveaux 
contributeurs potentiels, qui ne connaissent rien au sujet.

JB.

Le 31/12/2018 à 18:18, Christian Quest a écrit :
Oui, il va falloir suivre les publications de dernière minute... quel 
bazar !
Je suis presque chaud pour rajouter un 4ème épisode à ma série 
"Millésimons"*


Bien vue la requête overpass, heureusement que mon script amis à jour 
les admin_level sur les anciennes frontières internes des communes 
nouvelles ;)


Pour les EPCI, il va falloir attendre que la DGCL publie une liste à 
jour (base BANATIC).


Pour les anciennes communes nouvelles qui se sont étendues, j'ai en 
principe mis à jour admin_type:FR=ancienne commune nouvelle


Effectivement si on veut que la somme des admin_level=9 correspondent 
à l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur 
les plus petits morceaux du puzzle...


On peut toujours les retrouver avec le disused:admin_level=8

C'est à bien documenter une fois qu'on aura trouvé un consensus ;)


* https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf

Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat <mailto:jerome.ama...@gmail.com>> a écrit :


Bien jouer Christian!

Il va falloir continuer à suivre la page Wikipédia

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019

au cas ou il y ai des oublies ou des arrêtés préfectoraux signés
au dernier moment et qui paraissent que début janvier.

Les intercom et les arrondissements départementaux ne sont
constitués que de communes entières. Il y a des communes nouvelles
de plusieurs intercom ou d'arrondissements et donc des intercom et
arrondissement qui ont du être modifiés.
Je pense que cette requête overpass turbo permet de trouver des
frontières où il y a un problèmes ( frontières d'intercom mais pas
de communes) :
https://overpass-turbo.eu/s/ER6
(on peut faire pareil pour les arrondissement mais on trouve des
frontières où il n'y a pas forcement des problèmes)

En ce début d'année, il peut y avoir des changements dans les
intercom et les arrondissements non liés aux communes nouvelles
mais malheureusement je ne crois pas qu'il y ai de listes de ces
changements :)
(J'ai fait l'un de ces changements dans osm dans l'Ain, un
intercom en absorbe un autre)

J'ai vu que pour les ancienne communes nouvelles qui ont
fusionnées en de plus grandes communes nouvelles, il y a parfois
admin_level=9.
Je pense que ça n'a pas de sens, elles n'ont plus de rôle
administratif et ne devrait pas avoir de admin_level=* et avoir
disused:admin_level=8 et même disused:boundary=administrative.
Les ancienne communes d'avant la 1ere communes nouvelles, elles
gardent admin_level=9 si elles sont communes déléguées.
Si elle ne le sont pas, je pense que si on veux être logique il ne
devrait plus y avoir de admin_level=*




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



--
Christian Quest - OpenStreetMap France


___
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] Fusion de communes... LE chantier annuel ;)

[JB]

Ce qui est bien, dans un wiki pléthorique, c'est qu'on trouve toujours 
ce qu'on veut. Même avec l'indication en en-tête :
"Some methods are common, others are less widely used or discouraged. 
Some methods are strongly discouraged for the main OSM project but 
accepted and in widespread use in the separate Open Historical Map 
<https://wiki.openstreetmap.org/wiki/Open_Historical_Map> project."
Les pages moins ésotériques n'indiquent juste pas la méthode : 
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

JB.

Le 30/12/2018 à 18:07, osm.sanspourr...@spamgourmet.com a écrit :


Heureusement la position d'extension temporelle ne s'est pas faite 
sans réfléchir aux conséquences.


Ajouter le paramètre temporel en variable aurait cassé toutes les 
valeurs, imposant à tout utilisateur des données de regarder s'il 
s'agit d'une valeur normale ou d'une valeur temporelle.


Là on introduit de nouvelles clés évaluées seulement par l'humain ou 
par la machine à un instant t et remplaçant donc la clé suffixée par 
cette même clé non suffixée.


Date_namespace_suffix_as_"keyname:DATESPEC=..." 
<https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22>


C'est la même logique que le disused: utilisé aussi par Christian mais 
cette fois-ci en utilisant le suffixe et non le préfixe.


Lifecycle prefix (: = ) 
<https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Lifecycle_prefix_.28.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E.29>: 
si tu te fiches de l'aspect temporel tu ignores simplement ces clés, 
si ça t'intéresse tu les gères. La logique de JB serait : tu casses 
tout ce qui existe dès que tu introduis un paramètre temporel.


Jean-Yvon


Le 30/12/2018 à 09:46, JB - jb...@mailoo.org a écrit :

Le 29/12/2018 à 21:54, Christian Quest a écrit :


admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce 
que les précédentes communes fusionnées ont été mise à jour comme 
cela par quelqu'un de façon systématique ?


La syntaxe est déconseillée : pas de valeur variable dans la clé (ici 
la date), la partie variable est dans la valeur (à droite du "=").



___
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] Fusion de communes... LE chantier annuel ;)

[JB]

Le 29/12/2018 à 21:54, Christian Quest a écrit :


admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce que 
les précédentes communes fusionnées ont été mise à jour comme cela par 
quelqu'un de façon systématique ?


La syntaxe est déconseillée : pas de valeur variable dans la clé (ici la 
date), la partie variable est dans la valeur (à droite du "=").



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

Re: [OSM-talk-fr] Comment indiquer qu'un cimetière est ouvert aux véhicules ?

[JB]

Ha ?
Je parierais sur moins d'une minute sous JOSM, une fois prêt à éditer. 
Sélectionner tous les ways en question, ajouter le tag une fois.

JB.

Le 26/12/2018 à 13:16, Shohreh a écrit :

Merci.

S'il faut tagger chaque voie individuellement, c'est un boulot de dingue :-/



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

Re: [OSM-talk-fr] Comment indiquer qu'un cimetière est ouvert aux véhicules ?

[JB]

Bonjour,
Comme déjà noté, tu ne taggues pas le cimetière, mais chaque voie du 
cimetière. Ce sont sur elles que les gens circulent habituellement.
Par exemple celle-ci : https://www.openstreetmap.org/way/23793441. 
Cependant, access=permissive indique que c'est déjà le cas actuellement. 
Pour tout type de véhicule, jusqu'à ce que le gestionnaire du cimetière 
décide de changer.

Cordialement,
JB.

Le 20/12/2018 à 12:52, Shohreh a écrit :

Merci, mais comment faire ?

Doit-on créer une relation avec "service=highway=service" et y inclure
toutes les ways (comment ?) qui composent les voies dans le cimetière ?

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



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] Openstreetbrowser, les cimetières et la religion

[JB]

Bonjour,
Pour répondre à la question initiale, sans entrer dans d'autres 
pointillismes…
Les cimetières sont classés dans telle rubrique parce que l'auteur du 
projet en a décidé ainsi. OpenStreetBrowser est un projet personnel, et 
si l'auteur avait classé les cimetières dans la rubrique loisirs ou 
infrastructure, grand bien lui fasse.
Le code est disponible sous GPL v3 
(https://github.com/plepe/OpenStreetBrowser/blob/master/LICENCE.txt). Il 
y a possibilité d'ouvrir des tickets sur le projet. Mais à part ça, 
c'est à vous de jouer si c'est trop bloquant pour vous.

Bonne soirée,
JB.

Le 15/12/2018 à 10:01, Rpnpif a écrit :

Bonjour,

https://www.openstreetbrowser.org classe les cimetières dans la rubrique 
religion alors qu'en France ils en sont indépendants.




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

Re: [OSM-talk-fr] Les voies vertes

[JB]

Bonjour,
Je vais le dire clairement. La généralisation des tags wikidata n'est 
pas bien considérée comme bienvenue par une partie des contributeurs. 
Elle est déjà critiquée quand elle s'applique à un objet unique dans les 
deux bases (une ville, une attraction touristique), alors remplacer un 
tag général par un tag wikidata comme des berges sableuses, des voies 
vertes, j'ai des gros doutes. À part multiplier la difficulté par deux 
en la diluant dans deux bases de données, j'ai du mal à voir l'intérêt.

JB.

Le 03/12/2018 à 09:37, Jérôme Seigneuret a écrit :
ben entre mettre les panneaux et le wikidata je pense que les deux 
sont complémentaires
highway:wikidata=Q47214356 fait l'affaire aussi et évite les problèmes 
de catégorisation en clair on peut faire la représentation en se 
basant sur cette clé sans pour autant créé une nouvelle catégorie.
Qui plus est comme la voie peut avoir les types suivants : path, track 
ça évitera tous problèmes dans la manière de tager et de voiloir 
mettre les voies verte comme des cycleways
C'est mon clair q'une description mais le fait que ce soit une voie 
verte ne devrait pas être dans une description car cela n'est pas 
exploitable alors que la clé suivante oui


Je vous propose là juste une alternative. qui plus est cela peux être 
mis à jour assez rapidement


Pour les voies vertes mises dans une relation, il y a aussi des codes 
spécifiques pour les véloroutes.





Le dim. 2 déc. 2018 11:56, Charles MILLET <mailto:charlesmil...@free.fr>> a écrit :


Salut Axelos,

Je suis vraiment content que cette approche te convienne. C'est
bête comme remarque mais nos capacités à faire évoluer nos visions
sur la façon de cartographier est la clé de la réussite. On a des
approches différentes en fonction de nos sensibilités et je crois
que les compromis qu'on arrive à trouver sont finalement les
meilleurs solutions.

Charles

On 27/11/2018 20:04, Axelos wrote:

L'ajout de traffic_sign=FR:C115 peut sembler fastidieux, mais c'est le seul moyen 
d'identifier les "Voies vertes selon l'aménageur" malgré la diversité des 
aménagements. L'intérêt est de pouvoir identifier, par une simple requête Overpass, des 
voies voies vertes autorisées aux véhicules à moteur comme celles-ci.

En revanche ne remet plus en question cette proposition:)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto: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] Les voies vertes

[JB]

Le 28/11/2018 à 21:03, marc marc a écrit :

Est-ce que ton refus de la vision quasi généralisé vient-il du fait
qu'il y a une donneur d'ordre qui a un besoin de rendu particulier ?
Quasi-généralisé ? Tu bases le sondage sur ton sentiment personnel que 
tu projettes à la communauté française ?

Je trouve la vision d'Antoine sur les voies vertes très juste.
Je trouve malvenu de suggérer que son point de vue est lié à son 
travail. Antoine a toujours demandé l'avis de la communauté avant de 
cartographier des situations particulières et a toujours été transparent 
dans ses démarches.
Quand au sujet du rendu, ceux qui pratiquent devraient savoir que c'est 
un argument sans valeur. À partir du moment où tu fais un rendu 
spécialisé, tu es obligé de traiter toutes les manières de tagguer 
possible, pas uniquement la sienne ou sa préférée.

JB.


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

Re: [OSM-talk-fr] grèves Loire

[JB]

Le 27/11/2018 à 14:48, François Boucault a écrit :


Faut-il vraiment créer un élément spécifique pour les bancs de sable 
/de Loire/ ? (je ne connais pas les pratique lié au tag wikidata=*)


Non. Si tu veux. Ajouter le tag wikidata=* pour le banc de sable dans 
OSM ? Non.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Carto+ et le plateau de Saclay — Essonne

[JB]

En fait, j'ai pas vraiment l'impression qu'ils reversent dans OSM ni 
qu'ils l'utilisent, à part comme fond de carte (sans attribution 
directe, en plus…) ? Tu as des éléments qui me contredisent ? Le crédit 
« Site construit à partir des données OpenStreetMap » me laisse pensif.

Ça ressemble un peu à du don pour financer une base de données privée ?
JB.

Le 03/11/2018 à 12:30, Gwenaël Jouvin a écrit :

Bonjour à tous,

Un article du Parisien relate un projet cartographie en Essonne et 
particulièrement au plateau de Saclay :
http://www.leparisien.fr/essonne-91/plateau-de-saclay-souscrivez-pour-une-application-mobile-sur-la-vie-locale-02-11-2018-7933959.php

Et je peux vous dire qu’il y a du boulot dans cette zone en plein chambardement 
:-)

Le site utilise les données d’OSM : http://saclay.carte-ouverte.org/


Gwenaël


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

Re: [OSM-talk-fr] vérification de quelques tags,

[JB]

Les thématiques qui me parlent : Le 24/10/2018 à 18:30, ades a écrit :

waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
moins de 12m?
Va vraiment falloir que quelqu'un aille modifier ce wiki, la question 
revient régulièrement. 12m, ça date de l'époque où on ne pouvait pas 
faire mieux faute d'outils et d'imagerie adaptée. Je ne dis pas que 50cm 
serait la bonne limite, mais on peut faire bien mieux que 12m actuellement.

landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
landuse:forest ?
Bof, tu fais un peu comme tu veux, les puristes n'arrivent pas à se 
mettre d'accord sur une définition et les autres s'en fichent un peu.


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

Re: [OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

[JB]

Je ne sais plus quels moteurs de routage permettent d'éviter des zones 
prédéfinies comme OpenRouteService 
(https://wiki.openstreetmap.org/wiki/OpenRouteService/Help#Avoid_Areas), 
mais ça me semble être typiquement la base de données de zones à éviter 
qu'ils pourraient utiliser.

JBx

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :

Classe ! Félicitations !
J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api 
d'OED est publique.
Dire si ça concerne que les vélos où aussi les voitures, les piétons, 
mobilité réduite ?
Après pour que ce soit exploitable dans OSM par un calculateur 
d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?


Le jeu. 25 oct. 2018 à 09:33, Phyks > a écrit :


Salut,

> Vu que chaque ville à sa propre base / api ça me paraît
compliqué que les
> calculateurs d'itinéraire le prenne en compte nottament avec les
arguments
> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import
dans OSM
> mais que des contributeurs revalident ces données, modifier OSM
me parait
> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI,
faire une
> conflation ... les différents chantiers ont différents impact donc à
> tagguer différemment.

J'ai
https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
en stock avec toutes les opendata sur les travaux que j'ai trouvées en
France pour l'instant (et qui les uniformise un minimum).

Ça devrait être possible de reprendre un script du genre et de
l'injecter dans OED, non ?

-- 
Phyks




___
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] repère géodésique détruit

[JB]

Bof, was: est utilisé pour quelque chose qui a changé d'usage. Ici, ça 
me parle beaucoup plus de demolish:, removed:…

https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

Le 22/10/2018 à 15:03, marc marc a écrit :

was:man_made=survey_point (ou n'importe quel autre prefix de cycle
de vie plus précis si tu prèfères) sans quoi ceux qui se base
sur le tag principal sont induit en erreur, pensant qu'il y a un repère



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

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[JB]

Non. Je dis que des pratiques bien ancrées depuis plusieurs années ne 
seront pas modifiées sur le coup de tête d'une ou deux personnes.
Penses-tu vraiment que si quelqu'un décide que c'est vachement mieux 
d'utiliser man_made=building à la place de buiding=*, tout le projet 
suivra ?
Pour moi, amenity=parking est trop ancien, trop ancré pour qu'il puisse 
changer d'usage en quelques semaines, voire quelques années.
Même un wiki modifié ne fait pas la loi. Si tu suis un peu les 
discussions sur talk, sur les journaux, dans la sphère OSM, tu verras 
que les contributeurs « du terrain », ceux qui enrichissent la carte, 
sont quasiment toujours ceux que les autres n'ont que le choix de suivre.

JB.

Le 27/09/2018 à 14:22, djakk djakk a écrit :

JB c’est très embêtant ce que tu dis, osm ne pourra plus évoluer ? ... :O

djakk


Le jeu. 27 sept. 2018 à 00:01, marc marc <mailto:marc_marc_...@hotmail.com>> a écrit :


cela dépend vraiment de l'endroit...
si c'est un lieu uniquement réservé aux véhicules sncf
je vois pas ce qui empêche de mapper les 2 :
le service amenity=*sharing (c'est un peu comme une station velib...
à cet endroit t'as bcp de chance de trouver un véhicule
même si ceux-ci bougent)
pour l'emprise du parking amenity=*parking + access=customers
mais on ne le fait pas pour les velib... pq le faire pour
le freeflooting ? on gagne qlq chose a renseigner le service
disponible "sur" le sol séparément de la peinture du sol ?
ceci dit en passant aucun schéma n'existe (et donc aucune app)
pour trouver les parkings liés au fait d'être "client xyz)
donc l'usage des données du parking serra bien faible.

par contre si c'est qlq places dont on veux renseigner l'emprise
au sol dans un parking + grand c'est amenity=parking_space
on ne fait pas un amenity=parking pour chaque type de place
dans un seul parking.

Le 26. 09. 18 à 23:03, osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com> a écrit :
> C'est évidemment plus important car si tu ne loues pas un engin,
tu n'as pas de problème pour le garer. Tu peux le louer et
l'utiliser sans le garer par contre tu ne peux le garer avant de
l'avoir loué.
> Pour moi c'est juste du bon sens.  Principe de la cause et de
l'effet si *tu* préfères.
>
> Ce que la SNCF a fait c'est peindre un scooter et une puce. Je
doute que ça empêche un propriétaire de scooter de se garer là de
bonne foi.
>
> Jean-Yvon
>
>> Gesendet: Mittwoch, 26. September 2018 um 22:45 Uhr
>> Von: "Florimond Berthoux - florimond.berth...@gmail.com
<mailto:florimond.berth...@gmail.com>"
>> An: "Discussions sur OSM en français"
mailto:talk-fr@openstreetmap.org>>
>> Betreff: Re: [OSM-talk-fr] Arceaux partagés motos / vélos
>>
>> Je ne suis pas certain de vivre dans le monde, mais à Paris ce
qu'on appel
>> "free floating" c'est tu loues un scooter mal garé sur le
trottoir pour
>> rouler 3km avec et tu le gares sur un parking 2 roues motorisés
(parce que
>> tu es un mec bien).
>> Ce qu'à fait la SNCF c'est de dire, voici un emplacement de
stationnement
>> dédié et uniquement utilisable au free floating.
>>
>> « Ce qui est important ici c'est que tu *loues* pas que tu
gares. Tu peux
>> garer ton scooter où tu veux (mais si tu ne veux plus payer,
l'emplacement
>> est important). »
>> Le problème c'est que *tu* considères que l'important c'est la
location,
>> mais c'est purement subjectif.
>> Je le répète une station de velib c'est un assemblage de
fonction : service
>> de location ET stationnement réservé. L'un n'est pas supérieur
à l'autre.
>>
>> Le mar. 25 sept. 2018 à 22:02,
mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
>>
>>> Non, "free flaoting" et "simple parking" (au sens de
stationnement seul)
>>> c'est incompatible.
>>>
>>> Le concept du véhicule partagé à emplacement variable, c'est de la
>>> *location* de véhicule que tu gares à un endroit précis (comme un
>>> véhicule en autopartage classique) sauf que l'endroit où tu
déposes le
>>> véhicule peut être différent de l'endroit où tu l'empruntes.
>>>
>>> Ni plus ni moins, c'est donc bien de l'ordre du car_sharing et
non du
>>> parking : tu ne peux utiliser cet emplacement que si tu as
emprunté le
>>> véhicule à cet endroit.
>>> On ne tague pas plus les emplacements des voitures de location
>>> amenity=parking.
>>> Ce qui est

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[JB]

Tiens, ça rejoint une discussion sur talk… entre l'idéal des 
structurateurs, et la vraie vie.
amenity=parking, aujourd'hui, pour les contributeurs, c'est un parking. 
Pour automobiles. Éventuellement bus/autocars.

Un parking vélo, c'est une autre clé.
Et c'est ancré dans les usages, ça ne pourra pas être changé. Vote ou 
pas vote, d'accord ou pas d'accord. Il y a trop d'habitudes prises, on 
ne peut pas revenir dessus.

Du coup, le problème est réel pour les arceaux communs vélo/moto.
Utiliser amenity=parking + bicycle=yes, on peut le faire dans notre 
coin, mais il y a peu de chance que les outils généralistes le 
reconnaissent un jour.

JB.

Le 24/09/2018 à 11:23, Florimond Berthoux a écrit :

Bonjour,

plus un pour :

Le jeu. 20 sept. 2018 à 17:54, djakk djakk <mailto:djakk.dj...@gmail.com>> a écrit :



Ou revoir la méthode :
amenity=parking
bicycle=yes
motorcar=no
hgv=no
motorcycle=yes


Définir le droit d'accès et le type d'aménagement dans le même tag est 
une erreur conceptuelle.
C'est d'abord un parking, autorisé aux deux roues (vélo + moto), avec 
dessus une infra de type arceaux.


(Il y a le même problème avec le highway=cycleway, qui définit à la 
fois une route et un droit d'accès.)


Cordialement.
--
Florimond Berthoux


___
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] Impasse

[JB]

Euh,
On pourrait avoir une vue d'ensemble, de conflits d'intérêts possibles, 
de projets perso/professionnels derrière tout ça ?

Ça ressemble de plus en plus à un taggage « pour mon projet ».
D'abord on redéfinit les villes (tiens, ça aiderait bien pour de la 
moyenne/petite échelle), puis les trunk (idem), puis les bretelles 
(chouette, encore pareil), les impasses (on les supprimera du graphe 
routier). Ça râle un peu, alors on utilise un tag en plus «looks_like» 
pour ne pas modifier les autres. La suite, ce sera d'ajouter color=* sur 
les ways pour ne pas le coder dans la feuille de style ?

De mauvais poil,
JB.

Le 16/09/2018 à 15:37, djakk djakk a écrit :

Salut !
Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin 
d’avoir l’information sur toutes les way de l’impasse. But = 
transmettre l’info au moteur de rendu.
Je croyais que noexit était fait pour mais apparement c’est plutôt 
pour ne pas affoler les éditeurs sur une éventuelle mauvaise connexion 
avec une autre way.
Dois-je continuer à utiliser noexit=yes sur les ways, ou trouver une 
autre clé ?


PS : difficile de calculer ça, pensez au réseau routier de Belle-Île ;)

djakk


___
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] Classification des highway - trunk comme super-primary

[JB]

Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet a 
été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières 
années. Tu as tenté de relancer la discussion sans grande réussite il y 
a quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre 
cette fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui 
semble le compromis le plus stable ou au mieux le moins bancal, 
t'empêchera-t-il de dormir tranquille ?
Je pense que le panier de crabes est mieux ainsi, en équilibre, que si 
on le retourne une fois encore. Je pense que tu risques de te frotter à 
des résistances locales à plusieurs endroits, à des conflits d'éditions, 
qui montent parfois vite en tension lorsque la modification est faite 
par des contributeurs distants. Es-tu sûr que le jeu en vaille la 
chandelle ?

JB.

Le 12/09/2018 à 12:59, djakk djakk a écrit :
Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je 
réfléchi à de nouvelles valeurs pour la clé (pour refléter les 
quatre-voies en normes autoroutières - Bande d'arrêt d’urgence bitumée 
et large - et d’autres cas)


djakk


Le lun. 10 sept. 2018 à 19:49, djakk djakk <mailto:djakk.dj...@gmail.com>> a écrit :


Coucou !

Je reviens sur cette histoire de highway=trunk qui diffère selon
les pays.

Je pense qu’il est important d’avoir pour chaque clé-valeur une
définition commune au monde entier (autant que possible ) et qu’un
5e niveau dans la hiérarchie des “highways”
serait souhaitable : residential/unclassified - tertiary -
secondary - primary - trunk.

Du coup, il s’agirait de reprendre pour la France le classement
anglais des highways, où le trunk désigne une super-route pas
forcément de type autoroutier.

Par exemple pour différencier la N12 et la D31 à Ernée (
https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12
serait à mettre en trunk - comme à priori toutes les nationales
restant en France.

Pour retrouver les informations actuellement fournies par le trunk
français : la classification administrative avec le panneau “route
pour automobiles”, on a la clé-valeur “motorroad=yes”.
Il faut inventer une nouvelle clé pour désigner une route
dénivelée (pas de carrefours à niveau) : at_grade=no ou
junctionS=interchangeS (utile pour les cas où la route ressemble à
une route pour automobiles dénivelée, mais ça n’en est pas une
officiellement, exemple : la N12 au niveau de Goussainville :
https://www.openstreetmap.org/#map=16/48.7718/1.5526
).


djakk



___
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] Projets du mois (était : projet du mois : limite de vitesse 80/90 ?)

[JB]

Ça me rend triste, ce genre de message : « hé, je mange une pizza, 
j'envoie un mél à talk-fr pour dire qu'il faut tous qu'on rentre des 
pizzérias dans OSM ce soir. Et puis pour faire passer le truc, on dira 
que c'est un projet du mois… ».
Les derniers projets du mois, les arrêts de bus par Noémie et Junglebus, 
les toilettes publiques par Florian, les transformateurs par François, 
ont été préparés bien en amont, avec délimitation d'une tâche claire, 
simple, de terrain, création d'une page wiki, soumise, améliorée, une 
communication sur plusieurs canaux, un état des lieux initial, un suivi, 
une relance, une conclusion (mais pas toujours très aboutie, c'est ce 
qui manque souvent…). Pour réussir à faire prendre un peu la sauce, 
intéresser un public dont ce n'est pas le point d'intérêt principal, il 
me semble qu'un peu plus de préparation qu'un simple « hé, ce sera le 
projet du mois, même si on est déjà le 12 et que tout le monde est en 
vacances et que je ne sais pas si j'aurai le temps de m'en occuper 
pendant un mois. »

Un peu ronchon,
JB.

Le 12/08/2018 à 22:53, osm.sanspourr...@spamgourmet.com a écrit :


Bonjour,

certes on peut continuer encore un moment du côté des postes de 
distribution mais un sujet sans doute impactant plus les utilisateurs 
sont les limites de vitesse.


Je pense que les maxspeed=90 n'ayant pas source:maxspeed=sign sont 
tous à reprendre.


Usuellement

maxspeed=80
source:maxspeed=FR:rural

est la bonne mise-à-jour. Y compris pour les voiries à au moins deux 
voies dans le même sens car par défaut c'est 80.


Dans certains cas :

lane:3
lane:forward=2
lane:backward=1
maxspeed:forward=90
maxspeed:backward=80
source:maxspeed:forward=sign
source:maxspeed:backward=FR:rural

lane:3
lane:forward=1
lane:backward=2
maxspeed:forward=80
maxspeed:backward=90
source:maxspeed:forward=FR:rural
source:maxspeed:backward=80

Plus rarement :

lane:2
oneway=yes
maxspeed=90
source:maxspeed=sign

Ou encore

lane:4
maxspeed=90
source:maxspeed=sign

Reste que des

maxspeed=90
source:maxspeed=sign

datant d'avant juillet 2018 n'ont pas lieu d'être. S'il n'y a pas deux 
voies dans le même sens, c'est simple (et


https://overpass-turbo.eu/s/AZw permet de trouver les cas plus trop 
logiques).


Attention : 2 voies dans le même sens - avec ou sans séparateur 
central - est une condition nécessaire mais pas suffisante il faut en 
plus un panneau - et que les voies aillent dans la même direction au 
sens de turn=through.
Par exemple un tronçon court restera sans doute à 80, une voie de 
dépassement repassera sans doute à 90 mais à vérifier sur le terrain. 
Éventuellement en posant une note/fixme et en précisant de ne pas 
utiliser des images datant d'avant juillet 2018.


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] traduction et glossaire

[JB]

Le 29/07/2018 à 15:52, marc marc a écrit :

to tag : renseigner, cartographier
Euh, on se pose deux minutes et on se dit que cartographier, c'est « to 
map ». Que tagguer, c'est une autre histoire. Où la géométrie 
n'intervient pas vraiment, par exemple.


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

Re: [OSM-talk-fr] Signalisation routiere

[JB]

Tout le monde à l'air d'être handicapé du moteur en ce moment.
access=no implique foot=no, cycle=no, horse=no, etc… Il me semble 
qu'aucun de ces accès n'est interdit.

Ce n'est pas access=no, plutôt motor_vehicle=no.
JB.

Le 28/07/2018 à 10:29, David Crochet a écrit :

Bonjour


Le 28/07/2018 à 01:13, Philippe Verdy a écrit :

On peut toujours faire un truc du genre:
- 'access:bus=no;yes@navette', ou


Pourquoi réinventer le fil à couper le beurre, le wiki dit :
access=no
bus=private
motorcar:conditional=private@Jul 07-Aug 26: 08:30-17:30
motorcycle:conditional=private@Jul 07-Aug 26: 08:30-17:30
moped:conditional=private@Jul 07-Aug 26: 08:30-17:30
mofa:conditional=private@Jul 07-Aug 26: 08:30-17:30

Cordialement




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

Re: [OSM-talk-fr] highway=motorway_junction : noms ?

[JB]

Les sorties d'autoroute ont-elles un nom ? Je dirais oui : ici, 
j'interprète bien un nom (indiqué avec le numéro de sortie, en 
italique), et deux destinations (en dessous, police classique).
https://www.mapillary.com/app?focus=photo=LvUCqf6SINTILuVhgcwS1A 
(noscript pas franchement apprécié).

JB.

Le 24/07/2018 à 10:49, Philippe Verdy a écrit :
A ma connaissance les sorties d'autoroutes en France n'ont pas de 
noms, juste des numéros (le même en principe pour les deux sorties et 
deux entrées dans les sens).


Les bretelles elles-mêmes ont aussi un petit numéro de référence (pas 
toujours facile à repérer, mais utile en cas d'accident pour 
identifier précisément les voies affectées pour les services 
d'urgence, mais les annonces radio se contentent de donner le numéro 
de sortie, et la direction concernée).


En revanche les interconnexions des bretelles de sorties avec le reste 
du réseau est souvent un rond-point ou un échangeur qui a, lui, très 
souvent un nom, mais qui ne font pas lui-même partie du réseau 
autoroutier.


Le 24 juillet 2018 à 08:18, David Marchal <mailto:pene...@live.fr>> a écrit :


Salut, la liste.


Je modifiais récemment des sorties d’autoroute quand je me suis
aperçu de quelque chose : le tag name=* était parfois utilisé pour
la destination de la sortie, ce que je corrige, mais il est
parfois utilisé pour donner un nom, qui n’est pas celui des
destinations affichées, par exemple le long de l’A 35 en Alsace ;
ceci dit, ce nom ne semble pas affiché sur place. Existe-t-il des
sorties d’autoroute dotées de noms ? Où trouver une telle
information, si ce n’est sur place ?


Dans l’attente de vos réponses,


Cordialement.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<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] Tagger voie bus/vélo/taxis uniquement?

[JB]

Le 24/07/2018 à 11:35, Johnparis a écrit :
Parce que access=no implique motor_vehicle=no, le motor_vehicle tag 
n'est pas nécessaire. 
Ou l'inverse, conserver le motor_vehicle=no et virer le access=no (qui 
inclue les piétons, vélos, chevaux…).

JB.

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

Re: [OSM-talk-fr] Cartographier les voies vertes

[JB]

Puisqu'on demande un avis, le voilà : pas d'accord. Mon interprétation 
du wiki non plus :
"This tag <https://wiki.openstreetmap.org/wiki/Tag> represents *roads 
for mostly agricultural use*, *forest tracks* etc.; usually unpaved 
(unsealed) but may apply to paved tracks as well, that are suitable for 
/two/-track vehicles, such as tractors or jeeps."
Pour moi, la partie essentielle est celle en gras du wiki : usage 
agricole. Mon exemple : https://www.openstreetmap.org/way/161914750, ce 
chemin ne mène nulle part sauf au milieu de champs, il a finalement été 
goudronné car systématiquement embourbé. Que ce soit du goudron ou des 
pavés, franchement… L'usage n'en a pas été modifié.

JB.


Le 15/07/2018 à 19:41, osm.sanspourr...@spamgourmet.com a écrit :


Pour moi ce n'est pas un track, un track c'est une piste.

Là c'est d'un côté une route normale avec simplement une restriction 
d'accès de l'autre une route avec des nids de poule.


La page française comme la version anglaise parle bien de piste/track 
et n'envisage au mieux que le pavé.


Certes tracktype accepte le niveau 1 mais ce n'est pas cohérent avec 
la page de base.


D'autres avis ?

Notons que le grade 1 sur la proposition c'est un béton rugueux 
<https://wiki.openstreetmap.org/w/images/7/7f/Tracktype.jpg>, pas un 
bel asphalte comme sur la page tracktype 
<https://wiki.openstreetmap.org/wiki/File:Cesta_od_Le%C5%A1tiny_do_Lipnice_nad_S%C3%A1zavou_%282%29.jpg>.


Par contre le rendu est intéressant ;-)

Jean-Yvon


Le 12/07/2018 à 23:08, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :

Le 12/07/2018 à 22:22, osm.sanspourr...@spamgourmet.com a écrit :


Il y a quand même la référence de la voie qui l'indique.

CE= Chemin d'Exploitation, pas Chemin Écolo pour vélos, car comme 
deuzeffe le fait remarquer, sinon il y aurait un accent ;-).


Pour moi, chemin empierré où le passage de véhicules de particuliers 
est exceptionnel. On s'y croise difficilement (en mordant sur les 
bas côtés pour ne pas dire les champs).


Pas du 100 % mais pas loin.


Tiens, c'est pour tes 0.1% :-)

https://www.mapillary.com/map/im/pJ1RNDTgfFCUZXAvfJorqg
https://www.mapillary.com/map/im/0vCMhbMm6JOnTrexHjlQQg

Et il y en a d'autres dans le coin.
J'ai choisi
highway=track
tracktype=grade1
access=agricultural

J'ai hésité pour le surface=asphalt, mais comme il n'y en a plus au 
centre...


___
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] Route non utilisable

[JB]

Bonsoir,
Ça sent la donnée pas à jour dans votre application. La route a été 
retaguée accessible le 10/3/2018 : 
https://www.openstreetmap.org/way/185357948/history

Mettre à jour les données utilisées ?
JB.

Le 30/06/2018 à 22:43, Philippe Marin a écrit :

Bonsoir,

excusez ma question de novice, je ne suis qu'un contributeur 
occasionnel pour ajouter ou mettre à jour des infos locales.


Je devais faire un trajet en Chartreuse par le Col du Granier ce main, 
et ni Osmand ni Magic Earth n'ont accepté de me faire passer par la D 
285a. Le dernier kilomètre avant le col semblait inaccessible. Ne 
comprenant pas la raison, et connaissant un peu la route, j'y suis 
passé quand même, sans difficulté. Waze me proposait ce trajet d'ailleurs.


Vérification ce soir sur openstreetmap.org,
--> je ne vois rien dans les meta-données qui explique cela (tags, 
structure, accès autorisés, hauteur..). La route a été en travaux il y 
a quelques temps, c'est peut-être lié à cette période ?
Pouvez-vous me dire pourquoi les softs de navigation basés sur OSM 
semblent refuser de passer par là et comment corriger ce comportement ?


Merci d'avance.

--
Philippe.
--
/Non je ne cherche pas à me dépasser ! J'essaie déjà de m'atteindre, 
et c'est bien assez compliqué comme ça !

[Pierre Arditi]/
___


___
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] Cartographier les voies vertes

[JB]

On peut reprendre ce qui vient d'être écrit et faire un peu de 
vérification ?

maper un panneau routier sur le way auquel il s'applique serrait une première
À voir le wiki, ce n'est pas le cas : 
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#On_a_way_or_area
D'après taginfo.fr non plus, d'ailleurs : un quart des traffic_sign est 
utilisé en combinaison avec highway=* : 
https://taginfo.openstreetmap.fr/keys/traffic_sign#combinations

En plus la reconnaissance des panneaux routiers en cours pourrait aider.
Euh, on est à quel pourcentage de voies vertes couverte par Mapillary ? 
Proche de 100% ? J'en doute.

Si vraiment on veux un tag sur le way, "description=voie verte" me semble plus 
approprié.
Donc tu conseilles un tag qui ne sera utilisé par aucun traitement 
automatisé (rendu, routage) ?


Un peu de vérification avant d'être le premier à répondre ne ferait pas 
forcément de mal.

JB, un peu tranchant, ce soir.


Le 21/06/2018 à 18:01, marc marc a écrit :

Bonjour,

Le 21. 06. 18 à 17:48, Antoine Riche a écrit :

highway=*
traffic_sign=FR:C115

maper un panneau routier sur le way auquel il s'applique serrait une
première. est-ce vraiment nécessaire cette spécificité franco-fr ?
ne pourrait-on pas, comme pour les autres panneaux, mapper le panneau
avec un nœud là où il se trouve et ne mettre sur le way que l'effet
du panneau ?
En plus la reconnaissance des panneaux routiers en cours pourrait aider.
Si vraiment on veux un tag sur le way, "description=voie verte" me
semble plus approprié.

Pour le reste, je partage votre avis des avantages d'un highway=* libre
permettant un raffinement supplémentaire (track a la largeur d'une
voiture, au contraire du path)

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] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)

[JB]

En tant que non-spécialiste, une remarque :
J'ai fait une intégration de transformateur situé sur un pylône 
électrique : https://www.openstreetmap.org/node/569989/
Le Josm-fix contient power=substation (il sera écrasé par power=pole), 
mais également substation=minor_distribution qui fait râler le 
validateur de JOSM. Après comparaison, j'ai déduit que le tag était en 
trop. Est-ce que la base de données originale aurait permis de ne pas 
proposer ce tag à l'intégration ?

Sinon, la géolocalisation dans le coin a l'air plutôt propre.
JB.

Le 18/06/2018 à 01:56, François Lacombe a écrit :

Bonsoir à tous,

Après avoir été gonflé à bloc par Donat pour inscrire l'idée sur le 
papier, voici une proposition de projet du mois pour Juillet prochain: 
constituer la Base Nationale des Postes électriques (oui ca fait BNPé)


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques 
<https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques>


Je propose donc de s'occuper des 730 000 postes électriques libérés 
par Enedis en mai dernier, ils sont dès à présent visibles sur Osmose 
pour l'intégration. http://osmose.openstreetmap.fr/fr/map/#item=8280 
<http://osmose.openstreetmap.fr/fr/map/#item=8280>
Il y a d'autres exploitants en France, qui n'ont pas forcément libéré 
leur données, ce qui porte le nombre total de points à ajouter dans le 
cadre de ce projet à environ 850 000.
Une idée de la tâche à accomplir: 
http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8280 
<http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8280>


Les jeux de données ouvertes disponibles étant peu bavards, la 
collecte d'informations de terrain a une valeur importante, démontrant 
si il le fallait encore la pertinence d'OSM.
J'ai essayé de simplifier au maximum la description des différents cas 
possibles pour permettre autant que faire se peut de collecter le plus 
possible d'informations différentes.
Je suis preneur de commentaires d'ici le 01 juillet pour améliorer 
cette proposition


Enfin, je le remets ici parce que c'est important: ne jamais pénétrer 
à l'intérieur d'une installation électrique fermée sans être habilité. 
Les dangers sont réels, invisibles et aucune quête ne mérite qu'on s'y 
expose inutilement.


A très bientôt

François


___
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] Tag Voie centrale zébrée

[JB]

Le 14/06/2018 à 17:58, SALLES Quentin a écrit :

D'accord pour la représentation avec 2 ways
Compliquer les choses, c'est souvent risque de dérive et d'erreur 
ensuite (tourne à gauche, etc…)

Je reste partisan du plus simple : une voie, lanes=2.
JB.

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

[OSM-talk-fr] Plan de village

[JB]

Bonjour,
Je partage la carte de village que j'ai créée : 
http://randocarto.fr/demo/SaintGeorges_A1_300dpi.png
En bricolant un peu, c'est à reproduire ailleurs. Les outils sont mis à 
disposition ici : https://github.com/JBacc1/Village_map
Pour se faire une idée, il y a quelques dizaines d'heures de travail, 
entre amélioration des données OSM, transformation des données brutes 
vers quelques chose de plus fin pour le rendu, mise en page finale… 
Comme pour les autres cartes papier, ce n'est pas du prêt à rendre. 
Bidouillages à prévoir.

Voilà voilà,
JB.

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

Re: [OSM-talk-fr] osmose conflit entre tag

[JB]

Je dirais : une déchèterie ou un landuse, c'est une surface. Une 
barrière, un linéaire.

Mélanger les deux dans le même objet, c'est le bordel.
Après, je ne sais pas si Osmose réfléchit comme ça ou non.
JB.

Le 19/04/2018 à 23:12, marc marc a écrit :

Le 19. 04. 18 à 20:31, Marc M. a écrit :

Le 19. 04. 18 à 19:33, Philippe Verdy a écrit :

Pourquoi Osmose prétend un conflit avec ces tags
amenity= recycling
barrier= fence
landuse= industrial

sans lien vers le rapport osmose, j'imagine que c'est parce
qu'il faut un objet une fonction, par conséquent
un objet : la barrière
un autre objet : la déchetterie

j'ai vérifié une déchetterie sans barrière,
ma supposition est erronée, même soucis.
http://www.openstreetmap.org/way/524665913
https://osmose.openstreetmap.fr/fr/map/#zoom=18=47.31775=3.005758=1%2C2%2C3=T

je ne suis pas convaincu qu'une déchetterie (un espace de collecte)
est une industrie (un endroit qui modifie des matières)
mais j'imagine que le problème se pose peut-être aussi avec une valeur
de landuse plus adapté (auquel je n'ai pas réfléchi)
Perso je virerais landuse=industrial :)
___
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] Tag pour "chaussées à voie centrale banalisée" ?

[JB]

Le 04/04/2018 à 16:47, Shohreh a écrit :

2. Modifier "cycleway" en "both"
Pas mentionné dans le wiki, peu utilisé (11 fois en France, 24000 fois 
pour lane).


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

Re: [OSM-talk-fr] Import station essence

[JB]

Bonjour Noémie,
Tu as l'historique sur la liste imports du mois de mars : 
https://lists.openstreetmap.org/pipermail/imports/2018-March/thread.html#5436
De mémoire, Ilya a eu gracieusement une liste commerciale de stations 
services, non disponible en opendata. Il propose d'importer le tout et 
de maintenir le jeu de données au fur et à mesure des mises à jour 
mensuelles.
Il demandait des retours locaux et pour l'instant, je crois personne n'a 
parlé pour la France.
Certaines personnes insistent pour que l'import soit fait en changesets 
séparés pour chaque pays, mais ça ne semble pas encore acquis, Ilya a 
une grosse réticence.
Vu les retours sur la France qui vont tous dans le même sens, je pense 
qu'il sera bon qu'un message clair soit envoyé sur la liste import.

JB.

Le 26/03/2018 à 13:26, Noémie Lehuby a écrit :


Bonjour,

Est-ce qu'on ne gagnerait pas à demander à en savoir plus sur la 
source de données, et pourquoi pas à en demander une publication en 
opendata ou un extrait sur la France pour gérer ça selon nos habitudes 
(plutôt avec Osmose quoi) ?


J'ai retrouvé dans son outil toutes les stations que je connais, à des 
positions pas forcément exactes, mais utilisables pour mapper. Je ne 
peux juger de la qualité des tags proposés car je ne fréquente pas du 
tout les stations essence.
Mais il me semble qu'on ne devrait pas jeter le bébé avec l'eau du 
bain, et qu'il y a surement quelque chose d'utile à tirer de cette 
proposition d'intégration.


Noémie

Le 2018-03-26 12:29, Stéphane Péneau a écrit :


Je veux bien faire un message récapitulatif sur la liste d'import.

Ce qu'on a remarqué pour l'instant, et directement en anglais. Le 
mien n'est pas très bon, donc n'hésitez pas à corriger :


- A lot of "new" amenity=fuel are already in Osm
http://audit.osmz.ru/browse/navads_fuel/NVDS346_54a1ba689826bf65d6a31b83
http://audit.osmz.ru/browse/navads_fuel/NVDS368_545f7bfa82efa41a49637ace

- Most opening_hours are wrong. A lot of fuel stations can be use 
24/7 with a bank card.


- Phone numbers :
When a fuel station belongs to a supermarket, the phone's number is 
the supermarket one. I'm not sure it's a useful information.

Il faudrait aussi un exemple de numéro national

- brand, name, operator
Un avis argumenté sur ce sujet ? Je ne suis pas à l'aise avec ces tags

- Don't delete imported objects with ref:navads
Sorry but we disagree. Check yourself if you must ignore a POI before 
adding it over and over in Osm.


- ref:navads
This ref tag is a private one. Nobody can use it. We understand that 
it will be easier for you to update the fuel station, but if 
everybody start to use his private tag, the database will become a mess.


We already have an open fuel station database. These data are 
included in Osmose to let the contributors manually check each nodes.



Le 25/03/2018 à 22:36, deuzeffe a écrit :
Ma zone de confort n'est probablement pas représentative du 
territoire entier, cependant :

- sur les 4 existantes, il en manque une (une « de marque ». Hasard ?) ;
- les « à créer » existent déjà quelques dizaines de mètres plus loin ;
- les modif. pour les « à compléter » sont YOLO (je suis gentille).

Je n'ai pas regardé plus loin (le script est un infâme goinfre de 
ressources), mais je doute que ça soit de meilleure qualité. Pas 
compris d'où vient sa source (la DB sur data.gouv, même datant de 2 
ans ?)


Je suis assez de ton avis : augmenter la qualité de l'import (virer 
tout ce qui coince ; l'adapter au pays ?) puis on voit la nouvelle 
mouture. Au nom de la communauté, bien entendu !


Et puis (question de débutante) : quel intérêt d'un import massif 
pour des territoires où les données OSM sont pléthoriques ?


-- deuzeffe - qui aime bien osmose, mais quand même !

Le 25/03/2018 à 20:52, marc marc a écrit :
Il y a clairement un problème de qualité dans cette proposition 
d'import.

N'hésitez pas à signaler les problèmes sur la page wiki,
surtout si vous estimez que c'est pas un problème de "quelques points
à corriger mais général"
Ou alors on fait un post commun dans qlq jours au nom de
la communauté "talk-fr" ?
Car pour l'instant de ce que j'en ai entendu, il s'attend à ce que les
communautés locales corrigent les problèmes pour ensuite considérer
que la problème de qualité est résolu et donc l'import à faire.

Le 25. 03. 18 à 20:18, Cyrille37 OSM a écrit :
Le 25/03/2018 à 19:36, osm.sanspourr...@spamgourmet.com 
<mailto:osm.sanspourr...@spamgourmet.com> a écrit :

Ne pas importer, au plus permettre un rapprochment.


Oui, comme avec Osmose qui propose puis on indique si c'est fait, si
c'est un faux positif, ...


Le problème c'est qu'à la main, cela n'intéresse pas assez de monde.
cfr > 400k élément en attente rien que pour la France.
http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8xxx=1%2C2%2C3=france* 
http://osmose.openstreetmap.fr/fr/errors/?item=8xxx=1%2C2%2C3=france* 
c'est pour cela que je trouve qu'un import de meilleur

Re: [OSM-talk-fr] Import station essence

[JB]

Bonjour,
et merci d'ouvrir le sujet, je n'avais pas eu le courage de le faire. 
J'avais regardé du coté de chez moi, et avais été assez déçu par la 
qualité de ce qui était proposé à l'importation : beaucoup de doublons 
créés, souvent au milieu du bâtiment des supermarchés (en même temps, je 
suis assez satisfait de la couverture des stations dans OSM).
Un autre point en plus des tiens qui me soucie : dans le wiki, il est 
indiqué de ne pas supprimer un point importé qui ne serait plus présent 
sur le terrain et de le marquer disused:amenity… C'est ce qui m'embête 
chez les importateurs : « arrêtez de me compliquer la vie ». Pour moi, 
le contributeur local devrait toujours passer devant la contribution 
massive à distance (d'après les informations données, un peu de code 
pourrait s'en sortir pour faire les mises à jours sans avoir à garder 
ces points dans OSM).
Et pour râler un bon coup : le ref:navads privé, pas vérifiable, importé 
dans OSM pour se faciliter la vie, j'aime toujours aussi peu.

Mais je n'en ai pas parlé ailleurs.
JB.

Le 25/03/2018 à 19:18, Stéphane Péneau a écrit :

Bonjour,

Vous l'avez peut-être lu dans le weeklyosm, un import de station 
essence se prépare.


J'ai regardé les points qui seraient mis à jour autour de chez moi, et 
voilà ce que je constate :


- changement des horaires d'ouverture de 24/7 vers des horaires qui 
correspondent peut-être à la présence d'une personne sur place, ou du 
commerce attenant. C'est donc de mon point de vue, une mauvaise 
modification.


- ajout d'un numéro de téléphone. Dans le cas des stations dépendantes 
d'un supermarché, c'est le numéro de ce dernier. Je ne suis pas 
certain que ça soit très pertinent, mais pourquoi pas.


- ajout du code postal mouais

- Création de nouvelles stations : Ce sont des doublons de stations 
déjà existantes, mais mal géolocalisées dans la source utilisée.


Pour regarder ces données :

http://audit.osmz.ru/browse/navads_fuel

les marqueurs bleus sont des mises à jour, et les verts, des créations

la page wiki :

https://wiki.openstreetmap.org/wiki/Navads_Imports

La discussion sur la liste d'import :

https://lists.openstreetmap.org/pipermail/imports/2018-March/005436.html


___
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] Highway=trunk : harmonization between countries ?

[JB]

There is something I don't get.
Draw primary the same color as trunk and you have no more « 
discontinuity »?
In France, some commercial map (the most sold, I think) use a different 
rendering for trunk and primary, because you drive faster on trunks. I 
like it, I think they like it, because they have been using this 
rendering for decades.

JB.

Le 24/02/2018 à 04:45, Fernando Trebien a écrit :

As an exercise (and I'm curious about your thoughts on this), I found
the main routes between place=city within Czechia (didn't have time to
include cities in adjacent countries, bear that in mind).

Here's the result [1] using the old colour scheme (motorway=blue,
trunk=green, primary=red; with a little mistake: secondary=yellow).
Top image uses the current classifications, and bottom image is the
result if city-city routes are classified as trunks. Looks very
similar to most other maps. Just by looking at it, it's quite obvious
which is the main route between each pair of cities. As expected, the
method also found out the best ways through and around Praha when
going across it. This could also be slightly improved - for example,
with little extra time, it is easier to recommend going through route
6 and then Karlovarská than through route 5 and Bucharova.

I've checked the three small secondary segments using Street View.
Their physical structure is quite good. If still considered
undersirable, there are alternative main ways that increase the total
time of travel very slightly. Not all routers agreed on taking them
anyway.

[1] https://i.imgur.com/qFGSveX.jpg

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



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

Re: [OSM-talk-fr] Voies

[JB]

Bonsoir,
Je commence par le deuxième cas, le péage : surtout pas, et ça fait un 
an que personne n'a supprimé ça. Les voies ne sont pas séparées 
physiquement, pas marquées au sol, peuvent parfois être utilisées dans 
les deux sens, parfois sont fermées. Et cela n'apporte rien.
Pour le premier cas, le tourne à gauche, je dirais normalement « non, 
utilise turn:lanes » https://wiki.openstreetmap.org/wiki/Lanes. Mais 
dans ce cas précis, je suis plus réservé car cette modélisation évite 
d'avoir à créer plusieurs relations type=restriction car les petites 
rues qui arrivent de droite et de gauche ne peuvent apparemment pas 
traverser. Par contre, d'un point de vue routage, tu n'es pas génial, 
car dès la séparation des voies modélisées, on considère que tu ne peux 
plus tourner à gauche. Après, attention aussi aux « coutumes locales » 
qui peuvent faire apparaitre des habitudes de taggage différentes (ne va 
pas modifier toutes les intersections américaines alors que tu 
contribues habituellement en France).

JB.


Le 21/02/2018 à 19:21, djakk djakk a écrit :

Salut,

une question sur les voies non séparées par une barrière, comme les 
voies d’acceleration, les tourne-à-gauche et les multiples voies d’un 
péage : une « way » spécifique ou pas ?
Je croyais que non, mais en voyant que certains font l’inverse, je 
m’interroge.
Tourne-à-gauche en Californie : 
https://www.openstreetmap.org/#map=19/37.29258/-121.99091
Péage de l’A1 en France métropolitaine : 
https://www.openstreetmap.org/#map=16/49.2152/2.628 
<https://www.openstreetmap.org/#map=16/49.2152/2.6281>


djakk



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

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[JB]

Intéressant et enrichissant au-delà de l'exercice de communication. Dans 
ce qui est dit, ce qui n'est pas dit, ce qu'on trouve d'écrit ensuite.
La numérisation semble en tous cas avoir avancé (sur le terrain ou par 
décalquage des cartes IGN, c'est à voir).
La FFRP jongle comme elle peut avec la propriété intellectuelle, lecture 
du paragraphe 5.3 recommandée : 
https://www.mongr.fr/html/1710/conditions-generales-d-utilisation-du-site-mongr 
(pour une durée équivalente au droit d’auteur, oui, mais à partir de 
quelle date ?)

JB.

Le 19/02/2018 à 19:34, Jean-Claude Repetto a écrit :

Le 19/02/2018 à 15:19, JB a écrit :
Tu as des données précises sur leurs avancées ? Le projet est ancien 
et de discussions que j'avais pu avoir il y a un temps, l'avancement 
était anecdotique au niveau global. Ce n'est pas le même travail que 
de demander à un bénévole d'aller repeindre des balises au pinceau ou 
de faire de la saisie SIG suite à une reconnaissance terrain.

JB.


J'ai trouvé des applications directes du projet sur leur site:
https://www.ffrandonnee.fr/actualites/15839/numerique-de-la-carte-papier-a-l-appli-mobile-pour-randonner.aspx 



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

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[JB]

Le 19/02/2018 à 14:26, Jean-Claude Repetto a écrit :

La FFRP a déjà une action en cours pour effectuer tous les relevés de
terrain sur les sentiers:
https://www.ffrandonnee.fr/_248/ambitions-itineraires-pratiques-numeriques.aspx

Dans chaque département, une équipe de bénévoles a parcouru tous les
sentiers balisés et a relevé toutes les informations. Pas seulement le
tracé, mais aussi toutes les informations annexes: panneaux, petit
patrimoine, bancs, etc.

Je pense que leur base de données est bien plus complète que celle
d'OSM, dans laquelle beaucoup de sentiers sont encore absents.
Tu as des données précises sur leurs avancées ? Le projet est ancien et 
de discussions que j'avais pu avoir il y a un temps, l'avancement était 
anecdotique au niveau global. Ce n'est pas le même travail que de 
demander à un bénévole d'aller repeindre des balises au pinceau ou de 
faire de la saisie SIG suite à une reconnaissance terrain.

JB.

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

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[JB]

Bonjour,
Sauf erreur de ma part, la situation n'a pas avancé positivement depuis 
cette époque :

https://lists.openstreetmap.org/pipermail/talk-fr/2012-August/046340.html
http://forum.openstreetmap.fr/viewtopic.php?t=282
J'ai souvenir de retours négatifs de la fédération par un adhérent au CV 
qui aurait abordé le sujet, mais je n'ai retrouvé de traces.
J'ai trouvé une citation dans un mail privé de 2013 : « D'après des 
dires de membres de la FFRP, le Club Vosgien serait encore "pire" au 
niveau propriété intellectuelle... »
À David : adhérent ou pas, ça ne change pas forcément grand chose, si tu 
veux un coup de tampon de l'assoc' en plus, ça m'étonnerait qu'il te 
soit refusé. Si tu veux y aller « sérieusement » (au-delà d'un tweet, 
d'un mail râgeur ou d'un courrier sans suite), c'est chouette. Mais 
attends-toi à un travail de longue haleine, probablement en commençant 
par convaincre la base pour aller chatouiller la tête ensuite. Les 
groupes locaux vendent des cartes de randonnée locales avec leurs 
balisages en sur-impression, et se sentent dépossédés si quelqu'un 
d'autre pouvait en faire de même. Le numérique, les biens communs, ce 
n'est pas encore leur époque, pour ceux que j'ai pu rencontrer.

JB.
PS : et le CV et la FFRP se disputent toujours la propriété du GR5 dans 
les Vosges, il me semble…


Le 19/02/2018 à 09:35, David Marchal a écrit :


Aucune mention sur le Wiki, et je n’ai jamais entendu parler d’un 
accord. Je tenterais bien de l’obtenir, mais je ne suis pas membre de 
l’association OSM-FR et, autant que je sache, je n’ai pas de 
légitimité pour entamer une telle demande au nom de la communauté OSM, 
mais peut-être que ce n’est pas nécessaire ?


Pour l’interlocuteur, le balisage est la propriété intellectuelle de 
la fédération, bien qu’ils soient assez prodigues dans leurs 
autorisations d’usage pour autant que je sache. Par contre, je ne sais 
pas qui est responsable des itinéraires. Au moins certains comme les 
interdépartementaux ou les GR dans les Vosges dépendent logiquement de 
la fédération, mais d’autres sont probablement du ressort des clubs 
locaux, donc soit la fédération pourrait parler pour eux concernant 
tous les itinéraires, soit il faudrait voir avec chaque club pour les 
itinéraires de son ressort, ce qui serait moins pratique.


Cet échange pourrait également être l’occasion de leur faire connaître 
OSM, voire, qui sait, leur montrer comment enrichir OSM en s’en 
servant de base pour tenir leurs itinéraires à jour. Ce serait 
gagnant-gagnant : ils ne dépendraient plus de l’IGN pour leurs 
supports et la mise à jour de leur balisage sur leurs cartes, et OSM 
récupérerait des données en provenance directe de l’opérateur des 
sentiers.


Dans l’attente de vos réponses,

Cordialement



*De :* marc marc <marc_marc_...@hotmail.com>
*Envoyé :* dimanche 18 février 2018 18:45
*À :* talk-fr@openstreetmap.org
*Objet :* Re: [OSM-talk-fr] Itinéraires et balisages randonnée
Le 18. 02. 18 à 16:38, David Marchal a écrit :
> Autant que je sache, la situation entre OSM et la FFRP est la 
suivante :

> la FFRP est au courant qu’on cartographie leurs itinéraires avec leur
> balisage, et ils n’ont jamais daigné dire s’ils nous donnaient leur
> accord ou pas. J’ai bon ?

exact.

> Qu’en est-il du Club Vosgien ?

Si quelqu'un a déjà eu un accord avec eu, j'imagine qu'il l'a renseigné
dans le wiki. as-tu fait une recherche ?
sinon, si tu as de bons contacts humains avec eux, tu es un bon candidat
pour essayer e l'obtenir :-)
Surtout que les plus petites structures sont peut-être plus réceptive
à faire connaître leur travail.

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

[OSM-talk-fr] TLDR : les meilleurs intégrations du cadastre

[JB]

TLDR : les meilleures importations du cadastre
Je regarde les églises en Nouvelle Aquitaine, et je tombe sur un cas 
étrange : https://www.openstreetmap.org/relation/7130349

Tiens, les architectes sont imaginatifs, par là-bas ?
Ha non, en fait, c'est juste une intégration qui s'est terminée en import.
JB.

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

[OSM-talk-fr] Polygones depuis openstreetmap.fr

[JB]

Bonjour,
J'utilise de temps en temps http://polygons.openstreetmap.fr/ pour 
générer des fichier .poly (polygone) depuis des relations d'OpenStreetMap.
Je n'avais jamais trop exploré l'outil ni les finesse des fichiers .poly 
vu que ça semblait fonctionner habituellement, mais je viens de devoir 
le faire pour les enclaves (élément inner). La spécification du fichier 
polygone indique que l'identifiant de l'élément soustrait est préfixé 
par un point d'exclamation 
(https://wiki.openstreetmap.org/wiki/Osmosis/Polygon_Filter_File_Format#Example). 
Le script utilisé sur openstreetmap.fr ne semble pas prendre en compte 
ces éléments inner : 
http://polygons.openstreetmap.fr/get_poly.py?id=1241359=0
Quelqu'un a-t-il eu la même expérience ? L'outil est-il maintenu ? Le 
script est-il disponible quelque part (je veux bien essayer d'y jeter un 
coup d'œil, sans garantie de résultat) ?

JB.

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

Re: [OSM-talk-fr] Comment tagger les petits espaces verts sans herbe

[JB]

Le 08/02/2018 à 20:01, marc marc a écrit :

landcover=grass serrait + adapté.
Avec une telle réussite que le tag landcover est tout de même utilisé 
667 fois en France (plus d'un million de fois pour landuse).
Après toutes ces années, landcover est resté une superbe mauvaise bonne 
idée et n'est toujours pas adopté par les contributeurs.
(Perso, j'opte pour le landuse par défaut, comme rien d'autre ne me 
satisfait vraiment. Je ne sais pas si d'autres ont des meilleures 
pratiques ?)

JB.

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[JB]

Bon, alors, ce premier exemple, je risque de faire grincer des dents. 
Mon routeur préféré se fiche royalement de la localisation du point 
adresse par rapport au trajet, il semble simplement le projeter sur la 
voie la plus proche et gagner ce point-là :

https://graphhopper.com/maps/?point=45.749072%2C4.004656=45.748547%2C4.004694=fr=car=fastest=true_miles=false=OpenStreetMap
https://graphhopper.com/maps/?point=45.749072%2C4.004656=45.748547%2C4.004694=fr=car=fastest=true_miles=false=OpenStreetMap
Si quelqu'un veut vérifier comment les autres fonctionnent, mais pour 
lui, on ne gagnera rien à éloigner le point adresse de la voirie 
(punaise, et moi qui encourage à marquer l'entrée du bâtiment, je suis 
en train de défendre l'inverse…)

Je vais regarder les 6 points restants.
JB.

Le 25/01/2018 à 11:40, marc marc a écrit :

Bonjour,

Le 25. 01. 18 à 07:38, JB a écrit :

Tu pourrais donner un exemple

Les 7 derniers exemples listés en fin du précédent email sont
des exemples concret de problème ou de besoin non satisfait.
En voici un : un bâtiment avec une adresse et 2 accès.
Je souhaite un routage de l'adresse sur l'accès le plus proche.

Si tu met l'adresse sur l'un des 2 accès en bordure de parcelle,
un routage de l'adresse ignorera l'autre accès même si celui-ci
est + court. https://framapic.org/FcUSyUbM5u6S/Y6ErboyZ6ur2.gif
En vert la parcelle absente dans osm mais affichée
pour faciliter la compréhension.

Le problème se résout par l'abandon de la bordure de la parcelle
au profit d'une position + centrale, par ex sur le bord du bâtiment
https://framapic.org/VEytpWGfOCFD/A4Vp1LcxykK9.gif


se plaindre qu'une adresse sans route à proximité met le foutoir…
ben c'est un peu abuser

non je parle de la situation où même avec un carte "complète",
la position de l'adresse en bordure de parcelle permet uniquement
le routage vers une seule entrée mais échoue pour 7 besoins.
Tandis qu'abandonner cette pratique au profit d'une adresse
dans le centre ou sur une surface résout tous les besoins listés.

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] positionnement des adresses et ménage

[JB]

Le 25/01/2018 à 00:01, marc marc a écrit :

La confusion entre nœud adresse postale et routage provoque des
problèmes parfois insolubles et de nombreux besoins sont non satisfait.
Euh, j'ai laissé tomber la lecture de threads longs, pointus et qui 
dévient souvent. Comme celui-là en fait partie, je ne l'ai pas lu 
jusqu'à la fin. Et l'introduction ne m'a pas appris grand chose. Tu 
pourrais donner un exemple, qu'on voit de quoi on parle ? (Parler dans 
le vide, ça permet de discuter longtemps, mais souvent dans le vide, 
tiens…).

JB.
PS : j'ai lu qu'on parle de tracer des routes pour ne pas avoir de 
problème de routage… ben oui, se plaindre qu'une adresse sans route à 
proximité met le foutoir… ben c'est un peu abuser, j'ai l'impression. On 
parle de contributeurs, ici ?
PS2 : oui, j'ai la super pêche, ça va ! Assez pour pouvoir râler sans 
morosité !


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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[JB]

Le 17/01/2018 à 15:19, Charles MILLET a écrit :

je ne sais pas elle fait consensus.
Je confirme, elle ne fait pas consensus. Elle ne fera probablement 
jamais consensus.
highway=path a été la mauvaise bonne idée d'utiliser un mot trop 
descriptif pour tagguer autre chose.

JB.

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

Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau

[JB]

Bonjour,
Le fait que le way n'ait pas de tag est normal. Les tags sont portés par 
la relation : http://www.openstreetmap.org/relation/276616
Cette relation n'est pas fermée : les membres outer ne forment pas de 
boucle. Du coup, elle est impossible à rendre.
J'aurais bien montré ça, mais il semblerait que l'analyseur ne 
fonctionne pas : http://api.openstreetmap.fr/analyse/cgi-bin/index.py
Je n'ai pas réparé pour que tu puisses regarder. Un coup de JOSM et de 
la motivation si nécessaire, et ça peut repartir.

JB.

Le 06/01/2018 à 15:53, orhygine a écrit :

Salut à tous,

Je constate du côté de Pau une modification au niveau de la couverture 
du sol dans cette zone :


https://www.openstreetmap.org/#map=13/43.3570/-0.3401

Entre les zoom 12 et 13, la couleur de couverture du sol passe de 
beige à gris. Il semblerait qu'une modification ait eu lieu, non 
encore répercutée sur tous les niveaux de zoom.


Cela pourrait venir d'une modification intervenue sur le way 41766403 :

https://aleung.github.io/osm-visual-history/#/way/41766403

A la modification 41, des tags ont été supprimés mais cela commence à 
dater...


Les multipolygones CLC étant une science à part entière, un expert du 
domaine peut-il donner son avis ?


Salutations.

--
Christophe aka orhygine | http://orhyginal.free.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] Challenge ? Si on dégommait du rose ?

[JB]

Le 25/12/2017 à 16:56, Christian Quest a écrit :
C'est ici: 
http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13

Hello,
Je dois être handicapé d'Osmose, mais je n'arrive toujours pas à 
atteindre la carte osmose avec les erreurs qui correspondent. Quelqu'un 
aurait l'indulgence d'envoyer le lien qui va bien ?

JB.

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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[JB]

Le 17/12/2017 à 14:12, Axelos a écrit :

Je pense avoir trouvé la cause, le tableau par défaut et le français
interdisent les vélos à circuler sur highway=footway, alors que les
tableaux américain, anglais et australien les autorise.[…] belge […]

Euh, où ça ? #fakenews
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Belgium
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#United_Kingdom
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#United_States_of_America
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Belgium
(ok pour l'Australie, mais ça ne fait qu'un sur cinq).
JB.

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

Re: [OSM-talk-fr] highway=path + bicycle=yes

[JB]

Le 15/12/2017 à 21:55, osm.sanspourr...@spamgourmet.com a écrit :
Si on dit que sur les highway=path les cyles sont autorisés par 
défaut, alors quelle est l'information ajoutée ? 
Sans vouloir dévoiler des secrets, je dirais que les "path" sont 
tellement bien définis que chaque personne les utilise à sa manière. Et 
que si tu faisais un sondage représentatif sur ce que tu écris, tu 
serais probablement surpris par la réponse.

JB.

PS : le wiki c'est peut-être la bible, mais les pratiques restent une 
histoire de pratiquants.


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

Re: [OSM-talk-fr] highway=path + bicycle=yes

[JB]

Le 15/12/2017 à 20:23, jabali a écrit :

+1 pour un nettoyage
Bof. À part dégouter des contributeurs intéressés par la thématique, sur 
un tag qui ajoute une information et ne dégrade rien, je ne vois pas 
pourquoi.
Si j'étais de mauvaise humeur, j'oserais même utiliser le mot « 
vandalisme ». Mais je suis de bonne humeur ce soir.

JB.

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

Re: [OSM-talk-fr] Elections en cours à la Fondation OSM : ça concerne aussi la lste "internationale" en français

[JB]

Le 11/12/2017 à 12:05, Vincent de Château-Thierry a écrit :

Quelle part de OSM-France est financee par les adhesions ? il me
semble que la majeure partie des revenues est liee au sponsoring,
fondations etc non ?

L'essentiel des rentrées de l'association est liée au sponsoring, via le State 
of the Map. Mais je ne fais pas forcément le lien avec ta question précédente, 
Julien ?
D'encourager l'adhésion à l'OSMF (foundation) en mettant en place une 
adhésion à prix symbolique pour OSM-FR (France) ?
Je suis complètement en accord avec Martin qui s'interrogeait sur le 
corps électoral pour l'OSMF. Il semble qu'on recrute à coup de tarif 
d'adhésion.
(Pour la mauvaise foi : et si HOT avait financé l'adhésion des 200 
votants tardivement arrivés ? C'est une histoire de 4000€ ? Une paille ?)

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

Re: [OSM-talk-fr] Rendu hydro... avec BD Carthage et BD Topo

[JB]

Le 09/12/2017 à 21:53, Christian Quest a écrit :
Tout ça est à regarder avec la question qu'on se posait au début... 
importable en l'état ou pas ?
Par chez moi, j'ai l'impression qu'ils ont le même problème que nous : 
en zone découverte (prairie), ils sont bons. En zone couverte (forêt), 
ils sont médiocre à mauvais. Là où OSM a été cartographié proprement 
(GPS + analyse d'imagerie), OSM me semble meilleur que Topo.
Une base, agréable pour le traçage. De là à importer… c'est une autre 
histoire.

JB.

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

Re: [OSM-talk-fr] Intégration des toilettes depuis l'Open Data à Paris #IWheelShare

[JB]

Salut,
Il faut bien un râleur, alors je m'y colle (même si le but est louable 
et tout et tout…).
Il me semblait que quand chaque objet d'un import contient un fixme, 
c'est que ça ne devrait pas être importé ?

Avec entre-autres options :
 - quelqu'un s'y colle pour faire le tour avec un vélo (d'autres l'ont 
fait pour d'autres objets, je ne vise pas l'auteur du message), c'est 
l'histoire d'une demi-journée, une journée ? (vu qu'il semble y avoir de 
l'argent dans le projet, ça ne me semble pas exagéré de le demander).

 - une voie de service du coté d'Osmose.
JB.

PS : access=yes, c'était vraiment nécessaire ?

Le 06/12/2017 à 11:53, Florian LAINEZ a écrit :

Hello,
Adrien et moi travaillons pour I Wheel Share à intégrer les toilettes 
issues des données Open Data de Paris dans OSM.
On a trouvé 48 toilettes non-intégrées, sur le critère qu'il n'existe 
pas de toilettes dans OSM à moins de 20m.
Le résultat est ici : 
http://www.openstreetmap.org/changeset/54397052#map=13/48.8627/2.3288


avec un joyeux usage des tags suivants :
access=yes
amenity=toilets
drinking_water=yes
fee=no
female=yes
male=yes
note=intégré pour @I Wheel Share depuis les données Open Data de la 
mairie de Paris

operator=JC Decaux
source=https://opendata.paris.fr/explore/dataset/sanisettesparis2011
toilets:disposal=flush
toilets:position=seated
wheelchair=yes
fixme=vérifier la position exacte sur le terrain
opening_hours=*

Vos retours sont bienvenus.
Nous étudions actuellement sur une méthode pour industrialiser ce 
process pour la France entière, on vous en parle bientôt ...



--

*Florian Lainez*

@overflorian <http://twitter.com/overflorian>


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


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

Re: [OSM-talk-fr] Problème de GPS = problème de cartographie ?

[JB]

Bonjour,
Pour le premier cas, pour tourner à gauche, il faut passer sur un 
unclassified, alors qu'on passe de secondary à primary. Je suppose 
qu'Osmand ne veut pas de ce unclassified (ce qui peut être justifié). 
C'est une des raisons pour lesquelles je suis partisan de la 
cartographie de ces croisements au plus simple, ça évite les erreurs 
(voir une discussion d'il y a 1 ou 2 ans, où on a mis un bout de temps à 
remarquer qu'il y avait bien une erreur).
Par ailleurs, cette carto erronée : comme il n'y a pas de séparation 
physique des voies, il ne devrait pas y avoir de ways séparés pour les 
bretelles. Cela empêche un routeur (tiens tiens…) de passer d'une voie à 
l'autre.

JB.

Le 26/11/2017 à 18:33, Cédric Frayssinet a écrit :


Bonjour à tous,

Hier, j'ai fait un parcours avec Osmand et j'ai pu constater 2 
problèmes de GPS. Je ne sais pas si c'est du à Osmand ou à la façon 
que c'est cartographié (ma carte Osmand date du 1er octobre).


Du coup, j'ai mis 2 notes, un peu incomplètes :

  * http://www.openstreetmap.org/note/1216937#map=17/44.32807/1.46545=N

En arrivant de la D19, le GPS nous demande de tourner à droite sur la 
D820 pour nous faire faire un 1/2 tour un peu plus loin pour remonter. 
On peut très bien directement tourner à gauche dès l'embranchement.


  * http://www.openstreetmap.org/note/1217018#map=15/43.5541/3.8350=N

Là, c'est sûrement un peu plus compliqué. En effet, l'autoroute se 
sépare à présent en 2 avec : tout droit -> Lyon, et sur la droite -> 
Montpellier. Le GPS voulait me faire prendre Lyon et me faire faire un 
demi-jour plusieurs dizaines de kms après la note pour revenir sur  
Montpellier centre.


Du coup, je ne sais pas bien si ce sont des problèmes de cartographie. 
Merci pour les éclairages et merci aux contributeurs locaux lotois et 
héraultais :)


Cédric


--
En cure de désintoxication <https://degooglisons-internet.org/> de 
Google ! Client d'Enercoop 
<https://www.youtube.com/watch?v=xlwNxoGioWQ>, l'énergie militante


Également sur Mastodon : @bristow...@framapiaf.org 
<https://framapiaf.org/@Bristow_69>


Promouvoir et soutenir le logiciel libre <http://www.april.org>



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


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[JB]

Même question, tu as des références récentes ? Au sondage rapide coté 
français, ça semble dater d'il y a au moins 2 mois.

JB.

Le 24/11/2017 à 21:13, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour,
je crains qu'il ne fasse plus de dégâts sous ce nom mais sous une 
autre et que le problème ne soit plus grave : il n'est pas le seul.

Voir https://www.openstreetmap.org/changeset/51722348.
Doit-on regarder tous les noms comportant un / dans le coin ? Faire 
des réverts ou corriger proprement ? Je préfèrerai qu'ils comprennent 
et corrigent eux-mêmes ?
A-t-on contacté, a-t-on des contacts de l'autre côté des Pyrénées car 
Azpidatziak <https://www.openstreetmap.org/user/Azpidatziak> par 
exemple travaille de part et d'autre de la chaîne de montagne.
On attend sa réponse quelques jours et ensuite si besoin Christian 
allonge la requête au DWG?

https://overpass-turbo.eu/s/thy
Jean-Yvon
*Gesendet:* Freitag, 24. November 2017 um 15:06 Uhr
*Von:* "Christian Quest - cqu...@openstreetmap.fr" 
<osm.sanspourriel.038f093133.cquest#talk-fr@openstreetmap.org>

*An:* "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
*Betreff:* Re: [OSM-talk-fr] Utilisation du tag 'name' avec les 
langues régionales
Ces changeset sont anciens (2 mois), donc pas de nouvelle activité 
posant problème.
Côté DWG, aucune action prévue si il n'y a pas de nouvelles 
modifications pouvant être considérées comme du vandalisme (et c'est 
normal).
Les différentes discussions ouvertes sur les changeset passés sont 
suffisantes pour l'instant.
2017-11-24 13:50 GMT+01:00 marc marc <marc_marc_...@hotmail.com 
<mailto:marc_marc_...@hotmail.com>>:


Bonjour,

Des nouvelles du DWG ?
Izpura a aussi supprimer des nœuds pour les recréer avec
uniquement des
infos partielles
https://www.openstreetmap.org/changeset/52289582
https://www.openstreetmap.org/changeset/52105241
https://www.openstreetmap.org/changeset/52290242
https://www.openstreetmap.org/changeset/52104386
https://www.openstreetmap.org/changeset/52411982

J'ai corrigé.

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr




--
Christian Quest - OpenStreetMap France
___ 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] [osm-grenoble] Importation des arbres municipaux de Grenoble

[JB]

Le 19/11/2017 à 14:46, Jérôme Villafruela a écrit :

Je pense qu'il faudrait ajouter le tag ref (champ BIEN_REFERENCE) :
Mon avis doit commencer à être minoritaire par ici, mais j'en profite 
pour le rappeler : contre le fait d'importer des tag ref dans tous les 
sens :
 - ça effraie le nouveau contributeur : si un objet a un tag 
natural=tree, il n'hésitera pas à le modifier. Vous ajoutez 4 tags 
ref:xxx:yyy, source:date, source, etc…, il y réfléchira à trois fois 
avant d'y toucher.
 - si vous n'êtes pas capable de faire une repasse sur ces objets sans 
ce tag ref, est-ce que l'import était vraiment justifié ? Qualité, 
nécessité ?

JB.

PS : et pour vous dire, même moi après plusieurs années, j'hésite 
toujours à toucher à ces objets multiréférencés. Ça veut dire qu'une 
passe algorithmique est possible et qu'on aura d'autant plus de facilité 
à me tomber dessus si je fais une boulette ou ce que quelqu'un estime 
être une boulette. (Du genre : « bordel, j'ai bien indiqué que c'était 
un chemin/track lors de l'import, c'est vérifiable dans le fichier 
d'origine, alors pourquoi tu l'as passé en sentier ? »).



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

Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

[JB]

Le 17/11/2017 à 09:36, Christian Quest a écrit :
Ces poteaux matérialisent des itinéraires... ont ils été mappés dans 
une relation ?
Pas forcément. Selon les régions, il peut y avoir simplement de la 
signalisation de croisement à croisement, des directions vers des points 
d'intérêt, ou des itinéraires plus ou moins long.


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

Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

[JB]

Le 16/11/2017 à 11:42, marc marc a écrit :

A l'entrée d'une ville, un panneau indiquant le nom de la ville se tag
ainsi :
traffic_sign=city_limit
name="la ville"

Je trouve donc assez cohérent qu'un panneau de direction de randonnée
situé dans cette ville se tag ainsi :
tourism=information
information=guidepost
name="la ville" (si ce nom est repris sur le panneau bien évidement)

Hum… soit… je trouve la comparaison un peu étrange.
Si le panneau comporte un nom, on le met. Sinon, il n'en a pas et on 
n'en met pas dans OSM.

Ça semble suffire, non ?
(Et en tous cas, name=jalon, ça, c'est faux, pour sûr !)
JB.

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

Re: [OSM-talk] New OSM Quick-Fix service

[JB]

I only think I will print Frederick's mails, and regularly read them 
again and again.
Deprecated implies «bad, should not exist in OSM database, no one 
reviewed this object for the last years». It has very strong 
implications in OSM vocabulary. Using it here would have the effect to 
readers «Yes, if it's deprecated, of course it should be deleted». No, 
they are not deprecated, they only are useless to software parsers. They 
may be useful for contributors.
I will not answer anymore to this thread. It feels too much like a 
scientific paper submission: If you answer to every objection, even 
sometimes with halt-truth, there will come a time when there is no more 
to say.

JB.

Le 13/11/2017 à 11:27, Yuri Astrakhan a écrit :
JB, try to avoid swearword outburst, not helpful. Are you taking issue 
with the word "deprecated"?   The proper word should probably have 
been "unnecessary" to discuss the layer=0, per JOSM's naming:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss 



The wiki deprecation only lists one =no:  highway=no, but we are not 
discussing that one yet -- 
https://wiki.openstreetmap.org/wiki/Deprecated_features


I used the word "deprecated" in a more general term, to mean anything 
that community has decided to phase out, such as JOSM autofixes and 
deprecation list.


I have no   clue what you meant otherwise about mixing issues. I am 
attempting to answer every possible question being raised. So far 
there has been a few very constructive and helpful emails, and lots of 
sidetracks. If you want to stay focused, re-read my initial post, as 
well as my most latest post with the new tool capabilities, or just 
read the Sophox wiki page and try to follow the style of Simon & 
Tobias - both have raised valid objections, and in both cases it 
resulted in tool's improvements.


On Mon, Nov 13, 2017 at 3:05 AM, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> wrote:


Le 13/11/2017 à 01:16, Yuri Astrakhan a écrit :

You are right that =0 and =no seem like nobrainers, but if we
have listed them as deprecated, we should not use them.

Deprecated? Where did you find that?
(Swearwords somewhere here. Did someone already said that you mix
issues?)

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




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