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

2018-08-10 Par sujet Jérôme Seigneuret 
Car le rendu des styles DE et FR ne sont pas ceux de la carto mapnik carto
que tu trouves sur openstreetmap.org Le problème de raffraichissement ne
vient pas des données mais de la manière de rafraichir et de recalculer les
tuiles pour "mapnik carto"

Si je me trompe pas les serveurs de rendu sont utilisés en fonction de ta
proximité à un des serveurs. Le serveur qui fait les rendu mapnik carto
vers chez moi galère à mettre à jour les rendus correctement.
Les autres serveurs comme OSM FR et OSM DE avec leurs slyles ont un rendu
cohérent des données et les tuiles ne sont pas calculés sur les mêmes
serveurs que pour OSM Mapnik carto

Bref de mon coté il y a une c* dans le potage
Jérôme

Le ven. 10 août 2018 à 11:31,  a écrit :

> Pourquoi dis-tu "Carto DE pas de problème, corto osm.fr pas de problème"
> *Que je regarde le serveur français :*
>
> *http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
> **ou allemand :*
>
> *https://www.openstreetmap.de/karte.html?zoom=9=47.62499=-3.10881=B000TT
> **Je
> vois le soucis.*
>
> Que le serveur osm.org pose soucis par contre on est d'accord (mais ça
> s'améliore).
>
>
> Le 10/08/2018 à 10:58, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
> écrit :
>
> Salut,
>
> Ca reprend ce que je disais sur mes modifications.
> Carto DE pas de problème,
> corto osm.fr pas de problème
> carto .org: problème de mise à jour de tuile aléatoire et traitement sur
> zone mal pris en charge pour les mises à jour > affichage des landuse
> incohérent pareil pour les noms quels qu'ils soient.
>
> exemple:
> https://b.tile.openstreetmap.org/18/135336/92001.png
> dernière modification 2018-08-10 10:43:09
> Satut de la tuile : Tile is Clean.
> La date du dernier rendu correspond à la date de modification. avec
> l'heure en UTC
> y a t-il un problème de gestion des heures locale et UTC? Les dalles
> expirent sur 7jours glissants. J'aurais mon rendu seulement dans une
> semaine?
>
> Le serveur qui recalcul les dalles pour OSM.org a un problème sur le
> traitement des rafraîchissements de tuiles.
>
> Jérôme
>
>
> Le ven. 10 août 2018 à 09:56,  a écrit :
>
>> Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici
>>
>> Tu peux préciser ?
>> Que je regarde le serveur français :
>> http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
>> ou allemand :
>>
>> https://www.openstreetmap.de/karte.html?zoom=9=47.62499=-3.10881=B000TT
>> Je vois le soucis.
>> Par contre le problème a disparu jusqu'au niveau 12
>>  sur osm.org.
>>
>> Tu exclus le cache pourtant un problème temporaire aujourd'hui résolu
>> pourrait expliquer que les zooms faibles affichent le problème et plus les
>> zooms élevés.
>> Mais ajouter /dirty ne change rien.
>>
>> Jean-Yvon
>> ___
>> 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

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

2018-08-10 Par sujet Philippe Verdy 
Note: les zooms faibles sont raffraichis moins souvent à cause de la
quantité de calcul plus importante

Le ven. 10 août 2018 à 09:57,  a écrit :

> Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici
>
> Tu peux préciser ?
> Que je regarde le serveur français :
> http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
> ou allemand :
>
> https://www.openstreetmap.de/karte.html?zoom=9=47.62499=-3.10881=B000TT
> Je vois le soucis.
> Par contre le problème a disparu jusqu'au niveau 12
>  sur osm.org.
>
> Tu exclus le cache pourtant un problème temporaire aujourd'hui résolu
> pourrait expliquer que les zooms faibles affichent le problème et plus les
> zooms élevés.
> Mais ajouter /dirty ne change rien.
>
> 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-10 Par sujet Jérôme Seigneuret 
Salut,

Ca reprend ce que je disais sur mes modifications.
Carto DE pas de problème,
corto osm.fr pas de problème
carto .org: problème de mise à jour de tuile aléatoire et traitement sur
zone mal pris en charge pour les mises à jour > affichage des landuse
incohérent pareil pour les noms quels qu'ils soient.

exemple:
https://b.tile.openstreetmap.org/18/135336/92001.png
dernière modification 2018-08-10 10:43:09
Satut de la tuile : Tile is Clean.
La date du dernier rendu correspond à la date de modification. avec l'heure
en UTC
y a t-il un problème de gestion des heures locale et UTC? Les dalles
expirent sur 7jours glissants. J'aurais mon rendu seulement dans une
semaine?

Le serveur qui recalcul les dalles pour OSM.org a un problème sur le
traitement des rafraîchissements de tuiles.

Jérôme


Le ven. 10 août 2018 à 09:56,  a écrit :

> Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici
>
> Tu peux préciser ?
> Que je regarde le serveur français :
> http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
> ou allemand :
>
> https://www.openstreetmap.de/karte.html?zoom=9=47.62499=-3.10881=B000TT
> Je vois le soucis.
> Par contre le problème a disparu jusqu'au niveau 12
>  sur osm.org.
>
> Tu exclus le cache pourtant un problème temporaire aujourd'hui résolu
> pourrait expliquer que les zooms faibles affichent le problème et plus les
> zooms élevés.
> Mais ajouter /dirty ne change rien.
>
> 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-10 Par sujet osm . sanspourriel 

Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :

les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici 

Tu peux préciser ?
Que je regarde le serveur français :
http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
ou allemand :
https://www.openstreetmap.de/karte.html?zoom=9=47.62499=-3.10881=B000TT
Je vois le soucis.
Par contre le problème a disparu jusqu'au niveau 12 
 sur osm.org.


Tu exclus le cache pourtant un problème temporaire aujourd'hui résolu 
pourrait expliquer que les zooms faibles affichent le problème et plus 
les zooms élevés.

Mais ajouter /dirty ne change rien.

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 
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

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