Re: [OSM-talk-fr] Écluses et portes à flots

2018-01-18 Par sujet osm . sanspourriel 
Comme on est en milieu essentiellement marin et que les seamark:* sont 
pris de la norme des cartes nautiques électroniques (S57/S63/S100 pour 
les intimes), j'aurais tendance à favoriser :


seamark:gate:category

Et en plus c'est documenté :

https://wiki.openstreetmap.org/wiki/Seamarks/Gates#Categories

Le 18/01/2018 à 16:20, althio - althio.fo...@gmail.com a écrit :

Oui, il faudrait aller chercher l'avis des anglophones natifs.

Pourquoi pas faire la page wiki waterway=tidegate puis notifier sur
tagging, ou l'inverse ;)

De mon côté, pour "floodgate", je ne prendrais pas "flood"
littéralement pour "inondations", mais aussi "montée des eaux",
"débordement", "trop-plein".
Et pour moi on est totalement dans le contrôle d'écoulement (flow
control). Il y a d'autres installations qui sont clairement du "flood
protection".
Je vous laisse vous faire votre opinion, j'ai lu cela :

http://www.wordreference.com/definition/floodgate
[English] floodgate /ˈflʌdˌɡeɪt/ n. Also called: head gate, water gate
1. a gate in a sluice that is used to control the flow of water
2. (often plural: floodgates) a control or barrier against an outpouring or flow
[American] floodgate /ˈflʌdˌgeɪt/   n. [countable] Civil Engineering
1. gate regulating the flow of water.
2. anything serving to control the passage of something

http://www.wordreference.com/synonyms/floodgate
floodgate, sluice gate

http://www.wordreference.com/enfr/floodgate
floodgate n
often plural (gate preventing overflow of water) vanne, porte d'écluse
floodgates npl
figurative (barrier) barrière


En bonus, tout ce que j'ai pu pêcher dans taginfo :

waterway=lock_gate 17 359
waterway=sluice_gate 204
waterway=floodgate 170
waterway=former_lock_gate 12
waterway=gate 5
waterway=stuice_gate 3
waterway=headgate 3
waterway=stuice_gateream 2
waterway=former lock_gate 1
waterway=dock_gate 1
waterway=security_gate 1
waterway=sluicegate 1

waterway=flow_control 261
flow_control=sluice_gate 194
flow_control=water_level 22
flow_control=overflow 12
flow_control=bottom_outlet 11
flow_control=discharge 9
flow_control=entry 3
flow_control=over_flow 2
flow_control=traffic_lights half duplex 1
flow_control=moench 1
flow_control=sluice 1
flow_control=flood_gate 1

gate=flood_wall 6
gate=flood_defence 3
gate=flood_gate 2

seamark:gate:category=lock 295
seamark:gate:category=flood_barrage 51
seamark:gate:category=sluice 29
seamark:gate:category=general 3
seamark:gate:category=dyke 3
seamark:gate:category=caisson 3

2018-01-10 22:17 GMT+01:00  :

oups, j'avais lu flowgate. Comme quoi rien ne sert d'être plus fluent !

Oui, ça correspond protections anti-inondations.

Flood control et non flow control.
flow_control=water_level ? contrôle du niveau de l'eau
waterway=low_weir ? seuil bas

Semblent là aussi surtout utilisé en eaux douces.


Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :

Bonsoir,

ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
en anglais !!!).

Alors que les portes à flots j'ai l'impression que c'est quelque chose de
plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
(zone marécageuses par exemples).



Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :

Ça me plait, ça pourrait être utilisé pour les formes de raboub et les seuil
des ports me semble-t-il.

Pour le moment mes recherches sur Brest et Lorient n'ont rien donné : on a
des eaux ou des formes de raboub mais la séparation se fait par la vertu du
Saint-Esprit.

Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.

Il faudrait presque une info complémentaire car certaines "écluses" sont
faites pour faire entrer l'eau de mer, d'autres pour faire sortie l'eau
douce d'autres pour simplement contrôler le niveau style chasse de la baie
du mont Saint-Michel.


Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
en anglais !!!).

Alors que les portes à flots j'ai l'impression que c'est quelque chose de
plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
(zone marécageuses par exemples).


Le 10/01/2018 à 00:16, althio a écrit :


Par analogie, il faudrait quelque chose comme waterway=tidal_gate

tide gate ou floodgate semble plus courant en anglais.

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


à votre avis on part plutôt sur floodgate parce que cela existe déjà ou sur
un tidegate car plus lié au marée

à plus

Vinber




___
Talk-fr mailing list

Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-18 Par sujet Philippe Verdy 
Je suis d'accord aussi: ce qui va intéresser le moteur de navigation c'est
trouver un chemin d'accès non ambigu (même si pour lever l'ambiguïté il
faut aller au delà du domaine public et entrer sur une voie privée (qui
devra être tracée).

Cependant il reste à associer le nœud portant le numéro à sa rue car si on
passe par une voie privée ou un chemin public sans nom (ou ayant un nom
local non utilisé pour l'adresse tel que "entrée ouest"), la rue indiquée
dans l'adresse ne sera souvent pas la plus proche du nœud (certains
passages par une voie privée d'un tiers sont nécessaires, il y a des cas où
c'est une servitude obligatoire, toute propriété doit avoir un accès libre
à son propriétaire ou ses invités).

Et pour ça on a déjà la relation "associatedStreet" qui évite de copier le
nom de la rue dans tous les nœuds d'adresse (mais cette relation est
discutée, et ne rien mettre dans le nœud et ne pas l'associer non plus dans
une relation produit des erreurs...).

Même si on trace des voies privées, on n'a pas obligation de mettre le nœud
d'adresse dessus, mais il devrait en être assez proche pour qu'il n'y ait
pas d’ambiguïté sur le chemin à suivre (même si ce n'est pas le nom de rue
pour l'adresse indiquée dans le nœud ou la relation "associatedStreet").

Ça résout donc tous les cas et on n'a pas besoin d'attacher non plus ces
nœuds aux bâtiments: on se place sur un nœud à proximité du chemin d'accès
(public ou privé) et plutôt à l'extérieur (sauf en zone urbaine : on se
place à l'intérieur près de la porte d'accès faisant face au trottoir, ou
en limite de propriété s'il y a un jardin ou une cours privée devant, mais
en évitant de se mettre là aussi sur une barrière, un mur de clôture ou un
fossé). Les nœuds d'adresse devraient rester distincts de tout autre objet.

Il reste cependant le cas des POIs (commerces) situés à cheval entre deux
adresses : ces nœuds doivent porter un attribut pour leur propre numéro(s)
pour lever l’ambiguïté de numéro, voire aussi le nom de leur rue (et ils
n'ont pas à figurer en membre de relation "associatedStreet") car ils
peuvent avoir plusieurs accès par des rues différentes.

Si on a une relation 1:1 pour associer ces nœuds POIs aux adresses on peut
réutiliser le même nœud pour les deux (ce qui évite des doublons
d'adresses), sinon il faut les séparer et pour éviter les doublons
d'adresse on pourra toujours metttre le numéro et le nom de rue du POI dans
"contact:*" et non "addr:*".

Le 18 janvier 2018 à 18:52, Cyrille37 OSM  a
écrit :

> Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
>
> Le 16 janvier 2018 à 12:17, jabali  a écrit :Il
> faut accepter qu'une adresse et un bâtiment sont deux notions différentes.
> Dans ton 1er exemple de routage, ce n'est pas le bâtiment qu'il faut viser
> mais son point d'accès soit la barrière (qui devrait porter l'adresse) qui
> matérialise la distinction entre les espaces publics et privés.
>
>
> +1000
>
> immeubles à plusieurs entrées (donc plusieurs numéro), maison très proche
> d'une voie mais dont l'accès se fait par une autre voie. Ce questionnement
> revient régulièrement, et quand on fini par comprendre, c'est bien le point
> d'accès et non le bâti qui porte le numéro d'adresse.
>
> Cyrille37.
>
>
> ___
> 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] schéma des addr

2018-01-18 Par sujet Ralf Treinen 
Bonsoir,

On Tue, Jan 16, 2018 at 11:43:52PM +, marc marc wrote:

> Donc ma proposition : en cas de nœud-adresse avec une adresse pour un 
> bâtiment, ne pourrait-on pas associer l'adresse au bâtiment soit on 
> mettant le nœud sur le contour ou dans le bâtiment (ou via une relation
> si quelqu'un est motivé pour porter une proposition).

un collegue m'a rappelé il y a quelque temps un très bon principe (si
vous m'excusez l'anglais) :

  simple things should be simple, complicated things should be possible

Une relation (associatedAddress ?) qui associe une adresse à plusieurs
éléments (terrain, des bâtiments, des entrées, des commerces, ...)
me semble assez générale pour couvrir tous les cas que je peux
imaginer. C'est évidement lourd, personne n'a envie de créer
une relation par bâtiment. C'est pourquoi il faut aussi une solution
simple pour la grande majorité des cas qui est : un bâtiment - une
adresse. La solution de Marc de situer dans de tels cas simples l'adresse
au point d'entrée du bâtiment me semble très bien. 

-Ralf.

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-18 Par sujet Cyrille37 OSM 

resalut

Je ne suis pas aussi complexe, juste que l'usage d'une adresse me semble 
être de s'y rendre, puis il faut passer de l'espace public à l'espace 
privée, dans lequel la fonction du ou des bâtis ne concernent que les 
habitants/usagers/ Autre exemple (en plus des immeubles) le bâti 
ancien où il y a 2 à 4 bâtis pour la même adresse, ou encore une 
entreprise avec 4 ou 5 bâtis. Encore un autre, en ville cette fois, avec 
les maisons dans les intersections, qui ont l'air bien malines avec leur 
numéro au milieu et 2 voies bordant le coin et deux côtés.


Non franchement, je ne vois pas d'autre point d'accroche "utile" du 
numéro de voie que celui où l'on quitte l'espace public pour passer dans 
l'espace "privé" ou "d'usage".


Cyrille37.

Le 18/01/2018 à 19:39, marc marc a écrit :

Le 18. 01. 18 à 18:52, Cyrille37 OSM a écrit :

Le 17/01/2018 à 21:57, Romain MEHUT a écrit :

Le 16 janvier 2018 à 12:17, jabali a écrit :Il faut accepter qu'une
adresse et un bâtiment sont deux notions différentes. Dans ton 1er
exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son
point d'accès soit la barrière (qui devrait porter l'adresse) qui
matérialise la distinction entre les espaces publics et privés.

maison très proche d'une voie mais dont l'accès se fait par une autre voie.

j'aimerais bien voir un cas réel d'adresse de la rue A situé le long de
la rue B... j'imagine que ce genre de nœud doit parfois faire des yoyo.
On peux tout aussi bien résoudre le problème de routing en traçant le
chemin d'accès réel jusqu'à la maison. Ce n'est donc pas un bon argument
(si on veux un objet = une fonction, alors la position de l'adresse ne
sert pas au routing, c'est le rôle des routes de servir à cela).


c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.

Si on veux être puriste, je pense que c'est la parcelle qui porte
souvent l'adresse. Avant même qu'un architecte ai dessiné la voie
d'accès, la rue a parfois été saucissonnée pour attribuer les numéros
"non utilisé" aux parcelles non bâties.
Pour couper court, je ne nie pas qu'une adresse et un bâtiment sont 2
choses différentes. je reproche juste le manque de lien indispensable
entre les 2.
C'est bien (ou pas) de tager pour le routing.
Mais c'est tout aussi bien d'avoir la possibilité de se repérer sur une
carte (cela fait partie de la fonction première) et donc savoir quel est
l'adresse d'un bâtiment donné, le savoir avec certitude, pas en mode
devinette ou procéder par élimination/supposition dans les situations un
peu plus "tordue" qu'un alignement de maison le long d'une rue.
je t'invite à lire mon argumentation dans le sujet "schéma des adresses".
J'y expose un outil (qui n'est pas de moi) qui montre quand il y a un
lien entre un nœud adresse et le bâtiment... et quand il n'y en a pas.
je t'invite à faire une proposition pour combler ce manque.
Cela permettrait ensuite de demander aux applications de supporter ce
lien et donc d'afficher l'adresse du bâtiment quand on le sélectionne et
d'éviter ainsi que les utilisateur encode des doublons lorsque le nœud
se situe hors du bâtiment qui la concerne.
Parce que pour le moment, aucune application ne donne l'adresse d'un
bâtiment qui a un nœud adresse à x mètres. Nominatim se contente de
déplacer ta demande au nœud le plus proche... qui est juste... ou pas.
___
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] positionnement des adresses et ménage

2018-01-18 Par sujet marc marc 
Le 18. 01. 18 à 18:52, Cyrille37 OSM a écrit :
> Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
>> Le 16 janvier 2018 à 12:17, jabali a écrit :Il faut accepter qu'une 
>> adresse et un bâtiment sont deux notions différentes. Dans ton 1er 
>> exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son 
>> point d'accès soit la barrière (qui devrait porter l'adresse) qui 
>> matérialise la distinction entre les espaces publics et privés.

> maison très proche d'une voie mais dont l'accès se fait par une autre voie. 

j'aimerais bien voir un cas réel d'adresse de la rue A situé le long de 
la rue B... j'imagine que ce genre de nœud doit parfois faire des yoyo.
On peux tout aussi bien résoudre le problème de routing en traçant le 
chemin d'accès réel jusqu'à la maison. Ce n'est donc pas un bon argument 
(si on veux un objet = une fonction, alors la position de l'adresse ne 
sert pas au routing, c'est le rôle des routes de servir à cela).

> c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.

Si on veux être puriste, je pense que c'est la parcelle qui porte 
souvent l'adresse. Avant même qu'un architecte ai dessiné la voie 
d'accès, la rue a parfois été saucissonnée pour attribuer les numéros 
"non utilisé" aux parcelles non bâties.
Pour couper court, je ne nie pas qu'une adresse et un bâtiment sont 2 
choses différentes. je reproche juste le manque de lien indispensable 
entre les 2.
C'est bien (ou pas) de tager pour le routing.
Mais c'est tout aussi bien d'avoir la possibilité de se repérer sur une 
carte (cela fait partie de la fonction première) et donc savoir quel est 
l'adresse d'un bâtiment donné, le savoir avec certitude, pas en mode 
devinette ou procéder par élimination/supposition dans les situations un 
peu plus "tordue" qu'un alignement de maison le long d'une rue.
je t'invite à lire mon argumentation dans le sujet "schéma des adresses".
J'y expose un outil (qui n'est pas de moi) qui montre quand il y a un 
lien entre un nœud adresse et le bâtiment... et quand il n'y en a pas.
je t'invite à faire une proposition pour combler ce manque.
Cela permettrait ensuite de demander aux applications de supporter ce 
lien et donc d'afficher l'adresse du bâtiment quand on le sélectionne et 
d'éviter ainsi que les utilisateur encode des doublons lorsque le nœud 
se situe hors du bâtiment qui la concerne.
Parce que pour le moment, aucune application ne donne l'adresse d'un 
bâtiment qui a un nœud adresse à x mètres. Nominatim se contente de 
déplacer ta demande au nœud le plus proche... qui est juste... ou pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Atelier de lutherie

2018-01-18 Par sujet Rodrigo Vivar 

Bonjour

Vois pas pourquoi mettre métier dans description, pourquoi ajouter niveau intermédiaire "strings ou wind", apporte quoi ?

serais plutôt d'accord avec marc marc pour "musical_instrument=luthier". m'étonnerais chercher les fabricants d'instrument à corde, mais chercher "luthier" ou autre artisan oui.

Et lutherie connue en plusieurs langues

 

Quand décision pris, comment vous faites ici pour wiki : modifiez ou voyez avec autres pays ?

Et pour les quelques tags dans osm qui sont plus bon vous modifiez ?

 

cordialmnt

Rod 

 


2. Re: Atelier de lutherie (Julien Coupey)
3. Re: Atelier de lutherie (osm.sanspourr...@spamgourmet.com)



From: Julien Coupey 

Bonsoir,

Merci pour vos réponses. Je suis parti sur la combinaison :

shop=musical_instrument
craft=musical_instrument
musical_instrument=strings (ou wind)

La seule chose qui n'est pas vraiment décrite est le fait de fabriquer
en plus de faire de la réparation (le cas des luthiers des instruments
du quatuor). J'ai précisé ça avec le tag description qui est finalement
le seul où apparaît le mot luthier le cas échéant.

À+
Julien

Le 15/01/2018 à 09:53, Thibaud B a écrit :
> Bonjour,
>
>
> Je suis d'accord avec l'utilisation de craft=musical_instrument +
> musical_instrument=* et/ou éventuellement un tag description=* pour
> préciser l'activité de l'artisan, car ils peuvent parfois
> réparer/fabriquer plusieurs type d'instruments.
>
> Voir exemple ici : https://www.openstreetmap.org/node/5025952922
>
> Ici l'artisan répare tout type d'instrument à vent, j'ai préférer le
> mettre dans description , mais pourquoi pas un musical_instrument=wind
>
> Cordialement,
>
> 
> *De :* marc marc 
> *Envoyé :* dimanche 14 janvier 2018 01:10
> *À :* talk-fr@openstreetmap.org
> *Objet :* Re: [OSM-talk-fr] Atelier de lutherie
> Bonjour,
>
> Le 13. 01. 18 à 22:48, Julien Coupey a écrit :
>> C'est shop=musical_instrument[2] qui semble s'approcher le plus sur le
>> wiki, mais sans évoquer l'aspect de création artisanale.
>> Taginfo trouve seulement 22 occurences de craft=luthier, est-ce que vous
>> conseilleriez de l'utiliser ? D'autres idées ?
>
> si shop=musical_instrument semble une bonne idée,
> par analogie, tu peux mettre craft=musical_instrument 36 occurrences
> https://taginfo.openstreetmap.org/tags/?key=craft=musical_instrument
>
> Si la précision que c'est un luthier te semble nécessaire,
> pour ma part je privilégiais un sous-tag genre
> craft=musical_instrument + musical_instrument=luthier
>
> Cordialement,
> Marc
--

Message: 3
Date: Tue, 16 Jan 2018 23:44:25 +0100
From: osm.sanspourr...@spamgourmet.com
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Atelier de lutherie
Message-ID: <790412be-9eff-6367-d386-95874862c...@gmx.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Si, la clé craft indique que c'est de la fabrication :

https://wiki.openstreetmap.org/wiki/Key:craft

A minima de l'artisanat.
Tu peux éventuellement ajouter qu'elle fait aussi de la réparation :
https://wiki.openstreetmap.org/wiki/Key:repair

Le 16/01/2018 à 21:11, Julien Coupey - o...@coupey.fr a écrit :
> Bonsoir,
>
> Merci pour vos réponses. Je suis parti sur la combinaison :
>
> shop=musical_instrument
> craft=musical_instrument
> musical_instrument=strings (ou wind)
>
> La seule chose qui n'est pas vraiment décrite est le fait de fabriquer
> en plus de faire de la réparation (le cas des luthiers des instruments
> du quatuor). J'ai précisé ça avec le tag description qui est
> finalement le seul où apparaît le mot luthier le cas échéant.
>
> À+
> Julien

 



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

Re: [OSM-talk-fr] positionnement des adresses et ménage

2018-01-18 Par sujet Cyrille37 OSM 

Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
Le 16 janvier 2018 à 12:17, jabali > a écrit :Il faut accepter qu'une 
adresse et un bâtiment sont deux notions différentes. Dans ton 1er 
exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son 
point d'accès soit la barrière (qui devrait porter l'adresse) qui 
matérialise la distinction entre les espaces publics et privés.


+1000

immeubles à plusieurs entrées (donc plusieurs numéro), maison très 
proche d'une voie mais dont l'accès se fait par une autre voie. Ce 
questionnement revient régulièrement, et quand on fini par comprendre, 
c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.


Cyrille37.

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

Re: [OSM-talk-fr] Écluses et portes à flots

2018-01-18 Par sujet althio 
Oui, il faudrait aller chercher l'avis des anglophones natifs.

Pourquoi pas faire la page wiki waterway=tidegate puis notifier sur
tagging, ou l'inverse ;)

De mon côté, pour "floodgate", je ne prendrais pas "flood"
littéralement pour "inondations", mais aussi "montée des eaux",
"débordement", "trop-plein".
Et pour moi on est totalement dans le contrôle d'écoulement (flow
control). Il y a d'autres installations qui sont clairement du "flood
protection".
Je vous laisse vous faire votre opinion, j'ai lu cela :

http://www.wordreference.com/definition/floodgate
[English] floodgate /ˈflʌdˌɡeɪt/ n. Also called: head gate, water gate
1. a gate in a sluice that is used to control the flow of water
2. (often plural: floodgates) a control or barrier against an outpouring or flow
[American] floodgate /ˈflʌdˌgeɪt/   n. [countable] Civil Engineering
1. gate regulating the flow of water.
2. anything serving to control the passage of something

http://www.wordreference.com/synonyms/floodgate
floodgate, sluice gate

http://www.wordreference.com/enfr/floodgate
floodgate n
often plural (gate preventing overflow of water) vanne, porte d'écluse
floodgates npl
figurative (barrier) barrière


En bonus, tout ce que j'ai pu pêcher dans taginfo :

waterway=lock_gate 17 359
waterway=sluice_gate 204
waterway=floodgate 170
waterway=former_lock_gate 12
waterway=gate 5
waterway=stuice_gate 3
waterway=headgate 3
waterway=stuice_gateream 2
waterway=former lock_gate 1
waterway=dock_gate 1
waterway=security_gate 1
waterway=sluicegate 1

waterway=flow_control 261
flow_control=sluice_gate 194
flow_control=water_level 22
flow_control=overflow 12
flow_control=bottom_outlet 11
flow_control=discharge 9
flow_control=entry 3
flow_control=over_flow 2
flow_control=traffic_lights half duplex 1
flow_control=moench 1
flow_control=sluice 1
flow_control=flood_gate 1

gate=flood_wall 6
gate=flood_defence 3
gate=flood_gate 2

seamark:gate:category=lock 295
seamark:gate:category=flood_barrage 51
seamark:gate:category=sluice 29
seamark:gate:category=general 3
seamark:gate:category=dyke 3
seamark:gate:category=caisson 3

2018-01-10 22:17 GMT+01:00  :
> oups, j'avais lu flowgate. Comme quoi rien ne sert d'être plus fluent !
>
> Oui, ça correspond protections anti-inondations.
>
> Flood control et non flow control.
> flow_control=water_level ? contrôle du niveau de l'eau
> waterway=low_weir ? seuil bas
>
> Semblent là aussi surtout utilisé en eaux douces.
>
>
> Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :
>
> Bonsoir,
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
>
> Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :
>
> Ça me plait, ça pourrait être utilisé pour les formes de raboub et les seuil
> des ports me semble-t-il.
>
> Pour le moment mes recherches sur Brest et Lorient n'ont rien donné : on a
> des eaux ou des formes de raboub mais la séparation se fait par la vertu du
> Saint-Esprit.
>
> Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.
>
> Il faudrait presque une info complémentaire car certaines "écluses" sont
> faites pour faire entrer l'eau de mer, d'autres pour faire sortie l'eau
> douce d'autres pour simplement contrôler le niveau style chasse de la baie
> du mont Saint-Michel.
>
>
> Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
> Le 10/01/2018 à 00:16, althio a écrit :
>
>
> Par analogie, il faudrait quelque chose comme waterway=tidal_gate
>
> tide gate ou floodgate semble plus courant en anglais.
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> à votre avis on part plutôt sur floodgate parce que cela existe déjà ou sur
> un tidegate car plus lié au marée
>
> à plus
>
> Vinber
>
>
>
>
> ___
> 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] Écluses et portes à flots

2018-01-18 Par sujet Vincent Bergeot 

Bonjour,

Le 10/01/2018 à 22:17, osm.sanspourr...@spamgourmet.com a écrit :

Flood control et non flow control.
flow_control=water_level 
 ? 
contrôle du niveau de l'eau
waterway=low_weir 
 ? seuil bas


Semblent là aussi surtout utilisé en eaux douces.



donc si l'on part du principe que les divers tags existants ne sont pas 
"satisfaisants", que celui qui semble le plus correct pourrait être :
waterway=tidegate (la définition semble bien coller : 
https://en.wiktionary.org/wiki/tide_gate), plus peut-être un complément 
pour préciser le sens ?


Quelle est la "bonne" manière de continuer :

la liste tagging,
je me prends trop la tête, je fais et je documente sur le wiki (je 
récupère une photo pour illustrer également !)


merci
Bonne journée




Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :


Bonsoir,

ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à 
de l'inondation, du déluge (de ce que j'ai compris je ne suis pas 
assez fluent en anglais !!!).


Alors que les portes à flots j'ai l'impression que c'est quelque 
chose de plus régulier, à chaque marée, soit pour maintenir de l'eau 
dans un port par exemple soit pour empêcher l'eau de mer de venir 
"polluer" de l'eau douce (zone marécageuses par exemples).




Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :


Ça me plait, ça pourrait être utilisé pour les formes de raboub et 
les seuil des ports me semble-t-il.


Pour le moment mes recherches sur Brest et Lorient n'ont rien donné 
: on a des eaux ou des formes de raboub mais la séparation se fait 
par la vertu du Saint-Esprit.


Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.

Il faudrait presque une info complémentaire car certaines "écluses" 
sont faites pour faire entrer l'eau de mer, d'autres pour faire 
sortie l'eau douce d'autres pour simplement contrôler le niveau 
style chasse de la baie du mont Saint-Michel.



Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à 
de l'inondation, du déluge (de ce que j'ai compris je ne suis pas 
assez fluent en anglais !!!).


Alors que les portes à flots j'ai l'impression que c'est quelque 
chose de plus régulier, à chaque marée, soit pour maintenir de l'eau 
dans un port par exemple soit pour empêcher l'eau de mer de venir 
"polluer" de l'eau douce (zone marécageuses par exemples).



Le 10/01/2018 à 00:16, althio a écrit :



Par analogie, il faudrait quelque chose comme waterway=tidal_gate

tide gate ou floodgate semble plus courant en anglais.

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


à votre avis on part plutôt sur floodgate parce que cela existe déjà 
ou sur un tidegate car plus lié au marée


à plus

Vinber




___
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



--
Vincent Bergeot

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

[OSM-talk-fr] serveur opéré par la Fondation [Re: Première réunion du bureau de l'OSMF ...]

2018-01-18 Par sujet Benoit Fournier 
> Severin Menard  :
>> a priori l'instance de Mumble utilisée est celle du serveur de l'ONG HOT US 
>> Inc.

Vincent Privat  :
> ... pardon ? ça pourra être la première question à poser au board: pourquoi 
> ne pas mettre en place un serveur opéré par la Fondation et localisé en 
> dehors des US ?

De mon point de vue, ce n'est pas la première question à poser, et ce
n'est pas une question pour le board (plutôt pour OWG - Working Group
"Operations").


> pourquoi ne pas mettre en place un serveur localisé en dehors des US ?

Le serveur me semble localisé en Europe, pas vous ? Un serveur de hetzner.de ?
Et sinon, quelle différence ? (ça peut être bon d'expliciter les
justifications de manière raisonnée, pour éviter les interprétations
hasardeuses, par exemple d'être incorrectement assimilé à de
l'anti-américanisme trop primaire).


> pourquoi ne pas mettre en place un serveur opéré par la Fondation

Ensuite, je ne vais pas répondre à leur place, mais des réponses
possibles sont :
Parce que c'est pragmatique ? Parce que l'usage ne le justifie pas ?
Parce que personne ne l'a demandé ? On met le matériel à disposition,
vous pouvez le faire ?
Pour un exemple de discussion sur le sujet (canaux de communication
"chats" de type IRC/Mattermost/Slack/Jabber/...) et donc les
réflexions et positions des membres du Working Group Operations :
https://github.com/openstreetmap/operations/issues/128#issue-192860779
https://github.com/openstreetmap/operations/issues/128#issuecomment-264404220
https://github.com/openstreetmap/operations/issues/128#issuecomment-266739577

D'un autre côté, et toujours mon avis personnel, c'est que des
services opérés par des tiers, la communauté ou des organismes, et non
pas directement par la Fondation, il y en a beaucoup dans l'écosystème
OSM et que c'est plutôt sain.
OSM-FR fait tourner uMap, Osmose, les tuiles FR et HOT, HOT fait
tourner un Tasking Manager et un Mumble, iD est financé par Mapbox,
JOSM est en Allemagne, Geofabrik propose des services et outils
qualité, BBBike des extracts, thunderforest le rendu cycle, Mapbox
avec OSMCha, ... et Github fait tourner beaucoup de code pour beaucoup
de projets.

Si des aspects stratégiques ne sont pas bien couverts, il faut ouvrir
la discussion avec le groupe Operations OWG.

Benoît
contributeur et bénévole et membre à dimension variable de OSM-FR *et*
OSMF/SotM *et* HOT *et* CartONG.

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

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

2018-01-18 Par sujet Sébastien Dinot 
Bonjour,

Le contributeur vient de réagir que les courriers postaux devaient être 
adressés à Mios et non à Lacanau-de-Mios. J'ai donc corrigé dans la foulée les 
adresses. Problème résolu.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

2018-01-18 Par sujet Philippe Verdy 
Au sein d'une agglomération on a aussi un niveau de place=suburb pour
qualifier les anciens villages absorbés par une commune, ça donne un niveau
en plus de neighbourhood (et hamlet qui devrait rester rural je pense).
Le cas du Japon, de la Chine, de la Corée ou de l'Inde avec leur mégapoles
ayant de nombreuses subdivisions internes peut aussi nous inspirer.

Le 18 janvier 2018 à 13:02, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 18 janv. 2018 à 09:57, erwan salomon  a écrit :
> >
> > salut,
> >
> > si je comprend bien voici un cas similaire sans doute plus explicite :
> > https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
> > (avec la traduction bretonne dessous)
> > ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite
> autour : https://www.openstreetmap.org/way/176823228 )
> > - [ attention village dans le language courant en bretagne désigne
> quelque chose d’encore plus petit, ne jamais dire à un breton qu’il habite
> dans un village il le prendra mal ]
> > alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
> > mais globalement ce sont 2 communes qui font partie d’une agglomération
> > en tant que tel elles ont un nom et une adresse postale distincte (sinon
> il y aurait des doublon de nom de rue)
> > mais la gestion administrative se fait par l’agglomération (c’est la
> mairie de Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les
> habitant de Fort-Bloqué vote pour le maire de Plœmeur)
> > un quartier c’est en général plus continu avec les quartiers voisins
> dans le langage courant, mais l’agglomération peut en effet diviser sa
> surface en quartier pour en répartir la gestion et procéder à des réunions
> de quartiers
> > il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici
> c’est l’inverse
> > quand à la gestion par Osmose, la je suis incompétent pour te donner des
> conseils
>
> Sur le principe, il est correct de classer Fort-Bloqué dans la catégorie «
> village » (de 100 à 10 000 habitants en France, selon le dernier consensus)
> dans OSM, indépendamment de ce qu’en fait l’administration. L’obligation de
> lui adjoindre des codes et une population doit se limiter aux unités
> administratives définies par l’Etat, mais les collectivités peuvent à leur
> en définir et les publier.
> Si une relation correspondant à une unité infra-communale officielle peut
> être tracée, tant mieux. Osmose doit prévoir ce genre de cas.
>
> Sur la liste anglophone, on débat de « hamlet » et « neighbourhood », ces
> derniers  étant présentés comme les anciens hameaux rejoints par
> l’urbanisation.
> C’est ce que j’applique depuis longtemps, aprés avoir mis des « hamlet »
> en ville.
>
>
> Christian R.
> ___
> 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] Faux positif d'Osmose sur l'identification de la ville

2018-01-18 Par sujet Christian Rogel 

> Le 18 janv. 2018 à 09:57, erwan salomon  a écrit :
> 
> salut,
> 
> si je comprend bien voici un cas similaire sans doute plus explicite :
> https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
> (avec la traduction bretonne dessous)
> ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite 
> autour : https://www.openstreetmap.org/way/176823228 )
> - [ attention village dans le language courant en bretagne désigne quelque 
> chose d’encore plus petit, ne jamais dire à un breton qu’il habite dans un 
> village il le prendra mal ]
> alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
> mais globalement ce sont 2 communes qui font partie d’une agglomération
> en tant que tel elles ont un nom et une adresse postale distincte (sinon il y 
> aurait des doublon de nom de rue)
> mais la gestion administrative se fait par l’agglomération (c’est la mairie 
> de Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les habitant de 
> Fort-Bloqué vote pour le maire de Plœmeur)
> un quartier c’est en général plus continu avec les quartiers voisins dans le 
> langage courant, mais l’agglomération peut en effet diviser sa surface en 
> quartier pour en répartir la gestion et procéder à des réunions de quartiers
> il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici c’est 
> l’inverse
> quand à la gestion par Osmose, la je suis incompétent pour te donner des 
> conseils

Sur le principe, il est correct de classer Fort-Bloqué dans la catégorie « 
village » (de 100 à 10 000 habitants en France, selon le dernier consensus) 
dans OSM, indépendamment de ce qu’en fait l’administration. L’obligation de lui 
adjoindre des codes et une population doit se limiter aux unités 
administratives définies par l’Etat, mais les collectivités peuvent à leur en 
définir et les publier.
Si une relation correspondant à une unité infra-communale officielle peut être 
tracée, tant mieux. Osmose doit prévoir ce genre de cas.

Sur la liste anglophone, on débat de « hamlet » et « neighbourhood », ces 
derniers  étant présentés comme les anciens hameaux rejoints par l’urbanisation.
C’est ce que j’applique depuis longtemps, aprés avoir mis des « hamlet » en 
ville.


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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

2018-01-18 Par sujet Charles MILLET 
C'est sûr que les deux exemples sont sans ambiguïtés mais au final on 
trouve beaucoup d'aménagements équivalents que je ne trouve pas plus 
ambiguë d’ailleurs l'illustration de la page footway ne comporte pas de 
panneau : https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway


Je comprends bien la tentation de s'appuyer sur des éléments concrets 
comme des panneaux mais je crois que je préfère encore débattre sur la 
nature d'un chemin et la pratique ;)


On 17/01/2018 18:35, marc marc wrote:

Bonsoir,

Le 17. 01. 18 à 15:19, Charles MILLET a écrit :

éviter les débats pour savoir si un voie est un footway ou un cycleway

ce serrait pourtant facile en se basant :
sur la largeur : trop étroit pour un véhicule -> path
sur les panneaux
footway
https://wiki.openstreetmap.org/wiki/File:Path-footdesignated.jpg
cycleway
https://wiki.openstreetmap.org/wiki/File:Path-bicycledesignated.jpg
et donc sans panneau ou vélo+piéton-> path


je ne sais pas elle fait consensus.

Hélas non.
https://wiki.openstreetmap.org/wiki/FR:Path_controversy
___
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] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

2018-01-18 Par sujet Charles MILLET 
J'aurais du creuser un peu, je vois que la page francophone dédiée 
living_street 
(https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street) 
cite cette relation.


On 18/01/2018 10:19, Charles MILLET wrote:

Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté 
de ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits 


https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 
n'est pas

nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de 
ne pas
se basé sur les spécificités locales pour considérer des valeurs 
implicites
de cette importance. Mais je voulais avoir vos avis avant d'en 
parler dans
la partie discussion ou directement avec le contributeur. Bon je 
pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas 
trouvé de

référence claire, ça pourra faire l'objet d'un rappel :)

--
Charles MILLET
charlesmil...@free.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

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

2018-01-18 Par sujet Charles MILLET 

Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté de 
ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
se basé sur les spécificités locales pour considérer des valeurs implicites
de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
la partie discussion ou directement avec le contributeur. Bon je pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
référence claire, ça pourra faire l'objet d'un rappel :)

--
Charles MILLET
charlesmil...@free.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] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

2018-01-18 Par sujet Charles MILLET 
En fait c'est la condition de la signalisation qui me gène un peu. Il y 
a tellement de voies, disons "piétonnes", qui n'ont aucune signalisation 
— une très large majorité selon mon ressenti — que je ne sais plus 
vraiment à quoi sert le highway=footway si ce n'est pour signaler qu'il 
y a un panneau. J'avais tendance à l'utiliser pour les aménagement 
dédiés aux piétons (même sans panneau explicite) et effectivement selon 
la pratique (plus ou moins observée ou ressenti) à préciser que les 
cyclistes y sont autorisés.


Ça ne me dérange pas vraiment d'utiliser path mais j'ai l'impression 
qu'on perd un peu de subtilité.


On 17/01/2018 21:00, Romain MEHUT wrote:

Bonsoir,

Je trouve au contraire que c'est le meilleur compromis quand il n'y a 
effectivement pas de signalisation en place.


C'est aussi à mon sens plus compréhensible que d'associer par exemple 
highway=footway + bicycle=yes.


Romain

Le 17 janvier 2018 à 15:19, Charles MILLET > a écrit :


Bonjour,

Je sais qu'il y a une discussion en cours concernant
spécifiquement les pistes cyclables sur les trottoirs et je ne
veux pas faire de doublon. Mais je voulais avoir votre avis sur
une récente modification de la page FR:Bicycle avant de contacter
le contributeur ou de discuter sur la page. Voici la page de
modification pour référence :

https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110



La modification concerne cette phrase dans la partie Voies
piétonnes partagées

(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es

)
:

"En l'absence d'indication de nature de la voie, utiliser
l'attribut highway
=path
 qui
autorise cyclistes et piétons à circuler ensemble"

Même si cette approche est assez commode car elle permet d'éviter
les débats pour savoir si un voie est un footway ou un cycleway,
je la trouve assez catégorique et je ne sais pas elle fait consensus.

-- 
Charles MILLET

charlesmil...@free.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] Faux positif d'Osmose sur l'identification de la ville

2018-01-18 Par sujet erwan salomon 
salut,

si je comprend bien voici un cas similaire sans doute plus explicite :
https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
(avec la traduction bretonne dessous)
ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite autour 
: https://www.openstreetmap.org/way/176823228 )
- [ attention village dans le language courant en bretagne désigne quelque 
chose d’encore plus petit, ne jamais dire à un breton qu’il habite dans un 
village il le prendra mal ]
alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
mais globalement ce sont 2 communes qui font partie d’une agglomération
en tant que tel elles ont un nom et une adresse postale distincte (sinon il y 
aurait des doublon de nom de rue)
mais la gestion administrative se fait par l’agglomération (c’est la mairie de 
Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les habitant de 
Fort-Bloqué vote pour le maire de Plœmeur)
un quartier c’est en général plus continu avec les quartiers voisins dans le 
langage courant, mais l’agglomération peut en effet diviser sa surface en 
quartier pour en répartir la gestion et procéder à des réunions de quartiers

il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici c’est 
l’inverse

quand à la gestion par Osmose, la je suis incompétent pour te donner des 
conseils

erwan [glyo]
 
> Le 18 janv. 2018 à 00:39, Sébastien Dinot  a écrit :
> 
> Bonsoir,
> 
> Ce soir, en voulant résoudre quelques erreurs qu'Osmose m'attribue parce
> que je suis le dernier contributeur à avoir modifié les objets en
> question, je suis tombé sur la zone suivante :
> 
> http://osmose.openstreetmap.fr/fr/map/#item=2060=18=44.664133=-0.848937=1,2,3=T
> 
> Comme vous le verrez, Osmose signale que la ville de Lacanau-de-Mios est
> inconnue au bataillon. Sur Wikipédia, il est effectivement indiqué que
> Lacanau-de-Mios est un quartier de Mios et non une ville :
> 
> https://fr.wikipedia.org/wiki/Mios
> 
> En outre, sur le site de la ville de Mios, Lacanau-de-Mios est
> explicitement indiqué comme étant un quartier de Mios :
> 
> http://www.villemios.fr/vivre-a-mios/les-conseils-de-quartier/
> 
> J'ai donc contacté le contributeur qui a ajouté ces adresses postales et
> il m'a répondu :
> 
> 1. Qu'il habite là-bas depuis quelques mois (il a eu la courtoisie de ne
>   pas l'exprimer ainsi mais il est donc bien mieux placé que moi pour
>   savoir quelle est l'adresse postale et donc, comment renseigner
>   l'attribut « addr:city »).
> 
> 2. Il m'a transmis un lien vers Google Street View où on voit clairement
>   un panneau de signalisation indiquant l'entrée dans l'agglomération
>   de « Lacanau de Mios » :
> 
>   https://goo.gl/maps/TEhQwaTkUKN2
> 
> Et là, le doute m'envahit. Qu'appelle-t-on une agglomération (zone
> urbaine comptant au moins 2000 habitants dont les habitations sont
> séparées de moins de 200 m) ? Existe-t-il des agglomérations qui ne sont
> pas des villes et des communes ? Il semblerait que oui à la lumière de
> cet exemple. Quid des panneaux de signalisation correspondants ? J'en
> viendrais presque à oublier Osmose qui, pour le coup, me semble faire
> erreur.
> 
> Qu'en pensez-vous ? Comment trancher ?
> 
> Sébastien
> 
> -- 
> Sébastien Dinot, sebastien.di...@free.fr
> http://sebastien.dinot.free.fr/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
> 
> ___
> 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