Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

2013-02-05 Par sujet Stéphane Péneau 

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

2013-02-05 Par sujet Stéphane Péneau 

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

2013-02-04 Par sujet sly (sylvain letuffe) 
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

2013-02-01 Par sujet Frédéric Rodrigo 
Le 1 février 2013 10:33, Stéphane Péneau  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

2013-02-01 Par sujet Stéphane Péneau 


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

2013-02-01 Par sujet Stéphane Péneau 

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

2013-02-01 Par sujet Frédéric Rodrigo 
Le 1 février 2013 09:41, Stéphane Péneau  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=12&lat=47.0331&lon=-**
> 1.33732&layers=**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

2013-02-01 Par sujet Stéphane Péneau 

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=12&lat=47.0331&lon=-1.33732&layers=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

2012-11-14 Par sujet sly (sylvain letuffe) 
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

2012-11-13 Par sujet Nicolas Frery 
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

2012-10-23 Par sujet Philippe Verdy 
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

2012-10-23 Par sujet Stéphane Péneau 

@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

2012-10-23 Par sujet Philippe Verdy 
Le 23 octobre 2012 17:08, Ab_fab  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=12&lat=47.05131&lon=-1.36969&layers=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

2012-10-23 Par sujet Ab_fab 
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=12&lat=47.05131&lon=-1.36969&layers=B00FFT

2012/10/23 Stéphane Péneau 

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



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

2012-10-23 Par sujet sly (sylvain letuffe) 
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

2012-10-23 Par sujet Stéphane Péneau 
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

2012-10-23 Par sujet Stéphane Péneau 



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=12&lat=47.05131&lon=-1.36969&layers=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

2012-10-20 Par sujet Philippe Verdy 
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  a écrit :
>
> Le 20 octobre 2012 19:42, Stéphane Péneau  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

2012-10-20 Par sujet Philippe Verdy 
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  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

2012-10-20 Par sujet Stéphane Péneau 

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

2012-10-20 Par sujet sly (sylvain letuffe) 
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=13&lat=46.8784&lon=-1.67533&layers=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

2012-10-20 Par sujet Philippe Verdy 
Le 20 octobre 2012 18:25, Philippe Verdy  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=7&lat=46.88444&lon=-1.68743&layers=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=7&lat=46.88444&lon=-1.68743&layers=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

2012-10-20 Par sujet Philippe Verdy 
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=7&lat=46.88444&lon=-1.68743&layers=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=7&lat=46.88444&lon=-1.68743&layers=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  a écrit :
> Le 20 octobre 2012 16:56, 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.
>>
>> Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple
>> Falleron :
>> http://layers.openstreetmap.fr/?zoom=13&lat=46.8784&lon=-1.67533&layers=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

Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

2012-10-20 Par sujet Philippe Verdy 
Le 20 octobre 2012 16:56, 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.
>
> Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple
> Falleron :
> http://layers.openstreetmap.fr/?zoom=13&lat=46.8784&lon=-1.67533&layers=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 élimin

Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

2012-10-20 Par sujet Stéphane Péneau 

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=13&lat=46.8784&lon=-1.67533&layers=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

2012-10-19 Par sujet Stéphane Péneau 

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

Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

2012-10-19 Par sujet sly (sylvain letuffe) 
On vendredi 19 octobre 2012, Stéphane Péneau wrote:
> 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=6&lat=46.58797&lon=1.85904&layers=B00FFT

Sauf erreur, ça sera remis à jour d'ici 24h (je peux te soustraiter la 
vérification dans 24h ?)
 
> 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.

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


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

2012-10-19 Par sujet Stéphane Péneau 
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=6&lat=46.58797&lon=1.85904&layers=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

2012-10-19 Par sujet Stéphane Péneau 

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

2012-10-18 Par sujet sly (sylvain letuffe) 
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

Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

2012-10-18 Par sujet Pierre Béland 
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) 
>À : Discussions sur OSM en français  
>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

2012-10-18 Par sujet Ab_fab 
http://www.openstreetmap.org/browse/relation/78849

Le 18 octobre 2012 16:33, sly (sylvain letuffe)  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 
"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

2012-10-18 Par sujet sly (sylvain letuffe) 
> 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

2012-10-18 Par sujet Stéphane Péneau 

Le 18/10/2012 16:05, sly (sylvain letuffe) a écrit :

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.
  


Ok, merci pour l'info.

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


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

2012-10-18 Par sujet Francescu GAROBY 
Oupsss... J'avais raté ça, merci ! :-)

Le 18 octobre 2012 16:06, sly (sylvain letuffe)  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

2012-10-18 Par sujet sly (sylvain letuffe) 
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

2012-10-18 Par sujet sly (sylvain letuffe) 
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

2012-10-18 Par sujet Francescu GAROBY 
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  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=11&lat=46.94176&lon=-**
> 1.49921&layers=**B00FFT
>
> Stf
>
>
>
>
> __**_
> 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

2012-10-18 Par sujet Stéphane Péneau 
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

2012-10-18 Par sujet Stéphane Péneau 

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=11&lat=46.94176&lon=-1.49921&layers=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

2012-10-18 Par sujet sly (sylvain letuffe) 
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