Extrait la liste des départements, c'est rapide pour chaque département cela te fournira tous les noeuds nécessaires pour les relations plus grandes (régions et pays) étant donné que les ways utilisés pour la France entière sont partagés (enfin presque partout : il y a quelques ways différents dans les estuaires, qui ne poursuivent pas nécessairement les lignes de côtes aussi loin dans les terres, et il ne te rester alors que ces ways assez courts à charger pour compléter la géométrie des relations plus grandes).
En général quand je n'arrive pas à charger une relation trop grande, je procède ainsi : je charge les sous-zones pour et je complète ce qui manque pour fermer complètement la relation plus grande incomplète. C'est aussi la raison pour laquelle j'avais milité pour qu'on inclue les "subareas" (comme le font tous les autres pays... sauf la France) : cela donne un accès facile permettant de charger toutes les sous-zones nécessaires séparément. Ça accélère énormément les interrogations de la base et limite fortement les volumes de données nécessaires à lui demander en une seule fois, et cela permet aussi des contrôles de cohérence de la couverture (même si ces couvertures ne sont pas nécessairement exactement une partition exacte de la zone plus grande, car des recouvrements partiels ou des trous peuvent subsister et être justifiés localement). Et ce n'est pas non plus "redondant" comme l'affirment certains (je pense sincèrement qu'ils ont tord, la situation est plus compliquée qu'il n'y parait puisque les territoires ne sont pas parfaitement partitionnés... même en France, ou même seulement en France métropolitaine ou même sueulement dans sa partie dite "continentale" qui inclut pourtant encore de nombreuses îles côtières, selon la définition qu'on perçoit des "eaux intérieures"). Les cas pratiques d'utilisation des cartes devraient ne pas s'appuyer sur une pure définition géométrique, qui demande trop de travail et que le serveur ne peut pas supporter correctement ou efficacement. Une définition 'relationnelle" des sous-zones (que certains décrivent à tord comme une définition par surface alors que ce n'est pas le cas, la géométrie n'entrant pas en ligne de compte dans les "subareas") évite aussi des tas de problèmes liés à la stabilité des données: les subareas sont beaucoup plus stables et plus faciles à contrôler que des pures définitions de frontières trop facilement cassées dans des zones très locales sans pour autant que soit remis en cause l'existence des relations correspondantes. Avec les subareas, il est TRES facile de restaurer les trous créés par erreur par certaines modifications locales. ces données permettent aussi de télécharger en même temps les dépendances de certains ways utilisés par des relations de zones voisines: ces relations sont déjà chargées en même temps, il n'y a plus (par exemple dans JOSM) qu'à cliquer "télécharger les membres incomplets", et on voit immédiatement les noms des relations voisines partageant une frontière sans avoir même à les chercher, même si un morceau de frontière ne fait pas partie du rectangle dont on a chargé toutes les données. Cette inclusion permet donc aussi d'éviter de casser des frontières existantes puisque les modifications locale se feront aussi dans les relations voisines qu'on n'avait pourtant pas spécifiquement chargées. Je vous amène à reconsidérer le cas totalement isolationliste de la France, où vous vous refusez à utiliser cette solution adoptée PARTOUT ailleurs et qui facilite énormément le travail et renforce l'intégrité de la base tout en facilitant à la fois le travail de modification et l'utilisation des cartes pour des applications cartographiques tierces. Cela ne demande pas beaucoup de données supplémentaires (**beaucoup** moins que les ways présents dans les relations et **énormément** moins que les noeuds correspondants à ces ways). Cela ne change strictement rien au rendu des surfaces qui continue à s'appuyer sur les ways : c'est un outil d'analyse et de recherche très utile (et plus facile et moins lourd à utiliser pour les recherches dans les données). D'ailleurs des outils comme Nominatim se servent des subareas pour résoudre bien plus efficacement les ambiguités créées par des relations temporairement cassées. C'est 1000 fois plus efficace et produit moins d'erreur que la tentative de Nominatim de fermer une zone dont les frontières ont été cassées, par une estimation des chemins cmanquants et l'utilisation souvent trompée des calculs de distances entre centroïdes calculés pour savoir si un point fait ou pas partie d'une zone donnée ou de sa voisine mais dont les frontières sont cassées : on a eu souvent le cas comme par exemple Rennes classé en Loire-Atlantique dans Nominatim à cause de ça : Nominatim pourtant résoud cette difficulté facilement et sans se tromper avec les subareas... à condition qu'ils soient renseignés). Note: je n'ai JAMAIS dit qu'il fallait n'utiliser QUE les subareas. On continue à insérer comme membres ordonnées les ways de frontières dans les relations, car les deux types de données ne codent pas du tout la même chose : ce sont des niveaux d'analyse différents des données OSM, des niveaux presque orthogonaux puisqu'il y a de nombreuses exceptions locales à la pure définition géométrique (ces exceptions locales n'étant pas toujours des erreurs ou oublis ; les "erreurs" trouvées étant presque toujours parmi les ways oubliés ou supprimés à tord, ou mal fusionnés, ou mal subdivisés, et pratiquement jamais parmi la liste de subareas membres dont la stabilité et la fiabilité est démontrée partout ; d'autre part cela permet de gérer aussi le cas des frontières incertaines ou incomplètes, ou disputées, sans que soit remis en cause l'existence des relations et de leur liens avec une relation lus grande en tant que membre de rôle "subarea"). Dans tous les pays, on voit des instabilités de frontières. Mais on n'arrive à stabiliser les données et les faire converger et les réparer rapidement en cas d'accident qu'à partir du moment où les subareas ont été ajoutés. Chacun y trouve son compte : modificateurs, comme réparateurs, comme utilisateurs des données), et globalement la fréquence et la densité spaciale de réparations nécessaires, comme aussi les difficultés à les faire (surtout pour réparer les zones les plus étendues et les plus complexes, avec le minimum de conflits d'édition et de données à télécharger) ne fait que diminuer partout... sauf en France où on passe son temps à réparer sans arrêt les trous avec beaucoup trop d'effort nécessaire. Le 6 juin 2012 13:04, Aurélien FILEZ <kinj...@gmail.com> a écrit : > Merci pour cette rapide réponse. > > Le but est d'extraire le polygon exacte de la France métropolitaine > afin d'en obtenir le découpage via osmosis en partant d'un set de > l'Europe avec les données qui vont bien, notamment > completeRelations=yes et completeWays=yes (ainsi qu'omitdata=true) > histoire que les frontières soient propres, ce qui n'est pas bien le > cas avec les subsets de geofabrik. > > J'ai un outils permettant de gérer les sous relations, comme c'est le > cas pour la France métropolitaine, afin de produire le polygon exact > nécessaire, mais il fonctionne en ligne, et n'arrive pas à accéder à > l'adresse http://www.openstreetmap.org/api/0.6/relation/1403916/full > > Est-ce qu'il y aurait une autre source de données, à jour, que je > pourrais exploiter ? _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
