Script de génération des données communes-com OSM

[jdesboeufs]

Actuellement la mise à jour des données issues d'OSM (communes-com) nécessite une intervention manuelle de @cquest. Il faudrait disposer du script pour assurer la pérennité de ce dépôt en l'absence de données officielles côté IGN sur ce volet.

Par exemple actuellement même si on corrige #18 ou #17 on ne pourra pas re-générer. Cela bloque le support de ces territoires dans la Base Adresse Nationale alors même qu'un décret va rendre la remontée des Bases Adresses Locales obligatoires.

Tu peux prendre @ThomasG77 ?

[ThomasG77]

En fait, j'ai déjà échangé avec Christian, c'est corrigé dans https://osm13.openstreetmap.fr/~cquest/openfla/export/communes-com-20220101-TEST-shp.zip Il me reste à relancer le script avec ce nouveau jeu de données pour avoir les 2 communes manquantes. On a bien maintenant Uvea (98613) et Gambier (98719)

Sur le court terme, cela règle le problème mais comme tu l'évoques, un script serait plus viable pour éviter cette dépendance par rapport à Christian. J'envisage de passer par une recette Overpass

[cquest]

Le script est là: https://osm13.openstreetmap.fr/~cquest/openfla/export/openfla_export.sh

Il s'appuie sur une base osm2pgsql monde qui est utilisée pour le rendu cequi est une dépendance lourde quand on n'a pas ça sous la main.

[jdesboeufs]

Il ne manque que Uvea pour Wallis-et-Futuna ? Il me semblait qu'il manquait tout. Dans la foulée peut-être gérer les TAAF aussi.

[ThomasG77]

En fait, c'était dans les contours COM OpenStreetMap qu'ils manquaient. Maintenant, c'est les règles de filtrage des communes que je dois bouger https://github.com/etalab/contours-administratifs/pull/20

Te tiens informé.D'autres trucs sur le feu

[ThomasG77]

Avancé sur le script alternatif en utilisant l'API Overpass (portage de la logique du script fourni par Christian)

Soit le fichier overpass_com.ql avec le contenu suivant

/*
This query looks for nodes, ways and relations 
with the given key.
Choose your region and hit the Run button above!
*/
[out:json][timeout:25];
// gather results
(
  // query part for: “"ref:INSEE"=*”
  node["ref:INSEE"]["admin_level"="8"](if: is_number(t["ref:INSEE"]) && number(t["ref:INSEE"])>=97700 );
  way["ref:INSEE"]["admin_level"="8"](if: is_number(t["ref:INSEE"]) && number(t["ref:INSEE"])>=97700 );
  relation["ref:INSEE"]["admin_level"="8"](if: is_number(t["ref:INSEE"]) && number(t["ref:INSEE"])>=97700 );
  node["ref:INSEE"]["ref:INSEE"~"^975"];
  way["ref:INSEE"]["ref:INSEE"~"^975"];
  relation["ref:INSEE"]["ref:INSEE"~"^975"];
);
// print results
out body;
>;
out skel qt;

Faire

query-overpass overpass_com.ql >| /tmp/com.geojson

Il reste encore des problèmes:

• des limites maritimes qui traînent en plus des limites terrestres comme sur Saint-Pierre-et-Miquelon
• en polynésie, on a souvent uniquement le contour maritime sans le contour terrestre. Cela diffère fortement d'un atoll à l'autre. Il faut corriger la donnée ou bien regrouper les "natural"="coastline" à l'intérieur de chaque boundary maritime puis fusionner pour avoir le contour terrestre de cas à problème.

[ThomasG77]

Résolu via #20 et #22