Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Ah ok, j'avais compris que tu allais le corriger. Tant pis. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 01/02/2013 11:55, Frédéric Rodrigo a écrit : Le résultat actuel avait du prendre 2 mois à temps complet à 9 process (3 machines à 3 process). L'outil est un bougiboulga de c/python/ruby/perl (rayer la mention inutile s'il y a). http://lists.openstreetmap.org/pipermail/dev-fr/2011-January/000148.html Si tu veux te lancer là dedans l'idée serait de juste faire les communes manquantes. Si tu le fais je suis intéressé par les GPX produits. Malheureusement ça ne m'a pas l'air dans mes cordes. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le vendredi 01 février 2013 09:41:37, Stéphane Péneau a écrit : Bonjour Sly, Ce bug a été corrigé ou pas ? Celui que tu avais signalé en octobre ? Non, pas corrigé, et je ne compte pas le corriger. Toujours la même réponse donc : http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/050404.html En un mot : ça va* se réparer tout seul dimanche prochain. * ou disons : devrait Plus globalement, toutes les communes des pays de la loire sont vectorisées depuis longtemps (à l'exception de 2 en Mayenne), et pourtant, il y a pas mal de blanc. Le calcul a lieu tous les dimanche matin à 3h00. Si dimanche matin prochain, que personne n'a touché la commune entre le moment du calcul et le moment ou tu regardes et qu'elle est toujours en blanc... alors tu as trouvé un bug et j'aurais besoin de l'id de la relation pour tenter d'y voir plus clair Les deux que tu m'as cité : Aigrefeuille sur Maine : a été retouché aujourd'hui Remouillé : bien en bleu -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Bonjour Sly, Ce bug a été corrigé ou pas ? Je pose la question car il y en encore pas mal de commune qui passent en blanc. Exemple : http://layers.openstreetmap.fr/?zoom=12lat=47.0331lon=-1.33732layers=BFFTF Ces communes de Aigrefeuille sur Maine et Remouillé étaient en bleu encore récemment. Plus globalement, toutes les communes des pays de la loire sont vectorisées depuis longtemps (à l'exception de 2 en Mayenne), et pourtant, il y a pas mal de blanc. Stéphane. Le 23/10/2012 17:08, sly (sylvain letuffe) a écrit : On mardi 23 octobre 2012, Stéphane Péneau wrote: Ha, peut-être une piste : Il y a 2 jours, j'ai touché légèrement à certains chemins composant ces relations. Ouais, moi aussi je croyais avoir trouvé, ça correspondait pile poil avec un changement du chemin au 21 octobre, mais comme il a eu lieu après le calcul et que si je lance le calcul à la main ça marche ha mais au put eureka ! C'est toi qui m'a mis sur la voi (rie) ;-) Ho le bug de conception que j'ai trop honte de le dévoiler... En un mot : ça va se réparer tout seul dimanche prochain. En 17 mots : toute retouche sur une relation ou un membre remet à zéro son nombre de km de voirie En 9876215 mots simples : ha ouais mais ça va être un peu plus compliqué que prévu à corriger parce que la table de postgis est liée à l'import de osm2pgsql et va donc perdre l'info qu'il faut que je remette dynamiquement car mon script php... et blabla blabla... enfin bref pas tout de suite. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 1 février 2013 09:41, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Ce bug a été corrigé ou pas ? Je pose la question car il y en encore pas mal de commune qui passent en blanc. Exemple : http://layers.openstreetmap.**fr/?zoom=12lat=47.0331lon=-** 1.33732layers=**BFFTFhttp://layers.openstreetmap.fr/?zoom=12lat=47.0331lon=-1.33732layers=BFFTF Ces communes de Aigrefeuille sur Maine et Remouillé étaient en bleu encore récemment. Pour ce problème je ne sais pas, je laisse Sly regarder. Les communes sont bien des polygones fermés ? Plus globalement, toutes les communes des pays de la loire sont vectorisées depuis longtemps (à l'exception de 2 en Mayenne), et pourtant, il y a pas mal de blanc. L'extraction de la base de référence cadastrale a été calculé au premier trimestre 2011 (et ça a pris le trimestre entier pour faire le calcul). Il n'est pas prévu de mise à jour. Si tu veux refaire des calculs ou une mise à jour, les scripts dispo sur le net. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le vendredi 1 février 2013 10:03:08, Frédéric Rodrigo a écrit : Pour ce problème je ne sais pas, je laisse Sly regarder. Les communes sont bien des polygones fermés ? Oui, j'ai vérifié leur relation il y a 1 ou 2 jours. L'extraction de la base de référence cadastrale a été calculé au premier trimestre 2011 (et ça a pris le trimestre entier pour faire le calcul). Il n'est pas prévu de mise à jour. Si tu veux refaire des calculs ou une mise à jour, les scripts dispo sur le net. Ces communes sont dans la base de référence, je voulais juste préciser que ce n'était pas localisé à la zone que j'ai mentionné, et que de nombreuses communes sont touchées. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
L'extraction de la base de référence cadastrale a été calculé au premier trimestre 2011 (et ça a pris le trimestre entier pour faire le calcul). Il n'est pas prévu de mise à jour. Si tu veux refaire des calculs ou une mise à jour, les scripts dispo sur le net. C'est compliqué à mettre en place ? Je pose la question car je vais avoir pendant quelques semaines un Bi Xeon 16 coeurs à 2.6Ghz (+ hyperthreading). J'imagine qu'il devrait être capable de calculer ça un peu plus rapidement. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 1 février 2013 10:33, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : C'est compliqué à mettre en place ? Je pose la question car je vais avoir pendant quelques semaines un Bi Xeon 16 coeurs à 2.6Ghz (+ hyperthreading). J'imagine qu'il devrait être capable de calculer ça un peu plus rapidement. Le résultat actuel avait du prendre 2 mois à temps complet à 9 process (3 machines à 3 process). L'outil est un bougiboulga de c/python/ruby/perl (rayer la mention inutile s'il y a). http://lists.openstreetmap.org/pipermail/dev-fr/2011-January/000148.html Si tu veux te lancer là dedans l'idée serait de juste faire les communes manquantes. Si tu le fais je suis intéressé par les GPX produits. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le mardi 13 novembre 2012 16:17:17, sly (sylvain letuffe) a écrit : Le mardi 13 novembre 2012 16:04:10, Nicolas Frery a écrit : Le 20/10/2012 18:56, sly (sylvain letuffe) a écrit : (en considérant toujours qu'une commune vectorisée depuis moins de 8 mois n'apparaissant pas n'est pas un bug mais une suggestion d'évolution) Cette évolution est prévu ? Pas pour l'instant, je suggère à celui qui a fait le gros du boulot A priori, il n'y aura pas de mise à jour ça lui représente trop de boulot. Si quelqu'un est motivé pour prendre la suite, qu'il contacte F. Rodrigo -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 13/11/2012 16:15, Vincent de Chateau-Thierry a écrit : Plus maintenu, tu en es sûr ? Qu'il n'y ait pas une grande activité sur ce thème certes, mais quand je vois ça : http://osm2.crans.org/stats.db/departement/osm_commune_65.html (exemple pas tout à fait au hasard :-) ) J'ai parlé un peu trop vite, j'avais des vielles images en cache... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On fait comme ça. Les communes des pays de la loire sont vectorisées depuis assez longtemps donc je n'ai pas trop de risque de tomber sur ce genre de cas. Je crois qu'il n'y a que quelques exceptions en mayenne. Le comportement est vraiment bizarre : Les communes de remouillé et aigrefeuille sur maine n'ont plus de couleur, alors qu'elles en avaient la semaine passée : http://layers.openstreetmap.fr/?zoom=12lat=47.05131lon=-1.36969layers=B00FFT Relation admin Remouillé : http://www.openstreetmap.org/browse/relation/80330 Aigrefeuille : http://www.openstreetmap.org/browse/relation/78301 Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Ha, peut-être une piste : Il y a 2 jours, j'ai touché légèrement à certains chemins composant ces relations. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On mardi 23 octobre 2012, Stéphane Péneau wrote: Ha, peut-être une piste : Il y a 2 jours, j'ai touché légèrement à certains chemins composant ces relations. Ouais, moi aussi je croyais avoir trouvé, ça correspondait pile poil avec un changement du chemin au 21 octobre, mais comme il a eu lieu après le calcul et que si je lance le calcul à la main ça marche ha mais au put eureka ! C'est toi qui m'a mis sur la voi (rie) ;-) Ho le bug de conception que j'ai trop honte de le dévoiler... En un mot : ça va se réparer tout seul dimanche prochain. En 17 mots : toute retouche sur une relation ou un membre remet à zéro son nombre de km de voirie En 9876215 mots simples : ha ouais mais ça va être un peu plus compliqué que prévu à corriger parce que la table de postgis est liée à l'import de osm2pgsql et va donc perdre l'info qu'il faut que je remette dynamiquement car mon script php... et blabla blabla... enfin bref pas tout de suite. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Dans ce cas, elles devraient être listées ici : http://openstreetmap.fr/outils/limites-communales-a-importer Et on ne verrait plus de vert là : http://layers.openstreetmap.fr/?zoom=12lat=47.05131lon=-1.36969layers=B00FFT 2012/10/23 Stéphane Péneau stephane.pen...@wanadoo.fr Ha, peut-être une piste : Il y a 2 jours, j'ai touché légèrement à certains chemins composant ces relations. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 23 octobre 2012 17:08, Ab_fab gamma@gmail.com a écrit : Dans ce cas, elles devraient être listées ici : http://openstreetmap.fr/outils/limites-communales-a-importer Et on ne verrait plus de vert là : http://layers.openstreetmap.fr/?zoom=12lat=47.05131lon=-1.36969layers=B00FFT Ces deux liens ne concernent que l'existence de la relation de frontière et sa fermeture correcte. Je pense que sly parlait d'autre chose : la table dans laquelle il a calculé le kilométrage de voiries pour une commune, et qui est purgée chaque fois que la relation est modifiée, même si elle existe encore et continue à être fermée (tout bonnement car la modification a pu changer l'inclusion de tout ou partie de cette voirie dans la surface (modifiée) de la commune. Bref la commune est toujours bonne et non listée à importer dans le premier lien, et toujours remplie en vert dans le second, puisqu'elle est encore correctement fermée, mais on a perdu l'info du kilométrage, qui devra être recalculé plus tard sur la nouvelle frontière. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
@Sly, Et bien bon courage pour la correction du bug. En tout cas ce que tu expliques me semble correspondre à ce que je vois, car il me semble bien que ces 2 communes étaient en bleu ou en vert dimanche dernier. @Ab_fab J'ai dis que j'avais touché à certains chemins, pas que j'avais cassé la relation :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Peut-être alors qu'au lieu de purger le kilométrage de voirie d'une commune quand sa frontière est modifiée, il serait plus judicieux de le conserver, en se contentant de le marquer comme étant à recalculer (une façon simple de le faire serait de changer le signe du kilométrage : négatif, c'est à recalculer, le signe négatif ne s'affichant pas dans le rendu, qui peut cependant afficher une petite astérisque mentionnant que le kilométrage n'est peut-être plus à jour) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
24h plus tard : Au zoom 7, ça a l'air d'être ok, par contre, pas au zoom 6. Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple Falleron : http://layers.openstreetmap.fr/?zoom=13lat=46.8784lon=-1.67533layers=B00FFT La relation de Falleron : http://www.openstreetmap.org/browse/relation/166092 Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 20 octobre 2012 16:56, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : 24h plus tard : Au zoom 7, ça a l'air d'être ok, par contre, pas au zoom 6. Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple Falleron : http://layers.openstreetmap.fr/?zoom=13lat=46.8784lon=-1.67533layers=B00FFT La relation de Falleron : http://www.openstreetmap.org/browse/relation/166092 Pour Falleron c'est une anomalie de remplissage de la zone (alors que la zone est bien prise en compte puisque son libellé apparaît bien centré). Ce cas apparaît parfois quand certaines zones voisines sont mal fermées, la formation des polygones est alors ambiguë quand on n'extrait qu'une partie des données (et que les données extraites semblent suffisantes). Dans d'autres cas c'est lié à l'existence d'une frontière en doublon (les deux frontières sont utilisées alors simultanément dans le rendu, ce qui permet de positionner le libellé et tracer les contours, mais pas de remplir la zone qui alors ne se ferme pas correctement). On voit assez souvent alors des anomalies de raccordement des remplissages entre une tuile et la tuile voisine (qui parfois aussi va remplir la zone de gris, mais pas sa tuile voisine). A chaque fois que j'ai vu ça, c'est qu'il y a une anomalie dans les données de la base ou bien des données incomplètes ou mal taguées (par exemple on a omis de taguer un segment de rivière utilisé comme frontière dans une relation, ou bien ce segment est oublié dans la relation, et l'extraction des données ne voit pas ce segment, ou bien il y a un segment en trop dans la relation, ou bien il manque des tags dans la relation elle-même pour qu'elle soit prise en compte correctement pour ce qu'elle est sensée représenter). Concernant certains retards de mise à jour, ces anomalies dans la base peuvent en être aussi la cause. Si on croit que c'est correct, on peut toujours faire (avec certains navigateurs qui le proposent comme Chrome) un clic droit sur la tuile concernée pour demander à l'afficher isolément dans un onglet séparé du navigateur, puis ajouter /dirty à son URL pour demander à ce qu'elle soit rafraîchie plus tôt (cela a aussi pour effet de demander le rafraîchissement d'un certain nombre de tuiles voisines au même niveau de zoom, mais cela ne demande pas le rafraîchissement des tuiles couvrant la zone aux autres niveaux de zoom). Si quelques minutes plus tard (délai variable selon la charge du serveur de tuiles, dont on peut savoir s'il a traité la demande de rafraîchissement en utilisant /status à la place de /dirty afin qu'il indique quelle en est la date et l'heure de génération), et en réaffichant la tuile dans l'onglet séparé (CTRL+R) on ne voit toujours aucun changement, c'est qu'il y a bien une anomalie à corriger dans la base, et il faut regarder plus en détail ce qui manque. = Noter une anomalie apparente de Chrome (à confirmer) : Une tuile correctement rafraîchie séparément dans un onglet pour afficher sa nouvelle version, peut, lorsqu'on l'affiche dans la page web de la carte générale, n'être affichée parfois que dans son ancienne version. Chrome semble se mélanger dans la gestion de son cache, lorsque les images sont chargées par des requêtes HTTP dynamiques, au contraire des affichages demandés avec l'URL simple de la tuile, et son cache alors contient les deux versions : il se trompe en utilisant une version ancienne toujours présente aussi dans le cache. Ce n'est peut-être pas une anomalie du cache de Chrome, mais une anomalie du Javascript de la page web, dont les requêtes HTTP dynamiques utiliseraient certaines métadonnées comme par exemple un cookie de session dont il est tenu compte pour sélectionner la version de tuile à utiliser, ce cookie n'étant pas utilisé quand on demande la tuile dans un onglet séparé. La seule parade à ça pour l'instant, est de vider le cache du navigateur, car même la fermeture et la réouverture du navigateur, ou le rafraîchissement de la page web ne lui suffit pas à utiliser la version plus récente dans son cache, alors qu'il affiche parfaitement la version plus récente quand on la demande séparément. Cette purge du cache suffit à effacer la version marquée du cookie de session (une nouvelle session sera créée avec ses propres cookies, qui affichera la version récente de la tuile même si c'est la même version rendue que celle affichée séparément hors de cette session). L'anomalie peut aussi être causée par des métadonnées différentes retournées par le serveur suivant les deux types de requêtes HTTP qui sont, visiblement, différentes (l'une des requêtes, celle pour l'affichage de la tuile isolée, est plus dépouillée que l'autre, celle effectuée par les requêtes dynamiques en javscript du framework OpenLayers). J'ai tendance ici à penser que c'est une anomalie du framework OpenLayers (qui effectue des requêtes HTTP trop riches en paramètres pour obtenir les tuiles au lieu de se contenter seulement de leur URL en
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
En fouillant un peu mieux, je constate en fait l'inverse : c'est l'affichage de la tuile dans un onglet séparé qui effectue la requête HTTP la plus riche : Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET Entêtes : GET /voirie-cadastre/7/63/45.png HTTP/1.1 Host: b.layers.openstreetmap.fr Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7lat=46.88444lon=-1.68743layers=B00FFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 If-None-Match: 4ceeff3b43fdaeca2ff3ff59c6510421 alors que dans la page web la requête HTTP faite par OpenLayers ne contient que : Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET sans aucun autre entête. La réponse du serveur, même si c'est la même, est alors stockée dans le cache séparément puisque les résultats de ces requêtes dépendent (logiquement) de ces entêtes. Parmi les entêtes justifiant le stockage des deux versions de la tuile dans le cache du navigateur, il y a notamment tous ceux-là (ajoutés par le navigateur, mais pas par le framework OpenLayers dans ses requêtes dynamiques, mais dont il est tenu compte pour savoir si les versions doivent être séparées dans le cache du navigateur) : Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7lat=46.88444lon=-1.68743layers=B00FFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 Dans ce cas, ce n'est pas réellement une anomalie du serveur de tuiles, ni du navigateur. Je ne vois pas de parade évidente et immédiate pour le corriger dans le framework OpenLayers, qui n'a pas connaissance de la plupart de ces autres entêtes et dont il n'a pas lui-même besoin (pas plus que le serveur de tuiles non plus, à moins qu'il lui prenne un jour de tenir compte de Accept-Language: pour retourner des tuiles affichant ses libellés dans la langue préférée de l'utilisateur et configurée dans son navigateur, ce qui nécessiterait qu'OpenLayers ajoute ce paramètre de langue dans ses requêtes dynamiques, en tirant sa valeur de celle déjà présente dans la page web où il va afficher les tuiles qu'il demande). Le 20 octobre 2012 18:02, Philippe Verdy verd...@wanadoo.fr a écrit : Le 20 octobre 2012 16:56, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : 24h plus tard : Au zoom 7, ça a l'air d'être ok, par contre, pas au zoom 6. Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple Falleron : http://layers.openstreetmap.fr/?zoom=13lat=46.8784lon=-1.67533layers=B00FFT La relation de Falleron : http://www.openstreetmap.org/browse/relation/166092 Pour Falleron c'est une anomalie de remplissage de la zone (alors que la zone est bien prise en compte puisque son libellé apparaît bien centré). Ce cas apparaît parfois quand certaines zones voisines sont mal fermées, la formation des polygones est alors ambiguë quand on n'extrait qu'une partie des données (et que les données extraites semblent suffisantes). Dans d'autres cas c'est lié à l'existence d'une frontière en doublon (les deux frontières sont utilisées alors simultanément dans le rendu, ce qui permet de positionner le libellé et tracer les contours, mais pas de remplir la zone qui alors ne se ferme pas correctement). On voit assez souvent alors des anomalies de raccordement des remplissages entre une tuile et la tuile voisine (qui parfois aussi va remplir la zone de gris, mais pas sa tuile voisine). A chaque fois que j'ai vu ça, c'est qu'il y a une anomalie dans les données de la base ou bien des données incomplètes ou mal taguées (par exemple on a omis de taguer un segment de rivière utilisé comme frontière dans une relation, ou bien ce segment est oublié dans la relation, et l'extraction des données ne voit pas ce segment, ou bien il y a un segment en trop dans la relation, ou bien il manque des tags dans la relation elle-même pour qu'elle soit prise en compte correctement pour ce qu'elle est sensée représenter). Concernant certains retards de mise à jour, ces anomalies dans la base peuvent en être aussi la cause. Si on croit que c'est correct, on peut toujours faire (avec certains navigateurs qui le proposent comme Chrome) un clic droit sur la tuile concernée pour demander à l'afficher isolément dans un onglet séparé du navigateur, puis ajouter /dirty à son URL pour demander à ce qu'elle soit rafraîchie plus tôt (cela a aussi pour
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 20 octobre 2012 18:25, Philippe Verdy verd...@wanadoo.fr a écrit : En fouillant un peu mieux, je constate en fait l'inverse : c'est l'affichage de la tuile dans un onglet séparé qui effectue la requête HTTP la plus riche : Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET Entêtes : GET /voirie-cadastre/7/63/45.png HTTP/1.1 Host: b.layers.openstreetmap.fr Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7lat=46.88444lon=-1.68743layers=B00FFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 If-None-Match: 4ceeff3b43fdaeca2ff3ff59c6510421 alors que dans la page web la requête HTTP faite par OpenLayers ne contient que : Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET sans aucun autre entête. La réponse du serveur, même si c'est la même, est alors stockée dans le cache séparément puisque les résultats de ces requêtes dépendent (logiquement) de ces entêtes. Parmi les entêtes justifiant le stockage des deux versions de la tuile dans le cache du navigateur, il y a notamment tous ceux-là (ajoutés par le navigateur, mais pas par le framework OpenLayers dans ses requêtes dynamiques, mais dont il est tenu compte pour savoir si les versions doivent être séparées dans le cache du navigateur) : Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7lat=46.88444lon=-1.68743layers=B00FFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 Dans ce cas, ce n'est pas réellement une anomalie du serveur de tuiles, ni du navigateur. Réflexion faite, ce peut être considéré comme une anomalie du navigateur (Chrome ici), quand lorsqu'on demande le rafraîchissement complet de la page web contenant les diverses tuiles déjà affichées, le navigateur n'invalide pas dans son cache les images qui sont actuellement affichées dans la page avant son rafraîchissement (ce qui forcerait aussi leur rechargement dans le cache) : il ne semble le faire que pour les images dont les URLs étaient stockées statiquement dans le code HTML de la page web, sans tenir compte du fait que ces images ont été insérées dynamiquement par un javascript (celles-là ne sont pas purgées du cache). Je peux aller demander ça aux auteurs de Chrome pour voir si ce n'est pas une anomalie à corriger (car c'est assez gênant qu'une demande de rafraîchissement complet d'une page ne se fasse qu'en partie, mais nécessite une purge préalable du cache du navigateur, alors que ce cache contient encore des images obsolètes qui ne disparaîtront toutes seules que très tardivement mais jamais par une demande simple de l'utilisateur autre que la purge complète du cache). Constatez-vous cette anomalie de rafraîchissement avec d'autres navigateurs ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le samedi 20 octobre 2012 16:56:02, Stéphane Péneau a écrit : 24h plus tard : Au zoom 7, ça a l'air d'être ok, par contre, pas au zoom 6. ça, je ne peux pas trop dire d'où ça vient, j'ai transmis à la bonne personne Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple Falleron : http://layers.openstreetmap.fr/?zoom=13lat=46.8784lon=-1.67533layers=B00 FFT La relation de Falleron : http://www.openstreetmap.org/browse/relation/166092 Le recalcul ayant lieu dimanche prochain (demain) c'est ça qui manquait. J'ai relancé juste pour cette zone et ça semble être revenu. Attendons donc lundi voir si tout revient dans l'ordre après un re-calcul complet. idem, je te laisse revenir indiquer par un mail si tu trouves à nouveau un problème ? (en considérant toujours qu'une commune vectorisée depuis moins de 8 mois n'apparaissant pas n'est pas un bug mais une suggestion d'évolution) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 20/10/2012 18:56, sly (sylvain letuffe) a écrit : Le recalcul ayant lieu dimanche prochain (demain) c'est ça qui manquait. J'ai relancé juste pour cette zone et ça semble être revenu. Attendons donc lundi voir si tout revient dans l'ordre après un re-calcul complet. idem, je te laisse revenir indiquer par un mail si tu trouves à nouveau un problème ? (en considérant toujours qu'une commune vectorisée depuis moins de 8 mois n'apparaissant pas n'est pas un bug mais une suggestion d'évolution) On fait comme ça. Les communes des pays de la loire sont vectorisées depuis assez longtemps donc je n'ai pas trop de risque de tomber sur ce genre de cas. Je crois qu'il n'y a que quelques exceptions en mayenne. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Visiblement il y a bien un problème de données dans la base, ce qui explique que les communes ne se remplissent pas. Certaines ont été importées plusieurs fois (dans plusieurs relations de même type et de même nom), tout autour de Challans (Vendée). Quand les données sont exportées et les polygones formés pour le rendu, ces multiples tracés se combinent (ils font partie de la même sélection, le rendu se fiche complètement de savoir de quelle relation ou de quelle autre viennent ces tracés), ce qui « évide » le polygone obtenu, mais cela n'empêche pas le libellé central d'apparaître au bon endroit malgré tout. Encore une justification du fait que les tracés superposés sont nuisibles (on a du mal à les distinguer dans les éditeurs, et les vérifications de polygones ou des polygones adjacents ne trouvent aucun problème, car ce sont en fait des polygones différents chacun d'eux étant correctement fermé, même si leur géométrie est identique, ou quasiment identique, au point qu'on n'en voit qu'un). Je vais nettoyer tout ça (mais la correction simple en utilisant les relations dépendantes ne suffit pas, il faut charger tous les objets dans la zone où figure ces doublons, sauf que c'est difficile de voir où ils sont). Le 20 octobre 2012 19:42, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le 20/10/2012 18:56, sly (sylvain letuffe) a écrit : Le recalcul ayant lieu dimanche prochain (demain) c'est ça qui manquait. J'ai relancé juste pour cette zone et ça semble être revenu. Attendons donc lundi voir si tout revient dans l'ordre après un re-calcul complet. idem, je te laisse revenir indiquer par un mail si tu trouves à nouveau un problème ? (en considérant toujours qu'une commune vectorisée depuis moins de 8 mois n'apparaissant pas n'est pas un bug mais une suggestion d'évolution) On fait comme ça. Les communes des pays de la loire sont vectorisées depuis assez longtemps donc je n'ai pas trop de risque de tomber sur ce genre de cas. Je crois qu'il n'y a que quelques exceptions en mayenne. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Diffiile de voir ce qui cloche. En revérifiant tout. En plus, dès que je regarde un peu plus, on trouve davantage de communes pour lesquelles la couche Voirie/Cadastre disparait (plus aucune statistique calculée, dont plus de couleur non plus). On dirait que c'est plutôt le calcul de cette couche qui oublie de calculer des communes pour je ne sais quelle raison : s'il y a des doublons ou un problème d'indexation c'est dans ce calcul sur sa propre base et pas dans OSM lui-même. En attendant les communes, communautés de communes, cantons, circonscriptions législatives, arrondissements, départements et régions sont corrects. A revoir donc demain quand le calcul de la couche voirie/cadastre sera réeffectué pour voir si ces communes sont encore une fois oubliées. Le 20 octobre 2012 22:21, Philippe Verdy verd...@wanadoo.fr a écrit : Le 20 octobre 2012 19:42, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le 20/10/2012 18:56, sly (sylvain letuffe) a écrit : Le recalcul ayant lieu dimanche prochain (demain) c'est ça qui manquait. J'ai relancé juste pour cette zone et ça semble être revenu. Attendons donc lundi voir si tout revient dans l'ordre après un re-calcul complet. idem, je te laisse revenir indiquer par un mail si tu trouves à nouveau un problème ? (en considérant toujours qu'une commune vectorisée depuis moins de 8 mois n'apparaissant pas n'est pas un bug mais une suggestion d'évolution) On fait comme ça. Les communes des pays de la loire sont vectorisées depuis assez longtemps donc je n'ai pas trop de risque de tomber sur ce genre de cas. Je crois qu'il n'y a que quelques exceptions en mayenne. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 18/10/2012 18:16, sly (sylvain letuffe) a écrit : On jeudi 18 octobre 2012, Ab_fab wrote: http://www.openstreetmap.org/browse/relation/78849 Donc, joli bug de trouvé ;-) Il s'avère que 50 communes au total étaient présentes en double dans une des tables, et ça faisait foirer la mise à jour. Un recalcul de environ 1h est en cours pour remettre ça au propre Je confirme que ça fonctionne de nouveau normalement. Merci ! Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
C'est vraiment mineur pour mon utilisation, mais au cas où ça cacherait un bug plus grave : Jusqu'au zoom 6, ce sont toujours les anciennes données qui sont affichées : Dès qu'on passe au zoom 7, ce sont les nouvelles données, ça se voit assez bien autour de Poitiers. http://layers.openstreetmap.fr/?zoom=6lat=46.58797lon=1.85904layers=B00FFT J'ai oublié de préciser que j'ai été obligé de vider le cache pour voir les nouvelles données de la couche voirie/cadastre, et que je l'ai refait avant de poster ce message. Stf Le 19/10/2012 10:10, Stéphane Péneau a écrit : Le 18/10/2012 18:16, sly (sylvain letuffe) a écrit : On jeudi 18 octobre 2012, Ab_fab wrote: http://www.openstreetmap.org/browse/relation/78849 Donc, joli bug de trouvé ;-) Il s'avère que 50 communes au total étaient présentes en double dans une des tables, et ça faisait foirer la mise à jour. Un recalcul de environ 1h est en cours pour remettre ça au propre Je confirme que ça fonctionne de nouveau normalement. Merci ! Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le 19/10/2012 14:28, sly (sylvain letuffe) a écrit : Sauf erreur, ça sera remis à jour d'ici 24h (je peux te soustraiter la vérification dans 24h ?) ça marche ! Il y a aussi des histoires avec les caches locaux dans ton navigateur, mais je trouve ça inutile, je vais en causer à celui qui gère ça Ah ? Heu ! Peut-être, je ne maitrise pas le sujet. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Hello sly, A quelle fréquence la couche voirie/cadastre est-elle mise à jour ? Merci Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On jeudi 18 octobre 2012, Stéphane Péneau wrote: Hello sly, A quelle fréquence la couche voirie/cadastre est-elle mise à jour ? mise à jour des longueurs de voiries selon cadastre : jamais (ça à 8 mois je crois) mise à jour des longueurs dans OSM : 1 fois par semaine mise à jour des tuiles : 1 fois par jour, parfois moins -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le jeudi 18 octobre 2012 15:41:33, sly (sylvain letuffe) a écrit : On jeudi 18 octobre 2012, Stéphane Péneau wrote: Hello sly, A quelle fréquence la couche voirie/cadastre est-elle mise à jour ? mise à jour des longueurs de voiries selon cadastre : jamais (ça à 8 mois je crois) mise à jour des longueurs dans OSM : 1 fois par semaine mise à jour des tuiles : 1 fois par jour, parfois moins Donc si je comprends bien : La couleur des tuiles est mises à jour 1 fois par jour alors que l'affichage de la longueur dans Osm est maj qu'une fois par semaine. Pourtant, pour choisir la couleur appropriée, il faut bien calculer la longueur dans osm, non ? S'il n'y a plus de couleur, cela signifie qu'un recalcul est en cours ? Par exemple ici en ce moment : http://layers.openstreetmap.fr/?zoom=11lat=46.94176lon=-1.49921layers=B00FFT Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Oupss, je pense que j'ai mal compris, et que pour les tuiles, il s'agit de celles du fond de carte. Par contre, ma dernière question reste valable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Par curiosité, on pourrait avoir la légende qui va avec ? Que signifient les couleurs et les chiffres (X/Y) sous le nom des communes ? Merci, Francescu Le 18 octobre 2012 15:58, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le jeudi 18 octobre 2012 15:41:33, sly (sylvain letuffe) a écrit : On jeudi 18 octobre 2012, Stéphane Péneau wrote: Hello sly, A quelle fréquence la couche voirie/cadastre est-elle mise à jour ? mise à jour des longueurs de voiries selon cadastre : jamais (ça à 8 mois je crois) mise à jour des longueurs dans OSM : 1 fois par semaine mise à jour des tuiles : 1 fois par jour, parfois moins Donc si je comprends bien : La couleur des tuiles est mises à jour 1 fois par jour alors que l'affichage de la longueur dans Osm est maj qu'une fois par semaine. Pourtant, pour choisir la couleur appropriée, il faut bien calculer la longueur dans osm, non ? S'il n'y a plus de couleur, cela signifie qu'un recalcul est en cours ? Par exemple ici en ce moment : http://layers.openstreetmap.**fr/?zoom=11lat=46.94176lon=-** 1.49921layers=**B00FFThttp://layers.openstreetmap.fr/?zoom=11lat=46.94176lon=-1.49921layers=B00FFT Stf __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On jeudi 18 octobre 2012, Stéphane Péneau wrote: Donc si je comprends bien : La couleur des tuiles est mises à jour 1 fois par jour alors que l'affichage de la longueur dans Osm est maj qu'une fois par semaine. Pourtant, pour choisir la couleur appropriée, il faut bien calculer la longueur dans osm, non ? Exact, donc pas tout à fait, la couleur et longueur OSM sont calculées chaque semaine. Oublie mon 1 jour, c'est vrai pour les autres calques, pour celui-là (c'est vrai aussi) mais ça ne change rien vu que rien n'est mis à jour avant le dimanche. S'il n'y a plus de couleur, cela signifie qu'un recalcul est en cours ? Le calcul ne prend qu'une heure le dimanche à 1h du mat, donc ce n'est pas ça. Quand c'est vide, c'est que je n'ai pas d'info sur le cadastre et/ou que la commune n'est pas dans OSM. Là, visiblement, c'est que les communes ne sont pas : - vectorisées au cadastre - ne l'était pas avant la date d'import d'il y a ~10 mois -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On jeudi 18 octobre 2012, Francescu GAROBY wrote: Par curiosité, on pourrait avoir la légende qui va avec ? Que signifient les couleurs et les chiffres (X/Y) sous le nom des communes ? C'est indiqué dans le lien en bas à gauche : http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Oupsss... J'avais raté ça, merci ! :-) Le 18 octobre 2012 16:06, sly (sylvain letuffe) li...@letuffe.org a écrit : On jeudi 18 octobre 2012, Francescu GAROBY wrote: Par curiosité, on pourrait avoir la légende qui va avec ? Que signifient les couleurs et les chiffres (X/Y) sous le nom des communes ? C'est indiqué dans le lien en bas à gauche : http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Ce n'est pas ce que je constate, car très souvent, il y a une couleur de visible, et lorsqu'il y a pas mal de voirie ajoutée sur une commune, pendant une période d'une durée indéterminée, ça reste sans rien, puis ensuite, une couleur revient. En mode de croisière cette durée c'est 1 semaine. Avec les changements sur les derniers mois, je n'exclu pas que j'ai pû oublié ce re-calcul et que ça a pu foirer D'ailleurs, si on prend l'exemple de la commune de legé, le bati a été intégré en 2010, donc elle est dispo en tant que commune vectorisée depuis plus de 10 mois. Tu peux me donner l'id de la relation pour legé ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
http://www.openstreetmap.org/browse/relation/78849 Le 18 octobre 2012 16:33, sly (sylvain letuffe) li...@letuffe.org a écrit : Ce n'est pas ce que je constate, car très souvent, il y a une couleur de visible, et lorsqu'il y a pas mal de voirie ajoutée sur une commune, pendant une période d'une durée indéterminée, ça reste sans rien, puis ensuite, une couleur revient. En mode de croisière cette durée c'est 1 semaine. Avec les changements sur les derniers mois, je n'exclu pas que j'ai pû oublié ce re-calcul et que ça a pu foirer D'ailleurs, si on prend l'exemple de la commune de legé, le bati a été intégré en 2010, donc elle est dispo en tant que commune vectorisée depuis plus de 10 mois. Tu peux me donner l'id de la relation pour legé ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
C'est un outil très pratique, avec en plus une couverture mondiale. J'aimerais bien que la recherche Nominatim ne se limite pas à la France. Aussi les deux éléments suivants, au bas de la page à droite, pourraient être francisés : - Permalien - Éditer avec Potllatch Pierre De : sly (sylvain letuffe) li...@letuffe.org À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 18 octobre 2012 10h06 Objet : Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr On jeudi 18 octobre 2012, Francescu GAROBY wrote: Par curiosité, on pourrait avoir la légende qui va avec ? Que signifient les couleurs et les chiffres (X/Y) sous le nom des communes ? C'est indiqué dans le lien en bas à gauche : http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
On jeudi 18 octobre 2012, Ab_fab wrote: http://www.openstreetmap.org/browse/relation/78849 Donc, joli bug de trouvé ;-) Il s'avère que 50 communes au total étaient présentes en double dans une des tables, et ça faisait foirer la mise à jour. Un recalcul de environ 1h est en cours pour remettre ça au propre -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
