Relation de communes dans les relations départements

Bonjour,


J’ai consulter le wiki sur ce sujet et il ne semble pas avoir de consensus à ma connaissance sur l’ajout des relations définissant les communes dans les relations de niveau supérieur définissant les départements.

J’ai l’impression que ce n’est pas une chose à faire et en voulant contrôler les relations des communes de l’Aude et la présence de leur centre administratif, j’ai intégré au fil de mes validations chacune des communes de l’Aude existante dans la relation du département. Ceci afin d’éviter de contrôler deux fois la même commune.
Pour passer la validation JOSM, j’ai utiliser le rôle subarea pour les relations définissant les communes.

Cela m’a permis à partir de la relation “Département” de charger différente communes à travers le département sans charger toute la carte. Les communes étant la subdivision des départements en tant que collectivité territorial contrairement aux cantons et arrondissements qui sont des subdivision administrative, ça me semble logique mais il est probable que cette solution ai déjà été refusé par le passé. Avant de faire des bêtise j’aimerai en savoir plus. Aucune de mes modifications n’ont été envoyés sur le serveur.

Comme ça concerne des informations importante, voici mon fichier de travail : http://dl.free.fr/hvJ7sSjzi. Voici les modifications apportée :

  • Définition de rôle “outer” dans les relations de communes où cela manquait ;
  • Correction de deux frontières de communes dupliquée (strictement identique) ;
  • Correction de deux frontières de région dupliquée (strictement identique) ;
  • Séparation de deux routes superposé avec des frontière de commune (route décalé, frontière non modifiée) ;
  • Correction d’erreur de chemin/cours d’eau indiquées par JOSM ;
  • Correction d’erreur dans des relations indiquées par JOSM en dehors de l’Aude (vers Toulouse et Béziers).

Ce que je vois pour l’instant, c’est que mon JOSM a eu du mal à digérer le fichier et rame à chaque coup de molette pour (dé)zoomer… :-/

Peut-être là un argument en défaveur des subareas ?

Francescu

Le résumé du débat est ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modèle_somme_de_surface_ou_modèle_frontière

Il n’est pas clos, mais pour l’instant en tout cas, la non utilisation des role subarea pour inclure les relations des communes semble avoir le dessus.

Il existera cependant d’autres solutions, peut-être plus adaptées, selon ce que veux précisément faire.
Vérifier si les communes sont bien là, et valides ? : http://suivi.openstreetmap.fr/communes/communes.csv.txt
Voir graphiquement s’il n’y a pas des trous ? http://layers.openstreetmap.fr/?zoom=10&lat=43.06689&lon=2.58357&layers=B0000FFFFFFFFFFTFTFFFFFFF
Contrôler d’autres types d’erreurs ? http://osmose.openstreetmap.fr

Télécharger toutes les frontières de communes du département afin de le ré-utiliser dans un autre projet ? http://export.openstreetmap.fr/contours-administratifs/export-communes/incomplet/


ps pour windu: si ça rame, je ne pense pas que le rôle subarea change grand chose, mais ça vient juste que toutes les communes d’un département, affichées dans JOSM feront de toute façon ramer l’ordinateur.

@sly : je me doute bien que c’est le grand nombre de relations à afficher qui fait tout ramer. Et justement, quelle est la proportion de cas où un utilisateur peut avoir besoin de récupérer un département et toutes ses communes ? Suffisamment faible, selon moi, pour que si cela vient à se généraliser, cela ne se fasse pas sur les relations actuelles des départements (ni des régions, ni…), mais dans une relation “à coté”.

la reponse de Pieren sur la liste :

Si, il y a un consensus (moins une personne) pour ne pas mélanger les
torchons et les serviettes. Ceux qui veulent s’amuser à regrouper les
communes d’un département avec un role “subarea” peuvent le faire mais
pas dans la même relation qui définit les limites administratives du
département.

Visible aussi ici : http://gis.19327.n5.nabble.com/forum-osm-fr-Relation-de-communes-dans-les-relations-departements-tp5745797.html

:wink:

J’ai peut-être mal compris, ok, c’est bien le nombre qui fait ramer, mais c’est le nombre qui se trouve dans son fichier qui fait ramer. Ça n’implique pas forcément qu’en travaillant avec ça directement depuis la base officiel on soit obligé de tout télécharger.


Et justement, quelle est la proportion de cas où un utilisateur peut avoir besoin de récupérer un département et toutes ses communes ? Suffisamment faible, selon moi, pour que si cela vient à se généraliser, cela ne se fasse pas sur les relations actuelles des départements (ni des régions, ni…), mais dans une relation “à coté”.

Le fait que les communes soient insérées en role “subarea” dans les départements, n’impliquera pas automatiquement qu’elles seront téléchargées. Au final, ramera donc qui voudra, mais ça ne sera pas “automatiquement le cas” pour tous. Cf par exemple en espagne où c’est fait comme ça et, moins le téléchargement “en rab” des relations (sans leurs membres) des relations du niveau d’en dessous lorsque l’on clic dans JOSM “télécharger les membres” ça n’est pas forcément l’horreur

Pour info, pour charger toutes les relations des communes d’un département d’un coup, il y a un lien pour ça en bas des pages “état du découpage administratif” par département.

Exemple: http://openstreetmap.fr/outils/etat-du-decoupage-administratif?l=8&r=94

“Charger toutes les relations”… et une petite icône JOSM sur laquelle cliquer.

Sinon, overpass !

Oui c’est cela l’idée.

Je n’ai pas pris en compte tous les besoins (je commence à découvrir les anciennes discutions sur le sujet) mais mon idée principale (et personnelle) était :
1 - Appliquer la logique de subdivision de collectivité territoriale ;
2 - Avoir la possibilité de charger les communes d’un département depuis la relation parent, que ce soit sélectivement ou pas.

Le besoin de charger les communes n’est pas courant et en cas de commune non tracé dans un département l’utilisation de relation définie par des aire n’est pas applicable. C’est pour cela que je trouve l’idée bancale.

Concernant les ralentissements, cela est du au nombre important de segment. J’ai deux machines et sur l’ancienne je n’aurai pas réussi à faire ce travail correctement. La relation sans les segments ne provoque pas de ralentissement. Tout dépend du volume de donnée à traiter sur l’écran par JOSM.

Je pourrait résumé ce que j’ai retenu dans les archives de la liste :

  • L’utilisation d’aire pour définir la relation parent est valable uniquement si tous les éléments enfants existe (il manque encore beaucoup de commune) ;
  • Utiliser des bordures et des aires dans la même relation fait double emploi ;
  • Pour des besoins d’édition il est possible de créer des relations “aire” contenant les éléments souhaité et surtout ne pas polluer les relations existante (penser à les supprimer quand on en plus besoin serait un plus) ;

Sachant que c’était pour un besoin d’édition et de contrôle je vais corriger la relation décrivant le département en supprimant les éléments ayant le rôle subarea

:smiley: Tu me trous le ***

A chaque fois tu a déjà conçu les outils dont j’ai besoin. Cela me dispense de créer une relation temporaire contenant les communes du département. Pour l’instant j’ai toujours réussi à éviter ce genre de création et j’espère ne jamais être forcé à le faire.

Dès qu’on veut charger un sous ensemble des données sur certains critères, il faut faire appel d’un façon ou d’une autre à la base de données. L’overpass est un des moyens les plus simples…

Lecture du soir: http://wiki.openstreetmap.org/wiki/Overpass_API

Serveur overpass “France” (métropole): http://oapi-fr.openstreetmap.fr/

OverpassAPI et XAPI sont vraiment des outils à étudier Percherie, c’est tellement pratique :wink:

Cquest, on peut faire le ménage avec la colonne odbl.

J’ai tenté quelques fois de m’y mettre de façon pas très sérieuse. Le contenu en anglais passé au traducteur automatique est lisible, je vais devoir m’y mettre plus sérieusement :sunglasses:

Je viens de faire quelques essais qui semble fonctionner (pas facile tout est en anglais) mais je n’arrive pas à envoyer les données vers un fichier pour les importer dans JOSM.

Voici ma requête placé dans http://overpass-api.de/query_form.html :

(
way
    ["landuse"="vineyard"]
    (42.80,2.38,43.25,3.20);
>;
);
out;

J’arrive à voir le résulta en choisissant l’option “to OpenLayers auto-centered overlay” mais je n’arrive pas à faire plus pour exploiter les données.

(
way
[“landuse”=“vineyard”]
(42.80,2.38,43.25,3.20);

;
);
out;


Ca peut se traduire en XAPI:

http://oapi-fr.openstreetmap.fr/xapi/xapi?way[landuse=vineyard][bbox=42.80,2.38,43.25,3.20][@meta]

Dans JOSM, dans le menu fichier, choisir “Ouvrir un emplacement” et y coller cette URL…

Merci, quand j’ai vu @meta dans l’adresse que tu a indiqué j’ai trouvé ce qui manquait à ce que j’avais pour avoir un fichier compatible pour JOSM comportant les versions des éléments en ajoutant “meta” à “out”:

(
way
["landuse"="vineyard"]
(42.80,2.38,43.25,3.20);
>;
);
out meta;

Est ce que c’est une bonne solution de passer par le formulaire que j’ai indiqué ? C’est pour conserver une copie du fichier pour éviter de le télécharger plusieurs fois dans la même journée.

C’est à toi de voir. J’ai plus l’habitude de saisir les requêtes directement dans ‘Ouvrir un emplacement’ dans JOSM (qui garde les dernières URL utilisées).