périmètre administratif historique

Bonjour,
Jusqu’il y a peu, quand sur WikiTree on cherchait un lieu, ce site vous proposait de le trouver avec Grr Maps.
Après quelques discussions, OpenStreetMap a le droit de citer.
Bien, mais on peut faire mieux et pour cela j’ai besoin de votre aide.

Une personne a fort justement fait remarquer que s’il y avait possibilité de trouver des données historiques ce serait un vrai plus.

Il est déjà possible d’ajouter des attributs old_name (y compris avec le sous attribut de langue à la old_name:fr ou daté name:1945–1990 voir les deux).
Si vous cherchez Rue de La Montagne, Brest vous trouvez la rue en question et la Rue du Brigadier le Cann, Le Guelmeur, Brest, Finistère, Bretagne, France métropolitaine, 29200, France. En effet suite à une prise d’otage la Rue de la Montagne a été coupée en Rue de la Montagne et Rue du Brigadier le Cann.

De même vous pouvez maintenant chercher la Loire-Inférieure.
En attendant plus longtemps ou avec l’aide d’un gentil administrateur qui force l’actualisation des index de grandes zones, vous pouvez donc retrouver d’anciennes adresses telles que Nantes, Loire-Inférieure.
La réponse est bien sûr Ville Nantes, Loire-Atlantique, Pays de la Loire, France métropolitaine, 44000;44100;44200;44300, France.

Jusque là tout allait bien. Le problème c’est que la Loire-Inférieure a fait partie de la Bretagne administrative. Oui, Nantes est en Bretagne, mais ceci ne concerne pas OpenStreetMap tant que la Bretagne ne sera pas réunifiée administrativement parlant.
Quoique, si justement. Un généalogiste peut tout à fait légitimement trouver des adresses “Nantes, Bretagne”.
Actuellement il tombera sur le quartier Bretagne de Nantes. Pas trop mal, mais logiquement il devrait tomber sur Ville Nantes, Loire-Atlantique, Pays de la Loire, France métropolitaine, 44000;44100;44200;44300, France. Là les ligériens ne m’en voudront plus :wink:.

Restait donc à créer la région administrative historique Bretagne.
Après avoir lu les différentes techniques proposées dans le Wiki, j’ai choisi celle qui me semblait la plus simple : la création d’une relation comportant 5 membres (les départements bretons) avec le rôle area.

Après avoir créé une relation http://www.openstreetmap.org/relation/4568925 afin que cette zone soit cherchable par Nominatim je me suis rendu compte que ça ne marchait pas.
J’ai mis les tags suivants :
admin_level:1790-1972=4
description:fr=Bretagne historique
name:1790-1972=Bretagne
note=pour que Nominatim puisse trouver des lieux historiques tels que Nantes, Bretagne
type=boundary:1790-1972
wikipedia=fr:Bretagne

Sauf que Overpass-turbo me dit que la relation ne comporte pas de nœud :

  ["type"="boundary:1790-1972"];
(._;>;);
out body;

Je pensais que donner les membres en tant qu’area aurait suffit pour que Nominatim et Overpass-turbo sachent calculer les géométries associées.

À coup d’overpass-turbo et de JOSM j’ai donc préparé une Bretagne avec l’autre technique (récupération des frontières des 5 départements, suppression des limites internes).
Ça doit être bon.

Mais grâce au fil de discussion Aide sur JOSM : Import périmètre administratif j’ai découvert l’existence du lent (tout est relatif, c’est bien plus rapide le ma deuxième version) mais génial ComComMaker servant à créer des entités formées d’autres entités.
Les tags précédents sont-ils corrects en particulier celui-ci :
admin_level:1790-1972=4
(pas admin_level).
Est-ce que je peux ne rien entrer comme admin_level ?
Même question pour le type=boundary.
En effet je ne veux pas risquer que la Bretagne historique apparaisse comme région administrative actuelle.

Si ce que j’ai proposé n’est pas stupide est-il possible d’enrichir ComComMaker (en historicalregionmaker.openstreetmap.fr ?) afin :

  • d’être multilingue (même si WikiTree ne l’est pas)
  • d’avoir la possibilité d’entrer des dates de validité (ici 1790-1972)
  • et même dans le cas de régions historique l’obligation de les dater (au moins une date de fin --YYYY).

Je suis bien sûr d’accord pour apporter ma pierre à l’édifice (et à inciter des généalogistes de WikiTree à faire de même). Comme ça je pourrais leur proposer un tuto pour ajouter des régions historiques (sans risquer de tout casser). Vous semble-t-il préférable pour l’étape “sans risquer de tout casser” de leur conseiller de passer le fichier .osm généré à des personnes maîtrisant JOSM ou doit-on développer le tuto pour qu’ils puissent le faire eux-mêmes ?

Tu touche une question sensible (lire "à troll): quelle place pour des données “historiques” dans OSM…

Personnellement, je pense que c’est utile, mais que ça ne doit pas gêner le fonctionnement “normal” des outils qui s’appuient sur les données OSM.
Par contre… les outils habituels ne sauront pas en tirer parti et c’est le problème que tu rencontre.

Vouloir faire les deux en même temps va poser des problèmes à un moment donné et il ne faut pas non plus tagguer pour forcer à obtenir tel ou tel résultat sur tel ou tel outil alors qu’on n’est pas dans un cas “normal”. Nominatim n’est pas parfait et ne gère pas tout les name=* qu’il trouve.
Les name=* sur des area=yes sont en général visibles sur le rendu mapnik d’osm.org (pas forcément un choix judicieux d’ailleurs), mais les deux ne sont pas liés et ne fonctionnent pas de la même façon.

Tu touche une question sensible (lire "à troll): quelle place pour des données “historiques” dans OSM…

Personnellement, je pense que c’est utile, mais que ça ne doit pas gêner le fonctionnement “normal” des outils qui s’appuient sur les données OSM.
Par contre… les outils habituels ne sauront pas en tirer parti et c’est le problème que tu rencontre.

Vouloir faire les deux en même temps va poser des problèmes à un moment donné et il ne faut pas non plus tagguer pour forcer à obtenir tel ou tel résultat sur tel ou tel outil alors qu’on n’est pas dans un cas “normal”. Nominatim n’est pas parfait et ne gère pas tout les name=* qu’il trouve.
Les name=* sur des area=yes sont en général visibles sur le rendu mapnik d’osm.org (pas forcément un choix judicieux d’ailleurs), mais les deux ne sont pas liés et ne fonctionnent pas de la même façon.

Bonjour,

Il me semble qu’OSM n’a pas vocation à gérer le passé, seulement le présent. Le wiki mentionne http://wiki.openstreetmap.org/wiki/Open_Historical_Map comme projet annexe pour cartographier le passé.

Oui, oui. Il faut mettre le hola tout de suite. Il y a un large consensus pour ne mapper que le présent. Il y a déjà des problèmes avec des données “futures” (comme des projets de routes). Alors les données du passé… Je dois avouer que j’ai faillit supprimer cette relation moi-même directement. Mais je pense que c’est mieux que ça soit l’auteur qui le fasse pour une prise de conscience.

Les références historiques soulèvent moins de remarques lorqu’ils se cantonnent à quelques tags, genre old_name ou old_ref. Ils ont une certaine utilité losrqu’on utilise comme source d’anciennes cartes ou que des traces restent sur le terrain (comme d’anciens panneaux). Mais c’est à la condition que leur nombre soit limité. Et qu’ils ne gênent pas trop les contributeurs. Le fait de créer des éléments spécifiques (comme des ways ou des nodes) ou même des relations sont par contre de beaucoup moins tolérées lorsque leur nombre devient trop important et gêne l’édition classique. Il est de toute façon très difficile de maintenir l’intégrité des grandes relations car on constate qu’elle sont régulièrement “cassées” par les contributeurs débutants, ce qui nécessite une veille permanente.

De plus, ces données sont par nature statiques. Elles n’ont pas besoin d’être dans un wiki puisqu’elles ne doivent pas changer. Elles ont donc plus leur place dans une base de données séparée. Ou dans des projets clones comme OHM, déjà mentionné.

On va laisser faire l’auteur revenir en arrière. Mais ça ne veut pas dire qu’on ne va rien faire si celui-ci persiste…

Habituellement, j’aime pas être d’accord avec les idées bizarres de Pieren, mais là, je dois bien avouer qu’en l’état actuel des outils d’édition qui ne séparent pas les objets du passé du présent et du futur, si on accepte des frontières vielles de 40 ans, on va vraiment se retrouver avec de grosses difficultés d’éditions devant ce plat de spaghetti.

Pour un bar qui vient juste de fermer et que de nombreuses personnes indiquent encore comme direction , l’indiquer pendant encore ~5 ans comme “ancien bar fermé qui portait le nom de truc” à la limite, on est sur de la faible étendue, pour une durée limité, j’ai envie de dire que ça peut le faire tant qu’il est “dans le présent des esprits”

ps: je n’adhère en revanche pas à la justification de Pieren : “Vu que ça ne changera plus, pas dans un wiki” . Le wiki est un outil qui n’a pas pour but unique de traiter ce qui ne changera plus dans le futur. La date de naissance de Roosvelt ne changera plus et elle a tout à fait sa place dans wikipedia

@sly - ben oui mais là, tu tombes justement dans le piège des “comparaison n’ait pas raison”. C’est toute la diffèrence entre un wikipedia qui collecte (aussi) des faits historiques intangibles et OSM qui reflète le présent qui change en permanence - y compris les frontières des régions. Par définition, ce qui entre dans OSM peut être modifié par quiconque. Cela me rapelle une vieille discussion lorsque le service SIG de la ville de New-York était prêt à importer ses limites administratives dans OSM à la seule condition que personne ne puisse les modifier à part eux. C’est là que Frederik Ramm avait expliqué que par nature, des données qui ne pouvaient être modifiables par quiconque n’avaient pas leur place dans OSM.

@pieren : “OSM qui reflète un présent qui change en permanence” est une vision tronquée de ce que répertorie osm (ou de mauvaise foi). Le point culminant d’une montagne ne change qu’avec la tectonique des plaques, ça n’empêche pas qu’un wiki, qui apporte une méthode de contribution itérative est tout à fait indiqué pour les répertorier.

Mais nous nous dirigeons lentement vers le hors sujet.

héhé, j’ai faillit parler de l’altitude du mont blanc dans mon précédent post. Sa mesure a beaucoup varier dans le temps (cf http://fr.wikipedia.org/wiki/Mont_Blanc#Altitude_du_mont_Blanc) surtout grâce aux progrès des appareils de mesure. Pour OSM, c’est pareil. Certaines choses peuvent ne pas varier sur le terrain mais de meilleures sources mise à disposition (pour un import ou encore une imagerie aérienne de meilleure qualité) peuvent engendrer des corrections dans OSM. Concernant les limites adminitratives, on voit qu’elles évoluent en permanence comme celle de la région Bretagne. Garder les anciennes versions impliquerait qu’il ne faudrait pas/plus les modifier dans OSM. Pour la Bretagne, on se base en plus sur la forme actuelle des communes. Pour être exact, il faudrait aussi séparer et conserver toutes les anciennes limites communales qui bougent par échanges de parcelles ou déplacements de frontières physiques (comme les rivières ou les routes). Et chacune de ces versions, une fois bien établies, auraient vocation à ne plus être modifiées, comme la date de naissance de Roosvelt dans wikipedia.

Merci, j’avais lu ce Wiki et consulté le site en question… qui comporte quelques voies romaines.
Pas exactement la réponse au besoin exprimé (voir en début de mon post).

Est-ce que quelqu’un ici peut raisonnablement affirmer que OpenHistoricalMap répond au besoin ?

@Pieren “Il y a un large consensus pour ne mapper que le présent.”
S’il y avait large consensus, cquest ne parlerait pas de troll et les extensions horodatées de tags n’existeraient pas.

Pieren 11:42 : “Mais je pense que c’est mieux que ça soit l’auteur qui le fasse pour une prise de conscience.”
Pieren 11:49 : “On va laisser faire l’auteur revenir en arrière. Mais ça ne veut pas dire qu’on ne va rien faire si celui-ci persiste…”
Deuxième couche en 7 minutes. Le ridicule ne tue pas. Et c’est tant mieux.
Bon, c’était juste pour nourrir le troll, revenons aux choses sérieuses.

“Il y a déjà des problèmes avec des données “futures” (comme des projets de routes). Alors les données du passé…”
J’entends bien, mon but n’est pas de tout casser !

“(…) Mais c’est à la condition que leur nombre soit limité.”
Le nombre de structures administratives passées est très faible par rapport au nombre de nœuds dans OSM. Et il y a plus de mappeurs pour mettre à jour les horaires du bistrot que pour ajouter des régions historiques.

“Et qu’ils ne gênent pas trop les contributeurs.”
“Il est de toute façon très difficile de maintenir l’intégrité des grandes relations car on constate qu’elle sont régulièrement “cassées” par les contributeurs débutants, ce qui nécessite une veille permanente.”
D’où la création d’une relation comportant 5 membres (on doit être d’accord sur le fait que ce n’est pas une grande relation). C’était une des méthodes proposées pour la création de contours administratifs.
Si les relations sont souvent cassées c’est parce qu’elles sont longues et donc fragiles (comme le trait de côte par exemple).
Ici en théorie la définition faite (union de 5 zones) se suffit à elle-même, d’ailleurs comcommaker transforme cette description simple en relation complexe afin de palier aux défauts d’OpenStreetMap.
Je dis volontairement “défauts”, en me plaçant d’un point de vue utilisateur. J’entends bien que les calculs d’appartenance et de tracé sont basés sur les contours (les chemins) et non les zones. Mais ça c’est d’un point de vue informatique. Je ne connais personne me disant que la Bretagne est délimitée au nord, à l’ouest et au sud par le trait de basse côte. Pour savoir si je suis en Bretagne, il me suffit de savoir si que je suis dans un département de Bretagne. Ou une commune de Bretagne, personnellement je ne regarde pas si je suis vu à gauche du polygone principal en le parcourant dans le sens trigonométrique, même si pour un ordinateur c’est plus simple de calculer ainsi.

Sur les grandes relations qu’y a-t-il ? Sans prendre trop de risques je dirais le trait de côte (et les trais dérivés comme les 12 miles nautiques et autres ZEE), les rivières et les contours administratifs. Or la plupart des zones administratives sont des regroupements de zones administratives plus petites.

Tant que les zones ci-dessous ne changent pas, pas de soucis en théorie car si la relation est décrite comme dans comcommaker, c’est “juste” la moulinette de comcommaker à relancer : le contour de la relation supérieure s’adaptera.
Pour un mathématicien c’est juste un peu de topologie, pour un informaticien c’est un peu plus compliqué et pour un mappeur derrière JOSM c’est vite un cauchemar.

Donc ce qu’il faut c’est éviter le plan galère du mappeur et l’affichage de zones qui n’ont pas lieu d’être affichées.

On peut envisager que ces relations soient maintenues par des robots et non “à la main”, l’humain soumettant la relation en termes de haut niveau (ici BZH historique=22+29+35+44+56) et le robot, de la même façon que des index sont mis à jour automatiquement, recalcule le contour par élimination des contours en double des zones englobées.

“Elles ont donc plus leur place dans une base de données séparée. Ou dans des projets clones comme OHM, déjà mentionné.”
En théorie, on est d’accord, en pratique, voir ma remarque sur OHM (je n’ai pas précisé mais les cartes de 2008 et 2009 sont carrément vides, la carte “historical” n’a pas de date et les quelques routes datent de l’époque romaine).
De plus le nominatim présent utilise les données d’OSM et non celles d’OHM. Avec au final un lien qui ne marche pas, les identifiants des deux systèmes étant différents. OHM, un clone qui fait le clown ?

Ajouter des couches dans une umap, si un nominatim intégrait ces données (en cascadant sur le nominatim principal), ce serait sans doute une alternative.

@sly “en l’état actuel des outils d’édition”
On est d’accord, d’où la proposition ci-dessus.

@sly@pieren : “OSM qui reflète un présent qui change en permanence” est une vision tronquée de ce que répertorie osm (ou de mauvaise foi)”
Effectivement, @pieren confond son point de vue (respectable) et ce qui est (qui est quelque peu différent).

@pieren “Garder les anciennes versions impliquerait qu’il ne faudrait pas/plus les modifier dans OSM. Pour la Bretagne, on se base en plus sur la forme actuelle des communes. Pour être exact, il faudrait aussi séparer et conserver toutes les anciennes limites communales qui bougent par échanges de parcelles ou déplacements de frontières physiques (comme les rivières ou les routes). Et chacune de ces versions, une fois bien établies, auraient vocation à ne plus être modifiées, comme la date de naissance de Roosvelt dans wikipedia.”
Non, pour plusieurs raisons, même si d’un point de vue théorique (ou rhétorique, c’est selon) c’est exact.
On peut bien-sûr pour être rigoureux ajouter les glacis entre la Bretagne et la France d’avant 1532, etc… (*).
Et là on se retrouve sur le projet OHM.
Sauf que ce n’est pas mon point de départ.

Je rappelle le besoin : pouvoir retrouver sur une carte, même actuelle, une adresse d’époque afin s’inciter les généalogistes à utiliser OSM plutôt que GM. Est-ce que la carte muette OHM dont les recherches donnent des liens morts est une réponse sérieuse ? Là ils vont vite aller chez le pisteur en chef alors qu’ils font eux aussi un travail contributif.
Si la zone est plus grande de quelques km, c’est sans conséquence. Que des mappeurs fous ne doivent pas pouvoir modifier c’est hors sujet (je peux modifier n’importe quel tracé actuel ce qui est bien pire que de changer un tracé non affiché).
D’où la reprise des départements actuels. Tout comme le nouveau découpage des régions ne devrait pas empêcher dans le futur de chercher un “Strasbourg, Alsace” même si l’Alsace a disparu au profit de la Champagne-Ardennes-Lorarraine-Alsace si c’est la version des députés qui s’impose et donc que Nominatim répond “Strasbourg, Grand-Est”.

(*) ou sur les données de New York, merci pour le contre-exemple pertinent :wink: : ce n’est pas parce que l’on peut vandaliser qu’on va vandaliser, ici si quelque veut se « taper » un contour exact à la main, bonne chance et rien ne l’interdit.
Au fait, l’article de Wikipedia consacré aux régions prend pour référence les départements actuels. J’entends bien que par le passé (mais plus maintenant) le Mont-Saint-Michel était en Bretagne ou en Normandie suivant le tracé du Couéron, il ne faut pas pour autant que l’arbre cache la forêt.

Consensus ne veut pas dire unanimité. Je suis les discussions locales et internationales de ce projet depuis 2007 et je peux te garantir que l’immense majorité des contributeurs ne veulent pas de choses qui n’existent plus sur le terrain dans OSM. Il y a des cas à la marge comme le suivit de catastrophes naturelles (évalutation des destructions de bâti, organisation des secours, etc), l’identification d’éléments récemment disparus mais encore présents dans certaines sources (cadastre en France, imagerie aérienne) ou la disparition d’éléments qui conservent une trace sur le terrain (ruines ou dénivelés d’aanciennes voies de chemin de fer). Ce qui ne veut pas dire que régulièrement, il y a des gens qui tentent d’utiliser OSM pour y stocker des choses du passé (tu es loin d’être le premier). Ce qui à chaque fois soulève des protestions et a conduit à ce que ces personnes constituent un groupe pour utiliser les outils d’OSM sans avoir à utiliser la base de données d’OSM (le fameux projet “open historical map” déjà mentionné, qui a sa propre liste de discussion dont je suis aussi abonné).

Non, non. Ca n’est pas un troll. La relation sera supprimée dans les jours prochains. Si tu trouves que c’est exagéré, il faudrait alors que tu demandes l’opinion du reste de la communauté en postant, par exemple pour commencer, un message sur la liste francophone talk-fr@openstreetmap.org . Au cas où ça ne serait pas suffisant, tu pourrais passer à l’échelle supérieure en protestant sur la liste internationnale talk@openstreetmap.org et en dernier recours contacter le groupe des modérateurs du projet qu’on appelle le DWG dont Sly fait aussi partie.
Je pourrais aussi, si souhaité, référencer les nombreuses interventions de plein de gens ces dernières années qui protestaient contre l’ajout de données historiques dans osm. (pour dire que le problème n’est pas nouveau)

Le problème n’est pas de casser l’existant mais de faire coexister sur le même plan des données actuelles, futures et passées. Cela crée un immense plat de spagetti et complexifie considérablement le travail de “lecture” et compréhension des données par les contributeurs lambda.

Nominatim ne fonctionne pas avec un paramètre “date”, il faudrait donc modifier ce logiciel pour qu’il cherche des adresses en fonction d’une date. C’est faisable. Il faut juste trouver quelqu’un pour le faire et ce, dans le cadre d’OHM, parce qu’encore une fois, ce projet a été créé par des personnes qui ont constaté qu’ils n’étaient pas les bienvenus dans la base OSM principale. De plus, nominatim se base sur des limites administratives modélisés à partir de la somme des bords, jamais sur des relations donnant une somme de surfaces plus petites. Là aussi, c’est un très vieux troll mais ça fait des années que ça ne change pas.

umap peut uniquement aider pour des solutions d’affichage. Il ne sera d’aucune utilité pour des recherches d’adresses avec nominatim.

Je ne comprends pas que, se basant sur l’architecture OSM, il ne réutilise pas les données OSM en en ajoutant des similaires mais avec des identifiants différents (ou que les deux systèmes réservent des plages d’id). Car un nominatim qui donne des adresses systématiquement fausses (url OHM mais avec un id OSM)…
C’est bien parce que ça semblait logique que j’avais commencé à regarder OHM avant de revenir à OSM. Tu sais s’il est raisonnable de leur demander de renuméroter leur base afin de les rendre compatibles ? Changer les identifiants dans une base, ça se fait, mais pas à la légère.

Non, seulement le ton employé l’était et plus exactement les deux posts successifs venant de la même personne.

D’après la documentation, Nominatim accepte les is_in (tant qu’à réveiller les trolls :wink:).
Je suppose que le rang est moins bon que si c’est trouvé par inclusion. Parfait.

Ajouter des attributs historiques sur des données existantes semble être une pratique tolérée (et citée dans ce fil). Un tag is_in:state:1790-1972=Bretagne sur la Loire-Atlantique serait un compromis acceptable, n’est-ce pas ?
Pas de risque d’affichage erroné sur les cartes, pas de plat de spaghetti sur JOSM et Cie. Le seul problème potentiel c’est que des adresses anciennes semblent valables et donc risquer de faire marginalement des faux positifs, sauf que Nominatim affiche le résultat avec les noms actuels et le système de classement relèguera les infos à la fin.
D’ailleurs à propos de date, ça pourrait, sans filtrer par date, simplement trier par date (les données courantes d’abord, puis par plage de validité).
À la limite, c’est plus une explication du résultat que le résultat qu’il faut améliorer.
Une recherche de “Nantes, Loire-Inférieure” donne “Nantes, Loire-Atlantique”, ça pourrait rendre “Nantes, Loire-Atlantique (anciennement Loire-Inférieure)”.
À l’opposé une recherche de “Nantes, Loire-Atlantique” donnerait toujours “Nantes, Loire-Atlantique”.

À propos de la possibilité d’utiliser le Nominatim d’OpenStreetMap :
A feature such as the ability to add historic places would make this definitely superior to the Google map link. As it is it is mostly useless if we follow the style guidelines (a guiding principle is to “use their conventions instead of ours.” Applied to locations, this means using place names in native languages and using the names that people at the time used, even if they now no longer exist.)

Je ne sais pas si tu veux juste ajouter le tag “is_in:state:1790-1972” sur le noeud représentant la ville de Nantes ou sur la relation de la commune ou sur toutes les adresses de Nantes. L’impact n’est pas le même. Et de toute façon, le nominatim standard ne tiendra pas plus compte de ce tag que la super-relation historique précédemment citée (ça ne marcherait qu’avec un simple “is_in”).
Le concept de trier les résultats de nomintim par date est là encore quelque chose qui ne concernerait qu’OHM, c.à.d. ceux qui s’intéressent à l’historisation de la cartographie.
Sur les points de comment faire coexister données présentes et passées, c’est très complexe, surtout si on veut tisser un lien entre les différentes versions dans l’histoire d’un élément (que ce soit des frontières ou du bâti). Il faudra aussi tôt ou tard adapter l’éditeur. C’est donc toute la chaîne de production (éditeur, rendu, namefinder) à qui il faut ajouter une composante “temps”. Et j’ai peur que pour l’instant, il manque surtout des bras pour résoudre tous ces problèmes.

PS: si j’ai fais deux posts au début, c’est parce que je ne suis pas inscrit sur ce site et donc que je ne peux pas éditer mes précédents posts.