Re: [OSM-dev-fr] Simplifier nos limites admin...
C'est pour ça que j'ai regardé le cadastre avant de corriger... mais le manque dans l'algo est bien là. Le 15 décembre 2013 21:36, sly (sylvain letuffe) a écrit : > Le dimanche 15 décembre 2013 21:03:56, Christian Quest a écrit : > > La seule chose absolument pas gérées ce sont des polygones en 8. > > J'en ai identifié 2 et en reprenant le cadastre, le 8 n'avait pas lieu > > d'être. > > Attention à ne pas céder à la tentation du "je corrige les données pour > compenser un manque dans mon algo ;-)" > > Le multipolygon en 8 est valide au sens OGC (j'avais écrits ce > récapitulatif > avec exemple des cas courant : > http://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity ) > > Il y a cependant plus de chance que ça soit une erreur de saisie que de la > vrai donnée en "8" > > > -- > sly (sylvain letuffe) > http://wiki.openstreetmap.org/wiki/User:Sletuffe > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Le dimanche 15 décembre 2013 21:03:56, Christian Quest a écrit : > La seule chose absolument pas gérées ce sont des polygones en 8. > J'en ai identifié 2 et en reprenant le cadastre, le 8 n'avait pas lieu > d'être. Attention à ne pas céder à la tentation du "je corrige les données pour compenser un manque dans mon algo ;-)" Le multipolygon en 8 est valide au sens OGC (j'avais écrits ce récapitulatif avec exemple des cas courant : http://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity ) Il y a cependant plus de chance que ça soit une erreur de saisie que de la vrai donnée en "8" -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Si quelqu'un veux essayer mapshaper, j'aimerai bien voir ce que ça donne sur 36680 polygones et 9.5 million de nœuds... Objectif (quasi) atteint de mon côté; j'ai 2 niveaux de simplification (100 et 250) qui sont ok et un autre avec encore un petit bug (simplification la plus légère à 10). J'ai encore découvert des trucs pas clairs dans les data au passage que j'ai dû corriger (Ile de Porquerolles) car j'avais forcément des problèmes de topologie incorrecte partant de données à la topologie incorrecte ! Cet exercice a donc permis de corriger quelques erreurs ici ou là. La seule chose absolument pas gérées ce sont des polygones en 8. J'en ai identifié 2 et en reprenant le cadastre, le 8 n'avait pas lieu d'être. Il faut que je blinde la série de requêtes SQL pour mettre ça dans une transaction car je m'appuie sur le schéma osm2pgsql d'osm13 qui est en mise à jour permanente. Au final, ça prends environ 15mn de calcul pour générer 2 niveaux de simplification en conservant en plus les limites séparées et en refabricant les polygones complets. Le résultat en shapefile est là: http://osm13.openstreetmap.fr/~cquest/openfla/export/communes-fla100-shp.zip(20Mo) http://osm13.openstreetmap.fr/~cquest/openfla/export/communes-fla250-shp.zip(10Mo) Après un rapide contrôle visuel, il manque... Marseille (un problème lié aux arrondissements et/ou aux iles ?) ainsi qu'une commune en Alsace... N'hésitez pas à regarder ces premiers shapefile et à me signaler tout incohérence. Le 15 décembre 2013 20:02, Thomas Gratier a écrit : > Salut, > > En complément, je pensais plutôt que si on avait des limites > topologiquement justes, on pourrait passer par MapShaper > http://www.mapshaper.org (c'est l'interface en ligne mais on peut aussi > faire de la ligne de commande https://github.com/mbloch/mapshaper) > L'outil corrige aussi les limites qui se recouvrent. > Côté SQL, j'avais vu en stock > http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyWithTopologyExt > > Mes 2 cents > @+ > > Thomas > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Salut, En complément, je pensais plutôt que si on avait des limites topologiquement justes, on pourrait passer par MapShaper http://www.mapshaper.org (c'est l'interface en ligne mais on peut aussi faire de la ligne de commande https://github.com/mbloch/mapshaper) L'outil corrige aussi les limites qui se recouvrent. Côté SQL, j'avais vu en stock http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyWithTopologyExt Mes 2 cents @+ Thomas Le 15 décembre 2013 15:23, Bruno Cortial a écrit : > Bonjour, > > Je serai loin du SQL de Christian. > Pour produire des cartes en lignes avec d3.js j'ai regardé le format > topojson, qui est une évolution du geojson prenant en compte le partage de > géométries. Ce principe fait déjà gagner énormément en volume de données > sur les polygones adjacents. > Il se trouve l'outil de conversion gère en plus 2 paramètres de > simplification (simplify et quantize), tout en respectant la topo bien sur. > > https://github.com/mbostock/topojson > > C'est une solution clé en main, quitte à revenir ensuite sur des formats > moins geek, shape et geojson. > A+ > Bruno > > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr > > ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Bonjour, Je serai loin du SQL de Christian. Pour produire des cartes en lignes avec d3.js j'ai regardé le format topojson, qui est une évolution du geojson prenant en compte le partage de géométries. Ce principe fait déjà gagner énormément en volume de données sur les polygones adjacents. Il se trouve l'outil de conversion gère en plus 2 paramètres de simplification (simplify et quantize), tout en respectant la topo bien sur. https://github.com/mbostock/topojson C'est une solution clé en main, quitte à revenir ensuite sur des formats moins geek, shape et geojson. A+ Bruno ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
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 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 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
Re: [OSM-dev-fr] [OSM-talk-fr] Convertir les données de type polygones en noeud (gpx, csv, osm) ( était : umap problème de =?iso-8859-1?q?_requ=EAte?=)
Le samedi 14 décembre 2013 22:50:41, Vincent Pottier a écrit : > Ça peut se faire ? ça peut, et je m'ennuyais ce matin, alors c'est fait ;-) Le wrapper cité ici supporte également la syntaxe overpass API http://wiki.openstreetmap.org/wiki/Servers/api.openstreetmap.fr#Simplified_exports_where_ways.2Fnodes_are_simplified_to_GPX_or_OSM_waypoint.2Fnode_.28test.29 (je note d'ailleurs que pour pas bien plus cher, on pourrait même avoir la sortie au format csv dont parlait un autre fil de discussion) -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
