Bonjour, > De : "Pieren" > > Cette discussion revient régulièrement sur toutes les listes. La > dernière en date, c'est un américain qui se plaignait de devoir > supprimer à répétition une portion de route qui n'existe plus dans la > réalité mais qui est systématiquement rajoutée par d'autres parce > qu'elle est visible sur l'imagerie aérienne Bing. Comment dire aux > autres "cette portion de route n'existe plus" ? Ici, ce genre de > problème est plus fréquent avec les bâtiments qui sont encore dans le > cadastre mais plus dans la réalité. La seule solution actuellement > supportée par tous les outils : c'est mettre un way virtuel avec une > note : "cet objet n'existe plus depuis 1/1/2013", par exemple. > Je pense que la seule solution qui marche est de rajouter ces > informations, même générales, directement sur tous les objets > concernés. Quitte à mettre "source=attention, bâti décalé+cadastre > DGFiP 2013" sur tous les building d'une commune. > C'est brutal mais c'est le seul moyen d'avoir une chance d'être lu. > Malheureusement, certains éditeurs ont tendance à les cacher sous le > tapis. Par exemple, iD affiche bien les tags "note" mais pas les > "fixme". Ou JOSM qui considère qu'un élément avec uniquement un tag > "note" est un élément sans tags et l'affiche comme tel à l'écran. > Cette méthode a aussi l'avantage de s'adresser à ceux qui > s'intéressent à ces éléments, parce qu'ils les ont examinés > individuellement. > Par contre, ajouter de gros polygones pour dire "c'est le bazar dans > toute cette zone" ou "cette zone est converte par une imagerie > aérienne détaillée depuis xxx", c'est une très mauvaise idée parce que > ça gêne les contributeurs qui s'en foutent et que ça ne correspond à > rien sur le terrain. > Mettrre ces polygones dans une base séparée ? Pourquoi pas. Mais on a > déjà un outil qui s'appelle les "notes" et qui fait à peu près la même > chose. Peut-être que la solution passerait par l'extension de cet > outil sous forme de polygones alors qu'actuellement, on ne peut > définir des "notes" que sur des points.
L'idée de propager sur les objets de la base les notes en tous genres sur les sources pas à jour, décalées, etc, ne me dit rien de bien. Je penche vraiment pour une séparation entre les objets de la base OSM et ceux qui doivent porter les infos de qualification des sources. En disant "séparation", ça peut néanmoins être un voisinage proche, comme les traces GPS sont proches des données à tel point qu'elles sont téléchargeables par un outil commun (JOSM), à une case à cocher près. Je ne vois pas de blocage de principe à stocker ces infos ailleurs. On a déjà plein d'exemples d'informations stockées en dehors de la base et qui pour autant interagissent avec elle. Par exemple : - pour des stats sur les tags, le reflex est pour (quasi ?) tout le monde d'aller sur taginfo.org. C'est suffisamment pertinent et consensuel pour que tout le monde converge vers le même service, pourtant externe. - pour les emprises d'imagerie dispo, JOSM interagit avec des metadonnées pour proposer, sur une emprise donnée, l'ajout de couches WMS. Là encore, on accède à des infos hors de la base mais qui savent interagir avec les outils. Je pense vraiment qu'on ne doit pas bloquer sur ce stockage externe. À mon avis, ça ne peut pas être la cause de l'échec d'un service. Les questions sont plutôt sur l'intégration de ce service avec les outils : comment renseigner simplement une information sur les sources ? Comment y accéder tout aussi simplement ? Je réitère l'idée de s'appuyer sur uMap pour s'entraîner à collecter ces métadonnées. Les "fortunes" du cadastre sont un bon motif (mais pas le seul) pour amorcer une visu, si quelqu'un se sent de commencer. vincent _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
