P. N'importe quoi. Les EPCI ne peuvent pas gérer *toutes* les donénes
qu'on met dans OSM. Elles sont de toute façon obligées de faire le tri dans
ce qui les intéresse, et de reclasser/regrouper des éléments qui ont été
codifiés séparément dans OSM (par exemple à quoi cela peut servir à une
coll
le ,ombre de caractères c'est ridicule, sinon au devrait écrire aussi le
tag "admin_level=08" et non "admin_level=8"; cela aurait un sens si c'était
un identifiant servant de base à d'autres, mais ça n'a été modiflisé que
comme une valeur strictement énumérée ayant une valeur numérique comparable
s
Le 14/04/2013 16:52, Tony Emery a écrit :
Vincent de Château-Thierry wrote
Pour revenir au sujet, je vais reformuler autrement ma proposition de ce
matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement)
et un peu de robustesse, on pourrait renseigner ce type de tag :
ref:FR:ad
Vincent de Château-Thierry wrote
> Pour revenir au sujet, je vais reformuler autrement ma proposition de ce
> matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement)
> et un peu de robustesse, on pourrait renseigner ce type de tag :
> ref:FR:admin_level8=
>
> :
> l'objet tel qu
Guillaume Allegre wrote
>> Je continue de penser que ref:FR:
>
> est une
>> galère potentielle, tant en gestion qu'en compréhension.
>
> Pourquoi ? Ça gêne qui ?
Ceux qui utilisent les données dans des SIG classiques (il y en a encore).
Il ne faut pas seulement penser informatique et web...
cquest wrote
> ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée,
> pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée
> et ne doit pas être générique.
>
> ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE
> ref:FR:RATP du jeu de données d
Le 14/04/2013 15:25, Christian Quest a écrit :
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry mailto:v...@laposte.net>> a écrit :
Pour revenir au sujet, je vais reformuler autrement ma proposition
de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul
finalement) et
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry a
écrit :
>
> Pour revenir au sujet, je vais reformuler autrement ma proposition de ce
> matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et
> un peu de robustesse, on pourrait renseigner ce type de tag :
> ref:FR:admin_le
Le 14/04/2013 14:21, Guillaume Allegre a écrit :
Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit :
Et doncon est revenu au point de départ de la discussion :-)
Oui, et tant mieux, les digressions sur la meilleure réforme possible
des administrations, ce n'est pas
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry a
écrit :
>
> Pour revenir au sujet, je vais reformuler autrement ma proposition de ce
> matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et
> un peu de robustesse, on pourrait renseigner ce type de tag :
> ref:FR:admin_le
Le 14/04/2013 12:58, Philippe Verdy a écrit :
Pourquoi "FAUT-il- parvernir" à ça ? Je ne vois aucune justification au
fait d'avoir des tags identiques pour toutes les communes, car ce ne
sont pas des éléments consitutifs d'un "feature" géographique.
Le "il faut" n'est pas à prendre comme un
Le dim. 14 avril 2013 à 11:14 +0200, Christian Quest a écrit :
> ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de
> ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on
> fait référence vu qu'il n'ont rien en commun les uns avec les autres !
+1
--
°
Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit :
> Et doncon est revenu au point de départ de la discussion :-)
Oui, et tant mieux, les digressions sur la meilleure réforme possible
des administrations, ce n'est pas tellement ce qui va faire avancer la cause.
> Je c
Pourquoi "FAUT-il- parvernir" à ça ? Je ne vois aucune justification au
fait d'avoir des tags identiques pour toutes les communes, car ce ne sont
pas des éléments consitutifs d'un "feature" géographique.
Le "feature" c'est plutôt porté par les autres tags. Ici on ne parle que
d'un simple identifia
Le 14/04/2013 12:20, Philippe Verdy a écrit :
Et ce n'est pas suffisant, les objets pouvant être à cheval sur
plusieurs communes (une voirie, un parc, etc... ou être administré par
une autre commune qui est locataire les lieux sités sur le territoire
d'une autre (par exemple une déchetterie)
Le
Je peux prendre une exemple extrême mais réel : la maison de Victor Hugo
située à Guernesey (Hauteville House) est entièrement gérée par la Mairie
de Paris (avec le drapeau français à l'entrée, un administrateur local payé
par la mairie de Paris.
Pourtant elle n'est pas sur le territoire de la comm
Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs
communes (une voirie, un parc, etc... ou être administré par une autre
commune qui est locataire les lieux sités sur le territoire d'une autre
(par exemple une déchetterie)
Le 14 avril 2013 12:14, Vincent de Chateau-Thierry
Tout à fait d'accord, ce n'est pas mon idée de n'utiliser que l'admin_level
qui n'est pas suffisant (on a des tas de données qui pourraient provenir de
jeux sources maintenues par plusieurs communes simultanément sans qu'on
puisse savoir laquelle, ou de plusieurs départements ou plusieurs régions
j
Bonjour,
Le 14/04/2013 11:14, Christian Quest a écrit :
ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée,
pour moi le xxx doit contenir un identifiant unique vers le jeu de
donnée et ne doit pas être générique.
ref:INSEE indique bien qu'on parle du jeu de données de l'INS
ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée,
pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée
et ne doit pas être générique.
ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE
ref:FR:RATP du jeu de données de la RATP
ref:mhs du jeu
pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur
numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level
Le 14 avril 2013 09:58, Tony Emery a écrit :
> Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou
> ref:FR:admin_level_08 ?
>
>
>
> --
>
Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou
ref:FR:admin_level_08 ?
--
View this message in context:
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.html
Sent from the France mailing list archive at Nabble.com.
_
LA légitimité concerne l'utilisation quotidienne des données effectives.
L'asso est tout à fait habilitée à faire des recommandations et des études,
qui n'ont aucun impact réglementaire ou légal pour autant qui sont
inattaquables.
Les collectivités sont ensuite responsables de leurs décisions de s
Le 12 avr. 2013 à 15:58, Philippe Verdy a écrit :
> Même sans faire appel au mille-feuille administratif, il y a d'autres moyens
> de coopérations entre communes et autres collectivités pour certaines
> missions. Les associations ça existe, la France n'en manque pas !
>
> Déjà il y a l'Associa
Même sans faire appel au mille-feuille administratif, il y a d'autres
moyens de coopérations entre communes et autres collectivités pour
certaines missions. Les associations ça existe, la France n'en manque pas !
Déjà il y a l'Association des maires de France (AMF) et je ne vois pas
pourquoi les p
Christian Rogel wrote
> la solution est de faire des SIG à un niveau supérieur à la communauté de
> communes.
> C'est ce qui a été fait à Brest où la métropole met, par convention, son
> SIG à la disposition des autres EPCI du Pays de Brest (pays "Voynet")
> 9 agents arrivent à couvrir 89 communes
Le 11 avr. 2013 à 17:43, Tony Emery a écrit :
> Une fois que j'ai dit ça, que peut-on en tirer ?
> 1- Que la source première de données est et restera toujours la commune (en
> gros toujours) ;
> 2- Qu'il faut s'appuyer sur elles si l'on veut constituer une base crédible
> et maintenue dans le t
Si l'Etat ne peut plus financer ça auprès des collectivités territoriales
rurales, sans doute un accord de coopération avec la région, voire aussi
les autres régions, départements et communes et intercommunalités (via
leurs associations nationales), ou encore les chambres de commerce et
d'industrie
Le 11 avril 2013 19:58, Christian Quest a écrit :
> Il reste 8905 communes en raster et sur un an il y en a eu dans les
> de vectorisées.
>
> A ce rythme, il faudra encore 4 ans pour arriver à bout.
>
Et sans compter que le processus de vectorisation n'est pas financé partout
avec en partic
Il reste 8905 communes en raster et sur un an il y en a eu dans les de
vectorisées.
A ce rythme, il faudra encore 4 ans pour arriver à bout.
Voir:
http://munin.openstreetmap.fr/stats.db/departement/osm_commune_tous.html
Le 11 avril 2013 19:49, Tony Emery a écrit :
> Pieren wrote
> > Tout
Le 11 avril 2013 19:45, Tony Emery a écrit :
> Oui, le fichier RIVOLI (répertoire informatisé des voies et lieux-dits) est
> devenu le FANTOIR (Fichier ANnuaire TOpographique Initialisé Réduit)
>
Tu ne voulais pas dire plutôt le Fichier OUblié TOpographique Inutilisé au
Rebut ?
;-)
Pieren wrote
> Tout ce qui est dit sur les délais trop longs peut changer dès lors qu'une
> responsabilité est assignée et les moyens qui vont avec (c'est bien là où
> ça coince).
Sauf que l'Etat n'a déjà plus les moyens d'assumer ses propres missions
Pieren wrote
> L'inégalité des moyens entre
cquest wrote
> Ca dépend... les fichiers EDIGEO fournis à la DGFiP peuvent contenir le
> filaire de voirie en plus des étiquettes.
Ça fait 6 ans que je traite les données de la DGFiP et je n'ai jamais vu le
filaire de voie
cquest wrote
> Rivoli est devenu FANTOIR ou bien c'est différent ?
Oui,
2013/4/11 Christian Quest
> 2- La DGFiP ne dispose pas du filaire de voirie mais seulement d'une couche
>> de données représentant les étiquettes du nom des voies.
>>
>
> Ca dépend... les fichiers EDIGEO fournis à la DGFiP peuvent contenir le
> filaire de voirie en plus des étiquettes.
>
>
Oui, c
Le 11 avril 2013 17:43, Tony Emery a écrit :
> Alors, je vais essayer de vous expliquer comment ça marche.
> 1- La DGFiP fait partie de la fonction publique d'état et les communes de
> la
> fonction publique territoriale, c'est comme si vous vouliez comparer Auchan
> avec le boulanger du coin.
>
Pieren wrote
> Bah, je pensais au cadastre en disant ça. Ça à l'air de fonctionner à peu
> près correctement avec une administration centrale qui collabore avec les
> communes et collectivités locales (ça irait encore mieux avec plus de
> moyens). Mais la composante adresse n'est pas son principal
Le 11 avril 2013 11:14, Pieren a écrit :
> Mais la composante adresse n'est pas son principal souci (elles sont
> souvent erronées, imprécises et anonymes). Il suffirait d'en faire une
> obligation comme pour le parcellaire et en utilisant le même modèle de
> coopération pour l'actualiser.
>
Pour
2013/4/7 Tony Emery
> Une autorité de l'Etat qui se chargerait de chapeauter les compétences de
> collectivités territoriales autonomes ?!? Oula, tu veux la révolution ???
>
Penchez-vous sur le sujet de la décentralisation en France et vous
> comprendrez que vous avez tout faut, là...
>
Bah, je
2013/4/5 Christian Rogel
> J'ignore ce que Pieren désigne par contributeur lambda. Cela s'oppose à
> contributeur non-lambda.
>
Je vais essayer d'en donner une définition : c'est une personne de 7 à 77
ans qui veut juste ajouter une rue, une piste cyclable, un nom, une maison
ou un POI mais qui
Le sam. 06 avril 2013 à 15:46 -0700, Tony Emery a écrit :
> Je suis d'accord sur ce point. Mais je tiens, en tant que cartographe et
> géographe de formation à vous rappeler une chose : quel sens donne-t-on à la
> carte ? à quoi doit-elle servir ?
> S'il s'agit juste de cartographier le réel juste
On partage le même point de vue, sauf que les références provenant
d'entités administratives multiples mais de même niveau (plusieurs communes
ou plusieurs départements) risquent d'arriver (sans pour autant que leurs
identifiants de bases de données soient compatibles entre eux.
Là dessus OSM peut
Guillaume Allegre wrote
> OSM ne doit pas devenir un dépôt où les "institutions" accepteraient de
> verser leurs données à condition que personne n'y touche.
>
> OSM c'est du crowdsourcing avant tout ; l'open data est un complèment,
> bienvenu mais pas essentiel.
> Il faut qu'on travaille au max
Christian Rogel wrote
> Tony faisait le distinguo entre collectivité publique autonome et
> administration de l'Etat.
> C'est sur l'anarchie admistrative français qu'il met le doigt.
En fait, je ne parle pas d'anarchie, je suggère seulement de comprendre que
le service publique n'est pas une nébul
Pieren wrote
> Quand je parle de "simple", c'est par rapport à la simplification
> administrative qui ferait qu'une seule autorité serait chargée de
> maintenir une base unique. Elle pourrait bien-sûr être abondée par les
> créateurs d'adresses (les communes) mais aussi pouvoir être corrigée et
> a
Le jeu. 04 avril 2013 à 23:50 -0700, Tony Emery a écrit :
> En fait, je dois quand même vous alerter sur un points : les collectivité
> sont de plus en plus consciente de l'intérêt de gérer en interne une base
> exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque
> voie de
Le ven. 05 avril 2013 à 11:34 +0200, Pieren a écrit :
> 2013/4/5 Tony Emery
>
> > Par conséquent, ces traçés, même si leur précision
> > n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme
> > approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle
> > alo
Le 5 avr. 2013 à 17:36, Pieren a écrit :
> ... et sur mon opinion que OSM est trop orienté administratif, qu'en
> penses-tu ?
>
> Je suis d'accord. Mes coups de gueule sur les références récurentes au code
> INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des
> villes et q
2013/4/5 Ista Pouss
> comment est-ce que l'on peut en conclure que l'adresse est un problème
> simple, quand bien même l'administration est mal foutue.
>
Quand je parle de "simple", c'est par rapport à la simplification
administrative qui ferait qu'une seule autorité serait chargée de maintenir
Le 5 avril 2013 14:58, Tony Emery a écrit :
> problème de la maintenance de cette base unique. Et, là encore, la commune
> est la source unique de l'information.
C'est peut-être vrai pour les communes de taille raisonnable (disons
au moins 1500 habitants), mais aujourd'hui plus aucune des plus
pe
Le 5 avril 2013 14:42, Pieren a écrit :
>
>
> Quand je parle de serpent de mer, c'est au sein même de l'administration.
> Un peu de lecture s'impose:
>
> http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011
>
>
Ouais enfin bon merci de ne me donne
r OSM en français
Objet : Re: [OSM-talk-fr] expérimentations à Orange
Le sujet des adresses est revenu à de très nombreuses fois durant les
rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a
signé à ce sujet un partenariat avec PIGMA, la plateforme d&
cquest wrote
> Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses
> figurent dans le cadastre vectoriel et de ce côté, il est bien possible
> qu'on ai accès à court terme à diverses données vectorielles du cadastre
> dans leur format d'origine (donc récupération de la voirie et
Pieren wrote
> Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
> l'instant, chaque institution construit la sienne à grands frais (enfin,
> surtout aux frais des contribuables et des usagers).
> Mon rêve : une base adresse unifiée, publique, réutilisable librement et
> ave
Le sujet des adresses est revenu à de très nombreuses fois durant les
rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier,
l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme
d'échange d'infos géographiques d'Aquitaine.
Il y a aussi beaucoup d'infos à récupérer de la D
2013/4/5 Ista Pouss
>
> Que la collaboration avec l'administration aide à se valoriser, à
> travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette
> à donner des leçons à cet administration en est une autre.
>
>
Quand je parle de serpent de mer, c'est au sein même de l'admini
Le 5 avril 2013 12:27, kimaidou a écrit :
> Pieren,
>
> Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles,
> en ODBL, avec une api sympa pour y accéder, ce serait l'idéal !
>
>
> Le 5 avril 2013 11:54, Pieren a écrit :
>
>>
>> 2013/4/5 Tony Emery
>>
>>> Après, on ne peut
Pieren,
Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles,
en ODBL, avec une api sympa pour y accéder, ce serait l'idéal !
Le 5 avril 2013 11:54, Pieren a écrit :
> 2013/4/5 Tony Emery
>
>> Après, on ne peut pas parler de simplification administrative puisqu'il ne
>> s
2013/4/5 Tony Emery
> Après, on ne peut pas parler de simplification administrative puisqu'il ne
> s'agit pas de la même institution.
>
Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
l'instant, chaque institution construit la sienne à grands frais (enfin,
surtout aux f
Pieren wrote
> 2013/4/5 Tony Emery <
> tony.emery@
> >
>
>> Qu'avons nous comme identifiant voirie :
>> - Rivoli : c'est un code créé et géré par la DGFiP
>> - l'ID de la BDAdresse : idem pour l'IGN
>> Il faut donc créer un identifiant interne dans la commune car la commune
>> est
>> la source d
2013/4/5 Tony Emery
> Par conséquent, ces traçés, même si leur précision
> n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme
> approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle
> alors qu'il ne le devrait pas, c'est quand même ce découpage qui est
2013/4/5 Tony Emery
> Qu'avons nous comme identifiant voirie :
> - Rivoli : c'est un code créé et géré par la DGFiP
> - l'ID de la BDAdresse : idem pour l'IGN
> Il faut donc créer un identifiant interne dans la commune car la commune
> est
> la source de cette information.
>
>
Donc chaque rue a t
cquest wrote
> Il me semble qu'un numéro de référence unique de la voirie doit
> effectivement se baser sur le code rivoli/fantoir et le code insee de
> la commune.
>
> Comme toujours, il faut regarder les cas particuliers... par exemple
> comment gérer une rue qui est la limite entre deux commune
Il me semble qu'un numéro de référence unique de la voirie doit
effectivement se baser sur le code rivoli/fantoir et le code insee de
la commune.
Comme toujours, il faut regarder les cas particuliers... par exemple
comment gérer une rue qui est la limite entre deux communes ?
Ce simple cas partic
kimaidou wrote
> Bonjour,
>
> Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je
> pensais à une application libre que chacun pourrait installer chez soi
> pour
> gérer les liens entre OSM et ses données métiers, si elles sont privées.
> Par contre, l'idée d'une base commune fera
Désolé pour le retard de ma réponse. Je vais essayer de vous donner quelques
éléments de réflexion. Après, je suis ouvert à toutes propositions.
Guillaume Allegre wrote
> 1) la boundary est une frontière de canton, qui coïncide avec un bout de
> la frontière communale
> (Orange / Caderousse)
> ht
- Mail original -
> De: "kimaidou"
> Bonjour,
> Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je pensais
> à une application libre que chacun pourrait installer chez soi pour gérer les
> liens entre OSM et ses données
> métiers, si elles sont privées. Par contre,
Bonjour,
Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je
pensais à une application libre que chacun pourrait installer chez soi pour
gérer les liens entre OSM et ses données métiers, si elles sont privées.
Par contre, l'idée d'une base commune ferait encore sens pour les bases
Le 2 avril 2013 21:18, Guillaume Allegre a écrit :
> Le sam. 30 mars 2013 à 20:37 +0100, Guillaume Allegre a écrit :
>
>>
>> 1) la boundary est une frontière de canton, qui coïncide avec un bout de la
>> frontière communale
>> (Orange / Caderousse)
>> http://www.openstreetmap.org/?way=171243851 m
Le sam. 30 mars 2013 à 20:37 +0100, Guillaume Allegre a écrit :
>
> 1) la boundary est une frontière de canton, qui coïncide avec un bout de la
> frontière communale
> (Orange / Caderousse)
> http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue
> (points distincts)
> Selon m
Le lun. 01 avril 2013 à 20:08 +0200, kimaidou a écrit :
> Bonjour à tous
>
> On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour
> tous ces cas là, je préférerais largement qu'une base de données externe
> s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu
Les id d'objets OSM peuvent changer en effet mais une chose est stable
: la géolocalisation. Si nécessaire on pourrrait utiliser dans la base
OSM des relations "collections" contenant un ID stable dans cette
collection (sous forme de rôle de type "id:*" dans la liste de ses
membres).
Ce qui permett
Le 2 avril 2013 09:42, Christian Quest a écrit :
> Ce problème de multiplication des liens partant d'OSM vers des données
> externes vient en fait de l'incapacité actuelle à faire des liens
> pérennes pointant VERS OSM. Les ID des objets peuvent changer, les
> objets peuvent être découpés (par ex
Le 01/04/2013 20:08, kimaidou a écrit :
[...]
+1
Je crois que c'est en effet une telle base de données externe, à
l'écoute des minutes diff qui permet à la fois :
* l'enregistrement de métadonnées tierces
* le monitoring par un tiers de données synchrones, problème soulevé
voici quelques tem
Ce problème de multiplication des liens partant d'OSM vers des données
externes vient en fait de l'incapacité actuelle à faire des liens
pérennes pointant VERS OSM. Les ID des objets peuvent changer, les
objets peuvent être découpés (par exemple une route sera tronçonnée
pour l'enrichir en détails)
N'est-ce pas la même chose que les tags ref:*=* actuels ? Sauf qu'il
suffirait de définiir une convention de nommage plus strict pour ces
ref:*=* (et éviter l'utilisation d'autres tags ne commençant pas par
"ref:" tels que les "CLC_ID")..
Même dans une table séparée (ou une base séparée, ce qui ne
Bonjour à tous
On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour
tous ces cas là, je préférerais largement qu'une base de données externe
s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on
pourrait appeler OsmLink (ou mieux), qui centraliserait l'ense
Le code INSEE des communes est pourtant une brique de base en France,
et est largement documenté... surtout il n'est pas du tout inconnu de
ceux qui justement vont chercher à faire des liaisons avec les bases
SIG externes (d'une ou plusieurs communes des données mais avec des
définitions géographiq
Le sam. 30 mars 2013 à 23:46 +0100, Christian Quest a écrit :
> Si on se reposait les questions de base ?
Yep.
> A quoi servent ces ref:xxx ?
>
> Si il s'agit de maintenir un lien avec un jeu de données externes bien
> précis et d'une façon unique, il faut que la clé permettent d'identifier le
Le dim. 31 mars 2013 à 13:16 +0200, Pieren a écrit :
> 2013/3/30 Vincent de Chateau-Thierry
>
> > Avec le schéma ref:FR: on pourrait se retrouver avec
> > autant de clés que de communes, toutes signifiant grosso-modo la même chose
> > : "cette clé a pour valeur une référence interne à la commune
Le 30/03/2013 21:45, Vincent de Chateau-Thierry a écrit :
Ensuite : ref:orange : là, je pense qu'on a un problème à régler.
"orange" n'est pas suffisamment
distinctif. Si toutes les communes du monde se mettent à utiliser le
même schéma, on va multiplier
les conflits. Comment régler ça ?
P
2013/3/30 Vincent de Chateau-Thierry
> Avec le schéma ref:FR: on pourrait se retrouver avec
> autant de clés que de communes, toutes signifiant grosso-modo la même chose
> : "cette clé a pour valeur une référence interne à la commune XXX".
>
>
+1
Et quitte à me répéter, le code insee d'une commun
Le 30 mars 2013 23:14, Vincent de Chateau-Thierry a écrit :
>
> Le 30/03/2013 22:35, Guillaume Allegre a écrit :
>>
>> Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :
>>
Ensuite : ref:orange : là, je pense qu'on a un problème à régler.
"orange" n'est pas suffisam
Le 30 mars 2013 22:26, Guillaume Allegre a écrit :
> Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit :
>> Le 30 mars 2013 20:37, Guillaume Allegre a écrit
>> :
>> > 3) La relation 2649371 a des attributs bizarres :
>> > - pas de nom
>> > - un "CANTON=Ouest" pas documenté
>> > - un "re
Si on se reposait les questions de base ?
A quoi servent ces ref:xxx ?
Si il s'agit de maintenir un lien avec un jeu de données externes bien
précis et d'une façon unique, il faut que la clé permettent d'identifier le
jeu de données sans ambiguité et donc il faut qu'elle soit unique pour
chaque j
Le 30/03/2013 22:35, Guillaume Allegre a écrit :
Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :
Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange"
n'est pas suffisamment
distinctif. Si toutes les communes du monde se mettent à utiliser le même
Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :
> >4) la route http://www.openstreetmap.org/browse/way/195747326 a les
> >attributs :
> > highway = road
> > addr:postcode = |84100
> > ref:orange = 84087V99
> >En dehors de la typo sur le code postal avec le
Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit :
> Le 30 mars 2013 20:37, Guillaume Allegre a écrit :
> > 3) La relation 2649371 a des attributs bizarres :
> > - pas de nom
> > - un "CANTON=Ouest" pas documenté
> > - un "ref=22" pas documenté non plus
>
> En effet, on a un schéma déja
Le 30 mars 2013 20:37, Guillaume Allegre a écrit :
> 3) La relation 2649371 a des attributs bizarres :
> - pas de nom
> - un "CANTON=Ouest" pas documenté
> - un "ref=22" pas documenté non plus
En effet, on a un schéma déja existant et homogène utilisant le code
Insee complet du canton à 4 chiffre
Bonsoir,
Le 30/03/2013 20:37, Guillaume Allegre a écrit :
1) la boundary est une frontière de canton, qui coïncide avec un bout de la
frontière communale
(Orange / Caderousse)
http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue
(points distincts)
Selon moi, elle devrait ê
89 matches
Mail list logo
