Re: [OSM-talk-fr] Imprimer un plan à partir d'OSM ?

2019-03-19 Par sujet Jean-Christophe Becquet 
Le 13/02/2019 18:49, pepilepi...@ovh.fr a écrit :
> Pour son prochain plan sur papier la municipalité de mon patelin
> aimerait avoir un rendu d'OSM. L'imprimeur veut un fichier jpeg, tif ou PDF.

Bonjour,

Il y a aussi StaticMapLite
https://wiki.openstreetmap.org/wiki/StaticMapLite

Qui est basé sur un logiciel libre sous licence Apache
https://github.com/dfacts/staticmaplite

Et bien que le serveur https://staticmap.openstreetmap.de ne supporte
pas les referrers en https, on peut quand même obtenir des images.

Bonne journée

JCB
-- 
Richard Stallman : Toutes les libertés dépendent des libertés informatiques
http://www.apitux.org/index.php?2006/04/19/158-richard-stallman-toutes-les-libertes-dependent-des-libertes-informatique

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [OSM-talk-fr] Places PMR ?

2019-03-19 Par sujet deuzeffe 

On 19/03/2019 09:11, Vincent Bergeot wrote:

donc cela donne pour une place de parking  PMR :

amenity=parking_space

parking_space=disabled

access:disabled=yes

capacity:disabled=1

et si l'accessibilité est réelle wheelchair=yes


ce que je trouve un peu complexe du coup.


Mais complet. C'est ce que je tente de faire aussi. En contradiction 
avec le wiki, qui dit, de mémoire, que parking_space doit être dans un 
amenity=parking. Si la discussion permet de lever cette restriction, qui 
est parfois en contradiction avec le terrain, je suis pour.


--
deuzeffe. Mes 2F (donc).

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

Re: [OSM-talk-fr] Vidéosurveillance

2019-03-19 Par sujet lmagreault 
Shohreh wrote
> J'ai surtout beoin de savoir /où/ se trouvent ces caméras.
> 
> Donc, légalement, la mairie n'a pas obligation de révéler leur emplacement
> ?

Bonjour,

Lors de l'installation ou la modification du système de vidéoprotection, la
mairie a dû faire en préfecture une demande d'autorisation d'installer un
système de videoprotection.

https://www.service-public.fr/particuliers/vosdroits/R13984
  

Parmi les pièces à joindre à la demande, il y a un plan de détail :
"Il s’agit d’un plan à une échelle suffisante montrant le nombre, le
positionnement des caméras ainsi que les zones couvertes par celles-ci."
ou un plan du périmètre :
"Il s’agit d’un document qui peut se substituer au plan de détails et au
plan de masse, montrant l’espace susceptible d’être situé dans le champ de
vision d’une ou plusieurs caméras dans le cas d’une demande portant sur un
périmètre à vidéoprotéger"

Source : 
https://www.formulaires.modernisation.gouv.fr/gf/getNotice.do?cerfaNotice=51336&cerfaFormulaire=13806

  

Si le dossier est complet, un récépissé est remis au demandeur. La demande
est examinée par la commission départementale de vidéoprotection puis le
préfet prend un arrêté autorisant l'installation.

Exemple : 
http://www.jura.gouv.fr/content/download/16387/121566/file/RAA_39-201812005_du_21_12_2018.pdf#anchor-24

  

Bref, tu peux demander à la mairie le dossier complet de demande
d'autorisation qui est, à mon sens, un document administratif.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

2019-03-19 Par sujet Florimond Berthoux 
Bonjour,

Je ne vois pas l'intérêt du opposite_* sur une route oneway=no, étant donné
qu'il n'existe pas de sens "opposite".
Opposite veut dire le sens contraire de la circulation générale, à ne pas
confondre avec le sens du way.

cycleway:left=opposite_lane
alias de :
cycleway:left=lane
oneway:bicycle=no
cycleway:left:oneway=-1 (si le sens du way = sens oneway général, sinon
'yes')
Donc ça aurait du sens d'avoir cycleway:left:oneway=opposite :D

et pour le cas du cycleway:left=lane
on considère par défaut que cycleway:left:oneway=left:oneway
left:oneway valant en France -1 par défaut et yes en Angleterre par exemple.


Le mar. 19 mars 2019 à 13:43, Charles MILLET  a
écrit :

> J'ai vu cette remarque aussi mais merci de la faire remonter ici.
>
> Je suis un peu partagé parce que j'ai déjà vu des cas où le
> opposite_lane était adapté et compréhensible même pour une route que
> n'est pas à sens unique ...bon il s'agissait peut-être d'un
> opposite_track mais je trouve que les différents « opposite » (si ils
> survivent à ces débats) devraient pouvoir suivre une même logique.
>
> J'ai un peu arrêté d'avoir une opinion ferme sur ces sujets, je crois
> qu'il y a globalement une bonne approche dans les différents schémas...
> mais bref je cherche surtout à identifier la solution qui fait le plus
> consensus et qui ne soit pas poussée par la personne qui râle le plus
> fort même si la solution qu'elle présente est très bonne.
>
> Charles MILLET
> charlesmil...@free.fr
>
> On 19/03/2019 11:10, marc marc wrote:
> > Le mer. 13 mars 2019 à 22:11, Charles MILLET
> >
> >> dans la pratique le opposite_lane est bien utilisé et parfaitement
> interprétable.
> > sur la ml tagging, une des critiques est que qui dit opposite_lane (les
> > vélos sont permis sur une bande dans le sens opposé au traffic),
> > dit que la route (pour les non-vélo) est en sens unique.
> > hors 6% de ces way n'ont pas le tag sens-unique.
> > pour couper l'herbe sous le pied de cette critique un peu légère (on ne
> > change pas de schéma parce qu'il y a qlq erreurs humaines) et améliorer
> > les données, Markus propose de les passer en revenue et de les corriger
> > (soit la rue n'est plus en sens unique et opposite_lane devient sans
> > doute lane, soit ajouter le tag manquant sens unique)
> > 181 pour la France http://overpass-turbo.eu/s/H9e
> > ___
> > 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
>


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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

2019-03-19 Par sujet Charles MILLET 

J'ai vu cette remarque aussi mais merci de la faire remonter ici.

Je suis un peu partagé parce que j'ai déjà vu des cas où le 
opposite_lane était adapté et compréhensible même pour une route que 
n'est pas à sens unique ...bon il s'agissait peut-être d'un 
opposite_track mais je trouve que les différents « opposite » (si ils 
survivent à ces débats) devraient pouvoir suivre une même logique.


J'ai un peu arrêté d'avoir une opinion ferme sur ces sujets, je crois 
qu'il y a globalement une bonne approche dans les différents schémas... 
mais bref je cherche surtout à identifier la solution qui fait le plus 
consensus et qui ne soit pas poussée par la personne qui râle le plus 
fort même si la solution qu'elle présente est très bonne.


Charles MILLET
charlesmil...@free.fr

On 19/03/2019 11:10, marc marc wrote:

Le mer. 13 mars 2019 à 22:11, Charles MILLET


dans la pratique le opposite_lane est bien utilisé et parfaitement 
interprétable.

sur la ml tagging, une des critiques est que qui dit opposite_lane (les
vélos sont permis sur une bande dans le sens opposé au traffic),
dit que la route (pour les non-vélo) est en sens unique.
hors 6% de ces way n'ont pas le tag sens-unique.
pour couper l'herbe sous le pied de cette critique un peu légère (on ne
change pas de schéma parce qu'il y a qlq erreurs humaines) et améliorer
les données, Markus propose de les passer en revenue et de les corriger
(soit la rue n'est plus en sens unique et opposite_lane devient sans
doute lane, soit ajouter le tag manquant sens unique)
181 pour la France http://overpass-turbo.eu/s/H9e
___
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] hebdoOSM Nº 451 2019-03-05-2019-03-11

2019-03-19 Par sujet theweekly . osm 
Bonjour,

Le résumé hebdomadaire n° 451 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11622/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet marc marc 
Le 19.03.19 à 12:03, Bernard Lefrançois a écrit :
> Est-ce que quelqu'un a un avis sur ma proposition d'utiliser le champs 
> [value] décrit dans le wiki/Key:traffic_sign
> "Where the traffic sign requires a value, you can supply it after the ID 
> using brackets |[value]|."
> traffic_sign=FR:EB20[Ville1];EB10[Ville2]

techniquement rien n’empêche d'ajouter le champ [value]

niveau "légal", je me demande si cela un sens (le panneau n'est
pas de type "FR:EB20[Ville1]"
quand on regarde 
https://taginfo.openstreetmap.org/keys/traffic_sign#values avec une 
recherche sur [
c'est surtout les vitesses qui sont renseignée.

au niveau pratique, il y a une majorité écrasante qui
renseigne l'effet du panneau (city_limit) au lieu de la ref officiel
du type de panneau

pour contenter tout le monde, on peux imaginer :
- traffic_sign=city_limit sur le way
- traffic_sign=FR:EB20[Ville1];EB10[Ville2] à l'endroit précis du poteau
même si je reste d'avis que les noms des agglos sont mieux renseigné
par un polygone d'aglomération (par ex boundary=urban et/ou place=city)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet Bernard Lefrançois 

Le 18/03/2019 à 23:02, deuzeffe a écrit :

Aucun avis sur la proposition (pas assez aguerrie, je suis).

En revanche, j'abonde avec le fait qu'on ne peut pas mettre 2x2 
panneaux sur le même nœud, et pourtant sur le terrain, de nombreux 
panneaux doubles sont pile face à face sur le bas-côté droit de chaque 
voie. Et comme je ne sais pas faire, je n'y ai pas touché dans ma zone.


Ben, pourquoi pas?

Dans ton cas, je suppose que tu places le nœud sur le highway.

Cas d'un panneau à 2 indications orienté dans un sens, et un autre 
panneau à 2 indications de l'autre côté de la route, orienté dans 
l'autre sens, tagués sur un seul nœud:


traffic_sign:forward=panneau1;panneau2
traffic_sign:backward=panneau3;panneau4


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

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet Bernard Lefrançois 



Le 19/03/2019 à 10:02, Jérôme Seigneuret a écrit :
Ou avec Mapillary : 
https://www.mapillary.com/app/?focus=photo&lat=47.79721754166424&lng=-3.4809542&z=17&pKey=RxO4q1ZookumCATmH2Ct3g&x=0.5334449075931347&y=0.3798607750491876&zoom=3. 

Je suis tombé sur le même cas mais avec sur le même poteau les entrées 
et sortie inverse.
Est-ce que quelqu'un a un avis sur ma proposition d'utiliser le champs 
[value] décrit dans le wiki/Key:traffic_sign
"Where the traffic sign requires a value, you can supply it after the ID 
using brackets |[value]|."


Je me suis posé la question si [value] pouvait être de type "string" 
mais je me dis pourquoi pas?

Dans la sémantique OSM on décrit bien un attribut par key=value
(value n'ayant pas un sens strict de Valeur numérique).

Car, en une seule ligne on dirait tout:

traffic_sign=FR:EB20[Ville1];EB10[Ville2]

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

Re: [OSM-talk-fr] Code officiel géographique de l'Insee

2019-03-19 Par sujet osm . sanspourriel 

Le 19/03/2019 à 11:28, Rpnpif - rpn...@trob.eu a écrit :


C'est quoi le nom normalisé ?

Le nom avec des tirets à la place des espaces.

Une norme (de fait ?) dont avait parlé Philippe Verdy entre autres dans
un message il y a quelques mois.


Christian parle aussi souvent de ce tiret cadratin.

Dans ce cas on est d'accord, tout comme mettre les accents sur les
majuscules.

Je me demandais si ça allait au delà style Le Bono/Bono.

Jean-Yvon

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

Re: [OSM-talk-fr] plusieurs traffic_sign sur un poteau

2019-03-19 Par sujet Rpnpif 
Le 18 mars 2019, marc marc a écrit :

> Le 18.03.19 à 21:36, Florimond Berthoux a écrit :
> > comment mettre plusieurs panneau sur un même nœud (un même poteau) ?
> > proposition:
> > traffic_sign:forward:1=toto
> > 1 étant l'ordre de haut en bas sur le poteau.  
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging#How_it_works._How_to_map
> propose :
> - un autre ordre traffic_sign:no:forward
> - pas de :1 pour le premier (ce qui permet au moins à celui là
> d'être utilisable par tous)
> - de mettre chaque panneau sur un nœud différent au même endroit (ce
> qui pose des soucis dans plusieurs éditeurs)
> 
> je me demande s'il y a la moindre app capable d'utiliser ce micro mapping.
> perso je préfère rester dans le schéma classique hors propal

Il y a déjà direction=* qui est bien pratique.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Code officiel géographique de l'Insee

2019-03-19 Par sujet Rpnpif 
Le 18 mars 2019, osm.sanspourr...@spamgourmet.com a écrit :

> >> Une discussion précédente avait dit qu'on mettait le nom normlsié dans
> >> name=* et le nom officiel dans official_name=*  
> 
> C'est quoi le nom normalisé ?

Le nom avec des tirets à la place des espaces.

Une norme (de fait ?) dont avait parlé Philippe Verdy entre autres dans
un message il y a quelques mois.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Les portes de Paris

2019-03-19 Par sujet djakk djakk 
Même problématique avec les stations de métro dont le nom defini le
quartier ;)

Les portes correspondent au carrefour sur les Maréchaux, en tout cas c’est
ce qu’indiquent les panneaux directionnels pour celles qui sont indiquées.

Julien « djakk »


Le mar. 19 mars 2019 à 10:44, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Globalement d'accord avec toi Althio.
> Je voudrais insister sur le fait qu'un point place=locality me semble pas
> suffisant du tout, où le placer ? sur le boulevard, sur le periph, sur les
> rails du tramway, aux arrêt de bus ?
> Historiquement c'était assez simple, la porte c'était la porte, un unique
> lieu de passage, aujourd'hui c'est plusieurs lieux.
>
> Finalement je me dis que la porte n'existant plus, la notion de porte est
> portée par ces dérivés : arrêt de bus/tram, bretelle de périph, avenue, si
> bien qu'on pourrait retirer le nœud place=locality.
> Et j'aime pas cette définition de locality "pas de population", alors que
> c'est évidemment faux pour les portes de Paris.
>
> Je ne sais quoi décider, ajouter un place=gateway ?
>
> (Ça va se terminer en changeant rien, mais on peut rajouter les quartiers
> importants tout de même :D)
>
> Le lun. 18 mars 2019 à 22:46, althio  a écrit :
>
>> Presque pareil que Jean-Yvon pour moi :
>>
>>> > Place=locality n'est pas un point, c'est un lieu sans habitant, les
>>> (quartiers) des "portes" de Paris sont maintenant habitées.
>>> Et actuellement personne n'habite sur une porte.
>>> Donc locality me va bien. Si par contre des quartiers s'appellent du nom
>>> de la porte d'à côté alors il faut mettre un contour et
>>> suburb/neighbourhood/quarter.
>>>
>>
>> Un point avec place=locality : très bien pour les véritables lieux des
>> "Portes".
>> Je préfère un point, mais à la limite pourquoi pas un polygone qui
>> englobe les voies, le carrefour, de manière très étroite, mais pas les
>> bâtiments.
>> C'est le point exact si on vise une navigation avec cette destination ou
>> un passage par ce point.
>>
>> Un point (ou un polygone qui englobe les habitations du quartier) avec
>> place=suburb/neighbourhood/quarter : si et seulement si il y a un véritable
>> quartier avec une existence locale, qui répond à ce nom.
>> Pour Porte d'Orléans, tout à fait, il me semble que c'est suffisamment
>> reconnu pour être un nom de quartier ("J'habite à Porte d'Orléans", en plus
>> des commerces, aménités et arrêts de transport en commun qui reprennent le
>> nom).
>> Il y aurait quand même un travail de recensement des portes et de leur
>> reconnaissance en tant que quartier, pour affecter le bon niveau de
>> place=suburb/neighbourhood/quarter aux lieux qui pourraient en
>> bénéficier... et puis estimer leur "centre" ou leur "périmètre".
>>
>> On Sun, 17 Mar 2019 at 11:13, djakk djakk  wrote:
>>
>>> Salut !
>>>
>>> Un peu perdu dans toutes les sous-discussions, j’en relance une :)
>>>
>>> C’est moi qui avait initié la cartographie des portes de Paris.
>>> Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux
>>> routiers. Mais certaines portes sont très proches les une des autres : si
>>> la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge
>>> toute proche n’en est pas un. Elle ferait partie du quartier « porte
>>> d’Orléans » .
>>>
>>> @+
>>> Julien « djakk »
>>> ___
>>> 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
>>
>
>
> --
> Florimond Berthoux
> ___
> 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] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

2019-03-19 Par sujet marc marc 
Le mer. 13 mars 2019 à 22:11, Charles MILLET

> dans la pratique le opposite_lane est bien utilisé et parfaitement 
> interprétable.

sur la ml tagging, une des critiques est que qui dit opposite_lane (les 
vélos sont permis sur une bande dans le sens opposé au traffic),
dit que la route (pour les non-vélo) est en sens unique.
hors 6% de ces way n'ont pas le tag sens-unique.
pour couper l'herbe sous le pied de cette critique un peu légère (on ne 
change pas de schéma parce qu'il y a qlq erreurs humaines) et améliorer 
les données, Markus propose de les passer en revenue et de les corriger 
(soit la rue n'est plus en sens unique et opposite_lane devient sans 
doute lane, soit ajouter le tag manquant sens unique)
181 pour la France http://overpass-turbo.eu/s/H9e
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les portes de Paris

2019-03-19 Par sujet Florimond Berthoux 
Globalement d'accord avec toi Althio.
Je voudrais insister sur le fait qu'un point place=locality me semble pas
suffisant du tout, où le placer ? sur le boulevard, sur le periph, sur les
rails du tramway, aux arrêt de bus ?
Historiquement c'était assez simple, la porte c'était la porte, un unique
lieu de passage, aujourd'hui c'est plusieurs lieux.

Finalement je me dis que la porte n'existant plus, la notion de porte est
portée par ces dérivés : arrêt de bus/tram, bretelle de périph, avenue, si
bien qu'on pourrait retirer le nœud place=locality.
Et j'aime pas cette définition de locality "pas de population", alors que
c'est évidemment faux pour les portes de Paris.

Je ne sais quoi décider, ajouter un place=gateway ?

(Ça va se terminer en changeant rien, mais on peut rajouter les quartiers
importants tout de même :D)

Le lun. 18 mars 2019 à 22:46, althio  a écrit :

> Presque pareil que Jean-Yvon pour moi :
>
>> > Place=locality n'est pas un point, c'est un lieu sans habitant, les
>> (quartiers) des "portes" de Paris sont maintenant habitées.
>> Et actuellement personne n'habite sur une porte.
>> Donc locality me va bien. Si par contre des quartiers s'appellent du nom
>> de la porte d'à côté alors il faut mettre un contour et
>> suburb/neighbourhood/quarter.
>>
>
> Un point avec place=locality : très bien pour les véritables lieux des
> "Portes".
> Je préfère un point, mais à la limite pourquoi pas un polygone qui englobe
> les voies, le carrefour, de manière très étroite, mais pas les bâtiments.
> C'est le point exact si on vise une navigation avec cette destination ou
> un passage par ce point.
>
> Un point (ou un polygone qui englobe les habitations du quartier) avec
> place=suburb/neighbourhood/quarter : si et seulement si il y a un véritable
> quartier avec une existence locale, qui répond à ce nom.
> Pour Porte d'Orléans, tout à fait, il me semble que c'est suffisamment
> reconnu pour être un nom de quartier ("J'habite à Porte d'Orléans", en plus
> des commerces, aménités et arrêts de transport en commun qui reprennent le
> nom).
> Il y aurait quand même un travail de recensement des portes et de leur
> reconnaissance en tant que quartier, pour affecter le bon niveau de
> place=suburb/neighbourhood/quarter aux lieux qui pourraient en
> bénéficier... et puis estimer leur "centre" ou leur "périmètre".
>
> On Sun, 17 Mar 2019 at 11:13, djakk djakk  wrote:
>
>> Salut !
>>
>> Un peu perdu dans toutes les sous-discussions, j’en relance une :)
>>
>> C’est moi qui avait initié la cartographie des portes de Paris.
>> Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux
>> routiers. Mais certaines portes sont très proches les une des autres : si
>> la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge
>> toute proche n’en est pas un. Elle ferait partie du quartier « porte
>> d’Orléans » .
>>
>> @+
>> Julien « djakk »
>> ___
>> 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
>


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

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet Jérôme Seigneuret 
Ou avec Mapillary :
https://www.mapillary.com/app/?focus=photo&lat=47.79721754166424&lng=-3.4809542&z=17&pKey=RxO4q1ZookumCATmH2Ct3g&x=0.5334449075931347&y=0.3798607750491876&zoom=3
.

Je suis tombé sur le même cas mais avec sur le même poteau les entrées et
sortie inverse.

C'est bien l'exemple que je souhaite mettre en avant.

Le lun. 18 mars 2019 à 21:37, marc marc  a
écrit :

> Le 18.03.19 à 21:16, Ralf Treinen a écrit :
> > On Mon, Mar 18, 2019 at 09:11:59PM +0100, Ralf Treinen wrote:
> >> On Mon, Mar 18, 2019 at 04:05:34PM +0100, Charles MILLET wrote:
> >>> Plutôt que name:in et name:out je crois que name:exit et name:entrance
> seraient
> >>> plus proche de ce que se fait déjà.
> >>
> >> Comment gérer le cas où le panneau est sur la frontière entre deux
> communes,
> >> c-a-d la sortie d'une commune est l'entrée de l'autre ?
> >
> > Désolé j'ai envoyé ce mail avant de voir la proposition de Bernard
> > de mapper dans ce cas deux panneaux différents.
>
> les exemples de Bernard sont des entrées/sortie d'agglomération,
> pas de commune.
> pour ma part je ne fais rien avec l'info commune,
> elle existe déjà dans la relation de la commune.
> mais c'est facilement ajouté dans le tag inscription=*
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

2019-03-19 Par sujet Vincent Bergeot 

Le 18/03/2019 à 20:49, marc marc a écrit :

Le 18.03.19 à 18:02, Vincent Bergeot a écrit :

je n'imagine pas amenity=parking_space, capacity=8 et capacity:disabled=2

et pourtant si tu n'as d'image sat pour faire + précis,
tu peux faire un polygone devant l'entrée d'un magasin
et mettre de mémoire qu'il y a plusieurs places dont 2 PMR.
je trouve que c'est une erreur de se baser sur un tag capacity
pour décrire une restriction d'accès.



effectivement dans ce cas j'ajoute plutôt amenity=parking capacity=8 et 
capacity:disabled=2


je ne fais pas des places de parkings dans ce cas. Je crois que cela 
vient vraiment de ma représentation des places de parkings en mode 
unitaire, et donc pour moi en fait c'est un parking quand il y a 
plusieurs places de parkings !!!






   * parking_space=disabled

je trouve ce tag ambigu donc peux utilisable.
il a été utilisé avant d'être définit précisément.
du coup tu ne sais pas si le contributeur a voulu renseigner
la restriction d'accès ou l'accessibilité réelle.



ok, pour moi c'est vraiment la restriction d'accès (comme il peut y 
avoir des places pour les familles, pour les voitures de locations, pour 
les co-voiturages, ...). Et pas du tout l'accessibilité réelle, qui dans 
le cas des PMR pourra être renseignée par wheelchair et autres.




et le site renseigné sur le wiki comme l'utilisant,
ne semble plus l'utiliser. ex
https://www.openstreetmap.org/node/1601704007
http://rollstuhlkarte.ch/?zoom=18&lat=47.36616&lon=8.53991&layers=B00FFTT
(la surcouche est en 404)
c'est pour moi un bon candidat à être déprécié en faveur
de tag + précis :) mais c'est le + courant :-(


ok, pourquoi pas !


à propos de la restriction d'accès (disabled ou access:disabled)
j'avais vu je ne sais plus où un argument sur le conflit de mettre
disabled dans le nom du tag parce que les tag d'accès à gauche (les
clefs) sont des moyens de transport tandis que les usages sont à droite
(en valeur).


cela voudrait dire par exemple access:car=disabled  et cela pourrait 
marcher aussi pour carpool, family, rental, ...


j'aime bien cette idée, si cela peut en plus s'inclure dans un schéma 
cohérent plus général




la conséquence de mixer des utilisateurs dans la partie gauche
se pose par exemple lorsqu'on veux renseigner une place avec double
condition : les places PMR d'un magasin access=destination + disable=yes
Selon la logique de tous les autres tag d'accès (ex access=destination
foot=yes), c'est permis si on respecte au moins une condition non
surchargée access=destination ou disable=yes
du coup tu ne sais pas décrire les conditions multiples.
la solution que j'avais vu et utilisé était :
access=no + access:conditional=designated␣@␣disabled (yes au lieu de
designated fait aussi l'affaire)
215 utilisations mondiales dont sans doute bcp de moi
https://taginfo.openstreetmap.org/tags/access%3Aconditional=designated%20%40%20disabled


whaou !!!




Du coup, je met pour le moment les 2 (parking_space=disabled et accces)
en plus des 2 autres (capacity et wheelchair) pour favoriser
l'utilisation des données, mais c'est vraiment pas top.


donc cela donne pour une place de parking  PMR :

amenity=parking_space

parking_space=disabled

access:disabled=yes

capacity:disabled=1

et si l'accessibilité est réelle wheelchair=yes


ce que je trouve un peu complexe du coup.

pour un vélo amenity=bicycle_parking, dommage que personne n'est pensé 
un disabled_parking


à plus

--
Vincent Bergeot


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