[OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Damouns 
Bonjour à tous,

Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus)
ont été publiés depuis cet été sur Légifrance pour annoncer la fusion
de communes françaises en "communes nouvelles". La plupart d'entre eux
prennent effet à compter du 1er janvier 2013.

Il me semble qu'on peut intégrer ça le jour J dans la base OSM en
créant pour chacune une nouvelle relation admin_level=8 suivant les
nouveaux contours. Je me pose la question de la conservation des
anciennes communes en relations de niveau admin_level=10. Faut-il les
garder de cette façon ou non ? En effet celles-ci subsistent
normalement sous forme de « communes déléguées » (je m'attends à une
réaction argumentée et développée de Philippe Verdy !! Mais les autres
peuvent aussi donner leur avis bien sûr ;-)

Et j'appelle donc des volontaires pour traiter les communes
concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici
par département :

== dans le Maine-et-Loire ==

1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une
commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé.
(Référence : Arrêté du 14 septembre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873

2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en
une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs.
(Référence : Arrêté du 19 novembre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876

3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de
Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune
nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté
du 30 mars 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218

== dans les Deux-Sèvres ==

Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres),
en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin.
(Référence : Arrêté du 12 novembre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106

== dans le Rhône ==

Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de
Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle
appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29
octobre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902

== dans les Hautes-Alpes ==

1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et
Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle
appelée Saint-Bonnet-en-Champsaur, chef-lieu
Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005

2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de
Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une
commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy.
(Référence : Arrêté du 2 octobre 2012)
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090


Damouns

PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut
prendre celui de l'ancienne commune du chef-lieu ?

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

Re: [OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Francescu GAROBY 
Bonjour,
Le même jour, plusieurs EPCI vont aussi évoluer : je peux au moins citer
Caen-la-Mer (14 - Calvados) et la Communauté Urbaine d'Alençon (61 - Orne).
Je compte m'en occuper, mais ce sera plutôt le 2 janvier... afin d'éviter
toute erreur due à l'alcool ! ;-)

Francescu

Le 17 décembre 2012 11:44, Damouns  a écrit :

> Bonjour à tous,
>
> Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus)
> ont été publiés depuis cet été sur Légifrance pour annoncer la fusion
> de communes françaises en "communes nouvelles". La plupart d'entre eux
> prennent effet à compter du 1er janvier 2013.
>
> Il me semble qu'on peut intégrer ça le jour J dans la base OSM en
> créant pour chacune une nouvelle relation admin_level=8 suivant les
> nouveaux contours. Je me pose la question de la conservation des
> anciennes communes en relations de niveau admin_level=10. Faut-il les
> garder de cette façon ou non ? En effet celles-ci subsistent
> normalement sous forme de « communes déléguées » (je m'attends à une
> réaction argumentée et développée de Philippe Verdy !! Mais les autres
> peuvent aussi donner leur avis bien sûr ;-)
>
> Et j'appelle donc des volontaires pour traiter les communes
> concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici
> par département :
>
> == dans le Maine-et-Loire ==
>
> 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une
> commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé.
> (Référence : Arrêté du 14 septembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873
>
> 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en
> une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs.
> (Référence : Arrêté du 19 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876
>
> 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de
> Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune
> nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté
> du 30 mars 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218
>
> == dans les Deux-Sèvres ==
>
> Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres),
> en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin.
> (Référence : Arrêté du 12 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106
>
> == dans le Rhône ==
>
> Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de
> Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle
> appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29
> octobre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902
>
> == dans les Hautes-Alpes ==
>
> 1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et
> Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle
> appelée Saint-Bonnet-en-Champsaur, chef-lieu
> Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005
>
> 2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de
> Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une
> commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy.
> (Référence : Arrêté du 2 octobre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090
>
>
> Damouns
>
> PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut
> prendre celui de l'ancienne commune du chef-lieu ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Pieren 
2012/12/17 Damouns :

> PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut
> prendre celui de l'ancienne commune du chef-lieu ?

Justement, le site de l'INSEE fournit un outil bien plus pratique que
legifrance (pour nous):
http://www.insee.fr/fr/methodes/nomenclatures/cog/historique.asp

Comme tu le verras, les changements de limites communales ne se
limitent pas qu'aux fusions.

> (je m'attends à une
> réaction argumentée et développée de Philippe Verdy !!

Ah bon. Il y a encore quelqu'un pour le lire ? J'espère que tu es
capable de faire le tri parce qu'il y a beaucoup de faux dans ce qu'il
raconte et j'ai cessé de perdre mon temps là-dessus.

Pieren

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

Re: [OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Mickaël Guéret 
Salut,

je m'occuperais de Saint-clémentin et Voultegon, c'est juste à coté de
chez moi !

Pour les limites de niveau 10... je ne sais pas, mais il me semble qu'il
y a une différence entre les communes associées et fusionnées. Je ne me
suis pas documenté là dessus, mais par exemple, ma commune est issue de
la fusion de Nueil et Les Aubiers, on a bien une nouvelle commune, avec
une seule mairie et tout et tout [1]... Je ne vois pas l'intérêt des
limites de niveau 10 dans ce cas, si ce n'est raviver d'anciennes
querelles de clocher ! ;-)

Juste à coté, Bressuire et Mauléon ont par contre "phagocytés" les
petites communes aux alentours, qui sont dites associées [2 et 3]. Ces
communes peuvent quitter l'association et redevenir indépendante.
J'aurais trouvé pertinent de conserver les limites dans ce cas, avec un
niveau inférieur à la commune (pourquoi pas 10). Mais ça a déjà été
discuté plusieurs fois sur cette liste il me semble.

Mika
[1] http://fr.wikipedia.org/wiki/Nueil_Les_Aubiers#D.C3.A9mographie
[2] http://fr.wikipedia.org/wiki/Maul%C3%A9on_%28Deux-S%C3%A8vres%
29#Les_communes_associ.C3.A9es
[3]
http://fr.wikipedia.org/wiki/Bressuire#Les_communes_associ.C3.A9es_de_Bressuire


Le lundi 17 décembre 2012 à 11:44 +0100, Damouns a écrit :
> Bonjour à tous,
> 
> Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus)
> ont été publiés depuis cet été sur Légifrance pour annoncer la fusion
> de communes françaises en "communes nouvelles". La plupart d'entre eux
> prennent effet à compter du 1er janvier 2013.
> 
> Il me semble qu'on peut intégrer ça le jour J dans la base OSM en
> créant pour chacune une nouvelle relation admin_level=8 suivant les
> nouveaux contours. Je me pose la question de la conservation des
> anciennes communes en relations de niveau admin_level=10. Faut-il les
> garder de cette façon ou non ? En effet celles-ci subsistent
> normalement sous forme de « communes déléguées » (je m'attends à une
> réaction argumentée et développée de Philippe Verdy !! Mais les autres
> peuvent aussi donner leur avis bien sûr ;-)
> 
> Et j'appelle donc des volontaires pour traiter les communes
> concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici
> par département :
> 
> == dans le Maine-et-Loire ==
> 
> 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une
> commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé.
> (Référence : Arrêté du 14 septembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873
> 
> 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en
> une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs.
> (Référence : Arrêté du 19 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876
> 
> 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de
> Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune
> nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté
> du 30 mars 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218
> 
> == dans les Deux-Sèvres ==
> 
> Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres),
> en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin.
> (Référence : Arrêté du 12 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106
> 
> == dans le Rhône ==
> 
> Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de
> Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle
> appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29
> octobre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902
> 
> == dans les Hautes-Alpes ==
> 
> 1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et
> Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle
> appelée Saint-Bonnet-en-Champsaur, chef-lieu
> Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005
> 
> 2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de
> Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une
> commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy.
> (Référence : Arrêté du 2 octobre 2012)
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090
> 
> 
> Damouns
> 
> PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut
> prendre celui de l'ancienne commune du chef-lieu ?
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



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

[OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet sly (sylvain letuffe) 
Bonjour,

Juste pour info : En ce moment sur la liste des imports, les américains 
indiquent qu'ils s'apprêtent à se lancer dans un imports des bâtiments qui 
s'apparentent pas mal à notre cas. (Les détails semblent encore en discussion)

Je sais, vous vous en foutez ;-) mais là où ça nous concerne c'est que ça a 
relancé au sein du DWG le débat sur ce type d'imports semi-automatique.

Comme toujours, j'aurais aimé que ça se passe en public, mais y'a de la 
réticence, boudiou qu'il y en a ! Je vais donc tenter de faire dévier ça sur 
la liste imports car ça me semble d'importance, mais rien de gagné à moins d'y 
parler seul avec les américains (et donc prendre les coups) ! 

actuellement, l'étape n'en est toujours pas à redéfinir les guidelines ou à 
les discuter mais à déjà expliciter ce qu'on entend par "import", par 
"automatique" et ré-écrire au propre l'état actuel des choses tel que 
l'applique le DWG et lister ce qui est "mou" (conseil fortement conseillé) et 
"dur" (on va te bloquer/reverter si tu fais pas). Ce qui, à mon sens, sera 
déjà une bonne étape de départ :
"Il faut donner un nom au démon pour le vaincre améliorer"

Donc, il est possible qu'une partie se discute sur [imports]

le but est de déboucher sur une page wiki ou un document pdf figé revu et au 
propre, mais on ne sait pas trop par où commencer.

Le travail est d'autant plus dur en public que chacun va vouloir déclasser son 
propre import dans une autre catégorie pour être plus libre (ne pas remettre 
en cause la loi, mais l'applicabilité de celle-ci à son cas) style :
"Mais non, l'import du cadastre n'est pas un import"

-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] comment taguer un éboulement ?

2012-12-17 Par sujet Sylvain Maillard 
> Il me semble que ça pourrait être un avantage très fort d'OSM que de
tagguer des données provisoires, mais il faut une organisation, peut être
dans un projet particulier, peut être pas directement dans osm.
>
>Par exemple les surfaces/routes enneigées,  les zones de chantiers dans
une ville (qui peuvent emmerder plusieurs centaines de milliers de
personnes ponctuellement indéfiniment), les migrations d'oiseaux, etc, etc,
etc... je vois déjà des personnes qui utilisent OSM pour taguer les caméras
de surveillance (mais est-ce une donnée ponctuelle ou persistante ? ), et
d'autres, aussi, qui enregistrent les marchés de noël.

En fait, tout dépend de ce qu'on met derrière "donnée persistante": une
route coupée et rétablie 2 jours après, c'est de la données trop volatile
et ça n'a pas sa place dans OSM ... par contre un tunnel en travaux pendant
plusieurs mois (ex le tunnel de croix-rousse à Lyon) ou un pont fragilisé
par un accident (ex pont Mathilde à Rouen), les deux avec un impact au
minimum sur plusieurs mois, c'est considéré comme des données relativement
pérennes et on a fait les modifications dans la base OSM ...
Comme l'a dit philippe, les données volatiles en "live" ayant un impact
très limité dans le temps sont mieux dans une base externe, c'est déjà en
place dans un certain nombre de villes: voir par exemple
http://circulation.arles.fr/index.php?jour=04/04/2011, ou
http://trafic.rouen.fr

Pour ce qui est des données types route avec obligation d'équipement neige,
ou des marchés, tant que ça reste au même endroit il y a des tags
spécifiques pour données les dates d'application ;)

Après, OSM reste une base ouverte ou chacun est libre de rajouter des
informations, la vraie limite dépend donc plus de la durée minimale pour
qu'une modification soit réellement disponible dans l'éco-système OSM: la
base de données et à jour instantanément, les tuiles du serveur principal
très vite, mais pour les services extérieurs c'est beaucoup plus lent !
Geofabrik met à jour ses extraits "seulement" 1 fois par jour (donc pour
cet exemple initial d'éboulement, les données auraient été obsolètes 1 jour
après leur publication), les moteurs de routage font eux des mise à jour
moins fréquentes (donc n'auraient même pas vu la modification)...


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

Re: [OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Philippe Verdy 
Effectivement les communes associées restent des communes à part entière au
contraire des communes fusionnées. Les communes assoicées conservent donc
leur code INSEE.

Une fusion de commune crée bien une nouvelle commune, les anciennes
devenant de simples subdivisions administatives internes à la commune (qui
peuvent persister pendant ensuite un certain temps jusqu'à ce que la
nouvelle commune décide d'un autre découpage.

Maintenant après une fusion de commune il n'y a pas toujours création d'un
nouveau code INSEE : s'il y avait une commune plus importante que l'autre
et que le nom de la nouvelle commune commence par la plus importante ou ne
retient que celle-ci, son code INSEE sera conservé et utilisé. Si la
commune fusionnée a un nom différent des deux communes d'origine, l'INSEE
allouera un nouveau code.

L'INSEE peut aussi allouer un code temporaire (en fin de liste
départementale commençant par 999) pour  la persistance de certaines
données statistiques permettant la comparaison entre deux séries d'années
successives.

De toute façon l'INSEE publie les modifs nécessaires le temps venu dans le
COG. Ce qui peut nous pousser à devoir attendre et ne pas se précipiter à
faire la fusion tant que le COG n'en tient pas compte (on le saura vite en
janvier, l'INSEE doit déjà être prête concernant ces communes qu'il ne va
pas oublier pour les statistiques légales, qui doivent être publiées chaque
année). Mais là aussi l'INSEE a le temps en janvier, tant qu'il n'y a pas
de statistiques nouvelles à publier.

A mon avis on a intérêt à garder les limites des anciennes communes en
admin_level=10 après la fusion, tant qu'il n'y aura pas eu de réaménagement
du découpage communal par la nouvelle commune (qui peut par exemple
redessiner certaines limites de quartiers limitrophes des deux anciennes
communes, pour faire un aménagement commun, une même ZAC, une ZI ou une ZA).

Avant qu'un tel redécoupage infra-communal se produise pour son aménagement
concerté il y aura du temps, surtout si les communes fusionnées ont des
agglomérations séparées — même si une des mairies devient assez vite une
annexe ou est simplement fermée ou sert à un autre service municipal
(école, bibliothèque, salle d'activité associative, service technique...).

Déjà il y aura fusion le 1er janvier des actuels conseils municipaux déjà
élus, et l'élection indirecte du nouveau maire par ce conseil (s'il n'y a
pas de municipales anticipées décidées par le nouveau conseil qui ne se
réunirait que pour prononcer sa dissolution). Pas grand chose ne bougera en
terme de découpage avant les municipales suivantes : le nouveau conseil
fusionné va avoir du travail pour décider les services à conserver ou à
fermer (et il va lui falloir convaincre les résidents et électeurs de la
commune qui supporteront mal la fermeture ou l'éloignement de certains
services municipaux...).



Le 17 décembre 2012 12:25, Mickaël Guéret  a écrit :

> Salut,
>
> je m'occuperais de Saint-clémentin et Voultegon, c'est juste à coté de
> chez moi !
>
> Pour les limites de niveau 10... je ne sais pas, mais il me semble qu'il
> y a une différence entre les communes associées et fusionnées. Je ne me
> suis pas documenté là dessus, mais par exemple, ma commune est issue de
> la fusion de Nueil et Les Aubiers, on a bien une nouvelle commune, avec
> une seule mairie et tout et tout [1]... Je ne vois pas l'intérêt des
> limites de niveau 10 dans ce cas, si ce n'est raviver d'anciennes
> querelles de clocher ! ;-)
>
> Juste à coté, Bressuire et Mauléon ont par contre "phagocytés" les
> petites communes aux alentours, qui sont dites associées [2 et 3]. Ces
> communes peuvent quitter l'association et redevenir indépendante.
> J'aurais trouvé pertinent de conserver les limites dans ce cas, avec un
> niveau inférieur à la commune (pourquoi pas 10). Mais ça a déjà été
> discuté plusieurs fois sur cette liste il me semble.
>
> Mika
> [1] http://fr.wikipedia.org/wiki/Nueil_Les_Aubiers#D.C3.A9mographie
> [2] http://fr.wikipedia.org/wiki/Maul%C3%A9on_%28Deux-S%C3%A8vres%
> 29#Les_communes_associ.C3.A9es
> [3]
>
> http://fr.wikipedia.org/wiki/Bressuire#Les_communes_associ.C3.A9es_de_Bressuire
>
>
> Le lundi 17 décembre 2012 à 11:44 +0100, Damouns a écrit :
> > Bonjour à tous,
> >
> > Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus)
> > ont été publiés depuis cet été sur Légifrance pour annoncer la fusion
> > de communes françaises en "communes nouvelles". La plupart d'entre eux
> > prennent effet à compter du 1er janvier 2013.
> >
> > Il me semble qu'on peut intégrer ça le jour J dans la base OSM en
> > créant pour chacune une nouvelle relation admin_level=8 suivant les
> > nouveaux contours. Je me pose la question de la conservation des
> > anciennes communes en relations de niveau admin_level=10. Faut-il les
> > garder de cette façon ou non ? En effet celles-ci subsistent
> > normalement sous forme de « communes déléguées » (je m'attends à une
> > réaction argumentée et développée de

Re: [OSM-talk-fr] comment taguer un éboulement ?

2012-12-17 Par sujet Christian Quest 
La question dans ce cas devient: à partir de quelle durée une
modification temporaire a-t-elle de l'utilité dans la base OSM ?

J'ai peut être une réponse artificielle, mais en gros, si ça dure plus
que l'intervalle entre 2 dumps du fichier planet, ça commence à être
utile...

L'autre question qu'il me semble bon de se poser c'est: aurais-je le
temps, l'envie, la mémoire pour remettre l'objet dans son état initial
?

Des tags de date de contrôle peuvent aider à garder un oeil sur ces
modifications temporaires... avec une détection par exemple sur
osmose.

C'est même une question qu'on devrait souvent se poser... car rajouter
des objets nombreux mais non maintenus à jour rendra petit à petit les
données OSM moins intéressantes car partiellement obsolètes. C'est que
qui me pousse à me limiter dans l'ajout de commerces trop changeants
dans des quartiers où je ne fais que passer, alors que je le fais
systématiquement autour de chez moi.


Le 17 décembre 2012 13:25, Sylvain Maillard
 a écrit :
>> Il me semble que ça pourrait être un avantage très fort d'OSM que de
>> tagguer des données provisoires, mais il faut une organisation, peut être
>> dans un projet particulier, peut être pas directement dans osm.
>>
>>Par exemple les surfaces/routes enneigées,  les zones de chantiers dans une
>> ville (qui peuvent emmerder plusieurs centaines de milliers de personnes
>> ponctuellement indéfiniment), les migrations d'oiseaux, etc, etc, etc... je
>> vois déjà des personnes qui utilisent OSM pour taguer les caméras de
>> surveillance (mais est-ce une donnée ponctuelle ou persistante ? ), et
>> d'autres, aussi, qui enregistrent les marchés de noël.
>
> En fait, tout dépend de ce qu'on met derrière "donnée persistante": une
> route coupée et rétablie 2 jours après, c'est de la données trop volatile et
> ça n'a pas sa place dans OSM ... par contre un tunnel en travaux pendant
> plusieurs mois (ex le tunnel de croix-rousse à Lyon) ou un pont fragilisé
> par un accident (ex pont Mathilde à Rouen), les deux avec un impact au
> minimum sur plusieurs mois, c'est considéré comme des données relativement
> pérennes et on a fait les modifications dans la base OSM ...
> Comme l'a dit philippe, les données volatiles en "live" ayant un impact très
> limité dans le temps sont mieux dans une base externe, c'est déjà en place
> dans un certain nombre de villes: voir par exemple
> http://circulation.arles.fr/index.php?jour=04/04/2011, ou
> http://trafic.rouen.fr
>
> Pour ce qui est des données types route avec obligation d'équipement neige,
> ou des marchés, tant que ça reste au même endroit il y a des tags
> spécifiques pour données les dates d'application ;)
>
> Après, OSM reste une base ouverte ou chacun est libre de rajouter des
> informations, la vraie limite dépend donc plus de la durée minimale pour
> qu'une modification soit réellement disponible dans l'éco-système OSM: la
> base de données et à jour instantanément, les tuiles du serveur principal
> très vite, mais pour les services extérieurs c'est beaucoup plus lent !
> Geofabrik met à jour ses extraits "seulement" 1 fois par jour (donc pour cet
> exemple initial d'éboulement, les données auraient été obsolètes 1 jour
> après leur publication), les moteurs de routage font eux des mise à jour
> moins fréquentes (donc n'auraient même pas vu la modification)...
>
>
> Sylvain
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet Pieren 
2012/12/17 sly (sylvain letuffe) :

> Je sais, vous vous en foutez ;-) mais là où ça nous concerne c'est que ça a
> relancé au sein du DWG le débat sur ce type d'imports semi-automatique.

Oui, j'ai vu passé un message (re)demandant l'utilité du deuxième
compte. Je me suis bien marré. Tout le monde se fout de l' "import
guideline" jusqu'au jour où il trouve des données intéressantes à
importer.

Pieren

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

Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet Sylvain Maillard 
finalement ça n'est pas que les "méchants français" qui râlent ...
peut-être qu'on peut monter une coalition mondiale pour la simplification
des règles :D


Le 17 décembre 2012 13:40, Pieren  a écrit :

> 2012/12/17 sly (sylvain letuffe) :
>
> > Je sais, vous vous en foutez ;-) mais là où ça nous concerne c'est que
> ça a
> > relancé au sein du DWG le débat sur ce type d'imports semi-automatique.
>
> Oui, j'ai vu passé un message (re)demandant l'utilité du deuxième
> compte. Je me suis bien marré. Tout le monde se fout de l' "import
> guideline" jusqu'au jour où il trouve des données intéressantes à
> importer.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles

2012-12-17 Par sujet Philippe Verdy 
En effet si les communes ne sont QUE associées, leurs limites respectives
devraient être gardées absolument au niveau 9 (et non 10 comme de simples
quartiers), comme si c'était des arrondissements de commune (niveau plus
fort que celui des "grands quartiers" qu'on trouve dans les communes
réellement fusionnées). Tant pis si les admin_level d'OSM ne sont pas
légalement des arrondissements communaux en droit franco-français, les
admin_level d'OSM n'ont rien à voir avec la loi française.

Le cas de Bressuire inséparable de Mauléon dans OSM est une anomalie de la
base, d'autant plus que leurs codes INSEE respectifs n'ont pas disparu du
COG et continue à distinguer chacune.

Il y a d'autres cas (par exemple j'ai habité la commune de Le Rheu (35) qui
a aussi une commune associée autrefois dans une petite agglomération
séparée le long de la nationale. L'association existe encore même si les
agglomérations se touchent aujourd'hui et que presque tous les services
municipaux ont été fusionnés dans la plus grosse. Mais les panneaux
routiers indiquent encore "commune associée".

L'association de communes peut traduire la volonté d'un aménagement
concerté avec une économie de moyens pour la plus petite commune entrant
dans l'association, mais parfois cela n'aboutit à rien de concret ou les
désaccords sont trop importants entre les "clochers" et les communes
retrouvent leur indépendance en collaborant différemment dans une EPCI. Les
"communes associées" ont donc tendance à disparaître puisque les EPCI
fournissent des collaborations nécessaires presque partout sur le
territoire.




Le 17 décembre 2012 12:25, Mickaël Guéret  a écrit :

> Salut,
>
> je m'occuperais de Saint-clémentin et Voultegon, c'est juste à coté de
> chez moi !
>
> Pour les limites de niveau 10... je ne sais pas, mais il me semble qu'il
> y a une différence entre les communes associées et fusionnées. Je ne me
> suis pas documenté là dessus, mais par exemple, ma commune est issue de
> la fusion de Nueil et Les Aubiers, on a bien une nouvelle commune, avec
> une seule mairie et tout et tout [1]... Je ne vois pas l'intérêt des
> limites de niveau 10 dans ce cas, si ce n'est raviver d'anciennes
> querelles de clocher ! ;-)
>
> Juste à coté, Bressuire et Mauléon ont par contre "phagocytés" les
> petites communes aux alentours, qui sont dites associées [2 et 3]. Ces
> communes peuvent quitter l'association et redevenir indépendante.
> J'aurais trouvé pertinent de conserver les limites dans ce cas, avec un
> niveau inférieur à la commune (pourquoi pas 10). Mais ça a déjà été
> discuté plusieurs fois sur cette liste il me semble.
>
> Mika
> [1] http://fr.wikipedia.org/wiki/Nueil_Les_Aubiers#D.C3.A9mographie
> [2] http://fr.wikipedia.org/wiki/Maul%C3%A9on_%28Deux-S%C3%A8vres%
> 29#Les_communes_associ.C3.A9es
> [3]
>
> http://fr.wikipedia.org/wiki/Bressuire#Les_communes_associ.C3.A9es_de_Bressuire
>
>
> Le lundi 17 décembre 2012 à 11:44 +0100, Damouns a écrit :
> > Bonjour à tous,
> >
> > Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus)
> > ont été publiés depuis cet été sur Légifrance pour annoncer la fusion
> > de communes françaises en "communes nouvelles". La plupart d'entre eux
> > prennent effet à compter du 1er janvier 2013.
> >
> > Il me semble qu'on peut intégrer ça le jour J dans la base OSM en
> > créant pour chacune une nouvelle relation admin_level=8 suivant les
> > nouveaux contours. Je me pose la question de la conservation des
> > anciennes communes en relations de niveau admin_level=10. Faut-il les
> > garder de cette façon ou non ? En effet celles-ci subsistent
> > normalement sous forme de « communes déléguées » (je m'attends à une
> > réaction argumentée et développée de Philippe Verdy !! Mais les autres
> > peuvent aussi donner leur avis bien sûr ;-)
> >
> > Et j'appelle donc des volontaires pour traiter les communes
> > concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici
> > par département :
> >
> > == dans le Maine-et-Loire ==
> >
> > 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une
> > commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé.
> > (Référence : Arrêté du 14 septembre 2012)
> >
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873
> >
> > 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en
> > une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs.
> > (Référence : Arrêté du 19 novembre 2012)
> >
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876
> >
> > 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de
> > Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune
> > nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté
> > du 30 mars 2012)
> >
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218
> >
> > == dans les Deux-Sèvres ==
> >
> > Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres),
> > en une c

Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet rldhont 
On reforme l'alliance contre l'empire britannique de la guerre 
d'indépendance américaine ;-)


Le 17/12/2012 13:44, Sylvain Maillard a écrit :
finalement ça n'est pas que les "méchants français" qui râlent ... 
peut-être qu'on peut monter une coalition mondiale pour la 
simplification des règles :D



Le 17 décembre 2012 13:40, Pieren > a écrit :


2012/12/17 sly (sylvain letuffe) mailto:li...@letuffe.org>>:

> Je sais, vous vous en foutez ;-) mais là où ça nous concerne
c'est que ça a
> relancé au sein du DWG le débat sur ce type d'imports
semi-automatique.

Oui, j'ai vu passé un message (re)demandant l'utilité du deuxième
compte. Je me suis bien marré. Tout le monde se fout de l' "import
guideline" jusqu'au jour où il trouve des données intéressantes à
importer.

Pieren

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




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


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

Re: [OSM-talk-fr] La voie express limitée à 90 entre Donges et Saint Nazaire

2012-12-17 Par sujet Brice 
Précisément, je n'ai corrigé que sur le tronçon que j'ai emprunté i.e. entre 
St-Nazaire et la sortie D 773 vers Pontchâteau, la limite précise du passage de 
90 à 110 n'est probablement pas la bonne.

A ajuster par ceux qui feront le trajet complet entre Nantes et St-Nazaire.


Britz




Le 14 déc. 2012 à 16:35, Florian LAINEZ a écrit :

> Bon boulot :)
> 
> 
> 2012/12/14 Ab_fab 
> J'ai vu que Britz a fait l'ajustement hier
> http://www.openstreetmap.org/browse/changeset/14256789
> 
> 2012/12/14 Florian LAINEZ 
> un contributeur sur place pour taguer cela précisément ?
> http://www.donges.fr/?page=actualite&article=410
> merci
> 
> -- 
> 
> Florian Lainez
> http://twitter.com/overflorian
> http://www.nouslesgeeks.fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> -- 
> ab_fab
> "Il n'y a pas de pas perdus", Nadja
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> -- 
> 
> Florian Lainez
> http://twitter.com/overflorian
> http://www.nouslesgeeks.fr
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] comment taguer un éboulement ?

2012-12-17 Par sujet Ista Pouss 
Le 17 décembre 2012 13:25, Sylvain Maillard  a
écrit :

>
> Après, OSM reste une base ouverte ou chacun est libre de rajouter des
> informations, la vraie limite dépend donc plus de la durée minimale pour
> qu'une modification soit réellement disponible dans l'éco-système OSM: la
> base de données et à jour instantanément, les tuiles du serveur principal
> très vite, mais pour les services extérieurs c'est beaucoup plus lent !
> Geofabrik met à jour ses extraits "seulement" 1 fois par jour (donc pour
> cet exemple initial d'éboulement, les données auraient été obsolètes 1 jour
> après leur publication), les moteurs de routage font eux des mise à jour
> moins fréquentes (donc n'auraient même pas vu la modification)...
>

Oui, mais si on dit "OSM c'est des données persistantes de plusieurs mois",
alors personne ne cherchera pas à optimiser et/ou faciliter ce temps de
diffusion dans l'éco-système (comme c'est joli) OSM. Mais si on dit "OSM
devrait pouvoir accueillir des données ponctuelles", alors on se penchera
plus facilement sur ce qui me semble être une difficulté : ce temps de
diffusion dans l'éco-système (waou) osm. Pour ça que je manifeste.

Et il me semble que de dire : "les données ponctuelles c'est le boulot
d'autres sites", n'est qu'à moitié satisfaisant. Non pas que je veuille
qu'osm fasse tout (il y a les problèmes que Christian Quest relève), mais
cela augmente le poids de ce fameux "éco-système", et augmente donc ces
problèmes de diffusion de l'info de base.  Donc c'est reculer pour mieux
sauter.

On pourrait dire "On veut qu'OSM n'enregistre que des données fixes, mais
on voudrait que quelqu'un s'occupe d'optimiser le temps de diffusion des
modifs. En attendant chacun fait comme y veut". Je sais pas.

Pour le reste, d'accord.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet Christian Rogel 


Le 17 déc. 2012 à 13:51, rldhont  a écrit :

> On reforme l'alliance contre l'empire britannique de la guerre d'indépendance 
> américaine ;-)

D'autant que les Anglais avaient attaqué à partir du Canada. Re ;-)

Christian R.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse

2012-12-17 Par sujet Pierre Béland 
Oui mais ça c'est parce que de grands penseurs français déclaraient que ce 
n'étaient que "quelques arpents de neige" et nous ont laissé tombé. 


 
Pierre par cette belle journée neigeuse ...



>
> De : Christian Rogel 
>À : Discussions sur OSM en français  
>Cc : Discussions sur OSM en français  
>Envoyé le : Lundi 17 décembre 2012 11h10
>Objet : Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les 
>imports et les édits en masse
> 
>
>
>Le 17 déc. 2012 à 13:51, rldhont  a écrit :
>
>> On reforme l'alliance contre l'empire britannique de la guerre 
>> d'indépendance américaine ;-)
>
>D'autant que les Anglais avaient attaqué à partir du Canada. Re ;-)
>
>Christian R.
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Tetsuo Shima 
Bonsoir,

Une petit question sur la maniere de qualifier une écluse. Dans le wiki
l'exemple donne ceci : http://wiki.openstreetmap.org/wiki/Key:lock

La surface du bassin est qualifier a la fois par un landuse=basin ET par un
waterway=lock
Ce meme waterway=lock sert semble t il exclusivement pour les surface fermé
par une écluse et pas du tout pour qualifier le chemin d'un cours d'eau
passant dans une écluse. Jusque là tout va bien.

Sauf que ... Osmose n'aime pas la surface fermé qualifié waterway=lock, et
renvoi une erreur cours d'eau fermé!!! C'est une erreur d'interprétation
d'Osmose ou c'est moi qui est pas bien compris ... ou le wiki qu'est mal
fichu?

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

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
waterway=lock désigne unquement chaque porte d'écluse elle-même (un point
ou un trait), mais PAS le bassin placé d'un côté ou de l'autre (d'ailleurs
une écluse n'a pas toujours un bassin fermé par deux portes, il peut n'y en
avoir qu'une seule, ouvrant ou fermant le passage selon le niveau de l'eau
de l'autre côté, par exemple entre le bassin d'un port et un fleuve, pour
éviter que toute l'eau parte avec la marée.

Si tu fermes le traits ou si tu en fait une relation fermée, tu est en
train de tracer toute l'épaisseur de la porte, ce qui est ridicule quand
cette porte est mobile. En principe on ne tague avec qu'un seul nœud, sur
le filaire central du cours d'eau.

Entre deux portes sur un cours d'eau, ce n'est pas un bassin mais une
surface (définie dans une relation "waterway=riverbank" ou dans un chemin
fermé de même type) ; le filaire du cours central est alors un
"waterway=river" ou "waterway=canal". C'est le point d'intersection entre
les filaire central du cours d'eau et celui de fermeture du riverbank et
qui passe par la porte de l'écluse, que tu définis comme nœud
"waterway=lock".

Le bassin (landuse=bassin) est en principe autre chose : il est fermé soit
par une porte waterway=lock d'un seul côté (sur un seul noeud), mais le
plus souvent par un seuil. ou une conduite enterrée qui peut être fermée
par une vanne, ou vidée plus tard par une pompe. Mais il n'y en a qu'une
seule fermeture et non deux pour le relier à son bief d'alimentation ou de
débordement depuis/vers un cours d'eau. Cette fermeture de bassin se place
là aussi au point d'intersection entre le chemin filaire central du bief et
le contour du bassin. La différence entre un bassin et une riberbank est
justement qu'il n'y a pas de cours d'eau au milieu, faute de direction
d'écoulement, qui peut se faire dans un sens ou l'autre depuis ou vers le
bief.

Si tu fais comme ça, Osmose ne signale plus rien du tout sur ton bassin.

Souvent ce bassin peut être entièrement vide (c'est le cas des bassins
d'orage, remplis occasionnellement pour prévenir des inondations dans les
villes par le débordement des égouts pendant les fortes précipitation, même
si souvent ces bassins restent boueux car il est difficile de les vider
entièrement et on ne les nettoie que rarement, le fond n'étant pas toujours
cimentée mais juste constitué d'une feuille plastique épaisse, protégée par
un fond glaiseux ou sableux, sur lequel vont pousser des herbes)

Si le bassin est assez grand, il peut être permanent (avec juste sa hauteur
d'eau qui varie) : c'est alors un étang et il ne doit son niveau d'eau
permanent que parce qu'il y collecte des eaux de plusieurs petits cour
d'eau et des fossés.

Si un cours d'eau important y entre et en ressort, ce n'est plus un simple
étang mais carrément un lac (qui peut avoir son niveau d'eau surélevé et sa
surface agrandie, par un barrage ou un seuil artificiel, élevé du côté aval
du cours d'eau qui le traverse)

Le 17 décembre 2012 20:06, Tetsuo Shima  a écrit :

> Bonsoir,
>
> Une petit question sur la maniere de qualifier une écluse. Dans le wiki
> l'exemple donne ceci : http://wiki.openstreetmap.org/wiki/Key:lock
>
> La surface du bassin est qualifier a la fois par un landuse=basin ET par
> un waterway=lock
> Ce meme waterway=lock sert semble t il exclusivement pour les surface
> fermé par une écluse et pas du tout pour qualifier le chemin d'un cours
> d'eau passant dans une écluse. Jusque là tout va bien.
>
> Sauf que ... Osmose n'aime pas la surface fermé qualifié waterway=lock, et
> renvoi une erreur cours d'eau fermé!!! C'est une erreur d'interprétation
> d'Osmose ou c'est moi qui est pas bien compris ... ou le wiki qu'est mal
> fichu?
>
> Cordialement.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Pardon j'avais mal lu: les portes son bien des nœuds mais avec
waterway=lock_gate et non waterway=lock.

Je me demande la pertinence de waterway=lock alors que pour mois cela reste
la même chose qu'un waterway=riverbank (même si c'est une portion de canal,
ce qu'indique le filaire central tagué waterway=canal)

Si on considère les écluses d'Hédé (sur le Canal d'Ille-et Rance en
Ille-et-Vilaine) il y a 13 écluses successives avec autant 12 bassins
successifs, mais ils font bien partie du canal :

Je ne vois pas pourquoi ce ne serait pas des "waterway=riverbank" et ce
qu'apporte le fait de les taguer différemment en "waterway=lock" (même si
le "cours d'eau" filaire, passant par les écluses sucessives au milieu des
bassins du canal, n'a plus de sens "amont" ou "aval" bien défini puisque le
sens d'écoulement dépendra des différences de hauteur d'eau entre les
bassins, qui ont chacun leur propre alimentation en eau (apportée par des
conduites depuis des étangs de réserve en hauteur eux-mêmes alimentés par
des fossés des collines du bassin versant ou par des pompes remontant de
l'eau depuis le canal, les conduites pouvant aussi être ouvertes ou
fermées, et tous les bassins et étangs ayant aussi des seuils de
débordement de l'un vers l'autre pour éviter l'inondation).

Quel est le critère objectif différenciant un "waterway=lock" d'un
"waterway=riverbank" ? Sa longueur ? Le fait que sa hauteur d'eau varie
lorsque l'écluse est utilisée et sa porte ouverte ? (cette hauteur variera
toujours un peu sur tous les bassins dès que la porte sera ouverte).

Le 17 décembre 2012 23:16, Philippe Verdy  a écrit :

> waterway=lock désigne unquement chaque porte d'écluse elle-même (un point
> ou un trait), mais PAS le bassin placé d'un côté ou de l'autre (d'ailleurs
> une écluse n'a pas toujours un bassin fermé par deux portes, il peut n'y en
> avoir qu'une seule, ouvrant ou fermant le passage selon le niveau de l'eau
> de l'autre côté, par exemple entre le bassin d'un port et un fleuve, pour
> éviter que toute l'eau parte avec la marée.
>
> Si tu fermes le traits ou si tu en fait une relation fermée, tu est en
> train de tracer toute l'épaisseur de la porte, ce qui est ridicule quand
> cette porte est mobile. En principe on ne tague avec qu'un seul nœud, sur
> le filaire central du cours d'eau.
>
> Entre deux portes sur un cours d'eau, ce n'est pas un bassin mais une
> surface (définie dans une relation "waterway=riverbank" ou dans un chemin
> fermé de même type) ; le filaire du cours central est alors un
> "waterway=river" ou "waterway=canal". C'est le point d'intersection entre
> les filaire central du cours d'eau et celui de fermeture du riverbank et
> qui passe par la porte de l'écluse, que tu définis comme nœud
> "waterway=lock".
>
> Le bassin (landuse=bassin) est en principe autre chose : il est fermé soit
> par une porte waterway=lock d'un seul côté (sur un seul noeud), mais le
> plus souvent par un seuil. ou une conduite enterrée qui peut être fermée
> par une vanne, ou vidée plus tard par une pompe. Mais il n'y en a qu'une
> seule fermeture et non deux pour le relier à son bief d'alimentation ou de
> débordement depuis/vers un cours d'eau. Cette fermeture de bassin se place
> là aussi au point d'intersection entre le chemin filaire central du bief et
> le contour du bassin. La différence entre un bassin et une riberbank est
> justement qu'il n'y a pas de cours d'eau au milieu, faute de direction
> d'écoulement, qui peut se faire dans un sens ou l'autre depuis ou vers le
> bief.
>
> Si tu fais comme ça, Osmose ne signale plus rien du tout sur ton bassin.
>
> Souvent ce bassin peut être entièrement vide (c'est le cas des bassins
> d'orage, remplis occasionnellement pour prévenir des inondations dans les
> villes par le débordement des égouts pendant les fortes précipitation, même
> si souvent ces bassins restent boueux car il est difficile de les vider
> entièrement et on ne les nettoie que rarement, le fond n'étant pas toujours
> cimentée mais juste constitué d'une feuille plastique épaisse, protégée par
> un fond glaiseux ou sableux, sur lequel vont pousser des herbes)
>
> Si le bassin est assez grand, il peut être permanent (avec juste sa
> hauteur d'eau qui varie) : c'est alors un étang et il ne doit son niveau
> d'eau permanent que parce qu'il y collecte des eaux de plusieurs petits
> cour d'eau et des fossés.
>
> Si un cours d'eau important y entre et en ressort, ce n'est plus un simple
> étang mais carrément un lac (qui peut avoir son niveau d'eau surélevé et sa
> surface agrandie, par un barrage ou un seuil artificiel, élevé du côté aval
> du cours d'eau qui le traverse)
>
> Le 17 décembre 2012 20:06, Tetsuo Shima  a écrit :
>
>> Bonsoir,
>>
>> Une petit question sur la maniere de qualifier une écluse. Dans le wiki
>> l'exemple donne ceci : http://wiki.openstreetmap.org/wiki/Key:lock
>>
>> La surface du bassin est qualifier a la fois par un landuse=basin ET par
>> un waterway=lock
>> Ce meme waterway=lock sert se

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
En plus le schéma visible sur le wiki n'est applicable qu'aux seuls cours
d'eau naturel (ou sections parallèles canalisées permettant de contourner
un rapide ayant une hauteur d'eau insuffisante à la navigation) qui ont un
sens d'écoulement.

Sur les canaux, il n'y a pas toujours de sens d'écoulement défini, et les «
mitres » des portes ne sont donc pas orientées dans le même sens en
direction inverse de l'écoulement, mais seront plus souvent dans des
directions opposées (cela arrive même sur les sections parallèles
canalisées des cours d'eau naturels.

Si on suppose que "waterway=lock" se distingue du "waterway=riverbank" par
son resserrement (en largeur) et le fait que la bordure terreste est
maçonnée et beaucoup plus verticale pour résister aux changements de
hauteur d'eau, alors oui il faut qu'Osmose traite "waterway=lock" et
"waterway=riverbank" de la même façon au plan des vérifications de
géométrie.

Sur les écluses d'Hédé on va trouver 13 bassins maçonnés
("waterway=lock") ouverts chacun des 2 côtés de façon jointive sur des
"waterway=riverbank" (il y en aura 12 mais où la porte de l'écluse est AU
MILIEU du bassin bétonné et non de chaque côté. La surface canal lui-même
va donc bien être une succession alternant des "waterway=riverbank" et
des "waterway=lock", mais les portes d'écluses ne seront pas toujours sur
le segment où ces polygones se joignent.

La définition portée en tête de page wiki ne va pas coller à ce cas-là.

Et j'ai l'impression qu'Osmose confond "waterway=lock" (le bassin canalisé
et maçonné) avec "waterway=lock_gate" (la porte de l'écluse elle-même).

Osmose n'a pas de problème en revanche si on n'utilise pas "waterway=lock"
(dont l'usage distinctif me semble douteux et en tout cas pas assez
clairement décrit sur le wiki) mais uniquement des "waterway=riverbank" à
la place (bien plus simple à taguer : on peut toujours définir en plus la
maçonnerie de chaque rive sur le trait de limitation entre la terre et
bassin, mais ce n'est pas nécessaire pour la relation couvrant la surface
du bassin canalisé et même dans les deux cas on peut toujours aussi placer
à côté les quais, barrières ou murets de sécurité pour les piétons, les
bites d'amarrage...).



Le 17 décembre 2012 23:33, Philippe Verdy  a écrit :

> Pardon j'avais mal lu: les portes son bien des nœuds mais avec
> waterway=lock_gate et non waterway=lock.
>
> Je me demande la pertinence de waterway=lock alors que pour mois cela
> reste la même chose qu'un waterway=riverbank (même si c'est une portion de
> canal, ce qu'indique le filaire central tagué waterway=canal)
>
> Si on considère les écluses d'Hédé (sur le Canal d'Ille-et Rance en
> Ille-et-Vilaine) il y a 13 écluses successives avec autant 12 bassins
> successifs, mais ils font bien partie du canal :
>
> Je ne vois pas pourquoi ce ne serait pas des "waterway=riverbank" et ce
> qu'apporte le fait de les taguer différemment en "waterway=lock" (même si
> le "cours d'eau" filaire, passant par les écluses sucessives au milieu des
> bassins du canal, n'a plus de sens "amont" ou "aval" bien défini puisque le
> sens d'écoulement dépendra des différences de hauteur d'eau entre les
> bassins, qui ont chacun leur propre alimentation en eau (apportée par des
> conduites depuis des étangs de réserve en hauteur eux-mêmes alimentés par
> des fossés des collines du bassin versant ou par des pompes remontant de
> l'eau depuis le canal, les conduites pouvant aussi être ouvertes ou
> fermées, et tous les bassins et étangs ayant aussi des seuils de
> débordement de l'un vers l'autre pour éviter l'inondation).
>
> Quel est le critère objectif différenciant un "waterway=lock" d'un
> "waterway=riverbank" ? Sa longueur ? Le fait que sa hauteur d'eau varie
> lorsque l'écluse est utilisée et sa porte ouverte ? (cette hauteur variera
> toujours un peu sur tous les bassins dès que la porte sera ouverte).
>
> Le 17 décembre 2012 23:16, Philippe Verdy  a écrit :
>
> waterway=lock désigne unquement chaque porte d'écluse elle-même (un point
>> ou un trait), mais PAS le bassin placé d'un côté ou de l'autre (d'ailleurs
>> une écluse n'a pas toujours un bassin fermé par deux portes, il peut n'y en
>> avoir qu'une seule, ouvrant ou fermant le passage selon le niveau de l'eau
>> de l'autre côté, par exemple entre le bassin d'un port et un fleuve, pour
>> éviter que toute l'eau parte avec la marée.
>>
>> Si tu fermes le traits ou si tu en fait une relation fermée, tu est en
>> train de tracer toute l'épaisseur de la porte, ce qui est ridicule quand
>> cette porte est mobile. En principe on ne tague avec qu'un seul nœud, sur
>> le filaire central du cours d'eau.
>>
>> Entre deux portes sur un cours d'eau, ce n'est pas un bassin mais une
>> surface (définie dans une relation "waterway=riverbank" ou dans un chemin
>> fermé de même type) ; le filaire du cours central est alors un
>> "waterway=river" ou "waterway=canal". C'est le point d'intersection entre
>> les filaire central du cours d'eau et celui de fermetur

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Christian Quest 
Confusion entre lock et lock_gate ?

Ca serait bien de relire le wiki avant ce genre de réponse aussi
affirmative, non ?
Il y a même un dessin comme ça l'article ne risque pas de TL;DR !

http://wiki.openstreetmap.org/wiki/Key:lock

C'est bien osmose qui râle à tort sur waterway=lock à ce qu'il me semble...

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Note la discussion initiale portant sur la différenciation des
waterway=lock des waterway=riverbank a décrit la situation suivante, celle
des écluses à deux portes sur les sections parallèles canalisées des cours
d'eau naturels (l'autre bras naturel du cours d'eau a alors un seuil au
travers) :
   ->==>-

Sinon avec uniquement des waterway=riverbank on n'aurait QUE:
   ->--->-
Mais sur des écluses en escalier permettant de passer par dessus un col
comme les écluses de Hédé on a plutôt si on n'a que des riverbanks:

->->->->-<-<-<-
(Impossible de distinguer)

Mais la réalité est plutôt celle-là pour les écluses en escalier :

---=>=-=>=-=>=-=>=-=<=-=<=-=<=---
(les suites de trois signes =<> indiquent une section waterway=lock, alors
que les suites de signes "-" sont des waterway=riverbank).

La direction des portes est souvent non significative de la direction
d'éclulement sur les écluses placées sur des biefs de raccordement.

Sur les écluses en escalier, les waterway=lock (=>= ou =<=) sont souvent
beaucoup plus courts (quelques mètres) que sur une écluse à deux portes
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Tu m'énerves, j'ai répondu à ça déjà avant.


Le 18 décembre 2012 00:25, Christian Quest  a
écrit :

> Confusion entre lock et lock_gate ?
>
> Ca serait bien de relire le wiki avant ce genre de réponse aussi
> affirmative, non ?
> Il y a même un dessin comme ça l'article ne risque pas de TL;DR !
>
> http://wiki.openstreetmap.org/wiki/Key:lock
>
> C'est bien osmose qui râle à tort sur waterway=lock à ce qu'il me semble...
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Christian Quest 
Le 18 décembre 2012 00:29, Philippe Verdy  a écrit :
> Tu m'énerves, j'ai répondu à ça déjà avant.
>

Désolé de faire encore l'effort de lire (parfois en partie) cette logorrhée.
Je vais peut être moi aussi rester au TL;DR au risque de laisser
passer des erreurs pour lesquelles je croise les doigts pour que des
contributeurs peu informés pourraient prendre malheureusement pour
argent comptant (j'ai encore le souvenir du découpage de landuse sur
les limites administratives).

De la concision et un minimum de vérification avant de cliquer sur
"Envoyer"... c'est vraiment trop demander ?

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Le wiki ne traite QUE le cas des waterway=lock n'ayant ayant deux portes
(une de chaque côté, cas le plus courant) et oublie le cas où il n'y a
qu'une seule porte (au milieu) ce qui est le cas le plus courant dans les
suites d'écluses en escalier permettant de passer par dessus un col.

Dans le cas des escaliers les plus serrés seulement (permettant de
descendre ou monter une ancienne section rapide) on a le cas :

--->===>===>===>===>---

Et c'est toute la longueur ici entre les de la 1re à la 4e écluse (ici
l'écoulement naturel est de droite à gauche, la pointe du > de chaque porte
est vers l'amont) qui est maçonnée et resserrée par des rives renforcées.

Mais avant que "waterway=lock" soit proposé, on n'avait QUE
"waterway=riverbank" pour TOUTES les surfaces de cours d'eau ou de canaux.

On pouvait pourtant faire la distinction des parties resserrées et
artificialisées avec des rives renforcées (près des portes) avec un autre
attribut OPTIONNEL "lock=yes" dessus (voire parfois plutôt
"water_lock=yes"). Et cela allait très bien (et cela convenait très bien à
Osmose qui pouvait voir que les waterway=riverbank jointifs formaient la
surface d'un même cours d'eau).

C'était même bien plus simple à gérer et sélectionner dans les données (il
est implicite de toute façon qu'il y a au moins quelques mètres avant et
après chaque porte où les rives sont rapprochées et renforcées (et cela se
voit de façon évidente aussi sur la géométrie, ne serait-ce que par le
resserrement des rives), d'autant plus qu'à ce niveau de détail on a encore
besoin alors de dire ce qu'il y a sur les rives (murs ou barrières de
protection), ou les matériaux de ces rives construites (béton, plaques
métalliques, mur de brique, pierre...) qui soutiennent les quais au dessus
du plan d'eau (quand son niveau est abaissé pour ouvrir une porte vers
l'aval).

Les "waterway=lock" sont donc encore peu utilisés en comparaison des
waterway=riverbank (qui sont eux non plus pas tous annotés avec lock=yes ou
water_lock=yes).

Le pire c'est que la plupart des "waterway=lock" servent à taguer des
noeuds isolés, et non des chemins fermés ou relations fermées (ils sont
utilisés à la place de la totalité d'une écluse ou à la place d'une des
deux portes "waterway=lock_gate"). Et qu'Osmose lui ne voit pas ça comme
une erreur (donc il fait aussi la confusion entre "waterway=lock"
et "waterway=lock_gate" en considérant les cas les plus courants, il les
prend comme des synonymes !


Le 18 décembre 2012 00:38, Christian Quest  a
écrit :

> Désolé de faire encore l'effort de lire (parfois en partie) cette
> logorrhée.
>

Encore des mots pour insulter... Mais j'ai l'habitude.J'avais corrigé TOUT
de suite (les deux messages ont du arriver en même temps ou presque) avant
que tu prennes insultes plus d'une demi-heure après en ayant déjà reçu le
deuxième.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Christian Quest 
Le 18 décembre 2012 01:12, Philippe Verdy  a écrit :
> Le 18 décembre 2012 00:38, Christian Quest  a écrit
> :
>>
>> Désolé de faire encore l'effort de lire (parfois en partie) cette
>> logorrhée.
>
>
> Encore des mots pour insulter... Mais j'ai l'habitude.J'avais corrigé TOUT
> de suite (les deux messages ont du arriver en même temps ou presque) avant
> que tu prennes insultes plus d'une demi-heure après en ayant déjà reçu le
> deuxième.
>


Je pense que tu as du mal à saisir mon propos.

Plutôt que de répondre à une simple question par un exposé, il aurait
été plus judicieux:
1) d'aller lire la page du wiki (le lien était indiqué)
2) de comprendre le problème
3) puis de renvoyer une réponse incompatible avec le fonctionnement
normal d'une liste de diffusion (mais qui aurait éventuellement sa
place sur un blog perso comme il a été indiqué à maintes reprises)

Si demander de la concision et un minimum de vérification avant
d'envoyer un message fait partie des insultes, ça va être difficile de
rester constructif comme j'essaye de l'être.

Il serait bon de ne pas prendre la mouche et de monter sur ses grands
chevaux à chaque remarque que l'on peut faire.

Si c'est le mot "logorrhée" qui te gêne, remplace le par verbiage qui
d'ailleurs me semble plus adapté.

Nous sommes sur une mailing list, pas sur un blog perso.
Faudra-t-il fixer une taille maximale pour le contenu des messages ?

Fin de sujet pour moi.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Je l'avais lue cette page du wiki, et je me posais la question de sa
pertinence étant donnée la MAJORITÉ des données présentes, qui sont
contraires à ce qui est décrit dans cette page pas remise à jour pour soit
pour mieux expliquer soit pour fixer des règles plus précisés (car
visiblement presque tout le monde se trompe depuis que cette proposition a
commencé à être utilisée !)

Maintenant si tu ne veux pas comprendre que cette explication du problème
n'est pas qu'une "logorrhée", et que je n'étais pas là non plus pour donner
seulement une instruction mais soulever le problème d'une autre façon. Me
renvoyer ailleurs pour aller comprendre de quoi parlait la question
initiale que j'avais bien comprise alors que justement ce problème n'était
même pas compris par la majorité ni par les "experts" qui maintiennent
Osmose (mais se trompent ici, je ne jette pas la pierre mais qu'ont ne me
la renvoie pas non plus surtout quand la correction était déjà là).

==> En plus tu réattaques ici à nouveau en public alors que je venais de te
répondre en privé. Donc tu insistes dans le dénigrement et c'est pas cool
si tu penses que ton entourage connu et choisi suffit à réguler le projet
et que les autres sont des... (à compléter).

Le 18 décembre 2012 03:20, Christian Quest  a
écrit :

> 1) d'aller lire la page du wiki (le lien était indiqué)
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Sylvain Maillard 
c'est vrai que la page en question ne parle QUE de la partie "bassin",
puisque c'est LA page spéciale pour expliquer comment tagguer le "bassin"
...

il suffit de regarder les pages liées "See also" pour aller lire très
rapidement la proposition détaillée, qui comporte également une description
détaillés (http://wiki.openstreetmap.org/wiki/Proposed_features/Lock), et
évoque les cas particuliers dont tu parles:
- rien d'anormal à avoir lock=yes sur un node ("lock=yes could also be
applied to a single node in the canal way")
- le waterway=lock sert justement à décrire précisément tous les cas, et
permet de décrire une écluse avec une seule porte ("it doesn't care what
else is connected to the ends")
- "le cas où il n'y a qu'une seule porte (au milieu) ce qui est le cas le
plus courant dans les suites d'écluses en escalier" => euh, je ne suis pas
sur d'avoir bien compris comment une porte peut être "seule" si elle est
dans une "suite d'écluses" ...
- le problème d'avant avec que waterway=riverbank c'est justement qu'il n'y
avait aucun détail possible ...
- un humain est sans doute capable de faire de la photo-interprétation et
de comprendre à partir de quelques données, mais ça n'est pas le cas d'un
ordinateur, il faut tout lui expliquer en détail !


Sylvain



Le 18 décembre 2012 04:00, Philippe Verdy  a écrit :

> Je l'avais lue cette page du wiki, et je me posais la question de sa
> pertinence étant donnée la MAJORITÉ des données présentes, qui sont
> contraires à ce qui est décrit dans cette page pas remise à jour pour soit
> pour mieux expliquer soit pour fixer des règles plus précisés (car
> visiblement presque tout le monde se trompe depuis que cette proposition a
> commencé à être utilisée !)
>
> Maintenant si tu ne veux pas comprendre que cette explication du problème
> n'est pas qu'une "logorrhée", et que je n'étais pas là non plus pour donner
> seulement une instruction mais soulever le problème d'une autre façon. Me
> renvoyer ailleurs pour aller comprendre de quoi parlait la question
> initiale que j'avais bien comprise alors que justement ce problème n'était
> même pas compris par la majorité ni par les "experts" qui maintiennent
> Osmose (mais se trompent ici, je ne jette pas la pierre mais qu'ont ne me
> la renvoie pas non plus surtout quand la correction était déjà là).
>
> ==> En plus tu réattaques ici à nouveau en public alors que je venais de
> te répondre en privé. Donc tu insistes dans le dénigrement et c'est pas
> cool si tu penses que ton entourage connu et choisi suffit à réguler le
> projet et que les autres sont des... (à compléter).
>
> Le 18 décembre 2012 03:20, Christian Quest  a
> écrit :
>
> 1) d'aller lire la page du wiki (le lien était indiqué)
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Le 18 décembre 2012 07:11, Sylvain Maillard  a
écrit :

> c'est vrai que la page en question ne parle QUE de la partie "bassin",
> puisque c'est LA page spéciale pour expliquer comment tagguer le "bassin"
> ...
>
> il suffit de regarder les pages liées "See also" pour aller lire très
> rapidement la proposition détaillée, qui comporte également une description
> détaillés (http://wiki.openstreetmap.org/wiki/Proposed_features/Lock), et
> évoque les cas particuliers dont tu parles:
> - rien d'anormal à avoir lock=yes sur un node ("lock=yes could also be
> applied to a single node in the canal way")
>

Et pourtant c'est un cas anormal car lock=yes était destiné à qualifier une
riverbank (la surface du bassin... non ponctuelle) et non pas un
"waterway=lock" (la même surface où cela l'indique déjà et oùu c'est
redondant). Dans les deux cas ce n'est pas ponctuel.

Sinon c'est qu'il y a CONFUSION avec un noeud "waterway=lock_gate" (la
porte elle-même) et c'est bien une anomalie. La page du wiki ne traite pas
de la façon dont traiter les portes, juste des bassins où on les trouve.


> - le waterway=lock sert justement à décrire précisément tous les cas, et
> permet de décrire une écluse avec une seule porte ("it doesn't care what
> else is connected to the ends")
>

Faux ! Relis le haut de la page, cette page wiki ne traite QUE les écluses
à 2 portes. La phrase signifie seulement que ce noeud peut être relié (ou
pas) au filiaire du cours d'eau, à un chemin passant au dessus de l'écluse
(pour piétons, voire une route avec un pont).


> - "le cas où il n'y a qu'une seule porte (au milieu) ce qui est le cas le
> plus courant dans les suites d'écluses en escalier" => euh, je ne suis pas
> sur d'avoir bien compris comment une porte peut être "seule" si elle est
> dans une "suite d'écluses" ...
>

Justement tu n'as rien compris. La suite d'écluses est faite d'une seule
porte par marche de l'escalier. il n'y a reserrement dur cours d'eau avec
des quais maçonnés alors QUE sur quelques mètres autour d'UNE SEULE porte
(et non DEUX) le reste du canal sur chaque marche est faite alors de rives
non maçonnées.


> - le problème d'avant avec que waterway=riverbank c'est justement qu'il
> n'y avait aucun détail possible ...
>

FAUX ! Avant on aviat waterway=riverbank pour TOUS les bassins et on
précisait uniquement avec lock=yes EN PLUS uniquement sur les bassin où
c'est applicable (pour identigier le changement de hauteur d'eau et le
renformcement des rives). Et il y avait (il y a encore !) d'autres valeurs
de lock=*.

Bref waterway=lock n'apporte STRICTEMENT RIEN de plus que
waterway=riverbank si on doit en plus préciser une valeur à lock=*


> - un humain est sans doute capable de faire de la photo-interprétation et
> de comprendre à partir de quelques données, mais ça n'est pas le cas d'un
> ordinateur, il faut tout lui expliquer en détail !
>

Justement cela d'montre que tu n'as rien compris !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Sylvain Maillard 
les détails sur la manière de taguer les portes sont sur une autre page
wiki: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dlock_gate
(c'est bien fait ce truc appelé wiki, on ne parle que d'un seul sujet par
page, et les longues discussions sont ailleurs)

la situation actuelle met un peu de redondance dans les données (depuis
2008 quand même), mais je me vois mal regarder en détail tous les riverbank
quand j'ai besoin de faire une analyse sur le linéaire des cours d'eau !
d'ailleurs à ce sujet, un extrait de
http://wiki.openstreetmap.org/wiki/Key:waterway (pour retrouver son
contexte exact, merci d'aller voir le wiki) pour le tag "lock=yes": "Can
tag either the section of the way between the gates (detailed) or just a
single node in the waterway (less detailed)" => c'est bien dans l'esprit
d'ouverture d'OSM, à savoir que ceux qui veulent faire des cartes hyper
détaillées peuvent, et ceux qui n'en voient pas l'intérêt ne sont pas
obligés.

et si il manque des éléments pour représenter tous les cas particuliers, il
ne faut surtout pas hésiter à aller en parler sur
http://wiki.openstreetmap.org/wiki/Proposed_features/Lock et à faire une
proposition d'amélioration ;)
tu n'es pas le seul qui n'approuve pas cette manière de taguer, il y a
d'autres personnes qui préfèrent comme c'était avant.

Effectivement comme tu l'as si bien dit, quand on regarde un escalier de
très près, on ne voit qu'une seule marche ... ça n'empêche pas les autres
d'exister juste autour !


Sylvain



Le 18 décembre 2012 07:41, Philippe Verdy  a écrit :

> Le 18 décembre 2012 07:11, Sylvain Maillard a 
> écrit :
>
>> c'est vrai que la page en question ne parle QUE de la partie "bassin",
>> puisque c'est LA page spéciale pour expliquer comment tagguer le "bassin"
>> ...
>>
>> il suffit de regarder les pages liées "See also" pour aller lire très
>> rapidement la proposition détaillée, qui comporte également une description
>> détaillés (http://wiki.openstreetmap.org/wiki/Proposed_features/Lock),
>> et évoque les cas particuliers dont tu parles:
>> - rien d'anormal à avoir lock=yes sur un node ("lock=yes could also be
>> applied to a single node in the canal way")
>>
>
> Et pourtant c'est un cas anormal car lock=yes était destiné à qualifier
> une riverbank (la surface du bassin... non ponctuelle) et non pas un
> "waterway=lock" (la même surface où cela l'indique déjà et oùu c'est
> redondant). Dans les deux cas ce n'est pas ponctuel.
>
> Sinon c'est qu'il y a CONFUSION avec un noeud "waterway=lock_gate" (la
> porte elle-même) et c'est bien une anomalie. La page du wiki ne traite pas
> de la façon dont traiter les portes, juste des bassins où on les trouve.
>
>
>> - le waterway=lock sert justement à décrire précisément tous les cas, et
>> permet de décrire une écluse avec une seule porte ("it doesn't care what
>> else is connected to the ends")
>>
>
> Faux ! Relis le haut de la page, cette page wiki ne traite QUE les écluses
> à 2 portes. La phrase signifie seulement que ce noeud peut être relié (ou
> pas) au filiaire du cours d'eau, à un chemin passant au dessus de l'écluse
> (pour piétons, voire une route avec un pont).
>
>
>> - "le cas où il n'y a qu'une seule porte (au milieu) ce qui est le cas le
>> plus courant dans les suites d'écluses en escalier" => euh, je ne suis pas
>> sur d'avoir bien compris comment une porte peut être "seule" si elle est
>> dans une "suite d'écluses" ...
>>
>
> Justement tu n'as rien compris. La suite d'écluses est faite d'une seule
> porte par marche de l'escalier. il n'y a reserrement dur cours d'eau avec
> des quais maçonnés alors QUE sur quelques mètres autour d'UNE SEULE porte
> (et non DEUX) le reste du canal sur chaque marche est faite alors de rives
> non maçonnées.
>
>
>> - le problème d'avant avec que waterway=riverbank c'est justement qu'il
>> n'y avait aucun détail possible ...
>>
>
> FAUX ! Avant on aviat waterway=riverbank pour TOUS les bassins et on
> précisait uniquement avec lock=yes EN PLUS uniquement sur les bassin où
> c'est applicable (pour identigier le changement de hauteur d'eau et le
> renformcement des rives). Et il y avait (il y a encore !) d'autres valeurs
> de lock=*.
>
> Bref waterway=lock n'apporte STRICTEMENT RIEN de plus que
> waterway=riverbank si on doit en plus préciser une valeur à lock=*
>
>
>> - un humain est sans doute capable de faire de la photo-interprétation et
>> de comprendre à partir de quelques données, mais ça n'est pas le cas d'un
>> ordinateur, il faut tout lui expliquer en détail !
>>
>
> Justement cela d'montre que tu n'as rien compris !
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] waterway=lock

2012-12-17 Par sujet Philippe Verdy 
Ce n'est pas qu'une question de préférence mais bel et bien du fait que
certains n'ont absolument pas compris et pas lu la page wiki correctement
(et toi non plus).

- taguer un NOEUD avec waterway=lock est une erreur (commise par plus de la
moitié des cas d'utilisation de ce cas) car on voulait taguer juste la
porte et non le bassin
- Osmose s'est bel et bien planté en interprétant comme le font la majorité
des gens (qui se sont trompés aussi) et sans lire la description du tag (il
nterprète à l'envers

Et ce n'est pas qu'une question de niveau de détail. Il n'y a strictement
rien qui justifie de taguer un NOEUD avec waterway=lock (erreur) au lieu de
waterway=lock_gate (OK) car le niveau de détail est exactement le même (on
n'a toujours qu'un seul NOEUD et pas plus de tag).

C'est une confusion sur la valeur correcte d'un seul tag pour décrire une
porte (jsutement décrire sur une autre page du wiki).

Le simple fait que tu ne vois pas en quoi c'est une erreur, et que dans
plus de la moitié des cas on se trompe (et qu'Osmose et OSMI se trompent
aussi) démontre clairement que l'idée de préciser waterway=lock au lieu de
waterway=riverbank était mauvaise : non seulement elle n'a rien précisé de
plus mais augmenter la confusion de ce qui est décrit et compliqué la vie
des programmes (même si les humains ne semblent pas avoir de soucis à
interpréter ça, la preuve étant qu'ils ne comprennent pas où est l'erreur).

Hors si tu me reproches de ne pas avoir lu la page du siki, je te démontre
que justement je l'ai lue et même plus précisément que toi. Je ne dis pas
que tu ne l'as pas lue, mais que tu ne l'as pas comprise réellement (et tu
n'es pas le seul). Mais je ne te le reproches pas comme on est venu me le
reprocher complètement à tord.

Pour moi un unique waterway=riverbank suffisait, et clarifiait les choses
et évitait la confusion entre le bassin et la porte. Ensuite pour les deux
types de bassins (en fonction de la nature de ses quais rapproché et
maçonné et la "réglabilité" de la hauteur d'eau) c'est là qu'on pouvait lui
AJOUTER lock=yes (ou water_lock=yes SANS TOUCHER à waterway=riverbank qui
est gardé.

Et en aucun cas, là encore, avec cette solution on n'avait un un NOEUD
avec waterway=riverbank (avec ou sans lock=yes).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr