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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
