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

[Jérôme Amagat]

Le mer. 9 nov. 2022 à 18:23, Eric SIBERT  a écrit :

> > Ce pont n'est pas coupé par exemple :
> > https://www.openstreetmap.org/way/25086393
>
> Corrigé.
>
> Je suis passé dessus il y a deux ans et j'avais déjà complété les
> limites de vitesse mais pas coupé le pont:
>
> https://www.mapillary.com/app/?pKey=1112286489280438
>
> Après, sur tous les petits détails comme ça, chacun peut déjà corriger
> sans attendre un hypothétique volontaire qui s'occuperait d'une
> correction en masse ;-)
>
> J'aurais pu corrigé mais c'était pour illustrer mes propos :), Il y en a
peut-être d'autres.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

>
> > Normalement les ways des départementales sont coupés à la limite du
> > département mais à vérifier par contre pas obligatoirement les voies
> > communales et pour les départementales, les ponts ne semble pas coupés
>
> Des fois, les ponts sont coupés comme celui-là :
>
> https://osm.org/go/xV97dr~bU-
>
> Mais, s'agissant de chaussées séparées, il est déjà à 90 km/h dans les
> deux départements ;-)
>

Ce pont n'est pas coupé par exemple :
https://www.openstreetmap.org/way/25086393

> Il y a aussi les maxspeed=* des radars sur ces routes à modifier.
>
> Pas pensé. Je vais regarder si c'est important.
>
> > Moi je suis partisan d'une modification de masse, par contre bien faite,
> > récupérer tout les maxspeed=80 sur un département dans JOSM, vérifier les
> > limites du département, vérifier les objets qui ont ce maxspeed=80, ne
> pas
> > modifier les nationales et d'éventuelles voies d'accès aux nationales
> sans
> > ref=*,...
>
> C'est pour ce dernier point que j'ai tendance à privilégier les
> ref="D*". Je vais regarder s'il y a beaucoup de cas à 80 km/h sans ref.
>
> Ce petit pont au milieu d'une départementale n'a pas de ref=* :
https://www.openstreetmap.org/way/161567582
c'est une erreur que personne n'a corrigée et en ne modifiant que les way
en "D XX" ce pont restera à 80, ca ne serai pas bien grave mais autant
s'occuper de lui aussi :)
Un rond point à 80 sur une départementale :
https://www.openstreetmap.org/way/30720308

Il faut faire attention aux limites de département, avec overpass avec "in
Ardèche" j'ai ces 2 ways par exemple (j'ai pas tout regardé) :
https://www.openstreetmap.org/way/366950610
https://www.openstreetmap.org/way/423196543

Il y a aussi des maxspeed dans d'autre tag que maxspeed=*, sur des
départementales d'un département plutôt rural, il y a des chances que l'on
est pas des cas compliqué avec d'autre tag mais pour ne rien oublier il
faudrait vérifier aussi.

>
> > Le Cantal, ça fait 2 ans qu'il est repassé à 90, regarder le nombres de
> > routes départementales encore à 80 dans OSM :
> > https://overpass-turbo.eu/s/1nxF
>
> 93 way à 90 km/h
> 778 way à 80 km/h
>
> Retour au 90, le 1er février 2020, donc on est presque 3 ans après.


> En Ardèche :
> 34 ways à 90 km/h (dont un certain nombre sont des voies à chaussées
> séparées).
> 972 ways à 80 km/h
>
> Surtout, seulement 25% des départementales de l'Ardèche ont des limites
> de vitesse dans OSM. Vivement l'IA avec Mapillary pour nous aider...
>
> Eric
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

Pour les voies communales, c'est pareil que les départementales ou pas ? ne
pas se restreindre au ref avec un D, les rond-point et parfois des voies
d'accès n'ont pas de ref=*
Normalement les ways des départementales sont coupés à la limite du
département mais à vérifier par contre pas obligatoirement les voies
communales et pour les départementales, les ponts ne semble pas coupés
(faire attention lorsque l'on découpe une voie dans Josm que les relation
qui la contienne sont bien chargés).
Il y a aussi les maxspeed=* des radars sur ces routes à modifier.

Moi je suis partisan d'une modification de masse, par contre bien faite,
récupérer tout les maxspeed=80 sur un département dans JOSM, vérifier les
limites du département, vérifier les objets qui ont ce maxspeed=80, ne pas
modifier les nationales et d'éventuelles voies d'accès aux nationales sans
ref=*,...

Sinon se fier au source:maxspeed=*, je ne pense pas que ça soit une bonne
idée, une grande majorité des voies n'ont pas ce tag qui est très peu
utilisé et compris...
Mettre des fixme=*, bof, je trouve régulièrement des fixme=* qui ont plus
de 10 ans... ne rien faire aura pratiquement le même effet.
Les panneaux de limitation à 80 sont très rares, autant tout modifier en
une fois, une petite partie des modifications seront fausses (mais dans la
plupart des cas le maxspeed=80 était une erreur aussi) et pour une grande
majorité des modifications, on aura gagné plusieurs années par rapport à la
solution de laisser les contributeurs modifier au compte goutte.

Le Cantal, ça fait 2 ans qu'il est repassé à 90, regarder le nombres de
routes départementales encore à 80 dans OSM :
https://overpass-turbo.eu/s/1nxF
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

en recherchant des tags utilisés avec taginfo, je trouve des choix fait
dans certains pays pour nommer des forêts :
Aux Pays Bas, on a plus de 700 toponym=forest :
https://overpass-turbo.eu/s/1lJy
En norvège, une cinquantaine de place=woodland :
https://overpass-turbo.eu/s/1lJA

sinon on a 660 natural=forest qui ne sont pas spécialement nommés.
410 boundary=forest pour un tag documenté et il y en a plus de la moitié en
allemagne de l'est qui me semble mal utilisé...

Surpris de ne trouver qu'1 place=forest et 1 place=wood, pour moi, un truc
qui a surtout un nom mais qui regroupe plusieurs choses c'est le tag
place=* même si place est surtout  utilisé sur des nodes en dehors des
islands et islets.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

Le jeu. 8 sept. 2022 à 19:14, Jérôme Amagat  a
écrit :

>
>
> Le jeu. 8 sept. 2022 à 18:25, David Marchal via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Ça risque de faire foirer le rendu, je pense : le motif « arbresque » des
>> forêts va s’afficher deux fois, bonjour le rendu crade…
>>
>> Il y en aura un par dessus l'autre et donc 1 seul visible, je ne sais pas
> lequel ce sera.
>

Désolé je me suis trompé, je pensais que le font vert et les petits arbres
allaient ensemble mais ce n'est pas le cas.
sur le github du rendu ona çà :
https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbols/leaftype_unknown.svg
Donc j'ai cherché un exemple de 2 landuse forest qui se superpose et on a
par exemple ici :
https://www.openstreetmap.org/#map=17/45.49547/3.54268
c'est pas bien beau...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

Le jeu. 8 sept. 2022 à 18:25, David Marchal via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Ça risque de faire foirer le rendu, je pense : le motif « arbresque » des
> forêts va s’afficher deux fois, bonjour le rendu crade…
>
> Il y en aura un par dessus l'autre et donc 1 seul visible, je ne sais pas
lequel ce sera, Il faudrait regarder comment est fait le rendu mais c'est
peut être le plus petit en dernier ou au hasard.
On a des landuse=residential comme partie d'un plus grand pour pouvoir
avoir le nom d'un lotissement, pareil pour des landuse=industral pour
mettre le nom d'une entreprise donc ça ne serai pas le seul endroit où ce
serait le cas.
Par contre c'est pas terrible (c'est pour ça que j'ai mis "Pour moi la
moins mauvaise des solutions") donc quelqu'un passant après peut ne pas le
laisser en l'état et risque de supprimer l'un des 2, les petits ou le grand
landuse=forest.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

Le jeu. 8 sept. 2022 à 17:19, Marc_marc  a écrit :

> Bonjour,
>
> Le 07.09.22 à 21:02, Marc Mongenet a écrit :
> > elation type=site qui représente et fait exactement
> > ce qu'il faut.
>
> https://wiki.openstreetmap.org/wiki/Relation:site#Rationale
> pour les cas oü l'objet ne peux pas être représenté
> par une géométrie ou par des multipolygone :)
> ex : les noeuds d'un parc éolien
>

J'allais faire la même remarque, la relation type=site est une mauvaise
idée. C'est à utiliser seulement si ce n'est pas possible de le représenter
sous forme surfacique. Ici c'est surfacique donc pas de raison de
l'utiliser. Pour moi la moins mauvaise des solutions c'est un
(multi)polygon landuse=forest pour toutes la forêt et d'autres plus petit
avec aussi landuse=forest et leaftype=* si l'on veut que l'on nom
apparaisse sur le rendu sinon boundary=forest mais ca me gene un peu
d'utiliser boundary=* si la frontière c'est juste l'orée du bois...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible

[Jérôme Amagat]

Il me semble que ça n'a pas changé, toutes les adresses de la BAN (avec ou
sans fantoir) sont présentes dans la base qui sert pour BANO, j'avais
proposé une modification du rendu pour faire apparaître aussi les adresses
sans fantoir : https://github.com/osm-fr/bano-cartocss/pull/7
ça date de presque 2 ans, je ne sais pas si ça marche encore, il faudrait
peut être ne les afficher qu'à un fort zoom.

On ne pourrait pas avec la bonne requête sql avoir la liste de toutes les
voies qui n'ont pas de Fantoir et les afficher sur une page de Pifomètre ?

Pour les cle_interop dans osm, plutôt contre surtout pour les adresses sans
code Fantoir vu que lorsqu'elles auront un Fantoir la clé va être modifié
normalement.

Le mar. 6 sept. 2022 à 16:02, Marc_marc  a écrit :

> Bonjour,
>
>
> Le 06.09.22 à 14:47, laurent-38 a écrit :
> > Lorsque que l'on travaille à partir des CSV de la BAN, le champ
> cle_interop est fourni pour chaque adresse.
> > J'ai envie de rajouter cette information aux adresses que j'importe
>
> quel pourrait-être la réutilisation ?
>
> quelqu'un va-t-il chercher la ref 42 au lieu du 1 rue de la gare ?
> j'en doute, on ne s'échange pas la ref pour parler de son address.
>
> quelqu'un voudrait-il sélectionner les addr venant de la ban via osm ?
> hélas rien ne dit que l'objet osm ai les infos de la ban :
> quand un contributeur veux corriger le 1 rue de la gare en 3
> rue de la gare, il édite l'objet et change le 1 en 3 et sauvegarde
> cela sans avoir aucune connaissance qu'il vient de désynchroniser
> no et ref. suffit de de voir qu'il a fallu verouiller
> wikipedia/wikipedia dans certains cas (je crois en cas de name)
> dans ID pour forcer la non désynchro entre les 2
>
> qlq voudrait-il faire un rapprochement en ban et osm sur cette clef ?
> cela risque de faire des erreurs le point précédent.
>
> Cordialement,
> Marc
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible

[Jérôme Amagat]

(Désolé de faire 3 messages...)

Pour les communes avec des voies dans la BAN mais pas dans BANO car pas de
Fantoir, on peut les trouver en regardant la page des stats par commune sur
un département.
Par exemple pour le Cantal (15) :
https://bano.openstreetmap.fr/pifometre/stats_dept.html#dept=15
Regardez la colonne "Adresse BAN sans voie rapprochées", il y a des
communes avec un nombre important.
(Par contre si l'on va sur les voies récentes manquantes du même
département :
https://bano.openstreetmap.fr/pifometre/voies_recentes_manquantes.html#dept=15
Il n'y a que 74 voies manquantes dans osm pour ce département.)
Si l'on clic sur une de ces communes avec beaucoup d'adresses sans voies
rapprochées, par exemple Anglards-de-Salers (c'est la communes qui en a le
plus 744) :
https://bano.openstreetmap.fr/pifometre/index.html#insee=15006=0
Il ne manque qu'un lotissement de 3 adresses.
Le reste des adresses de la BAN que l'on ne voit pas c'est soit des
adresses lié à un lieu dit soit des adresses lié à une rue sans code
Fantoir.
On peut télécharger les données de la commune sur le site
adresse.data.gouv.fr. Pour Anglards-de-Salers la source des adresses est
très majoritairement la commune. On a une centaine de noms de voie
différents dont environ la moitié qui sont en fait des noms de hameaux mais
même les nom de hameau ont pour la plupart leur clé d’interopérabilité qui
n'est pas le code fantoir du hameau)

Dans le Cantal il y a en a quelques unes de communes dans ce cas mais ça
dépend beaucoup du département.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible

[Jérôme Amagat]

Le jeu. 1 sept. 2022 à 19:26, Marc_marc  a écrit :

> Hello,
>
> Le 31.08.22 à 23:50, Vincent de Château-Thierry a écrit :
> > une commune non couverte par Fantoir pour ses voies se retrouve
> > mécaniquement invisible dans BANO
>
> > Suggestions bienvenues !
>
> On n'a qu'à se substituer à l'administration quand
> elle est défaillante :)
> après les adressses fictives, je vous présente naivement :
> les codes fantoir fictifs !
> les ref ci-dessous sont volontairement fantaisiste
> pour exprimer l'idée
>
> Pas besoin de se substituer à l'administration, c'est déjà fait par la
BAN. toutes les adresses de la BAN ont une Clé d’interopérabilité
par exemple "15141_0002_4"  pour le 4 rue de l'Alagnon à
Neussargues-Moissac dans le cantal (on peux aussi avoir
"15141_0002_00025_b"  pour le 25 b de la même rue)
avec insee de la commune _ code de la voie _ numéro dans la voie
les 9 1e chiffres c'est le Fantoir de la voie auquel il manque une clé
calculé.
Si il n'y a pas de Fantoir pour la rue on a par exemple
"15108_zdktl2_2" même chose que précédemment sauf au milieu un code
voie temporaire, il semble faire 6 caractères avec lettre ou chiffre.

Par contre je ne sais pas comment il est déterminé et surtout s'il ne bouge
pas dans le temps.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible

[Jérôme Amagat]

Le mer. 31 août 2022 à 19:19, deuzeffe  a écrit :

> Le 31/08/2022 à 03:59, Jérôme Amagat a écrit :
> > Bonjour,
> > Moi pour gagner du temps, je fait que des copier coller et tout dans le
> > même calque :
>
> Merci pour le tuto. Que je testerai la prochaine fois que je "ferai" une
> commune à FANTOIR renseigné : il me semble que je comprendrai mieux en
> faisant en même temps.
>
> D'autre part, je ne sais pas trop si ta méthode fonctionne lorsque le
> FANTOIR est muet et que donc la couche BANO ne montre pas de rouge à
> dégommer. Je crains que non. Tu confirmes ?
>
> Malheureusement c'est plus compliqué lorsque ce n'est pas présent dans
BANO. On peux utiliser ta méthode pour récupérer les adresses puis en
faisant tout dans le même calque et en mettant toutes les adresses dans le
plugin todo et ensuite grâce à rechercher clé/adresse sur le nom de voie
marqué la sélection dans le plugin et donc marqué toutes les adresse de la
voie.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible

[Jérôme Amagat]

Bonjour,
Moi pour gagner du temps, je fait que des copier coller et tout dans le
même calque :
je télécharge le .csv sur la page de la commune de pifomètre que je mets
dans Josm, ça donne 1 point par rue, je sélectionne tout, je modifie
"Libellé BAN"=* en name=*, je mets tous les points dans le plugin todo, je
mets aussi tous les points dans une relation multipolygone que je mets
aussi dans todo. Une orthophoto et le rendu Bano (le cadastre et le rendu
Bd Topo peuvent servir aussi) et je télécharge les données OSM de la
commune dans ce calque.
Le principe après c'est de passé en revu chaque voie, cliquer sur le name=*
à droite dans les attributs d'un points du csv puis Ctrl+C ( pas besoin
d'ouvrir la boîte de dialogue modifier un attribut) puis Ctrl+V sur la ou
les bonnes voies de osm (les tracer si elles n'existent pas :) ) puis
"marquer" dans todo et au suivant (le plugin todo sélectionne le suivant et
nous amène dessus).
Et à la fin, sélectionner puis supprimer tout ce qui a dans la relation
multipolygone créée au départ, il ne faut pas oublier cette étape ! mais il
y a 2 warnings, d'abord Josm dit que l'envoi de donnée depuis ce calque est
fortement dissuadé car à la base c'est un .csv avec des données extérieures
mais comme toutes ces données ont été supprimées ça ne pose plus de
problème donc on peux continuer et le 2e warning c'est le validateur de
Josm, un multipolygon avec que des points ça n'est pas fermé (il y a aussi
un problème avec les clé présentes sur les points si on ne les a pas
supprimé).

Il ne faut bien sur pas se servir des nodes du csv de départ pour, par
exemple, tracer une voie comme on va tout supprimer à la fin.

À partir de quelques ajout de noms de rue sur une même commune, le temps
perdu au départ et à la fin est vite regagné : pas besoin de déchiffrer le
nom sur le rendu BANO, pas besoin de le récrire, pas besoin d'ouvrir et
fermer une fenêtre pour modifier l'attribut name (pour ça il ne faut pas
d'erreurs dans le nom de voie de la BAN, il manque souvent des accents...),
le plugin todo permet de passer toutes les voies sans en oublier. On peut
modifier le "Code FANTOIR" du csv en ref:FR:FANTOIR si l'on veut copier
aussi le code fantoir sur la voie dans osm. Pour ça on peut sélectionner 2
lignes dans les attributs (name et ref:FR:FANTOIR) et faire ctr+C et ctr+V
sur la voie OSM.

On peut aussi télécharger les .csv sur les pages de Pifomètre top adresses
manquantes et voies récentes manquantes d'un département et faire pareil
(250 noms de voies ça fait beaucoup :P mais on peut en sélectionner un sous
groupe et le copier dans un nouveau calque (ctrl+alt+V dans le nouveau
calque pour coller aux même positions ce qui a été copié dans le 1e calque)
).

Le mar. 30 août 2022 à 18:59, deuzeffe  a écrit :

> Hello,
>
> J'ai brouillonné un petit tuto pour dégommer du rouge avec ou sans
> Pifomètre, ici :
> https://wiki.openstreetmap.org/wiki/User:Deuzeffe/voies-sans-nom
>
> Merci pour vos avis, suggestions, précisions, corrections, etc.
>
> À vos claviers !
> --
> deuzeffe, qui s'en va se vêtir d'une armure anti-atomique, on ne sait
> jamais.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM : SOS raccourci clavier...

[Jérôme Amagat]

Bonjour,
ça m'est déjà arrivé...
C'est le "suivi de la vue", on le trouve dans le menu Affichage ou ctr+maj+F

Le sam. 30 juil. 2022 à 17:59, pepilepi...@ovh.fr  a
écrit :

> Bonjour,
>
> J'ai dû accidentellement heurter un raccourci clavier, maintenant quand
> je crée un chemin, chaque fois que je clique pouir poser un nouveau
> point JOSM déplace automatiquement  ma couche de données pour la centrer
> sur le nouveau point ! C'est monstrueusement chiant !
>
> Quelle est la touche maudite que j'ai invoquée, et comment m'en sortir SVP
> ?
>
> Merci, bon après-midi
>
> Jean-Pierre
>
> --
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> ___
> 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] Education - Comment mapper les ULIS et les SEGPA ?

[Jérôme Amagat]

Moi je préfère un objet surfacique pour les 2 avec ref:uai avec les 2
valeurs séparé par un ;
SEGPA c'est une "section" d'un collège donc 1 seul objet amenity=school.

Le mer. 6 avr. 2022, 18:20, Vincent Bergeot  a écrit :

> Le 06/04/2022 à 07:46, Arnaud Champollion a écrit :
> > Du coup pour l'ULIS il y a un tag déjà ou pas ?
> >
> > Dans le genre
> >
> > fr:ulis=yes
>
>
> je ne sais pas
>
>
>
>
> >
> >
> >
> >
> > Le 06/04/2022 à 07:33, Vincent Bergeot a écrit :
> >> Bonjour Arnaud,
> >>
> >> Segpa, collège. 2 établissements différents (de mémoire souvent
> >> distinct dans l'espace) j'aurai tendance à utiliser un
> >> landuse=education pour l'ensemble et 2 amenity=school distincts pour
> >> chaque établissement.
> >>
> >> Ulis en (primaire, élémentaire maternelle ?). Effectivement plutôt
> >> une 'caractéristique de l'établissement.
> >>
> >> Vincent
> >>
> >>
> >>
> >> Le 6 avril 2022 06:51:42 GMT+02:00, Arnaud Champollion
> >>  a écrit :
> >>
> >> Bonjour,
> >>
> >> Comment mapper un établissement (node) dans un établissement
> >> (surface) ?
> >> JOSM signale comme erreur le fait d'avoir un amenity=school dans un
> >> amenity=school.
> >>
> >> Cas 1 : une SEGPA au sein d'un collège.
> >>
> >> La SEGPA possédant son propre RNE a le statut d'établissement, à ce
> >> titre amenity=school pour la SEGPA et pour le collège.
> >>
> >>
> >> Cas 2 : une ULIS au sein d'une école primaire.
> >>
> >> L'ULIS ne possède pas son propre RNE, du coup je ne sais pas
> >> comment la
> >> qualifier.
> >>
> >> Ou bien un attribut de l'école pour signifier qu'elle dispose
> >> d'une ULIS ?
> >>
> >> Dans ce cas on pourrait étendre aux autres dispositifs comme
> >> UPE2A (pour
> >> les élèves allophones nouvellement arrivés)
> >>
> >> Merci,
> >>
> >> Bonne journée,
> >>
> >> Arnaud
> >> 
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >> 
> >>
> >> --
> >> Vincent Bergeot
> >
>
> --
> Vincent Bergeot
>
>
> ___
> 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] Changements "anciens" de limites communales

[Jérôme Amagat]

En anciennes communes qui ont encore une "existence" aujourd'hui, il y a
les communes qui sont devenues communes associées mais ça date des années
70. Il en manque beaucoup dans OSM.

Le mer. 18 nov. 2020 à 18:48, Christian Quest  a
écrit :

> Le 18/11/2020 à 18:23, Yann-Vari Gwiader a écrit :
> > Bonjour,
> >
> > Avant les incitations récentes aboutissant au regroupement de
> > certaines communes en France, les modifications des délimitations
> > communales ont été des phénomènes courants au XXème siècle. Il
> > s'agissait souvent de regrouper plusieurs communes en une, ou alors de
> > démembrer une ou plusieurs communes pour en créer une nouvelle, ou
> > alors de transferts de bouts de territoires d'une commune à une autre.
> >
> > La page suivante du wiki :
> >
> https://wiki.openstreetmap.org/wiki/Talk:France/Limites_administratives/Tracer_les_limites_administratives#Anciennes_limites_administratives_.28r.C3.A9gion.2Fd.C3.A9partement.2Farrondissement.2Fcommune.29
> >
> > indique : "Il est toujours pertinent de conserver les anciennes
> > limites (en positionnant disused:boundary sur la relation + en
> > complétant par end_date la date de fin de vie de la limite, ainsi que
> > source et source:url pour fournir la référence du changement)".
> >
> > J'ai un certain nombre d'exemples en tête concernant des modifications
> > territoriales de communes qui ont été réalisées dans les années 1950
> > et pour lesquelles des éléments (décrets + indications portées sur le
> > cadastre napoléonien) permettent de reconstituer les changements qui
> > ont eu lieu. Ces éléments ne sont pas, à cette heure, stockés dans
> > OpenStreetMap pour les exemples que j'ai en tête.
> >
> > La question que je me pose est de savoir si le mode opératoire
> > mentionné sur la page wiki ci-dessus est à jour et complet (dans
> > l'hypothèse où l'inclusion de telles informations est validée par la
> > communauté).
> >
> > Merci pour vos éclairages,
> > Yann
>
>
> C'est essentiellement pour les fusions récentes que l'on a conservé les
> limites, je ne pense pas que pour des changements antérieurs (année 50
> !) on ait quoi que ce soit dans OSM en France.
>
> Ajouter ces infos passerait sûrement mal au niveau de la communauté,
> assez attaché à cartographier le monde tel qu'il est et pas tel qu'il
> était il y a 70 ans. On a l'exemple des anciennes voies ferrées ou déjà
> il y a presque une sorte de tolérance à avoir ces tracés alors qu'il n'y
> a plus rien de visible sur le terrain.
>
> Il faudrait voir si Open Historical Map est encore actif et si ça ne
> pourrait pas être ajouté là bas.
>
> --
> 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] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Je suis d'accord, aucune solution n'est parfaite. Mais dire, on supprime
source=* car la source est quelque part dans l'historique de l'objet, je
n'y vois pas la solution miracle, loin de là.

Il faut revenir au sujet de cette discussion, on parle de modifier un tag
sur 1000 objets en France. Est ce qu'au niveau mondial, il a été décidé de
supprimer le tag source=* ? A ma connaissance non.

Je ne vois pas de problème à parler de la façon d'indiquer la source, mais
le principal ici, c'est d'aider David pour son import en se limitant à
l'usage aujourd'hui. Et pour moi, ça veut dire, (toujours pour son
changeset sur les heures d'ouverture), on ne touche pas à source=*, et on
met la source sur le changeset, on peut aussi l'ajouter dans
source:opening_hours=* mais pas d'obligation.

Et si un jour, il est décidé que le tag source=* était superflu, il sera
facile de le supprimer à ce moment-là.

Mon avis sur la façon d'indiquer la source : c'est le truc que je n'aime
pas lors de mes contributions à osm, je sais jamais quoi mettre et où,
surtout que la plupart du temps, je modifie des choses très différentes
avec des sources différentes. Quant tout (ou presque) vient d'une même
source, c'est facile de mettre la source sur le changeset mais c'est pas la
solution la plus simple pour les suivant qui voudrait savoir qui et à
partir de quelle source a été ajouter un tag, "il faudrait" que chaque tag
ait sa source et sa date de modification, c'est la ou le tag source:*=* est
utile mais comme il n'est pas lié au *=*, on peut modifier l'un sans
modifier l'autre et ça complique beaucoup l'édition. "Il faudrait" que
l'éditeur face le gros du travail, si lorsque l'on modifie un tag,
l'éditeur lie au tag la source du changeset et sa date de modification et
que cette info était facile à avoir dans l'éditeur pour les suivant, ça
simplifierait les choses mais il y a toujours le problème des sources
multiples et s'il faut écraser l'ancienne source ou l'ajouter...

Le lun. 16 nov. 2020 à 12:22, Marc_marc  a écrit :

> Bonjour,
>
> Le 16.11.20 à 10:23, Jean-Claude Repetto a écrit :
> > L'indication exclusive de la source sur le changeset n'est qu'un
> > pis-aller,
>
> dr;tl : la "vie" d'un tag source dans les différents cas
> de figure explique mieux les problèmes et les solutions.
>
> version longue :
>
> dans cette discussion, j'ai l'impression qu'il y a une tendance
> à "ce que je fais est parfait, les autres font du mauvais"
> qui ne se base pas assez sur la réalité tant des capacités
> des éditeurs que du comportement réel des contributeurs.
>
> prenons un exemple :
> j'importe un bâtiment à partir du cadastre avec source=cadastre
> sur l'objet building comme jadis et source=cadastre sur le changeset.
> ensuite un autre contributeur modifie la géométrie (la position
> des 4 nœuds) du bâtiment parce que celle du cadastre est erronée,
> ainsi qu'il a pu le constater sur place.
> il modifie aussi building=yes en building=detached
>
> Quel est la source actuelle de l'objet et de sa géométrie ?
> il ne subsiste plus aucune information venant du cadastre.
> toutes les infos de l'objet actuelle proviennent du terrain.
> est-t-on d'accord qu'il ne devrait donc plus y avoir
> aucune trace de source=ccadastre sur la version actuelle ?
>
> voyons ce qui se passe dans la réalité lors de cette modif
>
> 1) AUCUN éditeur à ma connaissance ne va modifier la source
> déclarée sur l'objet sauf intervention humaine spécifique,
> elle va donc se désynchroniser. si quelqu'un se base sur la source
> de l'objet et crois que l'objet actuel vient du cadastre il se trompe.
> à l'inverse tous les éditeurs vont fournir des meta-donées (le
> changeset) puis celui-ci est imposé par l'api.
>
> 2) certains préconisent alors d'ajouter source:geometry
> et source:building. mais là aussi aucun éditeur
> ne les traire comme une meta-donnée. c'est qu'une donnée
> comme une autre, uniquement modifié par intervention humaine
> spécifique. donc cela revient exactement à la même chose que
> le point précédent (source:geometry=cadastre sur l'objet
> ne dit pas que la géométrie actuelle vient du cadastre).
>
> 3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
> d'un tag source sur le changeset. iD le permet aussi.
> tous les éditeurs proposent facilement d'ajouter des sources
> ainsi que l'imagerie sat utilisée pour l'alignement.
> en tout état de cause, la présence de meta-donnée (les tags de
> changeset) sont renseigné par le contributeur de cette modif là
> et concernerait cette modif, donc fiable (quand elle existe)
> pour connaître la source de ces modifs.
>
> 4) le cas d'une session de modif avec plus d'une source.
> certains changeset mixent plusieurs sources
> et mixent donc aussi des âges de source différents.
> Il faut se souvenir que le tag source dans osm permet
> la traçabilité et la communication entre contributeur.
> Pour gérer ces mix, il y a 3 écoles :
> - plusieurs source:tag1 source:tag2 sur l'objet
> Hors on a vu ci dessous que cela ne 

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Le dim. 15 nov. 2020 à 21:57, Éric Gillet  a
écrit :

> Le 15/11/2020 à 17:21, Jérôme Amagat a écrit :
>
>
>
> Le dim. 15 nov. 2020 à 11:04, Éric Gillet  a
> écrit :
>
>> Le 15/11/2020 à 00:57, Jérôme Amagat a écrit :
>>
>>
>>
>> Le sam. 14 nov. 2020 à 21:01, Éric Gillet  a
>> écrit :
>>
>>> Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
>>> > On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
>>> >> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>>> >>>> Et il faut garder les anciennes sources (sauf les anciennes
>>> versions de
>>> >>>> ce que tu importes).
>>> >>>>
>>> >>>> Typiquement tu auras des source
>>> >>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
>>> >>>>
>>> >>>> Il ne fallait pas supprimer la source du bâti (par exemple).
>>> >>> Ah, j'avais mal lu le wiki. Source sur un object c'est historique
>>> mais il
>>> >>> ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
>>> >>> disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
>>> >>> touche pas.
>>> >> Je penses que la phrase du wiki "so don't go around deleting those
>>> >> source tags"/"ne vous précipitez pas pour supprimer ces balises
>>> sources"
>>> >> c'est pour éviter que des contributeurs suppriment/modifient en masse
>>> >> "uniquement" un tag.
>>> > Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
>>> implémenter ça.
>>> >
>>> > Mais depuis j'ai vu
>>> > "Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
>>> supprimer ces marques avant qu'une décision générale du projet décide de le
>>> faire."
>>> >
>>> https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
>>> >
>>> > Et pareil dans la version anglophone, " As usual don't start deleting
>>> those tags unless and until there is a general project decision to do so. "
>>> >
>>> >> [...]
>>> >> La source précédente (celle existante sur l'objet) n'est pas perdue,
>>> >> elle est stockée dans l'historique de l'objet. Tout comme le tag
>>> >> source=* que tu apposes aux changesets.
>>> > Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais
>>> pas aller
>>> > supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé
>>> au niveau du projet".
>>>
>>> Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
>>> horaires :
>>>
>>> - data.gouv.fr:LaPoste - 04/2012 (par exemple)
>>>
>>> La source LaPoste dans le tag source=* ce n'est pas obligatoirement pour
>> les horaires, il y a même de grandes chances que ce soit la source de la
>> position du bureau de poste donc pas de raison de le supprimer si l'on ne
>> change que l'horaire sans déplacer le bureau de poste. Et supprimer la
>> source quand c'est "cadastre", c'est la source de la géométrie du
>> bâtiment, il y a surement beaucoup d'autre source=* différentes, qui
>> peuvent être la source de la position du bureau de poste, du nom du bureau,
>> , du nombre d'étages du bâtiment, de la couleur de ses murs..., de
>> n'importe quel tag sur l'objet ou n'importe quel élément de sa géométrie.
>>
>> Justement on ne peut pas savoir à quoi s'applique le tag source en le
>> laissant. Le laisser lorsqu'on fait des modifs ça veut dire qu'il
>> s'applique également à la version courante de l'objet, alors que c'est pas
>> le cas vu qu'il y a plusieurs autres ajouts avec des sources différentes.
>>
> Les bibliographies à la fin de texte donnent la liste des sources
> utilisées pour réaliser le texte mais chaque source n'a pas servi à faire
> tout le texte et on sait rarement quelle source a servi à faire quoi. Là
> c'est pareil, ce qu'il y a dans source=* a servi à un moment donné à
> ajouter une ou plusieurs infos présentes sur l'objet mais pas moyen sans
> recherche de savoir la ou lesquelles.
>
> OSM c'est une base de données, pas un texte lu par un humain. On sait
> apposer les sources à chaque modification, ça ne me paraît pas comparable.
>

OSM est quand même souvent lu par des humain aussi, surtout le tag
source=*. Comment font les contributeurs pour savoir S'il fau

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Le dim. 15 nov. 2020 à 11:04, Éric Gillet  a
écrit :

> Le 15/11/2020 à 00:57, Jérôme Amagat a écrit :
>
>
>
> Le sam. 14 nov. 2020 à 21:01, Éric Gillet  a
> écrit :
>
>> Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
>> > On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
>> >> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>> >>>> Et il faut garder les anciennes sources (sauf les anciennes versions
>> de
>> >>>> ce que tu importes).
>> >>>>
>> >>>> Typiquement tu auras des source
>> >>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
>> >>>>
>> >>>> Il ne fallait pas supprimer la source du bâti (par exemple).
>> >>> Ah, j'avais mal lu le wiki. Source sur un object c'est historique
>> mais il
>> >>> ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
>> >>> disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
>> >>> touche pas.
>> >> Je penses que la phrase du wiki "so don't go around deleting those
>> >> source tags"/"ne vous précipitez pas pour supprimer ces balises
>> sources"
>> >> c'est pour éviter que des contributeurs suppriment/modifient en masse
>> >> "uniquement" un tag.
>> > Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
>> implémenter ça.
>> >
>> > Mais depuis j'ai vu
>> > "Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
>> supprimer ces marques avant qu'une décision générale du projet décide de le
>> faire."
>> >
>> https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
>> >
>> > Et pareil dans la version anglophone, " As usual don't start deleting
>> those tags unless and until there is a general project decision to do so. "
>> >
>> >> [...]
>> >> La source précédente (celle existante sur l'objet) n'est pas perdue,
>> >> elle est stockée dans l'historique de l'objet. Tout comme le tag
>> >> source=* que tu apposes aux changesets.
>> > Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais
>> pas aller
>> > supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé
>> au niveau du projet".
>>
>> Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
>> horaires :
>>
>> - data.gouv.fr:LaPoste - 04/2012 (par exemple)
>>
>> La source LaPoste dans le tag source=* ce n'est pas obligatoirement pour
> les horaires, il y a même de grandes chances que ce soit la source de la
> position du bureau de poste donc pas de raison de le supprimer si l'on ne
> change que l'horaire sans déplacer le bureau de poste. Et supprimer la
> source quand c'est "cadastre", c'est la source de la géométrie du
> bâtiment, il y a surement beaucoup d'autre source=* différentes, qui
> peuvent être la source de la position du bureau de poste, du nom du bureau,
> , du nombre d'étages du bâtiment, de la couleur de ses murs..., de
> n'importe quel tag sur l'objet ou n'importe quel élément de sa géométrie.
>
> Justement on ne peut pas savoir à quoi s'applique le tag source en le
> laissant. Le laisser lorsqu'on fait des modifs ça veut dire qu'il
> s'applique également à la version courante de l'objet, alors que c'est pas
> le cas vu qu'il y a plusieurs autres ajouts avec des sources différentes.
>
Les bibliographies à la fin de texte donnent la liste des sources utilisées
pour réaliser le texte mais chaque source n'a pas servi à faire tout le
texte et on sait rarement quelle source a servi à faire quoi. Là c'est
pareil, ce qu'il y a dans source=* a servi à un moment donné à ajouter une
ou plusieurs infos présentes sur l'objet mais pas moyen sans recherche de
savoir la ou lesquelles.

> En modifiant le tag opening_hours=*, seule la source dans
> source:opening_hours=* peut être modifiée ou supprimée.
>
> Elle n'est pas supprimée, elle devient non visible dans la version
> actuelle de l'objet. Elle est présente dans l'historique, tout comme les
> tags source dans les changesets, qui sont la façon retenue par la majorité
> des modifications dans OpenStreetMap.
>

La majorité des modifications dans osm utilise encore source=*. Osmose
ajoute source=* et beaucoup de gens l'utilisent toujours.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

[Jérôme Amagat]

La dernière modification supprime aussi les adresses de la BAN sans code
fantoir qui avant apparaissaient en rouge mais sans être entourées de quoi
que ce soit, il y avait juste des points rouge, j'ai fait une proposition
pour qu'il apparaissent d'une autre couleur avec un polygon entourant les
adresses : https://github.com/osm-fr/bano-cartocss/pull/7

Je pense qu"elles sont utiles : des rues pas encore au fantoir ou des
communes qui mettent du temps à mettre à jour leur fantoir mais dont les
adresses apparaissent déjà dans une des sources de la BAN. Il y a par
contre des trucs inutiles comme des erreurs d'orthographe.

Peut être les rendre moins visibles que le rouge qui est BAN avec fantoir
qui est le plus important et qui a de bonne chance d'être une modification
à faire dans osm.

Pareil pour les lieux dit avec adresses, la modif précédente du rendu a
supprimé les pseudo adresses donc il ne reste que des "vrais" numéros. Mais
tout n'est pas utile comme les "Le bourg".

Le sam. 14 nov. 2020 à 19:05, Christian Quest  a
écrit :

> Le 12/11/2020 à 23:01, Christian Quest a écrit :
> > Le 11/11/2020 à 15:35, deuzeffe a écrit :
> >>
> >> Mmmhh, je viens de tester dans ma zone de confort. Il y a des points
> >> rouges qui ne correspondraient pas à la légende donnée ici
> >>
> https://wiki.openstreetmap.org/wiki/FR:France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)#L.C3.A9gende
> >>
> >>
> >> En regardant de plus près, mais rapidement, il reste des 5000 et des
> >> 6000 (marqués en rouge, donc) : à virer ? Et des points adresses
> >> proches d'une highway bien présente et correctement nommée (d'après
> >> ce que je vois) suivant le cadastre/Fantoir.
> >> De plus, les numéros en gris ne correspondent plus à la légende, il
> >> me semble ?
> >>
> >> Échantillon sur demande ;p
> >
> >
> > Suivi...
> >
> > J'ai mis un peu trop vite en place le rendu hier. J'ai fait des
> > modifications aujourd'hui pour revenir à quelque chose de plus proche
> > de ce qu'on avait en v1.
> >
> > Il reste des points d'adresse en rouge sur des lieux-dits qui méritent
> > que je regarde avec vdct de quoi il s'agit. JE pense qu'on a désormais
> > des numéros associés à des lieux-dits, provenant de la BAN ce qu'on
> > n'avait pas avant (de mémoire).
> >
> > Les 5000/9000 provenant du cadastre doivent maintenant avoir disparu.
> >
>
> Suivi suite...
>
> Les points d'adresses numérotées dans les lieux-dits ont été retirés
> temporairement du rendu, le temps qu'on fasse le point sur leur usage
> par BANO (quel mode de rapprochement), leur intégration dans OSM, etc...
>
> Du coup, BEAUCOUP moins de rouge, les rues manquantes sont à nouveau
> bien plus identifiables !
>
> --
> 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] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Le sam. 14 nov. 2020 à 21:01, Éric Gillet  a
écrit :

> Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> > On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
> >> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>  Et il faut garder les anciennes sources (sauf les anciennes versions
> de
>  ce que tu importes).
> 
>  Typiquement tu auras des source
>  source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> 
>  Il ne fallait pas supprimer la source du bâti (par exemple).
> >>> Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais
> il
> >>> ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
> >>> disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
> >>> touche pas.
> >> Je penses que la phrase du wiki "so don't go around deleting those
> >> source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
> >> c'est pour éviter que des contributeurs suppriment/modifient en masse
> >> "uniquement" un tag.
> > Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
> implémenter ça.
> >
> > Mais depuis j'ai vu
> > "Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
> supprimer ces marques avant qu'une décision générale du projet décide de le
> faire."
> >
> https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
> >
> > Et pareil dans la version anglophone, " As usual don't start deleting
> those tags unless and until there is a general project decision to do so. "
> >
> >> [...]
> >> La source précédente (celle existante sur l'objet) n'est pas perdue,
> >> elle est stockée dans l'historique de l'objet. Tout comme le tag
> >> source=* que tu apposes aux changesets.
> > Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais
> pas aller
> > supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé
> au niveau du projet".
>
> Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
> horaires :
>
> - data.gouv.fr:LaPoste - 04/2012 (par exemple)
>
> La source LaPoste dans le tag source=* ce n'est pas obligatoirement pour
les horaires, il y a même de grandes chances que ce soit la source de la
position du bureau de poste donc pas de raison de le supprimer si l'on ne
change que l'horaire sans déplacer le bureau de poste. Et supprimer la
source quand c'est "cadastre", c'est la source de la géométrie du
bâtiment, il y a surement beaucoup d'autre source=* différentes, qui
peuvent être la source de la position du bureau de poste, du nom du bureau,
, du nombre d'étages du bâtiment, de la couleur de ses murs..., de
n'importe quel tag sur l'objet ou n'importe quel élément de sa géométrie.
En modifiant le tag opening_hours=*, seule la source dans
source:opening_hours=* peut être modifiée ou supprimée.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

[Jérôme Amagat]

Pas de réaction hostile sur le robot :D
On pourrait aussi indiquer sur le wiki, que les population=* en France ne
sont connus qu'au niveau communal et donc que les population=* sur les
place=* sont les populations des communes dont ce place=* est le chef lieu.
Pour une grande partie des communes française la population de la commune
et de son chef-lieu est la même ou presque la même. Il y a bien sûr, un
certain nombre de cas où ce n'est pas le cas, pas mal de communes nouvelles
ou les communes issues de regroupement fait depuis les années 70. Il y a
aussi les communes très étendues en zone rurale avec un nombre non
négligeable de gens dans les hameaux entourant le village principal.
Dans osm, le principe c'est d'indiquer des choses plus ou moins
équivalentes de la même façon dans le monde entier. Partout dans le monde,
population=* représente un nombre de personnes sur une surface donnée, plus
ou moins claire suivant le pays, ce n'est pas la population située juste
sous le node place=* :)

Le ven. 13 nov. 2020 à 16:25, Rpnpif via Talk-fr 
a écrit :

> Le 13/11/2020 à 10:16, Vincent de Château-Thierry a écrit :
> > Bonjour,
> >
> >> De: "Christian Quest" 
> >>
> >> Certes, mais ce n'est pas ce que dit le wiki (intl) et ce n'est pas
> >> globalement la pratique, sauf en France. Séparatisme ? ;)
> > Le wiki est un wiki :) On doit pouvoir y indiquer comment ça
> fonctionne en France, tout simplement.
> > Quand je vois les combinaisons du tag population sur Taginfo [1] on a
> plus de 10 "admin_level=*" et plus de 10 "boundary=*". Donc c'est
> loin d'être franco-français.
> >
> > vincent
> >
> > [1] https://taginfo.openstreetmap.org/keys/population#combinations
>
> Bonjour,
>
> Attention aussi, certains admin-centre ne sont pas sur le village ayant
> la plus grande population, donc c'est une mauvaise idée de mettre en
> relief l'admin-centre avec ce critère. Par ailleurs, on attend toujours
> l'affichage des noms des communes nouvelles qui devrait se faire avant
> les anciennes communes membres.
>
> Les départements ne sont pas affichés et ça ne pose de problèmes pour
personne, pareil pour les comcom, les arrondissements départementaux (sous
préfecture) portent aussi pour certains un nom différent de la ville sous
préfecture et ils ne sont pas affichés non plus. Pour beaucoup ces communes
nouvelles reprennent le nom des villages ou ajoutent un terme (région,
rivière...) derrière le nom du village principal. Ça n'apporterait de toute
façon que peu de choses de les afficher.
Pour moi, cette volonté d'afficher leurs noms, c'est un peu comme la
réticence de beaucoup à les créer, les gens pensent que ces communes
nouvelles vont remplacer leur village, que leur village va disparaître
alors que le village et son nom existeront toujours. Il faudra toujours
utiliser le nom du village pour indiquer un lieu. On donne trop
d'importance à ces communes nouvelles. De la même façon que les comcom,
c'est juste plusieurs villes ou villages qui se regroupent pour leur
gestion et bien sûr il faut donner un nom à ce regroupement...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

[Jérôme Amagat]

Donc pour les rendus et pour être en accord avec ce qui est fait ailleurs
dans le monde, il faudrait avoir les populations sur les node place
admin_centre des communes. La seule source fiable pour obtenir ces
populations est, il me semble, l'insee qui sort les populations légales
tous les ans, donc pourquoi pas un bot qui modifierait population=* et
source:pupulation=* des relations des communes et de leurs admin_centre
tous les ans lorsque l'insee sort ces chiffres. Cela permettrait d'avoir
des données tout le temps à jour. Je sais que pour beaucoup les bots c'est
le mal :) mais à part les personnes qui vont compter les habitants de leur
village, ça va être difficile d'avoir une meilleur source.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Jérôme Amagat]

Je sais pas si c'est facile à adapter à ton code mais chaque objet garde la
date de dernière modification (on a pas ce qui a été modifié, ca peut être
n'importe quel tag ou la géométrie), donc peut être modifier les
opening_hours=* existant que si n'a pas été modifié depuis au moins 1 ou 2
ans ..., pour s'adapter aux réticences de ceux qui pense que la source
n'est pas obligatoirement fiable, on peut penser que si le tag
opening_hours=* n'a pas été touché depuis au moins 1 an ou 2 alors les
données osm ne sont pas fiable non plus. Mais je n'ai pas regardé et il est
possible qu'il n'y ai pas beaucoup de bureau de poste non modifier depuis 1
an.

Le mer. 11 nov. 2020 à 22:23,  a écrit :

>
> Le 08/11/2020 à 23:20, David Faure via Talk-fr -
> talk-fr@openstreetmap.org a écrit :
> > Bonjour et merci pour toutes ces réponses !
> >
> > On dimanche 8 novembre 2020 16:43:36 CET
> osm.sanspourr...@spamgourmet.com
> > wrote:
> >>   > (ignore everything after 11:45, that's the max time for sending
> >>> letters, parcels, etc.)
> >> Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
> >> colis même s'il part le lendemain, rencontrer un conseiller.
>
> Je vois qu'Yves avait compris ce que tu veux dire. Ce que je ne
> comprends pas c'est ce que tu dis initialement : on se fiche des heures
> de collectes par rapports aux horaires d'ouverture de la Poste ou de
> l'agence postale.
>
> Oui avançons déjà sur opening_hours. Yves déclinera les collection_times
> (qui sont sans doute plus simples) :-D.
>
> >>   > Detect cases like "every other Saturday", which seems to happen.
> >>
> >> Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?
> > J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au
> changement
> > d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux
> > semaines impaires se suivent.
> > Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
> > est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26,
> > 2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.
> >
> > Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
> > 1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...
>
> Oui mais ça n'arrive que pour quelques bureaux et seulement au dernier
> trimestre.
>
> Même si le rythme quinzomadaire arrive ailleurs aussi (par exemple
> poubelles jaunes dans mon agglo). Donc semaine paire certaines années,
> impaires d'autres, ça n'a pas l'air d'avoir été défini dans opening_hours.
>
> > Les jours fériés je gère déjà [tant que le bureau fait la même chose
> tous les
> > jours fériés...].
> Je pensais bien, restent donc quelques dates vraiment exceptionnels.
> > Oui si j'arrive à tout automatiser, l'import pourrait se faire
> régulièrement.
> > Les données sont pour les 3 prochains mois, mais je ne sais pas si ça
> garantit
> > ces horaires. C'est peu probable (grêves, arrêts maladie, ...).
> Je pense que les grèves, tu n'auras pas (les grévistes n'ont pas à
> prévenir à l'avance). Les arrêts maladie ? Ça n'a apparaitrait que si le
> bureau n'est tenu que par une personne. Et dans ce cas je crains que
> l'info reste coincée aux niveau des RH. Alors des plages horaires
> réduites pour les bureaux de taille moyenne ? Je ne sais.
> >> Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> >> info bulle sur les bureaux avec les horaires actuels, les horaires
> >> déduits et les horaires bruts dont tu pars. Par exemple en important tes
> >> données dans une umap.
> > Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal
> à
> > voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier
> de
> > départ et le fichier de sortie permet de regarder ça. Si c'est pour
> > l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)
>
> C'est bien pour déboguer mais pour que la communauté vérifie.
>
> Bien sûr n'importe qui pourrait si le code est visible de manger le même
> travail de vérification que toi.
>
> umap.openstreetmap.fr, en haut tu te connectes avec ton identifiant OSM.
>
> Tu importes le fichier que tu as généré (csv, geojson, osm,...). Et
> ensuite reste "juste" à formater pour voir les bureaux avec horaires sur
> la carte.
>
> "Juste" c'est dans la couche d'import définir dans les "Options
> d'interaction" le "Gabarit du contenu de la popup".
>
> Et c'est simple :
>
> /Utilisez des variables avec les noms de propriétés de vos éléments
> entre accolades, ex. {name}, elles seront remplacées dynamiquement par
> les valeurs correspondantes./
>
>
>   /Mise en forme du texte/
>
>   * /*simple astérisque pour italique*/
>   * /**double astérisque pour gras**/
>   * /# un dièse pour titre 1/
>   * /## deux dièses pour titre 2/
>   * /### trois dièses pour titre 3/
>   * /Lien simple : [[https://exemple.fr]]/
>   * /Lien avec texte : [[http://exemple.fr|texte du lien]]/
>   * /Image : {{http://image.url.com}}/
>   * /Image avec largeur (en 

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Jérôme Amagat]

Le mer. 11 nov. 2020 à 16:44, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 10/11/2020 à 17:55, Jérôme Amagat a écrit :
> >
> > Si tu attends que tous les bureaux de poste soient present dans osm
> > pour faire ton ajout des heures d'ouverture, tu risque d'attendre
> > longtemps, on voit ici  :
> > http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8020 que les
> > non intégrés ne diminue plus depuis plusieurs mois...
>
> Bonjour,
>
> J'essaie de comprendre l'intégration des bureaux de postes suite aux
> messages échangés. Pas fastoche !
>
> De nombreux bureaux de postes "non intégrés" (dans osmose) sont en fait
> des changements de référence, mais le POI existe.
> exemple :
>
> https://osmose.openstreetmap.fr/fr/error/caf7b4e5-028a-3d50-d98e-4e097d52adb1
> existe bien sur la carte mais avec ref=08912A :
> https://www.openstreetmap.org/#map=19/47.06170/-0.89610
>
> Question 1 : est-ce qu'un item Osmose est capable de détecter (et
> proposer) ces éventuels changements de références ?
>
> J'ai vu qu'Osmose détecte les codes faux et les classe avec les bureaux de
poste sans ref dans "Bureau de poste sans attribut “ref:FR:LaPoste” ou
incorrect"
http://osmose.openstreetmap.fr/fr/map/#item=7050
Par contre j'ai trouvé au moins 2 détections de mauvais code d'après osmose
mais qui apparaissent bien dans le fichier source donc actif
Les bureau de poste d'Ambérieu en bugey (
http://osmose.openstreetmap.fr/fr/error/4692dcb9-d1e0-d41e-f3d8-d1d8d15f4516)
et d'Anglefort (
http://osmose.openstreetmap.fr/fr/error/0a7230a2-d3f6-7908-b180-3245bca4248a)
que l'on voit ici :
http://osmose.openstreetmap.fr/fr/map/#item=7050=11=45.9115=5.6867=1%2C2%2C3==
Il sont bien present dans la source :
https://datanova.legroupe.laposte.fr/explore/dataset/laposte_poincont/table/?disjunctive.code_postal_insee=identifiant_a


> Question 2 : D'autres bureaux de poste (je découvre) sont des
> "post_partner" qui sont dans des magasins, des bureaux tabacs, des
> mairies, etc. :
> exemple :
>
> https://osmose.openstreetmap.fr/fr/error/b610b6d3-6e55-abdc-18c3-e21576754fd3
> dont l'adresse est "Bar tabac Le Crocodile"
>
> Qu'en fait-on de ces derniers, on ajoute un POI post_office dans le
> bureau de tabac ? Ou on ajoute une étiquette post_partner au bureau de
> tabac ?
> En effet ce dernier peut sans doute vendre des boissons, du tabac, du
> service postal voire aussi réparer des clés ? Est-ce logique d'ajouter
> un POI pour le "service postal" qui physiquement est au même endroit que
> la vente de tabac ?
>
> Merci.
> Georges
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Jérôme Amagat]

Osmose permet de détecter des erreurs dans osm et permet aussi d'intégrer
des données en opendata. Il y a déjà la possibilité d'ajouter les bureaux
de poste manquant, d'après osmose il manque plus de 6600 bureau de poste en
la France.
Ce qui pourrait être bien, c'est que osmose propose de modifier les heures
d'ouverture des bureaux de poste déjà intégré mais pour ça il faut créer le
script python qui se servirait de la source en open data sur
datanova.laposte.fr. Osmose retéléchargerait régulièrement la source et
reproposerait d'actualiser les heures d'ouvertures lorsqu'elles sont
modifiés.
Mais osmose c'est du semi automatisé donc il faut que quelqu'un fasse la
mise a jour avec osmose pour chaque bureau de poste donc ça peut être un
complément à l'importation que tu comptes faire mais fait seulement avec
osmose (en supposant que quelqu'un a fait le script python qui va bien) ça
peut prendre des mois (voir des années) a actualiser tous les bureaux de
poste vu qu'il y en a environ 1.

Si tu attends que tous les bureaux de poste soient present dans osm pour
faire ton ajout des heures d'ouverture, tu risque d'attendre longtemps, on
voit ici  : http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8020
que les non intégrés ne diminue plus depuis plusieurs mois...

Le mar. 10 nov. 2020 à 09:32, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> On lundi 9 novembre 2020 21:32:40 CET Frédéric Rodrigo wrote:
> > Si le générateur des horaires d'ouvertures est codé en python
>
> Je connais bien mieux perl que python donc pour l'instant c'est en perl.
> Si quelqu'un veut m'aider à convertir en python... :)
>
> > ça serait bien aussi de l'ajouter à Osmose
>
> Pour refaire l'import en temps réel et voir si ça colle ? Ou bien je pige
> pas
> l'idée ?
>
> C'est peut-être surtout l'autre sens qui serait utile, valider que les
> horaires sont syntaxiquement corrects ? Mais bon ça je compte le faire
> avant
> import de toutes façons.
>
> >
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merg
> > e_poste_FR.py
> >
> http://osmose.openstreetmap.fr/fr/map/#zoom=9=45.215=0.104=705
> > 0%2C8020%2C8021%2C8022=1%2C2%2C3==
>
> Wow, merci pour ce lien. Ça m'explique pourquoi j'ai 17371 identifiants
> différents de bureaux de poste dans les données datanova, alors que la
> requête
> overpass de Jérôme ne me sort que 11503 bureaux avec un attribut
> ref:FR:LaPoste.
> osmose montre que de nombreux bureaux n'ont pas cet attribut, et certains
> ont
> une valeur qui n'existe plus chez laposte (renumérotation ? fermeture ...
> ?).
>
> Et ben c'est pas simple tout ça :-)
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Jérôme Amagat]

Le dim. 8 nov. 2020 à 23:23, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour et merci pour toutes ces réponses !
>
> On dimanche 8 novembre 2020 16:43:36 CET osm.sanspourr...@spamgourmet.com
> wrote:
> >  > (ignore everything after 11:45, that's the max time for sending
> > > letters, parcels, etc.)
> > Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
> > colis même s'il part le lendemain, rencontrer un conseiller.
>
> Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
> Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> ne vont pas dans opening_hours, donc je les considère hors périmètre.
> C'est déjà assez compliqué comme ça :-)
>
> > Ne pas confondre avec collection_times
> > https://wiki.openstreetmap.org/wiki/FR:Key:collection_times
>
> Oui, c'est pas ça non plus, je suis d'accord.
>
> >  > Detect cases like "every other Saturday", which seems to happen.
> >
> > Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?
>
> J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au
> changement
> d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux
> semaines impaires se suivent.
> Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
> est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26,
> 2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.
>
> Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
> 1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...
>
> >  > Decide whether to add specific single-date exceptions to the OSM
> > > opening hours or to just ignore them. Do we want this level of detail?
> >
> > Il y a deux types d'exceptions : les jours fériés et les jours vraiment
> > exceptionnels.
>
> Les jours fériés je gère déjà [tant que le bureau fait la même chose tous
> les
> jours fériés...].
>
> > Rien contre indiquer les jours vraiment exceptionnels mais il faut alors
> > être sûr que la mise à jour soit régulière. Avoir mettons une journée
> > dans le passé pourrait faire conclure à des horaires non actuels.
>
> Oui si j'arrive à tout automatiser, l'import pourrait se faire
> régulièrement.
> Les données sont pour les 3 prochains mois, mais je ne sais pas si ça
> garantiopening t
> ces horaires. C'est peu probable (grêves, arrêts maladie, ...). Du coup
> d'une
> semaine sur l'autre, les horaires prévisionnels pour "dans 2 semaines"
> pourraient changer. Donc en toute théorie il faudrait importer tous les
> jours,
> LOL. Mais bon déjà si c'est une fois par mois ça me semble pas mal.
>
> > Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> > info bulle sur les bureaux avec les horaires actuels, les horaires
> > déduits et les horaires bruts dont tu pars. Par exemple en important tes
> > données dans une umap.
>
> Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal à
> voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier
> de
> départ et le fichier de sortie permet de regarder ça. Si c'est pour
> l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)
>
> >  > and new post offices
> >
> > Et surtout ceux qui disparaissent (c'est plus fréquent).
>
> Hmm, je veux mettre à jour les horaires, pas supprimer des bureaux de
> poste,
> ça semble dangereux et hors périmètre :-)
> Je pense que la création et la suppression seraient plutôt à faire à
> partir
> d'une autre source de données, la liste des bureaux de poste
> https://datanova.laposte.fr/explore/dataset/laposte_poincont2/
> Mais ça je laisse volontiers à quelqu'un d'autre...
>
> > Horaires : oui on a le droit d'ajouter/modifier des horaires, on met en
> > général un source=La Poste, 2020-11-08 (histoire de savoir d'où ça vient
> > et de quand ça date).
>
> Dans le changeset, j'imagine. OK.
> Pas de mention de l'outil d'importation, au cas où quelqu'un veuille
> remonter
> à comment un mauvais import a eu lieu ?
>
> > Mais dans un premier temps détecter les différences c'est déjà un bon
> > point pour savoir ce qu'il y a à vérifier.
>
> Je ne suis pas sûr de ce que tu veux dire par là.
> Si l'outil détecte une différence entre OSM et datanova, j'imagine que
> datanova est plus fiable, mais c'est pas en comparant 08:00 et 09:00 qu'on
> saura qui a raison. Il faut aller voir les horaires sur la porte, mais la
> France c'est grand et on est confinés :-)
>
> Mais oui pour commencer c'est plus sûr de ne rien écraser.
>
> > Pages éventuellement à compléter par la suite :
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue
>
> Ah oui, j'ai vu cette page, mais je ne comprends pas bien la différence
> entre
> ses sections. Les imports ne sont-ils pas tous "communautaires" ?
>
> > https://wiki.openstreetmap.org/wiki/Contributors#France
>
> Merci pour l'info, c'est noté aussi.
>
> > Pour les imports, on va sans doute te conseiller de faire tes tests avec
> > JOSM
>
> OK.
>
> > mais pour la mise à jour 

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

Le lun. 5 oct. 2020 à 22:55, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 5 oct. 2020 à 20:09, Frantz  a écrit :
> >>
> >
> > Présent. Modifications suite à une discussion bien nourrie ici même dans
> laquelle tu étais intervenu, et pour ma part modifications qui ne faisaient
> que mettre la page FR en concordance avec la page anglophone. Comme déjà
> expliqué ici.
>
> Non, cela allait plus loin, puisque cela consacrait que la RF avait un
> usage propre.
>
>
> > On peut recommencer une fois de plus la discussion, mais je ne pense pas
> qu'il y aura plus de soutiens pour "école = lire, écrire, compter" que pour
> "école = éducation formelle ».
>
> J’ai assez de connexions avec les maternelles (enfants, ensegnants) pour
> estimer que la formalisation de la pédagogie en  maternelle n’a en rien
> changé sa position par rapport au CP.
>
> >
> >> [...]
> >> A quoi ça rime ?
> >
> > À essayer de faire avancer un sujet qui bloque depuis des années sans
> autre raison que "c'était comme ça dans le temps" (reprendre la dernière
> discussion pour voir à quand ça remonte !) ?
>
>
> Ne pas méprendre sur la remarque qui concerne la méthode de recueil de
> l’avis dominant : je n’avais rien vu de conclusif dans une discussion
> rassemblant un nombre limité de gens.
> Personne n’avait dit comment on allait y arriver.
>

> Pas vu quand il y avait eu un signal pour matérialiser une « décision ».
> C’est ça qui me semble étrange.
>

C'est rare les fois où sur cette liste, il y a, comme résultat de la
discussion, une décision claire. Même pour les discussions sur "Comment
taguer tel truc compliqué", le "résultat" de la discussion n'apparaît que
rarement sur le wiki donc se perd dans les limbes des archives de la liste
avec 1 ou quelques éléments tagués.


> J’avais mentionné qu’un vote pourrait avoir lieu, mais, ça n’a intéressé
> personne.
> La prochaine fois, j’ exigerai qu’on s’accorde là-dssus avant toute
> discussion commençant à se solidifier.
>
> Le problème d'un vote c'est qu'il faut quelqu'un pour l'organiser et si
l'on veut la meme chose que pour les propositions de nouveaux tags, il faut
y mettre du temps et de l'énergie.
Sinon, on organise un vote rapide, sur la page de discussion de
amenity=school ou kindergarten en français, 2 ou 3 lignes pour dire que
c'est un vote pour ou contre ameity=school pour les écoles maternelles et
on donne 1 semaine aux personnes de cette liste pour aller voter oui ou non
en dessous.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

Le lun. 5 oct. 2020 à 00:38, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> > Le 4 oct. 2020 à 22:49, osm.sanspourr...@spamgourmet.com a écrit :
> >
> > Christian veut de l'international ? isced:level
> >  répond à ce
> besoin.
>
>
> Donc « primary + isced = 0 ». Est-ce cohérent ?
>
>
> > > ça ne change rien au débat La maternelle est-elle pre-school ou non ?
> >
> > La clé pre-school n'existe pas. CQFD ;-).
>
>
> Exact, j’ai mis un trait-d’union imaginaire. Au temps pour moi.
>
> Il y a 1877 preschool dans la BDD , dont 1679 preschool = yes qui sont
> combinées avec 1835 amenity = kindergarten (c’est suggéré dans le wiki
> anglophone).
>
> preschool se trouve concentré en Europe, sauf Sud  N GB et Scandinavie.
>
> La phrase du wiki anglophone : "In 2016 it was proposed to add sub-tags
for the three age categories, nursery=yes, preschool=yes and
after_school=yes."
c'est tout, pas de lien vers cette proposition ou une discussion, pareil
pour la page preschool=* créé en 2017 et pas modifié depuis. Comme pour les
changements sur les pages fr de amenity=school et amenity=kindergarten qui
vous pose problème.

Et 1877 preschool dans le monde vu les 258000 amenity=kindergarten ça fait
pas beaucoup, il doit y avoir plus d'écoles maternelles en France avec
amenity=school.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

J'ai modifié les pages fr amenity=school
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool et
amenity=kindergarten
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dkindergarten pour
mieux séparer l'usage en France du reste du monde. N'hésitez pas à corriger.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

Le ven. 2 oct. 2020 à 10:01, Vincent Bergeot  a écrit :

> Le 02/10/2020 à 03:19, Jérôme Amagat a écrit :
>
>
> Vincent, tu me fais prendre conscience du fait que des changements
>> importants sur le wiki en français peuvent opérer par un seul contributeur
>> sans aucun mandat moral de la communauté francophone.
>> Où on s’aperçoit que les Belges, les Canadiens et les Suisses ne sont
>> guère intéressés par ce qui y est écrit.
>>  Rappel : les pages FR: du wiki ne conernent pas que la République
>> française.
>>
>> Oui peu de contributeur sur le wiki fr (et je pense sur toutes les
> langues) donc une modification peut prendre une grande ampleur.
> Mais ici le sujet des maternelles a été plusieurs fois abordé sur cette
> liste et à chaque fois, il me semble, la discussion va vers le fait que
> amenity=kindergarten n'est pas adapter aux écoles maternelles françaises et
> que amenity=school plait plus.
>
> je n'ai pas caché mon désaccord, mais maintenant il s'agit de transformer
> ce "choix" et que id, josm, osmose et les autres usages sachent parler le
> français -> et effectivement, comme souligné par Christian, je n'ai pas vu
> le sujet sur la liste talk (ce qui ne veut pas dire qu'il n'a pas été
> débattu, difficile de tout suivre)
>
Voila 2 discussions où le sujet a été abordé :
https://lists.openstreetmap.org/pipermail/talk-fr/2019-September/094299.html
https://lists.openstreetmap.org/pipermail/talk-fr/2020-May/098822.html

>
> Je suis d'accord que les tags osm sont internationaux mais il faut bien
> les adapter à chaque pays et la communauté française peut juger que
> amenity=school c'est de la maternelle au bac et amenity=kindergarten c'est
> les crèches et autres garderies de jeunes enfants comme des choix ont été
> fait pour les niveau administratif admin_level=*.
>
> oui, pour moi l'adaptation c'était school:fr=* justement et ou le
> isced:level
>
>
> Si l'on regarde cette source :
> https://data.education.gouv.fr/explore/dataset/fr-en-annuaire-education
> où il y a une colonne pour indiquer que l'école à des classes de
> maternelle et une autre pour dire qu'elle a des classes élémentaires, il y
> a, sur 50632 écoles, 13670 écoles seulement maternelle, 12027 seulement
> élémentaire et 24934 où il y a les 2, les écoles primaires. donc si l'on
> reste comme jusqu'à maintenant (kindergarten pour les maternelles et school
> pour les élémentaires et primaires) il n'y a, en fait, qu'environ un tiers
> des écoles maternelles en amenity=kindergarten le reste est à l'intérieur
> de school.
>
> je suis assez surpris par ces chiffres et comme discuté avec les gens de
> l'annuaire, il y a beaucoup aujourd'hui d'école "primaire" qui sont en fait
> des élémentaires mais aussi des doublons à priori :) d’où le terrain
> évidemment !
>
Moi, ce que je vois, c'est qu'en ville, il y a, le plus souvent, une école
maternelle et une école élémentaire séparés mais dans les villages qui sont
très nombreux en France, il n'y a qu'une école primaire.

>
> Je ne connais pas les systèmes éducatifs à l'étranger mais quand je
> regarde https://en.wikipedia.org/wiki/Kindergarten , je me dis qu'il y a
> peut être un problème dans le choix du mot kindergarten. ça dit que
> kindergarten est peu utilisé en uk alors que c'est normalement l'anglais uk
> qui est utilisé dans osm et pour les usa, c'est seulement l'année précédant
> l'entrée à l'école et non tout le préscolaire comme le dit le wiki osm.
>
> oui cela dit aussi que c'est utilisé dans de nombreux pays pour une
> variété d’institutions éducatives et d'espaces d'apprentissages pour des
> enfants de 2 à 6 ou 7 ans (Today, the term is used in many countries to
> describe a variety of educational institutions and learning spaces for
> children ranging from 2 to 6 or 7 years of age, based on a variety of
> teaching methods. )
>
> et qu'en France c'est nommé école maternelle (In France, pre-school is
> known as *école maternelle) :
> https://en.wikipedia.org/wiki/Kindergarten#France
> <https://en.wikipedia.org/wiki/Kindergarten#France>*
>
" pre-school is known as école maternelle" et non "kindergarten is known as
école maternelle".
Le problème c'est que dans cette page, il y a une liste de pays mais
beaucoup comme la France n'utilise pas le terme "kindergarten".
Ce que je comprends sur cette page, c'est que le terme kindergarten, quand
il est utilisé, c'est pour l'année voir les 2 années avant l'entrée à
l'école.
En France, les école maternelles c'est les 3 ans avant l'élémentaire donc
ça irait presque mais on utilise le terme "école" qui est traduit "school"
en anglais, souvent dans le même lieu que l'école élémentaire, les instits
ont la même formation et sont inte

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

> Vincent, tu me fais prendre conscience du fait que des changements
> importants sur le wiki en français peuvent opérer par un seul contributeur
> sans aucun mandat moral de la communauté francophone.
> Où on s’aperçoit que les Belges, les Canadiens et les Suisses ne sont
> guère intéressés par ce qui y est écrit.
>  Rappel : les pages FR: du wiki ne conernent pas que la République
> française.
>
> Oui peu de contributeur sur le wiki fr (et je pense sur toutes les
langues) donc une modification peut prendre une grande ampleur.
Mais ici le sujet des maternelles a été plusieurs fois abordé sur cette
liste et à chaque fois, il me semble, la discussion va vers le fait que
amenity=kindergarten n'est pas adapter aux écoles maternelles françaises et
que amenity=school plait plus.

Je suis d'accord que les tags osm sont internationaux mais il faut bien les
adapter à chaque pays et la communauté française peut juger que
amenity=school c'est de la maternelle au bac et amenity=kindergarten c'est
les crèches et autres garderies de jeunes enfants comme des choix ont été
fait pour les niveau administratif admin_level=*.
Si l'on regarde cette source :
https://data.education.gouv.fr/explore/dataset/fr-en-annuaire-education
où il y a une colonne pour indiquer que l'école à des classes de maternelle
et une autre pour dire qu'elle a des classes élémentaires, il y a, sur
50632 écoles, 13670 écoles seulement maternelle, 12027 seulement
élémentaire et 24934 où il y a les 2, les écoles primaires. donc si l'on
reste comme jusqu'à maintenant (kindergarten pour les maternelles et school
pour les élémentaires et primaires) il n'y a, en fait, qu'environ un tiers
des écoles maternelles en amenity=kindergarten le reste est à l'intérieur
de school.

Je ne connais pas les systèmes éducatifs à l'étranger mais quand je regarde
https://en.wikipedia.org/wiki/Kindergarten , je me dis qu'il y a peut être
un problème dans le choix du mot kindergarten. ça dit que kindergarten est
peu utilisé en uk alors que c'est normalement l'anglais uk qui est utilisé
dans osm et pour les usa, c'est seulement l'année précédant l'entrée à
l'école et non tout le préscolaire comme le dit le wiki osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Jérôme Amagat]

Si on est d'accord que les écoles maternelles doivent être des
amenity=school et non des amenity=kindergarten, je pense qu'il faut migrer
en un changeset les amenity=kindergarten school:FR=maternelle vers
amenity=school school:FR=maternelle. Et il faut modifier l'analyse osmose (
https://github.com/osm-fr/osmose-backend/blob/cb5e3a1f387851f4ac424a612c9eaddcf4685637/analysers/analyser_merge_school_FR.py)
pour qu'elle ne s'occupe plus que des amenity=school.

Il y a aussi comme erreur signalée (
https://github.com/osm-fr/osmose-backend/issues/909) les noms d'écoles qui
sont des descriptions et non des noms.

Je propose ces changements pour l'analyse osmose mais je n'ai pas testé si
ça marche :
https://github.com/osm-fr/osmose-backend/pull/983

Il y a aussi le problème primaire ou élémentaire, la source n'est pas très
claire donc difficile de savoir si il faut school:FR=primaire ou
school:FR=élementaire...

Le lun. 28 sept. 2020 à 18:18, Vincent Bergeot  a
écrit :

> Le 27/09/2020 à 11:22, Frédéric Rodrigo a écrit :
>
> Bonjour,
>
> La liste des signalements de dysfonctionnement d'Osmose à propos des
> écoles en France ne fait que s'allonger. Mais personne ne traite le sujet.
>
> https://github.com/osm-fr/osmose-backend/issues
>
> Le sujet de l'éducation intéresse ici du monde. Si quelqu’un veut bien
> regarder ça. Il faut faire le point sur les issues dans github et les
> analyses Osmose. Puis proposer les corrections qui vont bien dans les
> analyses Osmose (modification du code ou au moins signaler quoi changer
> où).
>
> Bonjour,
>
> je veux bien y regarder, sachant donc que le choix discuté ici est de
> transformer les écoles maternelles ayant "amenity=*kindergarten*" (avec
> soit maternelle dans le name, soit school:FR=maternelle, soit
> reconnaissance terrain) en amenity=*school* et school:FR=maternelle. Il
> s'agit de ne pas transformer les amenity=kindergarten correspondant à des
> crèches en school :)
>
> On garde le school:FR avec maternelle, élémentaire, primaire (3 "formes
> différentes" maternelle=Petite Section -> Grande Section,
> élémentaire=CP-CM2, primaire:PS -> CM2) / j'ai demandé des précisions à
> l'éducation nationale car même sur le site annuaire de l'éducation
> nationale il y a des contradictions.
>
> On voit comment la ref:UAI arrive à se glisser la dedans.
>
> Merci Frédéric du signalement
>
> --
> Vincent Bergeot
>
> ___
> 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] Tags addr: pour les radars

[Jérôme Amagat]

avec les addr:* (pas besoin de bbox) :
[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
relation ["addr:country"="FR"] [type=enforcement] [enforcement=maxspeed];
out;
https://overpass-turbo.eu/s/XMY
la response est quasi instantanée :)

par contre la solution donnée :
[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
node(r:device);
out;
ne donne que les infos de "node(r:device);" dans le csv donc seulement les
coordonnées.

comme ça (j'ai rajouté dans le csv les même colonnes que dans la 1e
requête, certains radars ont encore les addr:*) :
[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
out center;
https://overpass-turbo.eu/s/XN6
on a les infos des relations et les coordonnées du "centre" de la relation
, pas obligatoirement dans la même commune que le radar, mais je ne sais
pas comment faire une sortie avec les coordonnées du "device". Et si il a
besoin des adresses, je ne sais pas non plus...


La position des radars est presente sur
https://radars.securite-routiere.gouv.fr/ , mais pas moyen de trouver les
données "brute".
Quelqu'un semble avoir recuperer les données du site :
https://www.data.gouv.fr/fr/datasets/radars-automatiques/

On peut lire en bas de la page https://radars.securite-routiere.gouv.fr/,
"Les données radars sont affichées à titre indicatif et mises à jour
régulièrement : date de mise à jour le 06 novembre 2018" :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort?

[Jérôme Amagat]

Vous vous faite du mal à répondre à Philippe, ça ne sert à rien. Ça fait
plusieurs années que je lis ce qui se dit sur cette liste et il est
coutumier de ce genre d'intervention, il ne faut pas y faire attention et
même ne pas le lire, vous vous en porterez que mieux :)

J'ai quand même survolé ce qu'il a dit et j'ai tapé "bano" dans google et
le 1er résultat c'est data.gouv.fr (
https://www.data.gouv.fr/fr/datasets/base-d-adresses-nationale-ouverte-bano/
)
sur cette page beaucoup de date 2014 à 2016. Dans "Origine des données",
les dates pourrait faire croire qu'il n'y a eu aucun ajout d'adresses
depuis 2016, je pense qu'il faudrait supprimer ces dates inutiles. Même
chose pour "Historique du jeu de données" qui ne parle que de 2014. Et des
questions de 2019 n'ont aucune réponse.

Sur google, après data.gouv.fr, c'est  http://prev.openstreetmap.fr/bano
(aussi indiqué sur la page data.gouv.fr), la partie "Les news..." datent de
plusieurs années ça fait pas très "news". rebaptiser "historique", ajouter
des news plus fraîches ?
Et dans les liens au dessus, "graphes d'évolution du contenu" ne mène à
rien et il faudrait indiquer que le rendu est temporairement indisponible.

Ces petits changements ferait moins "mort"
Et ne vous embêtez pas à chercher à discuter avec Philippe...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Jérôme Amagat]

Le dim. 9 août 2020 à 23:18, Christian Quest  a
écrit :

> Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :
> >>>
> >>> Les mers, baies et détroits (place=sea, natural=bay, natural=strait)
> >>> en surfacique pourraient avoir leur nom qui apparaissent pour les
> >>> mer et détroit et plus tôt lorsqu'ils sont très grands pour les
> >>> baies qui sont déjà rendu.
> >>> exemple : le golfe du lion
> >>> https://www.openstreetmap.org/relation/9287303
> >>>
> http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B
> >>>
> >>
>
> Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu
> FR :)
>
>
> Très jolies toutes ces améliorations !
Par contre les grands lacs ont disparu à faible zoom
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#6/42.383/-80.607

Dans les zones où la forêt est decoupé en carré, il y a un effet
"quadrillage" pas très beau
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#9/-0.0316/-68.0836
Il y a aussi les aérodromes qui ne sont pas rendu aeroway=aerodrome
Les frontières qui n'apparaissent pas si elle n'ont pas de tag
boundary=administrative

Il y a un problème, non lié au rendu avec des landuse=landfill au nord de
la Russie. Des déchets nucléaires immergés ne font pas de la zone une
décharge...

Moi ça ne me gêne pas tous ces noms de villes et villages, (sauf en chine ,
trop de noms et de points noirs car trop de villes très peuplées, avec des
noms en anglais un peu plus long, il y en aura un peu moins). Par contre
les hameaux et quartiers, je les trouvent écrit trop petit, difficiles à
lire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Jérôme Amagat]

Tout d'abord, merci pour ce très beau rendu !

Plusieurs améliorations possibles :

Les aires d'autoroutes highway=services ne sont pas rendu contrairement au
aires sans service highway=rest_area
exemple : https://www.openstreetmap.org/way/125646404
http://tile.openstreetmap.fr/?zoom=17=45.84394=5.07038=B

Les barrage non plus, pas rendu waterway=dam, il y a seulement le nom qu
apparaît.
exemple : https://www.openstreetmap.org/way/37953758
http://tile.openstreetmap.fr/?zoom=15=45.22418=6.95203=B

Les rivières waterway=river sans natural=water ou waterway=riverbank
n'apparaissent qu'au zoom 15 ce qui est tard, il me semble.
exemple : https://www.openstreetmap.org/way/30785271
http://tile.openstreetmap.fr/?zoom=14=42.6065=8.9894=B

Il y a des déserts en natural=desert et en natural=sand pour les déserts de
sable, a faible zoom il sont rendu de la même façon mais à partir du zoom 8
les natural=sand disparaissent. Et il serait intéressant que leur noms
apparaissent aussi et peut être une couleur un peu différente ?
exemple : https://www.openstreetmap.org/way/232227949
http://tile.openstreetmap.fr/?zoom=8=30.16904=0.24451=B

Les mers, baies et détroits (place=sea, natural=bay, natural=strait) en
surfacique pourraient avoir leur nom qui apparaissent pour les mer et
détroit et plus tôt lorsqu'ils sont très grands pour les baies qui sont
déjà rendu.
exemple : le golfe du lion https://www.openstreetmap.org/relation/9287303
http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B

Truc plus compliqué et je ne sais pas si c'est possible C'est un rendu
fr, mais n' y a pas de name:fr partout :) et les noms sont illisibles pour
la plupart des francophones lorsqu'il sont dans un autre alphabet, par
contre les noms en anglais sont beaucoup plus présent et sont souvent les
même que les français, serait il possible de faire apparaître les noms en
anglais lorsque le name=* est dans un autre alphabet que l'alphabet latin
et qu'il n'y a pas de name:fr ? Je pense surtout au noms des villes et
régions en Chine, Japon, Thaïlande, pays arabe... mais aussi l'europe de
l'est et la Grèce avec leurs alphabet plus proche du nôtre mais difficile à
lire pour la plupart des francophones.
Je ne sais pas si c'est possible de trier par alphabet ou par pays.

Le sam. 1 août 2020 à 17:38, Christian Quest  a
écrit :

> Le 26/07/2020 à 23:53, Christian Quest a écrit :
> > Moins de trafic aussi sur les serveurs de l'asso alors c'est le moment
> > des chantiers !
>
> Le chantier continue avec la remise à jour des limites terre/mer et
> l'occupation des sols à petite échelle...
>
>
> Limites terre/mer :
>
> Les natural=coastline mises bout à bout forment d'immenses polygones qui
> sont nécessaires pour avoir la mer en bleu et la terre dans une couleur
> claire par défaut.
>
> Ces polygones sont relativement coûteux à calculer, car composés de très
> nombreux noeuds. Ils sont gigantesques car couvrant des continents entiers.
>
> Du coup, ils sont calculés de temps en temps et mis à disposition sur
> https://osmdata.openstreetmap.de/ sous une forme découpée (oui, façon
> puzzle) avec une version aux géométries simplifiées adaptée aux petites
> échelles.
>
> Les derniers fichiers shapefile dataient de janvier et ils ont été remis
> à jour hier.
>
> Pour le rendu FR, j'en ai profité pour changer la logique car depuis
> toujours, on mettait un fond bleu par défaut et on dessinait les
> continents par dessus.
>
> Or... on calcule bien plus souvent des tuiles sur terre que sur mer,
> donc autant avoir ça de moins à dessiner dans la majorité des cas même
> si c'est sûrement négligeable.
>
>
> L'occupation des sols à petite échelle :
>
> Pour les premiers niveaux de zoom, le rendu FR affiche l'occupation des
> sols (landuse=*). Le problème ici c'est le très grand nombre de
> polygones, parfois très petits et non visibles à ces échelles.
>
> Il y a quelques années, j'avais calculé une couche transparente au zoom
> 8 ne contenant que ces landuse pour l'appliquer par simple réduction sur
> les zoom 0 à 7.
>
> J'ai regénéré cette couche, cette fois-ci directement au zoom 7, en
> éliminant tous les polygones d'une surface de moins d'un pixel.
>
> Le résultat est un fichier geotif de 89Mo :
> http://osm13.openstreetmap.fr/~cquest/z7.tif
>
> On a désormais des déserts bien plus cohérents en Afrique !
>
>
> Conséquence, les tuiles ont toutes été recalculées jusqu'au zoom 12 et
> devraient apparaître au fur et à mesure de la mise à jour du cache.
>
>
> Si vous voyez des anomalies... signalez-les...
>
> --
> 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] Aire du viaduc de Millau

[Jérôme Amagat]

J'ai modifié un peu la géometrie https://www.openstreetmap.org/way/434996171
pour qu'elle cole plus au terrain mais ca ne devrait pas changé le problème.
Je pense que le problème vient du faite que le polygon est transformé en un
point au centre donc comme il y a des barrières pour ne pas faire demi tour
sur l'aire (https://www.openstreetmap.org/node/2920654534) pour le GPS il
faut entrer sur l'aire dans l'autre sens pour arriver plus près du point.

Le probleme est le même pour d'autres aire du meme genre,
https://www.openstreetmap.org/way/434996170 ou
https://www.openstreetmap.org/way/185442798
Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de chaque
côté de l'autoroute mais si elles ont le même nom, le GPS va t il choisir
le bon ?

La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires du point
de vu de la voiture, vu que l'on ne peut pas passer d'un côté à l'autre...
ou supprimer la barrière...
Ou ce que je préfère attendre que le GPS gère mieux ces cas.

Si on remplace par un node, je pense qu'on aura toujours le problème, dans
un sens ou dans l'autre de l'autoroute.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation : multiples … ca existe ?

[Jérôme Amagat]

Le sam. 18 juil. 2020 à 11:31, Denis Chenu  a écrit :

> Merci, merci , merci …
>
> Donc : si de multiples éléments font parti d'un ensemble : j'ajoute un
> polygone avec son amenity.
> C'est bien cela le principe ?
>
> Si (au final) ce batiment : https://www.openstreetmap.org/way/79966828
> fait parti du Jardin, mais avec juste un chemin entre les 2.
> 1. Est ce que cela vaut la coup de l'ajouter
>

A toi de voir :)


> 2. Comment faire ?
>
> Ca depend si tout est d'un seul tenant avec le chemin qui fait aussi parti
du jardin, il faut agrandir le polygone pour englober le bâtiment et le
chemin. Si par contre le chemin ne fait pas parti du jardin et donc que ce
n'est pas d'un seul tenant alors il faut utiliser une relation
type=multipolygon, voir le wiki :
https://wiki.openstreetmap.org/wiki/FR:Relation:multipolygon#Deux_anneaux_ext.C3.A9rieurs_disjoints
il faut mettre les 2 polygones dans une relation avec comme rôle "outer"
pour les 2 polygones et les tag sur la relation et pas sur les polygones.
un exemple du même type : https://www.openstreetmap.org/relation/10837473


> Denis
> Le 18/07/2020 à 01:51, Jérôme Amagat a écrit :
>
> Tout ce trouve dans un polygone donc il ne faut pas une relation mais un
> polygone avec à l'intérieur les bâtiments, le jardin, le recycleur... et on
> sait que le composteur et les bâtiments font partie du "Jardin du Hêtre"
> parce qu'ils sont à l'intérieur, par contre il faut y mettre les bon tags
> dessus à part le nom. Je pense que c'est surtout un jardin donc le tag
> principal leisure=garden convient. J'ai modifié le polygone
> https://www.openstreetmap.org/way/787565928 et supprimé la relation.
>
> Le ven. 17 juil. 2020 à 15:25, Denis Chenu via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Bonjour,
>>
>> J'ai une difficulté sur une relations, je ne sais pas comment la placer.
>> L'ensmble fait partie d'un seul élément "Jardin du Hétre"
>> La relation est la suivante
>> 1. Deux bâtiments coté rue
>> 2. 1 bâtiment intérieur (et plus)
>> 2. Une zone jardin (1 deuxième zone à construire)
>> 3. Un recycleur (compost partagé)
>>
>>
>> https://www.openstreetmap.org/?mlat=50.69923=3.16242#map=19/50.69923/3.16242
>> Pour l'instant : j'ai un multipolygone "Jardin du Hétre" en plus du
>> jardin "Jardin du Hétre" et du composteur "Jardin du Hétre" …
>>
>> On peut faire autrement ? Par exemple : indiquer quel est la partie du
>> batiment coté rue qui est l'entrée ?
>>
>> Merci
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Relation : multiples … ca existe ?

[Jérôme Amagat]

Tout ce trouve dans un polygone donc il ne faut pas une relation mais un
polygone avec à l'intérieur les bâtiments, le jardin, le recycleur... et on
sait que le composteur et les bâtiments font partie du "Jardin du Hêtre"
parce qu'ils sont à l'intérieur, par contre il faut y mettre les bon tags
dessus à part le nom. Je pense que c'est surtout un jardin donc le tag
principal leisure=garden convient. J'ai modifié le polygone
https://www.openstreetmap.org/way/787565928 et supprimé la relation.

Le ven. 17 juil. 2020 à 15:25, Denis Chenu via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> J'ai une difficulté sur une relations, je ne sais pas comment la placer.
> L'ensmble fait partie d'un seul élément "Jardin du Hétre"
> La relation est la suivante
> 1. Deux bâtiments coté rue
> 2. 1 bâtiment intérieur (et plus)
> 2. Une zone jardin (1 deuxième zone à construire)
> 3. Un recycleur (compost partagé)
>
>
> https://www.openstreetmap.org/?mlat=50.69923=3.16242#map=19/50.69923/3.16242
> Pour l'instant : j'ai un multipolygone "Jardin du Hétre" en plus du
> jardin "Jardin du Hétre" et du composteur "Jardin du Hétre" …
>
> On peut faire autrement ? Par exemple : indiquer quel est la partie du
> batiment coté rue qui est l'entrée ?
>
> Merci
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Découpage administratif à Paris, les conseils de quartier

[Jérôme Amagat]

Les quartiers administratifs ça sert à quoi ?
Ils ont des limites fixées depuis plus de 150 ans et ont dans leur nom le
mot "administratif" mais tout ce que je trouve apres une brève recherche
c'est qu"ils ont chacun un poste de police...(c'est une ancienne division
de la préfecture de police ?)
Donc j'ai l'impression qu'il n'ont rien à faire dans osm avec
boundary=administrative admin_level=10.
Les conseils de quartier ont aucun pouvoir non plus :) seulement
consultatif mais je trouve plus logique que pour eux il y ait
boundary=administrative admin_level=10.
Par contre pour les quartiers administratifs, il faudrait savoir a quoi ils
servent pour savoir quoi mettre dans boundary=*, peut être "historic"...

nb : Je ne suis pas parisien.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Jérôme Amagat]

Le mer. 8 juil. 2020 à 13:25, Florian LAINEZ  a écrit :

> OK, en effet Christian j'ai pris un mauvais exemple, mais la logique tient
> toujours.
>
> Voici donc l'exemple de la mairie de Montrouge, constitué d'un
> bâtiment avec 3 accès :
> - le bâtiment https://www.openstreetmap.org/way/83237614
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/2232200912
>   addr:role=entrance;visitors
> - l'entrée secondaire https://www.openstreetmap.org/node/2443190668
>   addr:role=entrance;delivery
> - l'entrée reservée au personnel
> https://www.openstreetmap.org/node/6245192824
>   addr:role=staff
>
> Pour un exemple plus classique et simple d'un cinéma, on aurait :
> - le bâtiment https://www.openstreetmap.org/way/83233476
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/5914047022
>   addr:role=entrance
> - la sortie de secours https://www.openstreetmap.org/node/7694884485
>   addr:role=emergency
>
> beaucoup de ces cas font doublons avec le tag entrance=*
https://wiki.openstreetmap.org/wiki/Key:entrance
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour BANO

[Jérôme Amagat]

pour l'exemple je me suis trompé de rue de la mairie.
celle indiqué est bien rapproché mais pas celle la
https://www.openstreetmap.org/relation/11263768 name=Rue de la Mairie
ref:FR:FANTOIR=352820032V non rapproché
https://bano.openstreetmap.fr/fantoir/#insee=35282=2
Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que le
nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon qui
n'existe plus alors que la commune nouvelle "Rives-du-Couesnon" créée en
2019 a le même code insee, Saint-Marc-sur-Couesnon est aussi toujours
present https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3

Le mar. 7 juil. 2020 à 19:46, Jérôme Amagat  a
écrit :

> Je ne sais pas si le problème vient de là mais il y a un souci de
> rapprochement avec bano v2.
> des codes fantoir qui sont sur des relations associatedStreet sont indiqué
> comme non rapproché sur la page
> https://bano.openstreetmap.fr/fantoir/#insee=35282=2
> exemple name=Rue de la Mairie ref:FR:FANTOIR=352820045J
> https://www.openstreetmap.org/relation/11261731
> la relation a été crée le 1/07 et le rapprochement est indiqué comme fait
> le 4/07 https://bano.openstreetmap.fr/fantoir/#insee=35282=2
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour BANO

[Jérôme Amagat]

Je ne sais pas si le problème vient de là mais il y a un souci de
rapprochement avec bano v2.
des codes fantoir qui sont sur des relations associatedStreet sont indiqué
comme non rapproché sur la page
https://bano.openstreetmap.fr/fantoir/#insee=35282=2
exemple name=Rue de la Mairie ref:FR:FANTOIR=352820045J
https://www.openstreetmap.org/relation/11261731
la relation a été crée le 1/07 et le rapprochement est indiqué comme fait
le 4/07 https://bano.openstreetmap.fr/fantoir/#insee=35282=2
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Jérôme Amagat]

Le mar. 30 juin 2020 à 09:13, Yves P.  a écrit :

> Yves : en France on veut l'unicité des points adresse.
>
> Oui, et je suis d'accord avec ça.
>
> L'idée de Florian est bonne, le résultat risque de l'être moins (cf. ton
> explication et celle de Jérôme).
>
> Par rapport au cas du ciné sur le bâtiment, je règle le problème en
> séparant le POI (ici le ciné) du bâtiment :
> Je met un noeud pour le POI vers son entrée, et laisse building=*,
> source=cadastre… sur le polygone.
>
> Pour le moment je fais ça manuellement.
>
> Je viens de regarder, d'après TagInfo FR, il y a 676 chemins et 9
> relations
>  avec
> amenity=cinema.
>
> Sur les relations, je pense qu'il y a des choses à modifier comme
https://www.openstreetmap.org/relation/11186531 et
https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être remplacer
par un polygone ou un multipolygone
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Jérôme Amagat]

Ces contact:*=* c'est pour avoir un unique objet par adresse, le plus
souvent un node qui représente seulement une adresse mais pas
obligatoirement. Mais les addr:*=* des cinémas sont surement pour bon
nombre d'entre elles déjà uniques donc les changer en contact:*=* fera
disparaître des adresses de osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bano v2

[Jérôme Amagat]

Pas super facile d'ajouter de grand nombre de rues avec les outils Bano sur
https://bano.openstreetmap.fr/
Je voulais partager comment je fais, (j'ajoute les noms des rues sur les
ways mais pas les adresses), c'est ce que j'ai trouver de mieux pour
ajouter un maximum de nom en un minimum de temps :

- Je commence par ajouter les relations des voies avec adresses sans
rapprochement OSM pour une commune (http://bano.openstreetmap.fr/fantoir/)
ou une partie des voies non rapprochées avec un maximum d'adresses d'un
département (
https://bano.openstreetmap.fr/fantoir/top_adresses_manquantes.html) ou des
voies les plus récentes manquantes (
https://bano.openstreetmap.fr/fantoir/voies_recentes_manquantes.html)
Je clique sur relation ce qui m'ajoute un calque dans josm avec une
relation avec les adresses de la rue, j'en ajoute autant que je souhaite
traiter. (a chaque clic, josm repasse en 1er plan, donc le mieux c'est de
rapetisser la fenêtre pour qu'elle n'apparaisse pas au dessus des mots
"relation")
- Ensuite dans josm :
- sélection puis fusion des calques
- sélection de toutes les relations et ajout dans la liste des tâches du
plugin todo
- recherche "-new". normalement ça donne aucun résultat mais il peut y
avoir un résultat si un nom de rue a été ajouté dans la journée avant la
mise à jour qui a lieu toutes les nuits ou si une voie portant le bon nom
est situé au bon endroit mais juste de l'autre côté de la frontières entre
2 communes. Si j'ai un résultat, je le purge ctrl+maj+P, josm oubli ces
données (si elles existent dans osm, pas de modification et si elles
viennent de http://bano.openstreetmap.fr, elles sont oublier).
- création d'une nouvelle relation où je mets toutes les données présentent
dans le calque (ctrl+A pour tout sélectionner) que j'ajoute à la liste des
tâches du plugin todo
Cette relation, elle est juste là pour à la fin, avant d'envoyer les
modifications à osm, pouvoir supprimer tout ce que je ne veux pas envoyer
en faisant "sélection des membres (ajout)" sur cette relation puis purger
ctrl+maj+P. je n'y met aucun tag, comme ça le validateur de josm me dit
qu'il y a un problème si j'essaye d'envoyer les données sans avoir supprimé
cette relation avec ce qu'elle contient. Et je prefere purger que supprimer
au cas où il y est un way de rue dans la relation je ne voudrait pas le
supprimer (normalement la recherche "-new" est là pour çà)
- maintenant le travail utile, je traite chaque relation :
- je télécharge les données seulement sur la partie qui englobe la rue ou
sur toute la commune suivant les cas.
- quand la relation est sélectionné, je sélectionne la ligne name=* dans la
partie attributs de josm et fait ctrl+C ça copie name="le nom de la rue"
(clé=valeur), je sélectionne le ou les way qui doivent porter ce nom et
fais ctrl+V pour ajouter le name=* sur le way. On peut aussi sélectionner 2
lignes name=* et ref:FR:FANTOIR=* pour copier coller les 2 clé=valeur sur
le(s) way(s). ca ne sert à rien d'ajouter les ways dans la relation
associatedStreet, la relation va être supprimée. Pareil pas besoin de
déplacer les adresses, supprimées aussi.
- marquer la relation dans la liste des tâches et passer à la relation
suivantes
- une fois toutes les relations traités (ou pas, tous les noms ne sont pas
obligatoirement à ajouter : déja un nom dans osm, orthographe
différentes) la dernières relations dans la liste, c'est celle où il y
a tout ce qu'il faut enlever : "sélection des membres (ajout)" puis purger
ctrl+maj+P
- envoyer les modifications

Voilà, si ça peux aider. ça permet de remplacer le rendu bano et le copier
coller des noms permet d'aller plus vite. on peut utiliser 2 calques, 1
pour les donnée à envoyer et 1 pour celle à ne pas envoyer mais le voyage
entre les 2 fait perdre pas mal de temps. Le fait de purger plutot que
supprimer fait que l'on ne suprimer pas des données par erreur et si on
envoie par erreur les relations et les adresses dans osm, on se retrouve
juste avec des adresses pas tres bien positionnée.
Si vous avez mieux, je suis preneur.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Jérôme Amagat]

plus que 367 (dont 99 itinérants) !
Normalement je n'ai pas fait d'erreurs cette fois ci et dans la pièce
jointe il y a les 367 (dont 99 itinérants) cinémas dont la ref CNC n'est
pas encore dans osm géolocalisé dans leur commune.
et ici :
https://docs.google.com/spreadsheets/d/1t84RGxfaPcZoOv6JresR6OxnGQEs68UDQDndbWI4wkU/edit?usp=sharing
un extrait de la base SIRENE geocodé par cquest (
http://data.cquest.org/geo_sirene/v2019/last/) qui ont comme
'activitePrincipaleEtablissement' '59.14Z'
( il n'y a qu'environ 1/3 qui ont un nom ou quelque chose qui y ressemble)
ref:FR:CNC,name,screen,capacity,_CODE COMMUNE,_COMMUNE,_GENRE,_ART ET ESSAI,cinema:3D,latitude,longitude
12,GEORGE V,11,1666,75108,Paris 8e Arrondissement,FIXE,,yes,48.873645,2.3116
4713,BORIS VIAN GRANDE HALLE,1,287,75119,Paris 19e Arrondissement,FIXE,,no,48.887253,2.387709
8425,QUARTIER LATIN I,2,164,75105,Paris 5e Arrondissement,FIXE,,no,48.845277,2.35058
9616,MK2 A,4,520,75113,Paris 13e Arrondissement,FIXE,,yes,48.8302,2.365001
10184,REX,3,511,80001,Abbeville,FIXE,,yes,50.109435,1.829831
13161,ESPACE CULTUREL AREA (EX-ESPACE CULTUREL),1,268,62014,Aire-sur-la-Lys,FIXE,,yes,50.645609,2.402642
13683,ESPACE CULTUREL MUNICIPAL,1,319,2A004,Ajaccio,FIXE,,no,41.928987,8.712092
13684,AUDITORIUM PASCAL PAOLI,1,432,2A004,Ajaccio,FIXE,,no,41.928987,8.712092
13685,ESPACE DIAMANT,1,295,2A004,Ajaccio,FIXE,,no,41.928987,8.712092
13692,PALAIS DES CONGRES,1,432,2A004,Ajaccio,FIXE,,no,41.928987,8.712092
14693,LE POLE CULTUREL,1,410,94002,Alfortville,FIXE,,no,48.796239,2.421504
15374,BEL' DONNE,2,241,38006,Allevard,FIXE,,yes,45.394443,6.084186
15682,SALLE POLYVALENTE,1,600,72003,Allonnes,ITINERANT,,no,47.962441,0.145667
17961,CINEMA DE LA VIOUZE,1,347,63004,Les Ancizes-Comps,FIXE,,no,45.92885,2.80976
18701,NORMANDIE,1,250,28007,Anet,FIXE,,no,48.853125,1.437646
20311,SALLE DE CINEMA,1,103,71009,Anost,FIXE,,no,47.078514,4.107077
23323,LE FIGUIER BLANC,3,826,95018,Argenteuil,FIXE,,yes,48.948578,2.248098
23392,L EAU VIVE,1,159,05006,L' Argentière-la-Bessée,FIXE,,no,44.788599,6.555362
25722,CIRCUIT 1,1,100,45008,Artenay,ITINERANT,,no,48.075392,1.876596
26180,SALLE POLYVALENTE,1,,12011,Arvieu,ITINERANT,,no,44.185087,2.674777
28113,PAUL GRIMAULT,1,169,78029,Aubergenville,FIXE,,yes,48.957567,1.851294
29144,CINE THEATRE LOUIS ARAGON,1,514,62048,Auchel,FIXE,,yes,50.509614,2.465888
29741,SALLE POLYVALENTE,1,150,63016,Augerolles,ITINERANT,,no,45.73394,3.63153
31331,LES ECRINS,1,97,38020,Auris,FIXE,,no,45.043029,6.088154
33912,LE FAMILIA,1,193,62065,Avion,FIXE,,no,50.407403,2.830058
35953,THEATRE VICTOR HUGO,1,418,92007,Bagneux,FIXE,,no,48.797934,2.310181
36282,SALLE MUNICIPALE CLAUDE PLAN,1,200,34022,Baillargues,ITINERANT,,yes,43.656757,4.008437
38592,SALLE COMMUNALE,1,90,47021,Barbaste,ITINERANT,,no,44.16377,0.24213
39174,THEATRE MONTDORY,1,345,76057,Barentin,FIXE,,yes,49.544418,0.950553
42681,L ATALANTE,1,180,64102,Bayonne,FIXE,,no,43.486661,-1.462185
44239,COUR DE L'ECOLE,1,0,07028,Beaulieu,ITINERANT,,no,44.368303,4.245604
45471,THEATRE SAINT MARTIN,1,211,62100,Beaurainville,ITINERANT,,no,50.417093,1.902671
51261,CINE 89,1,196,13014,Berre-l'Étang,FIXE,,yes,43.505714,5.161253
52532,FOYER RURAL,1,0,63038,Besse-et-Saint-Anastaise,ITINERANT,,yes,45.514507,2.902716
54292,LA BARBACANE,1,292,78062,Beynes,FIXE,,no,48.852507,1.876106
54692,THEATRE PAUL ELUARD,2,598,95063,Bezons,FIXE,,no,48.927287,2.214879
55532,CENTRE CULTUREL,1,298,33051,Biganos,FIXE,,yes,44.653812,-0.950799
56558,CENTRE CULTUREL CLAUDE VIGEE,1,214,67046,Bischwiller,FIXE,,yes,48.763985,7.863265
57303,MAISON DES FETES,1,600,54076,Blainville-sur-l'Eau,ITINERANT,,no,48.557443,6.407226
57821,COLONNES,2,339,33056,Blanquefort,FIXE,,yes,44.921266,-0.615808
57851,SELECT,1,114,16046,Côteaux du Blanzacais,FIXE,,no,45.460879,0.019402
58121,SALLE DE CINEMA,1,150,43165,Rosières,ITINERANT,,yes,45.131602,4.005209
59033,AUDITORIUM BOURSE TRAVAIL,1,,93008,Bobigny,ITINERANT,,no,48.906702,2.443342
59351,LOUIS JOUVET,1,142,02095,Bohain-en-Vermandois,FIXE,,no,49.98791,3.461742
59604,JEAN RENOIR,1,300,92009,Bois-Colombes,FIXE,,yes,48.915287,2.268837
62121,GERARD PHILIPE,1,245,94011,Bonneuil-sur-Marne,FIXE,,no,48.772161,2.489652
67304,RIO BORVO,1,152,71047,Bourbon-Lancy,FIXE,,no,46.61924,3.753851
67312,CASINO,1,124,03036,Bourbon-l'Archambault,FIXE,,no,46.58337,3.048207
67324,CASINO DE BOURBONNE,1,150,52060,Bourbonne-les-Bains,FIXE,,no,47.937958,5.757476
67333,LE ROXY,1,192,63047,La Bourboule,FIXE,,no,45.585742,2.747331
67903,SALLE POLYVALENTE,1,0,38052,Le Bourg-d'Oisans,ITINERANT,,no,45.054822,6.040113
68114,LE CINEMA,1,83,93013,Le Bourget,FIXE,,no,48.937602,2.428852
68212,AUDITORIUM DU CONSERVATOIRE,1,177,92014,Bourg-la-Reine,FIXE,,no,48.780114,2.316361
68561,FAMILIA,1,224,37031,Bourgueil,FIXE,,no,47.303777,0.174675
68562,ABBAYE DE BOURGUEIL,1,380,37031,Bourgueil,FIXE,,no,47.303777,0.174675
69231,LE FOYER,1,356,59098,Bousbecque,FIXE,,no,50.761597,3.079806
73098,OCEANOPOLIS,1,267,29019,Brest,FIXE,,yes,48.406102,-4.498893
74471,LE 

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Jérôme Amagat]

Plus que 330 cinéma dont la ref CNC n'est pas dans osm.
en pièce jointe (si ça passe) , ceux qui reste geolocalisé dans la commune.
ref:FR:CNC,name,screen,capacity,_CODE COMMUNE,_COMMUNE,_GENRE,_ART ET ESSAI,cinema:3D,latitude,longitude
4713,BORIS VIAN GRANDE HALLE,1,287,75119,Paris 19e Arrondissement,FIXE,,no,48.876298,2.402525
8425,QUARTIER LATIN I,2,164,75105,Paris 5e Arrondissement,FIXE,,no,48.841062,2.34152
14693,LE POLE CULTUREL,1,410,94002,Alfortville,FIXE,,no,48.807468,2.410192
35953,THEATRE VICTOR HUGO,1,418,92007,Bagneux,FIXE,,no,48.795358,2.319282
54292,LA BARBACANE,1,292,78062,Beynes,FIXE,,no,,
54692,THEATRE PAUL ELUARD,2,598,95063,Bezons,FIXE,,no,,
59033,AUDITORIUM BOURSE TRAVAIL,1,,93008,Bobigny,ITINERANT,,no,48.902272,2.431014
62121,GERARD PHILIPE,1,245,94011,Bonneuil-sur-Marne,FIXE,,no,,
68114,LE CINEMA,1,83,93013,Le Bourget,FIXE,,no,,
68212,AUDITORIUM DU CONSERVATOIRE,1,177,92014,Bourg-la-Reine,FIXE,,no,48.775324,2.315038
96533,JEAN GABIN,1,168,77079,Champagne-sur-Seine,FIXE,,no,,
110761,SALLE ANDRE MALRAUX,1,405,94021,Chevilly-Larue,FIXE,,no,,
117025,M J C THEATRE DE COLOMBES,1,322,92025,Colombes,FIXE,,no,48.919112,2.262578
120963,THEATRE DU CORMIER,1,307,95176,Cormeilles-en-Parisis,FIXE,,no,,
123905,CAMILLE ST SAENS,1,360,92026,Courbevoie,FIXE,,no,48.901612,2.268448
142171,PARTERRE,2,227,91200,Dourdan,FIXE,,no,48.526124,2.00729
144262,L'ORANGE BLEUE,1,345,95203,Eaubonne,FIXE,,no,,
148321,SALLE SERGE GAINSBOURG,1,180,93031,?pinay-sur-Seine,FIXE,,no,,
149335,PIERRE FRESNAY,1,400,95219,Ermont,FIXE,,no,,
152884,CINETAMPES,1,146,91223,?tampes,FIXE,,no,,
202370,0SALLE GEORGES BRASSENS,1,0,91315,Itteville,ITINERANT,,no,,
226883,THEATRE DU GARDE CHASSE,1,308,93045,Les Lilas,FIXE,,no,48.884642,2.425025
228122,ATELIER BARBARA,1,165,94044,Limeil-Brévannes,FIXE,,no,48.74939,2.492917
231939,THEATRE DE LONGJUMEAU,1,862,91345,Longjumeau,FIXE,,no,,
241923,THEATRE CLAUDE DEBUSSY,1,406,94046,Maisons-Alfort,FIXE,,no,48.802387,2.44122
258952,LA LUCIOLE,1,228,95394,Méry-sur-Oise,FIXE,,no,,
260904,ESPACE CULTUREL ROBERT-DOISNEAU,1,268,92048,Meudon,FIXE,,no,48.803752,2.239127
267481,CINEMA  11X20 14,1,48,77298,Mons-en-Montois,FIXE,,no,,
274702,L'EDEN,2,222,95428,Montmorency,FIXE,,no,48.978061,2.315175
299122,CENTRE CULTUREL  ORMESSON,1,358,94055,Ormesson-sur-Marne,FIXE,,no,,
303445,SALLE DES FETES,1,314,91479,Paray-Vieille-Poste,FIXE,,no,,
314451,ESPACE PAUL VALERY,1,340,94059,Le Plessis-Trévise,FIXE,,no,,
343762,ESPACE GEORGES SIMENON,1,229,93064,Rosny-sous-Bois,FIXE,,no,48.878171,2.506
442002,LE VANVES,1,192,92075,Vanves,FIXE,,no,,
444791,LA GRANGE,1,268,77487,Vaux-le-Pénil,FIXE,,no,48.525052,2.684837
457861,ANDRE MALRAUX,1,212,92078,Villeneuve-la-Garenne,FIXE,,no,,
457983,ESPACE CULTUREL,1,448,94077,Villeneuve-le-Roi,FIXE,,no,,
462304,CINEMA SORANO,1,204,94080,Vincennes,FIXE,,no,48.846711,2.418728
724000,CINE PINCE VENT,8,1606,94019,Chennevières-sur-Marne,FIXE,,no,,
12612,CINEMA MODERNE,1,286,36001,Aigurande,FIXE,,no,,
14445,PLANET'CINE,7,1199,61001,Alençon,FIXE,,no,48.430482,0.086104
15682,SALLE POLYVALENTE,1,600,72003,Allonnes,ITINERANT,,no,47.941615,0.153315
18701,NORMANDIE,1,250,28007,Anet,FIXE,,no,,
25722,CIRCUIT 1,1,100,45008,Artenay,ITINERANT,,no,,
44131,CINEMA LE DUNOIS,1,200,45028,Beaugency,FIXE,,no,,
45876,AGNES VARDA,1,205,60057,Beauvais,FIXE,,no,49.433484,2.056107
50833,REX,1,268,27056,Bernay,FIXE,,no,,
59351,LOUIS JOUVET,1,142,02095,Bohain-en-Vermandois,FIXE,,no,,
67324,CASINO DE BOURBONNE,1,150,52060,Bourbonne-les-Bains,FIXE,,no,,
68025,LE CINEMA,1,110,18033,Bourges,FIXE,,no,47.100514,2.396675
68561,FAMILIA,1,224,37031,Bourgueil,FIXE,,no,,
68562,ABBAYE DE BOURGUEIL,1,380,37031,Bourgueil,FIXE,,no,,
84981,ESPACE CULTUREL FRANCOIS MITTERRAND,1,170,76157,Canteleu,FIXE,,no,,
94711,FAMILIAL,1,393,52093,Chalindrey,FIXE,,no,,
95006,LA COMETE,1,153,51108,Châlons-en-Champagne,FIXE,,no,48.954145,4.363398
96950,SALLE YVES RENAULT,1,242,37050,Chambray-lès-Tours,FIXE,,no,47.35142,0.694571
104801,VOX,1,64,45083,Château-Renard,FIXE,,no,,
104863,APOLLO,1,328,36044,Châteauroux,FIXE,,no,46.791569,1.693724
106291,LUX,1,193,36046,La Châtre,FIXE,,no,,
119122,CINEMA MUNICIPAL,1,340,50139,Condé-sur-Vire,ITINERANT,,no,,
122720,SALLE DES FETES,1,0,60164,Le Coudray-Saint-Germer,ITINERANT,,no,,
126311,LE LONG-COURT,2,324,50147,Coutances,FIXE,,no,,
127571,LE CYRANO,1,270,80222,Crécy-en-Ponthieu,FIXE,,no,,
127661,LA FAIENCERIE,1,749,60175,Creil,FIXE,,no,49.263872,2.47509
137481,LE RABELAIS,1,167,37115,Descartes,FIXE,,no,47.00304,0.659791
138352,CINEMAS GRAND FORUM,8,1319,76217,Dieppe,FIXE,,no,49.928002,1.080231
142522,CINEMA LE NORMANDY,1,200,14711,Trévières,ITINERANT,,no,49.308697,-0.906494
156393,CINE SEINE,1,0,76258,Terres-de-Caux,ITINERANT,,no,,
158801,JEAN RACINE,1,119,02307,La Ferté-Milon,FIXE,,no,,
158812,VARIETES CINEMA,1,187,45146,La Ferté-Saint-Aubin,FIXE,,no,,
165801,VOX,1,280,80333,Fort-Mahon-Plage,FIXE,,no,,
179902,LA POINTE DE CAUX,1,337,76305,Gonfreville-l'Orcher,FIXE,,no,49.524165,0.229572

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Jérôme Amagat]

Le dim. 7 juin 2020 à 15:16, François Lacombe  a
écrit :

> Bonjour à tous,
>
> Le dim. 7 juin 2020 à 11:02, Frédéric Rodrigo  a
> écrit :
>
>> Le 04/06/2020 à 17:09, Marc M. a écrit :
>> > Le 04.06.20 à 17:02, didier2020 a écrit :
>> >> dans le référentiel, la bretelle est définie par 2 plo, non visible
>> >> sur le terrain
>> >> - la référence métier est sur un way
>> > séparer l'intégration en 2 :
>> > - les bornes réelles d'un côté
>> > - les ref de route non indiquée sur le terrain...
>> > sans doute qlq chose pour unsigned_ref.
>> > très pratique pour éviter qu'un guidage te propose
>> > de suivre une ref que tu ne vois pas.
>>
>> Je pense qu'il faut déjà se concentrer sur les bornes physiques.
>>
>>
>>
>> Un borne est portée une route qui a une référence.
>>
>> Le wiki de dit pas si la borne doit être sur ou a coté du la voie.
>>
>
> Si, c'est écrit : à côté de la voie
> https://wiki.openstreetmap.org/wiki/FR:Key:marker#Comment_contribuer
>
> là tu parle du tag marker=* pas de highway=milestone


> Ajouter les bornes comme noeuds de la route est une mauvaise idée : vous
> ne roulez pas sur la borne quand vous y circulez.
> Idem pour la signalisation.
>

On ne roule pas sur les feux de signalisation et pourtant c'est conseillé
de placer highway=traffic_signals sur un node du way de la route voir à
l'intersection des ways des routes. pareil pour les panneaux stop et cédez
le passage.
Le problème c'est indique t on la borne ou ce qu'elle représente : c'est
lorsqu'on est sur la route à côté de la borne que l'on est au point
kilométrique. Pareil pour les feux et panneaux (pour les feux et panneaux,
on a le problème de la direction mais pas là). Pour les route, on
"schématise" pas mal dans osm, pas de surfacique, 1 way par chaussée et pas
par voie ... autant continuer.
un node à côté de la route, ça veut aussi dire que l'info est beaucoup plus
difficile à réutiliser (sauf à l'afficher sur une carte).
Ici le jeu de donnée c'est beaucoup d'autoroutes où il me semble le pk est
indiqué des 2 cotés des 2 chaussées donc 3 ou 4 bornes a ajouter, 2 si sur
le way, 1 par chaussée.


>
>> La borne a ensuite une référence unique par route, composé du
>> département, numéro d'ordre de la borne, coté de chaussée [...])
>>
>> http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf page 12
>>
>> Mais cette référence de borne n'inclut pas la référence de la route
>> (c'eût aurait été trop facile).
>>
>
>> Nationalement il y a donc des doublons de référence de bornes. Ils font
>> donc les deux références pour l'identifier.
>>
>
> C'est le cas de certains objets, dont plusieurs déjà traités par Osmose :
> les pylônes RTE par exemple.
> C'est le cas aussi de la plupart des lampadaires, de beaucoup de bornes à
> incendie, des bornes GRTgaz.
> Les numéros sont donnés à la ligne, à la commune ou à l'EPCI, on ne peut
> pas les identifier nationalement.
>
> La conflation doit se faire dans chaque périmètre ce qui ajoute une
> difficulté en plus oui
>
>
>>
>> Soit on considère que par jointure/proximité avec la voie qui la porte
>> on retrouve cette référence, soit on cherche à rajouter la ref de la
>> route quand même sur la borne (mais dans quel tag ?), ou tout mettre
>> dans le même tag par concaténation.
>>
>
> ref=* doit contenir la référence de la borne telle que vue sur le terrain
> ou à défaut dans le fichier.
>

Pas de ref dans le fichier. le code plo indiqué dans le 1er message peut
être déduit des différentes colonne du fichier, mais n'est pas présent.

>
> M'est avis qu'il faut sortir de ref:*=* l'identification de la route sur
> la borne pour ne pas confondre.
> Un truc du style highway_name=* ou apparenté.
>
>
> Le dim. 7 juin 2020 à 11:33, didier2020  a écrit :
>
>>
>> Les versions Française et Anglaise ne sont pas aprouvée...
>>
>> la proposition était simple : ref est le nom de la route
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Milestones
>
>
> Bon point de souligner que les discussion n'est pas allée au bout.
>
> Je n'ai pas la même interprétation de "ref
> =* is optional, only to be
> used if the milestone actually has a reference number written on it."
> En France, je ne connais aucune borne kilométrique qui ait une référence
> sur le terrain.
>
>
> Bon dimanche à vous
>
> François
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Jérôme Amagat]

mon avis :
un node avec highway=milestone et distance=pr
ce node doit être un node du way de la route. Mais je ne crois pas
qu'osmose peut faire quelque chose pour ça.
Pas de ref=*, il n'y a pas de référence sur les bornes ni pour les borne
dans le jeux de données, le A * ou N * c'est la référence de la route et
pas de la borne.

Pour les bretelles, ajouter sur les way la référence en ref=*

il y a plusieurs bornage pour des départements sur data.gouv.fr :
https://www.data.gouv.fr/fr/search/?q=bornage
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Jérôme Amagat]

Le jeu. 28 mai 2020 à 15:26, Simon Réau  a écrit :

> Bonjour,
>
> Avec gileri  nous avons un
> désaccord sur un highway=footway situé dans la continuité de deux pistes
> cyclables. Notre discussion ce situe ici
> https://www.openstreetmap.org/changeset/85822975#map=19/45.75301/4.86788
>
> Le débat porte sur l'accès aux vélo sur cette partie entre les deux pistes
> cyclables.
>
> J'aimerais avoir l'avis de la communauté pour trancher la question.
>
> La voie en question
> https://www.openstreetmap.org/way/808726332
> https://www.openstreetmap.org/way/808726333
>

Si jai bien compris le lieu du débat, pour la métropole, ça fait parti des
aménagements cyclables, donc accessible aux vélos :
https://data.grandlyon.com/jeux-de-donnees/amenagements-cyclables-metropole-lyon/donnees
(Pas besoin de télécharger les données, on peut les afficher sur une carte)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une résidence dans une zone résidentielle ?

[Jérôme Amagat]

Moi, j'utilise place=neighbourhood pour les lotissements et les résidences
mais sur des nodes.

> En terme de taille et pour Nantes tu as raison : neighbourhood c'est trop
> grand.
>
Le problème est peut être le choix fait à Nantes d'utiliser
place=neighbourhood
Il y a place=quarter entre place=suburb et place=neighbourhood
de plus pour Nantes il y a le découpage administratif niveau 10 et 11, qui
peut être différent des véritables quartiers qui portent le même nom.
D’ailleurs pour certain "quartiers" administratifs, le nom est composé de 2
noms accolés représentant 2 quartiers différents. Donc les quartiers au
sens le plus courant (même sens qu'osm) n'ont pas la superficie des
quartiers administratifs.

Rien ne dit non plus que place=neighbourhood a une taille minimum, c'est
juste plus petit que place=quarter. city_block pour moi est peu adapté à la
France et est pour moi un bloc compacte d'habitation séparer du reste par
des rues. plot c'est censé être une parcelle, je ne crois pas qu'il faille
l'utiliser. Dans osm, pas de parcelle cadastrale, et place=* est censé
toujours être utilisé avec name=* ce qui ne semble pas être obligatoire ici
d'après le wiki et place=* n'est rendu que pour les nodes alors qu'ici il
faudrait une surface.

Par contre le problème, c'est que le rendu ne rend pas les place=*
surfaciques seulement les nodes et ajouter un label avec les même tag sur
un node, c'est donc avoir 2 objets pour la même chose, ce qu'il ne faut pas
faire dans osm...

Donc en fait, la solution que je préférés en cas de résidence représentée
par une surface c'est en plus de place=neighbourhood d'ajouter
landuse=residential :)
Ce n'est pas faux, c'est bien une zone résidentielle, elle fait partie
d'une zone résidentielle plus grande mais une partie de zone résidentielle
est bien une zone résidentielle :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] import cadastre d'une petite zone

[Jérôme Amagat]

Le mar. 12 mai 2020 à 01:09, Donat ROBAUX  a écrit :

> Je rejoins ce que dit Eric
>
> Quand tu télécharges ton petit bout de planche cadastrale via l'onglet
> Josm,
> que ca t'en télécharge 4 planches alors que t'as rien demandé (mais que tu
> as le malheur d'être proche de la jointure) que le SEUL bâtiment de la
> planche que tu voulais n'est pas dans le calque téléchargé, ca énerve un
> peu. Et au-delà de ca, une débauche d'énergie puisque tu télécharges trop
> de
> données pour rien.
>
> En revanche, quand tu passes par l'ancienne méthode via
> cadastre.openstreetmap.fr, en selectionnant juste ta petite zone, tu as
> ton
> bâtiment. Franchement je ne comprends pas. Pourtant ce sont bien les mêmes
> données avec la même mise à jour?
>
> Je n'y connais pas grand chose mais je ne pense pas que la débauche
d’énergie soit dans ce sens, dans le premier cas c'est juste un
téléchargement dans l'autre il faut récupérer les données dans les pdf.
Moi je préfères la méthode via le plugin josm, par contre aujourd'hui ça ne
marche pas :(
Il faut prendre l'habitude de sélectionner une zone très petite pour ne
télécharger qu"une planche et faire attention de ne pas télécharger dans la
planche avec les données osm... La mise à jour trimestriel, ne m'a que très
rarement posé un problème. Sur cadastre.openstreetmap.fr c'est très long
pour avoir une commune en entier maintenant que les pdf sont plus petit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] import cadastre d'une petite zone

[Jérôme Amagat]

Le dim. 10 mai 2020 à 15:37, Eric SIBERT  a écrit :

> Dans JOSM, quand on télécharge une zone, il y a un onglet
> "Téléchargement depuis le Cadastre". On choisit Objets : bâtiments. Ça
> télécharge dans un nouveau calque (par planches cadastres entières). On
> copie les bâtiments qu'on veut et on fait un "Coller à la position
> originale" Ctrl+Alt+V dans le calque OSM.
>
>
> Question annexe: à quelle fréquence sont mises à jour les données
> cadastre vecteur? J'ai un secteur à côté de chez moi avec des nouveaux
> bâtiments visibles depuis des mois dans le cadastre raster mais pas en
> import dans JOSM?
>
> les données sont celles la, il me semble :
https://cadastre.data.gouv.fr/datasets/cadastre-etalab
c'est trimestriel, normalement il devrait y avoir celles d'avril, peut être
un retard du au confinement
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Jérôme Amagat]

Difficile de trouvé d'autres exemples de côte pas a jour dans le rendu fr,
en cherchant au hasard, j'ai trouvé ça :
https://www.openstreetmap.org/#map=14/15.7668/40.0185
http://tile.openstreetmap.fr/?zoom=14=15.76549=40.01546=B000FFF
les nodes ont été créé en mai 2019 :
https://www.openstreetmap.org/changeset/70720131#map=12/15.7704/40.0388

Pour des discussions sur le changements relation vers node :
Sur le changeset de la modification de la Manche et golfe de Gascogne, pas
de réponse de l'auteur :
https://www.openstreetmap.org/changeset/83083550
Une discussion sur le forum qui concerne le golfe d’Ajaccio qui va bientôt
disparaître du rendu car la relation a été supprimer (les faible zoom ne
sont pas mis a jour aussi vite que les gros zoom) :
https://forum.openstreetmap.org/viewtopic.php?id=69220
Il y a eu plusieurs discussions il y a un an sur talk en anglais :
http://gis.19327.n8.nabble.com/Tag-for-a-plateau-or-tableland-tp5937977p5938119.html
http://gis.19327.n8.nabble.com/Verifiability-wiki-page-Geometry-section-added-tp5938601.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Jérôme Amagat]

Le ven. 8 mai 2020 à 10:47, Marc M.  a écrit :

> Bonjour,
>
> Le 07.05.20 à 20:32, Jérôme Amagat a écrit :
> > J'en profite pour signalé qu'il y a un problème sur le rendu fr, ça fait
> > maintenant un bon moment que la Gironde est asséché :
> >
> http://tile.openstreetmap.fr/?zoom=10=45.32095=-0.73387=B000FFF
>
> https://www.openstreetmap.org/relation/1675626
> sans doute que le rendu osm-fr ne connait pas
> il y a un an c'était en natural=water
>
> Ce n'est pas ça le problème,  en même temps que ce changement, les côtes
de la gironde sont devenus natural=coastline (exemple :
https://www.openstreetmap.org/way/538325176 )
Et le rendu des natural=bay sur le rendu osm ajoute juste le nom pas le
bleu.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Jérôme Amagat]

C'est pas facile pour le rendu, exemple l'île de Sein :
rendu osm : https://www.openstreetmap.org/#map=14/48.0367/-4.8522
rendu osm fr :
http://tile.openstreetmap.fr/?zoom=14=48.0373=-4.85245=B000
vue aérienne sur le geoportail :
https://www.geoportail.gouv.fr/carte?c=-4.852870844451901,48.03364219188839=14=ORTHOIMAGERY.ORTHOPHOTOS::GEOPORTAIL:OGC:WMTS(1)=yes

J'en profite pour signalé qu'il y a un problème sur le rendu fr, ça fait
maintenant un bon moment que la Gironde est asséché :
http://tile.openstreetmap.fr/?zoom=10=45.32095=-0.73387=B000FFF
La mise à jour du bleu de l'océan ne se fait pas.
(ça permet de dire à ceux qui ne le savent pas que ce bleu, placé grâce aux
natural=coastline n'est pas mis à jour aussi souvent que le reste sur le
rendu osm et donc que, après avoir modifié la ligne de côte, ça peut
prendre plusieurs jours voir semaine à être mis à jour.)

Autre chose, je signale que le Golfe de Gascogne, la Manche et d'autres ont
disparu du rendu à faible zoom car les grandes relations qui existaient
auparavant ont été remplacé par un node...
ces grandes relations ne plaisent pas à certains, les raisons évoquées sont
: trop grande, difficile a maintenir et la limite d'un golfe, d'une mer ...
sont approximatives.
Leur solution c'est de les remplacer par un node.
par exemples la Manche :
https://www.openstreetmap.org/node/7367542816
Maintenant il faut zoomé au bon endroit pour le voir sur le rendu et je
vois pas comment ce node pourrait être utile pour quoi que ce soit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] plusieurs structures dans un même bâtiment

[Jérôme Amagat]

Le sam. 25 avr. 2020 à 15:50, Yves P.  a écrit :

>
> Pour moi, si "géographiquement",
>
> On peut toujours -> indoor mapping ;D
>

> on ne peut pas distinguer les 2 (ou plus) structures alors, dans osm, ce
> n'est qu'un seul objet. Comme pour un bar restaurant, on choisit les tags
> les plus adapté pour les tags principaux et mettre les différents FINESS
> dans ref:FR:FINESS=*/ séparés par des ";".
>
> Oui
>
> ou mettre les 2 POI à la même position et le rendu choisira quoi afficher
> (le 1er, le dernier ?)
>
> J'ai fait ça pour Adecco générale, Adeco Médical et Adecco PME dans le
> même bureau.
> Adecco PME tombe à l'eau… qui est-ce qui reste dans le buro :D
>
> Il faut qu'on puisse trouver les 3, ils ont chacun un n° de tél spécifique.
> Si je met phone=1;2;3 qui appeler pour Adecco PME ???
>
> Ici PME a gagné :
> https://www.caresteouvert.fr/@46.214466,5.213543,19.51/place/n7437606917
> Là, personne :
> https://www.openstreetmap.org/node/7437606916#map=19/46.21445/5.21383
>
> Des numéros de téléphone différents mais le même lieu et sûrement les même
personnes qui répondent. Les numéros différents c'est sûrement surtout
cosmétique. peut être des employés différents pour les 3 mais
interchangeable et si un n'est pas disponible c'est un autre qui s'en
occupe.

>
> Dans le cas d'un EHPA et un EHPAD dans le même bâtiment, c'est bien la
> même entité qui prend en charges dss patients différents donc pour FINESS,
> il apparaît 2 fois et il y a 2 traitements pour les résidents mais ce n'est
> qu'un établissement.
>
> Oui.
>
> Dans ce cas c'est souvent simple dans ma région. Une aile est dédiée à
> l'une des structures.
>

Une aile ou un étage différent pour les chambres mais une bonne parti des
bâtiments hors chambres sert indifféremment pour les 2 "structures".

OSM n'est pas adapter à ce genre de chose alors il faut sûrement l'adapter
pour pouvoir gérer des cas plus compliqués mais je ne suis pas sur que osm
soit adapter à devenir un annuaire...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] plusieurs structures dans un même bâtiment

[Jérôme Amagat]

Le sam. 25 avr. 2020 à 11:58, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> j'aimerais vos regards sur ce point. Quand plusieurs structures sanitaires
> et sociales sont dans un même bâtiment, je ne suis pas confortable avec
> l'idée d'ajouter des POI en vrac.
> Je suis même tombé sur des cas où il y a avait 5 ou 6 structures sociales
> posées manifestement au hasard dans une maison, toutes ces structures (de
> mémoire du style MAS, FAM, EAM, etc.) ayant le même nom, comme "La Maison
> Verte".
>
> En dehors du fait que ça ne facilite pas la lecture d'une carte, je ne
> vois pas trop l'intérêt de cartographier des choses non positionnables sur
> une carte. Mais je suis prêt à changer d'avis :-)
>
> Pour être concret, j'ai un EHPA et un EHPAD dans le même bâtiment :
> http://finess.sante.gouv.fr/fininter/jsp/actionDetailEntiteJuridique.do?noFiness=850006610=850026584
>
> https://www.openstreetmap.org/?mlat=46.8210001=-1.9947037#map=18/46.82106/-1.99510
>
> Pas sûr qu'il y ait une distinction géographique. L'affectation dépend
> peut-être juste de l'état des patients. Pour les êtres humains normaux,
> il n'y a qu'une seule structure. Il n'y en a deux que parce que nous
> saisissons un ref:FR:FINESS proposé par Osmose.
>
> Vous suggérez quoi ? 
>

Pour moi, si "géographiquement", on ne peut pas distinguer les 2 (ou plus)
structures alors, dans osm, ce n'est qu'un seul objet. Comme pour un bar
restaurant, on choisit les tags les plus adapté pour les tags principaux et
mettre les différents FINESS dans ref:FR:FINESS=*/ séparés par des ";".

Dans le cas d'un EHPA et un EHPAD dans le même bâtiment, c'est bien la même
entité qui prend en charges dss patients différents donc pour FINESS, il
apparaît 2 fois et il y a 2 traitements pour les résidents mais ce n'est
qu'un établissement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Data Item à la place de *:wikidata

[Jérôme Amagat]

Le lun. 13 avr. 2020 à 19:11, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello,
>
> j'ai un peu expérimenté sur le sujet des data item, mais j'arrive pas à
> grand chose.
> Je résume l'objectif : éviter de mettre des tags qui veulent dire à peu
> près la même chose dans OSM, à savoir brand et brand:wikidata.
>
> Pour l'exercice, imaginons que j'essaye de récupérer les logos de quelques
> magasins franchisés.
> Aujourd'hui, je peux le faire en faisant un lien entre OSM et Wikimédia
> Commons en passant par Wikidata à l'aide du tag brand:wikidata.
> Par exemple avec une requête de ce type : https://tinyurl.com/rq7uktj
>
> Essayons maintenant de reproduire l'expérience sans le tag brand:wikidata,
> en utilisant le tag brand et les data items du wiki pour faire le lien.
>
> Voici une requête qui récupère des supermarchés avec un tag brand, puis
> qui cherche dans les data items du wiki l'élement brand=ce qui m'intéresse,
> puis récupère son tag wikidata associé et va chercher le logo :
> https://tinyurl.com/r6zofzz
>
> Bon, ça retourne rien, mais ... en vrai, il n'y a aucun data item avec des
> marques de supermarchés (cf aparté ci-dessous)
>
> Si je refais la même requête avec une marque qui a un data item existant :
> https://tinyurl.com/r8kz2d6
>
> ben ça marche toujours pas ... une idée de pourquoi ?
>

Je pense que le problème c'est que ?wikidata_from_dataitem c'est juste
"Q215657"
alors que wikidata attend quelque chose qu'il affiche wd:Q215657.
On le voit dans le requête qui marche avec brand:wikidata, il affiche bien
un wd:Qid avec un lien vers http://www.wikidata.org/entity/Qid
Il ne faut pas donner à wikidata juste la référence, le Qid mais l’élément
en entier.
Mais j'ai essayé en lui donnant "wd:Q215657" ou "
http://www.wikidata.org/entity/Q215657; mais ça ne marche pas.
Je ne sais pas comment on obtient l’élément wikidata à partir de son Qid,
je n'ai pas trouvé...

Sinon, sur le fait de se servir des data item de osm, je ne vois pas
l'utilité de recopier une partie de wikidata dans ces data item, autant se
servir de wikidata directement. ça évite d'avoir à maintenir les info dans
osm.
Par contre il n'y a pas vraiment toutes les marques dans wikidata. Par
exemple pour les supermarchés, il y a toutes les enseignes de la marque
Carrefour mais pas de Casino ou U.

>
>
> Aparté :
>
> Cette requête affiche les data items brand=qqch :
> https://tinyurl.com/ve4fq9r
>
> On constate
> - qu'il y en a 6 en tout
> - que seuls 2 ont un id wikidata
>
> La volumétrie est vraiment donc très faible pour le moment.
>
> Questions : est-ce qu'on peut faire un import des brand dans la base du
> wiki, avec a minima l'id wikidata (en commençant par la France, voire juste
> les supermarchés en France) ?
> Quelles sont les bonnes pratiques ? Quels sont les outils qui
> permettraient de faire ça ?
> Le 27/03/2020 à 20:38, Noémie Lehuby via Talk-fr a écrit :
>
> Bonjour,
>
> Il y a pas mal d'homonymes dans le domaine des transports (même si c'est
> plus network:wikidata ou operator:wikidata que brand:wikidata je te le
> concède) . Personnellement, j'ai découvert ce sujet grâce à / à cause des
> deux réseaux "Arc-en-Ciel" (en Haute-Garonne
>  et dans le Nord
> ) qui ont fait coulé pas mal
> d'encre sur nos listes de diff.
>
> L'idée est intéressante en tout cas, je ne pensais pas qu'on pouvait
> utiliser les Data Item pour cela. Il y a déjà de la doc sur ce sujet et ce
> cas d'usage ?
> Pour que ça puisse remplacer / complémenter wikidata et éviter la saisie
> d'info redondantes dans OSM, il faudrait qu'on puisse savoir facilement si
> une liaison entre un tag brand=qqch et wikidata existe déjà, savoir comment
> accéder à ces infos par APIs ou en téléchargeant un dump de la base, etc
>
> --
> Noémie Lehuby
>
> Le 26/03/2020 à 22:52, François Lacombe a écrit :
>
>
> Le jeu. 26 mars 2020 à 18:10, Yves P.  a écrit :
>
>> > Je suggère de ne taguer les objets OSM qu'avec brand=*
>> Le problème, c’est qu’il y a des homonymes…
>> C’est pour ça qu’il existe wikidata ;)
>>
>
> Oui mais les identifiants wikidata ne sont pas lisibles.
> Le parti pris d'OSM est d'avoir des valeurs lisibles par l'homme il me
> semble?
> Et puis la question qui se pose est d'avoir deux fois la même information
> sur les objets.
>
> Peux-tu me citer un exemple d'homonyme s'il te plait?
>
>
>> > Et dans le DataItem relatif à une marque donné
>> brand=Harley-Davidson -> https://wiki.openstreetmap.org/wiki/Item:Q5371
>>
>> Ok, mais ça revient à recréer wikidata ?
>>
>
> Non parce que wikidata ne va pas te dire sur quelle géométrie peut-être
> utilisé le tag, ou à quelles règles de validation il va répondre.
> Les DataItem c'est la description sémantique propre à OSM.
>
>
>> > Sinon on ne va faire que ça et cette liaison va être modifiée en
>> permanence en plus d'être difficile à maintenir partout.
>> +1
>>
>> > Cela donne un cas d'usage 

Re: [OSM-talk-fr] comment cartographier un établissement thermal

[Jérôme Amagat]

Spa c'est peut être le bon mot mais vu la page pour amenity=spa où il est
indiqué "Don't use! *Spa* is ambiguous", je suis pas sur que ce soit le bon
mot pour osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose et intégration FINESS : problème de localisation

[Jérôme Amagat]

Le mer. 25 mars 2020 à 17:27, Yves P.  a écrit :

> Bonjour,
>
> Je viens de regarder le résultat de la dernière PR.
> Ici
> les
> localisations ne correspondent pas du tout aux adresses.
>
> Les accents sont aussi manquants (champ subtitle):
>
> Exemple :
> 6, R, SAINT CYR, 71520 MATOUR, EHPA ne percevant pas des crdits
> d'assurance maladie
> Ce POI est localisé à Châlon-sur-Saône
>
> http://osmose.openstreetmap.fr/fr/error/a7a2a6b6-a919-1acb-884a-247dbe7e3448
>
> Je suis retourné au fichier source ici :
https://www.data.gouv.fr/fr/datasets/finess-extraction-du-fichier-des-etablissements/

Pour cet établissement ref:FR:FINESS= 710978040
les coordonnées sont 841416.0 6632966.4 ça fait bien comme dit osmose :
4,8537542 46,7818901
donc osmose le place bien
MAIS

dans un ancien fichier, celui utilisé avant les derniers changements par
osmose : https://static.data.gouv.fr/
resources/finess-extraction-du-fichier-des-etablissements/20190307-093304/etalab-cs1100507-stock-20190307-0422.csv
les coordonnées sont 813827.5 6579859.2 ça fait : 4,4791663 46,3090391
et ça se situe à Matour 6 rue de Saint-Cyr

Donc le problème des coordonnées n'est pas osmose mais la source, il fait
réutilisé un fichier plus ancien ...
(ca n'a pas l'air d'être juste un décalage de ligne)

sur la page :
https://www.data.gouv.fr/fr/datasets/finess-extraction-du-fichier-des-etablissements/
dans les commentaire, quelqu'un a détecté le même problème, les coordonnées
qui changent et sont mauvaises, il s'en plaint mais il n'obtient pas de
réponse...

Pour les accents, que j'ouvre le fichier sur libreoffice en ISO-8859-1 ou
en ISO-8859-15, j'ai les accents.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO - Top des voies non rapprochées, par nombre d'adresses

[Jérôme Amagat]

Le mar. 24 mars 2020 à 23:36, Vincent de Château-Thierry 
a écrit :

>
> Le 24/03/2020 à 17:46, Jérôme Amagat a écrit :
> > Quelqu'un a mieux que 70 "Le Bourg" sur 100 ? :)
> >
> https://dev.cadastre.openstreetmap.fr/fantoir/top_adresses_manquantes.html#dept=15
> >
> > Je pense qu'il faudrait avoir que les voies et pas les lieux-dits.
>
> Oui sur le Cantal c'est corsé :) Je n'ai pas restreint aux voies,
> histoire qu'on puisse constater l'ampleur du phénomène. En revanche,
> j'ai augmenté la longueur des listes proposées : ça vient de passer de
> 100 à 200 lignes.
>

On passe à 107 sur 200 dans le Cantal :)


> Peut-être que voir la masse des adresses rattachées à des lieux-dits
> nous permettra de statuer sur le modèle d'adressage avec addr:place,
> assez confidentiel encore (12000 points en France) et toujours pas géré
> dans BANO.
>
> Les lieux dits rapproché semble être aussi dans la liste. C'est voulu ?
Toujours dans le Cantal :
https://dev.cadastre.openstreetmap.fr/fantoir/top_adresses_manquantes.html#dept=15
Dans la liste il y a "Roueyre" à Saint-Flour :
https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=15187=5
Il existe un node avec place=hamlet et name=Roueyre qui est présent dans la
page de la commune comme "lieux-dits FANTOIR avec rapprochement OSM"
donc il est présent dans osm et détecté comme tel, pourquoi est t il dans
les top adresse manquantes ?
C'est voulu que ce genre de lieux dits soit dans cette liste ?
Pour ce cas là que faire de plus dans osm ? Ajouter les adresses? ce ne
sont que des pseudo adresse en 5000 ou plus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO - Top des voies non rapprochées, par nombre d'adresses (was: exemple d'usage d'osm vs covid19)

[Jérôme Amagat]

Quelqu'un a mieux que 70 "Le Bourg" sur 100 ? :)
https://dev.cadastre.openstreetmap.fr/fantoir/top_adresses_manquantes.html#dept=15

Je pense qu'il faudrait avoir que les voies et pas les lieux-dits.

Le mar. 24 mars 2020 à 15:10, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> Le 24/03/2020 à 10:39, Jean-Guilhem Cailton a écrit :
> >
> > C’est la question globale de l’utilité d’OSM pour les besoins carto…
> > Ce qu’on peut dire en tout cas c’est qu’elle est d’autant plus grande
> > que les données à l’endroit considéré sont complètes et de qualité…
> >
> >> si c'est pour un routage des équipes médicales chez les particuliers,
> >> le plus efficace me semble être les noms de rue manquante ayant de
> >> nombreuses addr, j'ai ouvert un ticket en ce sens
> >> https://github.com/osm-fr/osm-vs-fantoir/issues/102
> >
> > En effet. Bonne initiative.
> > Bien sûr que pour résoudre le problème global des adresses en France, la
> > stratégie prioritaire reste de compléter les noms de rue manquants, pour
> > commencer par résoudre ce sous-problème prioritaire là.
>
> Allons-y :)
>
> En echo au ticket ouvert par Marc-marc, je vous propose cette page :
>
> https://dev.cadastre.openstreetmap.fr/fantoir/top_adresses_manquantes.html
>
> qui vous donne par département la liste des 100 voies non rapprochées ET
> les plus pourvues en points d'adresse, selon le Cadastre.
>
> Vous verrez vite que cette liste rassemble de vraies rues et des
> endroits moins simples à cerner, comme des îles, des résidences, ou des
> lieux-dits. Vous trouverez aussi parfois des paquets d'adresses toutes
> positionnées en un même point. Bref, c'est à prendre avec un peu de
> recul, mais ces listes devraient nous permettre de dégommer certaines
> rues qui profiteront bien aux stats de remplissage de BANO.
>
> La page propose, tout à droite, d'intégrer directement les points
> d'adresse. C'est bien, mais long et fastidieux. Vous pouvez prendre le
> raccourci qui consiste juste à fixer/corriger le nom de voie dans OSM
> (colonnes "Edition"), ce qui améliore déjà le contenu d'OSM et profite à
> BANO. Libre à vous.
>
> Un dernier bémol : la base BANO n'étant pour l'instant rafraîchie qu'une
> fois par 24h (durant le nuit), ces listes sont elles aussi mises à jour
> une fois par 24h. Donc vérifiez au moment d'intégrer une voie ou des
> adresses que personne n'est passé quelques minutes avant pour
> ajouter/corriger le même endroit.
>
> Je ne promets pas que tout ça est totalement sec, donc merci pour vos
> retours
>
> 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

Re: [OSM-talk-fr] Barrière délimitant une aire de jeux

[Jérôme Amagat]

Le ven. 20 mars 2020 à 13:55, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Quand on trace une aire de jeux leisure=playground fermée,
>
> est-ce qu'on trace une barrière barrier=fence superposée, (+
> barrier=gate entrance=yes pour le portillon)
>
> ou bien on trace la barrière et on fait le playground comme relation à
> un seul membre outer qui serait la barrière ?
>
> Moi je préfère mettre le tag  barrier=fence sur le même élément que
leisure=playground
Un truc surfacique avec un linéaire, c'est pas super...
Mais une relation avec un seul membre, c'est pas terrible
et 2 ways identiques superposé non plus...

Pour le rendu mettre les 2 tags sur la même chose ça marche.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Covid-19 et carto

[Jérôme Amagat]

Le ven. 20 mars 2020 à 00:52, Marc M.  a écrit :

> Bonjour,
>
> La base finess étant dispo en opendata, ne serrait-il
> pas plus agréable de pondre une analyse osmose ?
>
> ou même se passer d'osm.

le jeu de donnée sur les activités de soins :
https://www.data.gouv.fr/fr/datasets/finess-extraction-des-autorisations-dactivites-de-soins/
Le fichier n'est pas bien foutu, il ne faut pas s'occuper des 6000
premières lignes... et pour savoir ce que sont les différentes colonnes, il
y a un fichier "description des données ..." sur la page de data.gouv.fr
il y a comme activité "Réanimation"
il y en a 358 mais certain sont en double ou triple (c'est divisé en
Réanimation pour adultes, pédiatrique et pédiatrique spécialisée et des
établissement ont pour tous).
Dans ce fichier il y a une ligne avec le "Numéro FINESS ET" (le numéro
Finess EJ je sais pas ce que c'est, un id par l'activités de soins sûrement)

Après il faut aller chercher tous les établissements pour avoir plus d'info
sur les établissements ici :
https://www.data.gouv.fr/fr/datasets/finess-extraction-du-fichier-des-etablissements/
il y a un fichier avec la géolocalisation, le numéro de téléphone et
l'adresse de tous les établissements de soins du pays.
le "Numéro FINESS ET" permet de faire le lien entre les 2 fichiers.

Donc on peut relié tous les service de réa a un nom, une géolocalisation ...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osthéopathes

[Jérôme Amagat]

Le jeu. 12 mars 2020 à 19:29, Rpnpif  a écrit :

> Le 12/03/2020 à 12:22, Arnaud Champollion a écrit :
>
>
> Le souci dans un premier temps ce n'est même pas l'absence d'icône, mais
> surtout le fait qu'il n'est pas rendu du tout, et si je comprends bien,
> parce qu'il n'a pas de tag amenity.
>
> Il quasi invisible.
>
> La recherche qu'on peut effectuer avec le point d'interrogation ne permet
> que de trouver le nom du praticien si on sait déjà où il est, et s'il est
> renseigné dans le "name", et qu'on sait déjà que c'est un ostéopathe.
>
> On ne trouve pas non plus en utilisant le champ de recherche.
>
> Au final il n'y a qu'une requête overpass sur
> healthcare:speciality=osteopathy qui permet de trouver.
>
> Certains contributeurs utilisent amenity=doctors, en effet c'est
> discutable du point de vue "médecin".
>
> Certains utilisent écrivent aussi name=ostéopathe, ce qui est incorrect
> mais paradoxalement plus efficace lors d'une recherche (on perd cependant
> le nom du praticien).
>
> Je suppose que c'est la même chose pour les kinés, orthophonistes ... bref
> tout ce qui est concerné par healthcare en dehors de clinic / hospital.
>
> Finalement on a amenity=doctors, amenity=clinic, amenity=hospital. Est-ce
> qu'on peut proposer un nouvel attribut, par exemple amenity=healthcare ?
>
>
> Comme la plupart du temps (au moins autour de chez moi et j'en ai dans ma
> famille), les ostéopathes sont des kinésithérapeutes qui se sont
> spécialisés, je mettrais  healthcare=physiotherapist
> 
> suivi de
> 
> healthcare:speciality
> =osteopathy
> .
> Il n'y a rien d'alternatif là-dedans en 2020. Ou alors dans tous les
> métiers il faudrait mettre alternatif pour les spécialités. Ne soyons pas
> plus intégristes que les intégristes ;).
>
Si l'ostéopathe n'est pas kiné pourquoi mettre healthcare=physiotherapist,
certains sont les 2 mais l'un n'implique pas l'autre.
Et ça ne règle pas le problème, vu que rien n'est rendu pour
healthcare=physiotherapist
non plus...
Et l'ostéopathie va dans healthcare=alternative vu que ce n'est pas une
pratique reconnu par l'académie de médecine et n'a pas prouvé son
efficacité sauf quand sont effectué des gestes de kiné :)

Pour le rendu,
Mon anglais n'est pas très bon et je n'y est pas passé trop de temps et je
comprend pas tout... mais ce que je comprends en lisant les issus du github
avec le mot healthcare :
https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+healthcare
c'est :
Apparemment il y a peu (jusqu'a il y a 1 an) les tag healthcare=* étaient
rendu avec un point ou une valise rouge avec une croix ?
Mais il y avait des problèmes quand c’était une surface donc pour régler le
problème le rendu a été enlevé il y a déjà plusieurs mois et devrait
revenir lors du prochain rechargement de la base de rendu qui ne devrait
plus trop tarder et devrait arriver avec la prochaine version du rendu
Si quelqu'un de plus a même de comprendre ce qui est dit peu vérifier que
je n'ai pas compris de travers :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osthéopathes

[Jérôme Amagat]

Le mer. 11 mars 2020 à 22:52, Marc M.  a écrit :

> Le 11.03.20 à 22:32, Arnaud Champollion a écrit :
> > amenity=doctors ?
>
> cela me semble un bon compris "avoir un rendu sans mettre un faux tag"
>
> Les ostéopathes ne sont ni médecin ni docteur... (Certain médecin sont
ostéopathe)
Par contre amenity=doctors, c'est pour un cabinet médical et je ne sais pas
si les anglais parlent de cabinet médical pour un ostéopathe... en France
je dirait non.
Et l'ostéopathe ce n'est pas de la médecine :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Jérôme Amagat]

Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> 
> (713).
>
>  Ce ne sont pas que des communes nouvelles ! et certaines communes
nouvelles portent le nom d'une ville ou d'un village.

J'ai fait cette requête sur overpass turbo : https://overpass-turbo.eu/s/QFS
On peut faire des truc bien compliqué maintenant ! c'est la première fois
que j'y utilise un if :)

Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
admin_centre.

dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
commune mais qui a sa relation admin_level=8 ?)
sauf un truc (créé par Philippe) une relation admin_level=8 pour le domaine
public maritime dans le golfe du morbillan :
https://www.openstreetmap.org/relation/8687577
relation inutile d’après moi.

Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
(~400) a priori des communes qui n'ont pas bougé ses dernière années.

Il y en a peut être un peu moins que ça, en regardant rapidement je vois
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un
name=Saint-Pierre-d'Entremont (Savoie)
Rémire-Montjoly écrit avec ou sens accens.

Je vois un autre problème non lié aux noms :
"Matis73" a changer des place=village en place=quarter dans les alpes

Comme évoqué par Florimond, il y a le cas des noms de villages et de
communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
ville. Je suis totalement contre les enlever du nom des villages mais que
fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
dans les tête comme un changement du nom de la ville ou du village donc on
les laisse comme nom de commune mais pas plus ou on les intègre au name des
villes et villages ou en alt_name?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Jérôme Amagat]

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> C'est traité de la même façon dans osm.
Comme la grande majorité des communes porte le nom du village (ou la ville)
principal on confond souvent les 2 mais dans osm la commune et le village
sont indiqués de 2 façons différentes.
relation boundary admin_level=8 pour les communes et place=village pour les
village.

Pour des communes fusionnées il y a longtemps avec un nom de commune
différents de celui du village principal, j'ai des cas pas loin de chez moi
:
Hautecourt-Romanèche : https://www.openstreetmap.org/relation/140516
Bohas-Meyriat-Rignat : https://www.openstreetmap.org/relation/140527
fusionnées dans les années 70
Pour les 2, les noms de communes sont l'addition des noms des anciennes
communes.

Pour des communes qui ne porte pas le nom d'un village, je connais Alleuze
: https://www.openstreetmap.org/relation/1223480 qui porte le nom d'un
château en ruine.
J'ai pas d'autres exemples en tête mais il y en a d'autres.

Pour ce qui est de l'utilisation de place=municipality :
l'ajout de la population de la municipalité serait logique.
Mais par contre, ce n'est pas l'admin_centre de la commune. (label ?)
Par contre où placer le node, dans un endroit dégagé pour pouvoir avoir le
nom des villages qui apparaissent aussi, au centre de la commune ou près de
l'admin_centre de la commune ?

:) par contre, 2 règles importantes d'osm serait enfreintes, "One feature,
one OSM element" et "ne pas taguer pour le rendu" :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] limites communales littorales

[Jérôme Amagat]

Les communes ont seulement la compétence de police au niveau des plages
donc pour moi ça ne fait pas partie des communes. La commune s'arrête sur
la ligne de côte à marée haute coef 120. Et même parfois une parti des
terres ne fait pas partie de la commune mais du domaine public maritime.
Pour la ligne de base, ce que je comprend cest qu'elle sert à tracer
d'autres lignes mais pas de différence administratives entre d'un côté ou
l'autre de la ligne.
Ce que je comprends cest que toute la zone maritime est géré par les
préfectures maritimes a partir de la limite fluviale.

Le lun. 27 janv. 2020 à 09:22, Philippe Verdy  a écrit :

> jusqu'à présent on a délimité les communes sur la "ligne de côte" de haute
> mer natural=coastline d'OSM).
>
> Pourtant:
>
> La loi n° 86-2 du 3 janvier 1986 institue au profit des maires des
> communes littorales une police spéciale des baignades et d’utilisation des
> engins de plage jusqu’à 300 mètres de la limite des eaux à l’instant
> considéré.
>
> Et cette définition est en partie indépendante de la définition légale de
> la ligne de base (limite de basse mer, sauf dans les baies fermées par des
> lignes de base définie par décret, mais jusqu'où ne s'étend pas pour autant
> la compétence communale, qui reste à 300 mètres de la ligne de basse mer.
>
> Ne devrait-on pas déjà importer les "lignes de base droites" dont on a des
> définitions précises, et qui délimitent non pas la compétence des
> collectivités locales (communes, et ensembles de communes, y compris les
> assemblées régionales, départementales et territoriales), mais celle des
> préfets de chaque département, c'est-à-dire les eaux intérieures et
> fluviales) ?
>
> D'autre part les préfectures maritimes elles sont compétentes en partie
> sur les eaux intérieures, jusqu'au point de séparation des domaines
> maritimes et fluviaux, sinon jusqu'à la ligne de basse-mer dont on a aussi
> les données sur le SHOM, et jusqu'aux limites de la souveraineté française
> (la ZEE, ou à défaut le plateau continental qui s'applique de droit sans
> dépasser les 200 miles car au delà il faut une négociation internationale
> d'extension du plateau continental en haute-mer); ces préfectures sont
> interrégionales, mais on des sous-directions elles aussi par zones
> interrégionales, qui ensuite se divisent en directions départementales des
> affaires maritimes (pour gérer les relations avec les collectivités
> départementales et régionales et leurs préfectures "terrestres"), mais cela
> reste une organisation du domaine maritime.
>
> Ensuite il faudrait revoir les limites communales jusqu'à 300 mètres de la
> côte, ce qui en simplifierait aussi le tracé. La ligne de base étant bien
> connue du SHOM, de même que les lignes de base droites fermant les baies et
> estuaires ou reliant les îles habitées, ainsi que les îlots côtiers sans
> s'écarter trop de la ligne de côte normale de basse mer.
>
> On a de plus en plus de données du SHOM, on a un beau portail pour toutes
> les limites maritimes. De quoi revoir nos communes littorales sur la ligne
> de base (hors lignes de base droites), éventuellement étendues jusqu'à 300
> mètres pour leur limite de police (limitée à la baignade et l'usage des
> engins nautiques, et la surveillance de la pollution) et avec l'aide aussi
> des points de séparation fleuve/mer du SHOM.
>
>
>
>
> ___
> 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] Intégration supports radio ANFR : différences mast/tower

[Jérôme Amagat]

Le jeu. 9 janv. 2020 à 22:05, François Lacombe 
a écrit :

> Bonjour et merci pour votre retour,
>
> On sera d'accord sur le "escalade dehors ou dedans"
> Mais pour les pylônes auto-stables, l'échelle est à l'intérieur du
> treillis le plus souvent donc c'est plutôt man_made=tower qu'il faudrait
> utiliser
>
> A la différence d'un poteau où il faut y accéder en nacelle
> obligatoirement (man_made=mast)
>
> Je pense que ce qui m'a fait faire ce choix c'est sur le wiki
man_made=mast : https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast
"Unlike a man_made=tower which is accessible and provides platforms, a
man_made=mast only offers ladder steps to climb it on the outside."

et man_made=tower : https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower
"A tower is accessible and provides platforms, whereas a mast only offers
ladder steps to climb it."
et le "often" dans "In comparison a man_made=mast is often a single mast of
concrete or steel."

Mais je suis pas contre un changement, j'ai pas d'avis...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[Jérôme Amagat]

C'est moi qui est fait ces choix pour osmose.
J'ai fait ce choix personne n'en a parler sur la discussion sur le github
d'osmose donc c'est resté comme ça.
La lecture des pages du wiki pour man_made=mast et man_made=tower m'a fait
faire ce choix.
Ce que j'ai compris c'est comme dit marc marc : tower si il y a un
intérieur ou au moins des plateformes et mast sinon donc pour les pylônes
j'ai mis mast. man_made=tower serait plutôt pour ce que l'on appelle en
français des "tours" donc pas trop les pylônes.
Le problème c'est que ce n'est pas en accord avec power=tower. Et peut être
pas trop avec les définitions de tower et mast ...

le code est là :
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_radio_support_FR.py




Le jeu. 9 janv. 2020 à 01:46, marc marc  a
écrit :

> Le 09.01.20 à 01:39, François Lacombe a écrit :
> > Je n'ai pas beaucoup participé aux discussions
>
> de mémoire, sur tagging, la différence avait surtout été mis
> sur comment on y monte : mat par dehors, polygone par dedans.
> ___
> 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] Ces raccourcis JOSM que l'on découvre "trop tard"

[Jérôme Amagat]

Le sam. 4 janv. 2020 à 22:27, Vincent de Château-Thierry 
a écrit :

>
> Le 04/01/2020 à 15:03, Georges Dutreix via Talk-fr a écrit :
> > Le 04/01/2020 à 13:06, Sébastien Dinot a écrit :
> >> Christian Quest a écrit :
>
> > J'en ai découvert un récemment que je trouve très utile.
> >
> > *Maj-U / Unselect nodes*
> > Si on veut déplacer une grosse poignée de maisons pour les repositionner
> > sur BD Ortho IGN par exemple, une sélection rectangulaire attrape des
> > noeuds d'autres bâtiments, de rues, ou des POIs. Maj-U ne conserve que
> > des "ways".
> >
> > il nécessite utilsplugin2 :
> > https://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2
>
> Merci je ne connaissais pas. Pour un besoin identique (sélectionner des
> bâtiments) j'apprécie Maj-E qui sélectionne les ways adjacents à la
> sélection. Quand on pense avoir sélectionné tous les buildings
> partageant des nœuds afin de les déplacer en cohérence, un coup de Maj-E
> permet de garantir que *tous* bougeront ensemble.
>
> Je profite du fil et de l'illustration partagée par Vincent (merci :) )
> pour évoquer que je n'ai jamais réussi à faire fonctionner les
> raccourcis qui sont des chiffres (Zoom sur le calque, la sélection, zoom
> précédent, etc) sous Ubuntu, alors que je m'en sers sous Windows. Je ne
> sais pas si c'est juste moi (mais même constat sur plusieurs postes), ou
> si c'est connu ? (je n'ai pas regardé dans le trac de josm avant de poster)
>
> J'ai le même problème, sous ubuntu aussi, j'ai modifié les raccourcis en
mettant pour le 3 "Zoom la sélection" (celui que j'utilise le plus) :
"guillemets". pour le 1 "Zoom sur donnée" c'est "esperluette" pour le reste
je sais pas et je les utilises pas...

sinon ceux que j’utilises :
"F" et "alt + X " je les utilises beaucoup
maj + R : ajouter les tags de la sélection precedente
maj + J : fusionner 2 surfaces, utile par exemple quand on ajoute le bati
avec le cadastre et qu'il faut fusionner des bâtiments
ctr + alt + V : coller un ou plusieurs objets (node way ou relation) dans
un calque que l'on a copié (ctr + c) dans un autre calque (pareil bien
utile pour ajouter des bâtiments avec le cadastre charger dans un autre
calque)
ctr + maj + V : coller les tags de l'objet que l'on a copier avant (ctr + c)
ctr + maj + G : remplacer la géométrie
+ et - : pour zoomer et de-zoomer :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

[Jérôme Amagat]

J'ajoute que je ne suis pas contre le fait de ce servir de ces lieu dit du
cadastre pour ajouter des place=* ou d'autre chose dans osm, je le fait
régulièrement mais j'aimerai qu'il y ai un peu de réflexion avant
d'importer, si le nom contient château vérifié que ce n'est pas le nom d'un
château présent pas loin, pareil pour un moulin, un bois... vérifier si
c'est le nom d'un groupe d'habitation ou des terrain à coté...

Pareil pour fantoir, c'est pas parce que c'est présent dans cette base de
donnée que ça a obligatoirement sa place dans osm, il y a pas mal d'erreur
présentes ou des chose qui n'existe plus

Le ven. 3 janv. 2020 à 15:06, Jérôme Amagat  a
écrit :

>
>
>> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma
>> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans
>> osm, non ?
>>
>> C'est pour ça que j'ai écrit : "quand le château existe encore et que le
> terme désigne seulement ce château". pareil pour les moulins.
>
> Sinon, 820  place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en
> sûrement quelques uns de légitime mais pas la plupart)
> https://overpass-turbo.eu/s/Pqj
> dont plus de la moitié place=locality
> Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est
> écrit sur le cadastre
>
> Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe)
> et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué
> que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un
> hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en
> approche le plus sur la commune...
>
> Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2
> ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..."
> mais là parce que c'est soit disant ancien on se fout de savoir si c'est
> encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le
> cadastre.
> Et donc il y plein de communes ou les lieux dit du cadastre on été importé
> directement sans vérification, tous ou presque avec place=locality, placé
> là où c'est écrit sur le cadastre même si on est très loin du lieu réel.
> Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il
> est pas conseillé d'importer les adresses sans vérification. Pour les
> rivières pressentent sur le cadastre il y avait des restrictions à son
> import dans osm.
> Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il
> faut vérifier.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

[Jérôme Amagat]

>
> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma
> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans
> osm, non ?
>
> C'est pour ça que j'ai écrit : "quand le château existe encore et que le
terme désigne seulement ce château". pareil pour les moulins.

Sinon, 820  place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en
sûrement quelques uns de légitime mais pas la plupart)
https://overpass-turbo.eu/s/Pqj
dont plus de la moitié place=locality
Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est
écrit sur le cadastre

Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe)
et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué
que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un
hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en
approche le plus sur la commune...

Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2
ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..."
mais là parce que c'est soit disant ancien on se fout de savoir si c'est
encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le
cadastre.
Et donc il y plein de communes ou les lieux dit du cadastre on été importé
directement sans vérification, tous ou presque avec place=locality, placé
là où c'est écrit sur le cadastre même si on est très loin du lieu réel.
Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il
est pas conseillé d'importer les adresses sans vérification. Pour les
rivières pressentent sur le cadastre il y avait des restrictions à son
import dans osm.
Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il
faut vérifier.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

[Jérôme Amagat]

Oui pour virer les point cardinaux mais il n'y en a d'autres que je n'aime
pas. Qui sont là juste pour remplir le cadastre avec des lieu dit.
"sous un autre lieu dit", les prés de un autre lieu dit" ... peut être que
parfois ça a vraiment une utilité mais pour moi c'est la même chose que les
points cardinaux.
"Le bourg"  si c'est le village de la commune, il faut mettre son nom pas
besoin d'un lieu dit qui porte le nom "le bourg"
"Le château", quand le château existe encore et que le terme désigne
seulement ce château, il faut mettre les bons tags et nom sur le bâtiment
mais pas besoin d'ajouter un lieu dit.
Pareil pour les moulins (et sûrement d'autres choses du même style)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

[Jérôme Amagat]

Le mer. 1 janv. 2020 à 17:27, Yves P.  a écrit :

>
> Il semble que tu n'as pas compris comment fonctionne ces polygones et même
> s'ils portent le même "nom" ils ont des attributs différents pour
> différentes choses homonymes et ne couvrant pas la même chose (département
> ou région, commune ou arrondissement ou canton ou circonscription
> législative ou académie ou île...). Chacune joue un rôle parmi les autres
> de même type.
>
> La *question principale* était comment passer de 3 traits de côtes à 1
> seul ?
> Le Parc national doit faire ses relevés à marée basse, le SHOM à marée
> haute et les contributeurs OSM après un Ti’ punch
>

Le SHOM c'est marée haute coefficient 120 (le plus haut sans tempête) et
c'est aussi (dans la quasi totalité des cas) la limite des communes, des
départements et des régions.
natural=coastline dans osm c'est pas super clair d’après le wiki
c'est "Mean high water springs" j'ai toujours pas compris si c’était la
moyenne des marées hautes ( donc un coef 95) ou la moyenne des plus hautes
marées hautes donc coef 120 comme le SHOM.
Pour les parc régionaux, c'est un regroupement de commune donc je dirais
que c'est la même limite que les communes mais pour les parcs nationaux, je
ne sais pas :(


>
> La *question secondaire* portait effectivement sur ces polygones
> homonymes :
>
> J’avoue, j’ai regardé uniquement et rapidement les relations Bouillante
>  
> (commune)
> et Bouillante (canton de Saint-Rose-1)
> 
> Le découpage du canton me paraissait bizarre à vu d’oeil dans sa partie
> sud.
>

erreur assez fréquente (j'annule des changements de temps en temps), penser
que la relation du canton qui porte le nom d'une commune (c'est presque
partout le cas) est là pour représenter une commune. c'est 2 chose
distinctes même si le nom est le même. Là c'est un peu différent, c'est une
relation pas pour le canton mais pour la parti d'une commune qui fait parti
d'un canton, je n'aime pas bien c'est relation, je trouve que la relation
du canton suffit, et si l'on veux retrouver cette parti du canton on a les
relation des communes, c'est Philippe Verdy qui a créé ces relations un peu
partout en france.

>
> Pour les relations Guadeloupe, 2 semblent avoir la même géométrie (1047206
> 
>  et 2562137
> )
> avec des admin_level respectivement de 6 et 4.
> La 3eme (7109289
> ) 
> contient
> uniquement Basse et Grande Terres (sans Marie-Galante, La Désirade et les
> îlets).
>

Une relation pour la région, une pour le département et une pour l'île, en
réalité pas l'île, puisque la Guadeloupe au sens géographique c'est 2 îles
donc cette relation a place=archipelago comme tag et ne contient pas les
autre îles.
Pour la Guadeloupe, il y a toujours une région et un département, mais il y
a plusieurs cas où les 2 ont fusionné en Collectivité territoriale unique
https://fr.wikipedia.org/wiki/Collectivit%C3%A9_territoriale_unique
Pour coller à cette nouvelle réalité, il y a peu être des changements à
faire dans osm. Pour Martinique, Guyane et Mayotte, il n'y a plus de raison
d'avoir de relation admin_level=6. Pour la Corse, c'est différent, il n'y a
plus les 2 départements mais encore les 2 préfectures...

>
> Ma *question secondaire était en fait *: Peut-on définir une seule fois
> la géométrie avec par exemple 1047206
> ,
> et inclure cette relation dans 2562137
>  ?
> Ainsi, on se retrouve avec moins de relations au niveau d’une ligne de
> côte par exemple.
> Ça me semble plus simple à comprendre et plus simple à maintenir ?
>
> Et de même, la relation Guadeloupe pourrait contenir uniquement les
> relations Grande-Basse-Terre, Terre de Bas, Terre de Haut… ??
>

Non c'est pas l'usage dans osm, il faut rappeler tous les way dans toutes
les relations.

>
> —
> Yves
>
> Je viens de regarder le découpage du canton de Saint-Rose-1 par rapport au
> texte officiel : ça colle vaguement.
>
> Soit l’import ? d’origine est trop simplifié, soit le polygone a été abimé.
> Il semble que ce soit le premier cas d’après cette requête overpass
>  (pas de changement visible depuis 3
> ans).
>
> *3° La partie de la commune de Bouillante située au nord d'une ligne
> définie par l'axe des voies et limites suivantes : depuis le littoral
> occidental, rivière Celleron, route de la Lézarde (direction Sud-Ouest),
> rue René-Turlet (direction Sud), rue Maurice-Selbonne (direction Sud-Est),
> chemin Deravin, segment de 89 mètres reliant les deux points de longitude
> et latitude respectives 

Re: [OSM-talk-fr] modif canton en Charente-Maritime par création de commune nouvelle

[Jérôme Amagat]

6 cantons modifiés dans le texte mais que 2 sur le terrain, je pense qu'il
n'y a que l'article 1 d'important ici :
https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=9C9FBC41E4699E40F4E6E33309B3AF52.tplgfr43s_1?cidTexte=JORFTEXT39356426=20191109
Je pense que l'article 1 donne les réels modifications, le reste c'est une
modification des noms des communes dans le décret ayant créé les cantons.
Lors d'une création de commune nouvelle, il faut supprimer les noms des
anciennes communes et ajouté le nom de la commune nouvelle donc rien ne
change si les anciennes communes était déjà toutes dans le même canton.

Le sam. 28 déc. 2019 à 16:10,  a écrit :

> Bonjour, non je ne crois pas qu'il a été exhaustif : je vois que le décret 
> Décret
> n°2019-1154 du 7 novembre 2019 - art. 2
> <https://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=89A1CF7E151E4165319BA57C8EBC7B9D.tplgfr43s_1?cidTexte=JORFTEXT39356426=LEGIARTI39359767=20191109=id#LEGIARTI39359767>
> a modifié 6 cantons dans le Morbihan et il en reprend 2 :
>
> https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28655882
>
> https://www.openstreetmap.org/changeset/76870512
>
> Peut-être que d'autres ont fait les mises à jours mais les dernières
> modifs d'Olyon ne portait pas dessus : cantons n° 3 (Grand-Champ
> <https://www.openstreetmap.org/relation/3975931>) , n° 4 (Guer
> <https://www.openstreetmap.org/relation/3590071>), n° 15 (Pontivy
> <https://www.openstreetmap.org/relation/3975942>), n° 18 (Séné
> <https://www.openstreetmap.org/relation/3975945>).
>
> Jean-Yvon
> Le 28/12/2019 à 15:43, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Il y a eu d'autres décrets de ce type pour d'autres départements le 7
> novembre et il semble que OD02fr (
> https://www.openstreetmap.org/user/OD02fr/history) a fait toutes les
> modifications.
>
> Le sam. 28 déc. 2019 à 15:21, Jérôme Amagat  a
> écrit :
>
>> Bonjour,
>>
>> Je viens de faire la modification, l'ancienne commune de Vandré change de
>> canton.
>>
>> Normalement aucune commune nouvelle cette année, interdit l'année
>> précédant une élection d’après la page Wikipédia sur les communes nouvelles.
>> https://fr.wikipedia.org/wiki/Commune_nouvelle#%C3%89volution_future
>>
>> Le sam. 28 déc. 2019 à 12:38, David Crochet  a
>> écrit :
>>
>>> Bonjour
>>>
>>>
>>> https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT39683206==id
>>>
>>> Cordialement
>>>
>>> --
>>> David Crochet
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] modif canton en Charente-Maritime par création de commune nouvelle

[Jérôme Amagat]

Il y a eu d'autres décrets de ce type pour d'autres départements le 7
novembre et il semble que OD02fr (
https://www.openstreetmap.org/user/OD02fr/history) a fait toutes les
modifications.

Le sam. 28 déc. 2019 à 15:21, Jérôme Amagat  a
écrit :

> Bonjour,
>
> Je viens de faire la modification, l'ancienne commune de Vandré change de
> canton.
>
> Normalement aucune commune nouvelle cette année, interdit l'année
> précédant une élection d’après la page Wikipédia sur les communes nouvelles.
> https://fr.wikipedia.org/wiki/Commune_nouvelle#%C3%89volution_future
>
> Le sam. 28 déc. 2019 à 12:38, David Crochet  a
> écrit :
>
>> Bonjour
>>
>>
>> https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT39683206==id
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>> ___
>> 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] modif canton en Charente-Maritime par création de commune nouvelle

[Jérôme Amagat]

Bonjour,

Je viens de faire la modification, l'ancienne commune de Vandré change de
canton.

Normalement aucune commune nouvelle cette année, interdit l'année précédant
une élection d’après la page Wikipédia sur les communes nouvelles.
https://fr.wikipedia.org/wiki/Commune_nouvelle#%C3%89volution_future

Le sam. 28 déc. 2019 à 12:38, David Crochet  a
écrit :

> Bonjour
>
>
> https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT39683206==id
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Idée folle : changer building=service en building=utility lorsqu'applicable

[Jérôme Amagat]

Le mer. 18 déc. 2019 à 00:29, François Lacombe 
a écrit :

> Bonsoir Jérôme,
>
> Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
> écrit :
>
>>
>> C'est joli mais qu'est ce que ça apporte de plus comme info que
>> building=service + power=substation + substation=minor_distribution ?
>>
>
> Avec building=service, on se sais pas de quel service il peut s'agir.
> Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
> de fois).
>
> Il est réellement intéressant de pouvoir construire des chaînes comme ce
> que je montrais dans le mail du dessus.
> Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
> les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
> comme power=substation et il peut en oublier.
>

Donc si on suis cette logique, il faut changer en building=tourism tous les
hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
école... pour avoir une belle chaîne de tag.

>
>
>>  L'architecture d'un garage est le plus souvent très éloigné de celle
>> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
>> un autre garage, une grande porte, pas ou seulement des petites ouverture,
>> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
>> building=service on peut faire la même chose, il y a sûrement plus de cas
>> différents que pour le garage.
>> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
>> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
>> par exemple de laissé building=church même si ça ne sert plus de lieu de
>> culte et il faudrait laissé building=garage même si le bâtiment est devenu
>> (sans trop de modif) une habitation...
>>
>
> Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
> building=garage si celui-ci deviens une habitation?
>

On le laisse comme on laisse building=church sur une église reconverti en
musée, habitation...
C'est la plupart du temps la destination première du bâtiment que l'on met
dans building=* mais si l'utilisation change le tag building=* ne doit pas
changer.
la page du wiki donne le tag building:use=* pour l'usage (
https://wiki.openstreetmap.org/wiki/Key:building) mais je ne n'ai jamais
utilisé ce tag.
La plupart du temps l'usage on l'ajoute avec d'autre tag, un bâtiment qui
sert de restaurant c'est amenity=restaurant quelque soit le tag building=*


> Il y a bien des silos de lancement de missiles balistiques qui deviennent
> des appartements, on voit de tout.
>

le bâtiment doit être tagué avec building=missile silo ou quelque chose
comme ça.

>
>
>> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
>> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
>> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
>> musée c'est building=church + tourism=museum il n'y a pas besoin de
>> building=tourism ou autre chose.
>> On peut privilégié une valeur comme building=utility lorsque le bâtiment
>> a été construit à cet effet mais je pense que building=service a l'avantage
>> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>>
>
> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
> comprendre, non
> Service ça veut tout et rien dire, vraiment.
>

C'st plus facile à comprendre que "utility" !


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>

Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
building=warehouse.


> Même si le wiki semble utiliser building=service pour building=utility, je
> ne suis pas sûr en plus que toutes les occurrences soient concernées par le
> changement proposé. Certains bâtiments ne doivent pas être des sites
> techniques d'utilités à proprement parler.
>
> Bref, il y a besoin d'en discuter encore un peu
>
> Bonne soirée
>
> François
>
>
>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Joli noms de rues

[Jérôme Amagat]

Le lun. 16 déc. 2019 à 07:59, Yves P.  a écrit :

>  je me demande dans quel état ils étaient quand ils ont choisi les noms de
> rues
> Pour une bonne parti des rues, ils leurs ont donné comme nom, d'où à où
> elles vont.
>
> Bienvenue à la campagne 
> Les chemins doivent être nommés comme ça depuis quelques centaines
> d’année 
> Et un jour il y a du goudron, et même des gens qui y habitent… des *r*urbains
> qui sait ? 
>
> C’est assez courant, dans le Doubs, Jura… Ces chemins desservent des
> pâtures occupées par des bovins (le truc blanc à tâches noires avec des
> cornes), ou des sapins pour le Jura.
> Quand il y a des lotissements qui se construisent (si, si) le bout de
> route est renommé pour faciliter la vie des dégommeurs de rouge sur Bano.
> Peut-être pour les livreurs d’Amazon qui se risquent dans ces contrées.
>
> La campagne et les vaches je connais, d’ailleurs c'est pas mal réducteur
blanc à taches noires (et même avec des cornes, elles en ont de moins en
moins ...) .
Je veux bien des exemples de communes avec ce genre de rues, ces dernières
années j'ai ajouté un bon paquets de noms de rues dans osm et j'avais
jamais vu ce genre de chose. Des "route de machin à truc" ça oui mais des
"Moulin Mairie Mairie Prairie".

Dans plein de village, ils donnent des noms aux rues seulement parce que
c'est devenu une obligation. Mais je me place en temps qu'habitant (on
n'utilise pas tous les jours son adresse mais c'est pas rare non plus), je
préférerai que la commune face dans les classiques "rue de la mairie", "rue
de l'église", "route de machin" (avec "machin" le village, hameau ou autre
chose sur la route) voir les classiques rues avec un nom de fleur, d'arbre
ou d'oiseau plutôt que ce qu'a fait cette commune ou "rue du hangar
communal" ou "rue du lagunage" trouvé récemment. "Rue du cimetière" je suis
pas fan non plus, le "rue du Repos pour ne pas dire "cimetière" est un peu
mieux...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Joli noms de rues

[Jérôme Amagat]

En ajoutant des noms de rues, je suis tombé sur la commune de Saint-Bénigne
dans l'Ain et je me demande dans quel état ils étaient quand ils ont choisi
les noms de rues et j'ai vérifié sur google street view, parce que je
pensais à une erreur, ils ont même payé puis installé des panneaux avec ces
noms donc ces gens (maire, conseillers municipaux, employés municipaux)
doivent être bourré à longueur de journée 
La commune avec les noms de rues :
https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=01337
Un exemple sur google street view :
https://www.google.com/maps/@46.4454723,4.9740272,3a,16y,149.3h,86.28t/data=!3m6!1e1!3m4!1sNJR0AECvhwrGvItf392nmg!2e0!7i13312!8i6656

Pour une bonne parti des rues, ils leurs ont donné comme nom, d'où à où
elles vont. Par exemple, "Léal Le Bourg" est une rue qui va du bourg de
Léal au bourg :)
Donc des gens habitent au "1814 Léal Le Bourg" mais ils n'habite pas à Léal
mais dans le bourg...
Mais la meilleur c'est "Moulin Mairie Mairie Prairie" :)
ça doit être marrant les tête des gens quand lorsque l'on te demande ton
adresse tu leur dis "1332 Moulin Mairie Mairie Prairie à Saint-Bénigne"
Je l'ai pas trouvé sur street view comme d'autres donc je suis pas sur que
tous ces noms de rues sont vraiment utilisés.
Il y en a d'autre avec "mairie" , "Mairie Vignes des Mares" et "Mairie
Terres de l'Alouette"

Il y a aussi, avec une forme plus classique, un "Voie du Château d'eau",
lorsque je l'ai lu, j'ai tout de suite pensé à un truc qui fuit :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le dim. 15 déc. 2019 à 20:20,  a écrit :

>
> Le 15/12/2019 à 10:46, Vincent de Château-Thierry - osm.v...@free.fr a
> écrit :
>
> https://dev.cadastre.openstreetmap.fr/fantoir/anomalies_fantoir.html
>
> Il faudra à terme ajouter la même analyse pour les ways et relations.
> C'est juste un début (et peut-être pas bien sec), vos retours bienvenus.
>
> Pas bien sec, en fait entre temps vdct a continuer de peindre sur les ways.
>
> Et là ce n'est pas très sec effectivement :
>
>
> https://dev.cadastre.openstreetmap.fr/fantoir/anomalies_fantoir.html#dept=56
> Loyat (56122) w444982747 Rue Vilette 56122091V ORG
> 
> FR
> 
> BANO
> 
> JOSM ID
> 
> P2
> 
>  Fantoir-OSM
> 56122
>  Fantoir
> brut 56122
> 
>
>
> 56122091V n'est pas le code FANTOIR mais le code dans la base OSM.
>
> https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=56122=1
>
> 561220*1*91V est le code FANTOIR... à mettre dans OSM (c'est fait).
>
La page indique les erreurs donc normal qu'il y ai une erreur dans le code
dans osm. Je pense qu'il faudrait remplacé le nom de la colonne "fantoir"
par "ref:FR:FANTOIR" pour bien indiquer que c'est le code présent dans osm
et pourquoi pas, de proposer un bon code si il y a un rapprochement de fait
dans la page de la commune, si c'est pas trop compliqué à ajouter :)


> Carnac (56034) w392349976 Village de Kergrim 56234B931N ORG
> 
> FR
> 
> BANO
> 
> JOSM ID
> 
> P2
> 
>  Fantoir-OSM
> 56034
>  Fantoir
> brut 56034
> 
> Carnac (56034) w476504665 Village de Kergrim 56234B931N ORG
> 
> FR
> 
> BANO
> 
> JOSM ID
> 
> P2
> 
>  Fantoir-OSM
> 56034
>  Fantoir
> brut 56034
> 
> Carnac (56034) w476504664 Village de Kergrim 56234B931N ORG
> 
> FR
> 
> BANO
> 
> JOSM ID
> 
> P2
> 
>  Fantoir-OSM
> 56034
>  Fantoir
> brut 56034
> 
> Carnac (56034) w476504662 Village de Kergrim 56234B931N ORG
> 
> FR
> 
> BANO
> 
> JOSM ID
> 
> P2
> 
>  Fantoir-OSM
> 56034
>  Fantoir
> brut 56034
> 
>
> Là 

Re: [OSM-talk-fr] Import du cadastre, Bano, toussa toussa

[Jérôme Amagat]

Le dim. 15 déc. 2019 à 18:01, Donat ROBAUX  a écrit :

> Salut à tous,
>
> Grâce au travail important de VdCT pour nous mettre en prod Bano V2, ca a
> relancé la machine sur les voies récentes
> http://dev.cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html
>
> Du coup, import de cadastre sur des nouveaux lotissements. Mais, j'ai des
> soucis.
> Avec l'import via Josm, soit j'ai toute la feuille (cool) (voire souvent
> plus que ce je demande, soit j'ai rien du tout, soit j'ai pas tous les
> bâtiments de la feuille.
>

Moi quand ça fonctionne pas avec le plugin josm, je vais chercher la
commune là : https://cadastre.data.gouv.fr/datasets/cadastre-etalab
(Il faut rajouté les tag building=yes, wall=no et source=*)
Par contre on a de nouveaux fichiers que tous les trimestres. Je pense que
c'est le problème quand il manque que certains bâtiments dans une feuille
avec le plugin, ils sont tout neufs et ajouté au cadastre après la dernière
version donc pas présent dans les fichiers dont ce sert le plugin.

(avec cadastre.openstreetmap.fr c'est la version la plus récente mais je ne
l'ai pas utilisé depuis un bon moment )

Du coup, je me rabats sur l'historique méthode via
> cadastre.openstreetmap.fr, mais quand je veux sélectionner une zone, c'est
> la page blanche.
>
> Du coup je suis un peu bloqué parce que pour l'instant aucun outil à part
> les notes ne nous permet véritablement de nous créer une alerte pour
> repasser sur une zone. Alors si je mappe la voie pour améliorer la carto
> OSM
> (et au passage "dégommer du rouge"), on ne verra que beaucoup plus tard
> qu'il faut importer le cadastre.
>
> Avez-vous ce type de difficultés avec l'import du cadastre?
>
> Donat
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[Jérôme Amagat]

Le dim. 15 déc. 2019 à 18:41, François Lacombe 
a écrit :

> Bonjour Stéphane
>
> Le dim. 15 déc. 2019 à 11:35, Stéphane Péneau 
> a écrit :
>
>> Salut,
>>
>> building=* est censé donner des informations sur *le type de bâtiment*.
>> J'ai l'impression que building=utility donne plus d'information sur ce
>> qu'il y a à l'intérieur que sur le bâtiment en lui-même, non ?
>> Tu peux me rétorquer qu'il en est un peu de même pour d'autres valeurs de
>> building. Oui, tu peux :-)
>>
>
> La question clé est : qu'est-ce que le type de bâtiment ? Y en a-t-il
> qu'un seul?
> C'est pour cette raison que je n'aime pas employer "type" dans les tags.
> Heureusement building:type est déprécié
> https://wiki.openstreetmap.org/wiki/Key%3Abuilding%3Atype
>
> On peut très bien chercher à classifier les bâtiment selon leur mode de
> construction, structure, destination,...
> Ce que je sais c'est que building=service ne nous dit pas de quel espèce
> de service il s'agit.
> Avec building=utility, on sera capable de fermer la chaîne sémantique avec
> des enchaînements building=utility + utility=power + power=substation +
> substation=minor_distribution
> => Avec une petite chaîne comme celle-ci on règle d'un coup et durablement
> la gestion immobilière d'Enedis, la qualification des locaux pour la DGFip
> et la consolidation du foncier pour les communes qui collectent des taxes
> d'occupation du domaine public.
>

C'est joli mais qu'est ce que ça apporte de plus comme info que
building=service + power=substation + substation=minor_distribution ?

>
> building=utility te renseigne uniquement sur la destination (comme
> building=garage) sans te dire ce qu'il y a à l'intérieur.
> Une station de pompage et un poste de transformation de quartier sont tous
> les deux éligibles à building=service / building=utility, pourtant le
> contenu et l'activité associée seront très différents
> utility=power vs utility=water sont là pour apporter un début de
> distinction par ailleurs.
>
>  L'architecture d'un garage est le plus souvent très éloigné de celle
d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
un autre garage, une grande porte, pas ou seulement des petites ouverture,
bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
building=service on peut faire la même chose, il y a sûrement plus de cas
différents que pour le garage.
Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
par exemple de laissé building=church même si ça ne sert plus de lieu de
culte et il faudrait laissé building=garage même si le bâtiment est devenu
(sans trop de modif) une habitation...

Je ne remplis que très rarement d'autre chose que "yes" ce tag :)

Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
peut déjà le faire avec d'autres tags, par exemple, une église convertie en
musée c'est building=church + tourism=museum il n'y a pas besoin de
building=tourism ou autre chose.
On peut privilégié une valeur comme building=utility lorsque le bâtiment a
été construit à cet effet mais je pense que building=service a l'avantage
d'être plus simple à comprendre et est déjà beaucoup utilisé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le sam. 14 déc. 2019 à 18:34, Yves P.  a écrit :

> @Jérôme
>
> Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je
> n'ai pas trop cherché non plus) donc je ne m'en suis pas occupé
>
>
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>
>- la clé de contrôle (1 lettre de l'alphabet sans I, O et Q ; ce
>caractère n'est pas distinctif mais sa présence reste recommandée).
>
>
> mais si il n'y en a qu'un dans osm c'est que ça doit être vrai.
>
> ?
> J’ai trouvée une seule valeur avec la clé incorrecte (lettre I)
> Mais en recalculant la clé et en la comparant avec celle se trouvant dans
> la valeur, on devrait vérifier qu’il n’y a pas eu d’erreur de saisie
>
> Je n'ai pas trouvé non plus comment cette lettre est obtenu. Donc
> [A-HJ-NPR-Z] ça me semble pas mal
>
> Je n’ai rien trouvé d’officiel. Heureusement quelqu’un a trouvé la réponse
> : https://georezo.net/forum/viewtopic.php?id=102292
> J’essaie de recalculer cette clé (en sachant quelle utilise le code
> direction qui ne figure plus dans OSM)
>
> Pas des plus facile à calculer :)
Je le dit à ma façon parce que pour moi c'était pas clair tout de suite sur
ton lien :

Si on a un code sur 11 caractères : XXYZZZ (ici ça en fait 10 mais il
manque la clé a la fin)
il faut faire ( XX * 19 + Y * 11 + ZZZ ) modulo 23 avec pour Y si c'est
une lettre il faut la changé en 10 pour A, 11 pour B 
Et le résultat on le change en lettre avec A pour 0, B pour 1 ... en
sautant I,O et Q

par exemple, pour ce code 010053B003B (que l'on trouve là :
https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=01053=4),

ça donne (10053*19+11*11+3)modulo 23 = 1 donc B

C'est pas simple mais j'ai vérifié pour plusieurs valeurs dont certaine
avec un code direction différent de 0 et ça marche :)

Mais je suis pas sur que ça nous serve pour osm, il faudrait mieux vérifier
que les valeurs de ref:FR:FANTOIR que l'on a dans osm sont bien présentes
dans la source officielle.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le sam. 14 déc. 2019 à 12:40, XavierBizot22440 
a écrit :

> La ref:FR:FANTOIR est à renseigner dans le tag highway nous sommes
> d’accord ?
>
> Sur ma commune je l’ai inséré dans la relation et non dans le highway
> est-ce convenable ? ou surtout pas ?
>
> Dans la relation, c'est ce qu'il faut faire. sauf si elle n'existe pas
alors sur le way.


"Et en plus incomplète : elle n’exclue pas les caractères I, O et Q de la
clé de contrôle.
Elle devrait donc se terminer par [A-HJ-NPR-Z]$ ou par [^IOQ0-9a-z?]$

Dans les données, je n’en ai trouvé qu’une (et il manque 1 caractère)
: 12300340I

De plus, on devrait vérifier la validité de la valeur FANTOIR en
recalculant la clé.
L’algorithme est-il publié quelque part ?"

Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je
n'ai pas trop cherché non plus) donc je ne m'en suis pas occupé mais si il
n'y en a qu'un dans osm c'est que ça doit être vrai. Je n'ai pas trouvé non
plus comment cette lettre est obtenu. Donc [A-HJ-NPR-Z] ça me semble pas mal

Et bien vu la recherche sur taginfo, je n'y avais pas pensé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le sam. 14 déc. 2019 à 01:38, Jérôme Amagat  a
écrit :

>
>
> Le ven. 13 déc. 2019 à 22:55,  a écrit :
>
>> Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à
>> 11 chiffres (ou 11, un point-virgule et 11).
>>
> Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça
> donne ça :
> https://overpass-turbo.eu/s/OXy
>
> et même plus précis :
> https://overpass-turbo.eu/s/OXB
>

J'ai mis l'expression régulière utilisée, là :
https://wiki.openstreetmap.org/wiki/Item:Q600
et j'ai ajouté une phrase sur le wiki dès le début de la page pour dire
qu'il faut 10 caractères :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le ven. 13 déc. 2019 à 22:55,  a écrit :

> Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à
> 11 chiffres (ou 11, un point-virgule et 11).
>
Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça
donne ça :
https://overpass-turbo.eu/s/OXy

et même plus précis :
https://overpass-turbo.eu/s/OXB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en
région parisienne, il y en a aussi à Dunkerque et autour avec le code
direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de
code direction 0 et aussi des fautes de frappe. Mais il y en reste encore.
Si ça tente des gens de continuer les corrections, on trouve les codes de
11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères :
https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé
par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération
nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code
rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent),
on pourrait ajouter le code insee de la commune avant le code déjà présent
mais on aurait que les 9 1er caractères et il manquerait le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses
car il y a après le code : "-le numéro" donc pour faire ça comme il faut il
faudrait avec ces numéros créer les relations associateStreet pour y placer
le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute
la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Bonjour,

D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
https://overpass-turbo.eu/s/OSX

Il y en a beaucoup dans l'Ain ajouté par chabe01 (
https://www.openstreetmap.org/user/chabe01), je vois aussi qu'il a ajouté
tous récemment des ref:FR:FANTOIR=* avec 11 caractères en région
parisienne. Et j'ai l'impression qu'il ajoute un 0 entre le département et
le code commune comme il est dit dans le wiki.

Déjà il faudrait le contacter pour lui dire qu'il commet une erreur et que
les outils https://dev.cadastre.openstreetmap.fr/fantoir/ sont bien utiles
pour l'ajout des adresses, il n'a pas l'air de les utiliser :)
Si ça tente quelqu'un de le contacter et de chercher si d'autres
contributeurs commette cette erreur.

Mais aussi, je pense qu'il faudrait faire une modification de masse pour
enlever ce caractère en trop mais tout ne viens pas de lui et comment bien
choisir les ref qui ont ce 0 en trop ?

Faut il obligatoirement 10 carractères ?

Il y a aussi beaucoup de valeur de ref:FR:FANTOIR qui n'ont ni 10 ni 11
caractères : https://overpass-turbo.eu/s/OSZ
Il y en a qui ne sont pas faux : plusieurs code séparer par des ";"
Il y a je pense des valeurs avec seulement le code rivoli sur 4 caractères.
Pour certain il y a un fantoir avec "-" suivie de 1 ou plusieurs caractères
derrière.


Comment pourrait on améliorer tout ça ? :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

[Jérôme Amagat]

Le sam. 30 nov. 2019 à 10:37, Yves P.  a écrit :

> le validateur de JOSM corrige cette erreur, les _ à la place d'espace.
> L'erreur est indiqué par le validateur et "réparer" remplace les _ par des
> espaces.
>
> Oui, le problème comme tu l’indiques plus bas et de faire les corrections
> sans s’attirer les foudres des communautés OSM
>
> Moi aussi je me suis fais plusieurs fois taper sur les doigts parce que
> j'envoyais des données sur plusieurs continent en même temps :) , ça plaît
> pas à certains qui, avec je sais plus quel outils, suivent les changset sur
> leur zones et donc un changset mondial, ça bip chez tout le monde :). Mais
> je pense pas qu'il y ai besoin de couper par pays, par "région" qui peut
> englober plusieurs pays ça suffit.
>
> Pas toujours 
> Je connais un contributeur qui utilise OSMcha  pour
> « surveiller » un territoire de métropole, et un changeset qui couvre toute
> la France va être détecté, même si il n’y a aucune modifications dans son
> territoire.
>

Oui c'est pour ça que je pense que la découpe par pays ce n'est pas le plus
intéressant, il faut découper l'envoi pour avoir une "surface" de changeset
la plus petite possible. En envoyant plusieurs changesets, si leur ensemble
recouvre une surface presque équivalente au monde entier, tout le monde
aura, avec OSMcha, un changeset pour son "territoire" donc pareil qu'avec
un changeset mondial :)

>
> Dans JOSM, je sélectionne un grand rectangle :) ou mieux (comme ça, ça
> sélectionne les relations) une recherche "(new or modified)  inview" en ce
> plaçant correctement, ne pas oublier les ( ) la dernière fois que j'ai été
> interpelé, je suis allé trop vite et les ai oublié donc dans la sélection
> il y avait des élements dans le monde entier :(  et après fichier -> envoyé
> la sélection.
>
> Je fais ça aussi. Parfois avant de faire envoyer la sélection
> CMD+ALT+MAJ+U, je dois faire machinalement un CTRL+A et j’envoi un gros
> bazar !
>
> Par contre, le gros problème c'est pour les éléments supprimés, il faut
> pas en avoir sinon on se retrouve avec à la fin et pas moyen de les
> sélectionner :(
>
> En fait il faut réussir à cibler ses modifications
>
> Pour les expression régulière et leur stockage, il est possible de les
> placer dans l'espèce de wikidata du wiki d'osm, les éléments OpenStreetMap
> Wiki, avec la propriété "Expression régulière pour valider la valeur" P13 (
> https://wiki.openstreetmap.org/wiki/Property:P13)
> Je l'ai fais il y a quelque temps ici :
> https://wiki.openstreetmap.org/wiki/Item:Q1273
> pour wikidata , c'est ici : https://wiki.openstreetmap.org/wiki/Item:Q827
> et wikipedia là : https://wiki.openstreetmap.org/wiki/Item:Q828
>
> Je ne connaissais pas, mais j’ai peur de ne pas être le seul. 類
>
> L’intérêt de le mettre ici, c’est que ça reste sur les serveurs OSM.
>

Oui, exactement, comme ça l'info est stocké quelque part.


> Encore faut-il que les développeurs le connaissent ?
>

S'il n'y a rien sur ces éléments OSM wiki, les développeurs ne
l'utiliseront pas et ... inversement. Il faut bien commencer quelque part.


> Tient, on pourra à terme virer toute une partie du wiki 
> (comme pour les boites dans wikipedia qui sont remplies automatiquement
> par des données wikidata).
>
> L’intérêt de le mettre sur wikidata, c’est que ce dernier est plus
> général; les expressions régulières souvent  existent déjà… Pourquoi
> réinventer la roue ?
>

Il n'y a pas les expressions régulières pour les tag OSM, si?
Comme wikidata, ça permet d'avoir des infos faciles à utiliser par un
robot, facile de créé une page dans une autre langue vu que la bande de
droite se remplit toute seul, permet de lier les pages des différentes
langues.

>
>
> Par contre, 2 remarques, l'expression régulière doit être tel que il sera
> ajouté "^(" avant et ")$" après, je comprends pas pourquoi cette
> restriction.
>
> Peux-tu donner des exemples ?
>

On peut toujours s'arranger avec ça mais pour moi le "^" et le "$" font
partie de l'expression régulière et il y a un soucis sur la page, on dit
qu'il sera ajouté "^(" avant et ")$" après, mais dans "format de l'url" il
n'y a pas les parenthèses.

>
> Et je sais pas comment on fait une recherche dans ce wikidata OSM, le seul
> moyen d'y accéder c'est par les pages "normales" et sur la colonne de
> gauche "élément OpenStreetMap Wiki »
>
> ça correspond dans wikipedia à Élément Wikidata.
>
> J’ai peut-être trouvé une piste 
> Il y a un serveur SPARQL pour OSM : il permet d’interroger les données OSM
> (et des bases de connaissances externes comme wikidata).
> Il s’appel Sophox  ?
>

J'ai vu ça mais j'ai jamais testé... et je comprend pas trop ce que ça
apporte par rapport à overpass.


> Je ne sais pas encore comment interroger le wikidata d’OSM que tu décris
> plus haut, par contre j’arrive bien à interroger les données OSM :
>
> Requête SPARQL des objets ayant un identifiant NGA (les feux, phares,
> bouées et 

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

[Jérôme Amagat]

>
>
>- 2669  contenant des _ à la place
>des espaces
>
> le validateur de JOSM corrige cette erreur, les _ à la place d'espace.
L'erreur est indiqué par le validateur et "réparer" remplace les _ par des
espaces.

Moi aussi je me suis fais plusieurs fois taper sur les doigts parce que
j'envoyais des données sur plusieurs continent en même temps :) , ça plaît
pas à certains qui, avec je sais plus quel outils, suivent les changset sur
leur zones et donc un changset mondial, ça bip chez tout le monde :). Mais
je pense pas qu'il y ai besoin de couper par pays, par "région" qui peut
englober plusieurs pays ça suffit.
Dans JOSM, je sélectionne un grand rectangle :) ou mieux (comme ça, ça
sélectionne les relations) une recherche "(new or modified)  inview" en ce
plaçant correctement, ne pas oublier les ( ) la dernière fois que j'ai été
interpelé, je suis allé trop vite et les ai oublié donc dans la sélection
il y avait des élements dans le monde entier :(  et après fichier -> envoyé
la sélection.
Par contre, le gros problème c'est pour les éléments supprimés, il faut pas
en avoir sinon on se retrouve avec à la fin et pas moyen de les
sélectionner :(

Pour les expression régulière et leur stockage, il est possible de les
placer dans l'espèce de wikidata du wiki d'osm, les éléments OpenStreetMap
Wiki, avec la propriété "Expression régulière pour valider la valeur" P13 (
https://wiki.openstreetmap.org/wiki/Property:P13)
Je l'ai fais il y a quelque temps ici :
https://wiki.openstreetmap.org/wiki/Item:Q1273
pour wikidata , c'est ici : https://wiki.openstreetmap.org/wiki/Item:Q827
et wikipedia là : https://wiki.openstreetmap.org/wiki/Item:Q828

Par contre, 2 remarques, l'expression régulière doit être tel que il sera
ajouté "^(" avant et ")$" après, je comprends pas pourquoi cette
restriction. Et je sais pas comment on fait une recherche dans ce wikidata
OSM, le seul moyen d'y accéder c'est par les pages "normales" et sur la
colonne de gauche "élément OpenStreetMap Wiki"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de modification en masse - Suppression de ref:INSEE des noeuds "place"

[Jérôme Amagat]

Le lun. 25 nov. 2019 à 22:35,  a écrit :

> Toutes ces mairies avaient été modifiées par mairies5962bot
>  le robot de LéG.
>
> Sauf deux d'Ille-et-Vilaine et dont les communes portent le code insee.
>
> LèG, inactif depuis 4 ans, n'a pas répondu à mon message du 17.
>
> *Bonjour, Près de 4 000 fois votre script a ajouté à tort des ref:FR:INSEE
> sur autre chose que des communes. Ces usages devraient disparaître : 
> **https://wiki.openstreetmap.org/wiki/FR:Key:ref:INSEE
> **. : 
> **http://overpass-turbo.eu/s/OaA
> *
>
> *Sans retour rapide (sur la liste ou ici) le ménage sera fait. Mais c’est
> plus pour que vous ne le fassiez plus à l’avenir.*
>
> Comme je ne précisais pas node ou way, j'avais la (non) réponse : un bot
> laissé sans maintenance, on fait ce que pense la communauté sans compter de
> ce qu'a fait le robot.
>
> Avant le passage de Stéphane :
> Type
> Nombre d'objets
> Nombre de valeurs
> [image: [Tous]] Tous
> 77 470
> 0.00%
> *40 734*
> [image: [Nœud]] Nœud
> 34 313
> 0.02%
> 32 965
> [image: [Chemin]] Chemin
> 1 452
> 0.00%
> 1 451
> [image: [Relation]] Relation
> 41 705
> 0.58%
> *40 682*
>
> Ce qui veut dire que l'on a viré au moins 52 valeurs portées par des
> chemins ou des nœuds sans relation associée donc on s'est planté quelque
> part.
>
> Il peut y avoir des confusions avec le code postale, j'ai déjà vu le cas,
mais il y a avait sûrement des place=* avec le code INSEE d'une ancienne
commune aujourd'hui disparu ou transformé en commune associée lors d'une
fusion de communes.
Normalement, les communes déléguées ont toutes leurs relations
admin_level=9 mais pas les communes associées. Dans le code officiel
géographique, il y a 550 communes associées et d’après taginfo (
https://taginfo.openstreetmap.org/keys/admin_type:FR#values) on a 231
admin_type:FR=commune associée et normalement toutes les communes associés
ont un code INSEE différent de celui des autres communes (ce n'est pas le
cas pour les communes déléguées qui peuvent avoir le même code que leur
commune mère).

Pour les mairies, cela pourrait être utile d'avoir un role dans les
relations pour la mairie car une mairie dans une relation admin_level=8 ne
veux pas obligatoirement dire que c'est la mairie de cette commune, les
communes déléguées et associées ont aussi une mairie.

Aujourd'hui, j'ai ajouté 2054 ref:INSEE sur des relations. Ce sont les
cantons, ils avaient un tag planned:ref=* (parfois modifié en ref=*) mis
lors de la créations de ces cantons en 2015 et qui normalement attendaient
le code officiel géographique de l'insee pour prendre leur valeur
définitive en ref:INSEE=* mais le changement n'a jamais été fait. Le
planned:ref était en XXX-YY avec XXX pour le département avec un 0 en
première valeur pour la métropole et YY une numérotation des cantons en 01,
02, ... obtenu par l'ordre alphabétique. Dans le code officiel
géographique, le code pour les cantons est XXYY (XXXYY pour les département
d'outre mer en 3 chiffres) avec XX le département et YY la même
numérotation que nos planned:ref . (Normalement) j'ai bien fait les choses,
j'ai vérifié que la numérotation était la même, que les noms de cantons
étaient les mêmes (il y a quelques différences d'orthographes que j'ai
laissé, articles, majuscules, accents) et j'ai modifié la ref en enlevant
le 0 du début pour la métropole, le tiret et changé en ref:INSEE=*.

On a dans ref:INSEE les code utilisées par l'insee pour différents objets,
commune bien sur, mais aussi canton, département ... j'ai vu que sur
wikidata, ces différents identifiants ne sont pas mélangés, il y a un "code
INSEE d'une commune", un "code INSEE d'un canton" ... peut être que ça
serai plus simple à maintenir de faire la même chose ...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de modification en masse - Suppression de ref:INSEE des noeuds "place"

[Jérôme Amagat]

J'ai fait quelques modification sur des élements avec ref:INSEE :
J'ai supprimé dans une comcom tous les ref:INSEE sur des natural =wetland
(un import, quelqu'un avait dejà supprimé d'autres tags inutiles venant de
l'import. il y avait des ways et des relations)
2 ref:INSEE sur des landuse=residential : pour l'un le ref:INSEE n'existe
pas et n'a jamais existé d’après l'insee (ce n'est pas le code postal n'ont
plus) l'autre c’était le code insee d'une commune associée, je l'ai importé
correctement du cadastre.
Quelque modif sur des relations qui n'avait pas les même tags que la
plupart des autres, surtout des disused: ajoutés
J'ai modifié quelques ref:INSEE en ref:IRIS voir ref:TRIRIS quand c'était
des référence IRIS (https://www.insee.fr/fr/metadonnees/definition/c1523)
découpage, plus fin que les communes, de l'insee.
Les TRIRIS sont un regroupement de plusieurs IRIS.
TRIRIS (7 chiffres) :  insee + 2 chiffres 01, 02 
IRIS (9 chiffres) : TRIRIS + 2 chiffres 01, 02 
Les tags ref:IRIS et ref:TRIRIS étaient déjà un peu utilisés (
https://taginfo.openstreetmap.org/search?q=iris) mais ne sont pas
documenté, c'est fait par l'insee donc je ne sais pas s'il faut utiliser
ref:INSEE ou ces tags.

il reste comme ref:INSEE :
tous un tas de node avec place=* villes, villages, quartiers , localités,
fermes !... parfois ce sont les chefs-lieu de commune et parfois non :)
Des mairies (node way ou relation) toutes dans le nord pas de calais sauf 2
il me semble.
en plus de çà :
Sur des ways il ne reste des ref:INSEE que sur l'île de Clipperton (
https://www.openstreetmap.org/way/160415456)
Sur des nodes en dehors des place=* évoqué plus haut, il y a aussi des
territoires d'outre mer avec place=state (il y en a 5) et place=district
pour Terre Adélie.

Sur les relations c'est plus compliqué :
- il y a bien sur les communes mais aussi les départements, les régions,
les arrondissements départementaux et la circonscription départementale du
Rhône(la seul en admin_level=5) : type=boundary + boundary=administrative +
admin_level=8,7,6,5,4
- les arrondissements de paris marseille et lyon : type=boundary +
boundary=administrative + admin_level=9 admin_type:FR=arrondissement
municipal
- des territoires d'outre mer : type=boundary + boundary=administrative +
admin_level=3
- en admin_level=3 il y a aussi 2 boundary=land_area et 2 boundary=maritime
et la relation "Terres australes et antarctiques françaises (terres)" qui
n'a pas de tag boundary=
- Terre Adélie : avec boundary=region + admin_level:FR=7 +
admin_type:FR=district
- les ancien canton d'avant 2015 : type=boundary +
disused:boundary=political
d'ailleurs les nouveaux cantons n'ont pas de tag ref:INSEE mais toujours
comme tag planned:ref=* ...
- Ensuite ont a des anciens truc qui ont un code insee :
- anciennes régions : type=boundary + boundary=historic +
disused:admin_level=4
- anciens arrondissements départementaux : type=boundary +
disused:boundary=administrative + disused:admin_level=7
- anciennes communes : là c'est plus compliqué, parfois il y a
disused:admin_level=8 parfois admin_level=9 voir admin_level=10 et même
admin_level=11

pour les admin_level=9 10 et 11 pas sur que ce soit seulement d'anciennes
communes.

Mais sinon il n'y a rien d'autre si je ne me suis pas raté.

Conclusion :
- Que faire des mairies avec ref:INSEE, certain ont du y passé du temps a
les recenser et ajouter ce ref:INSEE qui indique que c'est bien la mairie
de la commune ?
- Je suis pour supprimer tout les ref:INSEE sur les node place=* villes,
villages, quartiers , localités, fermes ... par contre que fait t on des
node place=state et place=district, il y en a 6, pour les territoires
d'outre mer qui ont aussi une relation ?
- Il y a parfois plusieurs relations pour les territoires d'outre mer ( le
territoire "administratif" + les terres ou la zone économique exclusive)
avec le ref:INSEE, on laisse comme ça ?
Pour les ancienne commune, c'est compliqué :) , parfois elles sont devenu
des communes associée ou déléguée donc admin_level=9 parfois des quartiers
donc admin_level=9, 10 ou 11 et parfois rien du tous :)
- Que faire des ref:IRIS et ref:TRIRIS, les documenter sur le wiki ou les
changer en ref:INSEE ou autre chose ?
- boundary=historic est parfois utilisé, sur toutes les anciennes régions
et sur des anciennes communes, moi je trouve pas ça utile...

Donc je pense qu'il faut modifié en masse en supprimant ref:INSEE sur les
nodes place=* en excluant les 6 place=state et place=district et voir si on
fait pareil pour les mairies (qui sont node , ways ou relations) mais sinon
ne pas toucher aux relations.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Amagat]

il y a beaucoup plus de commune avec addr:postcode=* qu'avec postal_code=*
: 3 contre 5000
Pour moi, postal_code=* va avec boundary=postal_code et c'est pour la zone
total du code postal
et addr:postcode=* c'est pour une adresse sur un node, un bâtiment ou un POI

Mais sur les commune je ne sais pas ce qui est le mieux mais à chaque fois
que je modifie une frontière de commune, j'ai le validateur JOSM qui me dit
qu'il y a un soucis avec addr:postcode=* et ce n'est pas nouveau? je crois
qu'historiquement c'est addr:postcode=* qui a été utilisé sur les communes.

Le dim. 17 nov. 2019 à 19:50,  a écrit :

> Bonjour, en passant sur Pleucadeuc suite à un noeud ref:INSEE mal placé
> j'ai vu que la commune avait une addr:postcode et non un postal_code.
>
> J'ai fait la modif mais je vois  que la modif inverse avait été faite
> volontairement :
>
> https://www.openstreetmap.org/relation/146321/history
> remplacement de postal_code par addr:postcode sur 107 communes (suite à
> discussion); construction et consolidation en cours (non terminée) du Pays
> de Dinan
> Edited about 1 year ago by Verdy_p
> 
> Version #15 · Changeset #62275163
> 
>
> Je n'ai pas souvenir de telle discussion.
>
> J'en suis resté à postal_code pour les zones de codes postaux et
> addr:postcode pour les adresses postales.
>
> Il y a du nouveau ou c'est une vision spécifique au pays de Dinan ? (!)
>
> Jean-Yvon
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OverPass noeuds des admin_centre des communes

[Jérôme Amagat]

Le mer. 13 nov. 2019 à 12:43, Cyrille37 OSM  a
écrit :

> Bonjour
>
> Cette sujet est déjà passé, mais je ne retrouve pas la réponse.
>
> La requête Overpass_QL suivante fonctionne mais elle retourne les nœuds
> et les relations. Quelle est la syntaxe pour que seuls les nœuds soient
> retournés :
>
> [out:json][timeout:30];
> area[name="Centre-Val de Loire"]->.zone;
> (
>rel(area.zone)["admin_level"="8"]->.relations;
>(
>   node(r.relations:"admin_centre");
>);
> );
> out ;
>
> Merci !
> Cyrille37
>
> Le out va sortir  tous ce qui a dans les parenthèses juste au dessus donc
node et relation donc il faut supprimé les parenthèses (celle autour de
node... ne serve a rien) donc :

[out:json][timeout:30];
area[name="Centre-Val de Loire"]->.zone;
rel(area.zone)["admin_level"="8"][boundary=administrative]->.relations;
node(r.relations:"admin_centre");
out ;

ça doit fonctionner. j'ai ajouté boundary=administrative, il y a des
endroits en France où admin_level=8 est utilisé pour des paroisses.


> ___
> 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] Interface de génération de fichiers .osm à partir du cadastre - les fichiers avec les adresses manquent

[Jérôme Amagat]

Très bon plugin !
3 remarques :
le téléchargement des sections ne fonctionne pas.
Ne fonctionne pas en outre mer.
Pour un très petit nombre de commune, le téléchargement ne se fait pas du
tout ou que sur certaines feuilles de la commune. (les communes sont
pourtant en cadastre vecteur et présent sur cadastre.data.gouv.fr)
J'ai retrouvé cette commune où je n'est pas les bâtiments partout : La
Grimaudière https://www.openstreetmap.org/relation/139291
et sur cette commune j'ai rien ni sur d'autres communes autour :
https://www.openstreetmap.org/relation/2940001

Le mar. 22 oct. 2019 à 23:04, Vincent Privat  a
écrit :

> @Yves: le problème de zoom est également corrigé
> @Vincent: c'est bien corrigé aussi, je te promets
>
> @tous les 2: c'est juste que la dernière version du plugin nécessite JOSM
> "latest"
>
> A+
> Vincent
>
> Le mar. 22 oct. 2019 à 10:58, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Yves P." 
>> >
>> > Le souci principal en l'état, sur mes quelques tests, est que le tag
>> > name, au lieu de contenir le nom de voie, contient le numéro
>> > d'adresse, en doublon du tag addr:housenumber. J’avais remarqué ça,
>> > mais je constate que c’est remonté et corrigé avec célérité. Merci
>> > Vincent(s) 
>>
>> Merci Vincent pour ta réactivité ! Je suis un peu frustré ceci-dit car en
>> prenant ce matin le greffon à
>> https://svn.openstreetmap.org/!svn/bc/35168/applications/editors/josm/dist/cadastre-fr.jar
>> j'ai toujours l'anomalie. Dans le panneau des plugins de JOSM ça m'indique
>> que j'ai le greffon 35167* (avec l’astérisque), je ne sais pas si c'est ce
>> qu'il faudrait constater ?
>>
>> 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