Bonjorn !
Je vais me lancer dans la cartographie de Clermont-Ferrand en 1830 à l’aide du cadastre des archives départementales.
Le truc c’est que sur OHM il y a certes la possibilité de mettre la date de début et de fin, mais quid des changements de paramètres ? Comme par exemple une rue qui change de nom ? Et plusieurs fois ? Ou autre chose, de revêtement, jsp…
Mercés per vostras respònsas
Honnêtement, je ne sais pas comment cela peut être solutionné… On voit la même question réapparaitre assez souvent.
Je peux la poser sur le discord des développeur OHM, mais j’ai peur que cela n’existe pas encore…
Arg, c’est pourtant quelque chose qui est super important au vu du projet…
Bon en attendant je créerais une nouvelle entitée à chaque changement…
Aujourd’hui, je crois que pour carto un tag qui a changé, le seul moyen est de mettre :
Sauf qu’on est d’accord que c’est vraiment pas pratique et qu’on va vite arriver à une base de donnée surchargée inutilement.
Une solution possible serait de rajouter un numéro après le tag, pour connaitre son ordre dans l’histoire, avec un start:date et un end:date propre à ce tag.
Par exemple :
name:1=Rue de la Chocolaterie
name:2=Rue du Cimetière
start_date:name:1=1880
start-date:name:2=1950
end-date:name:1=1950
Cela demanderait une certaine rigueur mais c’est d’une logique implacable (je crois).
Et utiliser des relations ?
À voir avec les solutions déjà en place et la facilité d’analyse mais une idée qui me vient :
name:1880:1950=Rue de la Chocolaterie
name:1950=Rue du Cimetière
oneway:1980:2012=yes
surface::1950=dirt
surface:1950=asphalt
C’est une autre possibilité plus simple qui reprend la même logique.
Pourquoi ?
J’avoue que je préfère la solution de La voie de la Raison (ironique mdr)
Après ce n’est évidement qu’une proposition, qui si elle doit se voir adoptée un jour, devra être accepté après un vote et tout le tralala.
PS: mon pseudo, ce n’est pas ce que je prétend être mais ce que je prétend suivre 
Je rappelle que la question porte sur OpenHistoricalMap…
Quand j’y avait participé (au tout début), on avait des tags à clé suffixées pour indiquer la période temporelle où le tag s’appliquait, un truc du genre name[1820-1892]=Rue Machin
Le principe a été abandonné ?
Parce que les relations sont une manière de gérer plusieurs valeurs pour le même tag, en fonction de l’intention du cartographe. Dans OSM, on s’en sert pour partager un chemin entre plusieurs itinéraires et lui donner plusieurs tags « name » : Ligne de bus 5, Boucle pédestre des petits pas, Circuit cycliste du coup de pompe, etc.
Oui, je sais bien comment marche une relation. Mais ce que je voulais dire, c’est que, comme tu l’as écrit, elles servent majoritairement pour les itinéraires, frontières, …
Là, je ne voie pas trop l’intérêt vu qu’une rue a une histoire tellement complexe qu’il y aurait des dizaines de relations au vu de chaque attribut ayant changé. De plus cela n’empêche pas la fragmentation des way.
Pourtant je croise souvent dans OSM des relations pour décrire des rues…
C’est possible que tu confonde avec les relation d’adresses, qui englobe tout les éléments d’une même rue plus les adresses, mais ce n’est qu’une supposition. Peux-tu mettre le lien d’une de ces relations afin de mieux comprendre?
Les relations addrStreet servent en effet à la base pour les adresses et les regroupent ainsi que les tronçons de voie de la rue pour créer une relation logique entre eux, mais à la base on ne regroupe pas juste les tronçons de voies.
La relation 1260363 par exemple (recherchée au hasard avec Overpass, parce que je n’ai qu’un téléphone sous la main)
La réponse d’un gars de OHM au US à ce sujet :
This is a tricky thing, b/c you could take several different approaches:
Use a relation to carry all of the time-changing attributes (surface, lanes, names, etc.) with appropriate start and end dates, and then just create a different relation for every change (I think but do not know this is preferred)
Use a single relation for the road and then create different ways for each time (I think this is problematic)
Now, the problem here is when sub-parts of the relation change, but again, I think that’s still a job for a relation.
For now, because there really isn’t a definitively correct model and no built-in lifecycle features in the OSM datamodel, I think the best thing to do is to figure out what works best for you now, and let others know what you learn. D’accord?