subject:"Re\: \[OSM\-talk\-fr\] \[OpenStreetMap\] Re\: Re\: Gros problème de correction... Groupe de modifications \: 28377712"

verdy_p wrote
Donc oui il faut pouvoir identifier quelle collectivité le fait, et le
fait est qu'elles en le font pas de la même façon sur les voiries
limitrophes partagées.

On s'en fout puisque le tag, tel qu'il est construit, permet d'intégrer les
identifiants de ces collectivités, quelle que soit la manière dont il est
construit. Il est où le problème ?

verdy_p wrote
La base de données voirie sur laquelle je travaille est « l’officiel de la
voirie de la CCPRO »,

Enfin tu réponds à la question ! Donc comme je te répondais depuis le
début c'est un ref:FR:CCPRO=*. Combien de fois je 'ai demandé le
périmètre de cette base et son nom?

Tu rigoles des genoux ? je t'ai dit au moins 20 fois pour qui, avec qui et
sur quel territoire je travaillais !?! Et donc, non c'est pas QUE CCPRO
puisqu'il y a aussi Avignon et son agglo ! en attendant la suite.

verdy_p wrote
Et non les communes ne sont pas compétentes de façon exclusive en tout ce
qui concerne la codification et la planification des réseaux (là on est
dans le cadre des divers plans locaux d'aménagement du territoire, mis en
place par les collectivités, leurs groupements, et par l'Etat, et même
l'Europe, ou par leurs diverses agences selon leurs besoins et compétences
propres).

Je n'ai jamais parlé DES réseaux, j'ai juste parlé de la compétence
exclusive de la commune sur la dénomination des voies. C'est une TRES grande
nuance pour qui sait vraiment de quoi il parle...

verdy_p wrote
Peu importe la compétence des communes ici (cela ne touche qu'à la
création et la dénomination locale, pas à la codification, ni même
l'exploitation puisque les communes ne gèrent pas *toute* la voirie
elles-mêmes et elles seules). Les compétences que tu cite ne sont qu'une
petite partie des besoins et usages.

Je n'ai jamais parlé de code mais d'identifiant unique, nuance. On vois que
tu n'as jamais travaillé sur une base de données voirie ou sur une base de
données adresses pour ne pas voir l'intérêt d'un identifiant unique pour
distinguer une voie d'une autre.

verdy_p wrote
Confusion très visible des codes INSEE utilisés... tiens donc, voilà une
codification intéressante, car justement elle ne vient pas de la
compétence des communes en matière de voirie mais d'un établissement
public de l'Etat où la commune n'a aucun pouvoir ! C'est très troublant de
voir un tag pourtant mentionner commune quand le code commune visible
n'est pas le bon et quand toi même tu justifie que cela vient non pas de
la commune mais d'une CC non mentionnée dans le nom du tag ni dans sa
valeur.

Tu parles de quoi là ? le code INSEE, l'Etat ? c'est quoi le problème ? J'ai
vraiment du mal à te suivre pour le coup !

verdy_p wrote
Et justement les quelques tags que j'avais enlevés étaient sur le
périmètre de la CCPRO, sur des frontières partagés par d'autres
collectivités (qui ne sont pas liées à ce que met en place « l’officiel de
la voirie de la CCPRO »), Tu ne vois pas le problème ? Le projet de la
CCPRO ne veut pas s'imposer comme norme pour les autres (en tout cas pas
dans OSM où la pluralité des sources est mondiale).

Le chemin de Saint-Roman, puisqu'il s'agit de ça,
http://www.openstreetmap.org/way/96962494 est une voie communale de la
commune de Bédarrides qui fait office de frontière avec la commune de
Courthézon et, oh miracle, les 2 communes font partie de la CCPRO, donc, la
CCPRO n'impose rien aux autres interco dommage !

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833409.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 12 février 2015 17:59, Tony Emery tony.em...@yahoo.fr a écrit :

 Pour répondre à Philippe, je dirais une chose que j’ai déjà écrite pas mal
 de fois et notamment un peu plus haut, genre le 12/02/2015 à 10 :17 :
 SEULES
 LES COMMUNES ONT LA COMPETENCE EN MATIERE DE CREATION ET DE DENOMINATION DE
 LA VOIRIE.

Je n'ai jamais prétendu le contraire et ce n'était pas mon propos
d'ailleurs.


 Après, qu’une commune choisisse de construire son identifiant d’une façon
 ou
 d’une autre, j’allais dire peu importe si l’on sait de quel commune il
 s’agit et que les identifiants son uniques. Le projet permet de passer de
 l’un à l’autre et c’est à la commune de voir comment elle veut faire, si
 elle souhaite verser ces données dans OSM.


Donc oui il faut pouvoir identifier quelle collectivité le fait, et le fait
est qu'elles en le font pas de la même façon sur les voiries limitrophes
partagées.

La base de données voirie sur laquelle je travaille est « l’officiel de la
 voirie de la CCPRO »,


Enfin tu réponds à la question ! Donc comme je te répondais depuis le début
c'est un ref:FR:CCPRO=*. Combien de fois je 'ai demandé le périmètre de
cette base et son nom?
Et non les communes ne sont pas compétentes de façon exclusive en tout ce
qui concerne la codification et la planification des réseaux (là on est
dans le cadre des divers plans locaux d'aménagement du territoire, mis en
place par les collectivités, leurs groupements, et par l'Etat, et même
l'Europe, ou par leurs diverses agences selon leurs besoins et compétences
propres).

Peu importe la compétence des communes ici (cela ne touche qu'à la création
et la dénomination locale, pas à la codification, ni même l'exploitation
puisque les communes ne gèrent pas *toute* la voirie elles-mêmes et elles
seules). Les compétences que tu cite ne sont qu'une petite partie des
besoins et usages.

Pour le reste, je ne garantit rien si je pars mais je ne pense pas que ce
 soit dans l’intérêt de la collectivité de ne pas continuer… Surtout que
 nous
 avons un logiciel de finance qui tourne derrière…


Ai-je suggéré à un moment qu'une collectivité ne devait pas le faire ou
n'avait pas besoin de le faire ? Désolé pour la poignée de tags non
documentés et qui semblaient visiblement erronés puisque inconnus mal
décrits et faisant apparemment référence à une commune qui n'était pas la
bonne :

Confusion très visible des codes INSEE utilisés... tiens donc, voilà une
codification intéressante, car justement elle ne vient pas de la compétence
des communes en matière de voirie mais d'un établissement public de l'Etat
où la commune n'a aucun pouvoir ! C'est très troublant de voir un tag
pourtant mentionner commune quand le code commune visible n'est pas le
bon et quand toi même tu justifie que cela vient non pas de la commune mais
d'une CC non mentionnée dans le nom du tag ni dans sa valeur.

Et justement les quelques tags que j'avais enlevés étaient sur le périmètre
de la CCPRO, sur des frontières partagés par d'autres collectivités (qui ne
sont pas liées à ce que met en place « l’officiel de la voirie de la CCPRO
»), Tu ne vois pas le problème ? Le projet de la CCPRO ne veut pas
s'imposer comme norme pour les autres (en tout cas pas dans OSM où la
pluralité des sources est mondiale).

Et ça me rappelle le vieux débat ici sur la codification des GR (source non
libre) alors qu'ils utilisent la voirie des communes qui ne sont pas liées
à cette codification et pas obligées non plus d'assurer leur continuité. Si
une commune ou une autre collectivité a besoin de fermer un chemin piéton
et les envoyer ailleurs, elle le fera sans demander la permission à la
FRPP, ni même la contacter pour suggérer un meilleur itinéraire évitant la
section fermée. La commune renommera ou divisera une rue sans lui demander,
elle pourra transformer un chemin piéton en bretelle de rocade ou céder le
terrain au privé qui le fermera. La commune est juste tenue de faire une
enquête publique et d'en tenir compte, l'enquête est une procédure
suffisante d'information, au regard de la loi et des règles des marchés
publics.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 12 février 2015 22:21, Tony Emery tony.em...@yahoo.fr a écrit :


 Et non, justement car il s'agit là du pouvoir de police du maire, donc ça
 restera à la commune, sauf si l'on supprime les communes.


Et le pouvoir de police du maire ne concerne pas la *codification* des
voies utilisée par les services municipaux ou communautaires.


 C'est d'ailleurs comme ça que l'on met à jour notre base de données, en
 récupérant systématiquement les délibérations des conseils municipaux.


D'accord, mais là encore les identifiants de la CCPRO ne proviennent pas
d'une décision du conseil municipal, c'est la CCPRO qui prend en charge
cette codification pour son SIG et met à les données codifiées obtenues à
disposition des communes (qui ont opté pour l'utilisation du SIG
communautaire mais peuvent encore avoir leur propre SIG avec encore
d'autres identifiants), ou d'autres collectivités qui y ont accès et
veulent faire des références croisées.

Tout ça c'est de l'administratif pur, de la méthode de travail, et ça n'a
rien à voir avec le pouvoir de police des maires sur son territoire, et
ça peut changer (y compris quand les CC changent de périmètre ou
disparaissent en fusionnant ou en se démantelant). Le jour où une commune
change de CC, ses données ne sont pas perdues, mais gardent leur
codification en plus de celle qui va être ajoutée dans leur nouvelle CC qui
suit d'autre règles, ces références cont *coexister* pendant un temps où
elles seront ensemble mais bien séparées dans des champs différents.
Pendant un temps la nouvelle commune d'une CC n'aura pas d'autre
identifiant pour sa voirie, conforme au modèle de sa nouvelle CC.

Comme les réformes territoriales sont nombreuses et fréquentes en ce
moement (et ce n'est pas terminé), les codifications vont se succéder aussi.

L'Insee ne peut tout codifier immédiatement dans son propre référentiel. Sa
seule urgence c'est d'enregistrer les nouveaux établissements publics et
collectivités avec des SIREN, selon sa codification de base en vigueur en
fin d'année N-1. Elle fait ensuite des mises à jour en masse en fin d'année
pour ne les publier que l'année suivante, avec un index des changements
opérés. Les SIG locaux feront la même chose : le référentiel a besoin d'une
stabilité suffisante sinon il ne sert pas à grand chose (sauf usage
purement interne) s'il change en continu (comme changent en continu les
identifiants OSM, dont l'usage est purement interne à sa propre base et
n'obéit à aucun pouvoir de police extérieur et ne résulte d'ailelurs
d'aucune décision humaine, pusiqu'ils sont attribués de façon totalement
automatique et imprévisible).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 12 février 2015 23:01, Tony Emery tony.em...@yahoo.fr a écrit :

 verdy_p wrote
  La base de données voirie sur laquelle je travaille est « l’officiel de
 la
   voirie de la CCPRO »,
 
  Enfin tu réponds à la question ! Donc comme je te répondais depuis le
  début c'est un ref:FR:CCPRO=*. Combien de fois je 'ai demandé le
  périmètre de cette base et son nom?

 Tu rigoles des genoux ? je t'ai dit au moins 20 fois pour qui, avec qui et
 sur quel territoire je travaillais !?! Et donc, non c'est pas QUE CCPRO
 puisqu'il y a aussi Avignon et son agglo ! en attendant la suite.


Là c'est toi qui 'rigole des genoux en étendant trop librement ma réponse
en prenant un autre exemple. Je donnais un exemple correct pour l'exemple
que tu donnais (tu ne parlais pas d'Avignon dans la phrase que je cite en
réponse. L'autre agglo d'Avignon utilisera son tag à elle. Est-ce que les
deux utilisent toujours la même codification commune quand elles sont en
collision ?


 verdy_p wrote
 Je n'ai jamais parlé de code mais d'identifiant unique, nuance. On vois que
 tu n'as jamais travaillé sur une base de données voirie ou sur une base de
 données adresses pour ne pas voir l'intérêt d'un identifiant unique pour
 distinguer une voie d'une autre.


Je n'ai pas parlé de code mais de codification, dont font partie les
identifiants uniques de toute base de données. Peu import esi je n'ai pas
travaillé pour une collectivité j'ai travaillé et travaille encore sur
d'autres bases de données qui ont elles aussi leur codification propre. Et
là encore il faut gérer des codifications de références externes multiples
(et pas synchronisées nécessairement entre elles).


 verdy_p wrote
  Confusion très visible des codes INSEE utilisés... tiens donc, voilà une
  codification intéressante, car justement elle ne vient pas de la
  compétence des communes en matière de voirie mais d'un établissement
  public de l'Etat où la commune n'a aucun pouvoir ! C'est très troublant
 de
  voir un tag pourtant mentionner commune quand le code commune visible
  n'est pas le bon et quand toi même tu justifie que cela vient non pas de
  la commune mais d'une CC non mentionnée dans le nom du tag ni dans sa
  valeur.

 Tu parles de quoi là ? le code INSEE, l'Etat ? c'est quoi le problème ?
 J'ai
 vraiment du mal à te suivre pour le coup !


Je parlais de la valeur de ton tag, même dans l'explication que te donnes
puisque tu dis bien que cela utilise le code INSEE (pas le code CCPRO ou
autre agglo) de la commune (laquelle ? ce n'est pas expliqué dans ta doc
m^me si ici tu l'as décrit mais plus tard). Cette collectivité ne code pas
tout en tout cas ne codifie pas elle-même la/les communes concernées.

 Le chemin de Saint-Roman, puisqu'il s'agit de ça,
 http://www.openstreetmap.org/way/96962494 est une voie communale de la
 commune de Bédarrides qui fait office de frontière avec la commune de
 Courthézon et, oh miracle, les 2 communes font partie de la CCPRO, donc, la
 CCPRO n'impose rien aux autres interco dommage !


Je ne l'ai pas fait par hasard, si je suis tombé sur ce chemin c'est parce
qu'il était rompu et qu'il ma fallu réparer les relations autour (et oui
cela allait beaucoup plus loin que la CCPRO, j'ai fait le tour des
différentes relations brisées et pour certaines ait du en retracer des
petits morceaux manquants, et refusionner là où deux segments successifs
n'étaient pas nécessaires.

Je me suis aperçu de ça avec un trou inexplicable dans les arrondissements
(très visible sur la couche admin_7 du rendu OSM.fr, où la zone n'était pas
rempli de rouge). Là le me suis aperçu que cela allait plus loin et
touchait toute une série de relations (dont les CC, les cantons anciens et
nouveaux, circonscriptions législatives, un bout de parc naturel, un cours
de rivière, quelques itinéraires de bus (relation route), un itinéraire
cyclable... Tout n'était pas venu nécessairement de tes modifs mais au
passage j'ai réparé en globalité tout ce que me signaliait le validateur de
données (en revanche je n'ai pas regardé du tout les landuse qui pour
l'instant n'affichait pas de gros défaut visible.

il peut y avoir quelques un dans ces chemins limitrophes qui n'avait plus
ton tag mais je n'ai pas regardé la totalité des limites communales qui
n'avaient pas été brisées.
Et justement Courthézon ou Bédarrides (je ne sais plus laquelle) était
partiellement brisée ce qui m'a amené à explorer tout leur contour pour le
vérifier et voir où ça clochait.

Et il manquait même toute une petite route en lacets (une dont le tracé
était visiblement très vieux et vraiment trop grossier avec des angles
impossibles ou passant au travers de batiments ou franchisant des ruisseau
d'une rive à l'autre sans aucun pont ni culvert, en diagonale
quasi-parallèle coupant la route sur plusieurs dizaines de mètres). Je n'ai
pas pour autant recré les chemins, j'ai ajouté des points qui manquaient
pour que cela ait un sens, et réaligné quelques uns qui étaient trop
éloignés du centre de la route.

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Je n’osais pas le dire, cher Vincent, de peur de passer pour un exploitant
privé de la donnée public mais, effectivement, j’ai aussi dans l’idée que
l’utilisation de ce type de tag sera quasiment impossible. J’avais fait la
même remarque à Jean-Louis quand il voulait intégrer les codes pour les ERP.
Il voulait créer un tag par type d’ERP et je lui ai dit que ce serait
inexploitable pour la suite.
Pourquoi pas le ref:FR mais à vérifier s’il n’y aurait pas de conflit ou de
risque de confusion avec d’autres ref français.

Par contre, le local_ref ne me semble pas forcément approprié. Il serait
plus utile pour récupérer la référence des voies communales (VC…) ou des
chemins ruraux (CR…). Mais ce n’est qu’un avis.

Le deuxième aspect est la réalisation d’une base de données voirie qui va
s’imposer aux communes dans le cadre des « Schémas de Voirie Communale ».
Les communes vont donc devoir faire ce travail de recensement de la voirie
de leur territoire mais, dans le cadre de la mutualisation, ce travail peut
être fait au niveau de l’intercommunalité.
Donc cette identifiant doit rester au niveau des communes, même si elles
sont traitées par les EPCI.

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833270.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Christian Rogel wrote
 Oui, la compétence est exclusivement communale pour le moment, mais quand
 les intercos auront été étendues et renforcées (y compris politiquement
 par le suffrage universel comme cela va se faire), la prestation des SIG
 qu’ils soient intercos ou par zones (pays ou autres) devra se faire en
 amont des décisions communales pour les questions techniques comme
 l’indexation des voies. 
 C’est de ces évolutions que naîtra le besoin de normaliser ces index
 nationaux qu’OSM n’aura qu’à reprendre.
 Ce genre de normalisation venu d’en-bas a déjà eu lieu sous l’égide des
 associations de territoriaux

Et non, justement car il s'agit là du pouvoir de police du maire, donc ça
restera à la commune, sauf si l'on supprime les communes.
Donc si le projet peut être porté par une autre structure, voire un
aménageur privé, c'est toujours le Maire qui contrôle la dénomination des
voies et qui fait délibérer par le conseil municipal.

C'est d'ailleurs comme ça que l'on met à jour notre base de données, en
récupérant systématiquement les délibérations des conseils municipaux.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833405.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-12 Par sujet Pieren

2015-02-12 13:44 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Effectivement, les toutes petites intercos n'ont pas plus les moyens. Après,
 je ne suis pas d'accord avec toi. Il faut des structures de taille
 suffisante si on veut qu'elles soient efficaces et qu'elles aient les moyens
 de faire quelque chose. Sinon, autant laisser les communes ! Ça n'a rien de
 technocrate, c'est juste logique.

Si on parle de logique, le simple citoyen que je suis ne comprends pas
que deux entités administratives créent et gèrent deux identifiants
uniques pour chaque voie. Ca fait sans doute partie de la
simplification administrative annoncée ... Plus sérieusement, il
suffirait que la DGFiP délivre des identifiants immédiatement aux
communes qui le demande, éventuellement avec un statut temporaire et
jusqu'à validation définitive par le cadastre. Mais ça doit être trop
simple pour nos technocrates ...
D'un autre côté, quand on voit les millions dépensés depuis des
décennies à gérer deux registres parcellaires en parallèle, plus rien
ne m'étonne (et ne parlons pas des base adresses).

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Christian Rogel wrote
L’amélioration est à venir, en fonction de l’extension de la superficie
des intercommunalités.
Le gouvernement parle d’un minimum de 20 000 hab., ce qui est encore une
invention débile des technocrates hors-sol. Il faudrait abaisser le seuil,
pour que dans la France désertifiée, on ait pas de C de C de la taille
d’un demi-département.

Effectivement, les toutes petites intercos n'ont pas plus les moyens. Après,
je ne suis pas d'accord avec toi. Il faut des structures de taille
suffisante si on veut qu'elles soient efficaces et qu'elles aient les moyens
de faire quelque chose. Sinon, autant laisser les communes ! Ça n'a rien de
technocrate, c'est juste logique.

Christian Rogel wrote
Mais, le renforcement des intercos amènera les services SIG à être
positionnés au moins à ce niveau, voire à un niveau supérieur par
conventionnement.
On en verra un modèle intéressant à Brest, au SOTM-Fr, puisque le SIG de
Brest Métropole Océane est le prestataire de toutes les intercos du Pays
de Brest (89 communes, 1690 km2, presque 400 000 hab.).

On voit déjà apparaitre des services SIG mutualisés sur plusieurs
communautés de communes (SIIG à Bagnols-S/-Cèze par exemple).

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833308.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

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:X
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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

C'est vrai que le seule de 20 000 habitants est stupide, et même deux fois
plus gros que la granularité des services adminsitratifs à Paris (pour son
découpage des 20 arrondissements en ~80 quartiers et une centaine de
sous-quartiers, le seuil atteint 10 000 habitants par subdivision).

10 000 est un bon chiffre pour prendre en compte une échelle suffisante de
démocratie locale avec des budgets dédiés (allouables au moins sur l'année
même si des arbitrages peuvent être négocies en cours d'année par
l'autorité commune gérant ces petites zones). Mais ce n'est qu'une
moyenne: sur Paris où 10 000 c'est gérable car ils sont très concentrés et
ont tous aussi accès tous les jours à des services situés dans les secteurs
voisins et partagés entre secteurs, ce n'est pas le cas dans le monde rural
où les distances grandissent très vite.

Alors oui les petites communes rurales ne peuvent plus tout faire et sont
obligées de se mutualiser (mais aussi les intercommunalités). C'est là
qu'intervient le modèle de développement ne cherchant pas à calquer le
^même modèle administratif partout :

- un modèle pour les zones urbaines denses (ou assez denses) ayant déjà
assez de services accessibles en leur sein : c'est celui des poles
métropolitains à développer pour regrouper des communes qui elles aussi
peuvent fusionner facilement dans ces pôles pour supprimer des barrière
administratives non essentielles qui pénalise le développement et
l'évolution du territoire urbain dans sa globalité, accessible facilement à
tous ceux qui se trouvent dans le pôle (ces pôles sont bien dotés en
services de transport pas cher pour tous notamment) Dans ces zones passer à
20 000 habitants a un sens, et les communes peuvent toutes y monter à un
seuil de 2 000 ou 3 000 habitants minimum (elles peuvent conserver une
démocratie locale en se divisant en arrondissements municipaux, numérotés
ou nommés : c'est le modèle de Nantes Métropole par exemple qui appelle ses
arrondissements des pôles de proximité).

-  un autre divisant le périmètre rural des pôles urbains en grands (mais
pas trop grand) pôles ruraux, où il est difficile de mettre tous les
services à disposition, mais où les pôles utbains seront TENUS par la loi
de contribuer à les aider à se développer, ou de leur donner des services
accessibles que ces pôles ruraux ne peuvent pas développer eux-mêmes. Dans
ces zones, les poles ruraux pourraient passer à 5 000 habitants (là :les
communautés de communes sont une soluion, mais certaines sont encore trop
petites et doivent être agrandies, mais du fait de l'augmentation des
distances pour accéder aux services de base il faut garder une démocratie
locale : le pole rural doit aider les communes isolées et pour cela doit
recevoir des subsides venant des pôles urbains. Dans ce cas, on peut monter
les communes à un seuil minimum (pour la survie) de 1 000 habitants (en
dessous, à cause des distances, il ne sera pas possible de donner les mêmes
services tous les jours, mais il peut y avoir une rotation des présences de
la démocratie locale.

Et puis il faudrait en finir avec la notion de chef-lieu unique : une
collectivité n'a aucune raison d'avoir son pole de décision en permanence
au même endroit quand ils peuvent tourner. Chaque collectivité emploie
aussi ses services administratifs qui sont plus ou moins répartis sur le
territoire et servent de points de contact accessible. C'est cette notion
de chef-lieu (ou capitale) qui est source de gaspillage et de frustrations
de la part de ceux qui n'y habitent pas et se voient petit à petit privés
de services ou contraints d'accepter uniquement les rebus des centres
urbains (déchetteries, emprise de leur territoire pour construire ou
étendre des rocades et autoroutes, zones indistrielles sales, cités
dortoirs,,,) et quelques services dégradés (écoles qui ferment, peu ou pas
de transport urbain même avec le centre urbain le plus proche, et jamais
entre les communes rurales malgré la présence des intercoms, déserts
médicaux...). peu ou pas de sécurité publique (absence même de la
gendarmerie)

Et ne pas oublier aussi qu'avec Internet maintenant plein de choses peuvent
se faire qui ne nécessitent plus de bâtir et entretenir un coûteux point
d'accueil permanent. C'est ce qu'à fait dès vite dès son indépendant
l'Estonie (même si elle a eu la chance de récupérer des stocks d'or stockés
depuis des décennies dans les banques occidentales et d'avoir eu très vite
des relations avec ses voisins scandinaves, tout en restant un port
important d'échange pour la Russie, comme pour la Finlande qui n'était plus
isolée du reste de l'Europe et tenue de passer soit par le nord soit par la
mer).

Le 12 février 2015 13:44, Tony Emery tony.em...@yahoo.fr a écrit :

 Christian Rogel wrote
  L’amélioration est à venir, en fonction de l’extension de la superficie
  des intercommunalités.
  Le gouvernement parle d’un minimum de 20 000 hab., ce qui est encore une
  invention débile des technocrates hors-sol. Il faudrait abaisser le

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Il faut quand même se rendre compte d’une chose très importante. Les services
d’Etats ont de moins en moins de moyens et les compétences sont de plus en
plus transférées vers les collectivités territoriales. Il y aurait plein de
choses à dire dessus mais ce serait très long.

Donc, s’il y a une tendance, c’est plus dans le sens de permettre aux
communes de créer leurs « Fantoir » comme l’a suggéré Christian. Mais on est
encore loin de tout ça. En attendant…..

Pour répondre à Philippe, je dirais une chose que j’ai déjà écrite pas mal
de fois et notamment un peu plus haut, genre le 12/02/2015 à 10 :17 : SEULES
LES COMMUNES ONT LA COMPETENCE EN MATIERE DE CREATION ET DE DENOMINATION DE
LA VOIRIE.

Donc l’histoire des bases des départements, des régions etc… n’a pas lieu
d’être. Au contraire, si les communes arrivent à mettre en place ce projet,
les autres institutions n’auront plus besoin de créer leurs propres bases…

Après, qu’une commune choisisse de construire son identifiant d’une façon ou
d’une autre, j’allais dire peu importe si l’on sait de quel commune il
s’agit et que les identifiants son uniques. Le projet permet de passer de
l’un à l’autre et c’est à la commune de voir comment elle veut faire, si
elle souhaite verser ces données dans OSM.

Après, cher Philippe, c’est bien d’écrire des romans que personne ne lit,
mais il faut vraiment lire les posts des autres aussi parce que, de mon
côté, j’en ai vraiment marre de répéter 50.000 fois les mêmes choses.

La base de données voirie sur laquelle je travaille est « l’officiel de la
voirie de la CCPRO », ex-« Officiel de la voirie d’Orange » qui concerne,
pour le moment, les 7 communes de la CCPRO. Cette base de données a été
conçue en partenariat avec la ville d’Avignon (et son agglomération).
Elle est disponible, en OpenSource ici :
https://drive.google.com/file/d/0B_qnfztqzzrOcUl1QjU3VF9MZGs/view?usp=sharing
Pour voir la licence d’utilisation, il faut ouvrir de 2ème onglet.
Je suis le contact principal de cet officiel car c’est mon boulot au sein de
la collectivité. Mais je travaille en coordination avec mes 2 autres
collègues, les 7 communes et les agents de terrain de la CCPRO qui nous
vérifie les infos sur place.
Pour le reste, je ne garantit rien si je pars mais je ne pense pas que ce
soit dans l’intérêt de la collectivité de ne pas continuer… Surtout que nous
avons un logiciel de finance qui tourne derrière…

J'ai pas lu le 2ème post... pas assez de temps!

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833370.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-11 Par sujet Philippe Verdy

Vu la façon dont tu le décrit, même si le tag vient d'une commune, son
usage étant intercommunal, il aurait été plus explciite de mettre
ref:FR:intercom=* si tu veux généraliser, intercom pouvant signifier
iintercommunal (plusieurs communes) ou intercommunalité (EPCI), ou
intercommunication, ou encore ref:street:local= puisque cela concerne
uniquement le linéraire et pas forcément tout ce qui touche géométriquement
l'objet qui peut y être collé. Cependant se passer de FR: serait
dangereux, pour peu qu'un autre pays se décide à utiliser ce même tag et
l'utiliser selon ses propres règles (ils ne sont pas au courant de cette
discussion et il ne faudra pas se plaindre en cas de conflit d'usage.

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:x = Vnn, où x est le code commune à 5
chiffres ?
- ou bien ref:FR:x=Vnnn, où x 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,

Le 10 février 2015 13:31, Tony Emery tony.em...@yahoo.fr a écrit :

 Bon, on peut relancer le débat sur le nom du tag et les caractères et
 comment
 on les mets

 Il s'agit du parti pris que l'on a pris localement pour harmoniser nos
 bases de données entre Orange, Avignon et les intercommunalités
 correspondantes. Pour le coup, on ne réfléchit pas que dans le stricte
 cadre
 d'OpenStreetMap. Dans notre Base de données, cet identifiant s'appelle
 ID_Interne.

 Donc, pour le nom du tag, à l'origine, j'avais ref:orange mais c'était pas
 bon pour x raisons.
 Vu que c'est un tag qui est, pour le moment, français, on (les
 contributeurs
 OSM) était parti sur un ref:FR.
 Et vu qu'il s'agit d'un identifiant issu des communes, on a mis
 ref:FR:commune.
 Après on peut toujours dire que les bases de données voiries peuvent être
 intercommunales, mais elles ne le sont pas toutes et le plus petit
 dénominateur commun est, justement, la commune.

 Après, dans les nombreux projets dont l'objectif est d'harmoniser et de
 normaliser les données (je vous renvoi à la directive européenne INSPIRE),
 les champs attributaires sont le plus contraignants possibles pour éviter
 les erreurs de saisie. Donc, on fixe le plus possible un nombre de
 caractères pour être sûr de ne pas en oublié un ou d'en mettre un en trop.

 Enfin, pourquoi rajouter des - ou des _ vu que c'est un identifiant et
 qu'on n'a pas besoin de lui faire raconter une histoire ? Après tout, le
 code FANTOIR marche comme ça, les identifiants parcellaires aussi...





 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833055.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-11 Par sujet Vincent de Château-Thierry


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:x = Vnn, où x est le code commune à
5 chiffres ?
- ou bien ref:FR:x=Vnnn, où x 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Tony Emery

Voilà, j'ai documenté le tag ref:FR:Commune.

C'est ici : http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:commune

J'attends vos remarques constructives...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833008.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Frédéric Rodrigo

Pour moi, il ne faudrait pas utiliser commune en française, pourquoi 
FR, rien de spécifique à la France. Sur la valeur, il faut la laisser 
entièrement libre.


Bref, quelque comme local_ref=* est suffisant pour moi.

Frédéric.


Le 10/02/2015 11:12, Tony Emery a écrit :

Voilà, j'ai documenté le tag ref:FR:Commune.

C'est ici : http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:commune

J'attends vos remarques constructives...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833008.html
Sent from the France mailing list archive at Nabble.com.

___
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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Pierre Knobel

Je trouve dommage de fixer la longueur du code à 6 caractères. Avec le
préfixe INSEE+V à 6 chiffres, ce serait possible de laisser le choix
du nombre de caractères aux collectivités en fonction de leur besoin.
A mon avis le plus simple pour le décodage automatique est un code à
longueur variable avec des séparateurs clairs entre les différents
éléments du code :
insee-type d'objet-code unique

Par exemple : 84007-V-4012,
Encore mieux : 84007-voirie-4012 (lisibilité)

 Le 10/02/2015 11:12, Tony Emery a écrit :

 J'attends vos remarques constructives...


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Tony Emery

Ça n'a rien à voir. L'ID parcellaire est très récent puisqu'il est apparût
avec la numérisation du cadastre il y a quelques années. Avant on avait un
truc du type AB 21, maintenant on a 840087000AB0021 sur 15 caractères fixes.

Et c'est tellement plus rapide de dire : ref:fr:commune = [CodeINSEE] 
[TypeObjet]  [RefUnique]

Ça nous (ou vous) fait sortir du monde purement informaticien et entrer dans
le monde merveilleux de la géomatique



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833068.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Pierre Knobel

On 2/10/15, Tony Emery tony.em...@yahoo.fr wrote:

 Enfin, pourquoi rajouter des - ou des _ vu que c'est un identifiant et
 qu'on n'a pas besoin de lui faire raconter une histoire ? Après tout, le
 code FANTOIR marche comme ça, les identifiants parcellaires aussi...


Les codes FANTOIR et les identifiants parcellaires sont des vieux
outils mis en place il y a longtemps, quand les langages de
programmation ne permettait pas facilement de faire des opérations du
genre :

(code_INSEE, type_objet, ref_unique) = '-'.split(ref_fr_commune_osm)

et qu'il fallait faire :

char code_insee[5], type_objet[1], ref_unique[6];
strncpy(code_insee, ref_fr_commune, 5)
strncpy(type_objet, ref_fr_commune+5, 1)
strncpy(ref_unique, ref_fr_commune+6, 6)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-10 Par sujet Tony Emery

Bon, on peut relancer le débat sur le nom du tag et les caractères et comment
on les mets

Il s'agit du parti pris que l'on a pris localement pour harmoniser nos
bases de données entre Orange, Avignon et les intercommunalités
correspondantes. Pour le coup, on ne réfléchit pas que dans le stricte cadre
d'OpenStreetMap. Dans notre Base de données, cet identifiant s'appelle
ID_Interne.

Donc, pour le nom du tag, à l'origine, j'avais ref:orange mais c'était pas
bon pour x raisons.
Vu que c'est un tag qui est, pour le moment, français, on (les contributeurs
OSM) était parti sur un ref:FR.
Et vu qu'il s'agit d'un identifiant issu des communes, on a mis
ref:FR:commune.
Après on peut toujours dire que les bases de données voiries peuvent être
intercommunales, mais elles ne le sont pas toutes et le plus petit
dénominateur commun est, justement, la commune.

Après, dans les nombreux projets dont l'objectif est d'harmoniser et de
normaliser les données (je vous renvoi à la directive européenne INSPIRE),
les champs attributaires sont le plus contraignants possibles pour éviter
les erreurs de saisie. Donc, on fixe le plus possible un nombre de
caractères pour être sûr de ne pas en oublié un ou d'en mettre un en trop.

Enfin, pourquoi rajouter des - ou des _ vu que c'est un identifiant et
qu'on n'a pas besoin de lui faire raconter une histoire ? Après tout, le
code FANTOIR marche comme ça, les identifiants parcellaires aussi...

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833055.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 13:17 GMT+01:00 François Lacombe fl.infosrese...@gmail.com:
 +1 Tony, keep going.

 François Lacombe

Non, c'est trop facile. Il faut d'abord examiner ce qui se passe avant
de donner un blanc-seing aussi rapidement (même si le message suivant
commence à poser les bonnes questions).
Le problème principal tourne autour de cette référence
ref:FR:commune. Il y a déjà en France un code unique pour les rues,
celui de la dgfip ref:FR:FANTOIR. L'explication donnée par Tony:

 Vous faites ce que vous voulez avec les codes Fantoir, nous gérons nos 
 identifiants internes

n'est en aucun cas satisfaisante, pas seulement parce que le tag n'est
documenté nul part (alors qu'il est utilisé depuis 2 ans déjà) mais
surtout parce qu'il est d'un usage interne ! OSM ne peut être le
réceptacle de données à usage interne, inexploitables par les autres
utilisateurs et incompréhensibles par les autres contributeurs. C'est
une règle fondamentale dans ce type de projet. D'autant plus que des
solutions techniques (externes à OSM) sont faciles à mettre en place
si un code unique, celui du fantoir, est correctement mis en place.

Notez que ça n'est pas la première fois que les expérimentations
faites sur Orange posent questions. C'était déjà le cas en 2013 avec
les mêmes personnes et le ref:FR:commune s'appelait à l'époque
ref:orange:
https://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056807.html

mais qu'à l'époque, le ref:FR:fantoir n'existait pas et l'excuse de
l'expérimentation était encore acceptable.

Concernant les autres points (limites communales), il ne s'agit
apparement que de maladresses. Inutile donc d'y revenir. Sinon,
concernant les échanges épistolaires de Philippe, on le connait ici
très bien et il sait déjà qu'il gagnerait beaucoup à être moins
agressif dans le choix de ses expressions mais qu'il ne changera
jamais de ce côté là.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
 Okay pour ce cas. Mais uniquement pour ce cas où la voirie n'a pas encore
 de code fantoir. On peut parfaitement tolérer ce ref:FR:commune comme
 une solution transitoire pour satisfaire tout le monde. Mais en aucun cas,
 on ne devrait le généraliser à toutes les voies.

L'avantage de cet identifiant est qu'il est plus exhaustif que le Fantoir.
Par exemple, à Orange, sur les 797 voies recensées, il manque 96 rivolis.
Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
supprimer derrière.


Pieren wrote
 Et ça n'exonère pas de le documenter dans le wiki...

J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
http://wiki.openstreetmap.org/wiki/Vaucluse/voirie  




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832601.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
Non, c'est trop facile. Il faut d'abord examiner ce qui se passe avant de
donner un blanc-seing aussi rapidement (même si le message suivant
commence à poser les bonnes questions).
Le problème principal tourne autour de cette référence ref:FR:commune.
Il y a déjà en France un code unique pour les rues, celui de la dgfip
ref:FR:FANTOIR. L'explication donnée par Tony:
Vous faites ce que vous voulez avec les codes Fantoir, nous gérons nos
identifiants internes
n'est en aucun cas satisfaisante, pas seulement parce que le tag n'est
documenté nul part (alors qu'il est utilisé depuis 2 ans déjà) mais
surtout parce qu'il est d'un usage interne ! OSM ne peut être le
réceptacle de données à usage interne, inexploitables par les autres
utilisateurs et incompréhensibles par les autres contributeurs. C'est une
règle fondamentale dans ce type de projet. D'autant plus que des solutions
techniques (externes à OSM) sont faciles à mettre en place si un code
unique, celui du fantoir, est correctement mis en place.

Le code Fantoir est généré par la DGFiP a posteriori de la création ou
dénomination de la voie faite par les communes. Du coup, les communes qui
gèrent une base de données voirie en interne attendent entre 1 et 3 ans
avant de récupérer ce code, ce qui n’est pas du tout satisfaisant.

L’idée du projet est d’harmoniser cet identifiant mais, comme la BANO ne se
fera pas en 2 jours, ce projet non plus. En théorie, il n’implique pas OSM
parce que beaucoup de communes gèrent ça dans leurs coins mais, à Orange (et
maintenant la CCPRO), nous avons pris le parti d’intégrer OSM dans le projet
parce que ça permet aussi d’améliorer la qualité des données d’OSM.

Pieren wrote
Notez que ça n'est pas la première fois que les expérimentations faites
sur Orange posent questions. C'était déjà le cas en 2013 avec les mêmes
personnes et le ref:FR:commune s'appelait à l'époque ref:orange:
https://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056807.html
mais qu'à l'époque, le ref:FR:fantoir n'existait pas et l'excuse de
l'expérimentation était encore acceptable.

Effectivement, c’est pour cela que j’ai modifié le ref :orange en ref :FR
:Commune. L’expérimentation est toujours en cours et le code FANTOIR n’est
pas parfait. On s’en rendra très vite compte avec la BANO lorsqu’il faudra
faire les mises à jour des adresses.

Ce sujet pourrait sûrement être discuté au prochain SOTM à Brest.

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832597.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

verdy_p wrote
Peux-tu citer une source ouverte (avec une licence compatible) où on peut
contrôler cette données ? Si non, elle n'a rien à faire dans OSM.

Il est un peu vieux parce qu'on n'a pas encore fini notre projet mais ça
devrait te convenir :
https://docs.google.com/spreadsheet/ccc?key=0AvqnfztqzzrOdE16YWpINmdfVm9MaERNWWdqQ09jMHc#gid=0

verdy_p wrote
Tu te dis Administrateur OpenStreetmap.fr mais tu n'en respectes pas les
règles de base.

Je te laisse ton argument, j'ai même pas envie de répondre

verdy_p wrote
Tu te dis Mandataire Grand Sud-Est mais mandataire de qui ?

de l'association OpenStreetMap-France

verdy_p wrote
- Je n'agis pas seul puisqu'on est plusieurs sur le projet

Qui ?

Je te l'ai déjà dit, les 3 grosses intercommunalités de Vaucluse et, je
penses, d'autres qui seront intéressées

verdy_p wrote
- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a
été mal
fait ?

Ce que moi et d'autres corrigent après ton passage qui est bien un
saccage..

Un saccage parce que j'ai fait péter 3 bouts de relations dans le Vaucluse ?
oufff!!! je mérite au moins la prison à perpétuité, là !

verdy_p wrote
- Je discute même pas sur le reste parce que j'ai même pas envie de
m'étaler
là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
concepts
et des projets qui n'ont rien à voir.

Non tu mélanges le projet OSM avec ton projet privé.

Mon projet n'a rien de privé. Je ne gagne pas d'argent dessus et, au
contraire, j'enrichis les données OSM.

verdy_p wrote
Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
échanges privés quand tu commences par me donner un ordre sans rien
expliquer publiquement.

Soit, mais pas au point de faire un vulgaire copier-coller des mails.

verdy_p wrote
Enfin, je crois connaitre le projet BANO largement mieux que toi donc.

On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.

Pourquoi ? tu crois qu'il n'y a que dans la mailing list qu'on discute de
BANO ?

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832593.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 14:41 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Le code Fantoir est généré par la DGFiP a posteriori de la création ou
 dénomination de la voie faite par les communes. Du coup, les communes qui
 gèrent une base de données voirie en interne attendent entre 1 et 3 ans
 avant de récupérer ce code, ce qui n’est pas du tout satisfaisant.

Okay pour ce cas. Mais uniquement pour ce cas où la voirie n'a pas
encore de code fantoir. On peut parfaitement tolérer ce
ref:FR:commune comme une solution transitoire pour satisfaire tout
le monde. Mais en aucun cas, on ne devrait le généraliser à toutes les
voies. Et ça n'exonère pas de le documenter dans le wiki...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 14:09, Tony Emery tony.em...@yahoo.fr a écrit :

  Non tu mélanges le projet OSM avec ton projet privé.

 Mon projet n'a rien de privé. Je ne gagne pas d'argent dessus et, au
 contraire, j'enrichis les données OSM.


L'enrichissement pour mettre des données privées, c'est un projet privé. Tu
n'as donné aucune référence consultable par d'autres. Ces données sont
inutilisables dans l'état. Merci donc de préciser ta source (pour qu'au
moins on puisse vérifier qu'elle est ouverte).

 Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
  échanges privés quand tu commences par me donner un ordre sans rien
  expliquer publiquement.

 Soit, mais pas au point de faire un vulgaire copier-coller des mails.


Enfin, je crois connaitre le projet BANO largement mieux que toi donc.
  On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.

 Pourquoi ? tu crois qu'il n'y a que dans la mailing list qu'on discute de
 BANO ?


Non. Mais ton projet ne semble avoir été discuté nulle part ailleurs non
plus dans le cadre d'OSM.

Certes BANO n'est pas un projet complètement ficelé, mais il progresse, et
vite. Le nombre d'acteurs impliqués (collectivités et administrations)
aussi. Au fur et à mesure on peut voir des problèmes arriver, et on cherche
des solutions (comme partout dans OSM pour divers sujets). Mais c'est un
projet commun dans la lignée aussi du projet OSM plus général (et tout ce
qui est fait pour BANO ne va pas non plus dans OSM, ou pas immédiatement).

La cartographie est riche de règles qui ont toutes leurs nombreuses
exceptions et ce n'est pas facile de maintenir une certaine cohérence, mais
on cherche **même dans les expérimentations** à permettre aux autres aussi
de contribuer/vérifier/corriger/compléter/améliorer. Tout n'est pas
forcément documenté tout de suite mais on cherche malgré tout à rendre les
choses compréhensibles (ce qui n'est pas le cas de ton tag ref:FR:commune
quand justement tu ne parles plus maintenant d'un niveau communal mais d'un
niveau intercommunal !)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

je suis d'accord, ce n'est même pas une référence communale selon la
description donnée par tony, mais une référence propre à la CCPRO

Bref ce devrait plutôt être ref:FR:87:CCPRO=* ou quelquechose du genre
permettant de classer ça.

Je réitère cependant ma demande d'accès public à la source de référence,
sinon cette référence est inutile dans OSM, et même interdite selon les
termes du contributeur d'OSM (que tony a lues et acceptées) et donc
nuisible au projet.

La CCPRO publie-t-elle ça en OpenData ?

Le 5 février 2015 16:56, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
a écrit :

 Le 5 février 2015 16:13, Pieren pier...@gmail.com a écrit :

 2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

  Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
  l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
  supprimer derrière.

 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.

  J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

 Il faudrait aussi voir ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

 Pieren


 Est-ce vraiment une référence qu'on peut qualifier de nationale ?

 Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
 l'ensemble du territoire français et il n'existe pas de répertoire
 officiel géré par un organisme qui en a la charge.

 PY


 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Si c'est juste pour faire une référence croisée privée entre OSM et ta base
propriétaire (qui n'est à ce jour pas ouverte...) je ne vois pas pourquoi
tu crois quie pour le faire tu changes les priorités et veuille remettre à
plus tard ce qui est la base commune, documentée, et discutée.
Les frontières adminsitrative (comme aussi les besoins pour le projet BANO
activement soutenu, ne passent pas en second plan.
Alors forcément je vis très mal que ton premier message a été un ordre
impératif alors que je corrigeais de gros saccages dans ce que tu as fait.
Oui je te reproche de vouloir agir tout seul et le fait de donner un ordre
en privé de ne pas te corriger.
Ce que tu fais sur Orange a été mal fait. Même si ça casse ce que tu
croyais pouvoir faire plus simplement, il va falloir te faire une raison,
et regarder un peu mieux ce qui préserve la compatibilité, pour que ce ne
soit seulement ton appli métier qui marche au détriment de tous les autres.

Ton initiative privée n'a aucun objectif communautaire, même si c'est pour
travailler (en privé) avec les collectivités qui, elles, soutiennent le
projet commun OSM tel qu'il est. Les collectivités pour leurs besoins
propres ont déjà leur propre SIG. BANO est même conçu pour servir de
plateforme d'échange en France. Qui dit échange ne signifie pas non plus
qu'OSM devra tout faire pour se réorienter uniquement sur les solutions
franco-françaises, OSM est mondial.

Mais tu interviens sur beaucoup plus de choses que tu croies. Tes
références privées (ton tag ref:FR:commune est en fait malvenu, car il
n'est franchement pas issu des données publiques des communes, on n'importe
pas le contenu des SIG communaux ou intercommunaux tels quels, ni même
celles du cadastre : c'est une obligation qu'on a sur OSM de faire un
important travail de fusion, de reclassement).
Ce n'est pas facile, ça demande du temps, mais petit à petit on y arrive.

Et il n'y a pas d'urgence, le développement d'OSM n'est pas lié au
calendrier d'un projet privé. Si tu as des urgences à gérer, fais comme les
communes, crée ton propre SIG métier où tu feras ce que tu veux.

Si tu veux une meilleure intégration de tes données, dans OSM, tu n'as pas
le choix, tu dois le documenter pour que les autres puisse le comprendre
(et les références externes dans OSM n'ont de réel intérêt que si elles
permettent d'accéder à des données accessibles par le public, même si elles
ne sont pas totalement ouvertes, elles doivent servir avant tout à
*n'importe qui* de pouvoir faire des vérifications, ce qui n'est pas
possible pour ton projet qui n'a aucune ouverture publique, qui n'a pas de
nom, et d'ailleurs tu n'as même pas voulu citer l'entreprise pour laquelle
tu fais ça : un aménageur comme Bouygues ou Bolloré ? un distributeur d'eau
? un groupe postal ou logistique privé ? A-t-on moyen d'y trouver un
contact officiel autre que ta propre personne qui ici agit de façon isolée
en ton propre nom ?)


Le 5 février 2015 11:26, Tony Emery tony.em...@yahoo.fr a écrit :

 Bonjour à tous,

 Comme certains le savent, je pilote un projet (il est vrai local) pour
 essayer de constituer une base de données voirie + adresses à terme qui
 puisse être interopérable par différents partenaires.

 Après avoir fait ce travail sur Orange (et je pense que cela a bien était
 fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze
 et
 j'applique cette méthode aux 6 autres communes, sachant que je travaille
 aussi avec mes homologues des territoires voisins pour faire de même.

 C'est vrai que la constitution de cette base a provoqué des dégâts au
 niveau
 des limites administratives. J'essaye de les corriger quand je les vois.

 En quelques mots, le projets vise à :
 - recenser toutes les voies de l'interco en croisant les bases de données
 différentes et les connaissances locales ;
 - créer des relations de type associatedStreet sur l'ensemble de ces voies
 et favoriser les liens entre OSM et d'autres applications ;
 - importer les adresses via le plugin http://cadastre.openstreetmap.fr/

 On a recenser toutes les voies des 7 communes de la CCPRO
 On a créer les relation associatedStreet sur 5 des 7 communes
 On a importer les adresses de 5 des 7 communes

 Un fois qu'on aura fini, on controlera les limites administratives
 (d'ailleurs, il faudra modifier les cantons).

 Dans une deuxième étape, on va travailler avec les agents pour qualifier le
 revêtement, les limitations de vitesse et de gabarit, la circulation douce,
 l'éclairage et les gestionnaires des voies.

 Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
 pour dire que ça peut être utile dans OpenStreetMap ?
 Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?


Peux-tu citer une source ouverte (avec une licence compatible) où on peut
contrôler cette données ? Si non, elle n'a rien à faire dans OSM.

Tu te dis Administrateur OpenStreetmap.fr mais tu n'en respectes pas les
règles de base.
 Tu te dis Mandataire Grand Sud-Est mais mandataire de qui ?
   - Je n'agis pas seul puisqu'on est plusieurs sur le projet

Qui ?

- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été mal
 fait ?


Ce que moi et d'autres corrigent après ton passage qui est bien un saccage..


 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.


Non tu mélanges le projet OSM avec ton projet privé.


 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).


Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
échanges privés quand tu commences par me donner un ordre sans rien
expliquer publiquement.


 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.


On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.


 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet Pierre-Yves Berrard

Le 5 février 2015 16:13, Pieren pier...@gmail.com a écrit :

 2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

  Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
  l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
  supprimer derrière.

 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.

  J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

 Il faudrait aussi voir ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

 Pieren


Est-ce vraiment une référence qu'on peut qualifier de nationale ?

Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
l'ensemble du territoire français et il n'existe pas de répertoire
officiel géré par un organisme qui en a la charge.

PY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet Vincent de Château-Thierry



Le 05/02/2015 18:04, Tony Emery a écrit :


Voici mon premier mail, dites-moi en quoi il est agressif :
Bonjour Philippe,

(...)

tu ajoute les tags admin_level et boundary sur le tronçon alors que c'est en
doublon avec le fait que ce tronçon fait partie d'une relation de type
boundary
Il faut que tu corriges absolument ces erreurs sur l'ensemble de ton groupe
de modification car nous ne pouvons plus réutiliser ces données par la
suite.


Ajouter les tags admin_level et boundary sur un tronçon, highway ou pas, 
n'a rien d'une erreur dès lors que ce way est membre d'une relation 
boundary=administrative. Et si au passage ça permet de rappeler, en 
cours d'édition, qu'on manipule une route (ou une rivière, etc.) *qui 
est aussi une limite*, ça me semble un garde-fou pas inutile. Il faut se 
rappeler que Potlatch 2 et iD sont muets quand on efface un membre de 
relation. JOSM en revanche, prévient, ce qui devrait limiter la casse.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Je tiens quand même à rappeler que l'intégration des tags ref:FR:Communes n'a
rien à voir avec mes erreurs de saccages massifs et honteux méritant la
correctionnelle. D'ailleurs, ces identifiants ont été intégrés avant et
n'ont eu aucune incidence.

C'est juste au moment de la création des relations associatedStreet au
cours de laquelle j'ai voulu corriger les tracés des voies que j'ai
supprimer par mégarde certains objets appartenant à d'autres relations.

Je comprends que p_verdy ait eu envie de corriger ça, avec d'autres
contributeurs. Ce que je ne comprend pas c'est pourquoi, en corrigeant les
relations, il a voulu supprimer le tag ref:FR:Communes qui est présent sur
l'objet et non sur la relation.

Par ailleurs, j'ai bien pris soins d'ajouter les code FANTOIR dans les
relations associatedStreet au moment de l'intégration des adresses, histoire
que l'on ne me taxe pas de fonctionnaire anti-fantoir.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832603.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 14:05, Pieren pier...@gmail.com a écrit :

 Sinon,
 concernant les échanges épistolaires de Philippe, on le connait ici
 très bien et il sait déjà qu'il gagnerait beaucoup à être moins
 agressif dans le choix de ses expressions mais qu'il ne changera
 jamais de ce côté là.


Tu n'as pas lu son tout premier message très agressif qu'il m'a envoyé et
plein de capitales, très agressif dès le premier contact (via la messagerie
interne d'OSM), sur le ton de l'ordre impératif.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
 l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
 supprimer derrière.

L'intérêt est que l'usage de ce code resterait très limité (par
exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
les autres communes françaises.

 J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
 http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

Il faudrait aussi voir ici:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Ce qui est agressif ce sont les mots TRES GROS, il faut, absolument.

Note bien aussi que cela concernait des voies qui ne sont _pas_seulement_
des limites des communes membres de la CCPRO (cela s'étendait aussi à
d'autres intercommunalités voisines, d'autres arrondissements, ou même le
département, la région, les cantons, qui eux n'ont aucun rapport avec ton
identifiant posé sur les voies partagées, pour un usage propre à quelques
intercommunalités (même si en interne ce sont les SIG des communes membres
qui les créent et les utilisent en se mettant d'accord via
l'intercommunalité pour rapprocher leurs bases).

Comme pour les relations prises en compte pour la BANO (des discussions sur
les corrections possibles des outils sont encore en cours), il te faudra le
migrer sur les relations propres à chaque commune (celle que tu indiques
par le code INSEE inséré dan ton identifiant). Je t'ai expliqué ça mais tu
n'as pas voulu écouter ou comprendre que cela crée des ambiguités ou
conflits (et ce ne sont que ces ambiguïtés/conflits qui posent problème
justement sur les voies intercommunales et notamment avec les communes qui
ne sont pas associées à l'objet de ton projet).

En attendant que l'outil de rapprochement de BANO comprenne, on a le même
problème d’ambiguïté avec ton code que pour le code FANTOIR et les adresses
postales de la BANO (et plus largement du schéma mondial de Karlsruhe pour
les tags des adresses) si tu le mets sur les voies en limite
intercommunales (ou proches de ces limites car il y a aussi des écarts, et
on en a discuté très récemment ici aussi, pour BANO).

Je réitère ma demande : quelle est la source accessible pour ces
identifiants (cela fait plusieurs fois que je te pose la question) ? Mets
ça sur la page wiki [[Vaucluse/voirie]] (tu n'es pas obligé de me répondre
directement à moi seul ou juste à cette liste, cette page suffit si tu la
complètes). C'est indispensable (pour qu'au moins on puisse valider la
licence relative à ces données internes pour l'instant pas accessibles). Là
il te faudra bien demander l'accord des collectivités concernées, tu ne
PEUX PAS te passer de leur accord.


Le 5 février 2015 18:04, Tony Emery tony.em...@yahoo.fr a écrit :

 Désolé, je précise, : Moi ou toute personne que tu aurais voulu et qui
 était
 à l'origine de l'intégration de ce tag dans l'objet, information que tu
 aurais pu relever en consultant l'historique de l'objet en question...
 C'est vrai qu'il y a des personnes adeptes des très longues phrases...

 J'ai passé la soirée hier a recorriger les relations que j'avais cassé,
 donc
 je n'ai rien brisé derrière.

 Voici mon premier mail, dites-moi en quoi il est agressif :
 Bonjour Philippe,
 Je viens de voir que tu as fait des modifications pour rattraper le
 contours
 administratif de certaines zones du côté du Vaucluse.
 Or, il y a 2 TRES GROS problèmes dans tes modifications : exemple Chemin de
 Saint-Roman (96962494)
 tu as supprimé le tag ref:FR:commune de certains tronçons de voie alors que
 pour nous cette information est primordiale et à laisser sur le tronçons de
 la voie.
 tu ajoute les tags admin_level et boundary sur le tronçon alors que c'est
 en
 doublon avec le fait que ce tronçon fait partie d'une relation de type
 boundary
 Il faut que tu corriges absolument ces erreurs sur l'ensemble de ton groupe
 de modification car nous ne pouvons plus réutiliser ces données par la
 suite.
 Par la suite, si tu dois faire des modifications sur ce territoire, merci
 de
 bien vouloir me contacter afin de ne pas détruire ce que nous avons mis en
 place.
 Bonne réception,
 Tony EMERY




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832624.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
 2015-02-05 15:17 GMT+01:00 Tony Emery lt;

 tony.emery@

 gt;:
 
 Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
 l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
 supprimer derrière.
 
 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.
 
 J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
 lt;http://wiki.openstreetmap.org/wiki/Vaucluse/voiriegt;
 
 Il faudrait aussi voir ici:
 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Et bien tu vois, mon ref:FR:Commune est un peu comme le ref:FR:BSPP:=*
des Casernes de sapeurs-pompiers de Paris et petite couronne.

Pour le moment, il y a la CCPRO et le Grand Avignon, et après on verra pour
que d'autres territoires en fasse de même...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832622.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 16:56 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com:

 Est-ce vraiment une référence qu'on peut qualifier de nationale ?

 Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
 l'ensemble du territoire français et il n'existe pas de répertoire
 officiel géré par un organisme qui en a la charge.

A priori, rien n'empêche d'utiliser ce tag dans d'autres communes.
Mais je suis d'accord, le titre du wiki est maladroit. On devrait dire
liste des tags ref spécifiques à la France

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 17:15, Tony Emery tony.em...@yahoo.fr a écrit :

 Donc, à défaut de comprendre comment ça marche et malgré ma « grossière
 erreur pécher mortel » de ne pas avoir documenté ce tag, tu aurais dû me
 contacter avant de le supprimer, quand bien même ce tag TE sembles
 incohérent.


Pourquoi aurais-je du te contacter TOI précisément ? Alors que ce n'était
qu'une toute petite poignée de ces tags qui ne concernaient justement QUE
les frontières incommunales que tu avais brisées un peu partout (et bon
nombre des autres relations dépendantes avec).

Bref de là à marquer dans ton message Gros problème de correction, et
ensuite envoyer un ordre sans rien expliquer et continuer à défaire les
corrections tout à fait légitimes pour briser à nouveau nos relations
partagées... Tu aurais pu au lieu de ce ton agressif et sans même prendre
le temps de te présenter, au moins demander des explications. Je n'ai
honnètement commis aucune erreur, et je le maintiens, il n'y avait
strictement aucun problème dans ce changeset et tu l'as prouvé toi-même
(mais un peu tard).

Et j'ai été correct dans mes messages alors même que tu a continué le ton
agressif dans les réponses suivantes.
Il a fallu que j'insiste pour que tu vienne en parler ici, ce que tu ne
t'es décidé à faire que quand c'est finalement moi qui ait transmis (parce
que tu coupais court à toute discussion et continuait à me donner des
ordres), et je t'avais prévenu à plusieurs reprises (sans même pourtant
revenir à nouveau sur tes modifs suivantes elles aussi imposées sans que tu
changes la moindre façon de faire). Je ne vois pas à quel titre je serais
le seul concerné, dès lors que tu crois que ces données posent problème à
quelqu'un d'autre, c'est juste tombé sur moi, ça aurait pu être un autre et
cela a déjà été le cas).

Heureusement que j'ai posté ici, au moins maintenant tu ébauches une
documentation sur le wiki (avec des tas d'erreurs encore à corriger, y
compris les noms de tag que tu indiques).

Mais toujours SANS documenter correctement ton ref:FR:commune et comment
il est attribué dans le cas des voies intercommunales. Tu mentionnes juste:
  Identifiant unique. Code INSEE Commune + V + identifiant sur 6
caractères. A mettre dans l'objet.
OK mais ça ne suffit toujours pas (quelle commune?), et il n'y a toujours
AUCUNE source publiquement accessible permettant de valider ça (bref là
encore tu exposes ce tag à des suppressions tout à fait légitimes sur les
voies intercommunales).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Bonjour à tous,

Comme certains le savent, je pilote un projet (il est vrai local) pour
essayer de constituer une base de données voirie + adresses à terme qui
puisse être interopérable par différents partenaires.

Après avoir fait ce travail sur Orange (et je pense que cela a bien était
fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze et
j'applique cette méthode aux 6 autres communes, sachant que je travaille
aussi avec mes homologues des territoires voisins pour faire de même.

C'est vrai que la constitution de cette base a provoqué des dégâts au niveau
des limites administratives. J'essaye de les corriger quand je les vois.

En quelques mots, le projets vise à :
- recenser toutes les voies de l'interco en croisant les bases de données
différentes et les connaissances locales ;
- créer des relations de type associatedStreet sur l'ensemble de ces voies
et favoriser les liens entre OSM et d'autres applications ;
- importer les adresses via le plugin http://cadastre.openstreetmap.fr/

On a recenser toutes les voies des 7 communes de la CCPRO
On a créer les relation associatedStreet sur 5 des 7 communes
On a importer les adresses de 5 des 7 communes

Un fois qu'on aura fini, on controlera les limites administratives
(d'ailleurs, il faudra modifier les cantons).

Dans une deuxième étape, on va travailler avec les agents pour qualifier le
revêtement, les limitations de vitesse et de gabarit, la circulation douce,
l'éclairage et les gestionnaires des voies.

Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
pour dire que ça peut être utile dans OpenStreetMap ?
Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832562.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet François Lacombe

Je ne trouve pas de documentation sur ref:FR:commune.

D'où sont tirées ces valeurs ?

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 13:17, François Lacombe fl.infosrese...@gmail.com a
écrit :

 +1 Tony, keep going.

 *François Lacombe*

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux

 Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?
 - Je n'agis pas seul puisqu'on est plusieurs sur le projet
 - Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été
 mal
 fait ?
 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.

 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).

 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet François Lacombe

Bonjour,

Je trouve très positive l'utilisation d'identifiants métiers externes à OSM
sur certains objets.

Tout simplement parce que cela permet de suivre ces objets en cas de
suppression/création sous une autre forme ensuite.

Si cela se limite à l'identifiant pour faire le lien avec un référentiel
externe, c'est tout à fait pertinent.
Après pour l'ajout de données plus privées, c'est autre chose mais je ne
crois pas que ce soit ce qui est fait par Tony.

A+

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 10:11, Vincent de Château-Thierry osm.v...@free.fr a
écrit :

 Bonjour,

  De: Philippe Verdy verd...@wanadoo.fr
 
  Visiblement il utilise OSM comme si c'était un SIG privé.

 Je doute que ça soit son intention. Mais Tony pousse l'utilisation d'OSM
 dans ses retranchements, en couplant les données OSM et ses référentiels
 métier,au sein de sa collectivité.
 Je l'ai alerté sur les relations cassées, j'en ai aussi réparé quelques
 unes depuis 24h.
 Pour ce qui est de tags tels que ref:FR:commune, si ça répond à son
 besoin, alors pourquoi pas. Mais il y a une limite à l'exercice : si ça
 n'est pas documenté, alors d'autres contributeurs n'auront pas de moyen de
 comprendre de quoi il retourne et ça n'aidera pas à la maintenance de ces
 tags, ni des objets qui les portent. Donc si Tony et lui seul en a l'usage,
 à lui avant tout de s'en donner les moyens en documentant ce qu'il fait de
 manière accessible aux contributeurs.

 vincent

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Alors on va essayer de faire simple.

- Je ne vois pas en quoi j'ai demandé de changer des priorités ?
- Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
quand j'ai fini, parce que mine de rien c'est un boulot énorme.
- Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
identifiant à la source de la création de la voie, c'est à dire au niveau
des communes.
- Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
sur les objets ?
- Je n'agis pas seul puisqu'on est plusieurs sur le projet
- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été mal
fait ?
- Je discute même pas sur le reste parce que j'ai même pas envie de m'étaler
là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des concepts
et des projets qui n'ont rien à voir.

Par contre, je trouve très déplacé de ta part de copier sur une mailing
liste une discussion qui est privée (entre toi et moi).

Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet Vincent de Château-Thierry

Bonjour,

 De: Philippe Verdy verd...@wanadoo.fr
 
 Visiblement il utilise OSM comme si c'était un SIG privé.

Je doute que ça soit son intention. Mais Tony pousse l'utilisation d'OSM dans 
ses retranchements, en couplant les données OSM et ses référentiels métier,au 
sein de sa collectivité. 
Je l'ai alerté sur les relations cassées, j'en ai aussi réparé quelques unes 
depuis 24h.
Pour ce qui est de tags tels que ref:FR:commune, si ça répond à son besoin, 
alors pourquoi pas. Mais il y a une limite à l'exercice : si ça n'est pas 
documenté, alors d'autres contributeurs n'auront pas de moyen de comprendre de 
quoi il retourne et ça n'aidera pas à la maintenance de ces tags, ni des objets 
qui les portent. Donc si Tony et lui seul en a l'usage, à lui avant tout de 
s'en donner les moyens en documentant ce qu'il fait de manière accessible aux 
contributeurs.
 
vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet Jo

Salut Tony,

Décrit de cette façon-là, je pense que vos contributions ont certainement
mérite et nous devrions être content que vous voulez les apporter. Je suis
convaincu qu'il sera possible de trouver un moyen pour travailler ensemble,
qui peut satisfaire tout le monde concerné.

Salutations,

Polyglot

2015-02-05 11:26 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Bonjour à tous,

 Comme certains le savent, je pilote un projet (il est vrai local) pour
 essayer de constituer une base de données voirie + adresses à terme qui
 puisse être interopérable par différents partenaires.

 Après avoir fait ce travail sur Orange (et je pense que cela a bien était
 fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze
 et
 j'applique cette méthode aux 6 autres communes, sachant que je travaille
 aussi avec mes homologues des territoires voisins pour faire de même.

 C'est vrai que la constitution de cette base a provoqué des dégâts au
 niveau
 des limites administratives. J'essaye de les corriger quand je les vois.

 En quelques mots, le projets vise à :
 - recenser toutes les voies de l'interco en croisant les bases de données
 différentes et les connaissances locales ;
 - créer des relations de type associatedStreet sur l'ensemble de ces voies
 et favoriser les liens entre OSM et d'autres applications ;
 - importer les adresses via le plugin http://cadastre.openstreetmap.fr/

 On a recenser toutes les voies des 7 communes de la CCPRO
 On a créer les relation associatedStreet sur 5 des 7 communes
 On a importer les adresses de 5 des 7 communes

 Un fois qu'on aura fini, on controlera les limites administratives
 (d'ailleurs, il faudra modifier les cantons).

 Dans une deuxième étape, on va travailler avec les agents pour qualifier le
 revêtement, les limitations de vitesse et de gabarit, la circulation douce,
 l'éclairage et les gestionnaires des voies.

 Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
 pour dire que ça peut être utile dans OpenStreetMap ?
 Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832562.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Par sujet François Lacombe

+1 Tony, keep going.

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?
 - Je n'agis pas seul puisqu'on est plusieurs sur le projet
 - Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été
 mal
 fait ?
 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.

 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).

 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712