Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet Philippe Verdy 
J'ai un peu "tittillé" le passage à niveau en le recréant sur un nouveau
nœud et supprimant l'ancien nœud, ça règle le problème du chemin parasite
(les mises à jour de rendu sont en cours pour les niveaux de zoom plus
bas). Au passage j'ai un peu amélioré la précision de placement de la ligne
de chemin de fer.

Le 9 août 2018 à 23:28, Philippe Verdy  a écrit :

> La modif n'a pas d'effet sur le chemin parasite, il semble que le rendu
> curieux soit lié au fait que le serveur de rendu a bien deux chemins mais
> il n'en trouve qu'un correctement tagué dans sa base mais avec une
> géométrie incomplète, et l'autre vient de la géométrie qu'il voit mais pas
> tagué correctement. Un changeset est visiblement passé sur ce serveur, mais
> visiblement pas au complet, il était peut-être tronqué quand il a été
> chargé, et cela a laissé ces parasites avec des modifs incomplètement
> chargées sur sa base esclave.
> Je reste persuadé que c'est un problème de remise en route des serveurs
> migré de Londres à Amsterdam: suite à l'arrêt il a du manquer certains
> diffs ou des diffs incomplets ou un problème d'espace disque ou d'espace
> temporaire saturé (suite aux scripts de migration) ou de connectivité
> temporaire (erreurs de caches DNS par exemple) a pu causer ce bogue. On
> voit ces bogues à divers endroits, tous autour des modifications effectuées
> durant une seule heure environ.
>
> La désynchronisation des "diffs" semble bien la bonne piste. Cela est déjà
> arrivé aussi sur les serveurs de rendu d'OSM France et chaque fois il a
> fallu repartir en chargeant un dump complet postérieur aux problèmes de
> diffs constatés puis rechargeant les autres nouveaux diffs émis depuis ce
> dump.
>
> En terme de tags je ne vois pas de problème, et les rendus d'OSM France ou
> Allemagne ou Mapquest ne sont pas impactés ici (mais eux n'ont pas changé
> d'hébergement et de config réseau pendant ce temps). De toute façon comme
> le bogue est connu et signalé, OSM.org trouvera bien une solution (quitte à
> arrêter deux de ses 4 serveurs de rendu et avoir un peu plus de "lag"
> pendant ce temps là, le temps de recharger leur base).
>
> En tout cas une chose est sure, cela ne vient pas des caches de tuiles
> (sur les 21 sites du CDN d'OSM.org) : ils sont bien à jour et pas en retard.
>
>
> Le 9 août 2018 à 22:46,  a écrit :
>
>> Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :
>>
>> si tu regardes le point qui a visuelement un 
>> problèmehttps://www.openstreetmap.org/node/252291030
>> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
>> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
>> osm.org)
>>
>> Ça fait 9 mois que baleineaux
>>  l'a mis comme
>> level_crossing d'un seul éléments ferré et d'un non ferré.
>> Et 12 jours qu'il a mis à jour la liaison https://www.openstreetmap.org/
>> way/262550757#map=12/47.5247/-3.0738=H
>>
>> Je vois que Philippe a titillé le chemin en lui mettant sa référence (et
>> en supposant une vitesse de 80 km/h).
>> La référence est bien affichée mais au niveau 18 on a un curieux rendu :
>> https://www.openstreetmap.org/query?lat=47.67901=-3.0216
>> 7#map=18/47.67904/-3.02191
>>
>> https://a.tile.openstreetmap.org/18/128871/91473.png
>> [image: https://a.tile.openstreetmap.org/18/128871/91473.png]
>> Sachant que le railway va de part et d'autre du PAN...
>>
>> N.B. : le décalage horaire ne me semble pas une bonne piste.
>> 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

[OSM-talk-fr] Lieux d'accueil enfants-parents

2018-08-09 Par sujet deuzeffe 

Bonsoir,

Les LAEP (ou parfois LAPE) sont des structures (~ 1500 ) officiellement 
reconnues et soutenues par la CAF (cf 
http://www.caf.fr/allocataires/vies-de-famille/futur-parent/garde-d-enfant/les-lieux-d-accueil-enfants-parents 
; il y a même une base en LO/OL),


C'est donc dans le thème enfance. Mais quel(s) tag(s) ? Ce ne sont pas 
des kinderkarten, même si ça peut s'en rapprocher. Quel tag pourrait-on 
utiliser voire créer ?


Merci pour vos réponses, quelles qu'elles soient.
--
deuzeffe

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet Philippe Verdy 
La modif n'a pas d'effet sur le chemin parasite, il semble que le rendu
curieux soit lié au fait que le serveur de rendu a bien deux chemins mais
il n'en trouve qu'un correctement tagué dans sa base mais avec une
géométrie incomplète, et l'autre vient de la géométrie qu'il voit mais pas
tagué correctement. Un changeset est visiblement passé sur ce serveur, mais
visiblement pas au complet, il était peut-être tronqué quand il a été
chargé, et cela a laissé ces parasites avec des modifs incomplètement
chargées sur sa base esclave.
Je reste persuadé que c'est un problème de remise en route des serveurs
migré de Londres à Amsterdam: suite à l'arrêt il a du manquer certains
diffs ou des diffs incomplets ou un problème d'espace disque ou d'espace
temporaire saturé (suite aux scripts de migration) ou de connectivité
temporaire (erreurs de caches DNS par exemple) a pu causer ce bogue. On
voit ces bogues à divers endroits, tous autour des modifications effectuées
durant une seule heure environ.

La désynchronisation des "diffs" semble bien la bonne piste. Cela est déjà
arrivé aussi sur les serveurs de rendu d'OSM France et chaque fois il a
fallu repartir en chargeant un dump complet postérieur aux problèmes de
diffs constatés puis rechargeant les autres nouveaux diffs émis depuis ce
dump.

En terme de tags je ne vois pas de problème, et les rendus d'OSM France ou
Allemagne ou Mapquest ne sont pas impactés ici (mais eux n'ont pas changé
d'hébergement et de config réseau pendant ce temps). De toute façon comme
le bogue est connu et signalé, OSM.org trouvera bien une solution (quitte à
arrêter deux de ses 4 serveurs de rendu et avoir un peu plus de "lag"
pendant ce temps là, le temps de recharger leur base).

En tout cas une chose est sure, cela ne vient pas des caches de tuiles (sur
les 21 sites du CDN d'OSM.org) : ils sont bien à jour et pas en retard.


Le 9 août 2018 à 22:46,  a écrit :

> Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :
>
> si tu regardes le point qui a visuelement un 
> problèmehttps://www.openstreetmap.org/node/252291030
> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
> osm.org)
>
> Ça fait 9 mois que baleineaux
>  l'a mis comme
> level_crossing d'un seul éléments ferré et d'un non ferré.
> Et 12 jours qu'il a mis à jour la liaison https://www.openstreetmap.org/
> way/262550757#map=12/47.5247/-3.0738=H
>
> Je vois que Philippe a titillé le chemin en lui mettant sa référence (et
> en supposant une vitesse de 80 km/h).
> La référence est bien affichée mais au niveau 18 on a un curieux rendu :
> https://www.openstreetmap.org/query?lat=47.67901=-3.
> 02167#map=18/47.67904/-3.02191
>
> https://a.tile.openstreetmap.org/18/128871/91473.png
> [image: https://a.tile.openstreetmap.org/18/128871/91473.png]
> Sachant que le railway va de part et d'autre du PAN...
>
> N.B. : le décalage horaire ne me semble pas une bonne piste.
> 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] Artefact ou erreur de données ?

2018-08-09 Par sujet osm . sanspourriel 

Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :


si tu regardes le point qui a visuelement un problème
https://www.openstreetmap.org/node/252291030
il ne fait plus partie que d'un rail. donc problèe entre temps résolu
et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu
osm.org)
Ça fait 9 mois que baleineaux 
 l'a mis comme 
level_crossing d'un seul éléments ferré et d'un non ferré.
Et 12 jours qu'il a mis à jour la liaison 
https://www.openstreetmap.org/way/262550757#map=12/47.5247/-3.0738=H


Je vois que Philippe a titillé le chemin en lui mettant sa référence (et 
en supposant une vitesse de 80 km/h).
La référence est bien affichée mais au niveau 18 on a un curieux rendu : 
https://www.openstreetmap.org/query?lat=47.67901=-3.02167#map=18/47.67904/-3.02191


https://a.tile.openstreetmap.org/18/128871/91473.png
https://a.tile.openstreetmap.org/18/128871/91473.png
Sachant que le railway va de part et d'autre du PAN...

N.B. : le décalage horaire ne me semble pas une bonne piste.
Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet Philippe Verdy 
les rendus des tuiles ne sont pourtant pas en retard. Et les données dans
leurs base non plus.

Je pense plutôt à un problème avec certains changesets en erreur qui n'ont
pas été envoyés/reçus ou ont été écrasés dans le flux (sans doute un
problème de mises à jours des dates sur certains serveurs transférés de
Londres à Amsterdam, par exemple une config de fuseau horaire incorrecte si
le serveur de temps a été changé et les serveurs n'avaient pas une horloge
réglée en UTC mais en heure locale; dans ce cas il y a pu y avoir un
décalage d'1 heure avant que le problème soit réglé, mais au moment du
changement le recul d'1 heure de l'horloge a pu provoquer des écrasements
ou un défaut de configuration des espaces de stockage réseau).

Bizarrement cela n'affecte que les serveurs de rendus d'OSM.org pas les
autres, ni la base de données maître. Ce serait donc un problème de mise à
jour de la base esclave (copiée/synchronisée sur le serveur de rendu) lié à
une reconfiguration incorrecte. Et pas du temps un "lag" (retard). A moins
de recharger cette base esclave (ou rejouer les diffs oubliés) je ne vois
pas comment le serveur de rendu peut corriger ses tuiles s'il a encore un
way qui aurait du être supprimé mais dont un noeud au moins a été gardé (le
noeud du passage à niveau).

On peut toujours essayer de fixer ça manuellement en découpant les 4
chemins connectés autour du passage à niveau pour former un trou, puis les
reconnecter à un nouveau noeud commun tagué en passage à niveau, puis
réunir les ways tronçonnés, et envoyer le tout: les 2 ways seront
préservés, seul le noeud du chemin de fer aura disparu, et le way parasite
qui l'utilisait devrait aussi être éliminé et plus tracé du tout. Mais il
est possible que cela ne marche pas non plus sur la base esclave, si ce
nouveau changeset ne passe pas car il supprimera l'ancien nœud de passage à
niveau "encore utilisé" par le way parasite (qui n'est déjà plus dans la
base maître).

De plus cette anomalie d'1 heure peut avoir eu des effets dans divers
autres endroits du monde sur la carte où il y aurait eu des écrasements
intempestifs par une désynchro des diffs.



Le 9 août 2018 à 19:09, marc marc  a écrit :

> Le 09. 08. 18 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
> > Je vois que sur OSM.org
> > 
> > ou OSM.fr
> > , la
> > ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe
> > s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée
> > une ligne TGV d'Auray à Quiberon ;-).
>
> si tu regardes le point qui a visuelement un problème
> https://www.openstreetmap.org/node/252291030
> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu
> osm.org)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet marc marc 
Le 09. 08. 18 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
> Je vois que sur OSM.org 
>  
> ou OSM.fr 
> , la 
> ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe 
> s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée 
> une ligne TGV d'Auray à Quiberon ;-).

si tu regardes le point qui a visuelement un problème
https://www.openstreetmap.org/node/252291030
il ne fait plus partie que d'un rail. donc problèe entre temps résolu
et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
osm.org)

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

Re: [OSM-talk-fr] Modifier un pont erroné avec une dizaine de relations imbriquées au moins.

2018-08-09 Par sujet Philippe Verdy 
Les tags sur les ways sont de toute façon indicatifs uniquement quand le
way entre dans une relation : la relation prime de toute façon en cas de
conflit éventuel.

Aussi bien les frontières que les cours d'eau devraient être modélisés dans
une relation contenant les way. Mais on a des tas de rues et de petits
cours d'eau sans relation du tout.

Ces tags sur le way quand il y a une relation sont plus des "rappels"
informant de la présence (éventuelle) d'une relation: s'il y a une
relation, c'est elle qui donne le nom a priori, mais pour les cours d'eau
c'est un peu plus compliqué car si l'ensemble du cours a un nom, il peut
changer localement le long du cours (notamment les cours d'eau sur
plusieurs pays ayant des langues officielles différentes, mais aussi dans
les estuaires (comme la Gironde et d'autres fleuves ouverts sur la remontée
d'eau marine jusqu'au dernier barrage, ou équipement comme une barrière
anti-sel, mais aussi les sections canalisées de fleuves et rivières qui
localement prennent le nom du canal, par exemple sur l'Ille à Rennes)
Le "name" alors sur le tracé est le nom local (ce serait un cas pour
utiliser "loc_name" plutôt que "name" réservé au cours d'eau naturel).
On a aussi des cas de noms encore plus locaux comme les noms d'écluses (là
on a décidé d'utiliser "lock_name" pour ne pas rompre la continuité des
noms des canaux et rivières canalisées).
Même chose avec les noms locaux de ponts et tunnels sur une rue/route.
D'une façon générale les frontières n'ont pas de nom bien défini sur leur
way, ces noms dérivent des relations qui les utilisent: les noms de
rivières et routes priment dans "'name".

Les autres attributs ne souffrent pas d'ambiguité/conflits en général entre
frontière et cours d'eau ou entre frontière et rue/route.

Mais il y a des conflits de valeurs sur "admin_level=*" (on a opté pour
utiliser sur le way la plus petite valeur), et sur "admin_type=*" ou
"boundary=*" : là on choisit en général de prendre la valeur d'"admin_type"
correspondant à l'admin_level le plus faible pour les frontières
"boundary=administrative", qui est aussi prioritaire sur les autres types
comme "boundary=political" sans "admin_level" (cas particulier: les
frontières religieuses qui ont aussi malheureusement un "admin_level" à ne
pas prendre en compte dans les priorités, cela aurait du être
"religion_level", mais on a des conflits "administratifs" dans des pays
multiconfessionnels qu'on ne peut pas régler sur les ways, uniquement sur
les relations) les valeurs données sont là aussi indicatives mais on les
choisit par degré d'importance administrative avant le reste.

Si on met encore des tags sur les ways au lieu des relations parentes,
c'est souvent par compatibilité avec plein d'outils et rendus qui eux ne
cherchent pas les relations parentes, qui elles aussi ne sont pas encore
obligatoires partout : ils sont aussi une aide utile pour les contributeurs
car ces tags permettent de distinguer facilement les chemins dans des
listes techniques d'objets qui ne sont pas pratiques à repérer avec juste
leur ID numérique. Mais des améliorations des éditeurs pourraient aller
chercher les relations parentes pour obtenir ces informations et les
afficher sans qu'on ait à les renseigner aussi sur les ways (hormi cas
spécial des noms locaux préférés aux noms globaux de l'objet dans leur
relation parente)

Le 3 août 2018 à 23:39, marc marc  a écrit :

> Le 03. 08. 18 à 11:27, Rpnpif a écrit :
> > Oui bien sûr, mais le problème n'est pas là. Le problème est la
> > superposition-fusion au mm près des tracés ou carrément le tagage type
> > squat dans les attributs du flux.
>
> l'idéal est d'avoir un way pour la rivière avec uniquement les tags de
> la rivière et utiliser ce way dans la relation boundary avec uniquement
> les tags qui concerne le boundary.
> mixer les 2 sur un way n'est pas top mais certains outils se servent
> encore des tags boundary sur les relations... hélas...
> ___
> 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] Artefact ou erreur de données ?

2018-08-09 Par sujet osm . sanspourriel 

Le 09/08/2018 à 16:36, David Crochet - david.croc...@free.fr a écrit :


Bonjour

Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :
Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la 
ligne fantôme (loin des extrémités) OSM ne trouve rien.


Non, je définit bien la recherche aux environs des nœuds (et non sur 
le parcours du chemin sans nœud aux environs


et en effectuant une requête entre le noeud 2393687377 
 et le noeud 2393687378 
, il ne trouve rien


En téléchargeant la zone dans JOSM, il ne trouve pas de telle ligne 
non plus.
En fait on est peut-être d'accord : en cherchant comme tu dis 
https://www.openstreetmap.org/query?lat=47.48469=-3.11789
Il trouve bien la relation Ligne d'Auray à Quiberon 


Pas la relation voyageurs (je ne sais pourquoi).

Si tu penses à une liaison comportant uniquement les points gare de 
Quiberon - PAN de Botulen, je ne pense pas qu'elle existe.
Et  pourtant https://b.tile.openstreetmap.org/19/257743/182946.png 
comporte toujours ce zombie.

C'est ce qui me fait penser à un problème d'affichage mais ça m'étonne.

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet David Crochet 

Bonjour


Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :
Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la ligne 
fantôme (loin des extrémités) OSM ne trouve rien.


Non, je définit bien la recherche aux environs des nœuds (et non sur le 
parcours du chemin sans nœud aux environs


et en effectuant une requête entre le noeud 2393687377 
 et le noeud 2393687378 
, il ne trouve rien


En téléchargeant la zone dans JOSM, il ne trouve pas de telle ligne non 
plus.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet David Crochet 

Bonjour


Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :


Curiosité : je vois qu'il y a une ligne vue en tant que transporteur 
de voyageurs  et une 
autre  en tant 
qu'infrastructure mais la première ne s'appuie pas sur la seconde. 
Est-ce normal ? Logique ?


A priori je trouve cela logique, l'un décrit la voie de circulation 
(référence provenant du réseau ferré) et ne définit que la voie de 
circulation l'autre indique la circulation possible (référence provenant 
du transporteur) avec les arrêts qu'il utilise pour définir ce trajet de 
transport.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet osm . sanspourriel 
> Le rendu cyclable et le rendu transport sont mis à jour avec des 
temps plus longs (7 à 15 jours environ)
Ça correspond bien à la dernière modif (10 jours). On verra dans 
quelques temps.


Le 09/08/2018 à 14:54, David Crochet - david.croc...@free.fr a écrit :
OSM.org ne trouve pas cette ligne lorsque je lui demande de "trouver 
autour" que ce soit d'une extrémité ou de l'autre. Je pense que 
l'erreur est déjà corrigé.

Si :
https://www.openstreetmap.org/query?lat=47.48470=-3.11792
Ou près du PAN :
https://www.openstreetmap.org/query?lat=47.6790=-3.0220#map=14/47.5606/-3.0749

Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la ligne 
fantôme (loin des extrémités) OSM ne trouve rien.


Curiosité : je vois qu'il y a une ligne vue en tant que transporteur de 
voyageurs  et une autre 
 en tant 
qu'infrastructure mais la première ne s'appuie pas sur la seconde. 
Est-ce normal ? Logique ?


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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet David Crochet 

Bonjour


Le 09/08/2018 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
Je vois que sur OSM.org 
 
ou OSM.fr 
, la 
ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne 
directe s'affranchissant des obstacles naturels. Je ne savais qu'avait 
été créée une ligne TGV d'Auray à Quiberon ;-).


OSM.org ne trouve pas cette ligne lorsque je lui demande de "trouver 
autour" que ce soit d'une extrémité ou de l'autre. Je pense que l'erreur 
est déjà corrigé.


Donc "wait and see"

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet David Crochet 

Bonjour


Le 09/08/2018 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
Comme les deux systèmes affichent la même chose ainsi que le rendu HOT 
mais que la carte cyclable 
 
est bonne comme la carte transports je me demande s'il n'y a pas un 
bogue dans l'affichage cartoCSS/Mapnik


Le rendu cyclable et le rendu transport sont mis à jour avec des temps 
plus longs (7 à 15 jours environ)


cordialement

--
David Crochet

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

[OSM-talk-fr] Artefact ou erreur de données ?

2018-08-09 Par sujet osm . sanspourriel 
Je vois que sur OSM.org 
 
ou OSM.fr 
, la 
ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe 
s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée 
une ligne TGV d'Auray à Quiberon ;-).


Comme les deux systèmes affichent la même chose ainsi que le rendu HOT 
mais que la carte cyclable 
 
est bonne comme la carte transports je me demande s'il n'y a pas un 
bogue dans l'affichage cartoCSS/Mapnik.


Je n'ai pas trouvé d'erreur, en particulier au point d'arrivée 
https://www.openstreetmap.org/node/252291030


Quelqu'un de plus doué pour trouver l'origine de l'erreur ?

De plus un local de l'étape peut confimrer que c'est le segment 
https://www.openstreetmap.org/way/23305663#map=17/47.68052/-3.00281 qui 
manque à la relation côté Auray ?


https://www.openstreetmap.org/way/262550757#map=17/47.48634/-3.11656

http://tile.openstreetmap.fr/?zoom=17=47.48634=-3.11656

http://overpass-turbo.eu/s/AV2

[out:xml][timeout:250];
{{geocodeArea:Morbihan}}->.searchArea;
(
  node["name"="Ligne d'Auray à Quiberon"](area.searchArea);
  way["name"="Ligne d'Auray à Quiberon"](area.searchArea);
  relation["name"="Ligne d'Auray à Quiberon"](area.searchArea);
);
(._;>;);
out meta;

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

Re: [OSM-talk-fr] Lit-et-Mixe

2018-08-09 Par sujet Philippe Verdy 
Pour les communes associées dans une fusion-association, ou pour les
communes déléguées dans les communes nouvelles, ou pour les arrondissements
municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
fusionnée de droit est de niveau 8, et peut avoir aussi un
"admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
En règle générale place=* est indépendant de l'entité adminsitrative (on
devrait même se passer de "place=*" pour les relations, il est plus lié aux
nodes).
De même les chiffres de population devraient être sur la relation (quand il
en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
même relation dans certains cas pour certaines entités: 'de jure' contre
'de facto'; 'capitale politique' contre 'capitale administrative' ou
'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
souvent ce noeud n'a pas le même nom que l'entité administrative où il est
situé. Ce noeud donne plutôt une vision de géographie urbaine et non
politique.

Les statuts de "ville", "village", "borough" (admin_type=* sur les
relations administratives ou politiques ou autres) ne vont pas bien avec
les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
aucun statut administratif et ne sont pas clairement délimités au sein de
l'entité administrative.

Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
plus large que l'entité administrative (notamment dans les grandes
métropoles, mais parfois aussi des villes plus petites, pour inclure une
partie de leur périphérie): les "place" correspondent mieux en France à ce
que l'INSEE désigne dans sa géographie urbaine (indépendante de la
géographie administrative) qui évolue tout le temps et plus vite que la
géographie administrative.

Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
prend le pas

Le "place=suburb" est plus pour la compatibilité des rendus génériques
internationaux: c'est une approximation permettant juste des comparaisons
et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
le style/la taille du libellé , il n'a pas de valeur en tant que donnée
administrative, et sinon pour donner une priorité estimée de "l'importance"
du lieu dans les recherches puisque une carte ne peut pas tous les afficher
: ce "place=*" est juste un des critères possibles permettant de filtrer
les éléments à afficher en priorité).


Le 9 août 2018 à 11:20, djakk djakk  a écrit :

> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
> préférerai qu’on garde place=village ou place=town et que le détail
> administratif se fasse avec les admin_level= ...
> Car quand on se balade on ne ressent pas la ville ou le village par son
> côté administratif mais par son urbanisme et sa densité commerciale et sa
> densité de services.
>
> djakk
>
>
> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>
>> Le  4 août 2018, Stéphane Péneau a écrit :
>>
>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est un
>> > peu délicat.
>> >
>> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
>> > suis pas trop d'accord. place=village est mieux adapté
>> >
>>
>> Bonjour,
>>
>> En complément de la réserve de Stéphane, c'est le même problème avec la
>> fusion récente de communes.
>> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
>> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> 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] édition mécanique : nettoyage is_in:continent

2018-08-09 Par sujet deuzeffe 

Je ne suis pas contre ;p

On 08/08/2018 01:40, marc marc wrote:

Bonsoir,

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

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

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

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

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



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

Re: [OSM-talk-fr] Lit-et-Mixe

2018-08-09 Par sujet djakk djakk 
Oui tout à fait c’est le même problème avec les communes fusionnées. Je
n’aime pas l’utilisation du place=suburb pour les communes associées ... je
préférerai qu’on garde place=village ou place=town et que le détail
administratif se fasse avec les admin_level= ...
Car quand on se balade on ne ressent pas la ville ou le village par son
côté administratif mais par son urbanisme et sa densité commerciale et sa
densité de services.

djakk


Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :

> Le  4 août 2018, Stéphane Péneau a écrit :
>
> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est un
> > peu délicat.
> >
> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
> > suis pas trop d'accord. place=village est mieux adapté
> >
>
> Bonjour,
>
> En complément de la réserve de Stéphane, c'est le même problème avec la
> fusion récente de communes.
> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>
> --
> Alain Rpnpif
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition mécanique : nettoyage is_in:continent

2018-08-09 Par sujet Philippe Verdy 
On pourrait ajouter "is_in:country" qui ne devrait plus servir à rien
maintenant qu'on a les frontières des pays (et qu'il a été décidé de
délimiter les zones contestées ou revendiquées par plusieurs pays dans des
relations séparées hors des revendications de chaque pays, avec un tag
spécifique).
La plupart des "is_in" était pour palier le manque provisoire de relations
de délimitation des frontières en indiquant cela sur des noeuds. Il reste
encore des "is_in:region=*" ou similaire pour des entités infra-nationales
non encore délimitées, notamment pas mal au niveau des municipalités ou
subdivisions nationales de 2e niveau (la plupart des délimitations de
premier niveau sont déjà dans la base, et notamment les "is_in:state=*"
pour les pays fédérés sont maintenant aussi inutiles.

Personnellement je considère les "is_in" un peu comme des "notes"
informatives à traiter comme des éléments "à faire". Ce ne sont pas
réellement des données exploitables (et encore moins le "is_in=*" qui
accepte une liste, que les "is_in:type=*" qui peuvent encore avoir une
utilité).

Pour l'Europe et l'Amérique du Nord au moins, la quasi totalité des
"is_in=*" ou "is_in:type=*" est maintenant inutile puisque les relations
nécessaires sont là.

De plus les tags "is_in[:type]=*" sont dépréciés plutôt en faveur des
membres de rôle "subarea" dans les relations :je sais certains n'aiment pas
les subarea, mais les requêtes spatiales sont lourdes et pas forcément
appropriées pour trouver les subdivisions correctes dans les cas connus où
la structure hiérarchique des niveaux n'est pas aussi stricte qu'on le
pense, et les "subarea" lèvent ces ambiguités et ont un coût négligeable
puisque c'est un seul membre ajouté par relation dans la relation parente
appropriée et n'implique aucun ajoute de relation supplémentaire, et sont
simples à gérer et vérifier de façon exhaustive et permettent aussi de
relever les cas de revendications territoriales multiples/contestées,
telles que les revendications chinoises contre celles de ses voisins, et
cela permet d'adapter les rendus carto selon les pays demandeurs et peut
permettre de lever des conflits d'édition en donnant la place à chaque
point de vue).

Bien souvent en plus on peut aussi utiliser les subarea pour créer et
référencer des relations incomplètes, dans lesquelles les membres
n'auraient encore que des noeuds (un "admin_centre", parfois 2 ou 3 pour
certaines entités comme l'Afrique du Sud qui a 3 capitales, et
éventuellement et encore d'autres pour les villes non encore tracées): ces
relations incomplètes sont faciles à trouver et on peut aussi y mettre un
tag "note" ou "fixme" pour bien indiquer ce qui reste à y faire pour les
délimiter ou ajouter des notes sur les difficultés ou contestations de
revendications. Il est simple de créer une liste exhaustive de relations
même incomplètes et continuer ensuite : au lieu des "is_in" dispersés, on
centralise l'info les sur la relation parente (même incomplète) avec ses
membres "subarea".

Les requêtes à la base de données sont largement simplifiées et beaucoup
plus rapide (avec beaucoup moins de données à scanner), et le modèle des
subarea est très résistant aux cas des relations brisées (dont certains
ways membre ont été scindés), et facilitent la réparation. Certains ont cru
à tord que les "subarea" étaient un conflit entre "modèle de surface" et
"modèle de frontière", ce n'est pas le cas car cela a toujours été les deux
en même temps: les subarea c'est autre chose et traduit seulement la
reconnaissance d'une sous-entité territoriale/administrative comme partie
d'une entité territoriale maître (voire plusieurs en cas de conflit de
revendications): les "subarea" gèrent très bien ces conflits et sont très
résistants. Il sont très peu coûteux, solides et efficaces, très faciles à
gérer et donnent un excellent rapport de complétude. Cela se construit très
vite avec peu de modifications à la base; même dans les éditeurs il devient
facile de naviguer entre niveaux. Et ils sont une méthode bien plus
efficace pour construire sans erreur (ou beaucoup moins d'erreurs) les
frontières ou pour ensuite les modifier (réformes adminstratives) sans
oubli : on sait facilement où en en est, on évite aussi des doublons
d'objets.

Les membres de rôle "subarea" ne sont pas non plus limités aux seuls
frontières administratives; on a dans la base d'autres objets comme les
limites fiscales, judiciaires, postales, militaires... En France aussi on a
les "local_authority" assez compliqués pour les EPCI (il n'y a pas que les
seuls ECPI à fiscalité propre, et même on a des cas où des ECPI ont leurs
propres subdivisions comme les métropoles de Paris ou Nantes), et qui
bougent régulièrement: il est là aussi facile de mettre dans la relation de
l'EPCI la listes des communes membres: la construction et vérification des
frontières en est facilité pour ensuite y mettre ou maintenir les ways
membres en rôle "outer"/"inner".

Certaines entités ont plusieurs types de découpages en