Le 4 janvier 2013 16:03, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 4 janvier 2013 15:38, Christian Quest <cqu...@openstreetmap.fr> a écrit : >> C'est l'utilisation de tags standards qui crée la confusion. >> >> Ajouter un tag (comme historic=yes) ne résoudra le problème que pour >> les outils tenant compte de celui-ci, ce n'est donc pas une bonne >> solution à mon avis. >> >> Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? >> >> Rappel: name[:1970]=Place de l'Etoile > > Cela ne marche QUE pour les objets dont la géométrie n'a pas évolué.
Oui, mais c'est déjà une première étape pour pouvoir indiquer des caractéristiques qui ont pu changer, sans que la géométrie de change ou assez peu pour qu'on puisse la confondre avec l'existante. > Là je parlais des objets limités différemment (par exemples des > fusions/scissions de cmmunes ou d'EPCI ou d'arrondissements, ou > changements du découpage cantonal/électoral, voire aussi les anciens > pays comme la Tchécoslavquie, ou l'Union soviétique, ou la RDA, font > il est aberrant de ne plus pouvoir dresser une carte alors qu'on a > souvent besoin de les montrer pour expliquer l'histoire, ou encore les > variations des frontières de la France au cours des siècles, y compris > les départements d'Alsace et Lorraine pendant les conflits avec > l'Allemagne depuis 1870, ou encore les cartes des anciens empires > français et britanniques). > Pour ces objets là, on peut très bien garder une copie de la relation et modifier les tags pour qu'ils indique qu'on décrit un objet "passé". boundary=xxx -> boundary[dates]=xxx > Pourtant l'histoire a fourni des traces persistantes dans les statuts > légaux et traités internationaux (par exemple en Alsace-Moselle pour > le concordat), qu'il est difficile de matérialiser sans support par > une carte montrant ces historiques. > > Il y a aussi le cas des collectivités en transition (deux coexistent > dans la même période : il n'est pas toujours poassible de choisir > l'une ou l'autre comme plus actuelle, même si leurs tags sont > différents) : on a donc besoin d'objets séparés marqués entièrement > eux-mêmes comme "historiques" avec leur propre ID séparé des objets > actuels. > Tout à fait. > Et pouvoir disposer d'un filtre permettant de masquer AUTOMATIQUEMENT > certains objets historiques (tant qu'on ne les demande pas > EXPLICITEMENT dans une requête) serait préférable à l'introduction de > tags spéciaux comme name[:1970] : à mon avis c'est mieux de coder deux > objets séparés chacun avec leur date de validité et la possibilité > d'en cacher certains par défaut. > Un masquage à quel niveau ? Au niveau de l'API ? au niveau du rendu ? Avec ces tags, ils sont forcément masqués au niveau du rendu car ne correspondent plus à des tags utilisés par les moteurs de rendu (sauf ceux qui voudraient en tirer parti). Pour l'API, les masquer me semble dangereux. Pour les dumps, on peut très bien les filtrer si on n'a en a pas l'usage. Le 4 janvier 2013 16:24, Ista Pouss <ista...@gmail.com> a écrit : > > Malheureusement les dates sont un des nids à problèmes de l'informatique et, > à ma connaissance, il n'existe pas de solution universelle. > > Surtout que ta proposition suppose que ce soit une plage de dates, et non > une date seule, qui indexe le nom. Car j'imagine que tu vas vouloir dire > quel était le nom de cette place en 1969, un jour. > name[:1970] indique que jusqu'en 1970 elle portait ce nom. Je m'inspire de la gestion des dates en généalogie où on peut avoir une date floue qui se précise petit à petit en fonction des recherches. Si on a une information partielle, on peut la noter, puis l'améliorer au fur et à mesure des sources d'infos. Ex: un plan de 1861 indique un nom pour une rue, je peux mettre name[1861]=xxx Un autre le 1820 porte le même nom, on peut en déduire avec de faible chance d'erreur ce tag... name[1820:1861]=xxx Pour exploiter ces informations, il faut bien sûr un traitement complémentaire sur les tages pour en extraire les dates de début/fin, mais au moins, l'info est disponible, et pas trop complexe à saisir, sans venir mettre le bazar dans les utilisations courantes de données. > Ce n'est pas impossible, mais je ne sens absolument pas OSM assez robuste > pour ça. > Pas robuste pour quelques tags en plus ? > Surtout que, sauf erreur, le name n'est qu'un tag parmi d'autres, qui ne > distingue absolument pas l'objet terrain.Or ce que tu veux est l'historique > de l'objet. Quel est, dans la base, ce qui dit "c'est un objet" ? Si t'as > pas ça on tombe forcément dans le pataquès dénoncé, avec son style bien à > lui, par Philippe. > Ce n'est pas vraiment l'historique de l'objet que je cherche à avoir (même si ça peut être un moyen de le faire), mais un moyen minimal de noter des informations passées liées à un objet ou de préserver une information intéressante qui sinon risque de disparaitre suite à un changement récent par l'unicité des tags. En 2009, une présentation au SOTM parlait de cela justement: http://fr.slideshare.net/frankieroberto/mapp-history-on-open-street-map J'essaye juste de trouver un moyen simple, qui ne casse rien aux fonctionnements existants des éditeurs, de l'API et du reste de la chaine (rendus, calcul d'itinéraire, etc).. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
