Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[marc marc]

je pense que tout est dans le titre :)
une épreuve sportive cycliste n'est pas un itinéraire cycliste.
Pour prendre une comparaison, ce n'est pas parce qu'une épreuve sportive 
permet aux F1 de rouler dans Monaco que ces mêmes rues constituent
un itinéraire routier à grande vitesse en dehors du we concerné.

si quelqu'un voulait faire d'osm un lieu pour recueillir ces infos,
ce qui n'est pas nécessairement une bonne idée comparé à un umap,
il faudrait à tout le moins un type=event au lieu de type=route
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[marc marc]

Merci pour cet article pratique pour ceux qui ne le connaissaient pas.
a publier aussi sur osm.fr ?

Le 05. 11. 18 à 16:46, Christian Rogel a écrit :
> On n’a droit qu’à 5 cartes ou mises à jour de cartes

n'est-ce pas plutôt "droit à 5 cartes simultanées et leur maj " ?
j'ai testé OsmAnd avec différente carte, je me souviens pas avoir été 
bloqué après avoir fait 5 changements de carte

Le 05. 11. 18 à 18:01, ades a écrit :
 > Et par rapport avec map.me ? Utilisé sur iOS je l’ai trouvé
 > plutôt bien foutu et fonctionnant pas mal du tout.

c'est tjs étonnant les goûts et les couleurs.
je considère maps.me comme le logiciel "basé osm" grand public
le + bugé tant niveau conception que "bug" au sens premier
- ne montre pas les hôtels osm mais ceux de leurs partenariats.
ce qui conduit les utilisateurs a créer des notes pour créer des hôtels 
existants dans osm mais pas chez les dit partenaires.
- a une liste longue comme le bras de problème de rendu pour des 
polygones, ce qui conduit aussi à des notes/création de doublon.
- a une gestion des langues très fluctuantes (parfois crée des name:fr 
en chinois en France, parfois un name:x dépendant de la locale du 
contributeur, parfois c'est bien compliqué à comprendre la logique).
Les 2 avantages que j'ai trouvé à maps.me c'est qu'il fonctionne sur des 
vieux trognons là oü OsmAnd ne démarre pas, et la facilité de 
l'interface pour des modifs basique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Tagging-fr] access=yes -> accès public

[marc marc]

je répondu sur talk-fr vu que tagging-fr est mort né

Le 05. 11. 18 à 17:28, Vincent Bergeot a écrit :
> Dans le wiki osm, sommes nous d'accord que public devrait être "yes" ici 
> : https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dtoilets#Acc.C3.A8s

oui c'est une erreur de traduction présente depuis la création
de la version fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout d'aménagements cyclable avec StreetComplete

[marc marc]

Le 05. 11. 18 à 11:35, Axelos a écrit :
> identifier les doublons

c'est bien cela le soucis.
il faudrait un tag genre cycleway=separate
qui indique que cet élément est déjà renseigné
mais par un autre objet à la manière de sidewalk=separate

il y a une propal antédiluvienne à ce sujet à la base
pour réparer les cas où l'objet séparé casse le routage
mais personne n'a à ma connaissance travaillé dessus.
je me souviens plus du degré de maturité qu'elle avait
ni même de son url :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question du nouveau abonné du Tchad

[marc marc]

Le 05. 11. 18 à 10:39, Lucien Misdombaye a écrit :
> s'il y a des manuels de prise en mains précis
Bonjour et bienvenue,

Si tu utilises iD (l'éditeur par défaut sur www.openstreetmap.org),
je te conseille d'expérimenter son tutoriel
il y a aussi
https://wiki.openstreetmap.org/wiki/FR:Guide_du_d%C3%A9butant
https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments_cartographiques
https://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum

Si tu as une question, n'hésites pas.

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

Re: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police

[marc marc]

J'utiliserais old_name

Le 3 nov. 2018 à 22:39, Laurent Combe 
mailto:laurent.co...@free.fr>> a écrit :

une question plus "opérationnelle"

que faire d'un ancien bâtiment ayant abrité jusqu'à "récemment" la brigade 
locale
maintenant ils disposent de locaux tout neuf qq patés de maisons plus loin avec 
accueil du public et tout ce qui va bien

que mettre comme tag sur l'ancien bâtiment qui a perdu sa dénomination mais qui 
garde encore sur sa façade les mots "GENDARMERIE NATIONALE" ?
le way en question https://www.openstreetmap.org/way/61782416
avec une belle vue photo prise par sogefi début octobre : 
https://www.mapillary.com/map/im/JRMPJzgXfvGhG7G6445MQQ

Laurent



Le ven. 2 nov. 2018 à 10:03, Vincent de Château-Thierry 
mailto:osm.v...@free.fr>> a écrit :
Bonjour,

> De: "Noémie Lehuby" 
> mailto:noemie.leh...@zaclys.net>>
>
> pour différencier gendarmerie et polices, on est partis sur le tag
> operator, qui est celui qui semblait le plus utilisé à date.
> On avait vu aussi le tag police qui reprend la même idée mais il est
> vraiment très peu utilisé :
> https://taginfo.openstreetmap.org/keys/police#values

On ne parle pas de la même chose. Les valeurs d'operator, au moins pour les 
polices municipales, sont distinctes par commune ou communauté de commune. Je 
ne parle pas de ça mais bien du type d'entité : municipale ou nationale pour la 
police, sinon gendarmerie.
Pour prendre des applications concrètes : si on souhaitait cartographier les 3 
natures de police (avec un picto distinct par nature), ou répondre à la 
question : "quelles communes ont une police municipale ?", en s'appuyant sur le 
tag police:FR on pourrait traiter ces questions. En s'appuyant sur operator=*, 
qui a 59 valeurs distinctes à l'instant, dont de nombreux "Mairie de xxx" qui 
sont logiques pour ce tag, on ne pourrait pas.

vincent

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

Re: [OSM-talk-fr] Borne de puisage

[marc marc]

Le 31. 10. 18 à 21:18, Vincent de Château-Thierry a écrit :
> En suivant ton raisonnement tous les bâtiments pourraient se contenter d'un 
> "building=yes"

le tag building décrit l'apparence d'un bâtiment
donc oui 2 bâtiments ayant l'apparence d'église auront le même tag 
building=church même si l'une des 2 a été transformé en loft,
ce qui se renseigne avec le tag building:use=residential
c'est pas très loin du tag usage :)
Dans cette logique ils peuvent avoir tous building=yes + building:use
si tu te préoccupes pas de leur apparence

histoire d'être constructif, il y a des tags :
- pour les prises d'eau dans des bassins et rivières (mais
le wiki est aussi axé pompier)
- pour les sources d'eau potable
- un autre pour les points de fourniture d'eau style remplissage 
réservoir caravane

sans avoir été voir le détail des débits des différents objets
en question, je serrais surpris quand même si on peux pas
décrire correctement ces bornes de puisage avec les schémas existant.

mais si effectivement cela manque, je suis preneur d'info un peu 
objective sur pq les 4 (ce qui me semble tjs trop) schéma ne vont pas
afin de voir si c'est pas le schéma ou le wiki qui est à améliorer
(la page fr des bornes n'est par exemple pas traduite depuis les 3 
rounds d'améliorations successives)

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

Re: [OSM-talk-fr] Site web pour récupérer coordonnées GPS d'un point?

[marc marc]

Le 31. 10. 18 à 14:33, Marc M. a écrit :
> Le 31. 10. 18 à 14:07, Shohreh a écrit :
>> Cyrille37 OSM wrote
>>> Sur openstreetmap.org, le bouton "partager" dans le menu à droite (barre
>>> verticale).
> 
> perso j'utilise simplement :
> clic droit, centrer la carte
> et tu copies l'url obtenue

réponse à oublier, j'ai mal lu la question :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Site web pour récupérer coordonnées GPS d'un point?

[marc marc]

Le 31. 10. 18 à 14:07, Shohreh a écrit :
> Cyrille37 OSM wrote
>> Sur openstreetmap.org, le bouton "partager" dans le menu à droite (barre
>> verticale).

perso j'utilise simplement :
clic droit, centrer la carte
et tu copies l'url obtenue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Borne de puisage

[marc marc]

Le 31. 10. 18 à 13:30, Vincent Bergeot a écrit :
>> J'ajoute une note car certains prennent ce schema de tags  
>> comme une description erronée d'une vraie borne incendie.

> on tente de le renseigner sur le wiki également : 
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dhydrant

perso après avoir participé aux 3 propals d'amélioration successives
sur la ml tagging, je trouve ce tag une erreur qui fractionne
un sujet oü de gros effort d'harmonisation ont été fait.
la page va même jusqu'à avoir les photos de bornes incendies...
est-ce un lapsus pour montrer à quel point c'est la même chose ?
idem s'il faut mettre une note sur chaque objet

je trouve bien moins ambigu de rester simple :
si 2 objets sont identique, ils ont le même tag
si l'usage change, on peux rajouter un tag usage=*

prenons un autre exemple : une caserne de pompiers, certaines de leur 
actions ne sont des pas lié à l'urgence (aller vider une cave inondée)
est-ce qu'on va créer un not-emercengy=not-fire_station pour diviser
la caserne en 2 et séparer le local où sont stockée les pompes
vide-caves du camion incendie ?

je trouve qu'on fait mieux de renseigner les critères objectifs 
(pressions, débit, raccord ...) lorsqu’ils sont dispo
quitte à rajouter un tag usage=* si on veux vraiment spécifier
l'usage habituel (ici les bornes incendies ont pour usage principal 
d’alimenter les bétonneuses des nouvelles constructions...
je me vois mal les changer le tag principal parce
qu'il "manque" d'incendie)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Retrouver un changeset commenté

[marc marc]

Le 31. 10. 18 à 10:34, Jérôme Seigneuret a écrit :
> J'ai un changeset qui a été commenté mais n'ayant pas eu le temps 
> de le traité j'arrive pas à le retrouver.

rechercher la notification dans ta boite email :)
ou
http://hdyc.neis-one.org/ mettre ton nom d'utilisateur osm
clic sur "created x comments" dans la première partie
puis clic "without an answer" tout en haut
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] migrer les amenity=swimming_pool (déprécié)

[marc marc]

J'en ai migré 700 à la main (=vérif visuelle) de l'ancien
vers le nouveau schéma (une confusion bassin<>piscine)

En séparant la migration de tag de l'ancien schéma vers le nouveau.
il y a 0 risque de dégradation. si c'était faux avant,
cela reste faux, si c'était juste, cela reste juste.
cette étape permet juste d'avoir un tag pour les bassins
au lieu d'en avoir 2, ce qui participe aussi à la confusion.

Paul proposait exclure aussi les nœuds
cela va avec ce critère en plus ?
j'ai l'impression qu'on est entrain de mélanger les 2
à bloquer la suppression de l'ancien schéma pour une question
de confusion de sens qui n'a aucun lien avec ancien/nouveau schéma.
Au rythme où cela va, dans 60 jours, il seront tous fait à la main.
Ou bien je passe à autre chose + utile que de les vérifier tous :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] confusion entre la piscine=le bassin avec l'eau et la piscine=le lieu contenant un ou plusieurs bassins

[marc marc]

Je pense toujours qu'il faut scinder (et donc je scinde mon message) :

- la correction d'erreur de sens (confusion entre la piscine=le bassin 
avec l'eau et la piscine=le lieu contenant un ou plusieurs bassins,
un vestiaire, etc...) et qui existe tant dans l'ancien que le nouveau 
schéma (peut-être des preset mal traduit dans iD et josm)
Osmose est sans doute le meilleur allié une fois un critère trouvé et 
donc ce serrait utile de lister les critères si quelqu'un est motivé 
pour le coder :
- un bassin avec un site web, téléphone, wikipedia ou de + de x m2 est 
probablement une piscine
- un bassin dans un bassin est probablement un bassin dans un piscine 
(mais cela peux être un doublon)
mais est-ce utile ? on a déjà 8000 alertes osmose que personne ne semble 
motivé à traité (donc l'utilité première est sans doute juste le bleu 
sur la carte)
http://osmose.openstreetmap.fr/fr/errors/graph.png?item=3080
https://osmose.openstreetmap.fr/fr/errors/?item=3080

- frilosité pour la migration de tag "bassin" de l'ancien schéma
vers le nouveau -> autre sujet

Cordialement,
Marc

Le 29. 10. 18 à 20:54, Noémie Lehuby a écrit :
> Hello,
> 
> J'ai fait une passe sur les amenity=swimming_pool (ainsi que les 
> leisure=swimming_pool) avec phone, website et wikidata.
> J'ai aussi essayé opening_hours mais ce n'est pas assez discriminant, il 
> y avait beaucoup de faux positifs (où le bassin et la piscine sont 
> présents tous les deux, tous deux avec les tags opening_hours, pas 
> toujours avec les mêmes valeurs d'ailleurs).
> 
> -- 
> Noémie Lehuby
> 
> Le 27/10/2018 à 19:28, Paul Desgranges a écrit :
>> Normalement tu ne devrais plus trouver de "amenity=swimming_pool ayant 
>> un tag leisure/name/building", puisque justement c'était l'étape d'avant
>>
>> Par contre j'ai cherché à l'instant les "amenity=swimming_pool" de 
>> type node seulement sur overpass-turbo https://overpass-turbo.eu/s/D9Q
>> et les premiers cas regardés ne peuvent pas être transformés 
>> directement en "leisure=swimming_pool"  !
>> - https://www.openstreetmap.org/node/1820461288 celui-ci c'est un 
>> "leisure=sports_centre + sport=swimming"
>> - https://www.openstreetmap.org/node/3648626536 celui-ci c'est un 
>> "leisure=sports_centre + sport=swimming"
>> - https://www.openstreetmap.org/node/1904181893 celui-ci c'est un 
>> bassin, mais il est déjà taggué comme bassin, et il est à coté d'un 
>> établissement qui n'est
>> pas taggué comme  "leisure=sports_centre + sport=swimming", et c'est 
>> plutôt ça qu'il faudrait faire du coup
>> -  et les autres que j'ai regardé aussi ...
>>
>> Donc je crains que la conversion massive soit un peu risquée.
>>
>> Il faudrait au moins couper en deux le traitement :
>>  - les nodes d'un coté (il y en a 102 
>> <https://overpass-turbo.eu/s/D9Q>), par nature on ne peut pas 
>> connaître leur superficie :  j'ai l'impression qu'il faudrait regarder 
>> chacun des cas ? et dans n'y aurait-il pas un outil qui permettrait de 
>> se répartir la charge ?
>>  - les ways d'un autre coté (il y en a 6120 
>> <https://overpass-turbo.eu/s/D9R>), il faut les traiter en fonction de 
>> leur superficie
>>    -- les grandes superficies sont à regarder au cas par cas (par 
>> exemple https://www.openstreetmap.org/way/129407009
>>  est à transformer en "leisure=swimming_area")
>>    -- les petites superficies je ne sais pas en fait, regarder si on 
>> ne peut pas exploiter la présence d'un autre tag : 'phone=*' ou 
>> 'access=customers' ou 'covered=yes' ?
>>
>>
>> Je pars une semaine, donc je ne pourrais pas participer à la suite de 
>> ceci la semaine prochaine en tout cas.
>> A bientôt
>> Paul
>>
>>
>>
>> >Le 27/10/2018 /à 17:51:09 2018/, Marc marc a écrit :
>> > J'avais déjà passé en revue le critère des 2000m2 mais
>> > il peux toujours y avoir de nouveaux cas entre temps.
>> >De toute façon, je proposais de le faire avec ceinture
>> >et bretelles. et donc ces cas sont ignorés dans ma correction.
>> >Si personne n'a plus d'objection, je ferrai la conversion
>> > des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
>> >ayant une surface < 2000m2 et situé en France
>> >en leisure=swimming_pool
>>
>> Le 27/10/2018 à 15:55, Paul Desgranges a écrit :
>>> Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il 
>>> n'y a plus de "amenity=swimming_pool + name=*" ni de 
>>> "amenity=swimming_pool + building=*" (sauf erreur ?)
>>> (l'occasion à chaque fois de faire un

Re: [OSM-talk-fr] Suivi de l'état du bâti par rapport au cadastre

[marc marc]

Bonjour,

Le 29. 10. 18 à 18:19, Gautier Pelloux-Prayer a écrit :
> Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
> ne pas en rajouter un nouveau ?!

hasard de calendrier, hier je me disais que je venais de trouver l'avant 
dernière pièce manquante pour faire "un peu mieux que "trop à la main"
https://github.com/sebastien-bugzilla/BatiOsm
http://forum.openstreetmap.fr/viewtopic.php?f=5=1762
l'autre pièce manquante c'était la tienne :)

> https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
> commune, afin de connaître de quand date le dernier import du cadastre 
> réalisé. Cela permet de détecter :

double bravo !
- d'avoir eu l'idée et de l'avoir fait
- d'avoir éviter de recoder tous les briques au profit d'une utilisation 
de l'existant (cela permet qu'une amélioration des ces briques profite 
aussi à ton interface)

> - les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
> vectoriel disponible)

j'ai pas trop compris comment on obtenait cette liste.
il y a l'air d'avoir 0.3% de commune concernée.
mais soit elles sont trop petite pour les trouver avec le zoom affichant 
la France entière, soit j'ai raté qlq chose :)

> - les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
> existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
> à la main (IGN, Bing)… mais il manque 90+% du bâti.

l'outil BatiOsm (ou une comparaison sommaire entre le nombre de bâtiment 
osm et celui dans l'extract cadastre osm.fr) permettrait de se faire une 
idée des communes où le manque est le plus criant.
On peux aussi encore plus sommairement se baser sur la présence ou non 
de l'extract sur le serveur.

> - et sinon la date d'import des autres villes (en se basant sur le tag 
> /source/ des bâtiments).

cette méthode histoire étant de + en + dépréciée,
une futur amélioration pourrait tenir compte de la date de modif ou 
d'analyser l'historique (même si c'est bcp plus long)

> les fichiers Etalab

l'an passé il était urgent d'attendre.
quel est la situation actuelle ? quelqu'un les utilise ?
sur le wiki, si c'est documenté, c'est "sous le radar"
dans les pages concernant le cadastre

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

Re: [OSM-talk-fr] Changement nom carburants Union Européenne

[marc marc]

Le 28. 10. 18 à 14:00, deuzeffe a écrit :
> Osmose, ae, manuel (HAHAHA, pardon, c'est nerveux), rien, ot'chose ?
> Que disent les autres listes européennes ?

sur tagging (la ml mondiale), je n'ai rien vu passé

>> - fuel:b7 pour le Diesel
>> - fuel:b10 pour le Diesel (grand froid) 

ce point là m'étonne (grand froid avec un B > à l'autre)
j'ai croisé une entreprie qui vend du bio-diesel 2ieme génération (fait 
à partir d'huile culinaire usagée)
et à titre de précaution, ils disent de faire moitié moitié pendant
les grands froids
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreurs Osmose : rue qui débouche sur une zone piétonne

[marc marc]

Le 28. 10. 18 à 11:20, Cédric Frayssinet a écrit :
> /*Jonction imparfaite, joindre le nœud ou utiliser l’attribut “noexit” 
> si sans issue*/
> 
> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.982123=3.136746==1==

ce n'est pas la place le soucis parce que là c'est correctement connecté
c'est la proximité des 2 routes très proche à mon avis
on le voit avec l'alerte au nord concernant
https://www.openstreetmap.org/node/704359470
à cet endroit là il manque un noexit sur ce noeud

pour l'autre extrémité ou les 2 rues sont tout aussi proche,
c'est un faux positif
osmose gagnerait peut-être a donner le way proche
au lieu de donner le way auquel appartient le noeud
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] baignade interdite

[marc marc]

Le 28. 10. 18 à 08:28, osm.sanspourr...@spamgourmet.com a écrit :
> zones de baignade _interdite_.
> https://wiki.openstreetmap.org/wiki/Swimming_and_bathing

le plus clair me semble swimming=no mais peu utilisé
https://taginfo.openstreetmap.org/tags/swimming=no
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

[marc marc]

J'avais déjà passé en revue le critère des 2000m2 mais
il peux toujours y avoir de nouveaux cas entre temps.

De toute façon, je proposais de le faire avec ceinture
et bretelles. et donc ces cas sont ignorés dans ma correction.

Si personne n'a plus d'objection, je ferrai la conversion
des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
ayant une surface < 2000m2 et situé en France
en leisure=swimming_pool

Le 27. 10. 18 à 15:55, Paul Desgranges a écrit :
> Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il n'y 
> a plus de "amenity=swimming_pool + name=*" ni de "amenity=swimming_pool 
> + building=*" (sauf erreur ?)
> (l'occasion à chaque fois de faire un peu de micromapping autour de ces 
> établissements...)
> 
> Ce que je n'ai pas fait, c'est le traitement de tous les 
> "amenity=swimming_pool" qui auraient une surperficie assez grande pour 
> suspecter un "leisure=sports_centre",
> cela reste une étape supplémentaire à faire avant le changement massif 
> des autres "amenity=swimming_pool" ?
> 
> Bonne journée
> Paul
> 
> 
> 
> 
>> je regarde de mon coté tous les cas qui sont exclus de l'édition de masse
>> Si je devais le faire
>>> 1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
>>> 'Piscine privée' pour mettre ça dans la "description"
>>> 2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
>>> mentionné) :   les amenity=swimming_pool nommés (sauf les noms m. 
>>> ci-dessus à traiter individuellement)   les amenity=swimming_pool qui 
>>> sont aussi building
>>>   les amenity=swimming_pool qui sont aussi leisure=sports_centre
>>>  Car tous ceux là ont vocation à devenir des "leisure=sports_centre
>>> sports=swimming name=... building=...", (sauf exception donc avec une
>> vérification visuelle)
>>> 3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
>>> leisure=*
>> et puisque tu es partant pour le reste, que moi je considère bcp plus 
>> risqué, et bien ça se complète pas trop mal
> 
> 
> 
> ___
> 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] signification multiple crossing=zebra

[marc marc]

En fait le soucis est quand tu fais l'inverse :
tu prend une image sat d'un endroit que tu ne connais pas,
tu édites avec iD, tu vois un zebra au sol,
tu ajoutes un "passage piéton zebra" et iD fait la supposition 
qu'automatiquement c'est un passage sans feu de circulation parce
qu'aux UK, il semblerait que le marquage au sol soie différent
pour les passages avec et sans feu, ce qui n'est pas le cas
ni en France ni en Belgique ni en Suisse
c'est cette supposition là que je propose de corriger.
si tu renseignes passag piéton avec zebra, ca veux juste dire cela.
permettant ainsi à ceux qui le souhaite d'ensuite compléter les
données pour renseigner si le passage piéton a ou non des feux.

Le 26. 10. 18 à 18:59, Gwenaël Jouvin a écrit :
> Bonsoir,
> 
> Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
> apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
> vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
> (wheelchair=yes|limited|no).
> 
> Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra 
> car, s’il a certainement une signification au Royaume-Uni ; c’est différent 
> en France où, par définition, tout passage pour piétons est marqué sur la 
> chaussée, donc ils sont tous « zebra » par défaut.
> 
> Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés 
> dans l’urbanisme, par exemple délimités par des pavés, des clous voire un 
> revêtement ou des pierres colorées.
> Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
> point de vue de la signalisation routière [1, art. 118].
> Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
> l’usage mais litigieux par la loi.
> 
> Enfin pour finir sur les points litigieux, on voit aussi des passages 
> intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
> d’être périlleux pour les deux-roues.
> 
> Gwenaël
> 
> 
> [1] IISR 7 : 
> http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
> [2] Circulaire du 15-05-1996 : 
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640
> 
> 
> Le 25/10/2018 à 23:51, marc marc a écrit :
>> Bonjour,
>>
>> j'aurais du vous proposer une édition de masse sur ce sujet.
>> c'était en préparation depuis longtemps depuis que le problème avait été
>> identifié lors d'une discussion cartomobilité qui discute entre autre
>> des problèmes de comment osm peux aider pour renseigner l'accessibilité
>> multiple.
>> mais voila, ces oir josm a poussé un patch qui complique encore la
>> chose. je vais donc vous exposer le problème en français, traduction
>> de celui que je viens de poster sur tagging (la ml mondiale anglaise
>> pour les problèmes de tag).
>>
>> Bonjour. Bonjour,
>>
>> J'ai un gros problème avec crossing=zebra.
>> il empêche de remplir d'autre valeur pour le croisement comme
>> crossing=traffic_signals (passage piéton avec un feu de circulation)
>> crossing=uncontrolled (passage piéton sans feu)
>> le wiki[1] dit que crossing=zebra est un raccourci pour
>> crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
>> mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
>> ont des zébra avec feu qui doivent donc être renseign avec
>> crossing=traffic_signals
>> donc à la fin, crossing=zebra n'a pas de sens... peut-être
>> que le contributeur précédent voulait dire crossing=uncontrolled +
>> crossing_ref=zebra
>> mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a
>> aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat
>> par exemple).
>> J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra
>> crossing_1=signals_traffic_signals
>> ou crossing=zebra;traffic_signals qui montrent que c'est un problème.
>>
>> un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev
>> n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
>> en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
>> en faveur du croissing=zébra
>>
>> Je fais partie d'un groupe de cartographes travaillant sur
>> l'accessibilité yant l'intention d'ouvrir une discussion pour y
>> remédier, mais l'actualité des commit nous a précédés.
>>
>> donc ma requête est : comment éviter à nouveau une balise multi sens ?
>>
>> Peut/doit-on séparer le type de croisement du marquage au sol ?
>> en résumé : changer les crossing=zebra au profit d'une autre balise ?
>> si oui crossing_Ref est-il si laid que dans le même temps un autre tag
>> en a besoin 

[OSM-talk-fr] signification multiple crossing=zebra

[marc marc]

Bonjour,

j'aurais du vous proposer une édition de masse sur ce sujet.
c'était en préparation depuis longtemps depuis que le problème avait été 
identifié lors d'une discussion cartomobilité qui discute entre autre 
des problèmes de comment osm peux aider pour renseigner l'accessibilité 
multiple.
mais voila, ces oir josm a poussé un patch qui complique encore la 
chose. je vais donc vous exposer le problème en français, traduction
de celui que je viens de poster sur tagging (la ml mondiale anglaise 
pour les problèmes de tag).

Bonjour. Bonjour,

J'ai un gros problème avec crossing=zebra.
il empêche de remplir d'autre valeur pour le croisement comme 
crossing=traffic_signals (passage piéton avec un feu de circulation) 
crossing=uncontrolled (passage piéton sans feu)
le wiki[1] dit que crossing=zebra est un raccourci pour 
crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
ont des zébra avec feu qui doivent donc être renseign avec 
crossing=traffic_signals
donc à la fin, crossing=zebra n'a pas de sens... peut-être
que le contributeur précédent voulait dire crossing=uncontrolled + 
crossing_ref=zebra
mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a 
aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat 
par exemple).
J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra 
crossing_1=signals_traffic_signals
ou crossing=zebra;traffic_signals qui montrent que c'est un problème.

un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev 
n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
en faveur du croissing=zébra

Je fais partie d'un groupe de cartographes travaillant sur 
l'accessibilité yant l'intention d'ouvrir une discussion pour y 
remédier, mais l'actualité des commit nous a précédés.

donc ma requête est : comment éviter à nouveau une balise multi sens ?

Peut/doit-on séparer le type de croisement du marquage au sol ?
en résumé : changer les crossing=zebra au profit d'une autre balise ?
si oui crossing_Ref est-il si laid que dans le même temps un autre tag 
en a besoin à utiliser pour le marquage au sol ?
(ajout hors traduction : perso je suis partisant d'étape limité séparée
et donc initialement j'aurais changer crossing=zebra en 
crossing_ref=zebra et reporté le choix d'un meilleur non pour le 
marquage dans un autre sujet)

évitons l'argument "il y a trop de cas à régler",
cela ne m'effraie pas de proposer une édition de masse une fois qu'un 
schéma cohérent a été établi.
mais le fait d'avoir la moité des outils qui remplissent une valeur avec 
une autre signification que l'autre ou que la signification historique 
est un gros problème pour l'utilisation. des données.

[1] https://wiki.openstreetmap.org/wiki/Key:crossing
[2] https://github.com/openstreetmap/iD/issues/4788
[3] https://josm.openstreetmap.de/ticket/16793
https://taginfo.openstreetmap.fr/search?q=%3Dzebra

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

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

[marc marc]

Le 24. 10. 18 à 18:30, ades a écrit :
> waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
> moins de 12m?

faudrait voir d'oü vient cette limite mais son sens est plutôt :
"au plus étroite est la rivière, au moins on gagne par rapport
à la représentation filaire"
Mais tot ou tard, on y viendra à tout faire en 2d (faut juste
que cela soi harmonieux avec l'existant)

> highway:* sauf autoroutes, voies rapides tous les usages sont inclus ? velo, 
> autos, piétons, bourrins, quads etc. ?

non, et le détail dépend du code la route de chaque pays
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
  > bâtiments isolés au milieu d’un farmland ? Dans la mesure où il ne 
s’agit pas d’exploitation agricole
landuse c'est l'utilisation actuelle. donc landuse=residential me semble 
adapté.
Si on veux vraiement insister qu'il y a eu un changement d'affectation
et non pas une erreur de tag, on peux rajouter
was:landuse=farmyard

> préciser la pelouse, le jardin potager, la cours devant, garde t-on le 
> ‘residencial’ ?

normalement chaque lieu ne devrait avoir qu'un landuse
donc la pelouse d'une parcelle résidentielle devrait rester en résidentiel.
il y a l’éternel débat entre ceux qui voudrait un landcover (pour dire 
cette partie de la zone résidentielle est couverte d'herbe ou a quelquea 
abres etc) et ceux pour qui landuser=grass est tellement courant qu'il 
faut garder cette erreur pour l’éternité. du coup landcover n'est pas 
rendu sur osm.org (ce qui n’empêche pas de l'ajouter mais démotive certains)

> landuse: flowerbed ? peut-on utiliser ce tag ( 6 occutrences pour l’instant) ?

tu peux utiliser le tag que tu veux :) mais c'est mieux si c'est 
compréhensible et utilisé :)
si c'est un landuse, c'est une zone qu'on sacrifie pour lutter
contre les inondations en aval en cas de crue ?

> landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
> landuse:forest ?

il y a 6 façons de voir une différence ou pas entre les 2
https://wiki.openstreetmap.org/wiki/Forest
la seule chose que tu peux en déduire des 2 tags c'est qu'il y a
eu des arbres, tout le reste est variable selon le contributeur.
c'est là qu'à nouveau un landcover permettrait de sortir de conflit
landcover=trees + managed=yes/no
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contributeur(e) compulsif(ve) et imprécis, faut faire quoi ?

[marc marc]

non faut pas être maso.
si t'as posté un commentaire sur 2-3 changeset
et qu'il en tient pas vraiement compte,
envois un email au DWG

http://hdyc.neis-one.org/?Gelweo
Mais tu parles de lui ?
soit l'outil bug soit je vois qu'un seul commentaire
à propos d'une erreur

est-ce que toutes les erreurs dont tu parles
ne serrait-elle pas simplement du au fait qu'il
map en fonction de l'ortho bient + qu'une médisance ?
Une zone pavée avec de l'herbe, cela se confond facilement
idem pour les vergers "fraîchement" arraché etc


Le 24. 10. 18 à 18:07, ades a écrit :
> merci pour vos réponses.
> Pendant ce temps, Gelweo continue, et j’ai même l’impression que ça s’aggrave 
> ;-) .
> Je viens juste de jeter un coup d’œil, invention de voies pour vélo ou pour 
> piétons, invention de noms, dessin de vergers arraché il y a 2 ans, mais 
> encore sur la BDOrtho… tag en 'landuse:grass' de zones pavées avec de l’herbe 
> entre les pavés, changement des riverbanks de la Loire en fonction de l’ortho 
> (image faite en fin d’été) invention de prairie là ou il n’y en pas, etc., 
> etc. .
> Sauf qu’après une ou deux remarques (certes je ne suis pas diplomate) ou 
> réparations d’erreurs, il revient et recommence, au même endroit et en pire…
> Je sais que si l’on travaille à l’échelle de Corinne, ça n’a pas 
> d’importance, mais bon…
> Encore s’il s’agissait d’un travail continu et « systématique » y-aurait sans 
> doute moyen de discuter, mais, en gros, ça va d’Angers à Saumur, sans 
> logique, au petit bonheur, " tiens si je déplaçais un point de ce way, bonne 
> idée… » « tiens si je rajoutais (inventais) une piste cyclable » ;-)
> 
> Je veux bien m’atteler à la tâche des vérifications (pour ma ‘zone de 
> confort', mais je modifie ou je me contente de dire qu’il serait peut-être 
> bien de coller à la réalité ?
> J’aimerais aussi que mes remarques/modifs soient validées, sinon ça va se 
> transformer (déjà un peu le cas) en querelle débile et non productive ; c’est 
> possible ?  comment ?
> 
> Pour être sur de ne pas dire trops de conneries, j’ouvre un outre fil pour 
> des questions simples de tags.
> 
> @osm.sanspourriel
> j’ai vérifié cadastre et orthophoto, quasiment immeuble par immeuble (y-en a 
> 2043). Le cadastre est décalé de 60cm par rapport à des repères de 
> nivellement (eux-mêmes donnés à 10cm près).
> J’ai pensé (ptet à tort) que ce décalage n’est pas vraiment significatif 
> 60cm, c’est 3 px de la BdOrtho, c’est largement inférieur à l’erreur que l’on 
> peut faire en reportant la BDOrtho sur OSM, surtout quand la façade de 
> l’immeuble est visible, cas très courant, la trace de l’égout de la toiture 
> n’est pas superposée avec la trace au sol du bâtiment.
> Le cadastre utilisé est la dernière version du PCI.
> 
> @marc-marc
> Je vais essayer les commentaires, pour la zone que je connais, pas pour le 
> centre-ville d’Angers, pas sorti de l’affaire, quasiment 350 changesets, 
> parfois pour le déplacement d’un point ;-((
> 
> Pour le cadastre voir ci dessus.Je ne pense pas qu’il faille le décaler pour 
> 60cm, mais s’il faut le faire…
> 
> @phil
> merci pour toutes ces infos, mais quo de la taxe foncière ?
> ___
> 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] Calcul d'itinéraire prenant en compte les travaux

[marc marc]

Pour ma durée, je pense que cela dépend surtout de la réactivé
à les retirer mais un bon mois me semble un ordre de grandeur.
Faut pas oublier que certains app ne mettent leur donnée à jour
qu'une fois par mois. si tu tombes avant la modif de fermeture,
c'est pas trop grave, c'est comme si elle n'existe pas.
mais si tu tombes le jour avant la réouverture, elle n'aura
lieux qu'un mois + tard.

pour EDO, l'autre soucis, c'est que c'est Franco-français
et je doute qu'il y ai bcp d'app motivé à faire une routine
pour chaque pays.
Freed a crée une liste Opentraffic
https://listes.openstreetmap.fr/wws/info/opentraffic
mais personne n'y a parlé :)


Le 24. 10. 18 à 17:42, Julien Coupey a écrit :
> Re,
> 
>  > Idéalement, il faudrait éviter de modifier OSM pour y déclarer des
>  > événement ponctuels
> 
> Oui bien sûr, c'est pour cela que j'ai précisé « pour peu que la durée 
> des travaux le justifie ». Dans les exemples indiqués initialement, on 
> est sur du 3 à 4 mois de fermeture, donc ça me semble tout à fait 
> pertinent de tagger en « construction » le temps des travaux.
> 
>  > Et, bien évidemment, il faudrait en parallèle, que les sites de
>  > calculs d'itinéraires tiennent compte d'EOD
> 
> Sans rentrer dans le débat de ce qu'il faudrait idéalement, ce n'est pas 
> le cas pour les principaux outils libres existants (OSRM, GraphHopper, 
> Valhalla). D'une part car une telle intégration n'a jamais été faite. 
> D'autre part comme indiqué par Christian parce que certains algos ont 
> besoin d'une vision statique du graphe à un instant donné et, une fois 
> un certain nombre de pré-calculs faits, ne pourront de toute façon pas 
> réagir de manière dynamique à d'autres sources d'informations.
> 
> À mon avis, le premier pas le plus pragmatique est de faire la part de 
> ce qui vaut le coup d'être indiqué en dur comme inaccessible pendant une 
> durée significative.
> 
> À +
> Julien
> 
> On 24/10/2018 16:21, Francescu GAROBY wrote:
>> Bonjour,
>> Idéalement, il faudrait éviter de modifier OSM pour y déclarer des 
>> événement ponctuels (ou à courte durée), car ce serait augmenter les 
>> risques de casser quelque chose.
>> Il vaudrait mieux renseigner tout cela dans OpenEventDatabase : 
>> http://live.openeventdatabase.org/
>> Et, bien évidemment, il faudrait en parallèle, que les sites de 
>> calculs d'itinéraires tiennent compte d'EOD. est-ce le cas ? Je 
>> l'ignore totalement...
>>
>> Francescu
>>
>> Le mer. 24 oct. 2018 à 16:13, Julien Coupey > > a écrit :
>>
>>     Bonjour Sébastien,
>>
>>     Le meilleur moyen pour que **tous** les calculateurs d'itinéraires
>>     basés
>>     sur OSM prennent en compte une rue barrée est de l'indiquer comme 
>> telle
>>     directement dans OSM pour peu que la durée des travaux le 
>> justifie. En
>>     tout cas c'est ce que je fais dans ce cas autour de chez moi en
>>     utilisant highway=construction (pourquoi pas ajouter la date de 
>> fin des
>>     travaux si elle est connue).
>>
>>     La question me semble du coup être de savoir comment exploiter
>>     efficacement les données fournies par la ville pour assurer des 
>> mises à
>>     jour dans les deux sens (fermeture et ré-ouverture).
>>
>>     À +
>>     Julien
>>
>>     On 24/10/2018 15:53, Sébastien Dinot wrote:
>>  > Bonjour à tous,
>>  >
>>  > On vient de me montrer que la communauté urbaine « Toulouse
>>     Métropole »
>>  > publie sur son site Open Data une API permettant de connaitre les
>>  > chantiers en cours
>>  >
>> 
>> 
>>  
>>
>>
>>  > sur la voirie.
>>  >
>>  > La ville de Toulouse publie elle-même ces informations sur son
>>     site Plan
>>  > DPI  (qui utilise au passage un
>>     fond de
>>  > carte OSM qui commence à dater).
>>  >
>>  > Voici par exemple les travaux en cours dans mon quartier
>>  >
>> 
>> .
>>  
>>
>>  >
>>  > Ces informations sont des plus utiles : les travaux visibles 
>> sur le
>>  > dernier lien entrainent la fermeture de deux rues, ce qui modifie
>>  > copieusement le flux de circulation dans mon quartier. Or,
>>     l'impact des
>>  > travaux sur l'axe routier est indiqué dans la description (ici «
>>     Route
>>  > barrée »).
>>  >
>>  > Du coup, il est pertinent de prendre en compte ces informations
>>     dans le
>>  > calcul d'itinéraire. Connaissez-vous des sites susceptibles de le
>>     faire
>>  > sur une base OSM auxquels nous pourrions signaler l'existence de
>>     cette
>>  > donnée ?
>>  >
>>  > Sébastien
>>  >
>>  > --
>>  > Sébastien Dinot, sebastien.di...@free.fr
>>     
>>  > http://sebastien.dinot.free.fr/
>>  > Ne goûtez pas au logiciel libre, 

Re: [OSM-talk-fr] Parking/aire de covoiturage : comment les tagguer ?

[marc marc]

Le 23. 10. 18 à 14:09, Francescu GAROBY a écrit :
> parking/aire de covoiturage (un parking où des covoitureurs 
> se donnent RDV, pour ensuite entre en ville dans la même voiture,  
> les autres laissant la leur toute la journée sur le parking/l'aire de 
> les covoiturages).

https://wiki.openstreetmap.org/wiki/Tag:amenity=car_pooling

à l'intérieur d'un amenity=parking dans ou à la place d'un parking 
normal selon que ce sont quelques places réservée ou tout le parking
___
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

[marc marc]

Le 22. 10. 18 à 14:43, François Lacombe a écrit :
> Sur le même sujet, j'ai supprimé environ 150 pylônes RTE qui ont été 
> démontés entre Charleville Mezieres et Reims hier soir.
> Certains avaient des points géodésiques que j'ai laissé.
> https://www.openstreetmap.org/node/669984935
> Dois-je mettre un end_date ?

si c'était un autre chose, je l'effacerais... mais un repère géodésique
je me dis que tu monde va le chercher parfois, croyant que c'est 
involontaire, alors c'est mieux de renseigner ce qui lui est arrivé.

end_date= (pour si quelqu'un veut retrouver quand il a été détruit)

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

> ou être déplacés consécutivement

je n'ai pas saisis ce que tu voulais dire.
si le repère était sur le poteau supprimé,
comment le repère pourrait avoir été simplement déplacé ?
j'ignore si l'ign compte remettre un nouveau repère proche
lorsqu'un repère est détruit, mais si c'est le cas,
j'espère qu'il n'aura pas la même ref, que ce serra un nouveau
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] migrer les amenity=swimming_pool (déprécié)

[marc marc]

J'ai changé le titre pour bien montrer que je me focalisait
sur qu'un des points du problème plus général signalé par Noémie :
changer le tag déprécié amenity=swimming_pool car c'est
le problème le + gros en taille qu'elle a identifié.

je laisse l'autre sujet pour le reste pour éviter la noyade :)

Le 20. 10. 18 à 15:24, Paul Desgranges a écrit :

> ça devient un peu compliqué de discuter du reste

Je pense que cette phrase résume aussi bien ma pensée.
Faire des étapes pour parfois 3 cas, c'est se compliquer la vie !
Je les ai corrigé, c'est plus rapide et simple.
Surtout qu'ils étaient déjà exclu du périmètre
de l'opération de masse.

> comment avais-tu compté ?

avec overpass mais de manière cumulative (tag déprécié -A -B)
c'est pour cela que le détail intermédiaire n'est pas comparable.

>  ne répondre qu'à une petite partie.

je pensais n'avoir rien d’intéressant à dire sur le reste :)
Mais si tu insistes pour avoir mon avis, l'expérience a encore
montré récemment avec maxspeed:type qu'une édition de masse
qui se disperse reste à l'état de discussion sans aboutir.
Voilà pourquoi je suis partisan d'étapes indépendantes et
ciblées plutôt qu'une méga-opération ultra imbriquée.

Mais tu es totalement libre d'être plus optimiste que moi et
de mettre en place un tel plan, obtenir l'accord unanime que
nécessite une opération de masse, le documenter et l'effectuer.

> traiter tous ces cas spéciaux
> Pas forcément à la main
> Si tu es d'accord avec ça

non, je ne suis ni candidat ni d'accord pour faire des éditions
de masses avec les 244 cas restant basée sur des suppositions
(taux d'erreur trop élevé <> temps raisonnable pour regarder
cela individuellement).
J'en ai traité quelques centaines, dans les différentes catégories,
il n'y avait jamais une conclusion binaire à en tirer.

> avant de toucher aux 7000 qui restent, il faudra aviser à nouveau

ok, j'attends que tu ai avisé :-)

Cordialement,
Marc
___
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

[marc marc]

Le 21. 10. 18 à 21:49, Alain VASSAULT a écrit :
> tu as la ref du point geodesique ou ces coordonnées?

il y les a 2, sur les 2 objets
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946

> jai l'appli "beta" librement dispo sur le google store  
> pour consulter et report sur les fiches geodesique.

Je suis curieux de voir ce que cela va donner, merci.

> Le 21 octobre 2018 21:45:43 GMT+02:00, David Crochet 
> a écrit :
> 
> J'ai envoyé un message à l'adresse ad'hoc pour signaler la disparition
> de la croix, avec photo d'un média audiovisuel  à l'appui :

Merci, voyons voir leur réaction. au moins "osm" aura transmis :)

 Message transféré 
Sujet : repère géodésique détruit
Date : Sun, 21 Oct 2018 20:29:10 +0200
De : Marc M. 
Pour : talk-fr 

Bonjour,

Un constructeur signale le démontage d'un clocher d'église qui 
hébergeait 2 repères géodésiques.
https://www.openstreetmap.org/note/1563371
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946
au niveau osm, c'est facile
was: devant le man_made=survey_point
un end_date
une maj de la description

mais je demandais :
- il y a a-t-il un outil QA qui va crier pour sa disparition ?
Si oui quel schéma supporte-t-il ?
- quelqu'un est en contact avec l'ign pour leur remonter l'info
s'ils ne l'ont pas ?

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

[OSM-talk-fr] repère géodésique détruit

[marc marc]

Bonjour,

Un constructeur signale le démontage d'un clocher d'église qui 
hébergeait 2 repères géodésiques.
https://www.openstreetmap.org/note/1563371
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946
au niveau osm, c'est facile
was: devant le man_made=survey_point
un end_date
une maj de la description

mais je demandais :
- il y a a-t-il un outil QA qui va crier pour sa disparition ?
Si oui quel schéma supporte-t-il ?
- quelqu'un est en contact avec l'ign pour leur remonter l'info
s'ils ne l'ont pas ?

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

Re: [OSM-talk-fr] Tag santé : wiki, osmose

[marc marc]

Le 20. 10. 18 à 23:05, deuzeffe a écrit :
> > D'abord, un labo. d'analyse.
> -- healthcare=doctor
> -- healthcare = laboratory

J'aurais mis le 2ieme (et corrigé l'osmecum vu qe le wiki dit déjà cela)

> -- healthcare=yes
> -- shop=optician

je ne considère pas un magasin comme un établissement de santé.
j'aurais viré healthcare
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[marc marc]

Le 18. 10. 18 à 23:55, François Lacombe a écrit :
> La 1ere pour sur le filaire river : 
> https://www.openstreetmap.org/way/34907146

c'est globalement correct https://www.openstreetmap.org/relation/1075117
même s'il y a de nombreux soucis sur la relation dont des zones
sans rôle mainstream et à l'inverse des zones avec plusieurs mainstream 
au même endroit.
J'ai corrigé une partie du tracé hier mais pas encore touché
à la relation pour éviter d'être à plusieurs dessus.

> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve : 
> https://www.openstreetmap.org/relation/660056

en plus d'être déconseillé par le wiki et inutile
c'est incorrect :
- un ensemble de polygone qui se touche ne forment un multipolygone.
un multipolygone dans osm est un ou plusieurs polygones qui ne se touche 
pas.
Le rendu osm.org avait même parlé d’arrêté de faire de la devinette
et de ne plus faire aucun rendu de certains multipolygone erronés
afin que l'erreur soie visible au lieu d'avoir des problèmes en cascade.
- Les berges du Rhône ne s'appelle pas le Rhône, il y a confusion.

> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer 
> la 2nde pour ne laisser que des polygones riverbanks continus sans 
> relation ?

oui

la page sur le wiki fr mériterait aussi d'être rafraîchie/rapprochée
avec le contenu de la version anglaise.

Et tant qu'à dire, les rôles tributary conflictuels
sont sur la mauvaise relation
https://wiki.openstreetmap.org/wiki/Relation:watershed

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

Re: [OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails

[marc marc]

Le 20. 10. 18 à 15:31, Paul Desgranges a écrit :
> je ne reçois qu'un mail sur cinq à peu près

ouvre un ticket chez la poste :)
mais vu que c'est une produit gratuit...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contributeur(e) compulsif(ve) et imprécis, faut faire quoi ?

[marc marc]

Bonjour,

Le 20. 10. 18 à 14:28, ades a écrit :
> Que fait-on quand on découvre qu’un nouveau contributeur (depuis le 23 
> septembre, 289 changesets) fait n’importe quoi ou presque.

il y a bcp de point différent dans ton email.
d'une manière générale, avec un nouveau, on peux partir du principe que 
c'est souvent involontaire et qu'il va falloir l'aider à progresser.
mettre un commentaire sur le changeset aide souvent pour quand "trop 
c'est trop". ca permet aussi de le suivre à plusieurs.

> pas de source sur l’objet

ca j'espère :) depuis le temps qu'on peux structurer l'info
sur le changeset :)

> "Corrections" des bâtiment du cadastre  (mis à jour à partir du fichier 
> etalab de juin 2018) à partir de la BDOrtho, mais là ça frole le vendalisme 
> ;-) .

je ne serrais pas si sévère. un débutant n'a pas de moyen de deviner 
qu'il y a une source cadastre plus fiable.
c'est le genre de chose qu'on devrait mettre dans l'acceuil aux nouveaux
pour lequel un coup de main n'est pas refusé :)

> Le cadastre est, certes, décalé  par rapport à l’ortho, (3px soit 60cm

un solution c'est d'alligner le cadastre et sauver/partager le décalage 
local... à voir si c'est déjà activé sur iD. Sur Josm oui.

> il faudrait  vérifier systématiquement toutes ces contributions

dans ma zone de confort je vérifie tout :)

> certaines sont intéressantes

espérons que les autres problèmes se résolvent dans ce cas.
sinon faudra demander au DWG de faire un message un peu plus 
"officiel"... et espérer là aussi que cela suffise.

> tout reprendre dès maintenant en laissant un commentaire ?

si t'as la motivation et le temps, c'est sûrement le mieux.
sinon cibler le plus "grave"

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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

Le 20. 10. 18 à 12:04, Paul Desgranges a écrit :
>>- 71 qui ont déjà un tag leisure
> on n'a pas du tout les mêmes résultats
> 62 amenity=swimming_pool and leisure=*

62 ou 71 sur 7000 c'est franchement la même chose :)
osm n'est pas statique, le fait que qlq cas ont été corrigé à la main
en 12h ne change rien fondamentalement.
et si tu fais la stat ce soir, il n'en restera plus, parce qu'au lieu
de compter par 3 fois le nombre exact, je vais les corriger,
c'est plus efficace :)

>> cela fait environ 7000 à modifier en leisure=swimming_pool.
> 2- J'enlèverais
> nommés 
> traiter individuellement)
> building
> leisure=sports_centre
> leisure=*

C'est cela (+ la taille) qui a été retiré pour arriver à 7000.

maintenant si tu préfères corriger tous ces cas à la main
avant de toucher aux 7000, pourquoi pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

résumé de la modif automatique proposée en France
en tenant compte de tous les suggestions :
7371 amenity=swimming_pool
- 71 qui ont déjà un tag leisure
- 272 avec un tag name
- 39 avec un tag building
- 18 avec une surface dams josm areasize > 2000m2

cela fait environ 7000 à modifier en leisure=swimming_pool.
pas d'objection ?

Pour le reste, je m’abstiens de le faire en automatique,
mais je donne volontiers un coup de main pour le faire
à la main, en regardant chaque objet.

Le 19. 10. 18 à 08:42, Paul Desgranges a écrit :

>      les "amenity=swimming_pool + name=*" 
>  en "leisure=sports_centre + 
> sport=swimming"

Je doute que tu puisses tirer une conclusion aussi binaire de
la présence d'un nom, j'ai déjà croisé souvent des name=piscine privée
Je pense que pour ceux là, soit on les inclus dans le groupe général 
(c'était supposé être un bassin, si c'est faux, cela reste faux)
soit c'est plus raisonnable de les charger dans josm et de faire
un contrôle humain pour mettre l'éventuel faux nom dans description
et tag d'accès plutôt que de changer le sens en centre sportif
car c'est une supposition hasardeuse.

> "amenity=swimming_pool + name!=*" 
>  en "leisure=swimming_pool"

critère "tag name" ajouté ci dessus pour l'édition de masse

> "amenity=swimming_pool + building=yes" 
>  en "leisure=sports_centre

- critère "pas de tag building" ajouté pour l'édition de masse.
- Mais convertir en centre sportir uniquement sur la base de la présence 
d'un tag building, c'est se tromper lorsqu'un bassin est couvert avec
un bâtiment en dur donc je passe mon tour pour faire cette modif là
en automatique (mais je ne suis pas vexé si quelqu'un veux faire 
autrement à ma place)
il y en a que 39 et un risque d'erreur trop élevé que pour justifier
de le faire à l'aveugle.

> Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
> les sélectionner sur ce critère de taille?

Je n'ai pas vu, Jérome parlait d'overpass
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.16.0

[marc marc]

Pour info (rendu osm.org, cela prendra du temps pour la maj des tuiles)

hasard de calendrier, icône en plus pour les centres sportif :)

 Message transféré 
Sujet : [OSM-dev] OpenStreetMap Carto release v4.16.0
Date :  Fri, 19 Oct 2018 05:44:45 +0200
De :Daniel Koć 
Pour :  osm-dev List 


Dear all,

Today, v4.16.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before all
tiles show the new rendering.

Changes include
- Changing societal amenities color to less intensive
- Adding rendering for natural=strait
- Adding rendering for leisure=track on lines
- Adding icon for amenity=vehicle_inspection
- Adding icon for leisure=sports_centre + sport=swimming and 
leisure=swimming_area
- Adding icon for tourism=gallery
- Changing color for aeroway=apron in aerodromes
- Moving amenity=post_box to z19+
- Moving amenity=atm to z19+
- Replacing icon for information=tactile_model
- Ordering amenity_lines by layer
- Small documentation and code fixes

Thanks to all the contributors for this release including dryo, a new 
contributor|.|

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.15.0...v4.16.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [OSM-talk-fr] Voting Default Language Format

[marc marc]

Je pense que le but de la propal est mal expliquée.
S'il y a un name qui est égale au name:fr, on sait déjà déduire
que le nom est en Français. et s'il y a un name=Viva Pizza name:it=Viva 
Pizza on sait déjà déduire que le nom du resto est en italien.
On sait déjà faire un rendu "priorité fr" comme celui osm-fr
ou dans une autre langage comme le montre ceux d'osm-be de bzh
La propal ne change rien pour cela.

Je trouve que le réel intérêt, c'est de dire de manière structurée :
s'il a qu'un SEUL name, En France, le plus probable c'est que
c'est du français tandis que c'est sans doute de l'allemand
en Suisse mais à nouveau du Français dans le canton de Genève.
tout en pouvoir surcharger cela si on le veux sur un poi.
Le gros avantage que je vois c'est les routages vocaux.
Il y aura un moyen d'encoder l'information nécessaire
à une prononciation plus adaptée au contexte local.

Le 19. 10. 18 à 12:52, Christian Quest a écrit :
> Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.
> 
> Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire 
> avec intelligence...
> 
> Cas du rendu FR: si default:language=fr, je prends les name, sinon je 
> prends les name:fr
> 
> Du coup, on aura bien le "name" sur le territoire français, même si il 
> n'est pas en français mais occitan ce qui est au final l'objectif 
> recherché, non ?
> 
> Pour savoir véritablement dans quelle langue est name=*, il faut le 
> comparer aux différents name:xx=* , il n'y a finalement que ça de fiable 
> si c'est cette info qu'on veut obtenir.
> 
> 
> Le ven. 19 oct. 2018 à 12:28, Rpnpif  > a écrit :
> 
> Le 19 octobre 2018, rainerU a écrit :
> 
>  > Bonjour,
>  >
>  > Je me pose des questions sur l'impact de cette proposition sur
> les objets qui
>  > ont un nom officiel en langue régionale :
>  >
>  >
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>  >
>  > Si j'ai bien compris la proposition, on mettrait
> default:language=fr sur la
>  > frontière de la France (ou des régions, départements,...) et les
> applications
>  > utiliseraient name=fr comme nom standard.
>  >
>  > A mon avis, cela pose un problème dans les cas où le nom officiel
> d'un objet est
>  > en langue régionale mais existe aussi un nom en français. Il y a
> eu un fil de
>  > discussion sur cette liste sur la manière de tagguer ces cas avec
> le schéma
>  > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je
> taggue name=  > officiel>, name:ca=, name:fr=. Avec le
> schéma
>  > proposé, un rendu en langue standard afficherait le nom français
> et pas le nom
>  > officiel en catalan. Si par contre on mettait name:fr= catalan>, on ne
>  > pourrait plus créer un rendu 100% français.
>  >
>  > Est-ce que cette question a déjà été discuté ici ou ailleurs, si
> oui quelle
>  > était la conclusion ?
> 
> Bonjour,
> Oui je suis d'accord avec toi : ce n'est pas une proposition
> pertinente.
> 
> -- 
> Alain Rpnpif
> 
> ___
> Talk-fr mailing list
> 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] édition mécanique : nettoyage is_in:continent

[marc marc]

Bonsoir,

Personne ne s'y étant opposé,
j'ai terminé de nettoyer la 100aine de cas qui restait encore en France.
Je me suis juste abstenu pour le moment sur la relation de la rivière la 
Meuse qui même si elle a un peu + de km en France est quasi bi-nationale
et donc je verrai cela un peu + tard pour ne froisser personne.

Je proposerai de descendre un niveau dans le nettoyage is_in
un peu + tard et dans un sujet séparé.

En espérant que cela fasse des émules dans d'autres communautés...
Je vais d'ailleurs aller en pèlerinage osm de l'autre côté de la 
frontière :)

Cordialement,
Marc
 Message transféré 
Sujet : édition mécanique : nettoyage is_in:continent
Date : Wed, 8 Aug 2018 01:40:32 +0200
De : Marc M. 
Pour : talk-fr 

Bonsoir,

une discussion a lieu ces derniers jours à propos des continents.
ceux-ci, hormis l’antarctique, sont pour le moment représenté par un 
nœud car l'étendue de ceux-ci sont imprécis et parfois conflictuel 
(parle-t-on d’Europe donc d'un continent politique ? si oui quel est
sa limite vers l'est ou de plaque tectonique et donc d’Eurasie ?)
bref le débat est en cours... et j'ai pas la prétention d'apporter 
quelques choses à celui-ci tant les positions sont éloignées.

par contre, pour contourner ce manque d'étendue géographique,
il existe le tag is_in:continent.
cela permet de renseigner qu'un pays ou une partie de celui-ci
est dans tel continent
cependant ce tag pour une raison inconnue se retrouve un peu n'importe 
où, il y a par exemple environ 350x ce tag en France continentale
alors qu'il est suffisant d'en avoir un seul sur la relation.

Mon message a donc pour but d'informer mon intention de procéder
un nettoyage en France continentale et donc de discuter de celui-ci 
avant de le faire comme il se doit :)

PS: c'est quasi toute la variété des is_in qui faudrait nettoyer.
Mais pour d'autre tag, ce serra moins trivial, alors je préfère
y aller par petite étape rapide à discuter et à faire.

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

Re: [OSM-talk-fr] Chantier sur les Champs, one way

[marc marc]

Oui c'est une bonne chose (tant la maj du au travaux que la fusion
des 2 groupes de bande)
mais il y aura bien un puriste pire que moi pour dire (ou refaire) qu'il 
faut 2 bandes vu l'obstacle entre les bandes à chaque passage piéton.
Même si techniquement c'est exact qu'il y a une coupure de routing à cet 
endroit là, je trouve que c'est excessif (ultra micro mapping)... mais 
comme c'est pas faux, dur de faire un revert sur cela...
et avoir une alternance de 1 et 2 way est techniquement juste mais 
horrible pour le rendu (même si on tag pas pour le rendu, faut quand 
même pas pousser un rendu horrible pour un ultra micro mapping)

ceci dit faudrait juste attendre que les nouvelles bandes en travaux 
soient une réalité

pour les itinéraires de bus, fusionner les 2 way pour ensuite supprimer 
les nœuds d'un des 2 ways est un moyen facile pour que les itinéraires 
de lignes de bus se mettent à jour sans effort (un bon plan est de 
résoudre leur éventuel anomalies avant de démarrer le gros chantier)

Le 17. 10. 18 à 22:05, Thomas Ruchin a écrit :
> Bonsoir
> 
> Dans l'absolu, pas d’objection puisque c'est effectivement une unique 
> chaussée avec des refuges piétons qui sont démontés à chaque défilé 
> militaire.
> Mais la manipulation n'est pas aussi simple à effectuer qu'il n'en 
> paraît, notamment en ce qui concerne la conservation des relations 
> (lignes de bus,..).
> Et puisqu'on en parle, les files de circulation générale passeront de 4 
> à 3 dans chaque sens. La bande technique (taxis, livraisons, etc) dans 
> la partie haute ou le couloir de bus dans la partie basse des Champs 
> prennent déjà une une file.
> 
> Thomas
> 
> Le mer. 17 oct. 2018 à 13:43, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a 
> écrit :
> 
> Bonjour,
> 
> Aujourd'hui les Champs Élysée (Paris, France :) est cartographié par
> deux highway=primary.
> Ce qui est pour moi une erreur, l'avenue est certes large, mais
> aucune délimitation physique ne sépare les deux sens de circulation.
> 
> En ce moment se déroule un chantier visant la création de pistes
> cyclables latérale séparé de la chaussée motorisé par un espace de
> stationnement, livraison, taxis, arrêt de bus.
> Les voies motorisés vont passer de 5 voies à 3 dans chaque sens.
> Pour une idée, voici une vue d'artiste :
> 
> https://www.cnews.fr/france/2018-10-07/paris-les-travaux-de-la-piste-cyclable-des-champs-elysees-vont-debuter-796190
> 
> D'où mon idée d'en profiter pour passer les voies motorisés en un
> seul segment.
> Je demande pour m'éviter les cris d'orfraie d'avoir osé touché à la
> plus "belle avenue du monde".
> 
> -- 
> 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
> 

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

[OSM-talk-fr] accueil des nouveaux : la suite

[marc marc]

Bonjour,

suites aux messages précédents de deuzeffe, Noémie et moi-même,
"on" a décidé d'avancer. il y a donc eu :

- plusieurs appels aux bonnes volontés sur le sujet,
c'est comme ca qu'on arrive à un gros groupe de 3 personnes :)
c'est jamais trop tard pour embarquer dans l’aventure, donner
votre avis, etc

- faire un message d’accueil plus conséquent que l'actuel.
on s'est basé en parti sur celui de la communauté suisse (merci
Simon pour le partage) que deuzeffe principalement a complété
en pointant des ressources du wiki.
On en a parlé longuement sur irc, Noémie dit à juste titre que
c'est sans doute un peu long, les idées sont bienvenue pour alléger
https://wiki.openstreetmap.org/wiki/FR:WikiProject_France/bienvenue

- le tester. on pensait faire cela à la main
sur irc, osmbot annonce les nouveaux. ceux qui veulent écrivent
un message avec le lien vers le wiki. c'est l'occasion aussi
pour ceux qui veulent de donner un avis sur le premier changeset
c'est aussi possible d'utiliser les outils de Pascal Neis ou
n'importe quel outil qui a votre préférence.
histoire de voir qui a reçu le message pendant cette phase,
on le mettra sur le premier changeset. mais libre à chacun
de l'envoyer par message privé si vous êtes timide :)

A venir :
- tenir compte d'éventuelle réaction à cette nouvelle version.
- de nombreuses pages axés débutant sur le wiki nécessite un 
rafraîchissement
- voir si on adapterait pas le message à l'éditeur.
quelqu'un utilisant iD vers le tutoriel iD
quelqu'un utilisant josm vers un doc axée tags
quelqu'un utilisant maps.me... ha bon non ils ne répondent quasi jamais.
- automatiser l'envoi
pour détecter les nouveaux, on peux se baser sur osmbot, utiliser
le rss de Pascal Neis ou parser nous-même les diff.
pour l'envoi, il n'y a pas d'api, faut donc crawler (en français ?)
les pages osm.org pour y parvenir (la communauté belge et suisse
fait l'envoi du message à la main... mais vu le volume et le manque
de bras, automatiser ne serrait pas du luxe si qlq a envie de le coder)

Critiques (constructives), bonnes volontés et pizza bienvenus :)

Cordialement,
Marc
___
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

[marc marc]

Le 17. 10. 18 à 12:28, Florimond Berthoux a écrit :
> on a quand un gros problème à Paris avec ça

quel est le problème avec le résultat de la discussion précédente ?

> Nouvelle proposition :
> amenity=bicycle_parking;motorcycle_parking
> Qu'en pensez-vous ?

supporté par 0% des apps et rendu actuellement
comme je sais pas ce que tu essayes de résoudre,
j'ai pas de solution autre que ce qui a déjà été dit :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] représentation 3d des olympiades

[marc marc]

Je vois pas comment tu peux dire que la dalle est 2 niveaux + que la rue
hormis le tag ele, on a rien dans osm qui permet de lier des hauteurs 
respective comme dire que tel route est 10m au dessus de tel autre.

les tag de la date devraient migrer du way outer qui définit son contour
à la relation qui définit son étendue sans les bâtiments
https://www.openstreetmap.org/way/79084943
https://www.openstreetmap.org/relation/2724004
et sans doute type=multipolygon + highway=pedestrian + surface (béton ?)

Le 17. 10. 18 à 10:07, Nicolas Bétheuil a écrit :
> C'est beaucoup mieux
> http://demo.f4map.com/#lat=48.8249258=2.3659648=18
> https://osmbuildings.org/?lat=48.82621=2.36447=17.4=45=-5
> 
> effectivement peux mieux faire pour dire que la dalle est en hauteur
> 
> @althio le way est celui que j'ai corrigé mais effectivement, me demande 
> pour supprimer le way et laisser la relation. sa forme est plus proche 
> de ce que l'on peut appeler la dalle des olympiades.
> 
> M’embête de remettre le nombre d'étage à 2 parce que du coup faut 
> modifier chaque échoppe pour la monter de 2 étages, pour toujours les voir.
> 
> 
> Le mar. 16 oct. 2018 à 09:51, althio  > a écrit :
> 
> La dalle en tant que voirie, aire de cheminement existe déjà :
> https://www.openstreetmap.org/relation/3283058
> 
> Ce way https://www.openstreetmap.org/way/79084943 :
> C'est peut-être plutôt le bâtiment sous la dalle.
> (donc peut-être remettre building=yes ? le bon nombre d'étages ? 2 ?
> enlever le tag "name" ?... ???)
> 
> 
> On Mon, 15 Oct 2018 at 20:31, Nicolas Bétheuil  > wrote:
> 
> Du coup j'ai plutôt utilisé area=yes & pedestrian=yes et j'ai
> enlevé le fait que c'était un immeuble
> https://www.openstreetmap.org/changeset/63551936
> 
> 
> Le lun. 15 oct. 2018 à 18:15, Philippe Verdy  > a écrit :
> 
> N'est-ce pas le même problème sur d'autres "dalles" comme
> celle de la Défense à Courbevoie, ou la dalle du Colombier à
> Rennes ? Et le même problème dans toutes les villes
> construites sur des reliefs escarpés (comme Monaco), où il
> est difficile de dire quel est le niveau du "sol" pour un
> étage donné qui peut être sous-terrain ou en hauteur d'un
> autre côté avec d'autres niveaux intercalaires?
> 
> La notion de "niveau" (ou "étage") se gère à priori bâtiment
> par bâtiment, pourtant on trouve des cas où deux batiments
> contruits sur des sols différents ont des passages accolés
> au même niveau (on passe san monter ou descendre du rez-de
> chaussée de l'un au 3e étage de l'autre) et on en trouve
> même dans des villes réputées "plates" comme Paris (les
> "grands magasins") ou Lille (par exemple sa fameuse grande
> librairie) qui ont aussi réunit des niveaux différents de
> plusieurs bâtiments accolés (ou assez proches pour installer
> des passerelles).
> 
> Dans certains cas, au sein de ces batiments, la notion de
> "niveau" n'est pas la même entre les surfaces occupées par
> un même magasin ou une même entreprise, que celle d'étage au
> sein des batiments dans lesquels ces locaux sont situés.
> 
> On a le cas aussi avec les stations souterraines de train ou
> métro, où la notion de niveau n'est pas beaucoup plus simple
> (le même niveau peut pourtant avoir des altitudes de
> plancher variables, avec des pentes douces ou quelques
> marches ignorées et sur une longueur assez grande cela fait
> vite une différence).
> 
> Le tag "layer=n" d'OSM ne donne qu'une relation d'ordre
> relatif entre des éléments superposés à la même position
> géographique (longitude et latitude), le tag "level=n" dans
> un batiment peut ne pas suffire non plus, et il est
> difficile de taguer précisément tous les points avec une
> véritable altitude, à moins de décider de ne plus taguer ça
> dans OSM
> 
> Mais on peut le faire avec un véritable modèle 3D (hors
> d'OSM lui-même) pour l'ensemble d'un édifice, qu'on
> géolocalisera ensuite sur un seul point (avec aussi son
> orientation correcte) ; et alors dans OMS on se contentera
> de tracer la seule empreinte au sol, quel que soit son
> altitude. Mais il manquera alors dans OSM les "ways" de
> communication (on mes ajoute de façon approximative sans
> tenir compte de l'altitude, mais en les ordonnant avec
> "layer=n", le reste est trop difficile à modéliser avec le
> modèle 2D d'OSM qui n'est pas conçu pour gérer correctement

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[marc marc]

Le 16 octobre 2018, Christian Quest a écrit :
>> Un petit bémol sur Paris pour le 16ème arrondissement, qui a 2 codes
>> postaux (75016 et 75116) mais la zone du 75116 existent déjà pour ce cas
>> particulier (en boundary=postal_code bien sûr):
>> https://www.openstreetmap.org/relation/4548229

Christian je suis ultra positivement surpris que tu ai créé une aire 
pour une info postale :)

Le 16. 10. 18 à 14:40, Rpnpif a écrit :
> J'ai vu un tag : addr:postcode=49220;49370. Est-ce que cette syntaxe
> avec le ";" est autorisée ?

je trouve cela incorrect car ; veux dire ET
je comprend bien l'idée de dire qu'il y a plusieurs CP dans cette 
commune mais les adresses dans cette zone n'ont pas plusieurs CP.
chaque adresse a un CP OU l'autre CP.
ce serrait comme mettre name=ancienne-commune1;ancienne-commune2
sur une commune fusionnée :( c'est pas le cas on met name=un nom
parce qu'il n'y a qu'un nom qui s'applique à cet objet.

> Si je comprend bien il faut créer une autre frontière boundary.

oui, c'est une solution

> Mais que met-on dans le boundary du niveau 8 ?

t'as le choix pour ces 1879 communes multi-CP (si j'ai bien
traité l'od de la poste)
- tu crées 2 boundary=postal_code et tu ne met rien au niveau
de la commune, c'est le moins ambigu mais en même temps comme
tu dis il y a "la peur du vide, vite vite faut tout dupliquer".
- tu crées une boundary=postal_code avec la première valeur
et tu met l'autre valeur dans la commune (de préférence la + utilisée.
les adresses dans la boundary=postal_code vont hériter de ce CP là
ceux qui sont dans la commune hors de la boundary=postal_code vont 
hériter du CP mis sur la commune.

je suis pas loin de penser qu'il faudra une note sur la commune pour 
signaler l’existence d'une sous-région CP pour éviter les ping-pong
du genre "non il y a 2 CP"... mais je trouve dommage de devoir faire
des notes pour pointer ce qui existe avec des tags corrects.
Ou à défaut faudra communiquer...
je pense que je vais mettre l'url du wiki dans les tag du changeset, 
cela aidera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

Le 16. 10. 18 à 09:33, Christian Quest a écrit :
> https://2.bp.blogspot.com/-mhCVrMV3K-8/UX2VXYXJUgI/A0g/fwvAWxZV4rI/s1600/Nangis_2.jpg

joli !
c'est un toit rétractable ?

Le mar. 16 oct. 2018 à 09:17, Paul Desgranges a écrit :
>      1. le bassin peut être à l'intérieur ou à l'extérieur
>      - bassin intérieur => "location=indoor"
>      - bassin extérieur => "location=outdoor"
>     2. le bassin peut être "couvert" ou pas.
>      - "couverte" au sens la piscine dispose d'un "abri piscine" (on
> distingue bien ces abris en photographie aérienne), les piscines
> privées dans les jardins, avec un abri pour : sécurité chute,
> déperdition d'énergie, feuilles mortes, etc.
>    Alors comment documenter ces 2 attributs
> ("location=indoor/outdoor" et "covered=yes/no") pour que l'usage en
> soit clair ?

tes 2 phrases ci-dessus me semble parfaitement clair, peut-être 
suffit-il de les ajouter sur la page wiki :)

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

Re: [OSM-talk-fr] openinframap

[marc marc]

tu le connais mieux que moi mais j'espère qu'il n'est pas contre
un PR et qu'il a au moins le temps de regarder/merger les PR.
sinon il y a le fork :) au moins pour faciliter la "vue"
des contributeurs sur le sujet

Le 15. 10. 18 à 23:44, François Lacombe a écrit :
> Je confirme.
> 
> Il faut voir sur le github, il y a quelques issues en suspend.
> Ca devrait être traité d'ici la fin de l'année, mais Russ n'a pas 
> toujours le temps
> 
> Si seulement on pouvait être plusieurs à l'admin :)
> 
> *François Lacombe*
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com <http://www.infos-reseaux.com>
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
> 
> 
> Le lun. 15 oct. 2018 à 22:53, Vincent Privat  <mailto:vincent.pri...@gmail.com>> a écrit :
> 
> Du coup je sais pas si c'est judicieux le label "Substation 20kv"
> pour tous les postes sans nom. La carte au zoom 13 est saturée
> maintenant :D
> 
> Le lun. 15 oct. 2018 à 21:27, Laurent Combe  <mailto:laurent.co...@free.fr>> a écrit :
> 
> cool
> 
> Le ven. 12 oct. 2018 à 13:39, François Lacombe
> mailto:fl.infosrese...@gmail.com>> a
> écrit :
> 
> Bonjour
> 
> Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
> Les mises a jour ont été faites.
> 
> François
> 
> Le sam. 1 sept. 2018 à 12:23, François Lacombe
>  <mailto:fl.infosrese...@gmail.com>> a écrit :
> 
> Bonjour
> 
> A noter que russs n'intervient sur openinframap qu'entre
> Noel et le nouvel an habituellement
> 
> J'ai bien proposé de l'aider dans sa tache mais sans
> réponse. Il y a pourtant beaucoup à faire
> 
> Bonne journée
> 
> François
> 
> Le sam. 1 sept. 2018 à 10:26, marc marc
>  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Bonjour,
> 
> info de Gazer75 (qui ne parle pas français) sur irc :
> I think it has stopped due to a problem,
> but ru is quite busy atm.
> 
> en français : il y a un problème :-)
> mais "russs", le gars qui s'en occupe, est débordé
> pour le moment.
> Le mieux est de prendre contact directement avec lui
> ou chercher s'ils
> ont un système de ticket pour être au courant des
> changements.
> 
> Cordialement,
> Marc
> 
> Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
>  > petit up gentil
>  > le problème de rafraichissement semble toujours
> présent
>  >
>  > Le mer. 22 août 2018 à 21:34, François Lacombe
>  >  <mailto:fl.infosrese...@gmail.com>
> <mailto:fl.infosrese...@gmail.com
> <mailto:fl.infosrese...@gmail.com>>> a écrit :
>  >
>  >     Bonsoir,
>  >
>  >     Relativement à ce problème, il semble
> toujours présent dans la zone
>  >
> https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
>  >
>  >     Il y a comme une espèce de ligne au nord de
> laquelle rien ne passe.
>  >     Surement un problème de mise à jour
>  >     A voir si les admins consentent à recharger
> la base
>  >
>  >     François
>  >
>  >     Le lun. 20 août 2018 à 08:48, François Lacombe
>  >      <mailto:fl.infosrese...@gmail.com>
> <mailto:fl.infosrese...@gmail.com
> <mailto:fl.infosrese...@gmail.com>>> a écrit :
>  >
>  >         Bonjour Laurent
>  >
>  >         En effet, on dirait qu'il y a une ligne
> horizontale au nord de
>  >         laquelle il n'y a pa

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[marc marc]

Le 15. 10. 18 à 23:11, Ralf Treinen a écrit :
> On Mon, Oct 15, 2018 at 08:08:18PM +0000, marc marc wrote:
>> Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :
>>
>>> Le wiki semble indiquer que c'est postal_code [1].
>>
>> oui. postal_code pour définir le code postal d'une étendue
>> par opposition à addr:postcode pour définir le code postal
>> d'une addr en particulier.
> 
> Merci pour cette confirmation. Et on est bien d'accord que quand
> le postal_code est renseigné pour une étendu avec admin_level=9
> (les arrondissements de Paris) qu'il n'est pas utile de le
> repeter sur les quartiers (adminlevel=10) inclus dans cet arrondissement ?

pour moi c'est (tjs?) inutile de répéter 2 fois la même chose :)
donc si c'est sur admin_level=9, pas besoin de le remettre sur les 
niveau 10 ni sur tous objet inférieur (genre les bâtiments)
ils vont tous hériter de l'info du niveau supérieur (comme on le fait 
pour les communes par ex).
on gagnerait bcp en lisibilité pour trouver les endroits oü il manque 
l'info... parce que pour l'instant il faut d'abord se farcir une logique 
éliminatoire/corrective pour prétraiter les données :(
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[marc marc]

Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :

> Le wiki semble indiquer que c'est postal_code [1].

oui. postal_code pour définir le code postal d'une étendue
par opposition à addr:postcode pour définir le code postal
d'une addr en particulier.

> en région Parisienne je trouve addr:postcode utilisé

c'est une erreur très fréquente en France :-(

> JOSM n'est pas d'accord avec cette combinaison :
>suspicious tag combination - boundary together with addr:*

osmose non plus de mémoire :)

> Faut-il remplacer tout les addr:postcode par postal_code dans les
> limites des communes ou arrondissements ?

oui... et convaincre ceux qui ont déjà fait des opérations inverses
de le cesser.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Décalage cadastre

[marc marc]

Le 15. 10. 18 à 21:17, Valentin GAUTREAU a écrit :
> Je suis face à un dilemme pour plusieurs communes et particulièrement 
> sur Montfaucon-Montigné (49). Le cadastre est complètement décalé par 
> rapport à la réalité (c'est à dire les cartes IGN et la BD Ortho IGN). 
> Comment faire ? Il faut décaler les bâtiments car ils chevauchent les 
> routes ou laisser comme tel avec plusieurs mètres de différence.

il y a plusieurs "visions", selon la précision et le côté pratique :

l'idéal c'est de trouver un man_made=survey_point de l'ign, de vérifier 
dans son historique s'il n'a pas été bougé et d'aligner le tout dessus.
c'est "la vérité" normalement en matière de coordonnées.

Le plus commode c'est de s'aligner sur le cadastre tant que t'as pas 
finit d'importer les bâtiments.
Une fois les bâtiments finit, il faut s'aligner sur l'un, sur l'autre 
selon ce qui te semble le moins mauvais (sans avoir regardé ce cas là, 
j'aurais tendance à choisir la bdortho)

à plus long terme, si tu trouves pas de repère géodésique et si
c'est proche de chez toi, il faut x jours différents une trace gps
d'un élément très reconnaissable (ex une route avec angle à 90°
histoire d'ensuite faire la moyenne des différentes traces
(visuellement ou via stravia par ex) et caler le cadastre et/ou
la bdortho sur cette moyenne (on peux partager/sauver le décalage
avec josm)
et ensuite faut réaligner le tout... et cela c'est bcp moins marrant

> Par ailleurs, peut-on informer les mairies de ces erreurs ?

ho tu peux... mais met un cierge à Marie en même temps...
L'administration est trop souvent peu réceptive/réactive
aux remontées d'erreur... mais fait tenter... mais uniquement
après que tu ai identifié si c'est bien le cadastre qui est
réellement décalé ou pas...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] représentation 3d des olympiades

[marc marc]

Le 15. 10. 18 à 13:58, Nicolas Bétheuil a écrit :
> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
> 
> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle 
> faisait 20 étages et du coup les commerces présents sur la dalle sont 
> juste invisible.

je connais pas vraiment le lieu
mais je ne qualifierais pas la date de bâtiment
https://www.openstreetmap.org/way/79084943
mais je ne sais pas comment je la qualifierais mieux :)
si j'ai bien décodé, c'est un parking souterrain
avec une "square" principalement bétonné au dessus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

Bonsoir,


Le 13/10/2018 à 21:46, Noémie Lehuby a écrit :
> Je partage ta compréhension de la page de wiki, le 
> leisure=swimming_pool est bien une partie (qui peut-être  
> cartographiée ou pas) du leisure=sports_centre.
>
> Par contre, j'ai l'impression que le amenity=swimming_pool était ambigu.
> Tu voudrais les modifier massivement vers swimming_pool ou vers 
> sports_centre ?

de ma lecture du wiki c'est vers swimming_pool
Si on veux raffiner, il faudrait détecter les amenity=swimming_pool 
proche d'un leisure=swimming_pool et les traiter à la main...
s'il y a du monde motivé par la thématique...
sinon ce qui était faux, restera faux, au moins le reste serra corrigé.

Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
> Un truc en plus, le terme 'piscine' de manière générale peut signifier à 
> la fois le bassin, le bâtiment, mais aussi le complexe sportif :
>   - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
> "leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment 
> piscine'  (le bassin est alors parfois à l'extérieur)

cette interprétation me semble erronée.
leisure=swimming_pool est selon moi clairement définit comme étant
le bassin.
leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
plusieurs fois devant en me demandant si c'était un garage entière vitré 
ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
entièrement constitué d'un bassin d'eau (piscine privé).
si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.

>   - "leisure=sports_centre" + "sport=swimming" : ça serait bien le 
> complexe sportif de type 'piscine', qui peut contenir des bâtiments 
> (avec ou pas des bassins), et aussi (ou pas) des bassins extérieurs, et 
> aussi (ou pas) de la pelouse etc. ...  (on a souvent le cas : 

ca je suis d'accord.

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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

Le 13. 10. 18 à 16:22, Paul Desgranges a écrit :
(a propos de) covered=yes/no
> pourquoi ne pas utiliser plus systématiquement location=indoor/outdoor

c'est 2 choses différentes.
tu peux avoir un bassin extérieur couvert ou non.
Mais cela gagnerait sans doute d'être mieux documenté.

> Le 10/10/2018 à 21:57, Noémie Lehuby a écrit :
>>   * j'ai beaucoup de leisure=swimming_pool
>>   * pas beaucoup de leisure=sports_centre + sport=swimming

je pensais que l'un (la page anglaise et française de 
leisure=swimming_pool disent que c'est pour le bassin lui-même)
était une partie de l'autre (leisure=sports_centre le complexe contenant 
un ou plusieurs bassins tous ou en partie destiné à la natation)

>> * quelques amenity = swimming_pool, pourtant déprécié

8000 en France... on pourrait facilement les convertir en masse
je veux bien m'en charger si tout le monde est d'accord sur le principe.
ou si quelqu'un veux faire autrement, cela me va aussi :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[marc marc]

Bonjour,

Le 12. 10. 18 à 11:24, Charles MILLET a écrit :
> Pour résumer tu n'est pas pour parce que tu n'est déjà 
> pas pour le route_ref ?

oui en résumé c'est exactement cela. je suis contre subtitution:lines 
permanent parce que je suis contre l'utilisation permanente de route_ref

Si c'est un tag temporaire comme un étape intermédiaire renseignant
les informations destiné à la création des relations, c'est utile
mais autant garder la même logique et créer subtitution:route_ref
Et je passerai à la relation même imparfaite dès que possible.

> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
> [route_ref=* can easily be added to individual bus stops without knowing 
> the whole route a service takes. It can serve as a basis to add the full 
> route relation LATER on]

je partage cet avis :
route_ref est utile quand il est utilisé temporairement "je suis passé 
devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter 
PLUTARD à la relation par ex avec un outil + adapté", c'est donc
à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
(même si je trouve qu'utiliser une clef spécifique pour une note/fixme 
dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à 
requêter" et si chaque catégorie de donnée utilisait une clef 
différente, ce serrait pas génial)

mais quand il est permanent, c'est une donnée dupliquée avec la galère 
que cela implique à chaque fois qu'il y a une différence entre les 2 :
si un utilisateur vire route_ref sans virer l'arrêt de la relation,
cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut
virer de la relation ? ou cela signifie-t-il qu'il a juste viré
une clef qu'il trouve inutile ?
Idem quand route_ref est présent mais différent des relations,
pour en avoir corrigé un bon paquet, quelle perte de temps à faire
une 2ieme fois les modifs en devinant le sens de la désynchro.
J'ai croisé des désynchro qui avait des années... c'est un peu
comme les notes non traitée, on a l'info mais faut quelqu'un
repasse une 2ieme fois pour que cela deviennent utilisable.

> on est pas mal dans cette situation au final sauf qu'au lieu 
> d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter 
> cette clé, on propose d'utiliser : substitution=yes + 
> subtitution:lines=* qui ont une vocation plus temporaire 
> (1 an, 2 ans ?).

en temporaire oui pourquoi pas.
dans cette optique, autant aller jusqu'au bout avec 
subtitution:route_ref qui dit clairement que cela a pour but
à terme d'être ajouté dans une relation de substitution.
mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"
hors on va le mettre dans le wiki comme façon de tager un arrêt
de substitution
puis il y aura la tentation de faire un umap
ou n'importe quoi d'autre pour montrer l'avancement..
et du coup le temporaire devient permanent...
Tu parles de 2 ans...
pq pas faire une relation imparfaite ? une relation ligne de bus
qui contient juste les quelques arrêts identifié dans le mois,
ce n'est pas complet mais c'est utilisable, un tag wiki sur
la relation vers la page qui explique l'expérimentation,
il serra toujours temps + tard d'affiner.
Mais je comprend/partage l'avis que la relation n'est pas
la priorité quand vous en êtes à l'étape d'identifier les arrêts.

> Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile 
> de la rejeter, perdre son utilité juste pour gagner en "pureté" 
> de la données ?

Le problème principal ce n'est pas la pureté.
C'est le fait qu'avoir les données de 2 manières différentes implique 
que par erreur ou par méconnaissance, certains contributeurs vont 
modifié l'un, d'autre vont modifier l'autre et tu finis par avoir
des données de moindre qualité que si tu as une seule manière
de le renseigner.
Idem pour l'utilisation des données : certains vont utiliser l'un
parce que + présent au début, d'autre vont utiliser l'autre...
et donc les outils n'auront qu'une vision partielle des données,
sauf à devoir se farcir les 2 manières et donc le temporaire
devient "durable".

> Bon voilà, j'oserai plus utiliser des notes ;)
:) à bon escient :)

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

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[marc marc]

Le 12. 10. 18 à 11:15, Charles MILLET a écrit :
> Le choix des way multiple est déjà celui recommandé ! (cf. T1 
> https://wiki.openstreetmap.org/wiki/Bicycle)
> 
> Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est 
> pas quelque chose qui a été introduit de manière cavalière mais on va 
> pas faire la même chose non plus dans l'autre sens.
> 
Le 12. 10. 18 à 10:34, Charles MILLET a écrit :
> Quelqu'un peut me dire où il est question de l'avis international en 
> faveur de "cycleway=track" ?
il n'existe pas un unique lieu d'avis international,
il y a :
- le wiki (tant la pagecycliste que la page qui explique
qu'on fait 2 way lorsqu'il y a un obstacle entre les 2)
- la mailling tagging
- et même s'il veux pas l'entendre, la communauté locale est un avis à 
prendre en compte. on devrait s'uniformer au niveau mondial mais c'est 
pas une raison pour ne pas tenir compte du local.
au lieu d'essayer de deviner ce qu'il prend comme source,
le mieux serrait de lui demander ou de lui montrer que sur la page des 
cyclistes avec le cas T1 dit clairement que plusieurs ways sont recommandé,
l'utilisation d'un seul way étant une version simplifiée quand on n'a 
pas tous les éléments" ou quand on veux faire "un premier jet simplifié 
qu'on raffinera + tard

> sens, puisqu'on a déjà du mal à définir des règles claire pour choisir 
> entre un way propre et un tag sur la chaussée, on va encore créer du 
> flou sur le sujet.
pourtant même moi le grand partisan d'un non excès des way séparé,
je trouve qu'il se trompe. mais ce n'est pas un avis international :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[marc marc]

Le 11. 10. 18 à 17:05, Charles MILLET a écrit :
> Nous pensons utiliser quelque chose comme ça
> substitution=yes

sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
en particulier, c'est un arrêt de bus, y dupliquer l'information
de tous les type de lignes pouvant éventuellement l'utiliser ne semble
à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque 
changement, il faut veiller à dupliquer le changement pour garder
la cohérence, faire une analyse osmose ou autre pour surveiller
les inévitables désynchronisation entre les 2 et avoir quelqu'un
qui passe du temps à resynchroniser les données).
Je pense que l'utilisation des données du type de ligne qui passe
à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
Mais je sais qu'on a au moins 2 champions de la duplication dans
la communauté qui ne manqueront pas de faire valoir l'inverse :-)

> subtitution:lines=RER C

pour les relations représentant les lignes,
Une possibilité serrait d'avoir exactement le même nom
et donc j'aurais plutôt vu quelque chose genre
name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
le nom, le from, le to, la ref et la branche...)
substitution=only (la ligne n'existe que quand l'autre est en panne)
substitution:of=train (elle remplace une relation train)
et éventuellement sur la relation du RER C:
substitution:by=bus
en ajoutant l'itinéraire de substitution dans la relation route_master
on pourrait sans doute faciliter une utilisation futur + poussée.
le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus 
fils d'une relation route_master=train
ce serrait sans doute utile d'en discuter sur tagging
avec une exemple de relation bus comparable à la relation rer
histoire de rendre la chose compréhensible pour ceux qui n'ont
rien de semblable chez eux.
c'est sans doute un peu prématuré si pour le moment vous en êtes
aux arrêts de bus eux-même.

> Ces tag pourrons être complétés par une note au besoin.

les notes peuvent être utile pendant l'expérience sur la première 
relation mais à long terme, des outils/contributeurs considèrent
la note comme étant souvent le signe que c'est pas stable d’où
le besoin de transmettre une information et qu'il faut donc
un éventuel coup de main pour transformer la note en tag + adapté.
url=la page wiki sur le changeset serrait très utile pour le 
contributeur qui veux en savoir plus sur le projet.

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

Re: [OSM-talk-fr] Représentation et tag des bas-cotés

[marc marc]

Le 11. 10. 18 à 11:37, ades a écrit :
> Y-a-t-il une « doctrine » pour la représentation des bas-cotés des routes et 
> des chemin ? faut-il les dessiner ? et quels tags ?

il y a 2 schémas area:highway=valeur de la highway et landuse=highway

> y-a-t-il une taille limite

le problème c'est surtout la maintenance. il faut déjà que la zone soie 
bien détaillée pour que cela ai du sens de faire du micro-mapping, 
hormis évidement la liberté à chacun de choisir comment il contribue.
les tag lanes et width me semble par exemple plus susceptible d'être 
utilisé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de limites de vitesse à l'aveugle

[marc marc]

Bonjour,

Le 11. 10. 18 à 11:01, pepilepi...@ovh.fr a écrit :
> Le 11/10/2018 à 10:53, marc marc a écrit :
>> Le 10. 10. 18 à 22:08, Sébastien Dinot a écrit :
>>> Avez-vous une idée pour remédier à ce problème de manière efficace
>>> et un peu plus subtile ?
>> faire un revert "à l'aveugle" de l'ensemble de ces doubles changements
>> de vitesse puis aller voir sur le terrain la réalité
> Juste pour ma culture : n'importe quel contributeur peut faire un revert
> d'un changeset de n'importe quel autre contributeur ?

oui, c'est une modification comme une autre qui a comme source l'état de 
l'objet avant la modif que tu veux annulée.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de limites de vitesse à l'aveugle

[marc marc]

Le 10. 10. 18 à 22:08, Sébastien Dinot a écrit :
> Avez-vous une idée pour remédier à ce problème de manière efficace 
> et un peu plus subtile ?

faire un revert "à l'aveugle" de l'ensemble de ces doubles changements 
de vitesse puis aller voir sur le terrain la réalité
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Status de la BANO

[marc marc]

Le 09. 10. 18 à 14:28, deuzeffe a écrit :
> j'intègre les points d'adresse dans la ligne du polygone, au niveau de 
> l'entrée

c'est l'une des 2 très bonne option qui permet justement d'atteindre
les x besoins dont j'avais parlé il y a quelques mois lors de
la précédente tentative de progression dans le domaine.
hélas ce n'est pas la vision dominante parmi les imports de masse,
fatalement vu qu'il est impossible d'importer une addr à cet endroit qui 
nécessite une intégration avec connaissance du terrain et non un import
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Status de la BANO

[marc marc]

Le 08. 10. 18 à 23:23, EpicKiwi a écrit :
> les adresses qu'elles contiens ne sont pas encore assez matures
> pour êtres intégrés à OpenStreetMap.
> Est-ce toujours le cas ?

avis strictement perso : elles sont matures (et même si elles ne
le sont pas, elles sont importées en masse depuis longtemps)

> je me demande ce que je peux faire pour contribuer a l'amélioration des 
> adresses dans OSM.

ajoute les adresses de ton choix dans osm.
si tu veux éviter de recopier ces adresses à la main,
tu peux utiliser http://cadastre.openstreetmap.fr en utilisant
"Choix du type de données : Adresses" tout en bas
c'est hautement chronophage, il y aurait beaucoup à automatiser.

> Doit-je contribuer à la BANO ?

tu contribues automatiquement à la bano lorsque tu ajoutes
une adresses dans osm en France.
l'information lorsqu'elle existe dans osm a même priorité
sur les autres sources pour l'info dans la bano

> placers des points d'adresses dans OSM ? 

c'est là que la communauté se divise.
entre ceux qui veulent des adresses pures, points flottant sans aucun 
lien avec ce à quoi elle correspondent hormis la devinette par proximité
et ceux qui voudrait un lien entre l'adresse et ce à quoi elle 
correspond comme on le fait pour les communes (l'étendue de la
commune permet de faire un lien entre un bâtiment et sa commune)

> Puis-je placer des points OSM sur la base de la BANO ?

oui c'est permis.

> Il serait inutile que je mette les adresses qui serons un jour importés 
> de la BANO dans OSM. Et je me demande quand elle le seront...

vu qu'il faut une consensus pour faire un import dans osm,
je prend peu de risque en disant : pas cette année.
Mais l'absurdité de la situation fait que tu peux utiliser bano
pour charger les adresses d'une commune, supposément les vérifier
une à une et les importer oups intégrer dans osm et ceci autant
de fois que tu veux, y compris pour toutes les communes du pays.
c'est cet import oups intégration qui est en cours depuis longtemps.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] rendu osmfr

[marc marc]

> c'est quoi le "rendu fr" ? Il y a un 
> rendu différent en fonction de la langue du navigateur web ?

techniquement ce serrait possible mais rare sont les sites qui le font.
le rendu fr ou rendu osmfr est un fork (une copie adapté) du rendu 
classique https://tile.openstreetmap.fr/
la grande différence avec le rendu de https://www.openstreetmap.org
c'est que le rendu fr utilise par défaut le nom en français (le tag 
name:fr) lorsqu'il est présent tandis que le rendu osm.org utilise
le nom "local" (le tag name).
il y avait à l'origine quelques spécificité au rendu osmfr tel que
la baguette, le rendu des terrains de sport et le niveau de zoom 20
mais avec le temps, les différences se creusent, le rendu osm.org 
évoluant + vite que celui osmfr
comparaison https://mc.bbbike.org/mc/?num=2=mapnik=osmfr
diff 448 commits présent sur osmfr mais pas osm.org, 2797 commits 
présent sur osm.org mais pas sur osmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscines avec bassin extérieur chauffé

[marc marc]

Le 08. 10. 18 à 17:47, GarenKreiz a écrit :
> pour des raisons de sécurité <...> fermer

vu qu'un opérateur peux toujours fermer pour cause de sécurité
ou même selon son bon vouloir, cela me semble peu utile d'ajouter
cette possibilité dans osm (on doit pas traduire chaque phrase
du site web en tag)
mais si quelqu'un voulait le faire, cela ressemblerait à
opening_hours=Apr-Sep ; Oct-Mar "selon la météo"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 08. 10. 18 à 17:47, François Boucault a écrit :
> c'est le tag landcover qui va orienter le rendu

> Avez-vous une idée de comment on rajoute un rendu ?

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md
la doc en anglais pour le rendu standard.

https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md
si tu veux l'installer rapidos sur ton pc pour tester.

tu peux aussi soumettre l'idée à Christian pour le rendu fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscines avec bassin extérieur chauffé

[marc marc]

Bonjour,

Le 07. 10. 18 à 21:16, Paul Desgranges a écrit :
>      - retirer "heated=yes",

-> tag temperature
parce que non chauffé, c'est très au contraire subjectif.
je connais des piscines que les locaux considère comme chaude mais
non chauffée... car c'est une source thermale tellement chaude que
la piscine doit brider le débit pour qu'un humain n'y rôtisse pas.
de même l'eau dans des bassins fort foncé est naturellement chaude,
"chauffé par le soleil" ou non chauffé selon les personnes.

>      - pouvoir indiquer qq chose comme "opening_days=21 Apr-22 Dec"

le tag opening_hours te le permet

>      - conserver le "length=50" car même si on peut déduire ça de la 
> géométrie, la valeur de l'attribut est ainsi plus directement requétable 

oui mais c'est valable pour tous les tags. vas-tu ensuite ajouter
tous les tags de la piscine sur chaque bassin parce que c'est plus 
facile à utiliser ?
j'ai longuement discuté avec un autre contributeur qui ajoutait 
l'adresse postale du bâtiment proche sur toutes les fontaines 
publiques... et il pensait aussi ajouté l'arrêt de bus le plus proche
à nouveau parce que "plus simple à utiliser dans son umap"
on s'arrête où dans la duplication des données parce que plus facile 
pour une utilisation très précise des données ?
peut-être faudrait-il au contraire documenter des moyens faciles
pour tirer le meilleur parti des données existantes, une sorte
de tutoriel/howto avec les cas qui reviennent de temps en temps.

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

Re: [OSM-talk-fr] Piscines avec bassin extérieur chauffé

[marc marc]

Le 06. 10. 18 à 09:43, Paul Desgranges a écrit :
> ouvert jusqu'au 22 déc. 

opening_hours :)

> Au-delà des considérations écologiques

quel source d'énergie par curiosité ?

>       length=50

si tu l'as tagé comme un noeud, c'est utile.
sinon cela se déduit de sa géométrie.
Tu peux d'ailleurs ajuster as géométrie avec josm pour faire 50m
tout rond.

>       heated=yes
> Le 'heated' est non documenté et peu utilisé, c'est ce que j'ai trouvé 
> de mieux !

il y a le tag temperatue, si connue.
certains semble même s'en servir pour des valeurs subjective.
https://taginfo.openstreetmap.org/keys/temperature

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

Re: [OSM-talk-fr] RB94 est de retour

[marc marc]

oui c'est bien le temps humain le soucis.
je pense pas réaliste de garder un contributeur actif dont la moindre 
modif doit être corrigée parce qu'il n'a pas envie des conventions de 
base... ou alors il faut un team qui trouve ses infos tellement 
intéressante que cela les motivent à le suivre indéfiniment...
dur à trouver...
nous sommes déjà pas assez motivé pour donner un avis sur ceux
qui le demande avec review_request sur le changeset :s
John toi qui l'a suivit et a essayer de le faire progresser,
tu en penses quoi ? il faut à nouveau le bloqué pour une durée limitée 
pendant que tu essayes de lui expliquer "la vie" ? ou peine perdue ?

Le 03. 10. 18 à 19:12, Thomas Ruchin a écrit :
> C'est compliqué avec ce contributeur, c'est qu'il ajoute de 
> l'information réelle mais qu'elle ne correspond pas aux règles d'OSM. Il 
> est beaucoup en mode "je tague pour le rendui".
> J'ai constaté que personne n'a le courage de suivre régulièrement ce 
> contributeur, donc soit on se partage le travail de vérification et mise 
> à niveau (chronophage) soit il faut reverter tout ce qu'il est possible 
> de reverter.
> Bref, pas de solution miracle malgré les efforts conjoints de quelques 
> membres aguerris - dont John et Jean-Yvon.
> 
> Le mer. 3 oct. 2018 à 17:04, marc marc  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> J'ai transmis à Guillaume DWG
> 
> Si il faut un coup de main pour le revert,
> suffit de me dire depuis quelle date il faut faire un revert intégral.
> 
> Le 03. 10. 18 à 15:21, Thomas Ruchin a écrit :
>  > Bonjour
>  >
>  > Notre ami est de retour et plutôt fidèle à lui même (je n'ai regardé
>  > qu'un seul changeset)
>  > https://www.openstreetmap.org/changeset/63136972
>  >
>  > Thomas
>  >
>  > Le lun. 24 sept. 2018 à 21:06,  <mailto:osm.sanspourr...@spamgourmet.com>
>  > <mailto:osm.sanspourr...@spamgourmet.com
> <mailto:osm.sanspourr...@spamgourmet.com>>> a écrit :
>  >
>  >     Il y  du bon quand il dit les directions des voies de droite
> et de
>  >     gauche (quoique réflexion faite même pas : sur la voie de
> droite on
>  >     peut rester sur le périphérique) mais en utilisant des clés
> obsolète
>  >     (exit_to) et en détournant des clés de leur usage (name) :
>  >
>  > https://www.openstreetmap.org/node/168540666
>  >
>  >     J'aurais tendance du coup à dire autant faire des revert : tout
>  >     annuler avant que d'autres ne corrigent que partiellement :
>  > https://www.openstreetmap.org/node/308242485.
>  >
>  >     Le nombre de contributeurs ayant exprimé la nécessité de
> changer de
>  >     pratique est élevé comme le montre les statistiques fournies par
>  >     Antoine.
>  >
>  >     On peut proposer à Florian de regarder un par un les changements,
>  >     mais je crains qu'on n'assiste à la mutation d'un être humain en
>  >     kangourou vu le nombre de bonds qu'il va faire. Par exemple
> avec les
>  >     nœuds ci-dessus.
>  >
>  >     N. B. : il faudrait bloquer ses autres comptes car sinon il va à
>  >     nouveau changer de compte et non de pratique.
>  >
>  >     Jean-Yvon
>  >
>  >
>  >     Le 24/09/2018 à 18:30, Guillaume Rischard -
> openstreet...@stereo.lu <mailto:openstreet...@stereo.lu>
>  >     <mailto:openstreet...@stereo.lu
> <mailto:openstreet...@stereo.lu>> a écrit :
>  >>     Comme il dirait dans ses commentaires de changeset, j'ai bloqué
>  >>     quelques choses:
>  >>
>  >> https://www.openstreetmap.org/user_blocks/2254
>  >>
>  >>     Je ne connais pas assez les endroits où il a édité pour savoir
>  >>     s’il faut revert tout ou s’il y a du bon dedans. Est-ce que la
>  >>     communauté locale pourrait s’occuper de vérifier ses changesets?
>  >>
>  >>     Merci,
>  >>
>  >>     Guillaume, Data Working Group
>  >>
>  >>
>  >>>     On 24 Sep 2018, at 16:51, Christian Quest
>  >>>     mailto:cqu...@openstreetmap.fr>
> <mailto:cqu...@openstreetmap.fr <mailto:cqu...@openstreetmap.fr>>>
> wrote:
>  >>>
>  >>>     signalement DWG, blocage...
>  >>>
>  >>>     Le lun. 24 sept. 2018 à 16:37, Florian LAINEZ
> mailto:winner...@free.fr>
>  >>>

Re: [OSM-talk-fr] RB94 est de retour

[marc marc]

J'ai transmis à Guillaume DWG

Si il faut un coup de main pour le revert,
suffit de me dire depuis quelle date il faut faire un revert intégral.

Le 03. 10. 18 à 15:21, Thomas Ruchin a écrit :
> Bonjour
> 
> Notre ami est de retour et plutôt fidèle à lui même (je n'ai regardé 
> qu'un seul changeset)
> https://www.openstreetmap.org/changeset/63136972
> 
> Thomas
> 
> Le lun. 24 sept. 2018 à 21:06,  > a écrit :
> 
> Il y  du bon quand il dit les directions des voies de droite et de
> gauche (quoique réflexion faite même pas : sur la voie de droite on
> peut rester sur le périphérique) mais en utilisant des clés obsolète
> (exit_to) et en détournant des clés de leur usage (name) :
> 
> https://www.openstreetmap.org/node/168540666
> 
> J'aurais tendance du coup à dire autant faire des revert : tout
> annuler avant que d'autres ne corrigent que partiellement :
> https://www.openstreetmap.org/node/308242485.
> 
> Le nombre de contributeurs ayant exprimé la nécessité de changer de
> pratique est élevé comme le montre les statistiques fournies par
> Antoine.
> 
> On peut proposer à Florian de regarder un par un les changements,
> mais je crains qu'on n'assiste à la mutation d'un être humain en
> kangourou vu le nombre de bonds qu'il va faire. Par exemple avec les
> nœuds ci-dessus.
> 
> N. B. : il faudrait bloquer ses autres comptes car sinon il va à
> nouveau changer de compte et non de pratique.
> 
> Jean-Yvon
> 
> 
> Le 24/09/2018 à 18:30, Guillaume Rischard - openstreet...@stereo.lu
>  a écrit :
>> Comme il dirait dans ses commentaires de changeset, j'ai bloqué
>> quelques choses:
>>
>> https://www.openstreetmap.org/user_blocks/2254
>>
>> Je ne connais pas assez les endroits où il a édité pour savoir
>> s’il faut revert tout ou s’il y a du bon dedans. Est-ce que la
>> communauté locale pourrait s’occuper de vérifier ses changesets?
>>
>> Merci,
>>
>> Guillaume, Data Working Group
>>
>>
>>> On 24 Sep 2018, at 16:51, Christian Quest
>>> mailto:cqu...@openstreetmap.fr>> wrote:
>>>
>>> signalement DWG, blocage...
>>>
>>> Le lun. 24 sept. 2018 à 16:37, Florian LAINEZ >> > a écrit :
>>>
>>> je bondis !
>>>
>>> Le lun. 24 sept. 2018 à 16:13, Antoine Riche
>>> mailto:antoine.ri...@zaclys.net>>
>>> a écrit :
>>>
>>> Après une pause en août, RB94 a repris du service en
>>> septembre.
>>>
>>> Résultat nous sommes quelques-uns
>>> 
>>> (http://resultmaps.neis-one.org/osm-discussion-comments?uid=7301654)
>>> à perdre beaucoup de temps à réparer ses contributions,
>>> faire des reverts quand il est encore temps, et commenter
>>> ses changesets en vain car il ne répond jamais.
>>>
>>> Dernier exemple en date (qui va faire bondir Florian),
>>> cette sortie
>>> (https://www.openstreetmap.org/node/3268095064) de la
>>> gare BFM à Paris qu'il a renommé "3a-(à 5 min) Bus 62 89
>>> 132 325 Sortie 2 Rue de France". Il me semble qu'on lui a
>>> déjà signalé dans le passé que ce n'est pas correct.
>>>
>>> On fait quoi ?
>>>
>>> Antoine.
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>>> -- 
>>>
>>> *Florian Lainez*
>>>
>>> @overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 03. 10. 18 à 09:54, ades a écrit :
> la baignade est interdite, 
> arr. préf.

vu qu'on ne tag pas la législation, il ne faudrait pas
le renseigner dans osm en l'absence de panneau.

> Ne faudrait-il pas  préciser dans le wiki que ‘wetland’ ne s’applique 
> pas à ce qui est dans le lit mineur d’un fleuve ou d’une rivière ?

cela me semble une bonne idée. idéalement à faire aussi en anglais 
histoire de garder une cohérence.

> comment maintenir l’information ?

pose la question au contributeur initial.
est-ce que les grèves bougent beaucoup ? peut-être a-t-il voulu 
simplement renseigner que "par là bas" il y a des gréves, la précision 
extrême n'étant pas très nécessaire s'il n'y a pas de réelle utilisation 
nécessitant une grande précision.
ce problème se pose pour beaucoup de micro-mapping ou même des commerces 
dont je croise parfois des notes signalant leur fermeture il y a des années.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parking vélo dans un parking sous-terrain

[marc marc]

Le 03. 10. 18 à 13:35, Florimond Berthoux a écrit :
> Comment cartographier un parking vélo dans un parking sous-terrain ?

> Je vois deux possibilités, soit le parking sous-terrain n'est modélisé 
> que par un nœud alors j'ajouterais les tags:
> amenity=parking
> parking=underground
> bicycle=yes
> capacity:bicycle=XX

cela me semble le plus raisonnable/utilisable pour un parking souterrain

> Soit le parking sous-terrain est cartographié par une relation de 
> différents éléments. Dans ce cas je rajouterais un nœud 
> amenity=bicycle_parking.

mais comme cette relation n'est utilisé par (quasi ?) personne,
j'ajouterai un location=underground sur le nœud histoire
de rendre l'information utilisable.

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

Re: [OSM-talk-fr] Wiki : carte osm "obfuscated"

[marc marc]

Le 03. 10. 18 à 01:27, Philippe Verdy a écrit :
> il fallait juste 

il fallait juste "une réponse d'une ligne", j'ai demandé 3 fois,
il y en a MARRE d'avoir 4 pages dans lesquelles il faut trouver
la réponse à la question parce que tu coupes les cheveux en 4 !
si tu n'es pas content, si tu penses que "il fallait" autrement,
tu n'as qu'à faire !
ha ben non j'oubliais, tu es blocké sur le wiki à cause justement
de ce genre de comportement nuisible dans une communauté.

Je verrai demain si d'autres pages ont encore un souci.
d'ici là, il y en a au moins une, la globale, qui fonctionne,
ce qui n'était pas le cas avant ma modif. c'est déjà çà !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Wiki : carte osm "obfuscated"

[marc marc]

j'ai trouvé ailleurs, la carte s'affiche à nouveau en dynamique.
https://wiki.openstreetmap.org/wiki/FR:WikiProject_France
c'est sûrement très imparfait car trop simple et propre :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Wiki : carte osm "obfuscated"

[marc marc]

pour le switch, si c'est la ligne 3, sa syntaxe est
indigeste et il n'y a pas de "map=static"
si tu as la solution, version "utile en une ligne",
je suis preneur... sinon "on" ira chercher ailleurs
ou on attendra qu'un autre "on" ai une solution.

Le 02. 10. 18 à 23:42, Philippe Verdy a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[marc marc]

Je ne vois pas ce que cycleway:left:oneway vient faire dans l'histoire 
ni ce qu'est "le site général" dans les 3 url qu'il poste.

le soucis n'est pas comment décrire que la piste cyclabe est à double 
sens, le problème principal est de comment décrire que c'est une piste 
et pas une bande et que dont la connexion avec d'autres way se fait à 
des endroits précis et non pas de manière linéaire comme c'est le cas 
pour une bande.
cycleway:left:oneway=yes serrait adapté pour décrire le fait qu'une 
bande est à double sens, mais ici ce n'est pas une bande c'est une piste


Le 02. 10. 18 à 13:33, Thomas Ruchin a écrit :
> Bonjour
> 
> J'ai échangé avec le contributeur à l'origine de la suppression du way 
> "cycleway" distinct et voici ci-dessous son propos. J'avoue que je suis 
> mal à l'aise car je ne vois pas trop comment le convaincre que ce n'est 
> pas une bonne idée.
> 
> Thomas
> 
> "On m'a conseillé cycleway:left:oneway. Le tag est référencé sur le Wiki 
> ici: https://wiki.openstreetmap.org/wiki/Item:Q3113 et en bug ici: 
> https://github.com/Project-OSRM/osrm-backend/issues/4060 (plus ou 
> moins). Une demande a été faite ici aussi: 
> https://github.com/abrensch/brouter/issues/98. Il y aussi une discussion 
> ici: https://github.com/Project-OSRM/osrm-backend/issues/4943, je vais 
> tester ce qu'ils disent dans 4943.
> 
> Je ne particperai pas à talk-fr, je demande des conseils sur le site 
> général afin de recevoir des conseils de toute la communauté, pas juste 
> quelques personnes. Plus y'en a qui participent, plus le consensus est 
> valable."
> 
> 
> Le mar. 2 oct. 2018 à 10:57, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a 
> écrit :
> 
> Bonjour,
> 
> D'après le wiki
> https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_tracks cas T3
> 
> C'était bien réalisé, comme pour la future prolongation
> https://www.openstreetmap.org/way/614951874
> 
> Comme la double voie vélo est séparée d'un séparateur et par du
> stationnement, dessiner la voie est justifié à mon goût.
> 
> Le mar. 2 oct. 2018 à 09:51, Francescu GAROBY  <mailto:windu...@gmail.com>> a écrit :
> 
> D'accord avec Marc : vu que la voie cyclable est physiquement
> séparée, elle doit être tracée à part.
> 
> Francescu
> 
> Le lun. 1 oct. 2018 à 22:49, marc marc
> mailto:marc_marc_...@hotmail.com>> a
> écrit :
> 
> Le 01. 10. 18 à 22:45, Thomas Ruchin a écrit :
>  > j'aurais créé un way spécifique highway = cycleway.
> 
> cela me semble tout a fait adapté vu le séparateur entre.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Francescu
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> ___
> 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] Comment taguer une piste cyclable à double sens sur chaussée ?

[marc marc]

Le 01. 10. 18 à 22:45, Thomas Ruchin a écrit :
> j'aurais créé un way spécifique highway = cycleway.

cela me semble tout a fait adapté vu le séparateur entre.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de Juillet : analyse Osmose des postes électriques

[marc marc]

Je plains Quantin qui doit trouver les réponses dans 10 pages :)

>  > Est-il supprimé automatiquement au bout de plusieurs jours ?

Si l'anomalie n'existe plus (objet ajouté dans ton cas),
oui il disparaîtra d'osmose à la prochaine analyse.
actuellement c'est un cycle de 2 jours pour la majorité des analyses.

___
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

[marc marc]

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 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"
>> An: "Discussions sur OSM en français" 
>> 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,  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 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).
>>>
>>> Jean-Yvon
>>>
>>> Le 25/09/2018 à 20:37, Florimond Berthoux - florimond.berth...@gmail.com
>>> a écrit :
>>>
>>> L'exemple dont je parle c'est bien du stationnement, rien d'autre que du
>>> stationnement réservé à des véhicules de free floating voir photo là
>>> https://twitter.com/ManOnDaMoon/status/1039906448283770880?s=19
>>>
>>> Au passage pour ce qui est des stations de véhicules en location (genre
>>> velib ou autolib pour les parisiens) c'est une parcelle terrestre qui offre
>>> le service de stationnement à certains véhicules en plus de l'offre de
>>> location et de sa gestion (bornes).
>>>
>>> Bref mon propos est simple, ne pas créer un tag pour chaque chose sur
>>> terre, il faut factoriser afin de rendre plus simple l'ajout et
>>> l'utilisation des données.
>>>
>>> Le mar. 25 sept. 2018 à 12:04, marc marc  a
>>> écrit :
>>>
>>>> je partage l'avis de Jean-Yvon : une station de véhicule en partage (=un
>>>> operateur y a mis des véhicules destinés à être emprunté), ce n'est
>&

Re: [OSM-talk-fr] Château... qui n'en est plus vraiment un !

[marc marc]

Le 25. 09. 18 à 12:24, Nicolas Moyroud a écrit :
> Donc building=castle et pas building=apartments pourtant il est 
> maintenant divisé en appartements ?

le tag building=* est pour l'apparence et le tag building:use=*
pour l'utilisation actuelle.
https://wiki.openstreetmap.org/wiki/Key:building:use (la page n'est
pas encore traduite en français)
Tu peux mettre building:use=apartments si tu veux + raffiné
que building:use=residential

>> si tu trouves qu'il y a un intérêt historique : historic=castle
> Ça peut être assez subjectif mais je verrai avec les acteurs locaux 
> si il y a un vrai intérêt historique au bâtiment.

C'est en effet difficile de juger de l'intérêt historique
si le bâtiment n'est ni classé ni visitable :-s
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Château... qui n'en est plus vraiment un !

[marc marc]

Le 25. 09. 18 à 11:58, marc marc a écrit :
> building:usage=residentiel (le bâtiment est ajd utilisé pour du résidentiel)

oups c'est building:use (et non usage) =residential (et non residentiEl)
___
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

[marc marc]

je partage l'avis de Jean-Yvon : une station de véhicule en partage (=un 
operateur y a mis des véhicules destinés à être emprunté), ce n'est 
vraiment pas du tout la même chose qu'un parking (on y met son propre 
véhicule qu'on viendra récupéré dans quelques minutes/heures/jours)

c'est difficile d'invoquer un vice "tag pour le rendu"
à propos d'un tag qui n'est pas rendu :-)

Le 25. 09. 18 à 10:55, Florimond Berthoux a écrit :
> Un parking de scooter (et de vélo et de trottinette) partagé n'a rien à 
> voir avec un parking ?
> Je suis perplexe.
> 
> (Oserais-je dire que « amenity=scooter_sharing » c'est du tag to render ?)
> 
> Le lun. 24 sept. 2018 à 20:41,  a écrit :
> 
> Si je comprends bien, c'est du scooter partagé, rien à voir avec un
> parking.
> 
> Les emplacements des voitures en partage sont repérés avec la clé
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_sharing.
> 
> __amenity
> __=__bicycle_rental__
> 
> pour les vélos en libre service.
> 
> Donc amenity=scooter_sharing ?
> 
> Jean-Yvon
> 
> 
> Le 24/09/2018 à 14:18, Florimond Berthoux -
> florimond.berth...@gmail.com  a
> écrit :
>> Je ne retrouve plus l'information, mais la SNCF à ouvert à gare de
>> Lyon (Paris) un stationnement pour le freefloating (scooter
>> électrique Cityscoot, trottinette électrique Lime, ...)
>>
>> Alors si on suit la logique amenity=bicycle_parking il faudrait un
>> amenity=freefloating_scooter ? Étrange.
>> Cela se résout plus facilement avec le droit accès.
>> D'un point de vue utilisation de la BdD c'est plus simple aussi,
>> pas besoin de se faire une collection de tag pour trouver tous les
>> parkings de tous les types.
>>
>>
>> Le lun. 24 sept. 2018 à 13:01, djakk djakk > > a écrit :
>>
>> Merci Florimond tu as mis les mots sur un ressenti flou que
>> j’avais.
>>
>> Je trouve que highway=cycleway est un raccourci bien pratique
>> mais il ne s’agirait que d’un alias vers un objet plus+
>> complexe ayant des valeurs par défaut.
>>
>>
>> djakk
>>
>>
>> Le lun. 24 sept. 2018 à 11:22, 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.)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Château... qui n'en est plus vraiment un !

[marc marc]

Le 25. 09. 18 à 11:58, Nicolas Moyroud a écrit :
> Petite question de tagging concernant un ancien château qui a été 
> réaménagé et reconverti en plusieurs habitations. La façade et les tours 
> toujours présentent pouvant représenter un intérêt historique, 
> pensez-vous que le bâtiment dans son ensemble mérite toujours d'être 
> taggé historic=castle ?

historique ne dit pas ce qu'était le bâtiment dans le passé
mais qu'il a un intérêt historique.
dans ton cas, je mettrais :
bulding=castel (le bâtiment a le look d'un château)
building:usage=residentiel (le bâtiment est ajd utilisé pour du résidentiel)
si tu trouves qu'il y a un intérêt historique : historic=castle
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil d'édition/mise à jour de commerce

[marc marc]

Le 24. 09. 18 à 23:02, César Bihler a écrit :
> Bonjour,
> 
> outil permettant aux propriétaire d'un commerce de mettre à jour, signaler ou
> créer leur commerce.

onosm ou osmmybiz (version améliorée mais qui à son lancement ne 
fonctionnait qu'en Suisse... à voir si c'est mondial maintenant)

> une note

le soucis c'est le manque de monde qui traite les notes :(
16000 notes ouvertes en France
https://resultmaps.neis-one.org/osm-notes-country?c=France=opened

> prêter main forte

sans avoir été voir le github des 2 projets, je suis sur qu'un coup de 
main est sûrement utile :)
j'avais discuté à propos de la version améliorée, je trouvais qu'il lui 
manquait un test pour éviter les typo et mise en forme par rapport aux 
convention (par ex afficher le nom des rues proches tels qu'elles 
existent dans osm au lieu de laisser la personne rentrer librement la 
rue (ou signaler une erreur) et ensuite celui qui traite la note doit 
trancher en cas de typo)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] restrictions d'accès dans les voies de cimetières

[marc marc]

Le 23. 09. 18 à 19:19, Philippe Verdy a écrit :
> Quelle valeur indiquer ?

mapper ce qui existe et non la législation.
highway=path si c'est étroit ou track si c'est assez large
que pour un véhicule de service y passe (sujet à controverse,
certain ne voyant dans track que l'aspect rural/agricole/forestier)
+ access selon les panneaux présents
+ barrier éventuelle à leur emplacement
+ opening_hour éventuel


> - propriété publique mais d'accès restreint et réglementé dans un espace 
> délimité
> - propriété privée mais d'accès "permissif".

on ne mape pas la propriété dans osm.
donc les 2 sont access=permissif
si tu veux maper l'opérateur public du parc operator:type=public
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Copyright manquant sur www.moselleinfogeo.fr

[marc marc]

Le 23. 09. 18 à 15:43, Manuel Klein a écrit :
> il me semble que la carte affichée sur
> http://www.moselleinfogeo.fr/infogeo/index.php/ressources/environnement
> provient d'OSM, sans que les crédits soient mentionnés. J'ai envoyé un
> message via la page de contact le 19/08/2018 resté sans réponse.
> 
> Que conseillez-vous de faire ?

cela vient bien d'osm (tuile d'osm.org)
relance les avec le lien du wiki à propos des attributions et termine 
une phrase genre "merci de confirmer la prise en compte"
parce qu'avec les administrations, un correct c'est parfois lent :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Domaine public maritime et limites communales/intercommunales.

[marc marc]

Le 21. 09. 18 à 18:29, Philippe Verdy a écrit :
> Ne pourrait-on pas créer une pseudo-commune avec admin_level=8

si c'est pas une commune, il suffit de ne pas lui mettre admin_level=8 :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.15.0

[marc marc]

ultra résumé partiel :
les objets "horeca" passe en orange
création/amélioration des rendu de qlq objets (voir liste ci dessous)
les bretelles routières sont plus fines :)

 Message transféré 
Sujet : [OSM-dev] OpenStreetMap Carto release v4.15.0
Date : Fri, 21 Sep 2018 19:13:51 +0200
De : Daniel Koć 
Pour : osm-dev List 

Dear all,

Today, v4.15.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before all
tiles show the new rendering.

Changes include
- Changing gastronomy objects color to orange (affects restaurant,
fast_food, ice_cream, food_court, bar, cafe, nightclub, pub and biergarten)
- Changing farmland and societal amenities (like school, hospital etc.)
colors to fit better into the overall color systematic
- Adding rendering for man_made=wastewater_plant and man_made=water_works
- Adding icon for man_made=storage_tank and man_made=silo
- Adding icon for amenity=bicycle_repair_station
- Adding icon for leisure=amusement_arcade
- Adding icon for shop=bookmaker
- Adding icon for shop=trade
- Adding rendering for attraction=water_slide
- Rendering most of the road links thinner (affects trunk_link,
primary_link, secondary_link)
- Moving manors to z16+
- Fixing missing country labels on z4 (affects Canada, Russia and Greenland)
- Small code and icon fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.14.0...v4.15.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
dev mailing list
d...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
___
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

[marc marc]

Le 21. 09. 18 à 09:20, Christian Quest a écrit :
> Question peut être bête et en rapport indirect avec le sujet... 
> qu'est-ce qui empêche (légalement et pratiquement) de garer un vélo dans 
> un emplacement moto ?

je ne sais plus qui avait justement débloqué la situation l'an passé en 
signalant que rien n'interdit le vélo de se garer sur une place moto.
la différence c'est qu'un vélo pour rester garer longtemps a besoin d'un 
encrage... sinon il va se déplacer en l'absence de son propriétaire :)
___
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

[marc marc]

Le 20. 09. 18 à 17:24, Phyks a écrit :
> stationnements "deux roues"
>      amenity=motorcycle_parking

on en avait discuté de mémoire l'an passé
c'est ce qui en était resorti considérant que qui peux le plus
peux le moins.
quitte à proposer un nouvel icone mixte moto+velo si

>      bicycle_parking=stands

si l'arceau est utilisable tant pour les motos que pour les vélos (je 
n'en ai jamais vu utilisable par les 2), soit il faudrait renseigner
les 2, soit le plus cohérent me semble être motorcycle_parking=stands
vu que c'est le raffinement de amenity=motorcycle_parking

Le 20. 09. 18 à 22:59, Axelos a écrit :
 > Le 20/09/2018 à 17:54, djakk djakk a écrit :
 >> Est-ce l’occasion d’utiliser le point-virgule pour faire une liste ?
 >> amenity=motorcycle_parking;bicycle_parking
 > les valeurs existent déjà.

il y a probablement aucun outil au monde qui l'utilise.
On dirait un concours pour proposer le moins conventionnel possible :-(
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] highway=valeuractuelle en highway=road + qlqchosedautre=valeuractuelle

[marc marc]

et surtout repartir au début : quel est le problème ?
en quoi changer tous les highway=valeuractuelle en highway=road + 
qlqchose=valeuractuelle permet de résoudre un problème qui n'est pas 
possible de résoudre de manière satisfaisante avec le système actuel ?

Le 19. 09. 18 à 15:22, Jérôme Seigneuret a écrit :
> Oui,
> 
> Peux être recréé un sujet connexe avec cette proposition sur la liste
> FR vu que l'on a quand même bien dévié
> 
> Le mer. 19 sept. 2018 à 15:14, djakk djakk a écrit :
> 
> Ta proposition ? Oui bonne idée.
> 
> djakk
> 
> 
> Le mer. 19 sept. 2018 à 15:06, Jérôme Seigneuret a écrit :
> 
> Pas abonné pour le moment. Peux-tu retransmettre la proposition? 
> Merci
> 
> Le mer. 19 sept. 2018 à 14:55, djakk djakk  > a écrit :
> 
> Excellent !
> 
> Il y a justement une discussion en cours sur la taggin’ mondiale à
> propos de la vitesse par défaut. Je viens de toucher un mot sur les
> “zones 30” (C’est : [Tagging] maxspeed:type vs source:maxspeed //
> StreetComplet)
> 
> djakk
> 
> Le mer. 19 sept. 2018 à 14:34, Jérôme Seigneuret 
> mailto:jerome.seigneu...@gmail.com>> a
> écrit :
> 
> Salut, J'ai pas vraiment pris le temps de m'interroger sur cette
> histoire de zone légale. Mais je vais aller dans ton sens sur ce
> sujet.
> 
> Je pense que pour bien décomposer les éléments il faudrait en toucher
> un mot avec un juriste qui accepterai de nous aider ou via les
> universités de droits. C'est un sujet à proposer je pense.
> 
> J'en reviens à la zone 50 en ville (zone légale 50) puis les zone 30
> puis les zones 20 Les notions d'accès (private et permissive) car une
> voie ouverte à la circulation sans barrière physique est de fait dans
> la loi une voie privé ouverte à la circulation publique (dans mon
> métier ça a un impact sur notre activité)
> 
> Mon problème et en lien avec le source:maxspeed=sign avec par exemple
> maxspeed=70. Vu que les panneaux de sortie et d'entrée de ville ne
> sont pas sur toutes les voies (problème de chemins classés en 
> highway=residential ou l'inverse) les outils de propagation de
> vitesse par simulation entre en conflit car un bord est à 80km/h et
> l'autre des fois à 30km/h. (peut-être aussi un manque sur les
> vitesses en zone privé.
> 
> Bref je vois plus un schéma découlant aussi de name du fait de ce
> soit une zone et que ce soit un critère lié au loi et règlement (code
> de la route) et que c'est pas lié uniquement à une notion de vitesse.
> Donc cette clé doit être décorrélé de maxspeed.
> 
> je pense à un truc du genre *highway:legal_type* * * Cette clé a déjà
> été décrit pour les panneaux publicitaire et comblera emplement le
> dispositif de vitesse
> 
> en agglo: Si tu es à 50 les vitesses sont implicites après on peut
> aussi le faire en explicite maxspeed=50 *highway:legal_type=urban
> *ou *highway:legal_type:FR=agglomération* Si c'est une voie à 70 
> maxspeed=50 *highway:legal_type=urban *ou 
> *highway:legal_type:FR=agglomération* maxspeed=70 
> source:maxspeed=sign
> 
> Le reste est dans le même contexte
> 
> Ça règle aussi le problème des Voies vertes 
> *highway:legal_type:FR=Voie Verte*
> 
> Et évite de jouer juste sur des types de "voie spéciale" sachant que
> les voies vertes traversent des chemins de halage des voies de
> service etc avec des conditions de circulation très variables.
> 
> Qu'en pensez-vous? On réutilise une clé existante qui colle à notre
> contexte. C'est quand mieux que d'avoir maxspeed:type=* 
> source:maxspeed=FR:zone:30 ou FR:zone30
> 
> Et avec ça, on libère et fait mieux correspondre la notion de
> source:maxspeed
> 
> D'ailleurs il y a aussi des notions de vitesse que j'appelle "de bon
> sens" car à moins d'être avec un véhicule de rallye tu ne roules pas
> toujours au max de la vitesse légale (problème de visibilité,
> sinuosité, pente, nombre d'accès sur la voirie, espaces boisés etc 
> avec passage de faune)
> 
> Concernant les vitesses de circulation et les outils il faut voir de
> ce coté https://wiki.openstreetmap.org/wiki/Routing#Speed_data
> 
> A+
> 
> Le mer. 19 sept. 2018 à 12:02, djakk djakk  > a écrit :
> 
> Ou plus simplement living_street=yes :)
> 
> 
> djakk
> 
> 
> Le mer. 19 sept. 2018 à 11:06, djakk djakk  > a écrit :
> 
> Salut !
> 
> Dans cette situation, je vois 2 choses à cartographier sur les “way”
> du parking, l’aspect de la route (highway=service + 
> service=parking_aisle) et l'influence du panneau (un couple
> clé-valeur à inventer qui montre qu’on utilise le panneau officiel
> “zone de rencontre” : highway_legal=living_street ?)
> 
> 
> djakk
> 
> 
> Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret 
> mailto:jerome.seigneu...@gmail.com>> a
> écrit :
> 
> @Phyks C'est q'une clause de bon sens mais certains parking sont
> affiché avec des vitesses de circulation à 10 20 ou 30 km.
> 
> La loi dit:
> 
> / Article R. 413-18. Lorsque des parcs de stationnement de véhicules
> sont aménagés sur des 

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[marc marc]

Le 19. 09. 18 à 12:12, Vivien MICHON a écrit :
> Le terme "zerowaste" couvre un champ plus large que le fait de venir avec son 
> contenant
> En restauration, cela sous-entend même que la cuisine est faite en portant 
> attention au gaspillage

es-tu utilisateur de la démarche ?
car en l'étant, je ne me retrouve pas du tout dans tes critères.

en tout cas il y a une contradiction entre le wiki osm et le lien 
wikipedia dans la page du wiki osm
https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
selon le wiki osm c'est la vente en vrac
https://en.wikipedia.org/wiki/Bulk_purchasing
selon wikipedia c'est la vente en grande quantité
qui est représenté dans osm par wholesale (cité sur wikipedia
comme un autre mot ayant le même sens)
https://wiki.openstreetmap.org/wiki/Key:wholesale
c'est foireux :(

je vais discuterai "hors ligne" avec quelques amis adepte de la démarche 
pour voir si mon ressenti sur la classification est jute ou pas.

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

[OSM-talk-fr] bac a sable pour les tests

[marc marc]

Le 18. 09. 18 à 23:25, Jérôme Seigneuret a écrit :
 > J'ai demandé si l'on pouvait en mettre un en place
 >  pour des projets et des tests de comparaison sur la liste dev
 > peut être tech est plus approprié.

tech est plus approprié si tu penses que l'asso osm-fr
devrait le faire ou te renseigner pour le faire :)
mais la ml dev aurait du normalement fournir des infos utiles :(

 > @marc marc on a la possibilité de mettre ça en place ou
 > vous avez une doc pour mettre un serveur en place "from scratch"

il y a 2 solutions :
- soit utiliser l'existant :) dev.api permet déjà l'utilisation bac
à sable. le seul soucis c'est que le bac est quasi vide et donc
pour faire un test de renommage d'une clef sur le réseau routier 
français, il faut commencer par importer le dit-réseau
(sélection avec overpass dans josm, dupliquer les données dans une 
nouvelle couche, envoyer le tout vers "dev.api").
c'est facile pour les données de taille limitée mais galère
si tu veux tester à l'échelle du pays.
- soit une créer une nouvelle bdd ou on pourrait imaginer importer
une extract france par ex.
pour cela 2 solutions : soit utiliser les config chef utilisé par 
osm.org soit les refaire en mode ansible utilisé par osm.fr

 > et ainsi s'en servir pour présenter aussi des cas d'étude
 > sur du routing ou du géocodage.

c'est là que cela coince : dev.api n'est rien d'autre que la bdd
et le script web qui interagit avec.
mettre UN serveur en place c'est facile mais il n'y a pas de rendu
de cette base, pas de routing, de nominatim, pas d'overpass.
hors osm c'est pas UN c'est plein d'outils annexes parfois nécessaire.
cela voudrait dire mettre en place ces outils annexes avec
les données du bac à sable.
et là le soucis, avis purement personnel, c'est les bras :
osm.fr a tellement d'outil qui attendent des bras pour progresser,
ce n'est peut-être pas prioritaire de faire un bac à sable.
Mais si des bras sont motivés pour le faire, je suis dispo pour aider.
C'est évidement conditionné à l'avis positif de l'asso,
je parle en mon nom propre, j'aide un peu l'asso au niveau technique
mais je ne parle pas en son nom.
ceci dit d'autres demandes semblable ont été acceptée,
sous réserve de bras pour le faire :)

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

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[marc marc]

djakk n'est pas un bleu même s'il est rarement aussi actif ici :)
pour la proposition au niveau mondial, je t'y encourage.
ceci dit rien n’empêche d'en parler ici, c'est, je pense, même très 
utile car l'impression qui en ressort c'est que les premiers retours 
n'ont pas été une discussion mais à sens unique.
je suis aussi personnellement très ennuyé de voir des éditions 
mécaniques contestée et en plus faite avec source=survey
genre renseigner la volumétrie du traffic avec 
https://wiki.openstreetmap.org/wiki/Key:traffic
tu as vraiment été mesurer le trafic de plein de route ?
au final cette clef ne veux plus rien dire si on y trouve
tout autant des infos objectives que des infos "je suis en désaccord 
avec highway=trunk alors je met traffic=trunk source=survey"
ou l'ajout de nouveau tag dans un revert cela sent la mauvais foi :(

pour repartir sur des bases plus saine, il faudrait (re)commencer
dans un nouveau sujet par expliquer l'un des problèmes que tu 
rencontres, voir si on peux le résoudre avec l'existant et ensuite 
seulement PROPOSER une modif, puis après un temps raisonnable la mettre 
en place si cela fait consensus.
il faut aussi tenir compte des objections précédentes (par exemple 
dupliquer toutes les clefs highway dans une autre clef parce que c'est 
plus facile pour ton rendu n'est pas très censé et in-maintenable).

Cordialement,
Marc

Le 18. 09. 18 à 22:30, Jérôme Seigneuret a écrit :
> Merci,
> Sache qu'on ne remet pas ton implication en cause.
> J'ai fait une annulation de la dernière partie du wiki car c'est 
> l'élément de référence pour l'ensembles des contributeurs. Même si les 
> modifications sont possibles (car c'est du mediawiki) on en parle avant 
> que cela ai un impacte considérable et de devoir faire les modifications 
> à 10 pour revenir en arrière.
> 
> J'ai aussi été gourmand au début et voulu bousculer les choses ... Cela 
> ne se fait pas par la force en ajout massif de données (tu peux faire de 
> l'ajout massif en respectant ce qui est déjà mis en place) mais en 
> communicant et en ayant des arguments assez convainquant pour faire 
> adhérer la communauté que nous sommes. On y trouve tous des intérêts qui 
> sont très variables et avec des niveaux de définition et de précisions 
> et une granulométries qui reflètent les niveaux de compréhension de 
> l'espace propre à chacun d'entre nous. Ce qui peut paraître futile pour 
> certains et une nécessité pour d'autre.
> 
> Certains sujets sont portés par peu de personnes car cela nécessite des 
> connaissances métier (réseaux électriques, eau, télécom) et dont 
> certaines informations de schématisation sont trop complexes
> Je parle pour InfosReseaux  qui s'est occupé de compléter les pages 
> concernant les réseaux électriques.
> D'autres touches beaucoup plus de gens et sont aussi contrôlé par 
> beaucoup plus de personnes et retouché aussi par bien plus de monde.
> 
> Es-tu affilié à un groupe local? Je pense que c'est déjà un bon début 
> pour échanger se présenter et communiquer aussi sa vision, les 
> thématiques de travail souhaitées et le territoire (même si j'ai pas 
> commencé mes édition ainsi)
> 
> Dans presque chaque département il y a une liste locale et plusieurs 
> groupes de travail car les intercommunalités s'intéressent au crowsoursing.
> 
> Bonne soirée.
> 
> Le mar. 18 sept. 2018 à 18:24, djakk djakk  > a écrit :
> 
> Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation
> de Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas
> vérifié si le contenu est cohérent).
> L’argument qui a fait mouche chez moi : l’absence de
> retro-compatibilité.
> 
> Je présenterai sur la mailing-list tagging (mondiale) un moyen
> d’arriver à une définition commune dans le monde entier pour la
> définition des routes, en contournant l’actuelle clé highway au lieu
> de changer brutalement la définition de ses valeurs. Je trouve que
> c’est améliorer Openstreetmap de gommer (autant que possible) les
> différences entre pays sur les définitions de valeurs.
> (Comment ? en décomposant ce qui fait une route, de l’aspect visuel
> à la définition administrative à l’utilisation plus ou moins
> intensive, pour du trajet interurbain ou du trajet intra-urbain).
> 
> 
> @+
> djakk
> 
> 
> Le mar. 18 sept. 2018 à 09:31, Christian Quest
> mailto:cqu...@openstreetmap.fr>> a écrit :
> 
> Le dim. 16 sept. 2018 à 15:43, djakk djakk
> mailto:djakk.dj...@gmail.com>> a écrit :
> 
> Je pense que je rajoute de l’information sans en supprimer
> ... ? Bon certes je chamboule l’existant ...
> 
> djakk
> 
> Dommage de procéder ainsi "en force".
> 
> Le tagging sur OSM fonctionne grâce à un consensus, il faut le
> respecter ou ouvrir une discussion (large) pour faire naître un
> nouveau consensus et ne pas "chambouler" ainsi l'existant, 

Re: [OSM-talk-fr] Besoin d'avis sur cette pratique

[marc marc]

Pour proposer qlq chose + utile que la suppression : 
man_made=wheel_trace + description : trace de la machine d'irrigation
histoire que le prochaine qui regarde l'ortho ne se pose pas la question
de ce que c'est et rajoute erronément un highway

Le 18. 09. 18 à 21:35, Romain MEHUT a écrit :
> Bon on est tous d'accord qu'il ne s'agit pas d'un highway.
> 
> Merci.
> 
> Romain
> 
> Le jeu. 13 sept. 2018 à 00:27, Jérôme Seigneuret 
> mailto:jerome.seigneu...@gmail.com>> a écrit :
> 
> Il faut juger du caractère temporaire, du faite qu'ell soit utiliser
> pour aller vers une destination et non pour exploiter l'inérieur de
> la parcelle. Une route enherbée ne laisse pas spécifique de trace
> mais ça reste une route si elle est traversé au même endroit
> régulièrement. dans ce cas on gère ça avec tracktype et on utilise
> le grade correspondant.
> Il y a une notion d'entretien également. Même un sentier piéton est
> entretenu.
> Un sillon de passage d'un tracteur au milieu d'un champs n'a pas de
> sens. Par contre ça pourrait en avoir au mieux d'une vigne et
> pourtant on ne fait pas un highway=track pour les inter-rang  je
> mais cependant le chemin autour car cela permet de traversé des
> coteaux et en plus comme c'est privé il faut définir
> access=permissive ou private suivant les indications. C'est la même
> chose en forestier: On ne crée pas une route entre chaque alignement
> d'arbres... Une question de temps, de lisibilité et de bon-sens
> 
> Bonne soirée
> Bonne soirée
> 
> Le mer. 12 sept. 2018 à 23:38, Gwenaël Jouvin
> mailto:gwenael.jou...@laposte.net>> a
> écrit :
> 
> Bonsoir,
> 
> Sans connaître le contexte, à la lecture des commentaires il est
> dommage que ça parte d’un si mauvais pied par des phrases
> courtes inévitablement mal interprétées à l’écrit.
> 
> Après, je comprends la réaction épidermique du contributeur
> initial qui voit son travail supprimé : il aurait, je crois, été
> plus prudent de le contacter au préalable ou de mettre une note.
> Je pense que je serais également pas très content si quelqu’un
> passait derrière mes contributions de terrain en cassant tout…
> c’est récemment arrivé à un collègue et il est obligé de tout
> refaire (chemins coupés, toponymes mélangés, historiques
> perdus…), y a de quoi enrager.
> 
> Évidemment, il est également confortable de bosser sur une carte
> où il existe déjà plein d’éléments mis par d’autres personnes
> qui maîtrisent les imports de jeux de données.
> 
> Contributeurs d’intérieur et d’extérieurs sont complémentaires !
> 
> 
> Sur l’objet en lui-même, ce n’est clairement pas un 
> puisque ce n’est pas une voie de circulation mais la trace
> laissée par une machine.
> 
> 
> Gwenj
> 
> 
> Le 12/09/2018 à 22:46, Romain MEHUT a écrit :
>  > Bonsoir,
>  >
>  > Sur la base d'un commentaire "J'ai une question à la con :
> c'est quoi ce truc ?" dans ce changeset
> https://www.openstreetmap.org/changeset/62500260 j'ai supprimé
> tous les highway=footway qui à mon sens n'en sont pas.
>  >
>  > Le contributeur à l'origine des contributions proteste contre
> mes suppressions comme vous pourrez le lire dans la suite de
> commentaires du changeset.
>  >
>  > Quel est votre avis ?
>  >
>  > Merci.
>  >
>  > Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Impasse

[marc marc]

version courte :
si tu veux tager les panneaux “voie sans issue”
c'est un traffic_sign=* qu'il te faut à l'endroit du panneau.
Tu peux le lier au way concerné par proximité ou, pq pas le faire 
appartenir au way concerné comme on le fait pour les stop.
mais un tag de panneau sur un way c'est spécial même si JB a déjà trouvé 
dans le passé un précédent dans cette façon tordue de faire)

version longue pour le tag noexit :
le wiki, dans sa version anglaise et française, ne donne aucune 
interdiction de l'utiliser sur les way, mais il donne un sens précis:
c'est une information qui dit que le nœud d'un way n'est volontairement 
PAS connecté/connectable à l'autre way tout proche.
son principal usage est la qualité : il permet de faire la différence 
entre un way ajouté et dont on a aucune idée si l'extrémité continue ou 
pas soit parce qu'il y a des arbres ou des immeubles qui masque le way 
sur l'image sat, soit parce que tu n'as pas pris la route jusqu'au bout 
et que tu l'as juste renseigné en passant sur la route perpendiculaire.
en sens les alertes osmose par ex sont tres utile avec ce tag, ils te 
disent les endroits ou le travail n'est pas finit.
pour le routages, ce tag est complètement inutile, que la rue soie 
réellement une impasse, le routage ne sait de toute façon pas l'utiliser 
si son extrémité n'est pas connecté à autre chose
cela explique aussi bien pq sans être faux, c'est totalement vide
de sens sur un way, je me demande s'il y a un outil qui l'utilise.

le détail sur https://wiki.openstreetmap.org/wiki/Key%3Anoexit
https://wiki.openstreetmap.org/wiki/Talk:Key:noexit#More_usage_instructions

le seul gros défaut, c'est le nom de la clef : validate:noexit aurait 
été parfaitement clair que c'est ni le panneau qui est renseigné
ni une information pour le routage.

PS: j'ai coupé le hors sujet... essayons de garder un titre = un sujet
c'est déjà assez dur à suivre ainsi.

Le 18. 09. 18 à 19:05, djakk djakk a écrit :
> Un tribunal, ou une université, ou une sous-préfecture, je le résumerai 
> à des emplois de bureau ...
> 
> Mais, ça n’est pas le bon sujet ! ;P
> 
> Pour les impasses, en faisant une requête overpass-turbo, je me rend 
> compte que le noexit sur les ways est pas mal utilisé malgré 
> “l’interdiction” du wiki ...
> 
> 
> djakk
> 
> 
> Le lun. 17 sept. 2018 à 15:04, JB  > a écrit :
> 
> 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

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[marc marc]

Le 18. 09. 18 à 20:05, Axelos a écrit :
> la balise highway=living_street est suffisante
> sur les voies accédants aux places de stationnements ? 

cela me semble suiffant si c'est ainsi qu'est la réalité
de la signalisation en place.

> N'est-il pas judicieux d'ajouter une autre balise en plus ?

il y a plein de tag possible en plus (surface smothness lit lanes)
mais aucune d'eux n'est indispensable, c'est des infos supplémentaires
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[marc marc]

Bonjour et bienvenu !

Le 18. 09. 18 à 16:04, seb...@laposte.net a écrit :
> Montpellier était seule candidate pour le State 
> Of The Map FR de l'année prochaine
> je n'ai pas vu de confirmation...

de mémoire cela a été annoncé sur la ml de l'association.
Vu que l'asso a un ca ce soir, j'imagine que ce point
est à l'ordre du jour.

> Connaissez vous http://fotoquest-go.org/en/map/ ou 
> http://fotoquest-go.org/en ?
> C'est une initiative autrichien de sciences participatives relatives 
> à l'occupation du sol.

c'est dommage que cela ne soie ni collaboratif ni opendata ni même clair
Pas convaincu non plus que cela ai la moindre utilité d'aller voir sur 
place qu'un champ est devenu un parking comme visible sur l'image sat.
Le seul intérêt c'est que le jeune du coin peux se faire 1€/15min
en ayant l'impression de faire avancer la science tandis que l’auteur 
pourra se faire un article sur la science participative sans rien
y connaître ou presque, supposition de ma part vu l'aspect
non collaboratif non ouvert.. en gros c'est un uber de la photo.

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

Re: [OSM-talk-fr] zones de parcmètres

[marc marc]

Bonjour,

Le 18. 09. 18 à 15:30, Florian LAINEZ a écrit :
> En ville, le stationnement est souvent régulé avec des zones.

Je trouve que la zone n'est pas une propriété du parcomètre
mais du parking et j'utiliserais donc parking:condition sur
les way concerné tel que documenté sur
https://wiki.openstreetmap.org/wiki/Key:parking:lane

parking:zone=
me parait + universel.
Le plus utilisé est parking:ticket:zone mais cela donne trop 
l'impression qu'il faut un ticket ce qui n'est pas le cas
dans de nombreux endroit.

pour les codes à utiliser dans l'application mobile
je suis pas convaincu de la plus-value a les dupliquer
tous les codes possibles sur chaque parcomètres.
c'est pas repris dans la doc de l'app ? c'est le role d'osm
d'être un mode d'emploi de l'app ?

je n'aurais mis aussi qu'une url website au lieu de 2.

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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[marc marc]

autant lunchbox a une connotation "boite à tartine" (je m'attend à ce 
que cela parle d'une épicerie qui vend des sandwich à emporter)
autant bulk_purchase a un côté "bulk" cad de masse, je m'attends
à ce que la magasin de boisson vende le bvin en tonneau.
hors les magasins zéro déchet n'ont souvent aucun lien ni avec le type 
de produit (il y en a bien sur qui vende de la nourriture mais il y a 
aussi des cosmétiques, des produits d’entretien, ...) ni avec le volume 
(tu peux acheter 50gr de noix ou 5l de produit de vaisselle)

Le 18. 09. 18 à 12:07, Julien Coupey a écrit :
> Bonjour,
> 
> Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il 
> y a déjà bulk_purchase[1] qui semble approprié.
> 
> Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent 
> ici[2] ou là[3].
> 
> À +
> Julien
> 
> [1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
> [2] : https://www.openstreetmap.org/node/5618249615
> [3] : https://www.openstreetmap.org/node/5867522816
> 
> On 18/09/2018 11:20, Vivien MICHON wrote:
>> Bonjour,
>>
>> Je propose la possibilité d’indiquer les commerces acceptant que le 
>> client vienne avec son propre contenant (de type boîte fermable et 
>> réutilisable).
>>
>> Cette pratique est de plus en plus courante, afin d’éviter 
>> l’utilisation de boîtes ou papiers jetables (zéro déchet).
>>
>> Elle est possible en vente à emporter dans un nombre croissant de 
>> restaurants, traiteurs, boucheries, fromageries…
>>
>> Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en 
>> YES ou NO.
>>
>> Le terme « lunchbox » fait référence à la boîte contenant le déjeuner, 
>> qui peut être utilisée à toute heure, pour tout type d’achat. Le terme 
>> indique également qu’il s’agit de nourriture.
>>
>> exemple : https://www.openstreetmap.org/node/5130551429
>>
>> Merci d’avance pour vos commentaires.
>>
>>
>>
>> ___
>> 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] nouveau champ takeaway:lunchbox

[marc marc]

Le 18. 09. 18 à 11:55, Jean-Claude Repetto a écrit :
> Il faudrait plutôt trouver un terme évoquant la notion de "sans emballage".

zerowaste ? c'est en tout cas comme cela qu'on ne nome parmis chez les 
partisants.
et cela a l'avantage de couvrir tout autant la pizzerie qui accepte de 
vendre une pizza à emporter dans le récipiant du client, que le 
restaurant qui mettra les restes du repas dans une boite du client,
ou me lagasinqui vend de l'huile de l'olive sans fourger une bouteille.

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

Re: [OSM-talk-fr] Rendu humanitaire

[marc marc]

Bonjour,

Le 17. 09. 18 à 12:45, Severin Menard a écrit :
> J'ai l'impression que le rendu humanitaire ne s'affiche plus

chez moi il s'affiche.
peux-tu décrire un peu mieux le problème ?
tuile vide/404/tuile pas à jour/coordonée/...

> il est toujours hébergé sur les serveurs d'OSM France ?

oui

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

Re: [OSM-talk-fr] Les bretelles

[marc marc]

le preprocesseur peux tres bien analyser la moindre diff
c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie 
toutes les bretelles d'une route pour mettre à jour un tag 
mono-utilisateur :)

publie qlq part stp un extrait rendu osm <> rendu avec ta modif
(ou extrait michelin), j'ai du mal a imaginer la chose.


Le 15. 09. 18 à 11:01, djakk djakk a écrit :
> Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour 
> récupérer l’info, mais en pratique difficile de faire un pré-processeur 
> pour les données énormes et très mouvantes d’osm. De plus, je pense que 
> pour les collectrices c’est impossible d’y arriver.
> 
> Le rendu correspondrait à la plupart des cartes, par exemple les cartes 
> Michelin papier.
> 
> 
> djakk
> 
> Le sam. 15 sept. 2018 à 10:09, marc marc  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Bonjour djakk,
> 
> Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
> 
>  > si on relie une autoroute à une tertiary, on pourrait
>  > choisir au niveau du rendu de ne pas afficher la bretelle.
> 
> je ne suis pas sur de comprendre.
> De quel rendu tu parles ? un rendu perso ?
> tu peux poster qlq part un extrait de carte qui n'afficherait pas
> certains bretelles parce que autoroute-tertiary  ?
> 
>  > Impossible en l’état actuel.
> 
> Parmis les spécialistes des styles de rendu, quelqu'un confirme
> qu'on ne peux pas récupérer le type de voie inférieur connectée à un
> bretelle ?
> si c'était confirmée, cela me semble bien + un problème de rendu
> qu'un problème de donnée.
> s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
> pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le
> cas réel d'utilisation)
> 
> Cordialement,
> Marc
> ___
> 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 bretelles

[marc marc]

Bonjour djakk,

Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :

> si on relie une autoroute à une tertiary, on pourrait
> choisir au niveau du rendu de ne pas afficher la bretelle.

je ne suis pas sur de comprendre.
De quel rendu tu parles ? un rendu perso ?
tu peux poster qlq part un extrait de carte qui n'afficherait pas 
certains bretelles parce que autoroute-tertiary  ?

> Impossible en l’état actuel.

Parmis les spécialistes des styles de rendu, quelqu'un confirme
qu'on ne peux pas récupérer le type de voie inférieur connectée à un 
bretelle ?
si c'était confirmée, cela me semble bien + un problème de rendu
qu'un problème de donnée.
s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le 
cas réel d'utilisation)

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

Re: [OSM-talk-fr] Numéro de tuile ?

[marc marc]

dans FF : F12, console réseau, rafraichir la page, tu as alors la liste 
des urls de toute les tuiles.

sinon perso je charge l'endroit dans josm, tu actives le fond de carte 
osm.org, clic droit, info sur la tuile

Le 14. 09. 18 à 10:27, Hélène PETIT a écrit :
> C'est quoi le truc pour connaître le numéro d'une tuile affichée dans 
> OpenStreetMAp.org ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr