Bonjour,
Le 05/01/2013 00:51, François Lacombe a écrit :
Je ne connais pas les cas simples, juste des cas particuliers.
On peut faire un truc simple pour commencer qui sera possiblement une
véritable horreur à intégrer à la prochaine itération en plus de ne
concerner qu'un nombre restreint de
Le 5 janvier 2013 10:47, Vincent de Chateau-Thierry v...@laposte.net a
écrit :
Bien que spectateur sur ce fil, je rejoins Christian là-dessus : pour
partager vos raisonnements, il doit y avoir moyen de les illustrer par des
scenarios sur des objets typiques, comme ceux déjà énumérés dans le
Bonjour,
D'une manière générale, je ne suis pas vraiment convaincu de l'utilité
d'avoir des données historique. Pour le moment, on a encore assez de
problème à résoudre pour la représentation du présent. Le passé peut
attendre, surtout que la dimension temporelle est un vrai casse tête. Seul
une
Le 5 janvier 2013 17:32, Black Myst black.m...@free.fr a écrit :
Bonjour,
D'une manière générale, je ne suis pas vraiment convaincu de l'utilité
d'avoir des données historique. Pour le moment, on a encore assez de
problème à résoudre pour la représentation du présent. Le passé peut
attendre,
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
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
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.
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 ?
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
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 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
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
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
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
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
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
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
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
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
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
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
à
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
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
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
Je ne connais pas les cas simples, juste des cas particuliers.
On peut faire un truc simple pour commencer qui sera possiblement une
véritable horreur à intégrer à la prochaine itération en plus de ne
concerner qu'un nombre restreint de situations.
Après je ne fais pas (encore, qui sait) parti
Je dévie le fil vers une notion d'historique...
Il y a une réflexion actuelle sur l'intégration de données historiques
dans OSM, une liste dédiée a même été créée (historic).
Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en
garder au moins une trace ?
J'ai une ébauche de
Le 3 janvier 2013 11:50, Christian Quest cqu...@openstreetmap.fr a écrit :
Qu'en pensez-vous ?
Je subodore que le problème sera la source, ou la référence, de la donnée.
La référence actuelle que j'ai comprise de osm est le terrain : c'est ce
que l'on voit. Il y a déjà quelques exceptions,
Techniquement, il doit être possible de reconstruire ce qui a été
effacé (tant que ce n'est pas le bot redaction qui l'a mangé), non ?
La relation que je viens d'effacer reste dans la base par exemple :
http://api.openstreetmap.org/api/0.6/relation/154958/history
Par contre il faut que les
De : Christian Quest
Je dévie le fil vers une notion d'historique...
Il y a une réflexion actuelle sur l'intégration de données historiques
dans OSM, une liste dédiée a même été créée (historic).
Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en
garder au moins une
Le 3 janvier 2013 13:15, Vincent de Chateau-Thierry v...@laposte.net a écrit :
De : Christian Quest
Je dévie le fil vers une notion d'historique...
Il y a une réflexion actuelle sur l'intégration de données historiques
dans OSM, une liste dédiée a même été créée (historic).
Plutôt que de
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
31 matches
Mail list logo
