Note: un outil de "vérification" ne doit s'appuyer que sur ce qu'il connait et pas analyser des objets pour lequel il n'a pas été conçu. C'est général dans OSM, dont le modèle est évolutif et doit pouvoir s'adapter à plus de situations. Télécharger en aveugle tous les niveaux de sous-relations sans regarder de quel type de sous-relation il s'agit conduira toujours à des erreurs d'analyse qui doivent être réanalysées manuellement pour voir si "l'erreur" signalée est réellement pertinente. Dans le cas de Nates-Métropole, on a une situation spéciale liée en plus qu'elle est structurée avec un découpage qui ne s'appuie pas sur ses seuls communes membres, mais découpe la commune de Nantes elle-même (pour les pôles de proximité). L'outil devrait servir à chercher les oublis/trous dans les cas simples qu'il connait, pour le reste il n'y a aucun outil actuellement pour vérifier ces découpages orthogonaux (incompatibles entre eux si on ne les distingue pas). Avec en plus une nécessité de maintenir un certain niveau de compatibilité (à condition que les outils fassent preuvent d'intelligence au lieu de sélectionner n'importe quoi qu'il ne connait pas) Faute d'outil satisfaisant, on a un autre type d'objet spécifique qui devrait être ignoré par l'outil tant qu'il n'a pas développé une autre solution, et permet au moins des vérification manuelles et des vérifications de l'exhaustivité. Ces objets rentent séparés des objets "standards" qu'ils aident à référencer mais ne remplacent pas. aprè-s on peut discuter des tags utilisés pour ces types d'objets mais il n'y a aucun conflit avec les types d'objets existants (à condition de les interpréter uniquement de la façon dont ils sont documentés). Autre exemple : il est prétendu qu'une zone boundary ne peut avoir qu'un seul noeud admin_center, ce qui est faux dans des cas bien connus (des pays ou régions à plusieurs capitales par exemple : Afrique du Sud, communauté autonome de Gallice).
Que l'outil signale qu'il est étrange d'avoir deux objets n'est en fait qu'une alerte, pas une erreur seulement parce que l'outil le signale. Bref prendre ces alertes avec précaution et ne pas vouloir tout corriger juste pour "faire joli" parce que l'outil semble exiger ses règles en méconnaissant certains cas particuliers. La doc ne mentionne que la façon standard de traiter les cas les plus courants, pour le reste on a des exceptions et on commence à les modéliser pour ensuite faire le point sur la façon de généraliser un concept oublié, une fois qu'on a assez de données en exemple pour le faire, et il est prématuré alors de documenter plus. Le Wiki d'OSM est très très loin de tout documenter. Au début il y a des essais, puis une progression sur un plus grand nombre d'objets, plsu tard on formalise tout ça et on trouve la généralisation si on peut. Le modèle actuel des boundary est largement insuffisant, surtout les administrative, qui présuppose (à tord) que tous les découpages sont strictement hiérarchiques, comem si tous les pays et régions utilisaient une administration centralisée en étoile (ceci est également faux en Espagne avec les comarques de niveau 7 qui ne sont pas un découpage parfait des provinces de niveau 6 puisque certaines comarques sont à cheval entre deux provinces). La géographie réelle est pleine de ces exceptions et il faut être asez souple pour ne pas vouloir absolument tout systématiser. D'ailleurs en France on a imposé les "local_authority" et on a encore des problèmes avec des cas particuliers (double niveau pour la Métroploe de Paris et ses EPT, super-niveau avec les pôles métropolitains, cas particulier des poles de procimité de Nantes Métropole, cas particulier des secteurs de Marseille, qui sont un niveau intermédaire entre la commune de niveau 8 et les arrondissements municipaux de niveau 9...). Et n'oublions pas non plsu que les "niveaux" d'OSM sont même incompatibles d'un pays à l'autre pour toutes les valeurs admin_level>2, et qu'il y a même des cas de recouvrements partiels de pays sur des zones co-revendiquées ou co-administrées (y compris les eaux territoriales comme une partie du Golfe de Gascogne en co-gestion entre la France et l'Espagne, ou encore un secteur frontalier dont la souveraineté alterne tous les 6 mois...) Le modèle "standard" a ses limites que les outils ignorent (ou font sembler d'ignorer quand ils sont trop rigides). Le 20 janvier 2016 à 14:18, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Non car c'est une collection de sous-area, avec un type à part qui n'est > pas un multipolygone non plus, ça a servi à la maintenance exhaustive des > relations liées, pour faire le trie entre les différentes sous-zones de > types différents. > la découpage de Nantes est très complexe en comparaison de bien d'autres > communes. > Il ne désigne pas non plus la relation pour Nantes-Sud qui est une > relation frontière normale. > > L'analyseur de polygones ne devrait pas tenir compte de cet objet qui > n'est pas un multipolygone, pas une trontière non plus, mais il oublie de > regarder si c'est type=multipolygon ou type=boundary (ou type=riverbank qui > existe aussi par endroit) > Il y a plein de choses dans les relations dont les membres ne sont pas > forcément non plus des polygones. > > Un seul type subarea pour les sous-membre ne pourrait pas suffire, car ils > sont de types différentes et se recouvrent, il s'agit de découpages > complètement différents de la même zone (le subarea est ambigu dans ce cas > car il ne précise pas quel sous-découpage est fait > > > Le 20 janvier 2016 à 11:32, Jocelyn Jaubert <jocelyn.jaub...@gmail.com> a > écrit : > >> Bonjour, >> >> On Tue, Jan 19, 2016 at 01:41:06PM +0100, Jocelyn Jaubert wrote: >> > On Sun, Jan 03, 2016 at 03:32:54PM +0100, Antoine Riche wrote: >> > > Le générateur de polygones a l'air d'avoir des soucis. sur une >> > > relation qui semble correcte dans JOSM et >> > > http://analyser.openstreetmap.fr/, le générateur de polygone >> > > retourne une erreur. Par exemple >> > > http://polygons.openstreetmap.fr/?id=4607815 >> > >> > Je pense qu'il s'agit d'un souci avec la relation collection 4660205 >> inclue par >> > cette relation (le site web parcourt toutes les sous relations pour en >> sortir >> > le polygone "général"). >> >> En regardant le wiki, role=collection n'est pas dans la liste des rôles >> utiles >> pour un relation type=boundary. Et je pense que ça ne signifie rien de >> bien >> pertinent ici. >> >> http://wiki.openstreetmap.org/wiki/Relation:boundary >> >> >> Est-ce qu'on ne devrait pas plutôt utiliser role=subarea pour la relation >> "Nantes Sud - sous-quartiers (4660205)" ? >> >> Il s'agit de ces relations: >> https://www.openstreetmap.org/relation/4607815 >> https://www.openstreetmap.org/relation/4660205 >> >> -- >> Jocelyn >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
