Le 9 novembre 2012 23:54, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > Le vendredi 09 novembre 2012 22:22:13, Vincent de Chateau-Thierry a écrit : >> J'ai un bémol > > Je m'y attendais ;-) > Fais, les 2 se valent à l'heure actuelle à mon avis. > > J'ai choisi mon option pour 2 raisons : > > - Car sans utiliser cette méthode, on ne pousse pas les outils à l'évolution > et donc les contributeurs continuerons à entasser toujours plus des relations > les unes sur les autres. L'arrivée des cantons, des epci, des réserves > naturelles, des diocèses,... ajoutant encore à cette complexité. > (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient > de plus en plus une calamité)
Eh oui, toi aussi tu l'admets que détricoter un ensemble de relations qui n'ont QUE des définitions de frontières devient un enfer. Alors que les relations sont faites nativement pour supporter un modèles relationnel très facile à comprendre et faire sans erreurs. Ce qui faciltite énormément les reconstructions de frontières manquantes (ce qui arrivent en fait extrêmement rarement car l'inclusion des liens relationnels (parent/enfant) assure que les relations parentes seront bien toutes chargées dans tous les éditeurs avant même qu'on puisse modifier une relation enfant. Le modèle n'est pas compliqué, il marche très bien. Regarde la république thèque : il est parfait et complet. Regarde la Slovénie (même chose). Regarde l'Allemagne (pas complet mais ils ont compris l'intérêt et arrivent à gérer bien plus d'entités et de niveaux adminsitratifs que nous. Ils gèrent aussi les zones postales. Et aussi les différents statuts de villes (et les nombreux cas de niveaux administratifs fusionnés dans la même collectivité, ce qui commence à se développer aussi en France et va certainement s'accélérer). Regarde l'Espagne il est presque complet sauf pour les comarques dont il faut encore en ajouter pas mal, mais avec des exceptions à gérer sur des inclusions partielles de comarques à cheval sur plusieurs provinces (ce qui existe aussi en France pour les cantons qui ont de telles exceptions dans un certain nombre de communes découpées en plusieurs fractions dont certaines fractions recouvrent aussi des communes voisines : on est amené à définir, pour une représentation relationnelle un niveai intermétiaire formant une fraction administrative et non une entité administrative complète, avec un type différent de bounday=administrative pour cette fraction.. Cela pourrait aussi être fait pour les fractions cantonales en France. Egalement pour les EPCI pour définir des listes d'EPCI par département (donc avec des fractions d'EPCI. Egalement pour les zones judiciaires ou de police. Avec la réforme administrative en cours en Espagne, ils arrivent à suivre ! même auand chaque communauté autonome développe son propre découpage administratif indépendant du découpage national en provinces et communes (qui devient de moins en moins pertinent, les comarques n'avaient plus d'utilité dans l'ancien système adminsitratif espagnol, depuis les communautés les font revivre et leur donne une identité propre un peu à la façon de nos communautés de communes, quitte à les redécouper, comme si on passait de nos cantons actuels aux EPCI sans changer les noms en France). On a plein d'autres relations à mettre dans la base pour la France, mais là je trouve qu'on s'enlise en ne regardant pas ce qui marche bien mieux ailleurs (on n'arrive plus à suivre la plus petite évolution et on se bloque pour rien en n'osant pas ajouter d'autres données pourtant pertinentes en cartographie. Continuer sur une logique purement géométrique (que ce soit avec celle des ways polygones fermés uniquement ou avec des relations qui n'ont que des chemins membres) n'est plus viable du tout: il conduit à beaucoup trop d'erreurs et une complexité gigantesque pour réparer. Je milite donc pour des polygones représentés par des relations, avec SANS AUCUN chemin superposé (même partiellement) et aussi pour ajouter aux relations non seulement leurs limites externes avec des listes de chemins, complexes à éditer, mais aussi avec des membres relationnels qui aident à consolider le tout et sont très stables, et bien plus faciles à comprendre pour les contributeurs et à vérifier ensuite. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
