Re: [OSM-talk-fr] question osmose/limite administrative

[Jérôme Amagat]

Moi ce que j'ai compris aux lois françaises sachant que je vis très loin de
toute les mers et océans :) c'est ça :
tu parles beaucoup des eaux intérieurs mais j'ai l'impression que ce terme
a une définition mais dans la réalité ne sert à rien. Rien ne s'applique
qu'aux eaux intérieurs.
La limite des communes, départements et régions en France c'est la laisse
des plus hautes mers donc le trait de cote avec un coef 120. Après cette
limite c'est le domaine maritime public jusqu’à la limite territorial qui
est à 12 miles de la ligne de base (et la ligne de base ne sert
pratiquement qu'à tracer cette limite). Sauf pour les terrains qui était
dans le domaine maritime public et qui ne sont plus du même coté que la
laisse des plus hautes mers (parti qui s'est ensablé ou digue) et qui le
reste (dans le domaine maritime public). Et cette parti dépend d'un préfet
donc de l'état.

Par contre pour osm la ligne natural=coastline pour moi c'est pas claire du
tout où elle se trouve. Dans le cas "normal" elle devrait être, d’après le
wiki, au niveau de la "mean high water spring" (j'ai pas compris ce que
c’était) ce qui correspond (toujours d’après le wiki) à la limite des
débris que l'on voit sur les photo aérienne sur les plages.
Et pour le cas des estuaires, il n'y a pas de règle est des fois la limite
est au niveau d'un pont ou s'enfonce pas du tout dans les terre ou
s'enfonce beaucoup.

pour les communes littorales, ce que j'ai rapidement comprit c'est que au
niveau des estuaires il n'y a pas d’obligation que la commune qui a quand
même l'influence de la marée mais pas l’océan à ses frontières soit une
commune littorales.

J'ai lu sur le wiki par contre que limite de pays et limite des cote donc
boundary=administrative au niveau du bord de mer n'est pas obligatoirement
au même endroit que natural=coastline. (mais je trouve que c'est plus
simple et clair d'avoir qu'une seul "frontière")

Le 20 décembre 2016 à 22:17,  a écrit :

> Oui et non.
>
> C'est effectivement côté trait de côte à la limite à une coefficient de
> 120 ou 95 mais pour la Laïta, c'est dû au fait que l'on considère les eau
> intérieures ou pas.
>
> Dans OSM on arrête assez tôt la pleine mer (grosso modo au droit de la
> plage), dans le trait de côté du SHOM on s'arrête plus logiquement au port
> maritime le plus à l'intérieur - ici le port de Guidel.
>
> Mais faute de règle claire suivant les abers, c'est considéré comme eaux
> "intérieures" (Laïta, Elorn, Ria d'Etel) ou pas, y compris au delà d'un
> ouvrage d'art (Aber Wrac'h au sud de Plouguerneau).
>
> Du coup, du côté de le Ria d'Etel, aussi beaucoup de notifications OSM.
>
> N.B. : le terme eaux intérieures n'est pas exact, les eaux intérieures
> sont les eaux en amont de la ligne de base - grosso-modo en amont de la
> laisse de basse mer, précisément en amont de la ligne de base.
>
> Aussi du côté de Santec http://www.openstreetmap.org/way/70733263
>
> Si on prenait comme trait de côté le coef de 95, ça me semblerait plus
> simple que des traits arbitraires (sauf si on dit ouvrage d'art de moins de
> X m au dessus des flots).
>
> Je n'arrive plus à retrouver cette couche du SHOM ni sur le site du SHOM
> ni sur Cartelie
> 
> mais ils mettent la limite des eaux intérieures juste en amont du port de
> Guidel au Bas-Pouldu.
>
> Et en amont des eaux intérieures on prend le milieu du fleuve
> (grosso-modo) sur OSM. Même dans les zones de marnage (jusqu'à Quimperlé),
> même dans les zones d'eaux saumâtres (limite plus au sud, entre Guidel et
> Clohars-Carnoët).
>
> Ce qui n'est peut-être pas à faire. Ou comme sur l'Elorn faire un
> natural=coastline (actuellement il y a un waterway=riverbank) quitte à ne
> pas le mettre entièrement dans le coastline mondial.
>
> N.B. : la commune de Quimperlé n'est pas une commune littorale alors que
> le trait de côte arrive à Quimperlé (logique, la Laïta est partie maritime
> de l'Ellé et Quimperlé vient de kemper, confluent en breton - de l'Isole et
> de l'Ellé).
>
> On avait les name=arbre, on a aussi les name=digue :
>
> http://www.openstreetmap.org/way/192460601#map=18/48.66796/-4.21447
>
> http://www.openstreetmap.org/way/301776271
>
> http://www.openstreetmap.org/way/229214469
>
>
> Jean-Yvon
>
> Le 20/12/2016 à 03:30, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
>
>
> Le 19 décembre 2016 à 23:12,  a écrit :
>
>> http://osmose.openstreetmap.fr/fr/map/#layer=Mapnik&zoom=13&;
>> lat=47.8061&lon=-3.5178
>> Au vu de ce qui précède et comme on sait que le cadastre est assez
>> fantaisiste sur les rivières il est permis de ce demander s'il n'en est de
>> même pour Admin express.
>> Le fait est qu'avec un fleuve dans un estran sableux, la limite
>> administrative est quelque peu arbitraire et je ne vois pas ce qui est bon.
>> Si je comprends bien Osmose, Admin express considère que les limites de
>> Clohars-Carnoët et de Guidel ne son

Re: [OSM-talk-fr] question osmose/limite administrative

[osm . sanspourriel]

Oui et non.

C'est effectivement côté trait de côte à la limite à une coefficient de 
120 ou 95 mais pour la Laïta, c'est dû au fait que l'on considère les 
eau intérieures ou pas.


Dans OSM on arrête assez tôt la pleine mer (grosso modo au droit de la 
plage), dans le trait de côté du SHOM on s'arrête plus logiquement au 
port maritime le plus à l'intérieur - ici le port de Guidel.


Mais faute de règle claire suivant les abers, c'est considéré comme eaux 
"intérieures" (Laïta, Elorn, Ria d'Etel) ou pas, y compris au delà d'un 
ouvrage d'art (Aber Wrac'h au sud de Plouguerneau).


Du coup, du côté de le Ria d'Etel, aussi beaucoup de notifications OSM.

N.B. : le terme eaux intérieures n'est pas exact, les eaux intérieures 
sont les eaux en amont de la ligne de base - grosso-modo en amont de la 
laisse de basse mer, précisément en amont de la ligne de base.


Aussi du côté de Santec http://www.openstreetmap.org/way/70733263

Si on prenait comme trait de côté le coef de 95, ça me semblerait plus 
simple que des traits arbitraires (sauf si on dit ouvrage d'art de moins 
de X m au dessus des flots).


Je n'arrive plus à retrouver cette couche du SHOM ni sur le site du SHOM 
ni sur Cartelie 
 
mais ils mettent la limite des eaux intérieures juste en amont du port 
de Guidel au Bas-Pouldu.


Et en amont des eaux intérieures on prend le milieu du fleuve 
(grosso-modo) sur OSM. Même dans les zones de marnage (jusqu'à 
Quimperlé), même dans les zones d'eaux saumâtres (limite plus au sud, 
entre Guidel et Clohars-Carnoët).


Ce qui n'est peut-être pas à faire. Ou comme sur l'Elorn faire un 
natural=coastline (actuellement il y a un waterway=riverbank) quitte à 
ne pas le mettre entièrement dans le coastline mondial.


N.B. : la commune de Quimperlé n'est pas une commune littorale alors que 
le trait de côte arrive à Quimperlé (logique, la Laïta est partie 
maritime de l'Ellé et Quimperlé vient de kemper, confluent en breton - 
de l'Isole et de l'Ellé).


On avait les name=arbre, on a aussi les name=digue :

http://www.openstreetmap.org/way/192460601#map=18/48.66796/-4.21447

http://www.openstreetmap.org/way/301776271

http://www.openstreetmap.org/way/229214469


Jean-Yvon


Le 20/12/2016 à 03:30, Jérôme Amagat - jerome.ama...@gmail.com a écrit :



Le 19 décembre 2016 à 23:12, > a écrit :



http://osmose.openstreetmap.fr/fr/map/#layer=Mapnik&zoom=13&lat=47.8061&lon=-3.5178


Au vu de ce qui précède et comme on sait que le cadastre est assez
fantaisiste sur les rivières il est permis de ce demander s'il
n'en est de même pour Admin express.
Le fait est qu'avec un fleuve dans un estran sableux, la limite
administrative est quelque peu arbitraire et je ne vois pas ce qui
est bon.
Si je comprends bien Osmose, Admin express considère que les
limites de Clohars-Carnoët et de Guidel ne sont pas dans la
rivière mais sur les rives avec un no-mans-land entre les deux.
Et donc des 586,3 m et 227,4 m


de décalage car deux bras perpendiculaires éloignent les terres du
milieu du cours d'eau. On dépasse même les 7000 m au sud.

Bizarre, non ?

Du côté de l'Aulne : même motif, même punition.

Quant aux côtes

,
visiblement Admin express prend un coefficient de 120.

C'est le même problème pour tes 2 cas, on est, pour les 2, derrière la 
laisse des plus hautes mers (coef 120 oui) et c'est là que s’arrête 
les pouvoirs des mairies (sauf exception comme la baignade) et on est 
dans le domaine maritime public qui dépend de l'état.
Dans osm la limite terre mer et donc de limite des communes c'est 
autre chose (mais quoi je sais pas trop ? lié aux orthophoto surtout)
Pour la laisse de haute mer, il y a le SHOM qui l'a mis en open data 
https://www.data.gouv.fr/fr/datasets/trait-de-cote-histolitt/

On peut la voir sur geoportail.gouv.fr  :
https://www.geoportail.gouv.fr/carte?c=-3.5397163200782202,47.801968186793914&z=12&l0=ORTHOIMAGERY.ORTHOPHOTOS:WMTS(1)&l1=GEOGRAPHICALGRIDSYSTEMS.MAPS.SCAN-EXPRESS.STANDARD::GEOPORTAIL:OGC:WMTS(1)&l2=ELEVATION.LEVEL0:WMTS(1)&permalink=yes 



Jean-Yvon

Le 19/12/2016 à 21:45, Christian Quest - cqu...@openstreetmap.fr
 a écrit :

Je viens de mettre ça en route cet après-midi ;)

 

Re: [OSM-talk-fr] Données du STIF sur Osmose

[Noémie Lehuby]

Bonjour,

Bonne idée Christian !
j'ai créé une page de débug qui précise, dans OSM et dans l'opendata, 
pour chaque arrêt avec une ref STIF, les lignes desservies :

https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=472985886

il faut lui passer en paramètre l'id OSM du noeud correspondant à 
l'arrêt.


Ça gère aussi les cas où un arrêt OSM correspond à plusieurs arrêts dans 
l'opendata (dont certains pas forcément du bon côté de la route ...) :

https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=928458342

N'hésitez pas à l'utiliser pour vérifier vos ajouts de références STIF 
;)


Noémie


Date: Mon, 19 Dec 2016 18:42:52 +0100
From: Christian Quest 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose
Message-ID:

Content-Type: text/plain; charset="utf-8"

C'est trompeur en effet...

J'ai intégré des arrêts sur ma commune et il manque quelques infos de
contexte pour savoir qu'on ajoute bien le bon ID quand il y a 
ambiguité. Il

faudrait par exemple le N° des lignes et la direction sinon deux arrêts
proches peuvent être intervertis très facilement.



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

Re: [OSM-talk-fr] chef-lieu de communes fusionnées

[Jérôme Amagat]

Le 20 décembre 2016 à 10:45, Christian Quest  a
écrit :

> Cherbourg est à Cherbourg-en-Cotentin ce que Belleville est à Paris sauf
> que le chef lieu de Paris c'est Paris ;)
>
pas vraiment, je dirais plutôt que Cherbourg est l'équivalent de Paris dans
ce cas et Octeville est Belleville et donc Cherbourg restera comme nom de
ville et Octeville deviendra un quartier vu que ça se touche. Mais là il y
a une différence c'est que le résultat de la fusion donne une commune avec
un nouveau nom peut etre que le "en-cotentin" restera come il fut ajouter
des "sur-machin" pour différencier des ville de même nom mais je pense que
pour l'instant la ville c'est Cherbourg même si je suis pas du tout du coin.

> Effectivement, ne plus du tout avoir le nom de l'ancienne commune car elle
> est devenue le chef lieu de la commune nouvelle est dommage. Il me semble
> utile de le préserver sur le noeud place=* mis en admin_centre.
>
Et donc le seul endroit où l'on va trouver le nom "Cherbourg-en-Cotentin"
c'est sur la relation de la commune (ou alors il faudrait creer un node
avec un place=municipality ou un truc du genre  et le mettre dans la
relation avec role label)?


> On va encore avoir une grosse passe de mise au propre au 1er janvier et
> autant se mettre d'accord sur ce genre de détail pour êtr ehomogène et bien
> documenter tout ça.
>

Il y a les code Insee aussi qu'est ce qu'on en fait pour les ancienne
communes? on les laisse et alors il y en a en double sur des admin_centre=8
et =9, on les supprime ou on ajoute un disused:? l'insee va les réattribuer
au moins pour les communes fusionner en 2016

>
>
> Le 20/12/2016 à 04:27, Jérôme Amagat a écrit :
>
> Je profite de ce sujet qui parle de la source "ADMIN EXPRESS" de l'IGN
> pour dire qu'il y a dans cette source les chefs lieu de communes avec leur
> nom.
> Par exemple pour la commune de Cherbourg-en-Cotentin le chef lieu c'est
> "Cherbourg" alors que dans osm l'admin_centre de la commune c'est un node
> place=town name=Cherbourg-en-Cotentin (avec name:fr=Cherbourg-Octeville
> ) et il n'y a plus rien comme place=* qui s'appelle Cherbourg (j'ai pas
> l'impression qu'il y ai même un quartier de  ce nom).
> Donc d'apres l'IGN Cherbourg est un chef lieu donc une ville (enfin pour
> moi un chef lieu c'est une ville (ou village ou hameau)) et dans osm
> Cherbourg n'est plus rien la ville Cherbourg a disparu au profit de
> cherbourg-Octeville puis Cherbourg-en-Cotentin avec la création d'une
> commune nouvelle.
> Pour moi les communes ont fusionnées mais les villes n'ont pas bougé il y
> a toujours une ville Cherbourg, une autre Octeville ... et il n'y a pas de
> ville s'appelant cherbourg-Octeville ou Cherbourg-en-Cotentin.
> Je donne en exemple cette commune parce qu'elle est importante mais c'est
> la même chose pour beaucoup de commune nouvelle et même des fusions de
> communes datant de plusieurs dizaines d'années.
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose et adresses bis

[Mathias Jérôme]

Les bis, ter etc... sont des indices de répétitions, mais les A,B,C etc... sont 
plutôt ce que j'appellerais des indices de déclinaisons (dans le cas du 36bis 
c'est que le 36 existe (ou existait) et est (était)  vraiment distinct, tandis 
que le 36A il est souvent situé au situé au 36, de même que le 36B se situera 
aussi au 36 , de fait les A,B,C,etc... sont souvent de la numérotation d'ordre 
"privative" : accès ou cages d'escaliers).
Personnellement, j'aime la solution de Christian car cela permet de distinguer 
clairement dans les référentiels les type "numéroteur"  des éléments de type 
"numéroté" (qui sont à titre principal des libellés de voie).
Et une fois tous les numéroteurs agrégés on pourra les séparer (encore bien sûr 
faut-il qu'ils soit de nature différentes, ici chiffres + lettres ça va on 
saura toujours les séparer au bon endroit).
Ce qui n'empêchera pas ensuite un traitement différent du cas du 36 A rue 
tartampion avec l'éventuelle suppression du A , du traitement du 36-Bis rue 
tartampion ,  qui n'a pas grand chose à voir avec le 36 si ce une forte 
probabilité de proximité.





  De : Tyndare 
 À : Discussions sur OSM en français  
 Envoyé le : Mardi 20 décembre 2016 16h18
 Objet : Re: [OSM-talk-fr] osmose et adresses bis
   


On 20/12/2016 12:40, Christian Quest wrote:
> A ma connaissance, il n'y a pas franchement de règle pour coller ou non
> les indices de répétitiion (c'est leur petit nom) aux numéros.

D'après le Larousse[1] bis et ter sont des adverbes, et en français je 
ne crois pas qu'on puisse coller l'adverbe au mot qu'il qualifie.

>
> On peut par contre se fixer une convention dans OSM.

+1, mais faut tomber d'accord et le terrain je ne suis pas sur qu'il 
respecte toujours la même convention ;-)

>
> Je favoriserait le fait de coller les indices, car on peut facilement
> les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
> reste de l'adresse comme ça peut être le cas avec un "34 A" le "A"
> pouvant être un "à...".

C'est plus simple de supprimer les espaces si besoin que d'avoir a en 
rajouter.
De la même manière qu'on ne met pas d'abréviation dans OSM, je 
pencherais plus pour garder une information la plus lisible et correcte 
possible dans OSM, et de documenter les règles de normalisation a 
appliquer pour obtenir une recherche optimale.

Donc je voudrais qu'on privilégie bis/ter/quater plutôt que b/t/q, et 
qu'on garde un espace dans ces cas là.

Par contre entre les numéros et les lettres A/B/C/... là j'ai pas 
vraiment d'avis si un espace est préférable on non.

Actuellement l'export semi automatique des adresses depuis le cadastre 
rajoute un espace par défaut dans tous les cas.
Si on décide que ce n'est pas souhaitable, il faudra changer ça et 
envisager une correction automatique de ce qui a déjà été importé.

> Les bis/ter/quater... devraient être en minuscules, les A/B/C en
> majuscule. Ils ont du coup différenciés et c'est aussi à mon avis plus
> "joli" en terme de graphie, mais là c'est une histoire de goût.

Je crois qu'on m'avais fait remarqué qu'il y a des villages en Alsace où 
sur le terrain les lettres comme a/b/c... sont écrites en minuscule mais 
je n'en suis pas sûr.

> Quand on ne sait pas si un b/t/q est un bis/ter/quater (cas possible
> avec le cadastre ou la BAN) je le laisserai en minuscule.

Là ça deviens subtil, peut être rajouter un tag "note" pour expliquer 
que la valeur peut être raffinée pour être moins ambigue.
De toute façon une fonction de normalisation pour la recherche d'adresse 
devrait générer la même chose dans tous les cas (que ce soit B, b ou bis 
avec ou sans espace)

 >
> Le 20 décembre 2016 à 12:02, Julien Lepiller  > a écrit :
>
>    Bonjour,
>
>    au moins sur Rennes, les adresses en "bis" et "ter" sont indiquées
>    en erreur sur osmose. Elles sont bien indiquées sur OSM, par exemple :
>
>    https://www.openstreetmap.org/node/4225509127
>    
>
>    a le tag addr:housenumber = "39 bis", et osmose propose plutôt
>    "39bis" (sans espace), de même pour toutes les adresses contenant un
>    "ter", et c'est exactement l'inverse quand l'adresse comporte une
>    lettre (https://www.openstreetmap.org/node/3805090559
>    ). Quelle est la
>    norme pour ces adresses ? Avec ou sans espace ? Comment corriger ça
>    durablement (histoire que ça ne se répète pas sur un import futur) ?
>    Ça fait plein de points sur osmose, c'est pas beau, et j'aimerais
>    bien que ça disparaisse ;)
>

[1] http://www.larousse.fr/dictionnaires/francais/bis/9553?q=bis

___
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] osmose et adresses bis

[Tyndare]

On 20/12/2016 12:40, Christian Quest wrote:

A ma connaissance, il n'y a pas franchement de règle pour coller ou non
les indices de répétitiion (c'est leur petit nom) aux numéros.


D'après le Larousse[1] bis et ter sont des adverbes, et en français je 
ne crois pas qu'on puisse coller l'adverbe au mot qu'il qualifie.




On peut par contre se fixer une convention dans OSM.


+1, mais faut tomber d'accord et le terrain je ne suis pas sur qu'il 
respecte toujours la même convention ;-)




Je favoriserait le fait de coller les indices, car on peut facilement
les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
reste de l'adresse comme ça peut être le cas avec un "34 A" le "A"
pouvant être un "à...".


C'est plus simple de supprimer les espaces si besoin que d'avoir a en 
rajouter.
De la même manière qu'on ne met pas d'abréviation dans OSM, je 
pencherais plus pour garder une information la plus lisible et correcte 
possible dans OSM, et de documenter les règles de normalisation a 
appliquer pour obtenir une recherche optimale.


Donc je voudrais qu'on privilégie bis/ter/quater plutôt que b/t/q, et 
qu'on garde un espace dans ces cas là.


Par contre entre les numéros et les lettres A/B/C/... là j'ai pas 
vraiment d'avis si un espace est préférable on non.


Actuellement l'export semi automatique des adresses depuis le cadastre 
rajoute un espace par défaut dans tous les cas.
Si on décide que ce n'est pas souhaitable, il faudra changer ça et 
envisager une correction automatique de ce qui a déjà été importé.



Les bis/ter/quater... devraient être en minuscules, les A/B/C en
majuscule. Ils ont du coup différenciés et c'est aussi à mon avis plus
"joli" en terme de graphie, mais là c'est une histoire de goût.


Je crois qu'on m'avais fait remarqué qu'il y a des villages en Alsace où 
sur le terrain les lettres comme a/b/c... sont écrites en minuscule mais 
je n'en suis pas sûr.



Quand on ne sait pas si un b/t/q est un bis/ter/quater (cas possible
avec le cadastre ou la BAN) je le laisserai en minuscule.


Là ça deviens subtil, peut être rajouter un tag "note" pour expliquer 
que la valeur peut être raffinée pour être moins ambigue.
De toute façon une fonction de normalisation pour la recherche d'adresse 
devrait générer la même chose dans tous les cas (que ce soit B, b ou bis 
avec ou sans espace)


>

Le 20 décembre 2016 à 12:02, Julien Lepiller mailto:o...@lepiller.eu>> a écrit :

Bonjour,

au moins sur Rennes, les adresses en "bis" et "ter" sont indiquées
en erreur sur osmose. Elles sont bien indiquées sur OSM, par exemple :

https://www.openstreetmap.org/node/4225509127


a le tag addr:housenumber = "39 bis", et osmose propose plutôt
"39bis" (sans espace), de même pour toutes les adresses contenant un
"ter", et c'est exactement l'inverse quand l'adresse comporte une
lettre (https://www.openstreetmap.org/node/3805090559
). Quelle est la
norme pour ces adresses ? Avec ou sans espace ? Comment corriger ça
durablement (histoire que ça ne se répète pas sur un import futur) ?
Ça fait plein de points sur osmose, c'est pas beau, et j'aimerais
bien que ça disparaisse ;)



[1] http://www.larousse.fr/dictionnaires/francais/bis/9553?q=bis

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

Re: [OSM-talk-fr] osmose et adresses bis

[Christian Quest]

A ma connaissance, il n'y a pas franchement de règle pour coller ou non les
indices de répétitiion (c'est leur petit nom) aux numéros.

On peut par contre se fixer une convention dans OSM.

Je favoriserait le fait de coller les indices, car on peut facilement les
séparer si besoin et surtout ça évite de créer une ambiguïté avec le reste
de l'adresse comme ça peut être le cas avec un "34 A" le "A" pouvant être
un "à...".

Les bis/ter/quater... devraient être en minuscules, les A/B/C en majuscule.
Ils ont du coup différenciés et c'est aussi à mon avis plus "joli" en terme
de graphie, mais là c'est une histoire de goût.

Quand on ne sait pas si un b/t/q est un bis/ter/quater (cas possible avec
le cadastre ou la BAN) je le laisserai en minuscule.


Je vois par contre qu'il y a des adresses en doublon... comme le 47 rue de
Châteaugiron, ou le 23 qui existe en 5 exemplaires... l'import est à revoir
car je pense qu'on mélange ici la notion de "plaque" et la notion d'entrée
et/ou de bâtiment et/ou une mauvaise prise en compte des indices de
répétition.

Pour le 23, ce sont les A/B/C/D qui manquent... ils sont dans la colonne
"adresse" comme les bis/ter, mais si c'est la colonne "extension" qui a été
utilisée, ils n'y sont pas car ils se trouvent en colonne "bâtiment".

Import à rectifier... heureusement il y a les source:addr:housenumber:ref
qui vont permettre de remettre ça au propre automatiquement.



Le 20 décembre 2016 à 12:02, Julien Lepiller  a écrit :

> Bonjour,
>
> au moins sur Rennes, les adresses en "bis" et "ter" sont indiquées en
> erreur sur osmose. Elles sont bien indiquées sur OSM, par exemple :
>
> https://www.openstreetmap.org/node/4225509127
>
> a le tag addr:housenumber = "39 bis", et osmose propose plutôt "39bis"
> (sans espace), de même pour toutes les adresses contenant un "ter", et
> c'est exactement l'inverse quand l'adresse comporte une lettre (
> https://www.openstreetmap.org/node/3805090559). Quelle est la norme pour
> ces adresses ? Avec ou sans espace ? Comment corriger ça durablement
> (histoire que ça ne se répète pas sur un import futur) ? Ça fait plein de
> points sur osmose, c'est pas beau, et j'aimerais bien que ça disparaisse ;)
>
> ___
> 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

[OSM-talk-fr] osmose et adresses bis

[Julien Lepiller]

Bonjour,

au moins sur Rennes, les adresses en "bis" et "ter" sont indiquées en 
erreur sur osmose. Elles sont bien indiquées sur OSM, par exemple :


https://www.openstreetmap.org/node/4225509127

a le tag addr:housenumber = "39 bis", et osmose propose plutôt "39bis" 
(sans espace), de même pour toutes les adresses contenant un "ter", et 
c'est exactement l'inverse quand l'adresse comporte une lettre 
(https://www.openstreetmap.org/node/3805090559). Quelle est la norme 
pour ces adresses ? Avec ou sans espace ? Comment corriger ça 
durablement (histoire que ça ne se répète pas sur un import futur) ? Ça 
fait plein de points sur osmose, c'est pas beau, et j'aimerais bien que 
ça disparaisse ;)


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

Re: [OSM-talk-fr] question osmose/limite administrative

[Christian Quest]

Pour visualiser les limites d'ADMIN EXPRESS, je les ai ajoutées dans le 
rendu "Route500" (pointillé violet + nom des communes).


Merci pour vos retours sur l'opportunité de garder cette analyse... j'ai 
un gros doute sur la pertinence d'après mes contrôles sur le 89 (donc 
pas en lien avec les limites terre/mer). La majorité des décalages 
importants ne sont pas cohérents avec les cadastres des communes 
limitrophes (j'affiche la couche cadastre + route500 dans JOSM pour 
comparer).


Dans quelques cas (un sur dix ?), il y avait bien un décalage dans OSM 
par rapport au cadastre...



Le 19/12/2016 à 23:12, osm.sanspourr...@spamgourmet.com a écrit :

http://osmose.openstreetmap.fr/fr/map/#layer=Mapnik&zoom=13&lat=47.8061&lon=-3.5178
Au vu de ce qui précède et comme on sait que le cadastre est assez 
fantaisiste sur les rivières il est permis de ce demander s'il n'en 
est de même pour Admin express.
Le fait est qu'avec un fleuve dans un estran sableux, la limite 
administrative est quelque peu arbitraire et je ne vois pas ce qui est 
bon.
Si je comprends bien Osmose, Admin express considère que les limites 
de Clohars-Carnoët et de Guidel ne sont pas dans la rivière mais sur 
les rives avec un no-mans-land entre les deux.
Et donc des 586,3 m et 227,4 m 
 
de décalage car deux bras perpendiculaires éloignent les terres du 
milieu du cours d'eau. On dépasse même les 7000 m au sud.


Bizarre, non ?

Du côté de l'Aulne : même motif, même punition.

Quant aux côtes 
, 
visiblement Admin express prend un coefficient de 120.


Jean-Yvon

Le 19/12/2016 à 21:45, Christian Quest - cqu...@openstreetmap.fr a écrit :

Je viens de mettre ça en route cet après-midi ;)

La source c'est "ADMIN EXPRESS" de l'IGN... nettement plus précis que 
feu GEOFLA.


Par contre, j'avais mis un seuil à 30m ce qui semble trop faible, il 
va passer à 50m (mise à jour en cours).


Je ne sais pas quelle est la précision exacte de cette source, 
annoncée à "15m d'erreur quadratique" mais visiblement ça me semble 
optimiste... si il faut on montera encore plus haut le seuil.






___
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] chef-lieu de communes fusionnées

[Christian Quest]

Cherbourg est à Cherbourg-en-Cotentin ce que Belleville est à Paris sauf 
que le chef lieu de Paris c'est Paris ;)


Effectivement, ne plus du tout avoir le nom de l'ancienne commune car 
elle est devenue le chef lieu de la commune nouvelle est dommage. Il me 
semble utile de le préserver sur le noeud place=* mis en admin_centre.


On va encore avoir une grosse passe de mise au propre au 1er janvier et 
autant se mettre d'accord sur ce genre de détail pour êtr ehomogène et 
bien documenter tout ça.



Le 20/12/2016 à 04:27, Jérôme Amagat a écrit :
Je profite de ce sujet qui parle de la source "ADMIN EXPRESS" de l'IGN 
pour dire qu'il y a dans cette source les chefs lieu de communes avec 
leur nom.
Par exemple pour la commune de Cherbourg-en-Cotentin le chef lieu 
c'est "Cherbourg" alors que dans osm l'admin_centre de la commune 
c'est un node place=town name=Cherbourg-en-Cotentin (avec 
name:fr=Cherbourg-Octeville ) et il n'y a plus rien comme place=* 
qui s'appelle Cherbourg (j'ai pas l'impression qu'il y ai même un 
quartier de  ce nom).
Donc d'apres l'IGN Cherbourg est un chef lieu donc une ville (enfin 
pour moi un chef lieu c'est une ville (ou village ou hameau)) et dans 
osm Cherbourg n'est plus rien la ville Cherbourg a disparu au profit 
de cherbourg-Octeville puis Cherbourg-en-Cotentin avec la création 
d'une commune nouvelle.
Pour moi les communes**ont fusionnées mais les villes n'ont pas bougé 
il y a toujours une ville Cherbourg, une autre Octeville ... et il n'y 
a pas de ville s'appelant cherbourg-Octeville ou Cherbourg-en-Cotentin.
Je donne en exemple cette commune parce qu'elle est importante mais 
c'est la même chose pour beaucoup de commune nouvelle et même des 
fusions de communes datant de plusieurs dizaines d'années.



___
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

[OSM-talk-fr] Défusion de communes !

[Christian Quest]

A ne pas oublier...

http://www.paris-normandie.fr/actualites/politique/sigy-en-bray-et-saint-lucien-se-separent-a-l-amiable-JI7802209


--
Christian Quest - OpenStreetMap France


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