Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

salut,

> si, la Côte d'Or :
> http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation_res
>ult.py?NumRelation=7424 Ménessaire est une exclave de la Côte d'Or à la
> limite entre la Nièvre et la Saône-et-Loire.
(...)
> J'ai utilisé une relation de relation. Peut-être n'ai pas bien taggé ?

Ma foi, ça me semble logique. 
Le problème est que les relations de relations ne sont pas très bien 
supportées par les outils en général.
( sauf à mon grand étonnement, l'analyseur de relation de Étienne !)

L'autre solution aurait été de placer les 3 ways de cette commune dans la 
relation "côte d'or". Là mon rendu l'aurait supporté. 
Mais comme toujours, si ceux qui tag se plient aux outils, ceux-ci n'ont plus 
de raison d'évoluer...

--
sly

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Denis]

sylvain letuffe a écrit :
>> Il y a des problèmes de rendus...
>> Mais pas seulement
>>
>> Une commune-département :
>> http://beta.letuffe.org/?zoom=12&lat=47.16872&lon=4.21068&layers=B0
>> FFTT
> 
> Ou un problème de saisie ?
> 
> J'ai éssayé d'ouvrir et de regarder la donnée, et la limite admin_level=6 se 
> sépare en deux (Nord et Sud). Cette commune n'appartient à aucun 
> département ?

si, la Côte d'Or : 
http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation_result.py?NumRelation=7424
Ménessaire est une exclave de la Côte d'Or à la limite entre la Nièvre 
et la Saône-et-Loire. Comme toutes les autres communes limitrophes sont 
en raster, le ban communal n'est composé que de 2 limites 
départementales : au nord avec la Nièvre et au sud avec la Saône et Loire.

> 
> Soit elle est dans la Nièvre soit dans la Saône et loire, auquel cas le 
> admin_level=6 doit alors passer au nord ou au sud, mais pas les deux

J'ai utilisé une relation de relation. Peut-être n'ai pas bien taggé ?

Denis

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

> Il y a des problèmes de rendus...
> Mais pas seulement
>
> Une commune-département :
> http://beta.letuffe.org/?zoom=12&lat=47.16872&lon=4.21068&layers=B0
>FFTT

Ou un problème de saisie ?

J'ai éssayé d'ouvrir et de regarder la donnée, et la limite admin_level=6 se 
sépare en deux (Nord et Sud). Cette commune n'appartient à aucun 
département ?

Soit elle est dans la Nièvre soit dans la Saône et loire, auquel cas le 
admin_level=6 doit alors passer au nord ou au sud, mais pas les deux

--
sly

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

Le samedi 16 mai 2009 14:01, Vincent Pottier a écrit :
> Mathieu Arnold a écrit :
> > Où alors, peut être c'est possible d'avoir avec le st_simplify pour les
> > zooms < 13 et sans pour les >= 13.
>
> +1

Bon tant pis pour les 20% à gagner, retour à la situation d'avant.

--
sly

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Vincent Pottier]

sylvain letuffe a écrit :
>> et puis on a plus l'info des bouts cartographes associés.
>> 
> Erreur de ma part, pour accélérer j'avais mis la condition admin_level=6, 
> mais 
> ça peut très bien être 4 
>
>   
>> Du coup je ne sais pas si c'est conseillé au delà d'un certain niveau
>> de zoom (puisqu'on ne trace pas le contour en entier le gain est peut-
>> être moindre ?
>> 
> En effet, je ne vais peu être activer cette simplification que sur les 
> faibles 
> zooms... ou la supprimer.
> Au mieux on dirait que ça ne gagne que 20%.
Il y a des problèmes de rendus...
Mais pas seulement

Une commune-département :
http://beta.letuffe.org/?zoom=12&lat=47.16872&lon=4.21068&layers=B0FFTT

Vincent

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Vincent Pottier]

Mathieu Arnold a écrit :
>
> Où alors, peut être c'est possible d'avoir avec le st_simplify pour les
> zooms < 13 et sans pour les >= 13.
>
>   
+1
Vincent

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Mathieu Arnold]

+--On 15 mai 2009 18:37:30 +0200 "sly (sylvain letuffe)"
 wrote:
| Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses 
| géométries type départements avant de les donner à mapnik et ça
| gagne de  20 à 30%
| (parfois bien plus, mais je pense heurter un problème de tunning de mon 
| postgres qui doit s' emmêler les buffers )

Je ne suis pas trop fan du st_simplify sur les départements, avec, je ne
peux pas savoir si la limite du département colle à celles des communes,
ou pas :



À choisir, je prendrais une version avec et une version sans le
st_simplify, avec pour quand je fais le tour des départements pour
réparer tout le monde, sans pour quand je veux être précis.

Où alors, peut être c'est possible d'avoir avec le st_simplify pour les
zooms < 13 et sans pour les >= 13.

-- 
Mathieu Arnold

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

> et puis on a plus l'info des bouts cartographes associés.
Erreur de ma part, pour accélérer j'avais mis la condition admin_level=6, mais 
ça peut très bien être 4 

> Du coup je ne sais pas si c'est conseillé au delà d'un certain niveau
> de zoom (puisqu'on ne trace pas le contour en entier le gain est peut-
> être moindre ?
En effet, je ne vais peu être activer cette simplification que sur les faibles 
zooms... ou la supprimer.
Au mieux on dirait que ça ne gagne que 20%.


>
> http://beta.letuffe.org/?zoom=12&lat=49.12445&lon=2.42226&layers=B0
>FFTT
>
> Yann
>
> Le 15 mai 09 à 18:37, sly (sylvain letuffe) a écrit :
> > Hélas comme j'en avais peur, le st_simplify sort des géométries
> > valides sur la
> > base de géométries non valides (le ST_SimplifyPreserveTopology semble
> > carrément toutes les corriger )
>
> ___
> 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] Beta letuffe - avancement communes - erreur

[Yann Coupin]

Bon ça fait surtout des trucs bizarre pour les frontières car la  
simplification n'est pas la même sur les contours des départements  
adjaçants, et puis on a plus l'info des bouts cartographes associés.  
Du coup je ne sais pas si c'est conseillé au delà d'un certain niveau  
de zoom (puisqu'on ne trace pas le contour en entier le gain est peut- 
être moindre ?

http://beta.letuffe.org/?zoom=12&lat=49.12445&lon=2.42226&layers=B0FFTT

Yann

Le 15 mai 09 à 18:37, sly (sylvain letuffe) a écrit :

> Hélas comme j'en avais peur, le st_simplify sort des géométries  
> valides sur la
> base de géométries non valides (le ST_SimplifyPreserveTopology semble
> carrément toutes les corriger )


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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

> Sinon, je serais interessee par les query que tu as mis en place :)
> Je ne me preoccupe pas du tout d'affichage mais je serais interessee par 
> les optimisations que tu obtiens.

en moyenne c'est de la bidouille "essais/erreurs", mais je files tout librement 
:
http:///beta.letuffe.org/mapnik-styles



> Par experience, Postgis a du mal avec les tres grosses geometries. De 
> plus, il existe un bug connu lie au pages TOAST qui ne tiennent pas 
> compte de la taille de la geometrie.
> Si la table est relativement petite et que la geometrie est enorme, les 
> index seront ignores par le planner de Postgres au profit d'un scan. 
> C'est quelque chose que j'ai deja subi. J'ai resolu le probleme en ne 
> faisant plus de scan sur la table qui posait probleme :p
> Plus serieusement, la solution generalement dans ce cas la est de 
> decouper les geometries, en partie plus petites avec un nombre limite de 
> points. Cela permet d'augmenter le nombre de ligne et de reduire la 
> taille de la geometrie.
> A noter que je parle d'un cas totalement different en premier lieu, donc 
> ca peut ne pas s'appliquer a ce que tu fais.
> 
> Emilie Laffray
> 
> sly (sylvain letuffe) wrote:
> >> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
> >> tenter un simplify() sur la colone geometry, avant de passer aux
> >> fonctions qui bourrinent.
> >> 
> >
> > Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en 
> > temps :
> > sans st_simplify :
> > http://beta.letuffe.org/cartes/communes.png : 1 minutes 30
> >
> > avec :
> > http://beta.letuffe.org/cartes/communes2.png : 15 secondes
> >
> > ( avec ST_SimplifyPreserveTopology :
> > http://beta.letuffe.org/cartes/communes3.png : 1 minute)
> >
> > Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur 
> > la 
> > base de géométries non valides (le ST_SimplifyPreserveTopology semble 
> > carrément toutes les corriger )
> >
> > Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses 
> > géométries type départements avant de les donner à mapnik et ça gagne de 
> > 20 à 30%
> > (parfois bien plus, mais je pense heurter un problème de tunning de mon 
> > postgres qui doit s' emmêler les buffers )
> >
> > A noter finalement que après tous ces tests, une vérité revient super 
> > régulièrement : Ce sont les disques durs qui sont limitant.
> >
> > Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que 
> > le 
> > noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 
> > 3 
> > à diviser par 10.
> >
> > Conclusion : mettre 16Go de RAM et laisser la base postgis sur un 
> > RAM-disque ;-)
> >
> >   
> 
> 
> ___
> 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] Beta letuffe - avancement communes - erreur

[Emilie Laffray]

Sinon, je serais interessee par les query que tu as mis en place :)
Je ne me preoccupe pas du tout d'affichage mais je serais interessee par 
les optimisations que tu obtiens.
Par experience, Postgis a du mal avec les tres grosses geometries. De 
plus, il existe un bug connu lie au pages TOAST qui ne tiennent pas 
compte de la taille de la geometrie.
Si la table est relativement petite et que la geometrie est enorme, les 
index seront ignores par le planner de Postgres au profit d'un scan. 
C'est quelque chose que j'ai deja subi. J'ai resolu le probleme en ne 
faisant plus de scan sur la table qui posait probleme :p
Plus serieusement, la solution generalement dans ce cas la est de 
decouper les geometries, en partie plus petites avec un nombre limite de 
points. Cela permet d'augmenter le nombre de ligne et de reduire la 
taille de la geometrie.
A noter que je parle d'un cas totalement different en premier lieu, donc 
ca peut ne pas s'appliquer a ce que tu fais.

Emilie Laffray

sly (sylvain letuffe) wrote:
>> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
>> tenter un simplify() sur la colone geometry, avant de passer aux
>> fonctions qui bourrinent.
>> 
>
> Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en 
> temps :
> sans st_simplify :
> http://beta.letuffe.org/cartes/communes.png : 1 minutes 30
>
> avec :
> http://beta.letuffe.org/cartes/communes2.png : 15 secondes
>
> ( avec ST_SimplifyPreserveTopology :
> http://beta.letuffe.org/cartes/communes3.png : 1 minute)
>
> Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur 
> la 
> base de géométries non valides (le ST_SimplifyPreserveTopology semble 
> carrément toutes les corriger )
>
> Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses 
> géométries type départements avant de les donner à mapnik et ça gagne de 
> 20 à 30%
> (parfois bien plus, mais je pense heurter un problème de tunning de mon 
> postgres qui doit s' emmêler les buffers )
>
> A noter finalement que après tous ces tests, une vérité revient super 
> régulièrement : Ce sont les disques durs qui sont limitant.
>
> Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que 
> le 
> noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 3 
> à diviser par 10.
>
> Conclusion : mettre 16Go de RAM et laisser la base postgis sur un 
> RAM-disque ;-)
>
>   


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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Emilie Laffray]

Ou acheter des SSD et les mettre en RAID 1 :p

Emilie Laffray

sly (sylvain letuffe) wrote:
>> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
>> tenter un simplify() sur la colone geometry, avant de passer aux
>> fonctions qui bourrinent.
>> 
>
> Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en 
> temps :
> sans st_simplify :
> http://beta.letuffe.org/cartes/communes.png : 1 minutes 30
>
> avec :
> http://beta.letuffe.org/cartes/communes2.png : 15 secondes
>
> ( avec ST_SimplifyPreserveTopology :
> http://beta.letuffe.org/cartes/communes3.png : 1 minute)
>
> Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur 
> la 
> base de géométries non valides (le ST_SimplifyPreserveTopology semble 
> carrément toutes les corriger )
>
> Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses 
> géométries type départements avant de les donner à mapnik et ça gagne de 
> 20 à 30%
> (parfois bien plus, mais je pense heurter un problème de tunning de mon 
> postgres qui doit s' emmêler les buffers )
>
> A noter finalement que après tous ces tests, une vérité revient super 
> régulièrement : Ce sont les disques durs qui sont limitant.
>
> Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que 
> le 
> noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 3 
> à diviser par 10.
>
> Conclusion : mettre 16Go de RAM et laisser la base postgis sur un 
> RAM-disque ;-)
>
>   


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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sly (sylvain letuffe)]

> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
> tenter un simplify() sur la colone geometry, avant de passer aux
> fonctions qui bourrinent.

Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en 
temps :
sans st_simplify :
http://beta.letuffe.org/cartes/communes.png : 1 minutes 30

avec :
http://beta.letuffe.org/cartes/communes2.png : 15 secondes

( avec ST_SimplifyPreserveTopology :
http://beta.letuffe.org/cartes/communes3.png : 1 minute)

Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur la 
base de géométries non valides (le ST_SimplifyPreserveTopology semble 
carrément toutes les corriger )

Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses 
géométries type départements avant de les donner à mapnik et ça gagne de 
20 à 30%
(parfois bien plus, mais je pense heurter un problème de tunning de mon 
postgres qui doit s' emmêler les buffers )

A noter finalement que après tous ces tests, une vérité revient super 
régulièrement : Ce sont les disques durs qui sont limitant.

Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que le 
noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 3 
à diviser par 10.

Conclusion : mettre 16Go de RAM et laisser la base postgis sur un 
RAM-disque ;-)

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org




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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

salut,

> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
> tenter un simplify() sur la colone geometry, avant de passer aux
> fonctions qui bourrinent.
>
> a+

Je n'y avais pas pensé dans ce cas. Le truc c'est qu'il ne faudrait pas que le 
st_simplify() rende la géométrie valide ;-) ça perdrait l'intérêt. Hors 
certaines erreurs de géométrie sont de l'ordre du mètre et je ne sais pas 
trop ce que fait l'algo Douglas-Peuker
http://postgis.refractions.net/documentation/manual-svn/ST_Simplify.html

a voir.

Mon expérience avec st_simplify m'indique que c'est une très bonne solution 
pour accélérer le temps de rendu mapnik (dans le cas des 
communes/dép/régions), mais ça déplace le problème vers postgres qui se met 
alors a consommer le cpu pour faire des simplify. 
pas simple

Merci pour l'idée en tout cas

--
sly

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur

[Pierre Mauduit]

Salut,

> Je m'étais pas rendu compte (j'avais mis ça sur le dos de corine) mais
> le 
> contrôle de géométrie sur chaque communes affichées en temps réél
> faisait 
> tripler le temps d'affichage du layer communes.
> 
Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être
tenter un simplify() sur la colone geometry, avant de passer aux
fonctions qui bourrinent.

a+

-- 

Pierre 


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

[OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sylvain letuffe]

> > Ce soir je me suis aperçu que sur beta letuffe un certain nombre de
> > communes sont rendues en gris.
> > Qu est ce que cela signifie ?
>
> Que les humeurs de l'admin ont changées ;-)

Et qu'elles ont rechangées, désolé, j'ai dû désactiver cette fonction 
"pour l'instant"

Ce serveur est déjà sur-sur-chargé et trop souvent on arrive plus rien à voir 
du tout.

paix à son cpu :
http://beta.letuffe.org/~www/graphs/

Je m'étais pas rendu compte (j'avais mis ça sur le dos de corine) mais le 
contrôle de géométrie sur chaque communes affichées en temps réél faisait 
tripler le temps d'affichage du layer communes.

Il va falloir que je passe par la case optimisation

--
sly

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Mathieu Arnold]

+--On 12 mai 2009 21:26:37 +0200 "sly (sylvain letuffe)"
 wrote:
| 
|> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
|> (parce que c'est comme ça, là)
| 
| L'art des modifications sans tests, heureusement qu'ils y'a des
| bétatesteurs  qui me surveille
| 
| C'était un poil terne ;-)

Puisqu'on parlait des communes en plusieurs parties, par exemple, là :

il y a un polygone en enclave dans Castelsarrasin qui vient de Castelmayran
(en exclave donc), et qui je pense, est deux fois en rose, ce qui fait que
c'est plus foncé, serait-il possible que l'enclave ne soit pas coloriée
par la commune qui l'englobe histoire que la couleur reste la même partout
? :-)

-- 
Mathieu Arnold

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Mathieu Arnold]

+--On 12 mai 2009 21:26:37 +0200 "sly (sylvain letuffe)"
 wrote:
| 
|> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
|> (parce que c'est comme ça, là)
| 
| L'art des modifications sans tests, heureusement qu'ils y'a des
| bétatesteurs  qui me surveille
| 
| C'était un poil terne ;-)

D'ailleurs, si tu veux un coup de main pour tripoter tout ça, j'ai une
petite expérience postgis suite à l'installation d'un serveur ROMA.

-- 
Mathieu Arnold

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Vincent Pottier]

sly (sylvain letuffe) a écrit :
>> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
>> (parce que c'est comme ça, là)
>> 
>
> L'art des modifications sans tests, heureusement qu'ils y'a des bétatesteurs 
> qui me surveille
>
> C'était un poil terne ;-)
>
>   
Mieux. Ouf ! Mes communes ne sont pas buggées !

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Vincent Pottier]

sly (sylvain letuffe) a écrit :
>> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
>> (parce que c'est comme ça, là)
>> 
>
> L'art des modifications sans tests, heureusement qu'ils y'a des bétatesteurs 
> qui me surveille
>
> C'était un poil terne ;-)
>
>   
Je trouvais que tout d'un coup beaucoup de communes étaient buggées dans
mon coin...
Je m'disais aussi...
J'ai eu peur un instant...

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[sly (sylvain letuffe)]

> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
> (parce que c'est comme ça, là)

L'art des modifications sans tests, heureusement qu'ils y'a des bétatesteurs 
qui me surveille

C'était un poil terne ;-)

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Mathieu Arnold]

+--On 12 mai 2009 15:58:02 +0200 "sly (sylvain letuffe)"
 wrote:
| 
|> Donc, on va dire que les communes que j'ai fait qui ont enclave/exclave
|> sont bonnes et que je ne vais pas avoir à les corriger :-)
| 
| hop j'ai trouvé comment retirer l'erreur pour les communes en plusieurs 
| morceaux

Et donc, toutes les communes pas en plusieurs morceaux sont en gris ?
(parce que c'est comme ça, là)

-- 
Mathieu Arnold

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[sly (sylvain letuffe)]

> Donc, on va dire que les communes que j'ai fait qui ont enclave/exclave
> sont bonnes et que je ne vais pas avoir à les corriger :-)

hop j'ai trouvé comment retirer l'erreur pour les communes en plusieurs 
morceaux

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org




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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Mathieu Arnold]

+--le 12.05.2009 15:26:36 +0200, sly (sylvain letuffe) écrivait :
| 
|> Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas
|> trouvé  d'auto-croisement ni de truc bizzarre, c'est peut-être donc
|> des fausses  alertes
| 
| Je viens de trouver un cas de fausse alerte :
| Lorsque la commune est en deux parties ou plus une erreur 
| "Hole lies outside shell at or near point" est sortie par postgis ce qui
| ne  rend pas pour autant la commune erronée.

Donc, on va dire que les communes que j'ai fait qui ont enclave/exclave
sont bonnes et que je ne vais pas avoir à les corriger :-)

-- 
Mathieu Arnold

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[sly (sylvain letuffe)]

> Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas trouvé 
> d'auto-croisement ni de truc bizzarre, c'est peut-être donc des fausses 
> alertes

Je viens de trouver un cas de fausse alerte :
Lorsque la commune est en deux parties ou plus une erreur 
"Hole lies outside shell at or near point" est sortie par postgis ce qui ne 
rend pas pour autant la commune erronée.

J'aimerais vous proposer une jolie croix à l'endroit du problème, mais je n'ai 
pas trouvé comment faire, donc c'est peu fastidieux

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org




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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Nicolas Bouthors]

sly (sylvain letuffe) a écrit :
> Les communes en gris sont considérées comme invalides dont la définition en 
> langage postgis est :
> "Returns true if this Geometry has no anomalous geometric points, such as 
> self 
> intersection or self tangency."

Eet ben j'ai du boulot moi :-(

-- 
Nicolas - http://nicolas.bouthors.org/album/

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[sly (sylvain letuffe)]

> Ca peut être une deuxième boucle mais aussi un segment du way qui
> revient en arrière puis à nouveau vers l'avant sur les mêmes noeuds.
J'ai fini par trouvé, c'était bien un croisement, merci pour l'idée en tout 
cas.

> C'est assez difficile à trouver (il faut bien regarder les flèches sur
> Josm ou - si mes souvenirs sont bon - utiliser le plugin validator).

J'avais bien pensé que la validator m'aiderait, mais je viens de re-vérifier 
et il n'annonce pas un auto-croisement comme une erreur


-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org




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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[Pieren]

2009/5/12 sly (sylvain letuffe) :
> Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas trouvé
> d'auto-croisement ni de truc bizzarre, c'est peut-être donc des fausses
> alertes
>

Ca peut être une deuxième boucle mais aussi un segment du way qui
revient en arrière puis à nouveau vers l'avant sur les mêmes noeuds.
C'est assez difficile à trouver (il faut bien regarder les flèches sur
Josm ou - si mes souvenirs sont bon - utiliser le plugin validator).
Pieren

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

Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre

[sly (sylvain letuffe)]

> Ce soir je me suis aperçu que sur beta letuffe un certain nombre de communes
> sont rendues en gris. 
> Qu est ce que cela signifie ?

Que les humeurs de l'admin ont changées ;-)

Petit blabla du pourquoi j'en suis arrivé là :
- j'avais déjà fourni des statistiques concernant le nombre de commune 
présentes dans OSM par département. Comme beaucoup l'ont remarqué, c'était 
assez peu fiable dû à un problème technique que je n'ai pas trop compris.

Pour améliorer les choses, j'ai trouvé une fonction postgis qui donne un point 
à l'intérieur d'une surface et évitait les erreurs de bordures. Bref, en 
voilà le résultat (en annexe) qui me semble bien plus cohérent et bien 
meilleur.

Mais je me suis heurté à un nouveau problème, sur certaines communes 
j'obtenais l'erreur :
"TopologyException: found non-noded intersection" (erreur de topologie)
J'ai pu ignorer ces communes problématiques en les passants à la fonction 
st_isvalid() qui détermine si la géométrie est "valide" ou non.

Les communes en gris sont considérées comme invalides dont la définition en 
langage postgis est :
"Returns true if this Geometry has no anomalous geometric points, such as self 
intersection or self tangency."

Ce n'est pas nécessairement un problème, j'imagine que des communes peuvent 
quand même avoir cette forme (quoi que ?) mais ça permet de les indiquer et 
vérifier ce qui plus probablement est une erreur.

Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas trouvé 
d'auto-croisement ni de truc bizzarre, c'est peut-être donc des fausses 
alertes

Annexe 1 stats :
Total:6784 (sans compter les départements oubliés)
donc 18.5% de communes françaises sont présentes dans OSM


ref;name;id relation;count
01;Ain;7387;22
02;Aisne;7411;114
03;Allier;7414;139
04;Alpes-de-Haute-Provence;7380;2
05;Hautes-Alpes;7436;21
06;Alpes-Maritimes;7385;21
07;Ardèche;7430;124
08;(none);(not in db);(unknown)
09;Ariège;7439;2
10;(none);(not in db);(unknown)
11;(none);(not in db);(unknown)
12;Aveyron;7451;159
13;Bouches-du-Rhône;7393;101
14;Calvados;7453;119
15;Cantal;7381;22
16;Charente;7428;146
17;Charente-Maritime;7431;117
18;Cher;7456;15
19;Corrèze;7464;94
20;(none);(not in db);(unknown)
21;Côte-d'Or;7424;134
22;(none);(not in db);(unknown)
23;Creuse;7459;236
24;(none);(not in db);(unknown)
25;Doubs;7462;206
26;Drôme;7434;302
27;Eure;7435;47
28;Eure-et-Loir;7374;24
29;Finistère;102430;8
30;Gard;7461;46
31;Haute-Garonne;7413;67
32;Gers;7422;399
33;Gironde;7405;297
34;(none);(not in db);(unknown)
35;(none);(not in db);(unknown)
36;Indre;7417;30
37;Indre-et-Loire;7408;129
38;Isère;7437;213
39;Jura;7460;21
40;Landes;7376;211
41;Loir-et-Cher;7399;2
42;Loire;7420;100
43;Haute-Loire;7452;25
44;Loire-Atlantique;7432;135
45;Loiret;7440;30
46;Lot;7454;323
47;Lot-et-Garonne;7416;44
48;Lozère;7421;31
49;Maine-et-Loire;7409;9
50;Manche;7404;19
51;Marne;7379;7
52;(none);(not in db);(unknown)
53;Mayenne;7438;2
54;(none);(not in db);(unknown)
55;(none);(not in db);(unknown)
56;(none);(not in db);(unknown)
57;(none);(not in db);(unknown)
58;(none);(not in db);(unknown)
59;(none);(not in db);(unknown)
60;Oise;7427;3
61;Orne;7419;2
62;Pas-de-Calais;7394;11
63;Puy-de-Dôme;7406;182
64;Pyrénées-Atlantiques;7450;2
65;(none);(not in db);(unknown)
66;Pyrénées-Orientales;7466;90
67;Bas-Rhin;7415;187
68;Haut-Rhin;7403;218
69;Rhône;7378;36
70;Haute-Saône;7423;8
71;Saône-et-Loire;7397;17
72;Sarthe;7443;326
73;Savoie;7425;300
74;Haute-Savoie;7407;293
75;Paris;71525;1
76;Seine-Maritime;7426;124
77;Seine-et-Marne;7383;86
78;Yvelines;7457;90
79;(none);(not in db);(unknown)
80;Somme;7463;40
81;(none);(not in db);(unknown)
82;Tarn-et-Garonne;7388;58
83;Var;7390;21
84;Vaucluse;7445;63
85;Vendée;7402;20
86;(none);(not in db);(unknown)
87;(none);(not in db);(unknown)
88;(none);(not in db);(unknown)
89;(none);(not in db);(unknown)
90;Territoire-de-Belfort;7410;102
91;Essonne;7401;56
92;Hauts-de-Seine;7449;36
93;Seine-Saint-Denis;7389;16
94;Val-de-Marne;7458;47
95;Val-d'Oise;7433;34
96;(none);(not in db);(unknown)
97;(none);(not in db);(unknown)
98;(none);(not in db);(unknown)
99;(none);(not in db);(unknown)
Total:6784

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org


ref;name;id relation;count
01;Ain;7387;22
02;Aisne;7411;114
03;Allier;7414;139
04;Alpes-de-Haute-Provence;7380;2
05;Hautes-Alpes;7436;21
06;Alpes-Maritimes;7385;21
07;ArdÚche;7430;124
08;(none);(not in db);(unknown)
09;AriÚge;7439;2
10;(none);(not in db);(unknown)
11;(none);(not in db);(unknown)
12;Aveyron;7451;159
13;Bouches-du-RhÃŽne;7393;101
14;Calvados;7453;119
15;Cantal;7381;22
16;Charente;7428;146
17;Charente-Maritime;7431;117
18;Cher;7456;15
19;CorrÚze;7464;94
20;(none);(not in db);(unknown)
21;CÃŽte-d'Or;7424;134
22;(none);(not in db);(unknown)
23;Creuse;7459;236
24;(none);(not in db);(unknown)
25;Doubs;7462;206
26;DrÃŽme;7434;302
27;Eure;7435;47
28;Eure-et-Loir;7374;24
29;FinistÚre;102430;8
30;Gard;7461;46
31;Haute-Garonne;7413;67
32;Gers;7422;399
33;Girond