Re: [OSM-dev-fr] Simplifier nos limites admin...
Le 18 décembre 2013 00:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il va falloir trouver une astuce... j'ai testé département par département et là c'est jouable. ... sauf si les limites côtières entre deux départements traversent justement par un estuaire (ex. 35 et 44), mais ça dépend jusqu'où on fait remonter l'estuaire maritime pour les limites des communes littorales. En revanche pour les limites de régions et départements (i.e. les limites préfectorales, pas celles des collectivités locales de la région et du département, qui n'ont pas compétence du domaine maritime et même pas la compétence totale sur le littoral terrestre protégé) et les limites nationales, on n'a pas de mal à définir leur domaine maritime en utilisant les limites dans les eaux territoriales. C'est bien pour ça qu'on devrait supporter en France aussi ce que font les Allemands depuis longtemps (et d'autres pays aussi) : les land_areas définis sur les lignes de côtes et non les limites des eaux territoriales nationales. Peut-être que ces land_areas ne sont pas documentés sur le wiki en anglais mais ça l'est parfaitement en allemand et il y a assez d'explication et de notes d'alertes dans les données OSM pour expliquer la différence avec les boundary=*, et ils en ont aussi discuté depuis longtemps de la nécessité d'avoir ces land_areas (qui ne sont pas seulement un besoin administratif, mais aussi un clair besoin au plan géographique/cartographique, même si en théorie on nos lignes de côtes devraient être celles de la ligne de base légale, qui traverse aussi les estuaires et inclut les ports presque fermés par une digue de protection et toute zone d'eau de moins de 50 mètres de large environ, soit l'ordre de grandeur des marées le long des plages atlantiques et de la Manche ou la Mer du Nord, cette distance étant plus réduite en Méditerranée, mais variant dans les estuaires selon les régimes des fleuves pour ce qui concerne les limites des estuaires).. Mais c'est vrai qu'un land_area pour la France demanderait un multipolygone très complexe avec de nombreux membres, tellement nos cotes sont découpées (surtout en Bretagne). Actuellement on ne sait toujours pas si en France les limites de nos régions doivent être celles des collectivités territoriales (excluant les eaux territoriales), ce qui semble être le cas, ou les limites (sous-)préfectorales (en fait de la compétence exclusive de l'Etat, lequel inclut le domaine maritime). Selon les cas on aurait besoin d'avoir les deux aussi en France, les limites administratives (de l'Etat) incluant les eaux territoriales, et une autre relation pour les land_areas (dans la compétence réelle des régions, départements et communes en tant que collectivités locales mais qui ne sont pas réellement un découpage complet du pays). ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Le 15 décembre 2013 15:07, Christian Quest cqu...@openstreetmap.fr a écrit : 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 J'ai des doutes sur Ferney-Voltaire. La route douanière ne me semble pas faire partie de la commune, ni même du territoire français, même si l'usage est réservé à la France. En tout cas, le cadastre ne contient pas cette route. On a le même schéma au niveau de l'aéroport de Mulhouse-Bâle, avec une route douanière permettant aux Suisses de rejoindre l'aéroport. Mais on n'a pas étiré la frontière le long de cette route. Si j'en crois la convention franco-suisse, cette route fait toujours partie du territoire suisse : http://www.admin.ch/opc/fr/classified-compilation/19560067/index.html Voir l'article 13: La route sera séparée par une clôture du reste des territoires suisse et français, mais la portion de route située en territoire suisse restera partie intégrante de ce territoire. On devrait donc pouvoir supprimer cette excroissance de Ferney-Voltaire. Matthias ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
2013/12/16 Matthias Dietrich eiger@gmail.com: J'ai des doutes sur Ferney-Voltaire. La route douanière ne me semble pas faire partie de la commune, ni même du territoire français, même si l'usage est réservé à la France. En tout cas, le cadastre ne contient pas cette route. On a le même schéma au niveau de l'aéroport de Mulhouse-Bâle, avec une route douanière permettant aux Suisses de rejoindre l'aéroport. Mais on n'a pas étiré la frontière le long de cette route. Je confirme pour les deux cas (Genève dans un sens et Bâle-Mulhouse dans l'autre). Ces routes sont cloturées jusqu'à l'accès des aéroports. C'est des territoires avec un statut juridique batard puisque le poste de douane est décalé et que le droit du pays frontalier s'y applique (aussi) mais ils ont conserver leur souverainté nationale. Celui-ci et d'autres sont listés sur wikipedia: http://fr.wikipedia.org/wiki/Particularit%C3%A9s_territoriales_de_la_France#Droits_fran.C3.A7ais_.C3.A0_l.27.C3.A9tranger Pieren ___ 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 cqu...@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 v...@laposte.neta é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
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 bruno.cort...@laposte.net 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...
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 osgeo.mailingl...@gmail.com 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...
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...
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) lis...@letuffe.org 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...
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 :( -- 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 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 :( -- 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 -- Arnaud Vandecasteele SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://geotribu.net/ ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
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 v...@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@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
[OSM-dev-fr] Simplifier nos limites admin...
Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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...
Je ne comprends pas le code cité, mais les communes limitrophes de bordure de département ont des boundaries avec admin_level=6. ( (région, 4), respectivement). Serait-ce une piste ? Art. Le 11 déc. 2013 16:59, Christian Quest cqu...@openstreetmap.fr a écrit : Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Je m'appuie uniquement sur les polygones de communes, pas sur les way d'origine qui peuvent avoir de tout comme tag admin_level (y compris aucun). Le 11 décembre 2013 17:04, Art Penteur art.pent...@gmail.com a écrit : Je ne comprends pas le code cité, mais les communes limitrophes de bordure de département ont des boundaries avec admin_level=6. ( (région, 4), respectivement). Serait-ce une piste ? Art. Le 11 déc. 2013 16:59, Christian Quest cqu...@openstreetmap.fr a écrit : Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ 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...
J'me disait bien que c'était trop bête pour être ça. Art. Le 11 déc. 2013 17:07, Christian Quest cqu...@openstreetmap.fr a écrit : Je m'appuie uniquement sur les polygones de communes, pas sur les way d'origine qui peuvent avoir de tout comme tag admin_level (y compris aucun). Le 11 décembre 2013 17:04, Art Penteur art.pent...@gmail.com a écrit : Je ne comprends pas le code cité, mais les communes limitrophes de bordure de département ont des boundaries avec admin_level=6. ( (région, 4), respectivement). Serait-ce une piste ? Art. Le 11 déc. 2013 16:59, Christian Quest cqu...@openstreetmap.fr a écrit : Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ 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 ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
De : Art Penteur Le 11 déc. 2013 17:07, Christian Quest a écrit : Le 11 décembre 2013 17:04, Art Penteur a écrit : Le 11 déc. 2013 16:59, Christian Quest a écrit : Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; Je n'arrive pas à voir quelle est l'unité du 2e paramètre de ST_Simplify(), la tolérance. Rien vu dans la doc PostGIS. As-tu les mêmes manques quand tu la passes à 0.0001 (soyons fous) ? Sinon une question : ça marche comment, cette syntaxe !bbox! ? (jamais utilisé). vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
En plus lisible : SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; Quand tu dis qu'il y a des manque, c'est que le compte n'y est pas ? Je suis pas expert, mais je me demande si tu n'exclues pas les limites qui ne se touchent pas avec le 'ON (st_touches(p.way,p2.way)'. Ca donne quoi si tu recherches au contraire les communes qui sont isolées ? Yves On 12/11/2013 04:58 PM, Christian Quest wrote: Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name http://p.name ,' - ', p2.name http://p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
Je en comprends pas tout à ce que fait cette requête, mais pourquoi tu as p2.osm_id ** p.osm_id dans ta clause ON ? Ca ne devrait pas être p2.osm_id *=* p.osm_id, plutôt ? Francescu Le 11 décembre 2013 16:58, Christian Quest cqu...@openstreetmap.fr a écrit : Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
!bbox! c'est pour TileMill (mapnik) car je l'utilise pour visualiser le résultat. La tolérance correspond au nombre de points intermédiaires pour définir un quart de cercle. Donc avec 1 ça te simplifie un cercle en 8 points. Ca ne joue que sur la simplification et pour être sûr je l'ai passé à 0.0001 et ça ne change rien. Voici un exemple de manques: http://cl.ly/image/2q2s2V0f1g1S Désolé pour la requête compacte, merci yves ! Pour le p2.osm_id p.osmid, c'est pour ne sortir une frontière entre 2 communes qu'une fois et pas deux. Si c'était un = ça me sortirait les limites d'une commune avec elle même ;) 2013/12/11 V de Chateau-Thierry v...@laposte.net De : Art Penteur Le 11 déc. 2013 17:07, Christian Quest a écrit : Le 11 décembre 2013 17:04, Art Penteur a écrit : Le 11 déc. 2013 16:59, Christian Quest a écrit : Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; Je n'arrive pas à voir quelle est l'unité du 2e paramètre de ST_Simplify(), la tolérance. Rien vu dans la doc PostGIS. As-tu les mêmes manques quand tu la passes à 0.0001 (soyons fous) ? Sinon une question : ça marche comment, cette syntaxe !bbox! ? (jamais utilisé). vincent ___ 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...
De : Christian Quest !bbox! c'est pour TileMill (mapnik) car je l'utilise pour visualiser le résultat. Ah oui, le truc qui remplace QGis ;-) La tolérance correspond au nombre de points intermédiaires pour définir un quart de cercle. Donc avec 1 ça te simplifie un cercle en 8 points. Ca ne joue que sur la simplification et pour être sûr je l'ai passé à 0.0001 et ça ne change rien. Voici un exemple de manques: http://cl.ly/image/2q2s2V0f1g1S Alors là... pas la moindre idée :-( vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Simplifier nos limites admin...
En remplaçant le ST_Touches par un simple j'ai ça: http://cl.ly/image/1O3r3Z0y2K1l Très bizarre... J'ai donc regardé ce que me sortait mon ST_Intersection des polygones des communes 14053 et 14206. J'ai une GEOMETRYCOLLECTION avec plein de LINESTRING et deux POLYGON... alors qu'en chargeant les relations dans JOSM, j'ai un seul way qui définit la frontière... bizarre... Dans JOSM j'ai donc fait une modif neutre sur les relations (changement de l'ordre des membres)... histoire qu'elle soit remise à jour par osm2pgsql à l'intégration des prochains diffs et là... j'ai maintenant un MULTILINESTRING Aïe... ça veut dire que la base osm2pgsql d'osm13 est un peu désynchronisée. Je vais tenter d'y forcer le recalcul des limites admin à grand coup de pending... Le 11 décembre 2013 17:48, V de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest !bbox! c'est pour TileMill (mapnik) car je l'utilise pour visualiser le résultat. Ah oui, le truc qui remplace QGis ;-) La tolérance correspond au nombre de points intermédiaires pour définir un quart de cercle. Donc avec 1 ça te simplifie un cercle en 8 points. Ca ne joue que sur la simplification et pour être sûr je l'ai passé à 0.0001 et ça ne change rien. Voici un exemple de manques: http://cl.ly/image/2q2s2V0f1g1S Alors là... pas la moindre idée :-( vincent ___ 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...
Et voilà: UPDATE planet_osm_rels SET pending=true FROM planet_osm_polygon where id=-osm_id and ref:INSEE is not null; 41936 polygones seront recalculés au prochain update... donc d'ici quelques minutes :) Le 11 décembre 2013 18:19, Christian Quest cqu...@openstreetmap.fr a écrit : En remplaçant le ST_Touches par un simple j'ai ça: http://cl.ly/image/1O3r3Z0y2K1l Très bizarre... J'ai donc regardé ce que me sortait mon ST_Intersection des polygones des communes 14053 et 14206. J'ai une GEOMETRYCOLLECTION avec plein de LINESTRING et deux POLYGON... alors qu'en chargeant les relations dans JOSM, j'ai un seul way qui définit la frontière... bizarre... Dans JOSM j'ai donc fait une modif neutre sur les relations (changement de l'ordre des membres)... histoire qu'elle soit remise à jour par osm2pgsql à l'intégration des prochains diffs et là... j'ai maintenant un MULTILINESTRING Aïe... ça veut dire que la base osm2pgsql d'osm13 est un peu désynchronisée. Je vais tenter d'y forcer le recalcul des limites admin à grand coup de pending... Le 11 décembre 2013 17:48, V de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest !bbox! c'est pour TileMill (mapnik) car je l'utilise pour visualiser le résultat. Ah oui, le truc qui remplace QGis ;-) La tolérance correspond au nombre de points intermédiaires pour définir un quart de cercle. Donc avec 1 ça te simplifie un cercle en 8 points. Ca ne joue que sur la simplification et pour être sûr je l'ai passé à 0.0001 et ça ne change rien. Voici un exemple de manques: http://cl.ly/image/2q2s2V0f1g1S Alors là... pas la moindre idée :-( vincent ___ 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/ -- 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
