[OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

[Vincent de Chateau-Thierry]

Bonsoir,

Le 24/01/2012 18:05, verdy_p a écrit :

>>
>> Tentons de ne pas tout mélanger :
>> 1- Il y a le boulot pour les ordinateurs
>> 2- Et le boulot pour les humains
>>
>> Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui
>> n'est pas le cas, nous repenserons 2)
>
> Justement, le 1) est intenable, et produit dix mille fois trop d'erreurs.
> C'est un enfer à maintenir de façon cohérente et cela entraine une
> redondance énorme en nombre de membres à copier de relation en relation, et
> des requêtes géométriques très couteuses, là ou les requêtes relationnelles
> sont bien plus efficaces.

C'est bien facile d'affirmer avec autant d'assurance de telles 
assertions sans donner aucun exemple. Mais sans matière, tu ne fais rien 
avancer.

(...)
>
> Regarde l'exemple que j'ai fait sur Paris pour les arrondissements: aucune
> redondance, et une grande facilité de navigation et d'exploitation pour
> créer des cartes statistiques sans faire aucune requête spaciale (par
> exemple pour faire des agrégats statistiques de population, sans doubles
> comptes, et pourtant exhaustives).

Ce que tu appelles "aucune redondance" consiste a avoir _en double_ dans 
la même relation (http://www.openstreetmap.org/browse/relation/7444 ) 
tous les ways frontières entre arrondissements "extérieurs" et communes 
de la petite couronne : les ways sont directement dans la relation, et 
rajoutés comme membres des relations décrivant chacun de ces 
arrondissements extérieurs. Sans parler des ways frontières entre 
arrondissements, qui sont chacun présent 2 fois aussi au travers des 
relations. Aucune redondance...

(...)
>
> L'édition est aussi facilitée puisque les membres inclus sont bien plus
> localisés, on n'a plus à gérer des listes de centaines de membres difficiles
> à contrôler et trier pour vérifier qu'ils sont bien continus ou complets.
> L'éditeur n'a plus à charger et sauvegarder autant de données (des dizaines
> de milliers de noeuds dès qu'on modifie une limite en bordure de région,
> bien plus en core si on est en frontière de pays, car les différents types
> de frontières s'y superposent... Et on évite les erreurs constantes du
> serveur qui peine à afficher l'historique, et retourne souvent "data
> full"...
>
Je te suggère de commencer à éditer les relations admins en ne chargeant 
que les quelques ways qui te sont nécessaires, au cas par cas. J'ai 
toujours fait ça, que ce soit pour tracer une limite de commune, ou 
réparer une relation cassée, et ça se passe très bien. Et dans les cas 
où ça n'est pas possible, oui, il faut tout charger, mais ça doit rester 
l'exception. Charger un département, c'est quelques minutes de 
chargement, c'est largement supportable une fois de temps en temps. 
Charger, au delà, une région entière voire la France, je serais bien 
curieux d'en connaître la motivation pour de l'édition.

	/*********************************************/

Pour revenir au départ du sujet, on se trouve encore à l'heure qu'il est 
avec un contour d'Ille-et-Vilaine inutilisable. Sauf levée de boucliers 
(argumentée), je procéderai demain soir à son rétablissement sous forme 
d'une relation "classique", c'est à dire modélisée comme toutes les 
autres emprises administratives françaises, selon le schéma renseigné ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives
Idem pour les tentatives "subarea" de Paris et du Val-de-Marne : s'il 
s'agit de proposer un modèle par somme de surfaces, comme le disait 
Pieren, autant le faire complètement, et non en imbriquant ça dans un 
schéma par limites ("boundaries").

Quand on sera capable, au prix d'une discussion et d'un consensus, de 
trouver un autre modèle (à supposer que ce soit nécessaire), alors on 
pourra modifier les données. D'ici là, pour les tests en tous genres à 
base de relations imbriquées ou sommes de surfaces pour des entités 
Région, Département et au dessous, il est tout à fait possible de créer 
de toute pièce des relations avec un autre schéma de tags, qui servent 
de support à la discussion, et sans pour autant casser / squatter un 
existant qui fonctionne et qui sert aussi à des consommateurs de données 
OSM. C'est aussi valable pour les contours d'EPCI, sly :-).

Et merci d'avoir lu jusqu'ici,
vincent