Sauf que si on veut tout mettre dans un unique tag fourre-tout, on tombera
sur des conflits d'usage. Le fait est que ce sont des identifiants de bases
externes spécifiques et distinctes et que si on les admet dans OSM, if faut
eviter les collisions.
Le fait est que "Tony Emery" a véhément commenté le fait que'une poignée de
ces identifiants externes privés soient supprimés (mais ils n'étaient même
pas expliqués à cette heure-là)
S'il est aussi insistant pour qu'on les garde, il doit avoir un solution
péreine qui ne provoquera pas de conflit avec les autres usages dans
d'autres bases externes privées.
Je ne vois pas à quel titre la base interne de quelques communes serait
prioritaire sur celles des communes voisines qui n'y participent pas et ont
leurs autres besoins. Et pourquoi pas alors les bases d'autre chose que les
communes ?
Par exemple
les départements et régions, les assos sportives (cyclistes,
randonneurs...),
la sécurité civile/les pompiers, la gendarmerie et la défense,
les parcs naturels, les agences de bassin (identification des ouvrages
impactant l'écoulement des eaux),
et diverses autres agences des divers ministères de l'Etat ou des
collectivités,
ou bien les bases qui leur servent pour échanger des informations
d'identification avec les fournisseurs
et attributaires de concessions publiques (exploitants de réseaux :
énergie, télécoms, assainissement, transport...)
Combien de références externes à des bases privées peut-on admettre dans
OSM (j'insiste elles sont privées par rapport à OSM, même si elles sont
maintenues par des organismes publics pour leur usage théoriquement
*interne*)?
Tony semble dire que ces identifiants sont *essentiels* à ses propres
besoins dans le cadre de son travail local avec les collectivités. Mais en
fait hormis lui, je void mal comment les autres peuvent même utiliser ces
identifiants et même s'y fier puisqu'ils sont invérifiables.
Il me semble donc que dans OSM on ne doit mettre que des références à des
bases externes qui sont au minimum consultables (à défaut d'être ouvertes
en opendata) et maintenues (ce qu'on n'a aucun moyen de savoir, sauf Tony
dans son coin et son travail actuel qui lui donne accès à ces données
internes).
Alors là oui, on peut mettre des références à ces bases externes et pour
chacune lui attribuer un tag spécifique. Il n'y aura jamais aucun problème
alors pour faire le lien entre les deux bases même si les tags "ref:XXXXX"
se multiplient (en fait il y en aura peu par objet, ils serontg utilisés
chacun dans des zones qui se recouvrent peu. Donc aucun risque d'explosion,
ni aucun risque de conflit en cas de recouvrement.
Mais un "ref:local=*" fourre-tout ne peut pas être stable : pas moyen de
savoir d'où ça vient, qui le maintient, et si la donnée est encore
pertinente. Et "Tony" va encore une fois râler si plus tard quelqu'un
écrase la donnée qui, pour lui seulement, lui parait "essentielle "à son
utilisation d'OSM, alors qu'un autre utilisateur voudra le justifier par sa
propre utilisation toute aussi essentielle pour lui !
Si c'est si essentiel pour lui, il faut qu'il obtienne un consensus, ce qui
ne sera pas possible si la base externe reste privée (et malgré même ses
propres efforts pour tenter de le documenter, pour tout le monde ces
identifiants sont inutilisables) Alors oui, il faut que Tony décrive
correctement cette base externe, lui donne un périmètre d'usage (son idée
de permettre de le réutiliser ailleurs sonne le glas de sa propre idée que
le tag est essentiel pour lui, car les autres tomberont forcément en
conflit et ne voudront pas s'adapter non plus pour utiliser dans leur base
seulement les identifiants non sourçables fournis par Tomy).
Et donc qu'il donne un nom à cette base, un point de contact pour la
maintenance, la vérification ou les recherches, un système décrivant ses
modes de mises à jour, et même sans doute une URL vers une page de
livraison de son catalogue de données (même si pour y accéder complètement
il faut s'acquitter d'un droit d'accès et d'une licence, ou appartenir à un
groupe assez large de personnes pouvant accéder gratuitement et facilement
à cette base externe, et qui incluerait assez d'autres utilsiateurs d'OSM).
Tomy ne peut pas rester le seul point de contact possible.
C'est passé inaperçu par lui pour l'instant mais Tomy n'a jamais voulu
répondre au sujet de ma question du statut de cette base qui visiblement
n'est pas OpenData (et sans doute ne le sera pas, et en tout cas pas sous
la forme où Tomy l'utilise et la croise avec OSM pour le projet qu'il dit
"essentiel" pour lui). plus tard Tomy a ajouté "nous", mais on ne sait
toujours pas qui sont les autres qui ne se manifestent pas ici (s'il y a
d'autres espaces publics où sont présents les "nous", ce serait bien de le
mentionner). Si on ne le sait pas c'est que justement leur utilisation
reste elle aussi privée et ils ne veulent pas dévoiler leur activité et ne
veulent pas la mêler avec OSM qui interférerait dans leur propre travail
(question de responsabilité).
==========================================
Bref:
==========================================
- Comment s'appelle cette base externe ?
- Tomy peut-il en préciser le périmètre où elle est maintenue et où son tag
dans OSM sera "essentiel" ?
- Est-il le seul contact dont on dispose pour interagir avec cette base
externe ?
- Si Tomy change de boulot ou nous quitte définitivement et n'a plus accès
à cette base, comment pourra-t-on savoir quoi faire de ces identifiants
"essentiels" mais toujours aussi inutilisables ?
S'il peut répondre à ces questions de base, alors le nom et le périmètre de
cette base peut justifier pour elle un tag spécifique. Sinon ce n'est pas à
OSM de stocker son tag et Tomy devra faire son rapprochement dans l'autre
sens, en se basant sur les identifiants qu'on a (Rivoli/FANTOIR) et des
autres tags descriptifs ainsi que de la localisation pour repérer les
objets qui sont en interne sans sa base privée. C'est plus à lui de
s'adapter à OSM, qu'à OSM de s'adapter à lui.
==========================================
C'est à lui que revient de développer, pour son propre usage, ses propres
outils de rapprochement (quitte pour cela à ce que Tomy crée sa propre base
annexe de rapprochement pour idenifier les versions d'objets OSM déjà
rapprochés, et ceux qui sont nouveaux ou modifiés dans OSM.
A lui de voir s'il utilisera alors les données d'OSM, ou s'il juge que'OSM
a une précision insiffisante, de faire des améliorations de géométrie dans
OSM lui facilitant son travail, ou corriger la géométrie stockée dans sa
base (mais alors c'est qu'il importe des données ouvertes d'OSM dans sa
base privée : sa base ne peut que rester privée, ou s'il est jamais
publiée, elle DEVRA l'être sous une licence compatible avec l'OdBL
(puisqu'alors sa base privée contiendra des données dérivées d'OSM et de
ses autres fournisseurs de données ouvertes).
Mais là je doute qu'il puisse même seulement en décider tout seul et même
si en le faisant il prendrait une responsabilité contraire à ses propres
obligations professionnelles ou contractuelles : il n'est en fait pas
titulaires des droits nécessaires et ne peut pas en décider, il lui faut
d'abord l'accord de son tiers.
Le 11 février 2015 23:30, Vincent de Château-Thierry <v...@laposte.net> a
écrit :
> Bonsoir,
>
> Le 11/02/2015 16:28, Philippe Verdy a écrit :
>
>>
>> Mais en fin de compte puisque ton identifiant utilise un numéro Insee de
>> commune française qui en est à la source,
>> - pourquoi pas "ref:FR:xxxxx = Vnnnnnn", où xxxxx est le code commune à
>> 5 chiffres ?
>> - ou bien ref:FR:xxxxxxxxx=Vnnnnnnn", où "xxxxxxxxx" est le code SIREN
>> de l'entité qui l'a défini,
>> - ou bien "ref:FR-dd:CCXXX = *" où "CCXXX" est l'abréviation en lettres
>> de l'EPCI et dd est le numéro de département de sa commune siège (donc
>> "ref;FR-87:CCPRO = *" pour ta communauté de communes, puisque "FR-dd"
>> est un code ISO 3166 valide comme l'est aussi "FR").
>>
>> Au moins avec ref:FR=* on sait que c'est discuté en France, et documenté
>> en français (pas sûr pour autant que nos amis belges ou canadiens nous
>> ait suivi adns le détail,
>>
>
> Allez, soyons fous : un des schemas ci-dessus emporte l'adhésion, et est
> massivement propagé. On se retrouve avec, disons, une centaine de
> collectivités qui l'adoptent. Résultat, une centaine de tags
> ref:FR:<identifiant de la collectivité> distincts, stockant chacun des
> valeurs pour la même notion : un identifiant unique.
> Et maintenant, un consommateur de données OSM veut appréhender ces données
> à l'échelle de la France, en exploitant ces identifiants, par exemple pour
> les afficher sur une carte. Donc une centaine de colonnes distinctes dans
> une BD, rien que pour récupérer toutes les valeurs des différents
> émetteurs. Des colonnes vides à 99% évidemment, puisque chacune n'est
> utilisée que sur un tout petit périmètre géographique.
> Tout ça fait une donnée très pénible à exploiter, car explosée
> artificiellement dans différents tags (osm) ou colonnes (de BD
> relationnelle). Vous voulez faire des stats ? Accrochez-vous...
>
> En bref : je suis contre les noms de tags à composante géographique à une
> maille aussi fine qu'une collectivité territoriale. Pour moi on ne devrait
> pas descendre en dessous du pays dans les espaces de nom, donc ref:FR ici.
> Et, ça a été rappelé par Fred, un simple tag local_ref permettrait souvent
> de s'en sortir.
>
> KISS*, comme disait l'autre.
>
> vincent
>
> * http://fr.wikipedia.org/wiki/Principe_KISS
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
