subject:"Re\: \[OSM\-talk\-fr\] Données historique et historiques des données..."

Bonjour,

Je suis plutôt pour conserver un historique en effet.

Par contre non pas l’implanter dans les tags, il est possible d'utiliser
les versions.
Ces dernières ont déjà une dimension temporelle, plus temporelle que les
tags par exemple.

Le problème est qu'on ne sait pour l'instant pas si le passage d'une
version à l'autre reflète une modification de la carte uniquement ou une
édition suite à une modification du terrain.

Ca demande forcément quelques modifications de l'API et on peut facilement
préciser dans une requête qu'on ne veut que des données contemporaines et
pas du passé.

C'est d'ailleurs étonnant que ca ne fasse pas partie des motivations de
l'utilisation d'une base versionnée...

2013/1/3 Christian Quest cqu...@openstreetmap.fr

 Au moins l'avantage avec des données anciennes, c'est qu'elles sont
 stables ;)

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
*François Lacombe*
*Apprenti Ingénieur Télécom Bretagne*

francois dot lacombe At telecom-bretagne dot eu
+33 6 73 41 92 99

http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Les numéros de version ne s'appliquent qu'au données, pas à
l'historique d'un objet sur le terrain.

Le changement d'année apporte son lot de changement dans les
découpages administratifs, les intercommunalités, etc.

J'essaye de produire une carte où j'ai besoin des EPCI de 2010...
comment je fais ? Prendre des données OSM de 2010 ? Loupé... il n'y
avait quasiment aucun EPCI.

Autant je comprend tout à fait qu'on ne peut pas tout mettre dans OSM
et que faire des cartes historiques dépasse le cadre d'OSM avec son
fonctionnement actuel autant certaines informations récentes mais ne
correspondant plus au présent peuvent être bien utiles. C'est cette
réflexion que j'essaye d'avoir.


Le 4 janvier 2013 15:06, François Lacombe
francois.laco...@telecom-bretagne.eu a écrit :
 Bonjour,

 Je suis plutôt pour conserver un historique en effet.

 Par contre non pas l’implanter dans les tags, il est possible d'utiliser les
 versions.
 Ces dernières ont déjà une dimension temporelle, plus temporelle que les
 tags par exemple.

 Le problème est qu'on ne sait pour l'instant pas si le passage d'une version
 à l'autre reflète une modification de la carte uniquement ou une édition
 suite à une modification du terrain.

 Ca demande forcément quelques modifications de l'API et on peut facilement
 préciser dans une requête qu'on ne veut que des données contemporaines et
 pas du passé.

 C'est d'ailleurs étonnant que ca ne fasse pas partie des motivations de
 l'utilisation d'une base versionnée...

 2013/1/3 Christian Quest cqu...@openstreetmap.fr

 Au moins l'avantage avec des données anciennes, c'est qu'elles sont
 stables ;)

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




 --
 François Lacombe
 Apprenti Ingénieur Télécom Bretagne

 francois dot lacombe At telecom-bretagne dot eu
 +33 6 73 41 92 99

 http://www.infos-reseaux.com

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Les versions d'objets ne sont pas satisfaisantes. Elles traitent
toutes sortes de situations de modifications ou
suppression/scission/fusions d'objets, parfois aussi des reverts, ou
des modifs annulées ou rendues invisibles par un problème
d'incompatibilité de licences ou de violation de droits.

La date de ces modifications n'a rien à voir avec la validité
historique de ces objets. On ne pourrait donc pas se passer des tags
pour mentionner les fates de validité des données historiques. Quelque
chose comme historic:start=-mm-dd et historic:end=-mm-dd.
Mais on doit alors toruver un moyen clair de les cacher
automatiquement et facilement pour un rendu actuel avec
hidden=historic pour qu'il n'y ait pas de confusion avec les objets
actuels.

A mon avis ces données historiques devraient être clairement
accessibles uniquement avec une requête spécifique qui les demande, et
masquées automatiquement par l'API standard, sinon on n'évitera pas
une base de données séparée, car ces données peuvent être très
perturbantes pour plein d'outils. Il faudrait donc que l'API permette
de faire non pas une suppression simple, mais permette de transformer
un objet en objet historique, gardé par la base mais non accédé par
défaut.

L'autre problème à régler est l'intégrité référentielle (des membres
de relation ou des noeuds de chamin) si on masque ces données
historiques, et l'intégrité géométrique (si des noeuds ont été
déplacés sans être effacés ou gardés à part dans l'historiques sous un
ID différent, masqué par défaut).

Tout cela mériterait une réflexion générale sur le schéma et sur la
possibilité de le rendre compatible avec un déploiement employant des
bases de données parallèles (pour ne pas surcharger trop non plus la
base principale), et ne pas trop compliquer non plus le travail pour
les nouveaux contributeurs qui seront tentés de supprimer des objets
qui n'existent plus ou bien ne sont plus au même endroit.

La solution des versions d'objets n'est pas adaptée à ces usages pour
produire des cartes historiques. Je pense que cela devrait se faire
dans une base d'un projet séparé. Ce sera bien quand les éditeurs
sauront travailler sur plusieurs bases en même temps, dans des calques
séparés (sans fusion possible de l'un vers l'autre, uniquement des
copies d'une base vers l'autre mais pas nécessairement avec les mêmes
id's, mais avec une possibilité d'un objet d'une base de référencer
des objets d'une autre base via les ref:*=*).

Le 4 janvier 2013 15:06, François Lacombe
francois.laco...@telecom-bretagne.eu a écrit :
 Bonjour,

 Je suis plutôt pour conserver un historique en effet.

 Par contre non pas l’implanter dans les tags, il est possible d'utiliser les
 versions.
 Ces dernières ont déjà une dimension temporelle, plus temporelle que les
 tags par exemple.

 Le problème est qu'on ne sait pour l'instant pas si le passage d'une version
 à l'autre reflète une modification de la carte uniquement ou une édition
 suite à une modification du terrain.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

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

- pas de risque de confusion
- possibilité d'en avoir plusieurs car des changements il peut y en
avoir eu plus d'un !

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Le fait que ça n'ai pas été intégré dès le départ va forcément motiver pas
mal de modifications. Profitons-en.

Les versions correspondent peut-être à diverses modifications qui ne relève
pas d'un changement terrain, mais lorsqu'il y a changement terrain, il y a
une nouvelle version OSM et c'est ce qui compte.
Pour l'avoir déjà testé, un fonctionnement à 4 dates permet :
- de dater la version elle-même
- de dater l'objet qu'elle représente de manière différente (ces dates
peuvent ne pas évoluer d'une version à l'autre).

Utiliser les tags, même avec un suffixe, va compliquer les choses si on
veut des enregistrements sans les données historisées.
Les tags ne sont pas les seuls à être modifiés, les coordonnées d'un node
(par exemple) le peuvent également d’où l'impérieuse nécessité :) de placer
l'historisation au niveau de l'enregistrement (sa version).
Les tags restent un tableau à 2 dimensions, c'est peu évolutif comme
concept, la version l'est beaucoup plus.

Pour le soucis des liaisons, ça ne sera pas simple dans tous les cas.
- Si on utilise un identifiant invariant suivant la version (comme c'est le
cas sur OSM), l'intégrité n'est pas préservée.
- Si on utilise un identifiant unique par couple objet/version, chaque mise
à jour d'objet va être un casse-tête pour le répliquer dans les références
qui le pointent.

Je crois que c'est un thème abordé sur le Wiki de débat sur l'API 0.7 par
ailleurs.

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

 - pas de risque de confusion
 - possibilité d'en avoir plusieurs car des changements il peut y en
 avoir eu plus d'un !

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
*François Lacombe*
*Apprenti Ingénieur Télécom Bretagne*

francois dot lacombe At telecom-bretagne dot eu
+33 6 73 41 92 99

http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

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é.
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).

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.

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.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

2013-01-04 Par sujet Ista Pouss

Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit :


 Rappel:  name[:1970]=Place de l'Etoile


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.

Ce n'est pas impossible, mais je ne sens absolument pas OSM assez robuste
pour ça.

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.

Je passe le baton de parole au suivant.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

2013-01-04 Par sujet Vincent Pottier


Le 04/01/2013 16:24, Ista Pouss a écrit :
Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr 
mailto:cqu...@openstreetmap.fr a écrit :



Rappel:  name[:1970]=Place de l'Etoile


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.


Ce n'est pas impossible, mais je ne sens absolument pas OSM assez 
robuste pour ça.


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.


Je passe le baton de parole au suivant.
Un exemple (suivant ISO 8601 pour la notation des dates et intervalles) 
pour un POI :

shop:[1985/1999-07]=florist
name:[1985/1999-07]=Mille Fleurs
shop:[1999-08/2005-02-21]=butcher
name:[1999-08/2005-02-21]=L'entrecôte
shop=electronics
name=Fréquences
On voit trois états successifs du magasin. L'état actuel est supposé 
être celui par défaut, ne comprenant pas de date de validité.


Pour une ancienne commune, sur une relation :
boundary:[/2011]=administrative
name:[/2011]=Trifouilly-les-Oies
...
Dans l'état actuel, les valeurs ne sont plus valides

Cette formule reste compatible avec l'existant. Les outils lambda 
n'utiliseront pas les tags *:[*]

La limite, c'est les collisions du genre :
shop:[1985/1999-07]=florist
amenity=pub
En 1990, c'était déjà un bar ?

L'autre limite, c'est, dans le premier exemple, en 1980, la boutique 
était electronics, la valeur par défaut ?


Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette 
couche temporelle, genre openning_hours, mais je redoute que certains 
éditeurs, que je ne nommerai pas, aient du mal.

--
FrViPofm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

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:

Re: [OSM-talk-fr] Données historique et historiques des données...

Le 4 janvier 2013 17:02, Vincent Pottier vpott...@gmail.com a écrit :
 Un exemple (suivant ISO 8601 pour la notation des dates et intervalles) pour
 un POI :
 shop:[1985/1999-07]=florist
 name:[1985/1999-07]=Mille Fleurs
 shop:[1999-08/2005-02-21]=butcher
 name:[1999-08/2005-02-21]=L'entrecôte
 shop=electronics
 name=Fréquences
 On voit trois états successifs du magasin. L'état actuel est supposé être
 celui par défaut, ne comprenant pas de date de validité.

 Pour une ancienne commune, sur une relation :
 boundary:[/2011]=administrative
 name:[/2011]=Trifouilly-les-Oies
 ...
 Dans l'état actuel, les valeurs ne sont plus valides


Je ne connaissais pas la notation des intervalle ISO, ça me semble
plus propre comme ça.

tag:[intervalleISO]


 Cette formule reste compatible avec l'existant. Les outils lambda
 n'utiliseront pas les tags *:[*]
 La limite, c'est les collisions du genre :
 shop:[1985/1999-07]=florist
 amenity=pub
 En 1990, c'était déjà un bar ?


C'est pas parfait, mais c'est mieux que rien ;)


 L'autre limite, c'est, dans le premier exemple, en 1980, la boutique était
 electronics, la valeur par défaut ?


Dans ce cas j'aurai ajouté un shop:[/1985]=electronics

On devrait considérer que par défaut tag=xxx est équivalent à tag[plus
grande date/]=xxx


 Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette couche
 temporelle, genre openning_hours, mais je redoute que certains éditeurs,
 que je ne nommerai pas, aient du mal.

Tant que ça ne leur pose pas de problème, ils les ignorent un point c'est tout.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Ce formalisme serait-il requêtable en xquery ou même en SQL?

Le 4 janvier 2013 17:11, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 4 janvier 2013 17:02, Vincent Pottier vpott...@gmail.com a écrit :
  Un exemple (suivant ISO 8601 pour la notation des dates et intervalles)
 pour
  un POI :
  shop:[1985/1999-07]=florist
  name:[1985/1999-07]=Mille Fleurs
  shop:[1999-08/2005-02-21]=butcher
  name:[1999-08/2005-02-21]=L'entrecôte
  shop=electronics
  name=Fréquences
  On voit trois états successifs du magasin. L'état actuel est supposé être
  celui par défaut, ne comprenant pas de date de validité.
 
  Pour une ancienne commune, sur une relation :
  boundary:[/2011]=administrative
  name:[/2011]=Trifouilly-les-Oies
  ...
  Dans l'état actuel, les valeurs ne sont plus valides
 

 Je ne connaissais pas la notation des intervalle ISO, ça me semble
 plus propre comme ça.

 tag:[intervalleISO]


  Cette formule reste compatible avec l'existant. Les outils lambda
  n'utiliseront pas les tags *:[*]
  La limite, c'est les collisions du genre :
  shop:[1985/1999-07]=florist
  amenity=pub
  En 1990, c'était déjà un bar ?
 

 C'est pas parfait, mais c'est mieux que rien ;)


  L'autre limite, c'est, dans le premier exemple, en 1980, la boutique
 était
  electronics, la valeur par défaut ?
 

 Dans ce cas j'aurai ajouté un shop:[/1985]=electronics

 On devrait considérer que par défaut tag=xxx est équivalent à tag[plus
 grande date/]=xxx


  Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette
 couche
  temporelle, genre openning_hours, mais je redoute que certains
 éditeurs,
  que je ne nommerai pas, aient du mal.

 Tant que ça ne leur pose pas de problème, ils les ignorent un point c'est
 tout.

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

2013-01-04 Par sujet Emilie Laffray

Moui ce que tu exposes comme point est discute depuis des annees sans
reponses convenables.
Comme il a ete signale plus tot dans le fil de discussion, il faudrait
passer a une autre version de l'API au final car gerer 4 dimensions avec le
systeme actuel n'est tout simplement faisable.
De plus, je vois de gros risques d'augmentation de la complexite dans la
coherence des donnees si on ne fait pas gaffe.
Je suis pour un support des donnees historiques mais je suis convaincue que
ce n'est pas juste en passant un nouveau parametre comme tu le proposes que
l'on resoudra le probleme. Il y a deja eus des publications de chercheurs
utilisant une architecture OSM pour une juxtaposition mais tous concluent
que la structure n'est pas encore adaptee a cela.
Donc oui pour les donnees historiques, non au bidouillage. Il y a trop de
risques avec des problemes de conflation temporelles (nodes, ways comme
pour les rues, les rivieres) pour que l'on resolve cela aussi facilement.

Emilie Laffray


2013/1/4 Christian Quest cqu...@openstreetmap.fr

 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

 - pas de risque de confusion
 - possibilité d'en avoir plusieurs car des changements il peut y en
 avoir eu plus d'un !

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Le 4 janvier 2013 17:02, Christian Quest cqu...@openstreetmap.fr a écrit :
 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 ?
Oui

 au niveau du rendu ?

Non.

 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.

Non. Ce qu'on veut c'est juste un filtre par défaut qui ne retourne
pas ces objets historiques, partout (rendus, éditeurs), SAUF si on les
demande explicitement. Ainsi tout continue à tourner comme maintenant,
et il faudra faire des rendus avec des requêtes API spécifiques pour
afficher les historiques (à ces moteurs alors de faire le tri entre
les dates pour prendre en compte une date de validité).
Par défaut l'API ne retournerait que les objets qui sont dans la
période de validité actuelle. Il suffirait de faire une requête en
mentionnant une autre date qu'aujourd'hui, ou un intervalle de dates
pour avoir différentes versions, ou une requête mentionnant toutes
dates.
Bref un paramètre supplémentaire de requête optionnel du genre
dates=-mm-dd/-mm-dd (recherche dans un intervalle) ou
dates=-mm-dd (recherche à une date donnée) ou dates=* (toutes
les dates), la valeur par défaut étant dates=today
Bref on ne supprimerait plus rien dans la base, on changerait juste un
tag de dates de validité pour un objet, qui ensuite ne serait plus
accessible en référence à une date donnée. L'objet persiste dans la
base et reste accessible malgré tout si on le demande explicitement
avec son ID, mais n'est plus retourné par un téléchargement par zone.
Si l'objet est membre d'une relation, ou est un noeud membre d'un
chemin, le validateur peut encore vérifier la cohérence référencielle
en utilisant les dates de début et fin validité de chaque objet. Mais
pour la majorité des utilisations, on ne s'occupera plus de ce chemin,
et un éditeur en mode simple pourra aussi avoir un filtre n'affichant
que les membres d'une date donnée (par défaut la date actuelle), avec
unsélecteur de date pour le voir à une autre date.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

2013-01-04 Par sujet Pieren

Tout ce que vous suggérez (et plus encore) est présenté dans ce
slideshare montré au SOTM de ... 2009:
http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map

Bonne lecture,
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Bref c'est exactement ce que je proposais plus haut qui résoud tous
les problèmes, sauf que le slide suggère l'addition de champs
start_date/end_date pour chaque attribut, ce que je trouve plutôt
redondant, on peut très bien se débrouiller avec des objets distincts,
avec juste cette parire d'attributs pour une objet. Leur idée de dater
les attributs est que pour eux il s'agit du même objet (mais l'ennui
ce sont les références depuis un autre objet : il faudrait alors dater
chaque noeud inclus dans un chemin, et chaque membre d'une relation.

Il me semble plus propre de ne mettre qu'une paire par objet, pas pour
chacun de ses membres, et de considérer que ce sont des objets
différents, comme si c'était des couches d'une autre dimension :

- imaginons qu'une communauté de communes référence deux communes mais
que ces communes fusionnent
- on crée une nouvelle relation pour la nouvelle commune (même si elle
conserve le même nom et même numéro INSEE, mais probablement pas le
même numéro ref:SIREN=21depCOMx qui a des incidences comptables car
les comptes de chaque entité coexistent pendant un certain temps le
temps que les transferts de responsabilité et engagements financiers
ou contractuels se terminent).
- on crée une nouvelle relation pour la nouvelle communauté de
communes puisque ses membres ont changé et sa géométrie a pu changer
- les anciennes relations de la commune et de la communauté de
communes persistent mais on leur met une date de fin de
validité.L'ancienne communauté de commune continue de référencer
l'ancienne relation : la contrainte est que les membres de la relation
de communauté de communes doivent avoir des dates de validité
totalement incluses dans la période de validité de la communauté de
communes.

Le problème est : que faire quand il y a des incertitudes de dates, en
terme de validité référencielle ? Il faut une règle permettant une
tolérance.
Par exemple quand on a start_date=c1890 (circa 1890) dans une objet
référent, il s'agit d'une tolérance de l'ordre de la décennie, comme
si la date de début validité du référent commençait en 1895, 5 ans
plus tart (sans aller au delà de la date indiquée en end_date) ; dans
l'objet référé la date de début de validité c1890 est étendue 5 ans
plus tôt à partir de 1885, de sorte que la validité de l'objet
référent est entièrement incluse dans l'objet référencé. Toutefois un
validateur en mode strict fera un test de date sans tolérance et
affichera un warning pour vérifier si les dates sont compatibles.

Même chose si une date mentionne une décennies sous la forme start_date=1890s.

Si la date de début mentionne juste une année, on peut réduit la
tolérance à moins d'un an; si la date mentionne le mois, on réduit la
tolérance à moins d'un mois. Si la date mentionne le jour la tolérance
est de moins de quelques heures ; je ne suis pas sûr qu'il faille
prendre en compte les heures dans les champs date, mais le format
ISO8601 standard (-mm-ddThh:mi:ssZ) le permet.

Si l'incertitude de la date de début (ou de fin) est différente, on
pourrait encore avoir start_date=1890-02-28+7d pour préciser un
intervalle d'incertitude de plus ou moins 7 jours autour de cette date
(donc ici dans 14 jours ou 15 dates). start_date=1890+2y indiquerait
une tolérance de plus ou moins 2 ans avant ou après 1890.

L'autre solution étant de traduire directement cet intervalle de dates
en deux attributs donnant des dates précises si cela facilite les
requêtes SQL : start_date=1890-02-21..1892-03-07 et
start_date=1888..1892 pour les deux cas précédents.

Les incertitudes de dates peuvent exister pour la date de début comme
pour la date de fin de validité (les 4 dates sont alors en ordre
croissant ; la paire à utiliser pour les tests de référence sont de
prendre le plus plus grand intervalle des dates 1 et 4 pour l'objet
référencé, et le plus petit intervalle des dates 2 et 3 pour l'objet
référent).

Certes cela duplique les objets et les attributs, mais il est plus
simple de gérer l'intégrité référentielle au niveau de chaque objet
ayant un ID unique qu'avec un seul objet avec des attributs dont les
valeurs sont datés et deviennent des listes de valeurs. Mais des
solutions peuvent être développées pour les éditeurs qui veulent
vouloir pouvoir saisir un même objet avec des attributs (et membres de
relation) datés individuellement. Il est même possible de lier ces
objets à un objet maître liant les ID d'objets entre eux dans une
liste odonnée par date avec une relation spéciale de type history
comme une relation normale, sauf que les relations elles-mêmes ou
autres objets ne sont pas modifiés, il n'y a que la nouvelle relations
spéciale qui au lieu de contenir des listes d'objets quelconque
contient une liste d'ID d'objets avec chacun leurs intervalles de date
de validité au lieu du rôle (cette relation spéciale appliquant des
contraintes : les intervalles ne doivent avoir aucune intersection
hors des intervalles de tolérance).

Bref aucune modification du schéma des objets

Re: [OSM-talk-fr] Données historique et historiques des données...

Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au
niveau de la primitive plutôt que ses tags...
Le tags sont des données particulières de la primitive, gérer un historique
à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée
rattachée à l'objet.

Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable
et manipulable que d'avoir à parser des chaines de texte pour faire une
sélection.
La version a le mérite de relier logiquement plusieurs historiques du même
objet sans avoir à créer une liaison history justement.
Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec
plusieurs entiers nécessaires.

Ce qui m'interpelle aussi, c'est que la problématique du nombre
gigantesque d'enregistrements que cela va entrainer ressorte alors que
moult versions obsolètes (tant sur le terrain que pour d'éventuels reverts)
sont conservées par ailleurs.
D'expérience je créé des vues restreintes sur les enregistrements actuels
(plus peut-être à d'autres points de temps fortement fréquentés) pour
obtenir non seulement une vision actuelle et un accès direct aux
historiques.

Concernant les liaisons entre primitives, une référence aux objets logiques
(dont le numéro ne change jamais au cours du temps) consolidées par les
dates de part  d'autre pour connaitre la bonne version à utiliser
fonctionnerait.
Ceci à condition de restreindre la conservation d'un objet à sa stricte
existence... on revient à la question philosophique des slides.


Bon week end à tous.

Le 4 janvier 2013 19:41, Philippe Verdy verd...@wanadoo.fr a écrit :

 Bref c'est exactement ce que je proposais plus haut qui résoud tous
 les problèmes, sauf que le slide suggère l'addition de champs
 start_date/end_date pour chaque attribut, ce que je trouve plutôt
 redondant, on peut très bien se débrouiller avec des objets distincts,
 avec juste cette parire d'attributs pour une objet. Leur idée de dater
 les attributs est que pour eux il s'agit du même objet (mais l'ennui
 ce sont les références depuis un autre objet : il faudrait alors dater
 chaque noeud inclus dans un chemin, et chaque membre d'une relation.

 Il me semble plus propre de ne mettre qu'une paire par objet, pas pour
 chacun de ses membres, et de considérer que ce sont des objets
 différents, comme si c'était des couches d'une autre dimension :

 - imaginons qu'une communauté de communes référence deux communes mais
 que ces communes fusionnent
 - on crée une nouvelle relation pour la nouvelle commune (même si elle
 conserve le même nom et même numéro INSEE, mais probablement pas le
 même numéro ref:SIREN=21depCOMx qui a des incidences comptables car
 les comptes de chaque entité coexistent pendant un certain temps le
 temps que les transferts de responsabilité et engagements financiers
 ou contractuels se terminent).
 - on crée une nouvelle relation pour la nouvelle communauté de
 communes puisque ses membres ont changé et sa géométrie a pu changer
 - les anciennes relations de la commune et de la communauté de
 communes persistent mais on leur met une date de fin de
 validité.L'ancienne communauté de commune continue de référencer
 l'ancienne relation : la contrainte est que les membres de la relation
 de communauté de communes doivent avoir des dates de validité
 totalement incluses dans la période de validité de la communauté de
 communes.

 Le problème est : que faire quand il y a des incertitudes de dates, en
 terme de validité référencielle ? Il faut une règle permettant une
 tolérance.
 Par exemple quand on a start_date=c1890 (circa 1890) dans une objet
 référent, il s'agit d'une tolérance de l'ordre de la décennie, comme
 si la date de début validité du référent commençait en 1895, 5 ans
 plus tart (sans aller au delà de la date indiquée en end_date) ; dans
 l'objet référé la date de début de validité c1890 est étendue 5 ans
 plus tôt à partir de 1885, de sorte que la validité de l'objet
 référent est entièrement incluse dans l'objet référencé. Toutefois un
 validateur en mode strict fera un test de date sans tolérance et
 affichera un warning pour vérifier si les dates sont compatibles.

 Même chose si une date mentionne une décennies sous la forme
 start_date=1890s.

 Si la date de début mentionne juste une année, on peut réduit la
 tolérance à moins d'un an; si la date mentionne le mois, on réduit la
 tolérance à moins d'un mois. Si la date mentionne le jour la tolérance
 est de moins de quelques heures ; je ne suis pas sûr qu'il faille
 prendre en compte les heures dans les champs date, mais le format
 ISO8601 standard (-mm-ddThh:mi:ssZ) le permet.

 Si l'incertitude de la date de début (ou de fin) est différente, on
 pourrait encore avoir start_date=1890-02-28+7d pour préciser un
 intervalle d'incertitude de plus ou moins 7 jours autour de cette date
 (donc ici dans 14 jours ou 15 dates). start_date=1890+2y indiquerait
 une tolérance de plus ou moins 2 ans avant ou après 1890.

 L'autre solution étant de

Re: [OSM-talk-fr] Données historique et historiques des données...

2013-01-04 Par sujet Ista Pouss

En vrac :

Pour la notation du temps l'ISO 8601 est la moins mauvaise solution
informatique, mais c'est une bombe à retardement culturelle. Comme elle est
basée sur un calendrier catholique, je vous fais pas de dessin.

Que l'on dise Ce n'est pas vraiment l'historique de l'objet que je cherche
à avoir, mais un moyen minimal de
noter des informations passées liées à un objet... ne fait que reculer
pour mieux sauter : tant que t'as pas l'objet, tu mets des dates sur du
vent. Impossible de justifier l'info. Avec l'historique, le terrain a
disparu. L'historique impose la justification des sources, et je ne vois
rien dans tes tags qui marque la justification des sources, et je ne vois
rien qui marque l'objet dont les sources parlent.

Après... il faut bien avancer, et il est rare qu'on avance en gardant
l'équilibre. Let's go[2013-01-01T20:47+01:00].



Le 4 janvier 2013 19:41, Tout le monde a écrit :

 Bref c'est exactement ce que je proposais plus haut qui résoud tous

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

A mon avis la création d'une version historique ne va pas entrainer
une profusion de données. Le plus gros des modifs de versions est dans
la branche principale (celle de la version actuelle, et cela restera
celle qui sera le plus contribuée. A un instant donnée on ne crée un
objet historique que pour conserver une de ces versions à peu près
stable. D'autant plus qu'on peut faire en sorte que l'éditeur par
défaut ne charge pas ces objets historiques sauf si on en fait la
demande explicitement.

Je suis d'accord avec toi que mettre cela dans des tags standards
n'est pas la bonne solution et qu'il vaut mieux une primitive séparée
pour créer une méta-relation listant les objets liés à un même
intervalle historique daté. Un même id d'objet ne doit servir qu'à un
seul intervalle de validité de date, cet objet pouvant être chargé ou
pas (mais pas par défaut par l'API quant on ne précise pas une date de
validité ou qu'on ne précise pas un intervalle de date à rechercher ou
pas de requête pour charger toutes les dates.

Ce sera d'autant plus important que pour les versions historiques, se
posera la question des sources différentes, et de droits intellectuels
distincts, des problèmes de licences distinctes.

Imaginons ensuite qu'on veuille créer une nouvelle version historique
d'un objet actuel pour en garder une archive datée, on devrait avoir
un bouton permettant d'ajouter cette version en mentionnant seulement
la date de fin de l'objet actuel et de début du nouvel objet. Les deux
objets sont alors soumis au serveur. L'ancien objet change de statut
(il est modifié) ce qui oblige les autres éditeurs à en tenir compte
comme une modif puisque l'ancien objet sera versionné comme une modif
standard. Mais il deviendra invisible ensuite pour ceux qui chargent
les objets référents ou la zone : ils obtiendront le nouvel objet à la
place, mais en chargeant l'objet, le serveur peut aussi indiquer que
cet objet dispose de versions datées différentes et permettre
d'effectuer une requête pour charger ces autres versions datées à la
demande.

Dans JOSM on aurait alors en dessous de la liste des attributs ou
membres une autre liste en table mentionnant une liste d'autres IDs
d'objets de même nature de primitive (noeud/chemin/relation), avec 3
colonnes : ID des autres objets, date de début, date de fin, cette
liste étant ordonnée et mettant en gras la version actuelle dont les
attributs et membres sont affichés. Si on clique une des lignes de
cette table, on sélectionne le nouvel objet. On doit aussi pouvoir
sélectionner plusieurs lignes pour effectuer ou pas des fusions
d'attributs ou membres communs.

Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car
ils sont ordonnés et connectés : il peut y avoir des noeuds communs
entre deux versions d'un chemin, ou bien tous les noeuds différents,
ou tous identiques, les chemins ne différent que par les attributs
voire sans aucune autre différence que les dates de validité (par
exemple quand deux anciens chemin pour une zone ont été fusionnés puis
rescindés à nouveau, ou quand une ligne de transport est aménagée
pendant un certain temps différemment, puis restaurée à son ancien
état, ou quand deux communes fusionnent pendant un certain temps puis
se reséparent, la commune ayant cessé d'exister de façon autonome
pendant une période donnée ; cependant je pense qu'il sera rare que la
restauration soit totalement à l'identique, sauf si la version
intermédiaire n'était que temporaire pour durer que quelques mois ou
moins de 2 ou 3 ans ; mais là tout est possible, et il est probable
que l'ancienne version ne corresponde pas exactement à ce qu(on trouve
à l'heure actuelle et que celle-ci de toute façon conservera un ID
séparé demandant des corrections et contributions distinctes à ne pas
apporter à la version actuelle).

Il est aussi très probable que les anciennes versions n'aient pas le
niveau de précision géométrique des versions actuelles : la Terre
bouge, les rivières bougent, les terrains bougent, il y a des
inondations, des glissements de terrain, des arrangements légaux pour
certaines parties, des échanges de parcelles qui ne feront pas l'objet
de retour en arrière.

Le 4 janvier 2013 20:55, François Lacombe
francois.laco...@telecom-bretagne.eu a écrit :
 Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au
 niveau de la primitive plutôt que ses tags...
 Le tags sont des données particulières de la primitive, gérer un historique
 à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée
 rattachée à l'objet.

 Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable
 et manipulable que d'avoir à parser des chaines de texte pour faire une
 sélection.
 La version a le mérite de relier logiquement plusieurs historiques du même
 objet sans avoir à créer une liaison history justement.
 Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec
 plusieurs entiers nécessaires.

 Ce qui m'interpelle aussi,

Re: [OSM-talk-fr] Données historique et historiques des données...

On a l'air d'être sur une longueur d'onde plus commune :)

Cependant, et ca doit aller dans le sens d'Ista Pouss, il faut trouver une
solution générale et reproductible à de multiples situations.
Pour toute primitive, hormis les champs id, version, changeset, user,
éventuellement les dates, tout n'est que donnée. Si il y a une modification
= une nouvelle version est créée.
Il faut partir de là et ne pas prendre les tags pour ce qu'ils ne sont pas.
Les sources, les noms, comme les informations terrain, restent des données
pour la base et l'API. Il n'y a pas de raison d'établir des critères dessus
pour gérer non seulement les versions et par extension le système
d'historique.
Un objet (chaque version d'une primitive) est atomique et on ne peut pas le
morceler. Sinon on ne peut pas s'assurer correctement de l'intégrité et de
la requêtabilité du bazar.

Si le système est suffisamment général, qui peut le plus peut le moins, on
pourra adopter certains fonctionnements qui sont propres aux cas
particuliers soulevés ici.
Sinon ca va marcher, mais il faudra faire de constantes adaptations pour
aller toujours plus loin dans le détail (vu le potentiel d'une communauté
comme celle d'OSM).

Et quelque chose de tout à fait intéressant dans ce que dit Philippe est
que lorsque l'on prononce l'archivage d'un objet, toutes les versions
intermédiaires qui le constituent jusque là sont regroupées en une seule
(ça a sa limite : un tel archivage ne peut pas être annulé au delà de la
dernière version connue).

Enfin c'est ma vision des choses, j'ai implémenté un tel système
directement sous la forme d'un ORM et certaines de ces problématiques se
sont présentées.
La leçon que j'en tire c'est qu'il faut s'abstenir de donner aux champs un
sens particulier. Il en faut un minimum (id, changeset, version...) et
gérer le reste de manière transparente.

Un petit exemple avec ça :
http://www.infos-reseaux.com/apps/ADSLObs/dataPLayout/props/com.infosReseaux.common.networks.IPNode/?obj_id=24314

Pour les dates j'aime bien les timestamp unix en secondes. Ca permet de
traiter des entiers plutôt que des chaines de texte mais après c'est très
personnel.

Le 4 janvier 2013 22:26, Philippe Verdy verd...@wanadoo.fr a écrit :

A mon avis la création d'une version historique ne va pas entrainer
une profusion de données. Le plus gros des modifs de versions est dans
la branche principale (celle de la version actuelle, et cela restera
celle qui sera le plus contribuée. A un instant donnée on ne crée un
objet historique que pour conserver une de ces versions à peu près
stable. D'autant plus qu'on peut faire en sorte que l'éditeur par
défaut ne charge pas ces objets historiques sauf si on en fait la
demande explicitement.

Je suis d'accord avec toi que mettre cela dans des tags standards
n'est pas la bonne solution et qu'il vaut mieux une primitive séparée
pour créer une méta-relation listant les objets liés à un même
intervalle historique daté. Un même id d'objet ne doit servir qu'à un
seul intervalle de validité de date, cet objet pouvant être chargé ou
pas (mais pas par défaut par l'API quant on ne précise pas une date de
validité ou qu'on ne précise pas un intervalle de date à rechercher ou
pas de requête pour charger toutes les dates.

Ce sera d'autant plus important que pour les versions historiques, se
posera la question des sources différentes, et de droits intellectuels
distincts, des problèmes de licences distinctes.

Imaginons ensuite qu'on veuille créer une nouvelle version historique
d'un objet actuel pour en garder une archive datée, on devrait avoir
un bouton permettant d'ajouter cette version en mentionnant seulement
la date de fin de l'objet actuel et de début du nouvel objet. Les deux
objets sont alors soumis au serveur. L'ancien objet change de statut
(il est modifié) ce qui oblige les autres éditeurs à en tenir compte
comme une modif puisque l'ancien objet sera versionné comme une modif
standard. Mais il deviendra invisible ensuite pour ceux qui chargent
les objets référents ou la zone : ils obtiendront le nouvel objet à la
place, mais en chargeant l'objet, le serveur peut aussi indiquer que
cet objet dispose de versions datées différentes et permettre
d'effectuer une requête pour charger ces autres versions datées à la
demande.

Dans JOSM on aurait alors en dessous de la liste des attributs ou
membres une autre liste en table mentionnant une liste d'autres IDs
d'objets de même nature de primitive (noeud/chemin/relation), avec 3
colonnes : ID des autres objets, date de début, date de fin, cette
liste étant ordonnée et mettant en gras la version actuelle dont les
attributs et membres sont affichés. Si on clique une des lignes de
cette table, on sélectionne le nouvel objet. On doit aussi pouvoir
sélectionner plusieurs lignes pour effectuer ou pas des fusions
d'attributs ou membres communs.

Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car
ils sont ordonnés et connectés

Re: [OSM-talk-fr] Données historique et historiques des données...

On dérive (comme les continents, on va bientôt en parler)... c'est
intéressant de pousser les concepts à leur limite, mais si on pouvait
identifier des cas simples qu'on peut gérer avec des solutions simples
ça serait déjà pas mal, non ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...