Re: [OSM-talk-fr] Qualité: Vérification et amélioration de la désignation de l'étiquette place

[Pieren]

2014-10-03 20:33 GMT+02:00 Jérôme Seigneuret :

Je suis d'accord pour virer les place=locality en zones habitées. Pour
excuser leurs auteurs, il faut dire qu'ils ont souvent été ajoutés à
une époque où les tags quarter/neighbourhood n'existaient pas.
Comparativement, "suburb" est beaucoup plus ancien mais ça ne
fonctionne que pour les grandes villes (city/town) et sa traduction
par "banlieu" en français peut expliquer son faible usage chez nous.

> En effet. Mais pour le landuse moi ça me pose un problème. Car certaines
> zones sont mixtes et portent sur une même ZAC dans laquelle tu as de
> l'industrielle de l'habitation et du commerciale...voir même de l'agricole
> ducoup ça te fait 4 landuses.

Normalement, on utilise le tag "place" pour les toponymes. Mais tous
les toponymes dans OSM n'ont pas leur tag "place" (rivières, cols,
sommets). Et comme le dit wikipedia, la toponymie n'est pas une
science exacte (euphémisme). Reste à savoir si une ZI ou une ZAC est
un toponyme.

> Ton site n'est pas un voisinage car bien trop grand pour être considéré
> comme tel et c'est pas un Quartier officiellement.

La définition entre suburb/quarter/neighbourhood est très vague sur le
wiki en anglais. On nous décrit la hiérarchie mais rien sur les
limites. Par contre, le wiki montre une forte réticence au tag
"quarter" (le vote est passé de justesse et le tableau "place"
rappelle que les anglophones ne comprennent pas la nuance avec
neighbourhood).

> Globallement pour le routing on utilise les valeurs de clé highway et place
> et non le landuse! Sauf si ça a changé... Donc si tu mets le nom dans cet
> élément tu pers la possibilité de l'utiliser en routing...

Heureusement, nominatim supporte bien plus que ces deux tags:
http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/FR

> C'est un proposed_feature certes, mais pas seulement, vu qu'il est ajouter
> sur la page du wiki  de la clé place sans plus de précision d'ailleurs sur
> comment l'utiliser(d'où la tentative de préciser son utilisation)... Dans ce
> cas, si il ne sert à rien chez nous pourquoi l'avoir ajouté (sachant que les
> pages peuvent et sont prévu pour ne pas forcément évoluer de la même
> manière) et même le laisser au risque d'avoir des choses pas très homogènes
> sur une même ville?
> Si l'on considère que 2 niveau sont suffisant (place=suburb,
> place=neighbourhood ) et que le tag quarter ne sert strictement à rien en
> France, ne devrait-on pas dire dans le wiki de ne pas l'utiliser?!

C'est à nous de décider dans quelle mesure ces tags s'adaptent à notre
contexte local. Si on arrive à trouver une bonne définition de l'usage
de "quarter", entre "suburb" et "neighbourhood", je n'ai rien contre
par principe, même s'il est faiblement utilisé pour l'instant d'après
taginfo.

Pieren

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

Re: [OSM-talk-fr] amenity=place_of_worship sur église en ruine

[Pieren]

2014-10-03 21:31 GMT+02:00 DH :

> La tentation, c'est un des dangers qu'OSM se doit d'éviter et la notion de
> beau reste, finalement, assez subjective.

Grave question : à partir de quand un bâtiment en ruine perd son
qualificatif de "building" ? lorsqu'il perd son toit ? un pan de mur ?
vitres cassées ? plus de porte ?

Pieren

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

Re: [OSM-talk-fr] amenity=place_of_worship sur église en ruine

[Francescu GAROBY]

Quand on le déclare inaccessible au public, pour des raisons de sécurité ?

Le 6 octobre 2014 13:31, Pieren  a écrit :

> 2014-10-03 21:31 GMT+02:00 DH :
>
> > La tentation, c'est un des dangers qu'OSM se doit d'éviter et la notion
> de
> > beau reste, finalement, assez subjective.
>
> Grave question : à partir de quand un bâtiment en ruine perd son
> qualificatif de "building" ? lorsqu'il perd son toit ? un pan de mur ?
> vitres cassées ? plus de porte ?
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Liste des voies OSM et codes FANTOIR par commune

[Yves Pratter]

Le 6 oct. 2014 à 08:13, Francescu GAROBY  a écrit :

> À première vue, c'est pas mal du tout, cet outil !
+1

> Juste une suggestion : mettre de la complétion sur le champs "code INSEE". 
> Voire, de la complétion à partir du nom de commune et proposer le code INSEE 
> correspondant.
+1

Petit détail : Peux-tu aussi afficher le nom de la commune en titre dans la 
page web ?
(balise TITLE et balise H1 par exemple).

Éternoz — Correspondance entre FANTOIR et voies OSM

Merci,

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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Pieren]

Et ben, au risque de faire tâche, je pense qu'OSM n'est pas capable de
devenir un référentiel adresse. On le sait tous, l'immense majorité
des adresses dans OSM vient du cadastre. Et celles-ci sont bourrées
d'erreur ou sont des prévisions. Alors, ensuite, on peut dire qu'avec
OSM, chacun peut corriger (d'ailleurs OSM ne serait finalement sensé
servir qu'à ça). Et s'il y a vandalisme, quelqu'un d'autre s'en
apercevra tôt ou tard, corriger, etc. Mais un référentiel ne peut pas
se satisfaire d'un "tôt ou tard". Il est évident que pour avoir un
niveau de confiance absolu et constant, cette base adresse ne doit
être modifiable que par un public restreint, identifié et responsable,
ce qu'OSM ne peut pas fournir (sauf à modifier notre modèle). Et je ne
parle même pas de notre incapacité à fixer une modélisation standard
pour les adresses (sur la façade, sur l'entrée. sur la bal, jusqu'au
palier, sur un noeud, sur un polygone, avec ou sans relation, codes
postaux, etc)
Au mieux, on ne peut servir qu'à relever des incohérences entre un
vrai référentiel et nos relevés sur le terrain (comme le fait bano
actuellement en nous comparant au cadastre). Mais une remontée
d'erreur pourrait aussi bien se faire par l'intermédiaire des mairies
qui devraient toutes avoir une compétence directe pour gérer cette
base adresse (à condition d'être bien cadrés).
De plus, l'aspect contaminant d'OdBL n'est pas négligeable. Il est
aussi un frein à de nombreux projets privés qui voudraient utiliser
OSM en général (et pas seulement pour les adresses). A l'IGN, ça les
obligerait à séparer RGE et adresses. Ou encore à mettre tout le RGE
en OdBL, ce qui repousserait le problème de la contamination aux
consommateurs suivants dans la chaîne. Les américains ont résolu le
problême en mettant leurs données dans le domaine publique.

Pieren

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

Re: [OSM-talk-fr] amenity=place_of_worship sur église en ruine

[sylvain letuffe]

On lundi 6 octobre 2014, you wrote:
> Grave question : à partir de quand un bâtiment en ruine perd son
> qualificatif de "building" ? lorsqu'il perd son toit ? un pan de mur ?
> vitres cassées ? plus de porte ?
> 
> Pieren

Question intéressante et récurrente sur le cycle de vie des objets :
Quand passe-t-on à "disused" (inutilisé) puis à "abondonned" puis à "ruined" 
et en effet, ça risque d'être assez flou la limite !

Pour ta question, quand doit on retirer le tag building=x pour devenir autre 
chose je pense que le choix tient dans la définition de "building". Le wiki 
d'osm n'en définit pas le sens pour osm, il nous reste la ou les définitions 
du mot building en anglais. J'en ai trouvé plusieurs sur le net :
la plus courante :
 "A closed structure with walls and a roof." 
( structure = A cohesive whole built up of distinct part)
"A building is a man-made structure with a roof and walls standing more or 
less permanently in one place" (wikipedia)
ou parfois :
"a man-made structure intended for human use or occupation"

Dans le sens des deux premiers, c'est exactement tes deux premières 
propositions, un bâtiment (dans osm) perd sont qualificatif de building s'il 
perd son toit ou un mur.
(branlette de cerveau : et s'il n'a perdu qu'une partie du toit ? a-t-il 
toujours sont toit ?)

Dans la 3ème, s'il n'est plus prévu pour être utilisé par des humains.

ps: on notera au passage que rapport à la première définition 
building=yes + wall=no 
est un usage incohérent que nous avons dans osm

-- 
sly
qui suis-je : http://sly.letuffe.org




--
View this message in context: 
http://gis.19327.n5.nabble.com/amenity-place-of-worship-sur-eglise-en-ruine-tp5819087p5819471.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Christian Quest]

C'est pour ça que BANO existe (et surtout BANO^2), pour se décorreler d'OSM
et apporter la surcouche nécessaire de fiabilisation, d'historisation et
avoir des terme de contribution différents permettant une double licence
sur les contributions faites sur la plateforme BANO^2.

Pour la qualité, il faut avoir un peu regardé la BD Adresse les yeux dans
les yeux pour ne pas avoir à rougir inutilement avec les données actuelles
de BANO.


Le 6 octobre 2014 14:22, Pieren  a écrit :

> Et ben, au risque de faire tâche, je pense qu'OSM n'est pas capable de
> devenir un référentiel adresse. On le sait tous, l'immense majorité
> des adresses dans OSM vient du cadastre. Et celles-ci sont bourrées
> d'erreur ou sont des prévisions. Alors, ensuite, on peut dire qu'avec
> OSM, chacun peut corriger (d'ailleurs OSM ne serait finalement sensé
> servir qu'à ça). Et s'il y a vandalisme, quelqu'un d'autre s'en
> apercevra tôt ou tard, corriger, etc. Mais un référentiel ne peut pas
> se satisfaire d'un "tôt ou tard". Il est évident que pour avoir un
> niveau de confiance absolu et constant, cette base adresse ne doit
> être modifiable que par un public restreint, identifié et responsable,
> ce qu'OSM ne peut pas fournir (sauf à modifier notre modèle). Et je ne
> parle même pas de notre incapacité à fixer une modélisation standard
> pour les adresses (sur la façade, sur l'entrée. sur la bal, jusqu'au
> palier, sur un noeud, sur un polygone, avec ou sans relation, codes
> postaux, etc)
> Au mieux, on ne peut servir qu'à relever des incohérences entre un
> vrai référentiel et nos relevés sur le terrain (comme le fait bano
> actuellement en nous comparant au cadastre). Mais une remontée
> d'erreur pourrait aussi bien se faire par l'intermédiaire des mairies
> qui devraient toutes avoir une compétence directe pour gérer cette
> base adresse (à condition d'être bien cadrés).
> De plus, l'aspect contaminant d'OdBL n'est pas négligeable. Il est
> aussi un frein à de nombreux projets privés qui voudraient utiliser
> OSM en général (et pas seulement pour les adresses). A l'IGN, ça les
> obligerait à séparer RGE et adresses. Ou encore à mettre tout le RGE
> en OdBL, ce qui repousserait le problème de la contamination aux
> consommateurs suivants dans la chaîne. Les américains ont résolu le
> problême en mettant leurs données dans le domaine publique.
>
> Pieren
>
> ___
> 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] Présentation de BANO au CNIG

[Frédéric Rodrigo]

Le 06/10/2014 15:04, Christian Quest a écrit :

C'est pour ça que BANO existe (et surtout BANO^2), pour se décorreler
d'OSM et apporter la surcouche nécessaire de fiabilisation,
d'historisation et avoir des terme de contribution différents permettant
une double licence sur les contributions faites sur la plateforme BANO^2.

Pour la qualité, il faut avoir un peu regardé la BD Adresse les yeux
dans les yeux pour ne pas avoir à rougir inutilement avec les données
actuelles de BANO.


À ce propos, il faudrait que tu nous explique ce que c'est vraiment que 
BANO^2.



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

Re: [OSM-talk-fr] Prix des carburants ?

[Jérôme Amagat]

Bonjour,

C'est si mauvais que ça? j'ai regarder pour quelques points, il sont pas
idéalement placé mais pas non plus très loin : une 50ene de mètre souvent
sur la route à coté de la station à part les station sur autoroute qui là
je suis d'accord sont souvent mal placé).
Il y a bien d'autres chose proposé a l’intégration qui sont pas toujours
bien placé.

Et ajouté les carburants sur les amenity=fuel sans fuel:*=* qui sont proche
(100 metres ?)

Le 4 octobre 2014 19:01, Frédéric Rodrigo  a écrit :

> Bon finalement après mise en place de l'intégration des stations à Osmose
> on a choisi de ne pas activer l'analyse. Le géolocalisation des stations
> étant de mauvaise qualité pour avoir un intérêt.
> Probablement le résultat d'un géocodage de piètre qualité.
>
> Frédéric.
>
>
> Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :
>
>> Oui, enfin ça reste un raffinement
>>
>> Le 26 sept. 2014 18:06, "David Crochet" > > a écrit :
>>
>> Bonjour
>>
>> Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :
>>
>> Mais bizarrement il nb'y a pas de simple payment:cards=yes
>>
>>
>> Non, car il y a des points de vente qui refusent certaines cartes
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>> _
>> 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
>>
>>
>
> ___
> 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] Prix des carburants ?

[Frédéric Rodrigo]

Tu peux de te faire toi même ton idée :
http://osmose.openstreetmap.fr/fr/map/#item=8200&useDevItem=true

C'est un item non actif, donc pas dans le menu et pas de marqueurs sur 
la carte, juste des rectangles.



Le 06/10/2014 15:14, Jérôme Amagat a écrit :

Bonjour,

C'est si mauvais que ça? j'ai regarder pour quelques points, il sont pas
idéalement placé mais pas non plus très loin : une 50ene de mètre
souvent sur la route à coté de la station à part les station sur
autoroute qui là je suis d'accord sont souvent mal placé).
Il y a bien d'autres chose proposé a l’intégration qui sont pas toujours
bien placé.

Et ajouté les carburants sur les amenity=fuel sans fuel:*=* qui sont
proche (100 metres ?)

Le 4 octobre 2014 19:01, Frédéric Rodrigo mailto:fred.rodr...@gmail.com>> a écrit :

Bon finalement après mise en place de l'intégration des stations à
Osmose on a choisi de ne pas activer l'analyse. Le géolocalisation
des stations étant de mauvaise qualité pour avoir un intérêt.
Probablement le résultat d'un géocodage de piètre qualité.

Frédéric.


Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :

Oui, enfin ça reste un raffinement

Le 26 sept. 2014 18:06, "David Crochet" mailto:david.croc...@free.fr>
>__>
a écrit :

 Bonjour

 Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :

 Mais bizarrement il nb'y a pas de simple payment:cards=yes


 Non, car il y a des points de vente qui refusent certaines
cartes

 Cordialement

 --
 David Crochet

 ___
 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




_
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




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

[OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Pieren]

Vu sur la liste dev, une info qui va sans doute intéresser tous les
utilisateurs de nominatim. Deux changements majeurs:
- la prise en compte de la relation waterway pour la recherche de rivières
- les POI comme les magasins et les restaurants peuvent hériter de
l'adresse du bâtiment dans lequel ils se trouvent (ça évitera une
grande partie des doublons)
Le service sur osm.org est déjà mis à jour mais comme il n'y a pas eu
de ré-import il est possible que ça ne fonctionne pas toujours (en
particulier si les nouvelles fonctions exigent des données nouvelles
dans la base nominatim et que celles-ci n'ont pas été modifiées dans
OSM depuis - donc pas de synchronisation rétroactive)

Pieren


-- Forwarded message --
From: Sarah Hoffmann 
Date: Sun, Oct 5, 2014 at 9:48 AM
Subject: [OSM-dev] Nominatim 2.3 release announcement
To: d...@openstreetmap.org


Hi,

we are happy to announce the release of a new stable version 2.3 of
Nominatim, the OSM search engine.

There are two new features that are most notable for users of the
search engine: there is now support for waterway relations, which improves
searching for rivers, and POIs like shops and restaurants now
can inherit their address from the building they are in.

Next to that a lot of smaller bugs have been fixed and further tweaks
to the search algorithm allow for improved ordering of results. This
release also marks the arrival of a functional test suite for
Nominatim.

The new release is available at

http://www.nominatim.org/release/Nominatim-2.3.0.tar.bz2

Installation instructions are at the usual place at

http://wiki.openstreetmap.org/wiki/Nominatim/Installation

You can always try the latest version of Nominatim on

http://nominatim.openstreetmap.org

Regards

Sarah

___
dev mailing list
d...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

Re: [OSM-talk-fr] Prix des carburants ?

[Francescu GAROBY]

Et puis, les stations sur autoroute, il y a moyen de les repérer avec les
photos aériennes. Du coup, ça nécessite clairement de faire le travail
manuellement, mais ça pourrait être utile, non ?

Francescu

Le 6 octobre 2014 15:14, Jérôme Amagat  a écrit :

> Bonjour,
>
> C'est si mauvais que ça? j'ai regarder pour quelques points, il sont pas
> idéalement placé mais pas non plus très loin : une 50ene de mètre souvent
> sur la route à coté de la station à part les station sur autoroute qui là
> je suis d'accord sont souvent mal placé).
> Il y a bien d'autres chose proposé a l’intégration qui sont pas toujours
> bien placé.
>
> Et ajouté les carburants sur les amenity=fuel sans fuel:*=* qui sont
> proche (100 metres ?)
>
> Le 4 octobre 2014 19:01, Frédéric Rodrigo  a
> écrit :
>
> Bon finalement après mise en place de l'intégration des stations à Osmose
>> on a choisi de ne pas activer l'analyse. Le géolocalisation des stations
>> étant de mauvaise qualité pour avoir un intérêt.
>> Probablement le résultat d'un géocodage de piètre qualité.
>>
>> Frédéric.
>>
>>
>> Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :
>>
>>> Oui, enfin ça reste un raffinement
>>>
>>> Le 26 sept. 2014 18:06, "David Crochet" >> > a écrit :
>>>
>>> Bonjour
>>>
>>> Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :
>>>
>>> Mais bizarrement il nb'y a pas de simple payment:cards=yes
>>>
>>>
>>> Non, car il y a des points de vente qui refusent certaines cartes
>>>
>>> Cordialement
>>>
>>> --
>>> David Crochet
>>>
>>> _
>>> 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
>>>
>>>
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Jérôme Seigneuret]

Je suis pas d'accord avec toi sur ce point du vandalisme Peiren.

Parcontre il est clair que pouvoir donner le contrôle aux organismes qui
attributs les permis de construire ça semble indispensable pour avoir les
infos à jour en directe car il me semble que c'est à ce moment que l'on va
créer l'info d'adressage réel (tant qu'il n'y a pas de premier PC il n'y a
qu'un adressage et un nommage de rue fictif).

Quoi qu'il en soit, il faut pouvoir identifier en temps réel du POST PUT
DELETE des adresses et avoir une parallélisation des données de référence
considérés comme sûre (source de données contenant uniquement des données
validées et de référence).

N'importe qui peut saisir ou corrigé ou supprimé et ça c'est la base d'OSM.
En cas de suppression ou de modification il faudra bien pouvoir analyser
tous ça et c'est déjà le cas pour les données IGN avec les points
géodésiques (c'est pas du temp réel mais c'est déjà ça)!

Après au niveau modèle, n'est il pas possible d'ajouter des tags réservés
de validation à certains organisme? Il me semble que c'est possible et que
cela avait été fait par la ville d'Orange pour ses besoins de gestion.

Si on veut que les organismes puissent agir correctement il faudra bien des
clés réservées.
Pour les adresses c'est comme pour les voies ferrées ou routières. On a un
aspect historique à gérer car on a un aspect de projet ou de prévision
(fictif ou réel)

Il y a tous un lot de tags faits pour la gestion temporelle d'un élément.
On a des éléments pour gérer les propositions de tags sur le Wiki. Pourquoi
ne pas mettre en place un système de tag qui pourrait permettre le suivi
des adresses temporaires, des noms de routes temporaires (Exemple: le SIG
de Quimper utilise pour ces adresses un champs F ou R pour fictif ou réel).

Christian, pour répondre au problème de correspondance des adresses :

Dans mon village il y a encore 5ans, on n'avait pas de numéro dans toutes
les rues. Maintenant toutes les rues ont un numéro sur un système
d'adressage métrique. Mais il reste dans la base du cadastre des adresses
qui n'ont pas été converties ou des noms de rue qui n'ont pas suivi ce
changement. La mise en correspondance ne se fait donc pas (il me semble que
BANO, suite à une autre discussion, n'exploite que le tag name pour les
correspondances)

J'ai aussi une adresse localisée au même endroit géographiquement dans BANO
dont les rues sont différentes car il y a l'ancien nom et le nouveau nom de
rue stockées 1 rue X et 1 rue Y. Je pense que la gestion des autres balises
complémentaires du tag name devrait être prise en compte afin de dégager ce
problème et mettre une alerte pour dire que ça se base sur un ancien nom de
rue. Cela permettra aussi une bonne part de mise en correspondance des
adresses contenues dans BANO

Suite à des changements de système de numérotation sur une rue dans une
autre commune, j'ai déjà vu sur le terrain deux numéros pour la même entrée
2 et l'autre 57...
Dans le cadastre c'est le 2 qui est stocké et pour avoir discuté avec
l'habitant son courrier est bien au 57. Il y a donc une temporalité à
prendre en compte si le système de numérotation si celui-ci évolue sur la
commune (rue, quartier, commune) au risque de ne pas avoir de
correspondance le temps de mettre à jour le système.

Temporairement quand il n'y a pas de nom de rue, les adresses sont au
lieu-dit, et dans mon cas, j'ai pour une rue, des adresses sur un lieudit
et celle d'à coté sur le vrai nom de la rue...
Là aussi pour avoir une correspondance le lieu-dit n'est pas à prendre en
compte sauf si l'on considère ça comme une ancienne correspondance
(histoire de 2 à 3 ans dans mon cas pour que la zone se développe et que la
collectivité décide de l’attribution d'un nom de voirie).

Jérôme


Le 6 octobre 2014 15:04, Christian Quest  a écrit :

> C'est pour ça que BANO existe (et surtout BANO^2), pour se décorreler
> d'OSM et apporter la surcouche nécessaire de fiabilisation, d'historisation
> et avoir des terme de contribution différents permettant une double licence
> sur les contributions faites sur la plateforme BANO^2.
>
> Pour la qualité, il faut avoir un peu regardé la BD Adresse les yeux dans
> les yeux pour ne pas avoir à rougir inutilement avec les données actuelles
> de BANO.
>
>
> Le 6 octobre 2014 14:22, Pieren  a écrit :
>
> Et ben, au risque de faire tâche, je pense qu'OSM n'est pas capable de
>> devenir un référentiel adresse. On le sait tous, l'immense majorité
>> des adresses dans OSM vient du cadastre. Et celles-ci sont bourrées
>> d'erreur ou sont des prévisions. Alors, ensuite, on peut dire qu'avec
>> OSM, chacun peut corriger (d'ailleurs OSM ne serait finalement sensé
>> servir qu'à ça). Et s'il y a vandalisme, quelqu'un d'autre s'en
>> apercevra tôt ou tard, corriger, etc. Mais un référentiel ne peut pas
>> se satisfaire d'un "tôt ou tard". Il est évident que pour avoir un
>> niveau de confiance absolu et constant, cette base adresse ne doit
>> être modifiable que par un public restrein

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Pieren]

2014-10-06 15:04 GMT+02:00 Christian Quest :
> C'est pour ça que BANO existe (et surtout BANO^2), pour se décorreler d'OSM
> et apporter la surcouche nécessaire de fiabilisation, d'historisation et
> avoir des terme de contribution différents permettant une double licence sur
> les contributions faites sur la plateforme BANO^2.

Double licence ? J'ai dû raté des épisodes alors ;-) Comme dit
Frédéric, les lecteurs de cette liste ne savent pas ce que représente
ce futur BANO2.

> Pour la qualité, il faut avoir un peu regardé la BD Adresse les yeux dans
> les yeux pour ne pas avoir à rougir inutilement avec les données actuelles
> de BANO.

Oui, je sais. Aucune source n'est parfaite. Même la poste doit avoir
ses problèmes pour palier les défaillances de certaines mairies. Mais
ça ne change rien à la solution proposée : soit une BAN controllé par
une autorité et des contributeurs assermentés, soit un BANO qui ferait
un peu le mélange de plusieurs sources et dont OSM qui serait senser
représenter la version la plus fiable car forçément issue du terrain
(hum). Moi, je préfère la première solution, à condition que ça soit
gratuit et réutilisable pour tout le monde et que le financement soit
pérenne. Les contributeurs/correcteurs devraient être naturellement
les agents des mairies, ceux-là même qui ont déjà la compétence pour
créer ou modififier les adresses.

Pieren,
qui ne travaille pas pour l'IGN ni ne fait partie d'aucun syndicat ;-)

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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Pieren]

2014-10-06 15:31 GMT+02:00 Jérôme Seigneuret :

> Suite à des changements de système de numérotation sur une rue dans une
> autre commune, j'ai déjà vu sur le terrain deux numéros pour la même entrée
> 2 et l'autre 57...
> Dans le cadastre c'est le 2 qui est stocké et pour avoir discuté avec
> l'habitant son courrier est bien au 57. Il y a donc une temporalité à
> prendre en compte si le système de numérotation si celui-ci évolue sur la
> commune (rue, quartier, commune) au risque de ne pas avoir de correspondance
> le temps de mettre à jour le système.

C'est vrai que c'est un problème qu'OSM a du mal à appréhender. On a
bien des tags comme "old_*" mais on ne connait pas leur période de
validité. Et si une rue change de nom par exemple, rien n'oblige le
contributeur a réutiliser l'ancien way ou relation associatedStreet.
Il peut très bien recommencer de zéro. Et même si  avec un peu de
chance, il remet un code fantoir, tout l'historique sera perdu (ou
alors, très, très difficile à reconstituer).
Et certains utilisateurs (comme la poste) voudraient certainement
pouvoir exploiter ces anciennes adresses (dans un ordre chronologique
inversé) en cas d'insuccès sur une recherche simple.

Pieren

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

Re: [OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Stéphane Péneau]

Le lundi 6 octobre 2014 15:18:14, Pieren a écrit :

Vu sur la liste dev, une info qui va sans doute intéresser tous les
utilisateurs de nominatim. Deux changements majeurs:
- la prise en compte de la relation waterway pour la recherche de rivières
- les POI comme les magasins et les restaurants peuvent hériter de
l'adresse du bâtiment dans lequel ils se trouvent (ça évitera une
grande partie des doublons)


Mais ne remonte toujours pas le nom de la commune lorsqu'on recherche 
un hamlet ou autre.
Ça passe encore parce qu'il en manque beaucoup dans Osm, mais d'ici 
quelque temps, le résultat d'une requête sur des toponymes très 
répandus tels que Beaulieu, Bellevue, Bel-Air, etc... deviendra 
illisible.


Pour ceux qui ne comprennent pas, si je cherche le hameau "beaulieu", 
nominatim donne les réponses sous la forme
Nom du hameau - Nom de la (sous) prefecture - département - région, 
etc...

Au lieu de
Nom du hameau - Nom de la Commune -  etc..

Stf


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

Re: [OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Francescu GAROBY]

Le deuxième changement que tu évoques signifie que, si aucun tag
'addr:housenumber' n'a été placé sur le magasin/restaurant/... mais qu'il y
en a un sur le bâti englobant, alors la recherche du magasin/restaurant
indiquera l'adresse dudit bâti ? Quid des relations associatedAddress

(qui
ne sont encore qu'à l'état de "proposed features") ? Sont-elles prises en
compte ?

Francescu

2014-10-06 15:18 GMT+02:00 Pieren :

> Vu sur la liste dev, une info qui va sans doute intéresser tous les
> utilisateurs de nominatim. Deux changements majeurs:
> - la prise en compte de la relation waterway pour la recherche de rivières
> - les POI comme les magasins et les restaurants peuvent hériter de
> l'adresse du bâtiment dans lequel ils se trouvent (ça évitera une
> grande partie des doublons)
> Le service sur osm.org est déjà mis à jour mais comme il n'y a pas eu
> de ré-import il est possible que ça ne fonctionne pas toujours (en
> particulier si les nouvelles fonctions exigent des données nouvelles
> dans la base nominatim et que celles-ci n'ont pas été modifiées dans
> OSM depuis - donc pas de synchronisation rétroactive)
>
> Pieren
>
>
> -- Forwarded message --
> From: Sarah Hoffmann 
> Date: Sun, Oct 5, 2014 at 9:48 AM
> Subject: [OSM-dev] Nominatim 2.3 release announcement
> To: d...@openstreetmap.org
>
>
> Hi,
>
> we are happy to announce the release of a new stable version 2.3 of
> Nominatim, the OSM search engine.
>
> There are two new features that are most notable for users of the
> search engine: there is now support for waterway relations, which improves
> searching for rivers, and POIs like shops and restaurants now
> can inherit their address from the building they are in.
>
> Next to that a lot of smaller bugs have been fixed and further tweaks
> to the search algorithm allow for improved ordering of results. This
> release also marks the arrival of a functional test suite for
> Nominatim.
>
> The new release is available at
>
> http://www.nominatim.org/release/Nominatim-2.3.0.tar.bz2
>
> Installation instructions are at the usual place at
>
> http://wiki.openstreetmap.org/wiki/Nominatim/Installation
>
> You can always try the latest version of Nominatim on
>
> http://nominatim.openstreetmap.org
>
> Regards
>
> Sarah
>
> ___
> dev mailing list
> d...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Stéphane Péneau]

Le lundi 6 octobre 2014 15:56:25, Pieren a écrit :

Et certains utilisateurs (comme la poste) voudraient certainement
pouvoir exploiter ces anciennes adresses (dans un ordre chronologique
inversé) en cas d'insuccès sur une recherche simple.


Est-ce que ce ça reste aussi compliqué si ces organismes conservent des 
fichiers "france" à intervalles réguliers, par exemple 1 tous les 6 
mois ?


Stf

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

Re: [OSM-talk-fr] amenity=place_of_worship sur église en ruine

[Jérôme Seigneuret]

Le 6 octobre 2014 15:01, sylvain letuffe  a écrit :

> On lundi 6 octobre 2014, you wrote:
> > Grave question : à partir de quand un bâtiment en ruine perd son
> > qualificatif de "building" ? lorsqu'il perd son toit ? un pan de mur ?
> > vitres cassées ? plus de porte ?
> >
> > Pieren
>
> Question intéressante et récurrente sur le cycle de vie des objets :
> Quand passe-t-on à "disused" (inutilisé) puis à "abondonned" puis à
> "ruined"
> et en effet, ça risque d'être assez flou la limite !
>

Sachant qu'en plus une ruine peu être occupé pour le culte ou squatter ...
et donc l'ensemble des termes cité peuvent être combiné dans la vrai vie


>
> Pour ta question, quand doit on retirer le tag building=x pour devenir
> autre
> chose je pense que le choix tient dans la définition de "building". Le wiki
> d'osm n'en définit pas le sens pour osm, il nous reste la ou les
> définitions
> du mot building en anglais. J'en ai trouvé plusieurs sur le net :
> la plus courante :
>  "A closed structure with walls and a roof."
> ( structure = A cohesive whole built up of distinct part)
> "A building is a man-made structure with a roof and walls standing more or
> less permanently in one place" (wikipedia)
> ou parfois :
> "a man-made structure intended for human use or occupation"
>
> Dans le sens des deux premiers, c'est exactement tes deux premières
> propositions, un bâtiment (dans osm) perd sont qualificatif de building
> s'il
> perd son toit ou un mur.
> (branlette de cerveau : et s'il n'a perdu qu'une partie du toit ? a-t-il
> toujours sont toit ?)
>

L'état de la construction n'est jamais cité. Pour moi une construction est
toujours une construction avec un type architectural. Une ruine n'est que
sont état de dégradation. Et c'est là que l'on voit les limites des
composantes métier sur l'utilisabilités d'une base de données et la
structuration des données qu'elle contient et le détail que l'on veut bien
y mettre.

>
> Dans la 3ème, s'il n'est plus prévu pour être utilisé par des humains.
>
> ps: on notera au passage que rapport à la première définition
> building=yes + wall=no
> est un usage incohérent que nous avons dans osm
>

Ben non car en Espagne pour éviter de payer la taxe il y a souvent des
habitation avec des pièces non terminé (sans toit) et pourtant c'est bien
une maison habité. Dans ce cas il faut surement dissocié l'habitation. Mais
dans ce cas on ne peut pas considéré une construction sans toit comme une
ruine... building=yes + wall=no à un sens dans ce cas
Ou alors il faut un tag building=under_construction

Tu as aussi des lieux de culte
http://fr.wikipedia.org/wiki/Abbaye_Saint-Mathieu_de_Fine-Terre ou le
culture se fait aussi dans la ruine (pas de toit)

Bref j'ai pas de solution toute faite. Si l'on prends les clé
indépendamment, on a toujours des incohérences...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Pieren]

2014-10-06 16:04 GMT+02:00 Francescu GAROBY :
> Le deuxième changement que tu évoques signifie que, si aucun tag
> 'addr:housenumber' n'a été placé sur le magasin/restaurant/... mais qu'il y
> en a un sur le bâti englobant, alors la recherche du magasin/restaurant
> indiquera l'adresse dudit bâti ? Quid des relations associatedAddress (qui
> ne sont encore qu'à l'état de "proposed features") ? Sont-elles prises en
> compte ?

Je pense avoir lu que nominatim prenait en compte la relation
associatedStreet. A voir si il le fait dans ce contexte. A tester.

2014-10-06 15:59 GMT+02:00 Stéphane Péneau :
> Mais ne remonte toujours pas le nom de la commune lorsqu'on recherche un
> hamlet ou autre.

Tu devrais soumettre ton problème aux auteurs. C'est ici:
https://github.com/twain47/Nominatim/issues/

Pieren

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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Christian Quest]

C'est quasi ingérable de cette façon. Il faut vraiment conserver une
historisation accessible sans faire des acrobaties.

Le 6 octobre 2014 16:06, Stéphane Péneau  a
écrit :

> Le lundi 6 octobre 2014 15:56:25, Pieren a écrit :
>
>> Et certains utilisateurs (comme la poste) voudraient certainement
>> pouvoir exploiter ces anciennes adresses (dans un ordre chronologique
>> inversé) en cas d'insuccès sur une recherche simple.
>>
>
> Est-ce que ce ça reste aussi compliqué si ces organismes conservent des
> fichiers "france" à intervalles réguliers, par exemple 1 tous les 6 mois ?
>
> Stf
>
>
> ___
> 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] Liste des voies OSM et codes FANTOIR par commune

[Philippe Verdy]

Peut-être aussi une icone rotative pendant le chargement (ou un message
"chargement en cours") avec effacement préalable de la liste affichée avant
d'exécuter la requête (on a l'impression de ne pas avoir cliqué ou qu'il ne
se passe ien pendant plusieurs seconds, et l'URL en haut n'est mise à jour
qu'à la fin).
Sinon c'est bien dommage que le formulaire en haut n'ait pas la recherche
d'une commune: on tape quelques lettres, ça affiche la liste des communes
(au lieu des codes FANTOIR) avec leur code INSEE, il n'y a plus qu'à
cliquer sur une d'elles pour renseigner le code INSEE à charger.

Autre idée: afficher aussi les communes limitrophes, même dans d'autres
départements, (et même si ce ne sont pas des mêmes codes FANTOIR, il y a
souvent des rues communes avec une numérotation partagée, soit par côté
pair/impair, soit par tranche voire parfois les deux quant a rue longe
partiellement les deux communes puis se poursuit des deux côté dans une
seule commune ou séparément dans les deux).

Cela permet aussi de faciliter la recherche du nom de commune pour peu
qu'on n'ait pas tapé les bons accents ou traits d'union ou que la recherche
de commune par nom cherche une égalité trop stricte (penser alors à
recherhcer en ignorant la casse, aux abréviations communes ST et STE ou
l'absence d'article initial toutes les communes contenant chaque mot tapé
en ignorant les minuscules-majuscules; peut-être aussi avec simplification
phonétique en ignorant certaines lettres comme les doubles consonnes, ou un
S ou X final).

Penser aussi aux anciennes communes ou communes associées et déléguées
(elles ont des codes INSEE historiques conservés car encore utilisés pour
l'état-civil et les SIREN, même après la fusion complète sans
association/délégation, même si les codes FANTOIR ne correspondent plus au
code INSEE de la nouvelle commune). Ce sera utile avec les toutes petites
communes rurales qui fusionnent de plus en plus et sont fortement incitées
à le faire, même si elles en intégrant des EPCI à FP (hors dérogations pour
les îles et communes de montagne et pour Mayotte) les communes associées et
déléguées reprennent parfois leur statut de commune pleine (pour les
compétences non transférées à l'EPCI et quand elles ont une population
suffisante dépassant les 500 âmes environ).


Le 6 octobre 2014 14:01, Yves Pratter  a écrit :

>
> Le 6 oct. 2014 à 08:13, Francescu GAROBY  a écrit :
>
> À première vue, c'est pas mal du tout, cet outil !
>
> +1
>
> Juste une suggestion : mettre de la complétion sur le champs "code INSEE".
> Voire, de la complétion à partir du nom de commune et proposer le code
> INSEE correspondant.
>
> +1
>
> Petit détail : Peux-tu aussi afficher le nom de la commune en titre dans
> la page web ?
> (balise TITLE et balise H1 par exemple).
>
> Éternoz — Correspondance entre FANTOIR et voies OSM
> 
>
> Merci,
>
> —
> Yves
>
> ___
> 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] Liste des voies OSM et codes FANTOIR par commune

[Ab_fab]

C'est peut être à cause de tout ça que l'on peut garder une solution simple
côté dev : le code insee.
ça prend 20 secondes à récupérer sur Wikipedia, et c'est garanti sans
accents et sans traits d'union.

Le 6 octobre 2014 16:26, Philippe Verdy  a écrit :

> Peut-être aussi une icone rotative pendant le chargement (ou un message
> "chargement en cours") avec effacement préalable de la liste affichée avant
> d'exécuter la requête (on a l'impression de ne pas avoir cliqué ou qu'il ne
> se passe ien pendant plusieurs seconds, et l'URL en haut n'est mise à jour
> qu'à la fin).
> Sinon c'est bien dommage que le formulaire en haut n'ait pas la recherche
> d'une commune: on tape quelques lettres, ça affiche la liste des communes
> (au lieu des codes FANTOIR) avec leur code INSEE, il n'y a plus qu'à
> cliquer sur une d'elles pour renseigner le code INSEE à charger.
>
> Autre idée: afficher aussi les communes limitrophes, même dans d'autres
> départements, (et même si ce ne sont pas des mêmes codes FANTOIR, il y a
> souvent des rues communes avec une numérotation partagée, soit par côté
> pair/impair, soit par tranche voire parfois les deux quant a rue longe
> partiellement les deux communes puis se poursuit des deux côté dans une
> seule commune ou séparément dans les deux).
>
> Cela permet aussi de faciliter la recherche du nom de commune pour peu
> qu'on n'ait pas tapé les bons accents ou traits d'union ou que la recherche
> de commune par nom cherche une égalité trop stricte (penser alors à
> recherhcer en ignorant la casse, aux abréviations communes ST et STE ou
> l'absence d'article initial toutes les communes contenant chaque mot tapé
> en ignorant les minuscules-majuscules; peut-être aussi avec simplification
> phonétique en ignorant certaines lettres comme les doubles consonnes, ou un
> S ou X final).
>
> Penser aussi aux anciennes communes ou communes associées et déléguées
> (elles ont des codes INSEE historiques conservés car encore utilisés pour
> l'état-civil et les SIREN, même après la fusion complète sans
> association/délégation, même si les codes FANTOIR ne correspondent plus au
> code INSEE de la nouvelle commune). Ce sera utile avec les toutes petites
> communes rurales qui fusionnent de plus en plus et sont fortement incitées
> à le faire, même si elles en intégrant des EPCI à FP (hors dérogations pour
> les îles et communes de montagne et pour Mayotte) les communes associées et
> déléguées reprennent parfois leur statut de commune pleine (pour les
> compétences non transférées à l'EPCI et quand elles ont une population
> suffisante dépassant les 500 âmes environ).
>
>
> Le 6 octobre 2014 14:01, Yves Pratter  a écrit :
>
>>
>> Le 6 oct. 2014 à 08:13, Francescu GAROBY  a écrit :
>>
>> À première vue, c'est pas mal du tout, cet outil !
>>
>> +1
>>
>> Juste une suggestion : mettre de la complétion sur le champs "code
>> INSEE". Voire, de la complétion à partir du nom de commune et proposer le
>> code INSEE correspondant.
>>
>> +1
>>
>> Petit détail : Peux-tu aussi afficher le nom de la commune en titre dans
>> la page web ?
>> (balise TITLE et balise H1 par exemple).
>>
>> Éternoz — Correspondance entre FANTOIR et voies OSM
>> 
>>
>> Merci,
>>
>> —
>> Yves
>>
>> ___
>> 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
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Liste des voies OSM et codes FANTOIR par commune

[Jérôme Seigneuret]

Merci pour la correction. Reste à voir le même fonctionnement avec les
lieudit habités (dont certains ne sont pas de type hamlet mais suburb
ou neighbourhood

C'est vrai que ça serait une bonne idée l'autocompétion (nom de commune et
code INSEE) D'ailleurs es-ce que l'on a un script aussi pour comparer si un
code INSEE est toujours valable pour une commune? Ou si une commune est
toujours actuelle (non fusionné avec une autre)

J'ai testé ça pour le boulot avec Navteq pour avoir les EPCI en 2014 et
j'avais un petit différentielle (5 codes INSEE différents + 2 communes
fusionnés.)




Le 6 octobre 2014 14:01, Yves Pratter  a écrit :

>
> Le 6 oct. 2014 à 08:13, Francescu GAROBY  a écrit :
>
> À première vue, c'est pas mal du tout, cet outil !
>
> +1
>
> Juste une suggestion : mettre de la complétion sur le champs "code INSEE".
> Voire, de la complétion à partir du nom de commune et proposer le code
> INSEE correspondant.
>
> +1
>
> Petit détail : Peux-tu aussi afficher le nom de la commune en titre dans
> la page web ?
> (balise TITLE et balise H1 par exemple).
>
> Éternoz — Correspondance entre FANTOIR et voies OSM
> 
>
> Merci,
>
> —
> Yves
>
> ___
> 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] Le nouveau Nominatim 2.3 est arrivé

[Stéphane Péneau]

Le lundi 6 octobre 2014 16:11:05, Pieren a écrit :


Tu devrais soumettre ton problème aux auteurs. C'est ici:
https://github.com/twain47/Nominatim/issues/


Il y avait déjà un ticket à ce sujet (je ne le retrouve plus) et la 
réponse était que Nominatim ne fait pas de distinction hiérarchique 
entre hamlet/village/city. En revanche ça fonctionne correctement pour 
les locality et isolated_dwelling.


Je n'ai pas insisté

Stf



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

Re: [OSM-talk-fr] Liste des voies OSM et codes FANTOIR par commune

[Ab_fab]

J'aime beaucoup cette présentation par liste.
Cela pourrait faire une bonne base de départ pour consigner les
incohérences repérées.
Avec un champ permettant de catégoriser le problème dans une liste.
Et un champ libre permettant de décrire précisément ce qui ne va pas.

Un peu l'équivalent de l'outil que BrunoC
 avait mis en place pour les
adresses de la communauté urbaine de Nantes ... mais en liste.

Le 4 octobre 2014 15:42, Vincent de Château-Thierry  a
écrit :

> Bonjour,
>
> Comme évoqué hier avec Yves, voici une page qui permet un inventaire, par
> commune, des voies proposées par FANTOIR et, parmi elles, de celles
> retrouvées dans OSM.
> L'outil a comme point d'entrée le code INSEE de la commune.
>
> C'est volontairement simple (vous pouvez dire rustique :) ), ça n'évoluera
> qu'en fonction des suggestions. Mon idée première était de proposer en
> complément du rendu carto, une manière simple de connaître et copier/coller
> les codes FANTOIR sans avoir à les ré-écrire : moins pénible et plus sûr.
>
> http://cadastre.openstreetmap.fr/fantoir/
>
> Vos retours bienvenus,
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Liste des voies OSM et codes FANTOIR par commune

[Jérôme Seigneuret]

@Ab_fab comme le fait remarqué Philippe le code Fantoir prends le code
insee comme référence et en cas de modification de la commune (fusion et
autre changement le code insee change) de l'ordre de 10 par ans.

C'est pour ça qu'il faut utiliser la base de l'INSEE et pas seulement le
Wiki

Le 6 octobre 2014 16:31, Ab_fab  a écrit :

> C'est peut être à cause de tout ça que l'on peut garder une solution
> simple côté dev : le code insee.
> ça prend 20 secondes à récupérer sur Wikipedia, et c'est garanti sans
> accents et sans traits d'union.
>
> Le 6 octobre 2014 16:26, Philippe Verdy  a écrit :
>
> Peut-être aussi une icone rotative pendant le chargement (ou un message
>> "chargement en cours") avec effacement préalable de la liste affichée avant
>> d'exécuter la requête (on a l'impression de ne pas avoir cliqué ou qu'il ne
>> se passe ien pendant plusieurs seconds, et l'URL en haut n'est mise à jour
>> qu'à la fin).
>> Sinon c'est bien dommage que le formulaire en haut n'ait pas la recherche
>> d'une commune: on tape quelques lettres, ça affiche la liste des communes
>> (au lieu des codes FANTOIR) avec leur code INSEE, il n'y a plus qu'à
>> cliquer sur une d'elles pour renseigner le code INSEE à charger.
>>
>> Autre idée: afficher aussi les communes limitrophes, même dans d'autres
>> départements, (et même si ce ne sont pas des mêmes codes FANTOIR, il y a
>> souvent des rues communes avec une numérotation partagée, soit par côté
>> pair/impair, soit par tranche voire parfois les deux quant a rue longe
>> partiellement les deux communes puis se poursuit des deux côté dans une
>> seule commune ou séparément dans les deux).
>>
>> Cela permet aussi de faciliter la recherche du nom de commune pour peu
>> qu'on n'ait pas tapé les bons accents ou traits d'union ou que la recherche
>> de commune par nom cherche une égalité trop stricte (penser alors à
>> recherhcer en ignorant la casse, aux abréviations communes ST et STE ou
>> l'absence d'article initial toutes les communes contenant chaque mot tapé
>> en ignorant les minuscules-majuscules; peut-être aussi avec simplification
>> phonétique en ignorant certaines lettres comme les doubles consonnes, ou un
>> S ou X final).
>>
>> Penser aussi aux anciennes communes ou communes associées et déléguées
>> (elles ont des codes INSEE historiques conservés car encore utilisés pour
>> l'état-civil et les SIREN, même après la fusion complète sans
>> association/délégation, même si les codes FANTOIR ne correspondent plus au
>> code INSEE de la nouvelle commune). Ce sera utile avec les toutes petites
>> communes rurales qui fusionnent de plus en plus et sont fortement incitées
>> à le faire, même si elles en intégrant des EPCI à FP (hors dérogations pour
>> les îles et communes de montagne et pour Mayotte) les communes associées et
>> déléguées reprennent parfois leur statut de commune pleine (pour les
>> compétences non transférées à l'EPCI et quand elles ont une population
>> suffisante dépassant les 500 âmes environ).
>>
>>
>> Le 6 octobre 2014 14:01, Yves Pratter  a écrit :
>>
>>>
>>> Le 6 oct. 2014 à 08:13, Francescu GAROBY  a écrit :
>>>
>>> À première vue, c'est pas mal du tout, cet outil !
>>>
>>> +1
>>>
>>> Juste une suggestion : mettre de la complétion sur le champs "code
>>> INSEE". Voire, de la complétion à partir du nom de commune et proposer le
>>> code INSEE correspondant.
>>>
>>> +1
>>>
>>> Petit détail : Peux-tu aussi afficher le nom de la commune en titre dans
>>> la page web ?
>>> (balise TITLE et balise H1 par exemple).
>>>
>>> Éternoz — Correspondance entre FANTOIR et voies OSM
>>> 
>>>
>>> Merci,
>>>
>>> —
>>> Yves
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
> ___
> 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] Prix des carburants ?

[Jérôme Seigneuret]

Ca ressemble à du géocodage adresse et non à de la géolocalisation...
J'ai regardé dans mon coin et j'ai pas mal de points localisés en début de
rue d'où les décalage et le fait que ce soit pas super. En même temps j'ai
regarder les popositons d'ajout pour les écoles et les éléments sportifs et
c'est pas beaucoup mieux en terme de précisions. J'ai des décalages de 200
à 300m.

Je pense que la reprojection peu merder un peu aussi (dixit grille de
transformation comme sous ArcGIS) Si c'est du Lambert 2 c'est encore
pire... car il y a des variantes

Le 6 octobre 2014 15:21, Francescu GAROBY  a écrit :

> Et puis, les stations sur autoroute, il y a moyen de les repérer avec les
> photos aériennes. Du coup, ça nécessite clairement de faire le travail
> manuellement, mais ça pourrait être utile, non ?
>
> Francescu
>
> Le 6 octobre 2014 15:14, Jérôme Amagat  a écrit :
>
> Bonjour,
>>
>> C'est si mauvais que ça? j'ai regarder pour quelques points, il sont pas
>> idéalement placé mais pas non plus très loin : une 50ene de mètre souvent
>> sur la route à coté de la station à part les station sur autoroute qui là
>> je suis d'accord sont souvent mal placé).
>> Il y a bien d'autres chose proposé a l’intégration qui sont pas toujours
>> bien placé.
>>
>> Et ajouté les carburants sur les amenity=fuel sans fuel:*=* qui sont
>> proche (100 metres ?)
>>
>> Le 4 octobre 2014 19:01, Frédéric Rodrigo  a
>> écrit :
>>
>> Bon finalement après mise en place de l'intégration des stations à Osmose
>>> on a choisi de ne pas activer l'analyse. Le géolocalisation des stations
>>> étant de mauvaise qualité pour avoir un intérêt.
>>> Probablement le résultat d'un géocodage de piètre qualité.
>>>
>>> Frédéric.
>>>
>>>
>>> Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :
>>>
 Oui, enfin ça reste un raffinement

 Le 26 sept. 2014 18:06, "David Crochet" >>> > a écrit :

 Bonjour

 Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :

 Mais bizarrement il nb'y a pas de simple payment:cards=yes


 Non, car il y a des points de vente qui refusent certaines cartes

 Cordialement

 --
 David Crochet

 _
 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


>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
> ___
> 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] amenity=place_of_worship sur église en ruine

[Philippe Verdy]

Des tas de ruines sont accessibles au public et se visitent quand il ne
reste qu'un bout de mur ou une porte, ou certaines travées ou les premiers
piliers d'un ancien pont, ou d'anciennes habitations troglodytes (allez
voir en Dordogne la vallée de la Vézère; plus de toit car il n'y en a
jamais eu, mais ce sont les murs qui sont en partiellement ruine...).

Ces ruines historiques (de l'époque romaine, au Moyen-Âge ou plus tard),
bien protégées et conservées ne présentent plus de danger particulier ou
ont seulement certaines zones inaccessibles protégées par clôtures.

Peut-on parler alors de ruines ? Parfois oui pour d'anciennes églises et
chateaux partiellement démolis et conservés en l'état. Parfois il n'y a
plus de risque, car les pierres sont déjà tombées au sol; ou il reste juste
le dallage, un ancien puits correctement fermé; avec des inscriptions et
des panneaux d'information et pas toujours un batiment en état pour une
expo locale...

Dans nos compagnes on trouve plein d'anciennes fermes qui sont débout mais
privées (inaccessibles au "public") mais qui sont de véritable "buildings"
alors qu'une partie n'a plus de toit et état (le toit n'est dangereux que
s'il risque de s'effondrer mais s'il n'y a déjà plus de toit, les murs
eux peuvent rester dans danger particulier, surtout avec un renforcement de
soutien contre le vent s'il n'y a plus de charpente et plus d'huisseries
aux fenêtes).


Le 6 octobre 2014 13:38, Francescu GAROBY  a écrit :

> Quand on le déclare inaccessible au public, pour des raisons de sécurité ?
>
> Le 6 octobre 2014 13:31, Pieren  a écrit :
>
> 2014-10-03 21:31 GMT+02:00 DH :
>>
>> > La tentation, c'est un des dangers qu'OSM se doit d'éviter et la notion
>> de
>> > beau reste, finalement, assez subjective.
>>
>> Grave question : à partir de quand un bâtiment en ruine perd son
>> qualificatif de "building" ? lorsqu'il perd son toit ? un pan de mur ?
>> vitres cassées ? plus de porte ?
>>
>> Pieren
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
> ___
> 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

[OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Yves Pratter]

Bonjour,

Osmose remonte un Gîte d’étape et propose les attributs suivants :
amenity=shelter
source=data.gouv.fr:Le ministère des droits des femmes, de la ville, de la 
jeunesse et des sports - 2014
tourism=alpine_hut

Mais ce n’est pas un vrai refuge alpin (pas au sommet d’une montagne).

Quelqu’un a utilisé tourism=chalet alors que ce n’est pas un bungalow.
Je pense que le bon attribut est tourism=hostel malgré que la page française 
décrit uniquement une auberge de jeuneusse.

Est-ce qu’Osmose pourrait proposer plusieurs tags ou en choisir un plus adapté 
en fonction du nom ?

Je remarque aussi qu’il ne propose pas l’attribut name alors que la donnée est 
bien fournie par le ministère (« Refuge de montagne, Gîte d'étape Lison acceuil 
»)
name=Gîte d'étape Lison accueil


—
Yves 

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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[JB]

Bof, tu mets en avant le « positioned in the mountains », je préfère la 
partie « accommodation for mountaineers, climbers and hikers », 
c'est-à-dire logement pour les montagnards, grimpeurs et randonneurs. 
Pour moi, le gite d'étape, logiquement le long d'un itinéraire de 
randonnée, correspond pas trop mal… À couper les cheveux en quatre, on 
perd en simplicité, à mon sens.

Aller, je complète la traduction sur la page française.
JB.


Le 06/10/2014 17:04, Yves Pratter a écrit :

Bonjour,

Osmose remonte un Gîte d’étape 
 et 
propose les attributs suivants :


  * *amenity=shelter*
  * source=data.gouv.fr:Le ministère des droits des femmes, de la
ville, de la jeunesse et des sports - 2014
  * *tourism=alpine_hut*


Mais ce n’est pas un vrai refuge alpin (pas au sommet d’une montagne).

Quelqu’un a utilisé *tourism=chalet *alors que ce n’est pas un bungalow.
Je pense que le bon attribut est *tourism=hostel *malgré que la page 
française décrit uniquement une auberge de jeuneusse.


Est-ce qu’Osmose pourrait proposer plusieurs tags ou en choisir un 
plus adapté en fonction du nom ?


Je remarque aussi qu’il ne propose pas l’attribut *name* alors que la 
donnée est bien fournie par le ministère (« Refuge de montagne, Gîte 
d'étape Lison acceuil »)

*name=Gîte d'étape Lison accueil*


—
Yves



___
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 : Terrains de sports non intégrés Refuge de montagne

[JB]

'taing, deux fois cette semaine… Comment qu'on édite ces lignes de 
tableau d'un template ? Les liens en bas de page guident de

https://wiki.openstreetmap.org/wiki/FR:Key:tourism
à
https://wiki.openstreetmap.org/wiki/Template:FR:Map_Features:tourism
en nous promettant qu'on pourra modifier la traduction, puis un petit 
lien en bas, qui dit qu'on peut modifier la traduction… ha non, en fait, 
il est pas cliquable, ce passage…

JB.

Le 06/10/2014 17:16, JB a écrit :
Bof, tu mets en avant le « positioned in the mountains », je préfère 
la partie « accommodation for mountaineers, climbers and hikers », 
c'est-à-dire logement pour les montagnards, grimpeurs et randonneurs. 
Pour moi, le gite d'étape, logiquement le long d'un itinéraire de 
randonnée, correspond pas trop mal… À couper les cheveux en quatre, on 
perd en simplicité, à mon sens.

Aller, je complète la traduction sur la page française.
JB.


Le 06/10/2014 17:04, Yves Pratter a écrit :

Bonjour,

Osmose remonte un Gîte d’étape 
 et 
propose les attributs suivants :


  * *amenity=shelter*
  * source=data.gouv.fr:Le ministère des droits des femmes, de la
ville, de la jeunesse et des sports - 2014
  * *tourism=alpine_hut*


Mais ce n’est pas un vrai refuge alpin (pas au sommet d’une montagne).

Quelqu’un a utilisé *tourism=chalet *alors que ce n’est pas un bungalow.
Je pense que le bon attribut est *tourism=hostel *malgré que la page 
française décrit uniquement une auberge de jeuneusse.


Est-ce qu’Osmose pourrait proposer plusieurs tags ou en choisir un 
plus adapté en fonction du nom ?


Je remarque aussi qu’il ne propose pas l’attribut *name* alors que la 
donnée est bien fournie par le ministère (« Refuge de montagne, Gîte 
d'étape Lison acceuil »)

*name=Gîte d'étape Lison accueil*


—
Yves



___
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


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

Re: [OSM-talk-fr] Prix des carburants ?

[Jérôme Amagat]

j'ai regardé ça http://osmose.openstreetmap.fr/fr/map/#item=8200&;
useDevItem=true.
C'est vrai qu'il y en a pas mal qui sont très mal placé mais c'est pour
beaucoup possible de retrouver leur vrai place avec l'adresse indiqué.
Mais il faut dire qu'il ne reste sur osmose que les stations non présente
dans osm ou très mal geocodé.
Les stations bien geocodé (ou pas trop mal) et presente dans osm ont
disparu (osmose en a trouvé combien? c'est possible de la savoir?) on
pourrai leur ajouté les données sur les carburants et services qui sont
presentes dans les donnée libéré.Peut etre comme les integration possible
pour les amenity=fuel qui n'ont aucun fuel:*=*

Le 6 octobre 2014 16:59, Jérôme Seigneuret  a
écrit :

> Ca ressemble à du géocodage adresse et non à de la géolocalisation...
> J'ai regardé dans mon coin et j'ai pas mal de points localisés en début de
> rue d'où les décalage et le fait que ce soit pas super. En même temps j'ai
> regarder les popositons d'ajout pour les écoles et les éléments sportifs et
> c'est pas beaucoup mieux en terme de précisions. J'ai des décalages de 200
> à 300m.
>
> Je pense que la reprojection peu merder un peu aussi (dixit grille de
> transformation comme sous ArcGIS) Si c'est du Lambert 2 c'est encore
> pire... car il y a des variantes
>
> Le 6 octobre 2014 15:21, Francescu GAROBY  a écrit :
>
> Et puis, les stations sur autoroute, il y a moyen de les repérer avec les
>> photos aériennes. Du coup, ça nécessite clairement de faire le travail
>> manuellement, mais ça pourrait être utile, non ?
>>
>> Francescu
>>
>> Le 6 octobre 2014 15:14, Jérôme Amagat  a écrit
>> :
>>
>> Bonjour,
>>>
>>> C'est si mauvais que ça? j'ai regarder pour quelques points, il sont pas
>>> idéalement placé mais pas non plus très loin : une 50ene de mètre souvent
>>> sur la route à coté de la station à part les station sur autoroute qui là
>>> je suis d'accord sont souvent mal placé).
>>> Il y a bien d'autres chose proposé a l’intégration qui sont pas toujours
>>> bien placé.
>>>
>>> Et ajouté les carburants sur les amenity=fuel sans fuel:*=* qui sont
>>> proche (100 metres ?)
>>>
>>> Le 4 octobre 2014 19:01, Frédéric Rodrigo  a
>>> écrit :
>>>
>>> Bon finalement après mise en place de l'intégration des stations à
 Osmose on a choisi de ne pas activer l'analyse. Le géolocalisation des
 stations étant de mauvaise qualité pour avoir un intérêt.
 Probablement le résultat d'un géocodage de piètre qualité.

 Frédéric.


 Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :

> Oui, enfin ça reste un raffinement
>
> Le 26 sept. 2014 18:06, "David Crochet"  > a écrit :
>
> Bonjour
>
> Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :
>
> Mais bizarrement il nb'y a pas de simple payment:cards=yes
>
>
> Non, car il y a des points de vente qui refusent certaines cartes
>
> Cordialement
>
> --
> David Crochet
>
> _
> 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
>
>

 ___
 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
>>>
>>>
>>
>>
>> --
>> Cordialement,
>> Francescu GAROBY
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Stéphane Péneau]

Le 06/10/2014 17:04, Yves Pratter a écrit :


Quelqu’un a utilisé *tourism=chalet *alors que ce n’est pas un bungalow.



Heu... tourism=chalet ce n'est pas spécialement pour les bungalows. 
C'est ce même tag qui est utilisé pour les gîtes :

http://wiki.openstreetmap.org/wiki/FR:How_to_map_a#G.C3.AEte_rural

Ou alors j'ai taggé tout un tas de gites de la mauvaise manière

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

Re: [OSM-talk-fr] Zones réglementées à effacer sur carte Ile Maurice

[Pierre]

Bonjour,



Je cherche à réactualiser la carte d’Ile Maurice suite au constat suivant
:



Navigator Mapfactor m’interdit le chemin le plus court entre 2 points
(très proches pourtant et reliés par une route nationale à proximité d’un
rond-point) et m’impose un trajet de contournement très important. Indice
: Si je choisis un point (arrivée ou départ) dans la zone sensible, le
logiciel m’indique que l’un des points se situe dans une zone réglementée
alors qu’il n’y a rien qui ne le justifie à priori. Si je les écarte pour
sortir de cette zone sensible, le contournement est imposé (voir image
ci-jointe).



En souhaitant modifier la carte sur OpenStreetMap, je n’ai pas trouvé
trace d’indication de « zone réglementée » (voir image ci-jointe) ou de
marquage particulier.



Une copie d’écran est ci-jointe.



Comment modifier cette zone ou l’effacer ?



Merci pour votre aide.



Cordialement.

Pierre Buchmann

8 boulevard de Courcelles

75017 Paris

Tél +33 142276515

Cell Pierre +33 628348115





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

Re: [OSM-talk-fr] Création d'interdiction de faire demi-tour à l'entrée d'un rond-point avec iD ?

[Jérôme Seigneuret]

Bonjour,

Les restrictions sont à prendre en compte en fonction des panneaux car de
base c'est le code de la route qui fait effet. Donc on évite d'ajouter des
restrictions à tous va!
Sur un rond-point les restrictions sont implicites

j'ai fait un script Overpass pour voir les
giratoires concernés et les dégager au besoin.

Si vous souhaitez vérifier ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Yves Pratter]

Le 6 oct. 2014 à 17:39, Stéphane Péneau  a écrit :

> Le 06/10/2014 17:04, Yves Pratter a écrit :
>> 
>> Quelqu’un a utilisé tourism=chalet alors que ce n’est pas un bungalow.
>> 
> 
> Heu... tourism=chalet ce n'est pas spécialement pour les bungalows. C'est ce 
> même tag qui est utilisé pour les gîtes :
> http://wiki.openstreetmap.org/wiki/FR:How_to_map_a#G.C3.AEte_rural

Chalet, c’est spécifiquement pour un mini bâtiment distinct (Genre bungalow, « 
cabane »…) :
« Detached cottages with self-contained cooking/bathroom/toilet facilities »

Le gîte d’étape selon mon expérience :
tourism=hostel pour un bâtiment avec des dortoirs, des chambres avec plusieurs 
lits… Les sanitaires, cuisine… sont communs.
tourism=guest_house pour une chambre chez l’habitant (genre gîtes de France, 
B&B)
tourism=alpine_hut pour un refuge/gîte isolé (le plus souvent en montagne)

Le 6 oct. 2014 à 17:16, JB  a écrit :

> Bof, tu mets en avant le « positioned in the mountains », je préfère la 
> partie « accommodation for mountaineers, climbers and hikers », c'est-à-dire 
> logement pour les montagnards, grimpeurs et randonneurs. Pour moi, le gite 
> d'étape, logiquement le long d'un itinéraire de randonnée, correspond pas 
> trop mal… À couper les cheveux en quatre, on perd en simplicité, à mon sens.


Effectivement, ce n’est pas simple de s’y retrouver. Je viens de trouver 
tourism=wilderness_hut !!

Mais pour moi il est important de distinguer un refuge paumé et difficile 
d’accès où il faudrait prendre un hélicoptère en cas de secours, d’un gîte dans 
un village, un hameau… et desservit par une route et/ou des lignes de bus.


> Ou alors j'ai taggé tout un tas de gites de la mauvaise manière
Pas forcément, il faut voir au cas par cas.
Pour l’utilisateur lambda, l’icône pour le rendu est quasiment identique.

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

Re: [OSM-talk-fr] Présentation de BANO au CNIG

[Yves Pratter]

Le 6 oct. 2014 à 14:22, Pieren  a écrit :
> Il est évident que pour avoir un niveau de confiance absolu et constant, 
> cette base adresse ne doit être modifiable que par un public restreint, 
> identifié et responsable, ce qu'OSM ne peut pas fournir (sauf à modifier 
> notre modèle). 

Le 6 oct. 2014 à 16:23, Christian Quest  a écrit :
> C'est quasi ingérable de cette façon. Il faut vraiment conserver une 
> historisation accessible sans faire des acrobaties.

En gros, il faut utiliser GitHub pour ça ;-)

—
Yves



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

[OSM-talk-fr] BANO : fréquence de mise à jour, lien vers carte de Christian manquants dans le wiki

[Yves Pratter]

Bonsoir,

Je n’ai pas trouvé à quelle fréquence est mise à jour la BANO ?
Idem pour les outils suivants.

Au passage, il manque une section avec les outils qui permettent de 
visualiser/lister facilement et rapidement sont contenu :
carte : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html
liste : http://cadastre.openstreetmap.fr/fantoir/#insee=25223

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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[JB]

Le 06/10/2014 18:30, Yves Pratter a écrit :

Pour l’utilisateur lambda, l’icône pour le rendu est quasiment identique.

Rhô ! Tu crois ça ? Pas bien, tout ça…

Sinon, wilderness_hut, en France, c'est surtout les abris non gardés, 
mais plus évolués que les amenity=shelter. Et comme pas gardé, 
généralement gratuit. Il y en a pas mal dans les Vosges, quelques uns 
dans le Vercors, pour les autres régions, j'en ai moins vu.
Chalet, c'est plus évolué, soit le mobile home ou le chalet du camping 
du coin, soit le gite rural (la maison où la famille va passer ses 
vacances).


Pour le randonneur sauvage, ce qui l'intéresse, il me semble, c'est le 
amenity=shelter (ou certains d'entre-eux), le wilderness_hut, le 
alpine_hut (et apparemment hostel), et le camp_site. Pour les vacances 
plus douillettes, on passe au guest_house et chalet.


Du moins, c'est comme ça que je l'aborde.

JB.

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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Stéphane Péneau]

Le 06/10/2014 18:30, Yves Pratter a écrit :

Le gîte d’étape selon mon expérience :

  * tourism=hostel
 pour un
bâtiment avec des dortoirs, des chambres avec plusieurs lits… Les
sanitaires, cuisine… sont communs.
  * tourism=guest_house
 pour
une chambre chez l’habitant (genre gîtes de France, B&B)
  * tourism=alpine_hut
 pour
un refuge/gîte isolé (le plus souvent en montagne)




Je parlais plutôt du gite "pas d'étape" qui est loué par une famille, un 
groupe de personne. C'est équipé de chambres, cuisines, salles de bain, 
et parfois de piscine & co. Ça s'apparente plus à de la location de maison.


"hostel", si je regarde la page wikipedia, ça s'apparente aux auberges 
de jeunesse, où des personnes de provenances différentes partagent un 
lieu avec souvent des dortoirs.


"hostel" n'a pas d'équivalent sur le wikipedia français (mais auberge de 
jeunesse n'existe pas)


la page française de "Gîte" existe en anglais en parlant d'une 
spécificité française :

http://en.wikipedia.org/wiki/G%C3%AEte

On n'est pas plus avancé

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

Re: [OSM-talk-fr] BANO : fréquence de mise à jour, lien vers carte de Christian manquants dans le wiki

[Jérôme Seigneuret]

Yves ce que tu veux c'est un lien qui te permet de voir en fonction de ton
code insee la carte tuilé BANO correspondant à l'emprise du code INSEE
saisie ?



Le 6 octobre 2014 19:02, Yves Pratter  a écrit :

> Bonsoir,
>
> Je n’ai pas trouvé à quelle fréquence est mise à jour la BANO ?
> Idem pour les outils suivants.
>
> Au passage, il manque une section avec les outils qui permettent de
> visualiser/lister facilement et rapidement sont contenu :
>
>- carte : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html
>- liste : http://cadastre.openstreetmap.fr/fantoir/#insee=25223
>
>
> —
> Yves
>
> ___
> 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] Prix des carburants ?

[David Crochet]

Bonjour

Le 06/10/2014 16:59, Jérôme Seigneuret a écrit :

Ca ressemble à du géocodage adresse et non à de la géolocalisation...


Je confirme

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Jérôme Seigneuret]

http://en.wikipedia.org/wiki/Wilderness_hut


   - Wilderness hut  -
   rent-free, open dwelling place for temporary accommodation


Donc c'est pas ce que tu veux vu que c'est un gîte d'étape
voir le site http://lison.accueil.free.fr/

gite d'étape c'est rest_house mais ça n'existe pas dans OSM
On peut l'assimilé à du B&B donc guest_house

Dans ton cas il y a  *Catered accommodation  *en clair de la restauration
avec l'hébergement donc le guest_house c'est OK et même les cabanes sont
proposées avec

il y a ça aussi à voir pour OSM
http://wiki.openstreetmap.org/wiki/Proposed_features/Tourism_Reform

Le 6 octobre 2014 19:36, Stéphane Péneau  a
écrit :

>  Le 06/10/2014 18:30, Yves Pratter a écrit :
>
> Le gîte d’étape selon mon expérience :
>
>- tourism=hostel
> pour un
>bâtiment avec des dortoirs, des chambres avec plusieurs lits… Les
>sanitaires, cuisine… sont communs.
>- tourism=guest_house
> pour une
>chambre chez l’habitant (genre gîtes de France, B&B)
>- tourism=alpine_hut
> pour un
>refuge/gîte isolé (le plus souvent en montagne)
>
>
>
> Je parlais plutôt du gite "pas d'étape" qui est loué par une famille, un
> groupe de personne. C'est équipé de chambres, cuisines, salles de bain, et
> parfois de piscine & co. Ça s'apparente plus à de la location de maison.
>
> "hostel", si je regarde la page wikipedia, ça s'apparente aux auberges de
> jeunesse, où des personnes de provenances différentes partagent un lieu
> avec souvent des dortoirs.
>
> "hostel" n'a pas d'équivalent sur le wikipedia français (mais auberge de
> jeunesse n'existe pas)
>
> la page française de "Gîte" existe en anglais en parlant d'une spécificité
> française :
> http://en.wikipedia.org/wiki/G%C3%AEte
>
> On n'est pas plus avancé
>
> Stf
>
> ___
> 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 : Terrains de sports non intégrés Refuge de montagne

[Frédéric Rodrigo]

Le 06/10/2014 17:04, Yves Pratter a écrit :

Est-ce qu’Osmose pourrait proposer plusieurs tags ou en choisir un plus
adapté en fonction du nom ?


Ce n'est pas impossible avec un patch.



Je remarque aussi qu’il ne propose pas l’attribut *name* alors que la
donnée est bien fournie par le ministère (« Refuge de montagne, Gîte
d'étape Lison acceuil »)
*name=Gîte d'étape Lison accueil*


La qualité des noms dans le fichier d'origine est trop disparate pour la 
proposé en automatique.



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

Re: [OSM-talk-fr] Prix des carburants ?

[Frédéric Rodrigo]

La mise à jour de données OSM avec des données OpenData est une 
amélioration de l'intégration de données avec Osmose que j'ai en tête.


Mais c'est quand même plus facile lorsque les ref sont intégrées à OSM 
et il n'y a pas toujours de ref, ou des ref non "privé" en la qu'elle on 
peut avoir confiance.



Le 06/10/2014 17:38, Jérôme Amagat a écrit :

j'ai regardé ça
http://osmose.openstreetmap.__fr/fr/map/#item=8200&__useDevItem=true
.
C'est vrai qu'il y en a pas mal qui sont très mal placé mais c'est pour
beaucoup possible de retrouver leur vrai place avec l'adresse indiqué.
Mais il faut dire qu'il ne reste sur osmose que les stations non
présente dans osm ou très mal geocodé.
Les stations bien geocodé (ou pas trop mal) et presente dans osm ont
disparu (osmose en a trouvé combien? c'est possible de la savoir?) on
pourrai leur ajouté les données sur les carburants et services qui sont
presentes dans les donnée libéré.Peut etre comme les integration
possible pour les amenity=fuel qui n'ont aucun fuel:*=*

Le 6 octobre 2014 16:59, Jérôme Seigneuret mailto:jseigneuret-...@yahoo.fr>> a écrit :

Ca ressemble à du géocodage adresse et non à de la géolocalisation...
J'ai regardé dans mon coin et j'ai pas mal de points localisés en
début de rue d'où les décalage et le fait que ce soit pas super. En
même temps j'ai regarder les popositons d'ajout pour les écoles et
les éléments sportifs et c'est pas beaucoup mieux en terme de
précisions. J'ai des décalages de 200 à 300m.

Je pense que la reprojection peu merder un peu aussi (dixit grille
de transformation comme sous ArcGIS) Si c'est du Lambert 2 c'est
encore pire... car il y a des variantes

Le 6 octobre 2014 15:21, Francescu GAROBY mailto:windu...@gmail.com>> a écrit :

Et puis, les stations sur autoroute, il y a moyen de les repérer
avec les photos aériennes. Du coup, ça nécessite clairement de
faire le travail manuellement, mais ça pourrait être utile, non ?

Francescu

Le 6 octobre 2014 15:14, Jérôme Amagat mailto:jerome.ama...@gmail.com>> a écrit :

Bonjour,

C'est si mauvais que ça? j'ai regarder pour quelques points,
il sont pas idéalement placé mais pas non plus très loin :
une 50ene de mètre souvent sur la route à coté de la station
à part les station sur autoroute qui là je suis d'accord
sont souvent mal placé).
Il y a bien d'autres chose proposé a l’intégration qui sont
pas toujours bien placé.

Et ajouté les carburants sur les amenity=fuel sans fuel:*=*
qui sont proche (100 metres ?)

Le 4 octobre 2014 19:01, Frédéric Rodrigo
mailto:fred.rodr...@gmail.com>> a
écrit :

Bon finalement après mise en place de l'intégration des
stations à Osmose on a choisi de ne pas activer
l'analyse. Le géolocalisation des stations étant de
mauvaise qualité pour avoir un intérêt.
Probablement le résultat d'un géocodage de piètre qualité.

Frédéric.


Le 26/09/2014 19:39, Jean-Baptiste Holcroft a écrit :

Oui, enfin ça reste un raffinement

Le 26 sept. 2014 18:06, "David Crochet"
mailto:david.croc...@free.fr>
>__> a écrit :

 Bonjour

 Le 26/09/2014 11:25, Frédéric Rodrigo a écrit :

 Mais bizarrement il nb'y a pas de simple
payment:cards=yes


 Non, car il y a des points de vente qui
refusent certaines cartes

 Cordialement



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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Yves Pratter]

Le 6 oct. 2014 à 19:36, Stéphane Péneau  a écrit :

> Je parlais plutôt du gite "pas d'étape" qui est loué par une famille, un 
> groupe de personne. C'est équipé de chambres, cuisines, salles de bain, et 
> parfois de piscine & co. Ça s'apparente plus à de la location de maison.
Ça correspond bien à la description de tourism=apartment

« A flat/appartement that can be rented, either from private person or a agency 
for a short period of time, e.g. on a weekly basis, for holiday purpose. Does 
not offer services like reception, bar or breakfeast like a hotel or a 
guesthouse, but is just a more or less furnished flat which normally includes a 
cooking facility. The tag will be applied to a building containing one or more 
holiday flats. »

Dans la page de discussion, quelqu’un fait le lien avec le terme  Vacation 
rental qui parle de maison, gite rural, villa holiday ;-D

> On n'est pas plus avancé
Tu n’es pas le seul, il est question de réformer l’attribut Tourism qui semble 
bien trop compliqué !

—
Yves



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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[JB]

Juste pour revenir à Osmose, il me semble que amenity=shelter + 
tourism=alpine_hut soit un peu exagéré. À mon sens, il ne devrait pas y 
avoir amenity=shelter.

JB.

Le 06/10/2014 20:23, Frédéric Rodrigo a écrit :

Le 06/10/2014 17:04, Yves Pratter a écrit :

Est-ce qu’Osmose pourrait proposer plusieurs tags ou en choisir un plus
adapté en fonction du nom ?


Ce n'est pas impossible avec un patch.



Je remarque aussi qu’il ne propose pas l’attribut *name* alors que la
donnée est bien fournie par le ministère (« Refuge de montagne, Gîte
d'étape Lison acceuil »)
*name=Gîte d'étape Lison accueil*


La qualité des noms dans le fichier d'origine est trop disparate pour 
la proposé en automatique.



___
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] La SNCF suit l'exemple Raildar ?

[PierreV]

Le service "Sncf Maps" a été lancé aujourd'hui:
http://www.sncf.com/fr/geolocalisation?data-map-zoom=6&data-map-livemap-unmatched=true
ou recherche par trajet http://www.sncf.com/fr/info-trafic ou recherche par
gare http://www.sncf.com/fr/rechercher-gare

Bref, petit comparatif de la carte de "visualisation" avec le service
dévelopé depuis bientot 1 an par http://www.raildar.fr/:
- points positifs: le fond de plan est un plan OSM qui charge "par défaut"
au niveau 6 sur la carte de france avec la visu des tgv uniquement. A partir
du zoom 8 le numéro des TGV est affiché et au niveau 9 les trains
"régionaux" apparaissent. Raildar affiche dès la carte de france les trains
régionaux.
Pour le fond il est "fourni" par un service allemand:
http://www.hacon.de/hafas/daten/karten-und-netze
mais il a l'air d’être travaillé pour "cacher" les voies ferrée de OSM qu'a
partir du zoom 14 (certaines voies non utilisées sont visibles du zoom 11 à
13). Le zoom max est le 15.

Allé coté infos des trains:
Très déçu... déja tout les trains sont "bleu" qu'ils soient en retard ou
pas... pas moyen de voir d'un coup d'oeil quels sont les trains en retard à
proximité!
Ensuite quand on fait apparaitre "la bulle" du train, il faut encore
"cliquer" pour faire apparaitre les horaires du train... mais surprise c'est
l'horaire "théorique" pas avec le retard. Pour connaitre si ton train a
un retard il faut "cliquer" sur la gare et "re-cliquer" sur un lien qui
t'affiche les horaires de la gare "théorique" avec enfin le retard annoncé!

Concernant la position, ben pas mieux que Raildar... ce sont des maj de 3
min a peu près...

Bref, beaucoup moins pratique que Raildar pour l'instant... j'espère qu'ils
vont prendre rapidement les retours des voyageurs pour rapidement faire
aussi bien que raildar voire mieux avec ce qui était attendu sur cette liste
dans les mails précédents?



--
View this message in context: 
http://gis.19327.n5.nabble.com/La-SNCF-suit-l-exemple-Raildar-tp5817273p5819548.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] BANO : fréquence de mise à jour, lien vers carte de Christian manquants dans le wiki

[Christian Quest]

Le 6 octobre 2014 19:02, Yves Pratter  a écrit :

> Bonsoir,
>
> Je n'ai pas trouvé à quelle fréquence est mise à jour la BANO ?
>

C'est désormais quotidien lancé à minuit, terminé un peu plus de 2h plus
tard.
Voir: https://github.com/osm-fr/bano-data/commits/master

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

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Stéphane Péneau]

Le 06/10/2014 20:25, Yves Pratter a écrit :


Le 6 oct. 2014 à 19:36, Stéphane Péneau > a écrit :


Je parlais plutôt du gite "pas d'étape" qui est loué par une famille, 
un groupe de personne. C'est équipé de chambres, cuisines, salles de 
bain, et parfois de piscine & co. Ça s'apparente plus à de la 
location de maison.
Ça correspond bien à la description de tourism=apartment 



Je suis rassuré :
tourism =*apartment* is 
very similar to tourism 
=chalet 
. Chalet are 
more single houses in mountain regions, and might often be more 
isolated. Aparments are often in villages, and several flats in one 
building.



Tu n’es pas le seul, il est question de réformer l’attribut Tourism 
 qui 
semble bien trop compliqué !




Oui, il va falloir suivre cette page.

Sait-on jamais, peut-être qu'un jour je trouverais la solution idéale 
pour tagger un Gîte troglodytique  :-)


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

[OSM-talk-fr] Panneaux de directions : tag Destination

[Jean-Baptiste Holcroft]

Bonjour,

Je ne comprends pas tout à fait comment mapper les panneaux directionnels,
si j'ai un petit panneau avec écrit le nom d'un village vers la droite,
j'indique : destination=Petit Village sur la voie qui y mène ?

Si j'ai des panneaux qui indiquent des espèces de lieux dits (des D29
d'après Wikipedia [1]), je peux l'indiquer aussi ?
Par exemple, j'ai une voie qui se nomme : "Route de la Queue du Serre" avec
un panneau qui indique :
* La Queue du Serre
* Font Gary

Je tag donc :
* Highway=Unclassified
* Name=Route de la Queue du Serre
* Destination=La Queue du Serre;Font Gary

Correct ?

Je trouve que le wiki [2] met l'accent sur les cas compliqués, mais les cas
simples et classiques ne me sautent pas aux yeux.
Je vois aussi la possibilité d'utiliser une relation [3], mais je ne vois
pas vraiment l'intérêt quand des tags simples permettent de répondre au
besoin
Çà vaudrait la peine de mettre à jour la page wiki des panneaux en France
[4] selon vos réponses.

[1] :
https://fr.wikipedia.org/wiki/Panneau_de_signalisation_directionnelle_de_position_en_France
[2] : https://wiki.openstreetmap.org/wiki/Key:destination
[3] : https://wiki.openstreetmap.org/wiki/FR:Relation:destination_sign
[4] : https://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France
--
Jean-Baptiste Holcroft
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Panneaux de directions : tag Destination

[David Crochet]

Bonjour

Le 06/10/2014 21:04, Jean-Baptiste Holcroft a écrit :

Je trouve que le wiki [2] met l'accent sur les cas compliqués, mais les
cas simples et classiques ne me sautent pas aux yeux.


Comme ?

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Prix des carburants ?

[Yves Pratter]

Le 6 oct. 2014 à 16:59, Jérôme Seigneuret  a écrit :

> J'ai regardé dans mon coin et j'ai pas mal de points localisés en début de 
> rue d'où les décalage et le fait que ce soit pas super.
Avec mon navigateur je ne vois pas le marqueur sur la carte.
Peux-tu mettre une image temporaire ?

 (je n’ai pas de Gimp sous la main pour transformer ça en pompe ou en pistolet 
à essence)

> En même temps j'ai regarder les popositons d'ajout pour les écoles et les 
> éléments sportifs et c'est pas beaucoup mieux en terme de précisions. J'ai 
> des décalages de 200 à 300m.
En zone rurale le décalage est souvent (très ?) important mais on arrive quand 
à repositionner l’objet.

—
Yves



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

Re: [OSM-talk-fr] Prix des carburants ?

[Yves Pratter]

Le 25 sept. 2014 à 23:15, Frédéric Rodrigo  a écrit :

> J'ai commencé à liste les informations que osmose va pouvoir mappé sous forme 
> de tag :
> http://lite3.framapad.org/p/station_services

   923   Vente de pétrole lampant

Le chiffre correspond aux nombres d’éléments trouvé dans le fichier ?

> J'aimerais bien aussi trouver des tags pour :
> - Vente de pétrole lampant
> - Vente de fioul domestique

Ça serait bien de gérer aussi :
« Vente de gaz domestique » (utile pour les camping-caristes, les navigateurs 
en péniches… cf. OpenRiverBoatMap)
« Station de gonflage ». Je pensais qu’il y en avait dans toutes les stations 
services, mais non, du moins dans ma région
les heures d’ouvertures :
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMOSE : Terrains de sports non intégrés Refuge de montagne

[Yves Pratter]

Le 6 oct. 2014 à 20:27, JB  a écrit :

> Juste pour revenir à Osmose, il me semble que amenity=shelter + 
> tourism=alpine_hut soit un peu exagéré. À mon sens, il ne devrait pas y avoir 
> amenity=shelter.
Ce ne serait pas le cas des refuges ouverts l’été, mais qui laisse accès à un 
abris l’hiver (grange non verrouillée qui sert de pseudo dortoir) ?
En saison, il y a un gardien qui prépare des petits déjeuners, des repas…

—
Yves


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

Re: [OSM-talk-fr] BANO : fréquence de mise à jour, lien vers carte de Christian manquants dans le wiki

[Yves Pratter]

Le 6 oct. 2014 à 19:42, Jérôme Seigneuret  a écrit :

> Yves ce que tu veux c'est un lien qui te permet de voir en fonction de ton 
> code insee la carte tuilé BANO correspondant à l'emprise du code INSEE saisie 
> ?
J’ai aussi pensé à ça — et ça serait super pratique…

…mais j’ai du mal m’exprimer, je voulais qu’un lien « officiel » soit mis dans 
une section « Liens externes » à la wikipedia.

—
Yves

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

Re: [OSM-talk-fr] BANO : fréquence de mise à jour, lien vers carte de Christian manquants dans le wiki

[Jérôme Seigneuret]

Dans ce cas il faut l'ajouter dans la page du wiki BANO le lien vers
http://cadastre.openstreetmap.fr/fantoir/
Il me semble qu'il y avait une autre interface qui est en maintenance
permanente...

Le 6 octobre 2014 22:01, Yves Pratter  a écrit :

>
> Le 6 oct. 2014 à 19:42, Jérôme Seigneuret  a
> écrit :
>
> Yves ce que tu veux c'est un lien qui te permet de voir en fonction de ton
> code insee la carte tuilé BANO correspondant à l'emprise du code INSEE
> saisie ?
>
> J’ai aussi pensé à ça — et ça serait super pratique…
>
> …mais j’ai du mal m’exprimer, je voulais qu’un lien « officiel » soit mis
> dans une section « *Liens externes* » à la wikipedia.
>
> —
> Yves
>
>
> ___
> 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] Panneaux de directions : tag Destination

[Jean-Baptiste Holcroft]

Eh bien, ça me semble parfait pour décrire le périphérique et les
autoroutes (motorway & freeway + 1ère phrase de la traduction française),
mais je me m'interroge pour un simple panneau. Alors cela me donne une
impression de complexité.

--
Jean-Baptiste Holcroft

Le 6 octobre 2014 21:16, David Crochet  a écrit :

> Bonjour
>
> Le 06/10/2014 21:04, Jean-Baptiste Holcroft a écrit :
>
>> Je trouve que le wiki [2] met l'accent sur les cas compliqués, mais les
>> cas simples et classiques ne me sautent pas aux yeux.
>>
>
> Comme ?
>
> Cordialement
>
> --
> David Crochet
>
> ___
> 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] Prix des carburants ?

[Yves Pratter]

Le 26 sept. 2014 à 11:25, Frédéric Rodrigo  a écrit :

>> payment:mastercard=yes
>> payment:visa=yes
>> payment:maestro=yes
Cette liste me parait bien trop longue… et dans notre cas, nous ne savons pas 
quel type de carte est accepté.
payment=mastercard;visa;maestro est plus court et tout aussi lisible ?

En admettant qu’on trouve une source de données détaillée, ne pas oublier le 
cas du liquide : payment:cash=yes/no
Qui ne s’est pas retrouvé au bord de la panne d’essence, un week-end, avec 
seulement un billet ?

> 
> Mais bizarrement il nb'y a pas de simple payment:cards=yes
Ce n’est pas documenté, mais c’est utilisé :

payment:cards=yes   817
payment:debit_cards=yes 3 802
payment:credit_cards=yes6 083

Au passage, je viens de voir qu’on peut comparer plusieurs tags avec tagInfo :
http://taginfo.openstreetmap.org/compare/payment:cards/payment:debit_cards/payment:credit_cards

> La ça serait plutôt un amenity=vending_machine mais on a déjà amenity=fuel. A 
> défaut, il faudrait juste utiliser vending_machine=fuel.
C’est plutôt la clé vending qu’il faut utiliser ;-)

vending 48 169
vending=yes 248
vending=fuel64

http://taginfo.openstreetmap.org/compare/vending/vending=yes/vending=fuel

—
Yves


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

[OSM-talk-fr] un peu de casse

[Pierre-Yves Berrard]

J'ai découvert quelques bizarreries dans ce secteur :
https://www.openstreetmap.org/#map=15/49.4555/2.4768

Notamment :

   - un énorme multipolygone farmland qui est est passé en residential ;
   - l'admin_center de la relation Erquinvillers qui a disparu.


J'aimerais bien restaurer ce dernier, mais je ne trouve pas son "id".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Panneaux de directions : tag Destination

[Christian Quest]

Pourquoi veux-tu mettre destination=* ?

Je ne vois pas ce que ça apporte dans ce cas.

C'est un noeud place=* qui donne l'info de position du lieu-dit, ensuite
c'est aux algo de routage de calculer la route et ils n'ont pas besoin de
panneaux routier pour cela.

Sur un échangeur, les affectations des voies sont intéressantes à
renseigner à l'aide de destination=*

Si tu veux vraiment mapper cette info, c'est le panneau qu'il faut
modéliser avec une relation destination_sign:
http://wiki.openstreetmap.org/wiki/Relation:destination_sign

On a peut être d'autres trucs à faire avant ;)


Le 6 octobre 2014 22:35, Jean-Baptiste Holcroft  a
écrit :

> Eh bien, ça me semble parfait pour décrire le périphérique et les
> autoroutes (motorway & freeway + 1ère phrase de la traduction française),
> mais je me m'interroge pour un simple panneau. Alors cela me donne une
> impression de complexité.
>
> --
> Jean-Baptiste Holcroft
>
> Le 6 octobre 2014 21:16, David Crochet  a écrit :
>
> Bonjour
>>
>> Le 06/10/2014 21:04, Jean-Baptiste Holcroft a écrit :
>>
>>> Je trouve que le wiki [2] met l'accent sur les cas compliqués, mais les
>>> cas simples et classiques ne me sautent pas aux yeux.
>>>
>>
>> Comme ?
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] un peu de casse

[Vincent de Château-Thierry]

Bonsoir,

Le 07/10/2014 00:05, Pierre-Yves Berrard a écrit :

J'ai découvert quelques bizarreries dans ce secteur :
https://www.openstreetmap.org/#map=15/49.4555/2.4768

Notamment :

  * un énorme multipolygone farmland qui est est passé en residential ;
  * l'admin_center de la relation Erquinvillersqui a disparu.


J'aimerais bien restaurer ce dernier, mais je ne trouve pas son "id".


Tu l'as via l'historique de la relation :
http://www.openstreetmap.org/api/0.6/relation/1073957/16

820324803 on dirait

Bonne nuit,
vincent

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

Re: [OSM-talk-fr] un peu de casse

[f . dos . santos]

La relation Erquinvillers :
- http://www.openstreetmap.org/relation/1073957/history

Et donc le noeud admin_centre qui a disparu :
- http://www.openstreetmap.org/node/820324803

Pour ce qui est de l'énorme multipolygone c'est celui-ci :
- http://www.openstreetmap.org/relation/3374806

Sur ce, bonne nuit ;-)

- Mail original -
De: "Pierre-Yves Berrard" 
À: "OSM talk-fr" 
Envoyé: Mardi 7 Octobre 2014 00:05:02
Objet: [OSM-talk-fr] un peu de casse



J'ai découvert quelques bizarreries dans ce secteur : 
https://www.openstreetmap.org/#map=15/49.4555/2.4768 



Notamment : 


* un énorme multipolygone farmland qui est est passé en residential ; 
* l'admin_center de la relation Erquinvillers qui a disparu. 



J'aimerais bien restaurer ce dernier, mais je ne trouve pas son "id". 
___
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] un peu de casse

[Pierre-Yves Berrard]

>
>
>> Tu l'as via l'historique de la relation :
> http://www.openstreetmap.org/api/0.6/relation/1073957/16
>
> 820324803 on dirait
>

Merci vincent (je ne connaissais pas le coup de l'affichage en xml des
versions)

J'ai rétabli la relation communale.

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

Re: [OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Philippe Verdy]

Ca pose tout de même un problème pour les communes associées et même dans
des communes simples qui ont plusieurs villages (sur les panneaux d'entrée
d'agglomération on trouve bien le nom de ces villages en gros avec en
dessous et plus petit l'indication "(commune de X)". Il est alors nor,al de
taguer ces noeuds "place=*" avec la valeur "village" (ou "hamlet" parfois
si moins de 100 habitants).
Ces noms sont aussi utilisés dans les adresses postales (avec le code
postal de la commune le plus souvent mas pas toujours, ce peut être celui
d'une commune voisine dont le bureau de poste est plus proche et dessert
mieux ce village)

Malgré tout on indique souvent sur le noeud principal de la commune la
population totale communale; y compris leurs villages séparés, et leurs
communes associées qui ont pourtant une population mesurée et bien définie
(même pour l'INSEE). Alors même qu'on permet au nœud admin_centre qu'il
porte le nom local du village centre différente de celui de la commune
entière.

Si on veut être logique, la mesure de population donnée dans un noeud place
ne devrait inclure que celle de l'agglométation (ou fraction
d'agglomération dans la commune) mais pas toute la commune et le classement
en hamlet/village/town/city se ferait sur ce chiffre plus restreint (de
quoi déclasser un certain nombre de "town" en "village". Et on devrait
garder des noeuds place pour les villages et communes associées séparés.

Pour la population communale entière, le chiffre devrait être porté non pas
par le noeud mais par la relation communale (et il devrait en être de même
du code INSEE de la commune qui est très mal porté par le noeud "central"
d'une des agglomérations de la commune.)

place=hamlet/village/town/city participe plutôt au zonage urbain de la
France et non au découpage admnistratif (relations communales), mais on a
du mal à gérer les zones urbaines, (aires urbaines, pôles urbains...) qui
portent sur plusieurs communes (et qui pourtant seraient très utiles pour
un meileur rendu cartographique des noms de villes.

Cela permettait de voir Nantes et pas Saint-Nazaire, ou de rendre visible
Paris au lieu de grosses communes de sa ceinture). On a bien des clés
"capital=yes" (capitale nationale) ou "capital=3/4/5/6/7/8" (autres niveaux
administratifs, très utilisé en Espagne où de nombreuses communes ont de
nombreux villages dont aucun ne correspond au nom de la commune) pour
tenter de classer l'importance relative des lieux, mais tous les rendus
n'en tiennent pas comtpe et continuent de se contenter des
place=hamlet/village/town/city (et souvent sans même tenir compte de la
population indiquée, justement parce qu'elle est incohérente sur les noeuds
et même les ref:INSEE ou la présence de liens Wikipédia parfois utilisé
comme critère "d'importance" ne donne pas de bons résultats; car on peut
avoir un tout petit village avec son lien Wikipédia mais pas la plus grosse
ville voisine, surtout si elel vient de changer de périmètre)

Je suis donc favorable à déplacer les chiffres de population et la
référence INSEE des noeuds place vers la relation communale uniquement. Et
laisser place=* uniquement avec les valeurs hamlet/village/town/city pour
les noeuds admin_centre, sans aucune population indiquée (mais en tenant
compte des autres réalités du zonage urbain). Le critère d'importance d'un
village devrait prendre en compte le fait qu'il est admin_centre d'une
relation adminsitrative (le tag capital=* étant déprécié mais conservé pour
compatibilité pendant un certain temps pour les moteurs de rendus qui les
utilise sans chercher les relations associées)

Note: Mapnik sur OSM.org est encore incohérent et refuse d'affiche le nom
d'une commune qui a des quartiers indiqués (suburb est prioritaire à tous
les niveaux de zoom, on ne voit le nom de la commune qu'à un niveau de zoom
très avancé et en plus petit que le nom des quartiers, alors que ces
quartiers sont peu mentionnés dans la signalisation routière et
directionnelle contrairement au nom de la commune)

No,inati, de son côté a encore du mal à ordonner le tout; il tient compte
de la hiérarchie des relations adminsitrative, mais pour le nom d'un lieu
affiché en tête avant ces découpages, il ne sait pas quoi choisir et
malheureusement peut n'afficher que le nom du lieu dit et d'un
sous-village, mais pas le nom de la commune (avant arrondissement,
département; région, pays...) alors même que la commune est relation
administrative (apparemment cela se produit quand la commune a un nom
différent de celui de son village centre).

Enfin j'aimerais bien que les communes associées restent taguées en tant
sue relation adminsitrative; mais on n'est toujours pas clair sur
l'admin_level à utiliser.

Pour moi cela devrait être le niveau 9, comme les arrondissements
municipaux de Paris/Lyon/Marseille (ce qui ne pose aucun problème
d'ambiguité dans ces 3 villes à arrondissements qui n'ont aucune commune
associées); afin de conserver au niveau 10 les quartiers administratifs de
chaque c

Re: [OSM-talk-fr] Panneaux de directions : tag Destination

[David Crochet]

Bonjour

Le 06/10/2014 21:04, Jean-Baptiste Holcroft a écrit :

Je tag donc :
* Highway=Unclassified
* Name=Route de la Queue du Serre
* Destination=La Queue du Serre;Font Gary


Attention à placer correctement le sens du chemin et définir le 
"forward" ou le "backward" si ce n'est pas un sens unique


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Panneaux de directions : tag Destination

[Jean-Baptiste Holcroft]

La raison est très simple, utiliser OSMAnd autour de Paris est très
complexe à cause de l'absence de cartographie des panneaux.
Mais le problème est le même en campagne, entendre "tournez à droite sur la
rue de ..." est souvent peu pratique, car si on voit le panneau
directionnel, le nom de la rue est souvent bien moins visible.
Donc quitte à avoir plein de photos de noms de voies, autant en profiter
pour ajouter les panneaux pris au passage.

Quel est l'intérêt de la relation par rapport à un
direction:forward/backward comme l'indique David ?

--
Jean-Baptiste Holcroft

Le 7 octobre 2014 00:08, Christian Quest  a écrit :

> Pourquoi veux-tu mettre destination=* ?
>
> Je ne vois pas ce que ça apporte dans ce cas.
>
> C'est un noeud place=* qui donne l'info de position du lieu-dit, ensuite
> c'est aux algo de routage de calculer la route et ils n'ont pas besoin de
> panneaux routier pour cela.
>
> Sur un échangeur, les affectations des voies sont intéressantes à
> renseigner à l'aide de destination=*
>
> Si tu veux vraiment mapper cette info, c'est le panneau qu'il faut
> modéliser avec une relation destination_sign:
> http://wiki.openstreetmap.org/wiki/Relation:destination_sign
>
> On a peut être d'autres trucs à faire avant ;)
>
>
> Le 6 octobre 2014 22:35, Jean-Baptiste Holcroft  a
> écrit :
>
> Eh bien, ça me semble parfait pour décrire le périphérique et les
>> autoroutes (motorway & freeway + 1ère phrase de la traduction française),
>> mais je me m'interroge pour un simple panneau. Alors cela me donne une
>> impression de complexité.
>>
>> --
>> Jean-Baptiste Holcroft
>>
>> Le 6 octobre 2014 21:16, David Crochet  a écrit :
>>
>> Bonjour
>>>
>>> Le 06/10/2014 21:04, Jean-Baptiste Holcroft a écrit :
>>>
 Je trouve que le wiki [2] met l'accent sur les cas compliqués, mais les
 cas simples et classiques ne me sautent pas aux yeux.

>>>
>>> Comme ?
>>>
>>> Cordialement
>>>
>>> --
>>> David Crochet
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le nouveau Nominatim 2.3 est arrivé

[Yves Pratter]

Le 6 oct. 2014 à 15:18, Pieren  a écrit :

> Vu sur la liste dev, une info qui va sans doute intéresser tous les
> utilisateurs de nominatim. Deux changements majeurs:
> - la prise en compte de la relation waterway pour la recherche de rivières
ça fonctionne même avec les écluses (ou presque) :-)

Recherchez « Cléry-sur-somme, canal du nord » depuis la carte de Christian : 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.htm
(Choisissez le fond de carte OpenRiverBoat plus adapté)

Par contre « écluse de cléry-sur-somme, canal du nord » ne fonctionne pas…

Peut-être que Claude ou Yohan auront regardé ça de plus près ?


—
Yves

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