Pas tant que ça !
C'est encore un exemple que montre que les ID non-obscures ne sont pas une
bonne valeur pour un UID.
Et donc qu'il faudra bien une génération d'UID et pas l'utilisation d'un
UID d'un référentiel existant (que ce soit celui de la municipalité à la
source des données ou toute
C'est exactement ce que j'ai dit : ta SARL en déménageant n'a pas changé
d'identité légale, son SIREN n'a pas changé seul le SIRET (établissement) a
changé.
L'autre cas existe aussi où plusieurs entités légales distinctes
(différents SIREN) coexistent au même endroit, leurs salariés n'étant pas
Le 18 avril 2013 03:50, Philippe Verdy verd...@wanadoo.fr a écrit :
Le 17 avril 2013 08:50, Christian Quest cqu...@openstreetmap.fr a écrit
:
A mon avis *on* diverge encore...
L'idée de départ, ce sont des id stables permettant la mise en place de
liens VERS les données OSM, pour éviter
Pfff Franchement le fil des réponses indiquait qu'on faisait une
réponse à mes remarques.
Maintenant si tu ne veux pas lire c'est ton problème, alors que cette
discussion contient plein d'autres messages assez longs car il y a beaucoup
d'arguments pour et contre.
Le 18 avril 2013 10:07,
Le mer. 17 avril 2013 à 13:17 +0200, Pieren a écrit :
2013/4/17 Ista Pouss ista...@gmail.com
Il garantit que l'URL qu'il donne restera toujours la même, tant que
l'objet satisfait les critères de reconnaissance.
C'est un peu vague tout ça. Personne n'est capable de dire ce que sont ces
Le mer. 17 avril 2013 à 19:06 +0200, Christian Quest a écrit :
#a4u2k9 dans mon exemple est un geohash... il correspond à une bbox
qui est de plus en plus petite lorsque le geohash est long (et
inversement). C'est un truc existant qui est même supporté en interne
par postgis (ST_GeoHash).
Non, le SIREN change aussi : il désigne l'identité, la raison sociale. LE
code établissement sert pour les sociétés qui ont une série
d'établissements dans des lieux différents.
Bien des commerces toutefois sont des franchises, à l'identité du franchisé
(la plupart du temps une petite SARL ou une
En revanche ni le SIREN ni le SIRET change si un commerce quitte sa
franchise pour prendre une enseigne d'une autre franchise (qui peut au
passage complètement changer la nature du commerce en terme de services).
L'enseigne est en général propriété du franchiseur, le franchisé la loue.
Dans un
Autre cas : il peut y avoir plusieurs SIREN (plusieurs identités légales)
au sein d'un même lieu (donc nécessairement des SIRET différents aussi même
si on ne peut pas distinguer géographiquement les établissements) sans
qu'on puisse les séparer. Le cas est courant dans les sociétés de service
2013/4/18 Guillaume Allegre allegre.guilla...@free.fr
Je ne sais pas quoi en faire dans OSM, mais au moins n'essayez pas de
réinventer un
référentiel qui existe déjà.
La boulangerie était citée en exemple. Il faut évidemment que le système
fonctionne avec n'importe quel tag ou combinaison de
Le jeu. 18 avril 2013 à 12:02 +0200, Philippe Verdy a écrit :
Non, le SIREN change aussi : il désigne l'identité, la raison sociale. LE
code établissement sert pour les sociétés qui ont une série
d'établissements dans des lieux différents.
Non. Je maintiens, je l'ai vécu en 2007. Ma SARL a
Le SIRET correspond au SIREN + un numéro d'ordre (et le chiffre de contrôle).
A chaque nouvel établissement (adresse mais aussi activité différente
à ce qu'il me semble) un nouveau SIRET est attribué avec le numéro
d'ordre suivant.
Le SIREN identifie une entreprise, il ne change pas tant que
A mon avis on diverge encore...
L'idée de départ, ce sont des id stables permettant la mise en place de
liens VERS les données OSM, pour éviter de multiplier les ref:xx partant
dans tout les sens et souvent en cul de sac (pas d'accès à des données
complémentaires derrière).
Enfin, c'est mon
cquest wrote
A mon avis on diverge encore...
L'idée de départ, ce sont des id stables permettant la mise en place de
liens VERS les données OSM, pour éviter de multiplier les ref:xx partant
dans tout les sens et souvent en cul de sac (pas d'accès à des données
complémentaires derrière).
Le 17 avril 2013 08:50, Christian Quest cqu...@openstreetmap.fr a écrit :
A mon avis on diverge encore...
L'idée de départ, ce sont des id stables permettant la mise en place de
liens VERS les données OSM, pour éviter de multiplier les ref:xx partant
dans tout les sens et souvent en cul de
Le mar. 16 avril 2013 à 09:47 +0200, Christian Quest a écrit :
Je pense par exemple à:
- Jean-Louis qui veut garder une liste des commerces et leur correspondance
dans OSM,
Ben il publie sa liste (opendata) sur le site de sa ville / comcom
(éventuellement expurgée de certaines informations si
Le mar. 16 avril 2013 à 10:20 +0200, JB a écrit :
Mon tout petit grain de sel à cette discussion que je suis comme une
« curiosité ». Je rajouterais dans les usages : et pas une accumulation
de tags ésotériques qui ne disent rien aux débutants… et mêmes moins
débutants.
Du coup, pour
2013/4/16 Guillaume Allegre allegre.guilla...@free.fr
Pour moi la pollution est quand même super légère (qui la voit ?).
Et en partant du double principe :
- un tag que je ne comprends pas, je n'y touche pas ;
- si je veux comprendre, c'est documenté dans le wiki
on règle le problème.
On
Bonjour,
Je me permets de repartir de ce message pour élever le débat. AMHA vous
partez trop vite dans les détails techniques et devez revenir à des
concepts plus stratosphériques.
J'ai créé une page dans le Wiki pour libérer cette liste de diffusion, mais
vous êtes libres, n'est-ce pas ?
Je m'excuse de revenir encore dessus mais certaines collectivités gèrent des
référentiels adresses réalisés en interne et je les vois mal ne pas avoir
créer d'identifiant interne pour leurs voies.
L'avantage est que, les collectivités étant la source principale des
données, on peut plus s'appuyer
Pas de problème, j'ai bien noté ce point de vue, mais je ne le partage
simplement pas, bien amicalement :-)
Je comprends que les différentes administrations aient leurs UID locaux,
mais je considère, peut être à tord, que OSM *est le référentiel* et que
c'est à ce référentiel de produire un UID
2013/4/16 Marc SIBERT m...@sibert.fr
Je comprends que les différentes administrations aient leurs UID locaux,
mais je considère, peut être à tord, que OSM *est le référentiel*
Ouch, je m'étrangle à chaque fois que je lis ou entends ça. OSM ne peut pas
être un référentiel pour la simple
Oh ! Là ! faut pas se faire de mal à la gorge pour un terme.
Je parle ici de fonctions d'un composant d'un SI(G). Je ne qualifie pas
OSM par rapport à la valeur de ses données.
Je dis juste que OSM *est le référentiel* du Système d'Informations
Géographique libre qui tourne autour... par
Encore une fois je suis plutôt de l'avis de Tony que de toi Marc sur ce
point:
si la référence et l'origine des noms de voie, et leur segmentation, vient
de la commune, c'est le référenciel de la commune qui fournit les
identifiants les plus précis et les plus stables. Tous les autres (Rivoli,
Le 14 avril 2013 17:04, Tony Emery tony.em...@yahoo.fr a écrit :
Ça peut être encore plus complexe vue qu'une rue peut être coupée en deux
et
être renommée dans ces 2 parties. Mais on n'est pas obligé de commencer par
le plus difficile.
L'évolution des objets est un problème à traiter à
Le 15 avril 2013 09:45, Christian Quest cqu...@openstreetmap.fr a écrit :
Le 14 avril 2013 20:04, Ista Pouss ista...@gmail.com a écrit :
Le 14 avril 2013 16:00, Christian Quest cqu...@openstreetmap.fr a
écrit :
Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien.
Je n'ai pas été clair, je voulais dire non accessible et pas non ouvert au
sens des licences libres. Désolé pour la confusion.
--
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon :
http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr
Ce débat m'intéresse beaucoup voilà ce que j'en pense (même si je suis pas
certain de ne pas être hors-sujet) :
1) Il faut effectivement limiter les références externes (à des données
ouvertes donc) que l'on met dans OSM. Maintenant quand c'est bien fait c'est
vraiment super pratique.
2) Pour
Un lien qui se base sur l'ID et le numéro de version d'un objet OSM est
déjà un point d'entrée plus fiable que le seul ID.
On pourrait reprendre l'objet et analyser l'historique pour savoir ce qu'il
est devenu, mais c'est à mon avis très complexe à gérer.
L'objet peut:
- disparaitre et être
C'est également un sujet qui m'intéresse, mais j'aimerais avoir au moins
un cas concret d'application pour travailler dessus.
Le 15/04/2013 14:28, Christian Quest a écrit :
Un lien qui se base sur l'ID et le numéro de version d'un objet OSM est
déjà un point d'entrée plus fiable que le seul
cquest wrote
L'analyse de l'historique ne va pas être évident du tout !
Ce qui reste stable c'est quand même la position approximative et la
description approximative et en combinant les deux les risques d'ambiguité
diminuent.
Oui et non. Si mon objet way a été découpé ou regroupé il y aura
Pour prendre un peu de recul... si on réfléchissait au problème de façon
plus globale ?
Pour utiliser des ref:xx ?
- pour lier des données OSM avec des jeux de données externes
Peut-on/doit-on le faire pour n'importe quel jeu de données ?
Je ne pense pas. Si ce sont des données librement
Salut
C'est un vieux débat sur lequel déjà pas mal d'efforts a déjà investi.
Un geohash ne résouds qu'une partie du problème même en y associant le type
de tag.
On peut citer les cas de déménagement d'une société dans un autre endroit
de la ville.
De même un coiffeur ou toute autre société peut
cquest wrote
Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps)
serait un truc du genre bakery#u09v8z39 où bakery indique le type
d'objet cherché et #u09v8z39 est le geohash de sa position approximative.
C'est assez facile à mettre en œuvre pour des objets ponctuels ou
Le 14/04/2013 16:00, Christian Quest a écrit :
Pour prendre un peu de recul... si on réfléchissait au problème de
façon plus globale ?
Pour utiliser des ref:xx ?
- pour lier des données OSM avec des jeux de données externes
Peut-on/doit-on le faire pour n'importe quel jeu de données ?
Je ne
Le 14/04/2013 17:04, Tony Emery a écrit :
cquest wrote
Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps)
serait un truc du genre bakery#u09v8z39 où bakery indique le type
d'objet cherché et #u09v8z39 est le geohash de sa position approximative.
C'est assez facile à mettre
Effectivement la condition est qu'une partie des données est au minimum
accessible au public, donc qu'on doit être capable d'utiliser ces
références pour aller consulter ces ressources externes. Leur justification
c'est d'une part de permettre de synchroniser la partie libre / ouverte
de ces
Le dim. 14 avril 2013 à 16:00 +0200, Christian Quest a écrit :
Pour prendre un peu de recul... si on réfléchissait au problème de façon
plus globale ?
Pour utiliser des ref:xx ?
- pour lier des données OSM avec des jeux de données externes
Peut-on/doit-on le faire pour n'importe quel
Le 14 avril 2013 16:00, Christian Quest cqu...@openstreetmap.fr a écrit :
Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien.
Pourquoi ? Si le id est correctement géré et que le droit d'usage de cet id
est permis ? Est-ce non ouvertes qui te gène ?
Il va falloir se
39 matches
Mail list logo
