[OSM-dev-fr] Simplifier nos limites admin...

Dim 15 Déc 14:07:18 UTC 2013

Bon... ça avance... j'ai maintenant l'intégralité des limites.
Le principe est le suivant:
- extraction des limites entre 2 communes (ST_Touches + ST_Intersection)
- extraction des limites côtières et frontalières
- extraction des communes non limitrophes (les iles)
- première génération de polygones non simplifiés pour chaque commune
- extraction des limites restantes par différence avec le polygone
d'origine (cas des communes côtières qui comportent une enclave, il y en a
2 en Corse)

Il y a sûrement moyen d'être plus efficace, mais au moins le résultat est
correct et ne loupe rien !

Je m'attaque au processus de simplification.

Comme indiqué plus haut, celui-ci fonctionne bien dans la très grande
majorité des cas, mais sur certaines communes aux contours tarabiscotés, le
fait de simplifier les limites une à une peut faire qu'elles se croisent.

Quelques exemples:
- Ferney-Voltaire: http://www.openstreetmap.org/relation/140088
- Aren: http://www.openstreetmap.org/relation/2809778

Je compte donc faire ça avec la méthode suivante:
- générer les polygones simplifiés (ST_BuildArea)
- rechercher ceux manquants ou invalides + diminuer le niveau de
simplification des limites de ces communes et boucler tant que ça coince.

J'ai constaté que l'IGN avait sûrement une approche similaire car sur le
cas de Mont-Dauphin, le polygone de l'enclave est nettement moins simplifié
que d'habitude.

Au final ce processus sera documenté et reproductible, y compris pour autre
chose que des polygones de communes et pour "tailler à la serpe" on pourra
choisir les dimensions de celle-ci.

Mon bloc note de requêtes SQL est là :
https://gist.github.com/cquest/66797473e5663bb4ba43

J'en suis à la "génération finale des polygones" où je bute pour l'instant
sur des problèmes de topologie.

Le 13 décembre 2013 22:57, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> En fait je voulais résoudre 2 problème en même temps.
>
> Le premier: le rendu des limites admin ne me plait pas.
> En effet, le rendu se base sur les polygones et pas sur les ways qui les
> constituent. Du coup, pour chaque limite, on a en général 2 tracé, voir 4,
> 6 ou 8 pour les limites de département, région, pays.
> Ca donne un truc baveux avec des pointillés qui bien sûr ne peuvent
> quasiment jamais coincider.
> Donc avec les linestring qui constituent les limites permettrait une
> réelle amélioration du rendu sur ce plan.
>
> Regénérer ces frontières permet aussi de proposer un jeu de données des
> frontières (comme dans GEOFLA d'ailleurs qui a un shapefile des polygones
> et un autre des linestring) où pour chacune on peut indiquer ce qui se
> trouve de part et d'autre pour les différents niveaux de découpage, donc
> représenter plus facilement différents niveaux de frontières.
> Ces frontières je ne suis pas obligé de les simplifier.
>
> Deuxième problème: besoin de tracés simplifiés pour les petites et
> moyennes échelles
> Encore un problème pour le rendu où on se rapproche du besoin d'un
> équivalent du GEOFLA, mais où l'on peut aussi plus ou moins simplifier les
> limites selon l'échelle souhaitée et en ne perdant pas au passage par
> exemple bon nombre d'iles (GEOFLA en zappe la majorité).
>
> Ces deux problèmes étant liés, je tente de faire d'une pierre deux coups
> et mis à part quelques bugs tordus de topologie par endroit, le résultat
> est très correct.
>
>
>
>
> Le 13 décembre 2013 21:35, Vincent de Château-Thierry <vdct at laposte.net>a écrit :
>
>
>>
>> Le 13/12/2013 20:09, Arnaud Vandecasteele a écrit :
>>
>>  Salut Christian,
>>>
>>> Je prends la discussion en cours de route donc excuse moi par avance si
>>> la question t'a déjà été posée.
>>> Mais as-tu pensé à avoir recours à la topologie ?
>>> Ex ->
>>> http://blog.mathieu-leplatre.info/use-postgis-topologies-
>>> to-clean-up-road-networks.html
>>>
>>> A.
>>>
>>> On 13-12-13 03:27 PM, Christian Quest wrote:
>>>
>>>> Bon, je progresse...
>>>>
>>>> Si vous voulez voir la tête des requêtes c'est par ici (WARNING, ça
>>>> peut piquer les yeux):
>>>> https://gist.github.com/cquest/66797473e5663bb4ba43
>>>>
>>>> Et graphiquement au final ça peut donner ça:
>>>> http://cl.ly/image/2e2Y0l0K1Q0O :)
>>>>
>>>> mais aussi ça: http://cl.ly/image/3g2B2O2w3x2O :(
>>>>
>>>
>> Pas gagné en effet. À la réflexion, qu'est ce qu'on attend d'un tel jeu
>> de données ? Vu que le niveau de détail géométrique approche celui du
>> GeoFLA, le principal avantage serait d'être un découpage à jour en termes
>> de références INSEE et de fusions de communes.
>> Du coup on pourrait imaginer un jeu hybride, qui prend la géométrie du
>> GeoFLA (ou du Route 500, selon le niveau de simplification qu'on veut
>> atteindre), qui en enlève toutes les portions pas à jour, et qui les
>> remplace par celles issues d'OSM et simplifiées géométriquement, avec les
>> "bons" attributs. Au final, en delta par rapport à un millésime GeoFLA, il
>> faudrait à la louche s'attendre à une cinquantaine de remplacements issus
>> d'OSM (changement de noms, nouveaux codes INSEE, fusions et split de
>> communes). Ça permettrait, pour les traitements géométriques, de ne pas
>> avoir à tout gérer (cf ton cas tordu sur la 2e copie d'écran) mais de
>> focaliser sur un delta.
>>
>> Pour la topologie, ici ça ne résoudra rien. En revanche ça permettra de
>> détecter les régressions entre source et résultat. En gros, si on a inventé
>> ou perdu un voisinage entre 2 communes, c'est via un contrôle sur les
>> relations topologiques qu'on pourra le détecter.
>>
>> vincent
>>
>>
>> ---
>> Ce courrier électronique ne contient aucun virus ou logiciel malveillant
>> parce que la protection avast! Antivirus est active.
>> http://www.avast.com
>>
>>
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20131215/c2633c28/attachment.html>