<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Le 16/11/2010 19:25, sly (sylvain letuffe) a écrit :
<blockquote cite="mid:201011161925.28383.sylvain@letuffe.org"
type="cite">
<meta name="qrichtext" content="1">
<p>Tu as tout à fait raison, aujourd'hui on est un peu obligé de
passer par des bidouilles, genre source:name= source2= source=X+Y+Z,
des relations pour que chaque way puisse être découpé et ainsi marquer
sa source.</p>
<p> </p>
<p>Mais cela vient en partie de la mauvaise gestion des tags de
changeset par les éditeurs courants, mais en partie seulement je pense :</p>
</blockquote>
<br>
Depuis quand un changeset devrait indiquer qu'on a travaillé 12 noeuds
avec le cadastre, 5 ways avec Corine, modifié 2 relations avec Yahoo ?<br>
J'en étais resté au descriptif du changeset censé dire la nature du
travail accompli dans ledit "commit". Chacun a des pratiques assez
rigolotes dans le domaine.<br>
<blockquote cite="mid:201011161925.28383.sylvain@letuffe.org"
type="cite">...</blockquote>
Je ne sais pas si c'est moi qui n'arrive plus à comprendre, si c'est
les pratiques qui évoluent trop vite où si l'on en confond pas : <br>
- source de l'objet<br>
- tags du changeset<br>
- analyse de l'historique de l'objet<br>
<blockquote cite="mid:201011161925.28383.sylvain@letuffe.org"
type="cite">
<p>Idéalement, peut-être, il faudrait un système de métadonnée ou il
serait possible par exemple d'ajouter à chaque objet les différentes
sources et origine de constitution qui ont servi durant la vie de
l'objet, genre source1, puis source2, ... comme tag sur chaque objet
mais d'une manière moins manuelle (interface qui permet : tous ce que
je viens de faire à pour source Y, et tout ce que je vais faire à pour
source X) et moins bidouillesque</p>
</blockquote>
Voilà qui parle à ma fibre de documentaliste !<br>
Toutefois, et ce n'est pas pour décourager, mais il existe des normes
de métadonnées géographiques (ISO 19115/19139 +19110 et autres profils
inspiro-compatibles pour les intimes), mais elles sont tellement
touffues que beaucoup rechignent à rentrer dans un niveau de
description aussi fin.<br>
Ce dont tu parles est parfaitement décrit par la norme dans le
chapitre, je n'invente rien, Data Quality (DQ_Lineage, DQ_Process, etc.)<br>
Je ne peux m'empêcher de repenser au document de Serge Mang sur la
qualité des données OSM et de sa nécessaire évaluation. Cette
évaluation peut se faire (au moins) de 2 manières complémentaires :<br>
- une analyse fine des changesets : pas pour les tags qu'ils
contiennent mais pour le delta des données touchées (géométrie +
sémantique) et leurs sources éventuellement différentes<br>
- une description de l'origine des nouvelles données produites à
l'instant t<br>
<br>
La prise de conscience de la nécessité de saisir des métadonnées au
niveau le plus adapté naît de l'incertitude de ne pas pouvoir utiliser
la donnée elle-même (casquette d'utilisateur) et de la tentative d'en
faire une nouvelle jugée "meilleure" (casquette de producteur).
L'outillage suivra.<br>
<br>
C'est un débat qui a déjà eu lieu, il me semble<br>
<br>
Denis, meta au travail<br>
</body>
</html>