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

Le 12 février 2015 23:01, Tony Emery  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

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 22:21, Tony Emery  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 17:59, Tony Emery  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

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 Christian Rogel


> Le 12 févr. 2015 à 17:59, Tony Emery  a écrit :
> 
> 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…..

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

Christian R.

___
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

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

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  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
> s

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

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 :

> 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

2015-02-12 Par sujet Christian Rogel


> Le 12 févr. 2015 à 11:19, Christian Quest  a écrit :
> 
> Stéphane, ta conclusion est la bonne...
> 
> En fait le DGFiP devrait déléguer la création des codes de voirie
> uniques au communes.
> Bon, ça c'est l'idéal, mais n'oublions pas que l'immense majorité des
> communes sont très petites et sans moyens pour gérer ça. Du coup on
> arrive rapidement à un gros bazar dans les données ainsi produites.

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.
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.).


Christian R.___
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 Christian Quest

Stéphane, ta conclusion est la bonne...

En fait le DGFiP devrait déléguer la création des codes de voirie
uniques au communes.
Bon, ça c'est l'idéal, mais n'oublions pas que l'immense majorité des
communes sont très petites et sans moyens pour gérer ça. Du coup on
arrive rapidement à un gros bazar dans les données ainsi produites.

Mais bon, dans nos réunions autour de la BAN, c'est un sujet que
j'aborde régulièrement... ça et aussi le COG de l'INSEE et sa
publication décalée.

A ce (dernier) sujet j'ai écrit un petit billet de blog:
https://cquest.hackpad.com/Millsimons--Lf9LGG75tTh

Le 12/02/2015 11:09, Stéphane Péneau a écrit :
> Bonjour Tony,
>
> Si je comprends bien :
> - Les codes Fantoir auront toujours plusieurs mois ou années de retard
> sur les décisions des communes.
> - On aura donc toujours de la nouvelle voirie présente sur le terrain,
> sans code Fantoir existant.
> - Des collectivités utilisant osm peuvent avoir besoin d'un
> identifiant pour ces nouvelles voies.
> - Le code Fantoir n'étant pas encore créé, il en faut un autre.
>
> Tu parles du schéma de voirie communale qui s'imposera à tous, donc
> toutes les communes devront créer pour leurs nouvelles voies quelque
> chose qui ressemblera à ce que vous faites avec ref:FR:commune ?
>
> Si oui, dans l'idéal Il faudrait donc un code SUPERFANTOIR, créé par
> les communes, et construit de manière identique sur tout le pays.
>
> Finalement, une fois le code superfantoir mis en place, le code
> fantoir deviendrait superfétatoire.
>  désolé...pas résisté
>
> Stf
>
> Le 12/02/2015 10:17, Tony Emery a écrit :
>> Pour répondre (un peu) à Philippe, ce que j’essaye de vous faire
>> comprendre
>> c’est que la dénomination des voies reste la compétence de la commune et
>> seulement de la commune. C’est donc la source la plus proche de la
>> réalité
>> que nous puissions avoir, notamment parce que la dénomination des
>> voies font
>> l’objet d’une délibération au conseil municipal. Cette délibération
>> est le
>> seul document qui fait foi et qui peut être consultée en cas de doute
>> sur la
>> toponymie (erreur sur une carte, sur une plaque de rue ou autre).
>>
>> 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
>>
>>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France


___
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 Stéphane Péneau

Bonjour Tony,

Si je comprends bien :
- Les codes Fantoir auront toujours plusieurs mois ou années de retard
sur les décisions des communes.
- On aura donc toujours de la nouvelle voirie présente sur le terrain,
sans code Fantoir existant.
- Des collectivités utilisant osm peuvent avoir besoin d'un identifiant
pour ces nouvelles voies.

- Le code Fantoir n'étant pas encore créé, il en faut un autre.

Tu parles du schéma de voirie communale qui s'imposera à tous, donc
toutes les communes devront créer pour leurs nouvelles voies quelque
chose qui ressemblera à ce que vous faites avec ref:FR:commune ?

Si oui, dans l'idéal Il faudrait donc un code SUPERFANTOIR, créé par les
communes, et construit de manière identique sur tout le pays.

Finalement, une fois le code superfantoir mis en place, le code fantoir
deviendrait superfétatoire.

désolé...pas résisté

Stf

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

Pour répondre (un peu) à Philippe, ce que j’essaye de vous faire comprendre
c’est que la dénomination des voies reste la compétence de la commune et
seulement de la commune. C’est donc la source la plus proche de la réalité
que nous puissions avoir, notamment parce que la dénomination des voies font
l’objet d’une délibération au conseil municipal. Cette délibération est le
seul document qui fait foi et qui peut être consultée en cas de doute sur la
toponymie (erreur sur une carte, sur une plaque de rue ou autre).

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

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.

-
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

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

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

Oh mon Dieu quelle agressivité de ma part ! J’ai mis 2 mots en majuscule et
j’ai dit « il faut absolument », Belzébut, sors de ce corps…

Je n’ai jamais utilisé ce tag ailleurs que dans les 7 communes de la CCPRO,
sauf erreur grossière de ma part et qui mérite sûrement un autoflagélation.
Pour info, il n’y a pas de SIG dans les communes de la CCPRO. Le SIG est
dans l’interco. Cette base n’est pas seulement utilisée par notre interco
puisque, vu qu’elle est intégrée à OSM, elle est utilisée par d’autres
partenaires.

Les relations que j’ai créées dans OSM sont issues du site
http://cadastre.openstreetmap.fr/ qui est très bien documenté ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses
Je pense que tu confonds le gestionnaire de la voie qui peut, par exemple,
être identifié par le tag operator, et la commune où se trouve la voie. Et,
je regrette mais oui, dans une interco, quand une voie fait office de limite
de commune, elle n’est recensée que dans pour des 2 communes, afin d’éviter
les doublons. Et dans la vrai vie, les agents qui interviennent sur ce genre
de voie ne le font pas que d’un côté. C’est une des 2 communes qui en a la
charge. Après, pour la dénomination de la voie ça peut être différent, mais
c’est quand même rare je pense. Au pire, on pourra toujours mettre un :left
ou un :right si vraiment ça pose problème.

Tu n’auras pas de problème avec mon code puisque c’est la commune qui le
fournira. Donc, je ne vois pas où est le problème, sauf a en créer un là où
il n’y en a pas.

Alors moi te dire plus simple. Officiel Voies Orange être disponible en
ligne adresse suivante :
https://docs.google.com/spreadsheet/ccc?key=0AvqnfztqzzrOdE16YWpINmdfVm9MaERNWWdqQ09jMHc#gid=0
identifiant expliqué page 1
licence d’utilisation page 2
base de données voirie page 3, identifiant colonne 4
Tu peux même cliquer sur les liens « localiser », tu verras, c’est magique !
mais c’est perfectible…

Vu que je travaille dans cette collectivité (et oui, je ne suis pas une
boîte privé à la solde de Véolia) et que c’est moi qui ai mis en place ce
projet dans ma collectivité, je te donne l’autorisation de la réutiliser
(bon seigneur que je suis).

Je ne sais que dire de plus….

-
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-tp5832528p5832632.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

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

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

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

Pieren wrote
> 2015-02-05 15:17 GMT+01:00 Tony Emery <

> tony.emery@

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

> 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

Mon action sur la qualification de la voirie ne consiste pas seulement à
intégrer des identifiants uniques. Je qualifie la voirie manquante, corrige
les noms à partir des délibérations des mairies, ajoute les adresses,
qualifie l’occupation des sols, le mobilier urbains, l’activité économique,
etc….

Je pense que, avec Jean-Louis Zimmermann, notre travail a fait d’Orange un
territoire remarquable en termes de qualité de la donnée sur OSM et des
usages exploitant ces données.
Par exemple :
http://lizpoi.3liz.com/orange/index.php/lizpoi/map/?tree_id=7&selected=

Toute création de données géographique sur notre territoire est presque
systématiquement importer, voire directement créée dans OSM. Il ne doit pas
y avoir beaucoup de collectivité en France qui en sont à ce degré
d’ouverture au public de leurs données géographiques.

Maintenant, je pousse d’autres collègues autour de nous pour qu’ils
contribuent dans OpenStreetMap, participe à des forums et des conférences
pour promouvoir OSM et forme des étudiants à devenir les futurs
contributeurs.

Donc non, mon travail n’est pas privé, je confirme.

Alors mea culpa pour ne pas avoir « documenté » le tag « ref :FR :Commune »
qui doit représenter 5% de mon travail sur OSM. Un projet est ouvert ici
http://wiki.openstreetmap.org/wiki/Vaucluse/voirie et il ne concerne pas que
le tag « ref :FR :Commune ».

Ma source, c’est les 7 communes de la CCPRO pour laquelle je travaille et
que tu trouveras dans la table que j’ai mis à disposition librement et
gratuitement sur Internet et pour lequel je t’ai donné le lien quelques
posts plus haut.

Quant au projet BANO, je m’y intéresse depuis que cquest a lancé l’idée, on
a fait une réunion au dernier SOTM France à Paris, on en parle régulièrement
en CA et j’ai participé au BANO Tour à Aix en fin d’année dernière. Donc on
en parle tout autant ailleurs que sur la mailing list. Pour que tu voies que
ça avance de notre côté :
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#13/44.0782/4.8582
Faisant partie d’une collectivité, tu remarqueras que oui, j’y suis
fortement impliqué et, encore une fois, je pense maitriser plus que toi le
problème.

Quant au niveau « intercommunal » du tag ref :FR:Commune, dans la mesure où
les interco récupèrent de plus en plus la compétence voirie et mutualise
leurs SIG, ce tag va devoir effectivement évoluer mais pas tant que la
nomination de la voirie reste une compétence mairie. Il n’empêche que la
constitution de l’identifiant unique se fera là où se trouve la compétence
SIG. 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.

Ai-je assez « discuté » avec toi ?

-
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-tp5832528p5832619.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

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 
a écrit :

> Le 5 février 2015 16:13, Pieren  a écrit :
>
>> 2015-02-05 15:17 GMT+01:00 Tony Emery :
>>
>> > 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
>> > 
>>
>> 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

2015-02-05 Par sujet Pierre-Yves Berrard

Le 5 février 2015 16:13, Pieren  a écrit :

> 2015-02-05 15:17 GMT+01:00 Tony Emery :
>
> > 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
> > 
>
> 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 15:17 GMT+01:00 Tony Emery :

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

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

Je ne l'ai pas oté partout. juste sur les ways frontières entre DEUX
communes. Comme ton tag n'était pas explicite et visiblement n'a rien à
voir avec une référence *communale*, il est juste incohérent. Normal qu'un
autre qui ne comprend pas du tout ce que tu fais (et n'a aucun moyen de le
faire) le vire sur une frontière communale quand c'est justement cela
concerne DEUX et non UNE SEULE commune.

Je n'ai pas fait d'erreur, et s'il y en a elle n'est que chez toi parce que
tu as omis de documenter et expliquer avant.

Mais non, tu as juste envoyé un ordre tout de suite et coupé court toute
discussion immédiatement (et tu continues encore à le faire ici en disant
"je ne veux pas discuter").


Le 5 février 2015 15:29, Tony Emery  a écrit :

> 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
>
___
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  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

Le 5 février 2015 14:05, Pieren  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

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

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
  




-
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

2015-02-05 14:41 GMT+01:00 Tony Emery :

> 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

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 13:17 GMT+01:00 François Lacombe :
> +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

Le 5 février 2015 13:13, Tony Emery  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 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 

Le 5 février 2015 13:17, François Lacombe  a
écrit :

> +1 Tony, keep going.
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 5 février 2015 13:13, Tony Emery  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

+1 Tony, keep going.

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 5 février 2015 13:13, Tony Emery  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

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

> 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

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  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:
> http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe

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