Re: [OSM-talk-fr] To Vote or not to Vote

[marc marc]

Le 11.12.18 à 21:49, Jacques Lavignotte a écrit :
> inquiétudes sur certaines tendances.

avis perso :
- le représentant d'HOT n'est pas indépendant même s'il croit l'être
(je vois mal comment il pourrait voter contre une demande de HOT)
- Guillaune et Joost ont un implication communautaire de longue date
et n'ont pas de conflit connu (quoi que pour Guillaume, il est dépendant 
au vélo, mais cela ne compte pas) :-) ;-)
c'est 2 candidats qui méritent du soutient.
je m'abstiens de donner una avis sur les autres par manque d'info.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] osm-fr machine ovh down

[marc marc]

Bonjour,

les 4 serveurs ovh osm25/26/27/28 sont inaccessible (pas
de réponse au ping ni ssh).
Par conséquent l'ensemble des services concernés sont en panne
cela inclus principalement :
- umap
- le rendu fr et bzh
- le site web de l'asso
- les liste de diffusion régionale et spéciale (genre transport)
- le forum osm-fr
- osmose (le frontend=l'interface web totalement et une partie des 
backend (les analyses en eu-même) ne tournent plus et les autres ne
savent plus envoyer leur résultat)

le détail complet est sur le wiki
https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France
tout ce qui est noté avec osm25/osm26/osm27/osm28

Apparemment St Nicolas a appelé père fouettard

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

Re: [OSM-talk-fr] Importation PNR Sainte-Baume

[marc marc]

Le 05. 12. 18 à 18:31, Nicolas Moyroud a écrit :
> 
>> Si ce sont les limites *communales* qui sont basées sur BD Topo, il 
>> faut couper en segments "BD Topo" et "segments libres" et reprendre 
>> (par conflation ?) les nœuds OSM qui sont bien pour les nœuds BD Topo.
>>
> Hum vu que ça ne suit pas partout les limites communales il va y avoir 
> des endroits où il n'existera pas de noeuds dans OSM. Donc il faudra 
> créer des nouveaux noeuds en se basant uniquement sur la source. Mais si 
> ça provient de la BD Topo IGN il me semble qu'on n'en a pas le droit ! 
> D'autres ont un avis à ce sujet ?

je ne comprend pas le soucis que tu évoques.
tu charge la géométrie du PNR par exemple dans josm (peu importe
la source tant qu'elle est valide pour osm)
tu prend les limites communales d'osm sur la zone concernée.
tu fais une relation qui comporte 2 type d'outer :
- là oü le parc suit les limites d'une commune, tu remplaces
le(s) tronçon(s) concerné en faveur du(des) way osm correspondant
- là où le parc ne suis pas les limites d'une commune, tu garde
le tronçon définit par la source d'origine.

ce n'est évidement valable que pour les parcs "non minuscule"
pas besoin de faire une relation multipolygon si le parc
n'a besoin que de qlq noeuds :) un mp serrait exact mais un peu excessif
pour les petits parc, un simple way suffit même si 10m est commun
avec une limite communale

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

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

[marc marc]

Le 27. 11. 18 à 23:25, Antoine Riche a écrit :
> j'imagine que si on demande à un humain "normal" 
> (ni expert OSM, ni aménageur, ni même cycliste) de quoi il s'agit, 
> il répondra que c'est une piste cyclable.

apparemment non :)
Je pensais que cette confusion était du passé et était LE résultat de
la discussion précédente. la voie verte n'est pas une piste cyclable
qui tolère des intrus sans vélo.

> J'aime bien l'idée que cette personne puisse mettre à jour  
> la carte et ajouter cette voie sans trop se prendre la tête

tout a fait
il voit un chemin, il tag un chemin highway=track
s'il voit plutôt une ancienne route inter-village ré-allouée
à la mobilité douce, il tag highway=unclassified

> L'aménageur qui a posé le panneau "interdit à 
> tous véhicules sauf riverains" ajoute motor_vehicle=destination. 

ok

> Enfin un cyclo-mappeur consciencieux vérifie que l'aménagement 
> est bien mappé : il voit le panneau Voie verte et ajoute traffic_sign=FR:C115.

et là je ne comprend pas.
sur quoi va se baser le cyclo-mappeur pour cet ajout ?
s'il est sur place et voit le panneau à l'entrée d'un chemin,
il peux juste constater qu'il y a un panneau et mettre un nœud.
rien ne lui permet en voyant le début du chemin de savoir si la voie 
verte persiste au prochain croisement et si à ce croisement elle 
continue avec le même chemin osm ou si le chemin osm et la voie verte 
divergent.
Si le cyclo-mappeur fait une modif depuis son salon en se basant
sur foot=designated cyclewaw=designated alors cela montre que
traffic_sign sur le way ne sert a rien puisqu'il est une information 
dérivée de tags qui sont suffisant à localiser la voie verte.
Avis perso, le contributeur "sans prise de tête" aura bien plus facile 
d'ajouter description="voie verte" plutôt que de mémoriser les codes
légaux des panneaux et deviner leur portée lorsqu'il n'emprunte pas
l'entièreté de sa longueur.

Est-ce que ton refus de la vision quasi généralisé vient-il du fait
qu'il y a une donneur d'ordre qui a un besoin de rendu particulier ?

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

Re: [OSM-talk-fr] arbres remarquables

[marc marc]

Le 27. 11. 18 à 12:14, Jozeph a écrit :
> Ma question se résume finalement à savoir si on rajoute au nom de 
> l'arbre la mention "arbre remarquable" ?

je ne connais aucun arbre dont c'est le nom :)
ce que tu cherches est denotation=landmark
https://wiki.openstreetmap.org/wiki/Key%3Adenotation
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Bonjour,

Le 26. 11. 18 à 12:21, Pierre L. a écrit :
> Cette histoire de "highway=path" ne me parle pas. Où dois-je me diriger
> pour insérer cette info ?

c'est un problème de qualité de traduction :-(
tu dessines le tracé comme pour n'importe quel autre voie.
path dans iD se nome actuellement erronément "chemin non carrossable"

> En voyant ainsi le "highway=track/unclassified" désignant une voie
> verte, mais avec véhicules autorisés à titre exceptionnels

la caractère exceptionnel est mal formulé.
path est un sentier qui "physiquement" ne permet pas le passage
d'un véhicule de type 4x4, peu importe l'autorisation
track est un chemin qui physiquement le permet.
les autorisations genre "sauf riverain" se décrivent par le tag
d'accès comme par exemple access=destination.

> À utiliser donc dans ce cas par exemple :
> https://goo.gl/maps/SCnTFPQLj692

Il y a un problème de licence interdisant d'utiliser les images 
propriétaires de Google Maps et de Google Street View.
Si tu avais une photo sans ce problème, je répondrais :
je pense que la meilleur façon d'agir face à ce genre de situation
c'est un email au responsable concerné parce que c'est un *** sans nom.
Je laisse les pro du domaine confirmer mais une voie verte permis aux 
voitures des riverains me semble incompatible légalement.
ceci dit pour osm, c'est assez facile :
type de voie : track (assez large pour un véhicule)
faite pour les vélos et piéton : bicycle=designated foot=designated
les riverains : access=destination
les véhicules de service : à ma connaissance on n'a pas de tag
surface=asphalt
pour le voie sans issue : rien sur le chemin, c'est plus loin
sur le nœud "sans issue" qu'il y a parfois un attribut à ajouter
comme par exemple une bloc de béton bloquant physiquement les véhicules
il y a plus qu'à aller voir sur place pour avoir une source=survey :)

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

Re: [OSM-talk-fr] internationalisation du wiki

[marc marc]

Bonjour,

Le 24. 11. 18 à 19:37, David Crochet a écrit :
> Le 23/11/2018 à 20:00, marc marc a écrit :
>> l'utilisateur doit utiliser un template ou un url particulière lorsqu'il
>> traduit une page en->fr ?
> tout se fait dans une page "spéciale"

se ferrait ou se ferra :)
Car si j'ai bien compris, l’extension translate n'est pas installé
sur le wiki osm.org en remettre un couche ici ne change rien,
l'utilisateur ne sait pas faire une page internationalisée
tant qu'un admin osm.org (dont aucun ne semble lire ici) ne
l'installe pas l’extension. faut aller en parler sur talk
et/ou sur le github osm.org

ou alors j'ai mal compris quelque chose :)

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

Re: [OSM-talk-fr] internationalisation du wiki

[marc marc]

Le 23. 11. 18 à 19:42, David Crochet a écrit :
> Il faut utiliser le système d'internationalisation de mediawiki ( 
> https://www.mediawiki.org/wiki/Extension:Translate/fr )

mais concrètement, il faut faire quoi ?
l'utilisateur doit utiliser un template ou un url particulière lorsqu'il 
traduit une page en->fr ?
un admin doit faire qlq chose ? (parce qu'il me semble qu'il y a aucun 
admin osm.org ici... donc en remettre un couche ici ne les informe pas)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tour de contrôle

[marc marc]

Le 22. 11. 18 à 11:31, Dlareg a écrit :
> Le 22/11/2018 à 10:18, Lionel Giard a écrit :
>> Juste pour donner plus d'informations sur les tags utilisés pour le moment.
> 
> Du côté du nombre d'utilisation, rien en permet de trancher réellement :
> 
> 147 tower:type=aircraft_control
> https://taginfo.openstreetmap.org/tags/tower:type=aircraft_control
> 
> 369 service=aircraft_control
> https://taginfo.openstreetmap.org/tags/service=aircraft_control

je pense que cela décrit 2 choses différentes :
- la construction elle-même (même non utilisé, la tour reste la même)
- son utilisation actuelle (le tag usage est régulièrement utilisé
dans d'autre situation)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Amélioration des rendus pour Openstreemap.org - Add render for power portals and insulators

[marc marc]

Le 21. 11. 18 à 11:12, François Lacombe a écrit :
> Une plateforme de test manque clairement pour faire ces propositions de 
> rendus.
> On irait beaucoup plus vite à chaque modification si on avait les moyens 
> de faire un rendu, mais je n'ai pas le temps de maintenir un tel serveur.

rajouter une feuille de style sur l'un des 3 serveurs de rendu osm-fr
me semble (je parle en mon nom propre) tout à fait possible comme 
demande. pour la maintenance, cela peux se limiter à :
- forker le dépôt gravitystorm en osm-fr/openstreetmap-carto-test
- y faire les modifs
ce n'est pas + de travail que ce qu'à fait l'auteur du PR
- synchroniser le serveur avec le dépôt (manuellement ou la nuit)
si ce n'est que cela qui bloque, je veux bien rajouter cela
à ma liste de chose à faire :)

mais quand je vois la divergence entre le rendu osm-fr et osm.org
j'ai l'impression que la tâche chronophage est de regarder chaque mois 
s'il y a des choses à faire pour maintenir les PR non mergé dans le 
dépôt initial qui sont parfois à adapter de temps à autre suite aux 
modifs du dépôt initial.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] compteurs vélo

[marc marc]

Le 21. 11. 18 à 11:04, lau a écrit :
> support : ground

s'il est enterré, il n'est pas posé sur le sol
donc plutôt location=underground

> recording:remote : yes => dans quel cas utiliser celui-ci ?

j'imagine que cela signifie que les données sont envoyé "ailleurs"
par exemple pour être consulté en temps réel via un site web
Par opposition au compteur donc quelqu'un vient récupérer les données
de temps à autre
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Timber Jack

[marc marc]

Le 19. 11. 18 à 11:32, Pub a écrit :
> Je vais essayer de contribuer

bonjour et bienvenue.
si tu as des questions, n'hésites pas
___
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]

Le 16. 11. 18 à 20:27, Jacques Lavignotte a écrit :
>> https://osmose.openstreetmap.fr/fr/map/#item=8190=500=3=9=48.936=2.625==
>>  
> Si les flèches vertes sont des boîtes à Pandores qui manquent, 

oui

> Que puis-je faire pour les mettre à jour ?

si tu utilises josm, il suffit de cliquer sur le lien fix-josm,
cela te créera automatiquement un objet, il ne restera plus qu'à affiner 
la position.
si tu utilises iD (l'éditeur par défaut sur openstreetmap.org)
il faut aller sur openstreetmap.org, repérer l'endroit signalé par 
osmose, zoomer au maximum, cliquer sur éditer, chercher police,
ajouter le poste de police, son nom etc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

[marc marc]

Le 15. 11. 18 à 22:21, Christian Rogel a écrit :
> P. S. : Je n’ai pas pu contacter Operon, car, impossible d’utiliser la 
> messagerie OSM

je lui en ai parlé récemment (probablement un commentaire de changeset)
il m'avait dit qu'il en avait discuté il y a longtemps (et je n'ai pas 
encore pris le temps de lui demander où) et rien n'interdit à qlq de 
documenter les tag qu'il utilise, même si cela aurait été évidement 
mieux (pour la qualité) d'en faire une réflexion à plusieurs.
l'idée mériterait d'être peaufinée mais j'y vois un gros avantage,
celui de simplifier fortement les zones "vitesse par défaut"
c'est d’ailleurs ironiquement ce que je fais dans ma zone de confort,
j'ai un polygone qui regroupe les panneaux + qlq points pour inclure 
toutes les routes, quand j'ajoute des nouvelles routes, je fusionne
mon calque "urbain" et je sais tout de suite quelle route ont besoin
du maxspeed par défaut (parce que les maxspeed non-par-défaut sont
deja tous mapé dans ma zone de confort)
La différence c'est que je n’envoie pas mon calque complet.
mais c'est un gâchis si des utilisations sont trouvées.

donc au lieu de jeter le bébé avec l'eau du bain, je pense qu'il
veux mieux voir 1) qu'est-ce qui ne va pas ? 2) comment corriger ?
si je comprend bien, hormis le côté "individuel", le seul reproche
actuel c'est le fait que le polygone contient d'autre point que
les panneaux alors que sa page wiki ne le précise pas ? cela se
résout en ajoutant sur le wiki "et le nombre minimum de point
nécessaire afin d'inclure les routes (et batiment ?) situées entre
ces panneau dans le polygone formés par les panneaux" ?

l'autre vrai soucis que moi je vois c'est la maintenance
c'est déjà "pas fait" d'avoir le landuse résidentiel qui s'étend
en cas de nouveau bâtiment... alors étendre la zone urbaine quasi
pas utilisée... cela va fatalement cassé (mais facile à détecter)

PS: zone urbaine <> résidentielle .. de nombreuses villes ont une 
étendue différente du landuse résidentielle.. ne fusse qu'à cause
des landuse école, commerce, petite industrie parfois en ville, ...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] traduction building=detached

[marc marc]

Bonjour,

https://wiki.openstreetmap.org/wiki/Tag%3Abuilding%3Ddetached
comment traduire en français en étant le + "international" possible ?
- villa (mais en anglais, un bungalow est aussi dans la catégorie 
"detached")
- villa 4 façades (terme courant en belgique pour faire la différence 
avec les maisons jumellée dite ville 3 façades)
- maison individuelle (mais c'est pas clair qu'une maison mitoyenne
ne fait pas partie de cette catégorie)
- maison isolée (donne l'impression qu'il faut être seul au milieu des 
champs)
- maison mono-familiale ? mais des bâtiments monofamilial ont été 
transformé en bi-familiale sans aucune apparence extérieur... hors
le tag building décrit l'apparence... c'est pas génial d'inclure une 
traduction qui laisse penser qu'on décrit le nombre de foyer)

autre idée ?

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

Re: [OSM-talk-fr] rappel concernant l'élection de OSMF board

[marc marc]

c'est le 17 la date limite pour les candidats (en espérant qu'il y en ai 
pas trop, parce que sinon les votes serront trop dispersés face aux 
"corporate"


Le 15. 11. 18 à 09:26, Christian Quest a écrit :
> On va attendre que les candidatures soient closes, je ne sais pas quand 
> c'est mais ça doit être proche.
> 
> Guillaume, comment sais-tu qu'il y a 76 nouveaux membres français ?
> Où a-t-on accès au détail des membres par pays, voire à la liste des 
> "normal members" ?
> 
> 
> Le mer. 14 nov. 2018 à 20:05, Jarry Philippe  > a écrit :
> 
> Bonsoir
> Je me suis inscrit à la fondation.
> Pour le vote il faudra m’expliquer comment rééquilibrer la gouvernance.
> À bientôt
> Philippe JARRY
> 
> Envoyé de mon smartphone
> Merci d’excuser les éventuelles fautes de frappe.
> 
> Le 13 nov. 2018 à 09:21, Christian Quest  > a écrit :
> 
>> J'ai publié un appel à ce sujet:
>> 
>> https://medium.com/@cq94/48h-pour-r%C3%A9-%C3%A9quilibrer-la-gouvernance-de-la-fondation-openstreetmap-906f3f648d27
>>
>> Relayé sur:
>> - https://twitter.com/cq94/status/1062253323510792192
>> - https://www.facebook.com/cquest/posts/10216217773452785
>>
>>
>> Le lun. 12 nov. 2018 à 20:20, Vincent Privat
>> mailto:vincent.pri...@gmail.com>> a écrit :
>>
>> Je plussoie cet appel.
>> J'ai rajouté récemment sur la page d'accueil de JOSM un gros
>> message incitant les utilisateurs à rejoindre les rangs.
>> Le message est traduit en de nombreuses langues j'espère que
>> ça va aider à renforcer la représentativité de la communauté
>> OSM au sein de la Fondation.
>> A+
>> Vincent
>>
>> Le lun. 12 nov. 2018 à 18:48, Guillaume Rischard
>> mailto:openstreet...@stereo.lu>> a
>> écrit :
>>
>> Je m’excuse, j’avais gardé les membres qui n’ont jamais ou
>> plus payé leur cotisation.
>>
>> Les chiffres corrects du top 10 sont:
>>
>>   20 Australia
>>   21 India
>>   23 Italy
>>   27 Canada
>>   27 Switzerland
>>   28 Netherlands
>>   42 France
>>  116 United Kingdom
>>  201 Germany
>>  384 United States
>>
>> Bonne soirée,
>>
>> Guillaume (Stereo)
>>
>> > On 12 Nov 2018, at 18:38, Guillaume Rischard
>> mailto:openstreet...@stereo.lu>>
>> wrote:
>> >
>> > Bonsoir,
>> >
>> > Si les Français ne s’inscrivent pas pour voter avant le
>> 15 septembre, ils n’auront pas leur mot à dire dans OSM.
>> >
>> > Je ne sais pas si des sociétés US achètent vraiment des
>> votes, mais les chiffres internes de membres par pays
>> montrent qu’on a un gros problème de sous-représentation :
>> >
>> >  58 "Canada"
>> >  73 "Switzerland"
>> >  74 "Netherlands"
>> >  83 "India"
>> > 102 "France"
>> > 318 "United Kingdom"
>> > 470 "Germany"
>> > 845 "United States”
>> >
>> > Alors inscrivez-vous vite sur
>> https://join.osmfoundation.org/normal-membership , c’est
>> important, c'est 20 euros, c’est fait en cinq minutes, et
>> c’est bientôt trop tard pour voter cette année.
>> >
>> > Guillaume (Stereo), candidat à l’élection
>> >
>> >> On 12 Nov 2018, at 17:03, Christine Karch
>> mailto:christ...@hermione.de>> wrote:
>> >>
>> >> Bonjour,
>> >>
>> >> bientôt l'élection de OSMF board aura lieu. Si on veut
>> participer il
>> >> faut être membre de OSMF. Et il faut être membre un
>> mois avant
>> >> l'élection. Comme l'élection est le 15 Décembre 2018,
>> il faut s'inscrire
>> >> avant le 15 Novembre 2018 (si on est trop tard, on peut
>> participer
>> >> l'année prochaine, les élections sont jaque année).
>> >>
>> >> On peut s’inscrire à la Fondation OSM ici (ça coûte £15):
>> >>
>> >> https://join.osmfoundation.org/
>> >>
>> >> Vous trouvez toutes informations sur les dates ici et
>> aussi les candidates:
>> >>
>> >>
>> 
>> https://wiki.openstreetmap.org/wiki/Foundation/AGM18/Election_to_Board
>> >>
>> >> (Je serais heureuse si quelqu'un de la France serais
>> candidat.)
>> >>
>> >> Amicalement,
>> >>
>> >> Christine
>> >>
>> >> 

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

[marc marc]

Le 13. 11. 18 à 11:22, Erik Amzallag a écrit :
> Est-il prévu une analyse Osmose pour vérifier l'absence de doublons dans 
> les ref:FR:GendarmerieNationale en base ?

hier il y avait 8 valeurs multiples
https://taginfo.openstreetmap.fr/keys/ref%3AFR%3AGendarmerieNationale#values
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Defibrilateur qui n'apparaît pas.

[marc marc]

Le 12. 11. 18 à 18:27, Jacques Lavignotte a écrit :
> https://www.openstreetmap.org/changeset/64295794#map=19/46.57820/0.27617

ils ne sont pas rendu sur le style utilisé par osm.org
par crainte de certains que cela sature la carte
https://github.com/gravitystorm/openstreetmap-carto/issues/1603

> Quand je suis en mode EDIT le DAE est visible.

cela te confirme qu'il est bien dans la base :)
d'autre style (osmfr ?) ou d'autre outil (umap ?) peuvent l'utiliser
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rappel concernant l'élection de OSMF board

[marc marc]

Le 12. 11. 18 à 17:03, Christine Karch a écrit :
> Vous trouvez toutes informations sur les dates ici et aussi les candidates:
> https://wiki.openstreetmap.org/wiki/Foundation/AGM18/Election_to_Board
> (Je serais heureuse si quelqu'un de la France serais candidat.)

il y a aussi un problème d'achat de voix par 2 entreprises us au moins, 
non nomée dans osmweekly.
du coup il serrait dangereux de disperser les votes en fonction
de la nationalité et privilégier les idées.
Dans la liste des candidats actuels, je connais Guillaume et Joost comme 
non affecté par ce problème.
Pour les autres, par méconnaissance, je ne me prononce pas.
Mais ce serrait surement utile que quelqu'un se prononce s'il a les 
infos, afin que chacun vote en connaissance de cause.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore les piscines

[marc marc]

Le 10. 11. 18 à 15:18, Paul Desgranges a écrit :
> Récemment aussi tous les 'amenity=swimming_pool' de type nœud 
> (https://overpass-turbo.eu/s/D9Q) ont été migrés vers 
> 'leisure=swimming_pool'. Parfois, c'était des objets qui auraient dû 
> être taggués 'leisure=sports_centre+sport=swimming', en tout cas ceux 
> qui ont un nom https://overpass-turbo.eu/s/Dyk

pour la migration, étant donné que je les ai tous vérifié à la main,
je serrais surpris d'en avoir mal converti.
mais par contre, il existait le même genre de confusion
avec leisure=swimming_pool que avec amenity=swimming_pool
ex https://www.openstreetmap.org/node/2702289118

j'ai décimé une 100aine de faux-bassin
sur le critère site web/téléphone/wikipedia
josm avec le plugin todo est bien pratique
pour les passer en revue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hello OSM world [Poitiers 86]

[marc marc]

Le 10. 11. 18 à 20:13, Jacques Lavignotte a écrit :

> Jacques à proximité de Poitiers (86)

bienvenue :) si tu as des questions, n'hésites pas
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dans quel tag mettre le nom d'une résidence ou immeuble de bureaux ?

[marc marc]

Bonjour,

Le 08. 11. 18 à 22:31, Christian Rogel a écrit :
> une très grande partie des habitations rurales ont un nom et certains 
> craignent que le zèle de la Poste ne contamine les décideurs.
> J’espère que les locaux auront à coeur de mettre ces noms dans OSM, 

Je n’adhère pas à ta logique que je trouve sans rapport.

Si tu habites au no 1 rue de la gare mais que tu n'aimes pas
ton adresse et inscrit sur le bâtiment "42 avenue de la liberté",
ce n'est pas pour autant que cela devient ton adresse postale.
donc si c'est pas ton adresse postale, cela n'a pas sa place
dans les tag addr:* dans osm.

Parce que sinon celui qui fait une application qui récupère l'adresse 
postale du lieu depuis osm, va se retrouver avec une adresse postale
"42 avenue de la liberté" invalide.

C'est exactement la même chose pour les noms des bâtiments.
Tu es libre de mettre un panneau "Résidence de la liberté" sur ta maison
Mais si c'est non-postal, cela n'a pas sa place dans addr:*
Un contributeur peux le renseigner dans name sur le building,
je le fais régulièrement à chaque fois que le bâtiment a aussi un no.

la question n'est donc pas d'ajouter à osm ou pas, mais comment.
la vrai question est donc :
y a-t-il en France des bâtiments ayant à la fois un numéro
et un nom "postal" pour un bâtiment ? si oui, documentons le.
Sinon, comme je le suppose, addr:housenumber et addr:housename
sont mutuellement exclusif comme dans la majorité (tous ?) des pays
et on gagnerait à le préciser sur la page wiki francophone
pour renseigner le prochain qui se posera la question.

> si, une fois de plus, les services publics les laissent tomber.

c'est plutôt une question de savoir qui attribue une adresse postale.
Ce n'est sûrement pas chacun qui choisit la sienne et au facteur à 
savoir que "résidence de la liberté" c'est au no 1.
C'est justement un des rôles d'un(e délégation de) service public, non ?

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

Re: [OSM-talk-fr] Dans quel tag mettre le nom d'une résidence ou immeuble de bureaux ?

[marc marc]

addr:housename et addr:housenumber sont supposé être mutuellement 
exclusif : il y a des endroits oü les bâtiments n'ont pas de numéro
mais un nom utilisé par la poste.

soit t'es passé devant et t'as une idée s'il y avait un no d'immeuble
soit il faudrait regarder la ban ou la bano pour ce bâtiment
pour choisir entre addr:housename et name

de manière totalement subjective, j'ai l'impression que les villes
et les bâtiments récent ont tous un numéro et que le nom est
purement décoratif (=non postal)... mais c'est subjectif :)

Le 08. 11. 18 à 16:52, Topographe Fou a écrit :
> Bonjour,
> 
> Dans le cas où le cadastre précise un nom pour un bâtiment résidentiel 
> ou de bureaux (ou dans le cas où il y a une joli plaque au niveau de 
> l'entrée genre "Villa des Oliviers"), faut-il mettre cette valeur dans 
> 'addr:housename' ou 'name' ou les deux ou une autre ?
> 
> J'ai trouvé les deux pratiques dans OSM et ne trouve pas de réponse 
> claire sur le Wiki (j'ai regardé la page sur les bâtiments, celle sur 
> name, celle que les adresses et celle sur le cadastre).
> 
> Quelques exemples à Rueil-Malmaison :
> https://www.openstreetmap.org/way/71341319
> https://www.openstreetmap.org/way/71341177
> 
> Par avance merci.
> 
> Cordialement,
> 
> LeTopographeFou
> 
> 
> ___
> 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] migrer les amenity=swimming_pool (déprécié)

[marc marc]

J'ai fais la conversion à la main des nœuds (avec de nombreux
messages au contributeur initial vu l'impossibilité de savoir
s'il pensait à une piscine ou un bassin lorsque c'est dans un bâtiment)

Les objections précédentes ayant été toutes traitées à la main,
j'ai fait la conversion mécaniques de ceux qui restaient en France.

Le 31. 10. 18 à 08:26, Noémie Lehuby a écrit :
> Hello,
> 
> Ça me va si on commence par migrer les amenity=swimming_pool en 
> leisure=swimming_pool pour en finir avec ce sujet.
> 
> On a déjà pas mal écumé les faux positifs, et en effet, on va juste 
> transformer un tag faux (amenity=swimming_pool) en un tag qui est 
> seulement potentiellement faux (leisure=swimming_pool à tort).
> 

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

Re: [OSM-talk-fr] maps,me maj des cartes

[marc marc]

Le 05. 11. 18 à 23:18, Vincent de Château-Thierry a écrit :
> j'utilise son pendant pour maps.me ("generator_tool"). Je
> génère des mises à jour quotidiennes de cartes (fichiers souvent
> départementaux) de manière à avoir des données à jour et éviter des
> contributions en doublon. Ca fonctionne bien pour mon usage. Le code
> nécessaire est dispo ici : https://github.com/mapsme/omim

J'ai lu leur longue procédure
https://github.com/mapsme/omim/blob/master/docs/MAPS.md
Mais comment tu réinjectes la carte produite dans l'appli ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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-be] official meeting on November 13th

[marc marc]

Le 27. 10. 18 à 21:34, joost schouppe a écrit :

la traduction des 2 parties :

Salut,

Parce que nous avons envoyé ce message très rapidement (à cause de la 
date limite du 28 octobre), il était seulement en anglais. Le courrier 
d'invitation aux membres sera également en français et en néerlandais. 
Mais comme il s'agit déjà d'une annonce officielle, c'est une bonne 
pratique de fournir des traductions. Je vais le faire maintenant pour le 
néerlandais. Si quelqu'un veut répondre par une traduction en français, 
ce serait génial.
Certaines personnes ont été surprises de ne pas se retrouver sur la 
liste des membres. Ceci est basé sur le formulaire "Join" sur osm.be, et 
a ensuite été nettoyé en demandant aux gens de reconfirmer leur adhésion 
un peu plus tard. Malheureusement, le formulaire d'inscription n'est pas 
disponible pour le moment. Si vous avez des questions ou si vous voulez 
vous inscrire maintenant, veuillez communiquer avec moi ou bo...@osm.be

Un autre point à l'ordre du jour : nous examinons actuellement un projet 
quelque peu formel avec la Croix-Rouge flamande. Ce serait un bon moment 
pour s'assurer que personne ne voit de problèmes avec cela.
Et une correction : nous ne "visons pas une semaine", nous avons déjà 
fixé une date et un lieu : Le 13 novembre au "Markten" à Bruxelles.
--
A l'occasion de la reconnaissance d'OpenStreetMap-Belgium comme un 
représentant local officiel de la Fondation OpenStreetMap, nous avons 
pensé qu'il était temps de penser à nouveau à notre organisation. C'est 
l'heure d'une réunion officielle ! Elle aura lieu le 13 novembre. Vous 
pouvez participer en ligne via le canal Riot spécialement pour les 
réunions : https://riot.im/app/#/room/#osmbe-meetings:matrix.org) ou en 
face à face au café De Markten à Bruxelles. L'idée est qu'il s'agit 
d'une réunion comme les réunions habituelles, mais avec un ordre du jour 
officiel. Toute personne qui est membre (ce qui signifie que vous êtes 
sur cette liste : https://members.osm.be/list.php?lang=fr_US) peut 
voter, et nous pouvons voter sur tout ce qui est à l'ordre du jour. Cet 
ordre du jour doit être clôturé le 29 octobre, alors partagez les points 
à l'ordre du jour dès que possible en répondant ici ou en privé.

Des sujets auxquels nous avons pensés :
 décider d'un code de conduite (proposition disponible sur 
https://github.com/osmbe/working-group-bylaws)

 évaluer le fonctionnement du conseil d'administration : mode de 
fonctionnement, nombre de membres, date des élections ?

 préciser ce que cela signifie d'être membre (exigences minimales, 
mieux expliquer)

 comment avoir plus de membres actifs ?

 les priorités actuelles correspondent-elles à ce que les membres 
veulent ?

 Coopération possible avec la Croix-Rouge flamande

Si vous le souhaitez, vous pouvez vous inscrire via 
https://www.meetup.com/OpenStreetMap-Belgium/events/255829090/
(ou faites-nous le savoir)

Tout le monde est le bienvenu ! Mais pour voter, il faut être membre 
depuis 60 jours. Vous pouvez le vérifier via http://members.osm.be/list.php

Les membres recevront une autre invitation par la poste.

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

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: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[marc marc]

Bonjour,

c'est exact. une licence "non commercial uniquement" n'est
pas compatible avec osm, vu qu'on doit pouvoir utiliser
les données osm aussi dans un cadre commercial.
il faut demander une autorisation spécifique "droit d'utiliser
les données en vue de contrinuer à osm"
de nombreuses sources l'ont accordé mais c'est loin d'être automatique.

Courage :)

Cordialement,
Marc

Le 19. 10. 18 à 22:28, Pierre Béland a écrit :
> Bonjour Claude,
> 
> Je connais peu les relations pour itinéraires de services de transport.
> 
> Le groupe de discussion Import de OSM suit de très près tout import. Et 
> la question de licence c'est toujours très litigieux. Si pas indiqué 
> OdBL, il faut habituellement une autorisation écrite permettant 
> spécifiquement à OSM d'utiliser les données.
> 
> Licences ; À première vue RTL Longueuil et STL Laval ont la même licence 
> avec un libellé indiquant que pas pour fin commerciales
> -> Automatiquement, cela est non conforme à OdBL et donc il faudrait une 
> autorisation écrite
> 
> 
> Pierre
> 
> 
> Le vendredi 19 octobre 2018 13 h 55 min 35 s HAE, Alouette955 
>  a écrit :
> 
> 
> Bonjour,
> Il y a quelques temps je lançais une consultation sur ma proposition 
> d’import pour les arrêts d’autobus du Réseau de transport Métropolitain, 
> maintenant EXO. J’attends incessamment leur autorisation pour l’import 
> avec mention sur la page des contributeurs.
> https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
> Tout commentaire sur ma méthodologie est bienvenue.
> Depuis j’ai compris que EXO, tout comme la STM (Montréal), la STL 
> (Laval) et le RTL (Longueuil) sont des opérateurs distincts mais qui 
> collaborent sous l’égide de l’ARTM. Un peu compliqué mais maintenant 
> clarifié. J’en ai profité pour créer une page pour l’ARTM dans le wiki:
> https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
> La STL et le RTM ont une licence qui me semble beaucoup plus permissive:
> http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/
> https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à 
> l’encadré Conditions d’utilisation)
> Je songe donc les inclure à mon projet d’import sans autre formalité 
> autre de les indiquer dans la page des contributeurs.
> La question est: Aie-je bien compris ces licences?
> Il ne me semble pas que l’import dans la base de données OSM est une 
> utilisation commerciale ou quasi commerciale mais peut-être y a-t-il un 
> précédent qui m’obligerait à obtenir une autorisation spécifique.
> Merci,
> Claude
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> 

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

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