Re: [OSM-talk-fr] polygone pour représenter un trottoir

[djakk djakk]

Salut ! Moi je pense que tout est représentable sous forme de polygone,
mais qu’on a pas forcément le temps du coup on simplifie en ligne voire en
point. Reste le problème de la généralisation (la transformation du
polygone en ligne) qui impose peut être de faire polygone + ligne.

Julien « djakk »


Le sam. 27 avr. 2019 à 13:39, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> que pensez-vous de cette modélisation des trottoirs, sous la forme de
> multipolygones ?
>
> https://www.openstreetmap.org/relation/1979876
> https://www.openstreetmap.org/relation/1979878
>
> Je comprends qu'il soit tentant de micro-cartographier les trottoirs
> comme des polygones, mais je suis un peu sceptique.
>
> Le wiki est en tout cas formel, la représentation de ce type d'objet est
> normalement uniquement sous forme de chemin :
> https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway
>
> --
> nlehuby
>
>
> ___
> 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] Les portes de Paris

[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] Interdiction de tourner à gauche non respectée

[djakk djakk]

Marc, tu peux penser personnellement que ça n’est pas utile mais je ne
pense pas que tu puisses parler au nom de tous les contributeurs osm ... 樂

Julien « djakk »


Le dim. 17 mars 2019 à 20:45, marc marc  a
écrit :

> Le 17.03.19 à 16:01, djakk djakk a écrit :
> > Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est
> > pas du tout respectée. Comment le refléter dans openstreetmap ?
>
> comme un interdiction de tourner à gauche normale
> et puis t'ajoute un tag genre zuei=rezzrezw qui ne serra utilisé par
> personne mais qui permettra de te dire que t'as fait ton edit trollesque :)
> si tu veux croire que c'est utile, tu peux inventer un tag moins
> aléatoire genre respectducodedelaroute=rare
> ___
> 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 Santerre

[djakk djakk]

Est-ce que ça existe dans d’autres pays ? Des régions avec des frontières
non administratives ?

Julien « djakk »


Le dim. 17 mars 2019 à 20:11, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Salut,
>
> Dans le même genre, j'aimerai aussi ajouter La Thiérache, région naturelle
> et culturelle avec son fromage, son journal local, ses communautés de
> communes et sa page wikipedia :)
> https://fr.wikipedia.org/wiki/Thi%C3%A9rache
>
> utiliser place=county « A county - a geographical region of a country. » ?
>
>
> Le dim. 17 mars 2019 à 15:45, djakk djakk  a
> écrit :
>
>> Salut ! Le Santerre, un « petit pays » qui a son panneau touristique
>> marron sur l’autoroute A29 et sa page Wikipedia.
>> Le genre d’info non-administrative que j’aimerai avoir sur OpenStreetMap
>> ! :)
>>
>> Julien « djakk »
>>
> ___
>> 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] Interdiction de tourner à gauche non respectée

[djakk djakk]

Il ne s’agit pas d’une possibilité isolée mais d’une pratique courante
vérifiable facilement ...

Julien « djakk »


Le dim. 17 mars 2019 à 19:59, GarenKreiz  a écrit :

> Le jour où un conducteur utilisant OSM provoquera un accident mortel, pas
> sûr que cela fasse de la bonne publicité!
>
> Tant que nos véhicules sont conduits par de personnes dotées de libre
> arbitre et pouvant décider à tout moment de griller un feu rouge, couler un
> stop, rouler à contre sens, se stationner sur le trottoir, franchir une
> ligne blanche pour tourner, etc, il est sans doute inutile de noter dans
> OSM que les lois peuvent être contournées sur le terrain.
>
>
>
> On Sun, 17 Mar 2019 at 18:46, djakk djakk  wrote:
>
>>
>> Oui il faut cartographier d’un côté ce que veut l’administation et de
>> l’autre ce qui se passe en vrai. :)
>>
>> Arf ! Ça serait super si on pouvait faire un grand polygone pour faire un
>> héritage d’attributs ...
>>
>>
>> Julien « djakk »
>>
>>
>>
>> Le dim. 17 mars 2019 à 18:43, Léo El Amri via Talk-fr <
>> talk-fr@openstreetmap.org> a écrit :
>>
>>> On 17/03/2019 16:01, djakk djakk wrote:
>>> > Dans mon voisinage il y a une interdiction de tourner à gauche qui
>>> n’est
>>> > pas du tout respectée. Comment le refléter dans openstreetmap ?
>>>
>>> Hum... Est-ce qu'on devrait vraiment cartographier ça ?
>>>
>>> Parce que si oui, j'ai la moitié des intersections de Saint-Denis et
>>> autour à modifier ;)
>>>
>>> ___
>>> 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] Interdiction de tourner à gauche non respectée

[djakk djakk]

Oui il faut cartographier d’un côté ce que veut l’administation et de
l’autre ce qui se passe en vrai. :)

Arf ! Ça serait super si on pouvait faire un grand polygone pour faire un
héritage d’attributs ...


Julien « djakk »



Le dim. 17 mars 2019 à 18:43, Léo El Amri via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> On 17/03/2019 16:01, djakk djakk wrote:
> > Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est
> > pas du tout respectée. Comment le refléter dans openstreetmap ?
>
> Hum... Est-ce qu'on devrait vraiment cartographier ça ?
>
> Parce que si oui, j'ai la moitié des intersections de Saint-Denis et
> autour à modifier ;)
>
> ___
> 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] Interdiction de tourner à gauche non respectée

[djakk djakk]

althio me propose :

type=restriction
restriction=no_left_turn
except=*lawbreaker*
*informal=not_respected*

:)

Julien « djakk »


Le dim. 17 mars 2019 à 16:01, djakk djakk  a écrit :

> Salut !
>
> Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est
> pas du tout respectée. Comment le refléter dans openstreetmap ?
>
> Julien « djakk »
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Interdiction de tourner à gauche non respectée

[djakk djakk]

Salut !

Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est
pas du tout respectée. Comment le refléter dans openstreetmap ?

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

[OSM-talk-fr] Le Santerre

[djakk djakk]

Salut ! Le Santerre, un « petit pays » qui a son panneau touristique marron
sur l’autoroute A29 et sa page Wikipedia.
Le genre d’info non-administrative que j’aimerai avoir sur OpenStreetMap !
:)

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

[OSM-talk-fr] Les portes de Paris

[djakk djakk]

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

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

[djakk djakk]

Salut !

« Direction » c’est l’angle du panneau par rapport au Nord c’est ça ?

Name:in et name:out, bonne idée !

Julien « djakk »



Le sam. 16 mars 2019 à 13:44, Francescu GAROBY  a
écrit :

> Bonjour,
> D'où provient ce "name:2" ? C'est vous qui proposez ce nom de tag ? Je ne
> le trouve pas clair du tout !
> Je préférerais "name:in" / "name:out", pour indiquer dans quelle
> agglomération on entre/sort.
> "Direction", c'est pour indiquer la référence de la route sur laquelle on
> se trouve ? Pourquoi ne pas mettre plutôt le nom d'un village/une ville un
> peu importante, et se trouvant dans ladite direction ?
>
> Francescu
>
> Le ven. 15 mars 2019 à 17:46, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Salut,
>>
>> J'aimerai améliorer les affichage pour les panneaux d'entrée et sortie de
>> ville.
>>
>>
>> voici un cas  sur le même panneaux
>> direction=310
>> highway=traffic_sign
>> name:2=Jouy-en-Josas (sortie)
>> name=Les Loges-en-Josas (entrée)
>> traffic_sign=city_limit
>>
>> merci
>>
>> Jérôme
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Francescu
> ___
> 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] Les contours de la Bretagne

[djakk djakk]

Et que vas-tu faire de Montmartre qui appartient à moitié au quartier de
Clignancourt à moitié au quartier des grandes carrières (je pense que c’est
une dénomination typiquement administrative, que personne n'utilise ou ne
connais) ? 樂

Julien “djakk”


Le lun. 11 mars 2019 à 11:49, djakk djakk  a écrit :

> Et le rôle admin_center il est où du coup ?
>
> Julien “djakk”
>
>
> Le lun. 11 mars 2019 à 11:41, Romain MEHUT  a
> écrit :
>
>> "On" ? Sauf erreur, seul Florimond a discuté dans ce sens.
>>
>> Ce serait pareil encore pour
>> https://www.openstreetmap.org/relation/2195026 et
>> https://www.openstreetmap.org/node/2143885542 Dans les 2 cas, il s'agit
>> bien de définir un quartier (en plus le tag wikidata est identique) et si
>> on suit
>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element il
>> n'y a pas lieu d'y avoir deux objets.
>>
>> Romain
>>
>> Le lun. 11 mars 2019 à 11:09, djakk djakk  a
>> écrit :
>>
>>> Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets
>>> (administration contre habitude)
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le lun. 11 mars 2019 à 10:03, Romain MEHUT  a
>>> écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds
>>>> "Goutte d'Or" et "Clignancourt" conformément à ce principe
>>>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element
>>>>
>>>> Romain
>>>>
>>>> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux <
>>>> florimond.berth...@gmail.com> a écrit :
>>>>
>>>>> Je complète:
>>>>> « les 80 quartiers de Paris ont une définition précise pour leurs
>>>>> limites »
>>>>> définition qui a été arbitrairement décidé par une instance
>>>>> administrative, qui n'est même pas présente sur le terrain.
>>>>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme
>>>>> étant la Goutte d'Or ;)
>>>>> Donc non, au contraire c'est un bon exemple.
>>>>>
>>>>> Si le centre d'une région est mieux définit que ses limites extérieurs
>>>>> (ce qui est généralement le cas en histoire, les frontières bougent plus
>>>>> que le centre d'un territoire).
>>>>> Il me parait tout à fait opportun de modéliser cette région par son
>>>>> centre. Modélisation certes imparfaite mais qui permet tout de même de
>>>>> situer la chose sans trop de subjectivité.
>>>>>
>>>>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry <
>>>>> osm.v...@free.fr> a écrit :
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit :
>>>>>> > Bonjour,
>>>>>> >
>>>>>> > Utiliser un point et non un polygone, à placer à peu près au centre
>>>>>> de
>>>>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du
>>>>>> vrai
>>>>>> > centre :) ?
>>>>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la
>>>>>> Goutte
>>>>>> > D'or https://www.openstreetmap.org/node/2142414234
>>>>>>
>>>>>> Les quartiers de Paris ne sont pas un bon exemple ici, car
>>>>>> contrairement
>>>>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle
>>>>>> de
>>>>>> subjectivité et c'est bien le problème de ces limites), les 80
>>>>>> quartiers
>>>>>> de Paris ont une définition précise pour leurs limites, reprise par
>>>>>> 80
>>>>>> relations comme celle-ci :
>>>>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547
>>>>>>
>>>>>> Pour revenir à la question initiale pas sûr que boundary=historic
>>>>>> soit
>>>>>> pratique pour répondre, ça signifierait que chaque zonage correspond
>>>>>> à
>>>>>> un ancien découpage administratif. Je verrais plutôt une valeur de
>>>>>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi
>>>>>> correspondent les 161 relations boundary=traditional notamment.
>>>>>>
>>>>>> vincent
>>>>>>
>>>>>> ___
>>>>>> 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
>>>>
>>> ___
>>> 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] Les contours de la Bretagne

[djakk djakk]

Et le rôle admin_center il est où du coup ?

Julien “djakk”


Le lun. 11 mars 2019 à 11:41, Romain MEHUT  a
écrit :

> "On" ? Sauf erreur, seul Florimond a discuté dans ce sens.
>
> Ce serait pareil encore pour
> https://www.openstreetmap.org/relation/2195026 et
> https://www.openstreetmap.org/node/2143885542 Dans les 2 cas, il s'agit
> bien de définir un quartier (en plus le tag wikidata est identique) et si
> on suit
> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element il
> n'y a pas lieu d'y avoir deux objets.
>
> Romain
>
> Le lun. 11 mars 2019 à 11:09, djakk djakk  a
> écrit :
>
>> Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets
>> (administration contre habitude)
>>
>> Julien “djakk”
>>
>>
>> Le lun. 11 mars 2019 à 10:03, Romain MEHUT  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds "Goutte
>>> d'Or" et "Clignancourt" conformément à ce principe
>>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element
>>>
>>> Romain
>>>
>>> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux <
>>> florimond.berth...@gmail.com> a écrit :
>>>
>>>> Je complète:
>>>> « les 80 quartiers de Paris ont une définition précise pour leurs
>>>> limites »
>>>> définition qui a été arbitrairement décidé par une instance
>>>> administrative, qui n'est même pas présente sur le terrain.
>>>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme
>>>> étant la Goutte d'Or ;)
>>>> Donc non, au contraire c'est un bon exemple.
>>>>
>>>> Si le centre d'une région est mieux définit que ses limites extérieurs
>>>> (ce qui est généralement le cas en histoire, les frontières bougent plus
>>>> que le centre d'un territoire).
>>>> Il me parait tout à fait opportun de modéliser cette région par son
>>>> centre. Modélisation certes imparfaite mais qui permet tout de même de
>>>> situer la chose sans trop de subjectivité.
>>>>
>>>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry <
>>>> osm.v...@free.fr> a écrit :
>>>>
>>>>> Bonjour,
>>>>>
>>>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit :
>>>>> > Bonjour,
>>>>> >
>>>>> > Utiliser un point et non un polygone, à placer à peu près au centre
>>>>> de
>>>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du
>>>>> vrai
>>>>> > centre :) ?
>>>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la
>>>>> Goutte
>>>>> > D'or https://www.openstreetmap.org/node/2142414234
>>>>>
>>>>> Les quartiers de Paris ne sont pas un bon exemple ici, car
>>>>> contrairement
>>>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle de
>>>>> subjectivité et c'est bien le problème de ces limites), les 80
>>>>> quartiers
>>>>> de Paris ont une définition précise pour leurs limites, reprise par 80
>>>>> relations comme celle-ci :
>>>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547
>>>>>
>>>>> Pour revenir à la question initiale pas sûr que boundary=historic soit
>>>>> pratique pour répondre, ça signifierait que chaque zonage correspond à
>>>>> un ancien découpage administratif. Je verrais plutôt une valeur de
>>>>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi
>>>>> correspondent les 161 relations boundary=traditional notamment.
>>>>>
>>>>> vincent
>>>>>
>>>>> ___
>>>>> 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
>>>
>> ___
>> 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] Les contours de la Bretagne

[djakk djakk]

Effectivement à 10km de Paris on se présente “de Paris” à des gens qui ne
sont pas du tout du coin, pour simplifier. 珞

Julien “djakk”


Le lun. 11 mars 2019 à 11:26, marc marc  a
écrit :

> 2 points :
>
> - dans ce genre d'exemple hautement subjectif, je pense qu'il faut
> éviter les "on". untel pense que (y compris s'il est "local" au sens de
> source=local knownledge") mais pas "on" permettant de transformer chaque
> avis individuel en groupe (fictif ou non) partageant cet avis.
> cela gagnerait en visibilité.
>
> - faire 2 limites administrations <> habitude, franchement j'en vois pas
> l'avantage et c'est surtout hautement subjectif.
> le gars en bordure mais hors de Paris se considère dans Paris ?
> allez hop un place=subjective_truc pour paris, pour la métropole,
> pour l’arrondissement, etc
> et puis finalement je trouve que je fais partie du prolongement de la
> rue d'avant parce que je suis pas d'accord sur le changement de nom de
> la rue il y a 10 ans,allez hop encore petit truc pour dire que je
> conteste l'administration...
> Parce que si ton voisin lui trouve que la limite est une rue + loin,
> il a lui aussi le droit de faire une nouvelle relation
> place=mon_ressenti_des_limites_de_paris non ?
> bienvenu dans OpenAnachiMap...
>
> Le 11.03.19 à 11:07, djakk djakk a écrit :
> > Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets
> > (administration contre habitude)
> >
> > Julien “djakk”
> >
> >
> > Le lun. 11 mars 2019 à 10:03, Romain MEHUT  > <mailto:romain.me...@gmail.com>> a écrit :
> >
> > Bonjour,
> >
> > Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds
> > "Goutte d'Or" et "Clignancourt" conformément à ce principe
> > https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element
> >
> > Romain
> >
> > Le dim. 10 mars 2019 à 23:38, Florimond Berthoux
> > mailto:florimond.berth...@gmail.com>>
> > a écrit :
> >
> > Je complète:
> > « les 80 quartiers de Paris ont une définition précise pour
> > leurs limites »
> > définition qui a été arbitrairement décidé par une instance
> > administrative, qui n'est même pas présente sur le terrain.
> > Un parisien ne parlera par de l'ouest de la porte de la Chapelle
> > comme étant la Goutte d'Or ;)
> > Donc non, au contraire c'est un bon exemple.
> >
> > Si le centre d'une région est mieux définit que ses limites
> > extérieurs (ce qui est généralement le cas en histoire, les
> > frontières bougent plus que le centre d'un territoire).
> > Il me parait tout à fait opportun de modéliser cette région par
> > son centre. Modélisation certes imparfaite mais qui permet tout
> > de même de situer la chose sans trop de subjectivité.
> >
> > Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry
> > mailto:osm.v...@free.fr>> a écrit :
> >
> > Bonjour,
> >
> > Le 10/03/2019 à 17:49, Florimond Berthoux a écrit :
> >  > Bonjour,
> >  >
> >  > Utiliser un point et non un polygone, à placer à peu près
> > au centre de
> >  > la région (en espérant qu'il n'y ai pas une guerre de
> > religion du vrai
> >  > centre :) ?
> >  > C'est ce qui est fait pour les quartiers de Paris, par
> > exemple la Goutte
> >  > D'or https://www.openstreetmap.org/node/2142414234
> >
> > Les quartiers de Paris ne sont pas un bon exemple ici, car
> > contrairement
> > aux régions vécues, dont chacun a sa propre limite
> > (Marc_marc parle de
> > subjectivité et c'est bien le problème de ces limites), les
> > 80 quartiers
> > de Paris ont une définition précise pour leurs limites,
> > reprise par 80
> > relations comme celle-ci :
> >
> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547
> >
> > Pour revenir à la question initiale pas sûr que
> > boundary=historic soit
> > pratique pour répondre, ça signifierait que chaque zonage
> > correspond à
> > un ancien découpage administratif. Je verrais plutôt une
> > valeur de
> > boundary

Re: [OSM-talk-fr] Les contours de la Bretagne

[djakk djakk]

Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets
(administration contre habitude)

Julien “djakk”


Le lun. 11 mars 2019 à 10:03, Romain MEHUT  a
écrit :

> Bonjour,
>
> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds "Goutte
> d'Or" et "Clignancourt" conformément à ce principe
> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element
>
> Romain
>
> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>> Je complète:
>> « les 80 quartiers de Paris ont une définition précise pour leurs limites
>> »
>> définition qui a été arbitrairement décidé par une instance
>> administrative, qui n'est même pas présente sur le terrain.
>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme
>> étant la Goutte d'Or ;)
>> Donc non, au contraire c'est un bon exemple.
>>
>> Si le centre d'une région est mieux définit que ses limites extérieurs
>> (ce qui est généralement le cas en histoire, les frontières bougent plus
>> que le centre d'un territoire).
>> Il me parait tout à fait opportun de modéliser cette région par son
>> centre. Modélisation certes imparfaite mais qui permet tout de même de
>> situer la chose sans trop de subjectivité.
>>
>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry <
>> osm.v...@free.fr> a écrit :
>>
>>> Bonjour,
>>>
>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit :
>>> > Bonjour,
>>> >
>>> > Utiliser un point et non un polygone, à placer à peu près au centre de
>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du vrai
>>> > centre :) ?
>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la
>>> Goutte
>>> > D'or https://www.openstreetmap.org/node/2142414234
>>>
>>> Les quartiers de Paris ne sont pas un bon exemple ici, car contrairement
>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle de
>>> subjectivité et c'est bien le problème de ces limites), les 80 quartiers
>>> de Paris ont une définition précise pour leurs limites, reprise par 80
>>> relations comme celle-ci :
>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547
>>>
>>> Pour revenir à la question initiale pas sûr que boundary=historic soit
>>> pratique pour répondre, ça signifierait que chaque zonage correspond à
>>> un ancien découpage administratif. Je verrais plutôt une valeur de
>>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi
>>> correspondent les 161 relations boundary=traditional notamment.
>>>
>>> vincent
>>>
>>> ___
>>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les contours de la Bretagne

[djakk djakk]

Il n’y a de source valide que le cœur des habitants ... et les journaux
locaux aussi.

Julien “djakk”


Le dim. 10 mars 2019 à 13:38, marc marc  a
écrit :

> commencer par trouver une source valide ? :)
> il y boundary=historic pour les renseigner
>
> Le 10.03.19 à 12:49, djakk djakk a écrit :
> > Salut !
> >
> > Moi j’aimerai bien tagger les “petits pays” dans osm ! La Bretagne
> > historique, le Tregor, le Vercors. Ça n’est pas basé sur des limites
> > administratives.
> >
> > Des idées ?
> >
> > Julien “djakk”
> >
> >
> > Le sam. 9 mars 2019 à 15:34,  > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
> >
> > Merci Antoine
> >
> > Le 09/03/2019 à 15:18, Rpnpif - rpn...@trob.eu
> > <mailto:rpn...@trob.eu> a écrit :
> >> Les limites
> >> historiques pourraient éventuellement être mises avec un tag
> historic ou
> >> quelque chose comme ça.
> >
> > C'est dans ce sens que je proposais de créer une relation Bretagne a
> > 5 départements avec un end_date : ça permet d'avoir la version
> > historique de la Bretagne sans entrer en compétition avec la région
> > Bretagne qui ne comporte que 4 des 5 départements ;-). Et en mettant
> > des subareas plutôt d'un tracé linéaire afin de ne créer qu'une
> > relation à 5 membres et non créer une autre relation difficilement
> > maintenable. Après pour afficher il suffit de tenir compte de la
> > date de validité de la relation.
> >
> > Pas la Crimée ? Bah, il y en a bien qui veulent faire Paimbœuf
> > traverser la Loire ^^. Et ils n'ont pas forcément tort.
> >
> > Jean-Yvon
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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] Les contours de la Bretagne

[djakk djakk]

Salut !

Moi j’aimerai bien tagger les “petits pays” dans osm ! La Bretagne
historique, le Tregor, le Vercors. Ça n’est pas basé sur des limites
administratives.

Des idées ?

Julien “djakk”


Le sam. 9 mars 2019 à 15:34,  a écrit :

> Merci Antoine
> Le 09/03/2019 à 15:18, Rpnpif - rpn...@trob.eu a écrit :
>
> Les limites
> historiques pourraient éventuellement être mises avec un tag historic ou
> quelque chose comme ça.
>
> C'est dans ce sens que je proposais de créer une relation Bretagne a 5
> départements avec un end_date : ça permet d'avoir la version historique de
> la Bretagne sans entrer en compétition avec la région Bretagne qui ne
> comporte que 4 des 5 départements ;-). Et en mettant des subareas plutôt
> d'un tracé linéaire afin de ne créer qu'une relation à 5 membres et non
> créer une autre relation difficilement maintenable. Après pour afficher il
> suffit de tenir compte de la date de validité de la relation.
>
> Pas la Crimée ? Bah, il y en a bien qui veulent faire Paimbœuf traverser
> la Loire ^^. Et ils n'ont pas forcément tort.
>
> Jean-Yvon
> ___
> 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] Une nouvelle manière de tagger les routes

[djakk djakk]

Voilà ! Je ferai une proposition tag par tag.

Julien “djakk”


Le dim. 3 mars 2019 à 20:00, PanierAvide  a écrit :

> Bonsoir,
>
> Merci pour les exemples, c'est plus explicite. La suite c'est de faire une
> proposition formelle pour chacun des tags ? Ça permettrait de voir ce qui
> passe ou pas au niveau international ;-)
>
> Cordialement,
>
> Adrien P.
>
> Le 03/03/2019 à 18:53, djakk djakk a écrit :
>
> Salut !
>
> J’ai mis à jour la page :
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
>
> Avec quelques exemples, un tordu et 2 normaux
>
> Nouveauté : une séparation de la classification locale et de la
> classification régionale.
>
>
> Julien “djakk”
>
>
> Le mar. 26 févr. 2019 à 16:01, djakk djakk  a
> écrit :
>
>> Bonne question au sujet de la relativité, entre les rues de New York et
>> les routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada
>> en « piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires
>> de New York qu’à partir de zoom=12.
>> Il faut des attributs pour ça : « importance » et « surface » seraient
>> suffisants. « Highway » ne me serait pas utile dans ce cas.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 26 févr. 2019 à 14:58, marc marc  a
>> écrit :
>>
>>> je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des
>>> infos dans un schéma, l'autre moitié dans l'autre et une partie des
>>> infos incohérente entre 2 schémas qui coexisterait pendant 10 ans.
>>>
>>> je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton
>>> problème, si le trunk japonais permet le piéton et l'européen non.
>>> pour résoudre cela il y a la propal des valeur par défaut (avoir le
>>> contenu de la page wiki dans des relations par pays voir régions
>>> afin que chaque outil ne doivent plus réinventer la roue pour
>>> les récupérer)
>>>
>>> le problème no 1 est peut-être de définir le besoin.
>>> la propal parle d'un rendu différent entre la première photo
>>> et la 2ieme.
>>> j'attends de voir les valeurs des tags et des sources sur les exemples
>>> proposés pour voir un peu + clair sur ce qui n'est pas possible
>>> avec les tags actuels pour les ways routier (pour les autres il est
>>> vrai qu'il y a moins de niveau différent et de critères pertinent)
>>>
>>> Le 26.02.19 à 14:18, Florimond Berthoux a écrit :
>>> > Bonjour,
>>> >
>>> > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait
>>> > rudement pratique pour les utilisateurs des données que les tags
>>> soient
>>> > universels.
>>> > Parce que là concrètement si je veux faire une carte pour cycliste (à
>>> > tout hasard ;) je dois m'amuser à parser la page du wiki
>>> >
>>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction
>>> > pour connaitre la cyclabilité des trunks et faire un code spécifique
>>> > pour chaque région. Ça devient lourd.
>>> >
>>> > Le mar. 26 févr. 2019 à 13:21, >> > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
>>> >
>>> > Bonjour,
>>> >
>>> > Le cas du public_transport v2 est un "bon" précédent au même titre
>>> > que la privatisation du rail en Grande-Bretagne : l'exemple à ne
>>> pas
>>> > suivre.
>>> >
>>> > Si on veut que trunk soient les voies express/rapides actuellement
>>> > limitées à 110 km/h, il suffit de se mettre d'accord.
>>> >
>>> > Changer de modèle parce qu'un attribut n'est pas utilisé en France
>>> > comme ailleurs ça n'a aucun sens.
>>> >
>>> > Jean-Yvon
>>> >
>>> > --
>>> > 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
>>>
>>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Une nouvelle manière de tagger les routes

[djakk djakk]

Salut !

J’ai mis à jour la page :
https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads

Avec quelques exemples, un tordu et 2 normaux

Nouveauté : une séparation de la classification locale et de la
classification régionale.


Julien “djakk”


Le mar. 26 févr. 2019 à 16:01, djakk djakk  a écrit :

> Bonne question au sujet de la relativité, entre les rues de New York et
> les routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada
> en « piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires
> de New York qu’à partir de zoom=12.
> Il faut des attributs pour ça : « importance » et « surface » seraient
> suffisants. « Highway » ne me serait pas utile dans ce cas.
>
> Julien « djakk »
>
>
> Le mar. 26 févr. 2019 à 14:58, marc marc  a
> écrit :
>
>> je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des
>> infos dans un schéma, l'autre moitié dans l'autre et une partie des
>> infos incohérente entre 2 schémas qui coexisterait pendant 10 ans.
>>
>> je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton
>> problème, si le trunk japonais permet le piéton et l'européen non.
>> pour résoudre cela il y a la propal des valeur par défaut (avoir le
>> contenu de la page wiki dans des relations par pays voir régions
>> afin que chaque outil ne doivent plus réinventer la roue pour
>> les récupérer)
>>
>> le problème no 1 est peut-être de définir le besoin.
>> la propal parle d'un rendu différent entre la première photo
>> et la 2ieme.
>> j'attends de voir les valeurs des tags et des sources sur les exemples
>> proposés pour voir un peu + clair sur ce qui n'est pas possible
>> avec les tags actuels pour les ways routier (pour les autres il est
>> vrai qu'il y a moins de niveau différent et de critères pertinent)
>>
>> Le 26.02.19 à 14:18, Florimond Berthoux a écrit :
>> > Bonjour,
>> >
>> > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait
>> > rudement pratique pour les utilisateurs des données que les tags soient
>> > universels.
>> > Parce que là concrètement si je veux faire une carte pour cycliste (à
>> > tout hasard ;) je dois m'amuser à parser la page du wiki
>> >
>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction
>> > pour connaitre la cyclabilité des trunks et faire un code spécifique
>> > pour chaque région. Ça devient lourd.
>> >
>> > Le mar. 26 févr. 2019 à 13:21, > > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
>> >
>> > Bonjour,
>> >
>> > Le cas du public_transport v2 est un "bon" précédent au même titre
>> > que la privatisation du rail en Grande-Bretagne : l'exemple à ne pas
>> > suivre.
>> >
>> > Si on veut que trunk soient les voies express/rapides actuellement
>> > limitées à 110 km/h, il suffit de se mettre d'accord.
>> >
>> > Changer de modèle parce qu'un attribut n'est pas utilisé en France
>> > comme ailleurs ça n'a aucun sens.
>> >
>> > Jean-Yvon
>> >
>> > --
>> > 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
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes

[djakk djakk]

Bonne question au sujet de la relativité, entre les rues de New York et les
routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada en «
piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires de New
York qu’à partir de zoom=12.
Il faut des attributs pour ça : « importance » et « surface » seraient
suffisants. « Highway » ne me serait pas utile dans ce cas.

Julien « djakk »


Le mar. 26 févr. 2019 à 14:58, marc marc  a
écrit :

> je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des
> infos dans un schéma, l'autre moitié dans l'autre et une partie des
> infos incohérente entre 2 schémas qui coexisterait pendant 10 ans.
>
> je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton
> problème, si le trunk japonais permet le piéton et l'européen non.
> pour résoudre cela il y a la propal des valeur par défaut (avoir le
> contenu de la page wiki dans des relations par pays voir régions
> afin que chaque outil ne doivent plus réinventer la roue pour
> les récupérer)
>
> le problème no 1 est peut-être de définir le besoin.
> la propal parle d'un rendu différent entre la première photo
> et la 2ieme.
> j'attends de voir les valeurs des tags et des sources sur les exemples
> proposés pour voir un peu + clair sur ce qui n'est pas possible
> avec les tags actuels pour les ways routier (pour les autres il est
> vrai qu'il y a moins de niveau différent et de critères pertinent)
>
> Le 26.02.19 à 14:18, Florimond Berthoux a écrit :
> > Bonjour,
> >
> > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait
> > rudement pratique pour les utilisateurs des données que les tags soient
> > universels.
> > Parce que là concrètement si je veux faire une carte pour cycliste (à
> > tout hasard ;) je dois m'amuser à parser la page du wiki
> >
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction
> > pour connaitre la cyclabilité des trunks et faire un code spécifique
> > pour chaque région. Ça devient lourd.
> >
> > Le mar. 26 févr. 2019 à 13:21,  > > a écrit :
> >
> > Bonjour,
> >
> > Le cas du public_transport v2 est un "bon" précédent au même titre
> > que la privatisation du rail en Grande-Bretagne : l'exemple à ne pas
> > suivre.
> >
> > Si on veut que trunk soient les voies express/rapides actuellement
> > limitées à 110 km/h, il suffit de se mettre d'accord.
> >
> > Changer de modèle parce qu'un attribut n'est pas utilisé en France
> > comme ailleurs ça n'a aucun sens.
> >
> > Jean-Yvon
> >
> > --
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes

[djakk djakk]

Marc, le “trunk” anglais (et japonais) n’est pas du tout le même qu’en
France, il correspond à une classification administrative, la plus forte
avant les autoroutes. Il peut très bien s’appliquer à une grosse route
classique ou à un grand boulevard d’une ville.

Marc, j’avais mis des sources quand j’ai modifié les highway bretons en
fonction du trafic (les cartes de trafic par département). Sans ça c’etait
souvent Départementale = secondary.

Adrien, il y aura beaucoup de valeurs par défaut, donc j'espère que grâce à
ça ça ne tournera pas à l’usine à gaz.

Oui je vais mettre des exemples.


@+
Julien djakk


Le lun. 25 févr. 2019 à 20:09, PanierAvide  a
écrit :

> Bonjour,
>
> Je suis un peu partagé, autant certains aspects ont du sens (un système
> admin_level-like pour les routes c'est intéressant), autant d'autres
> aspects vont vite tourner à la même situation qu'actuellement  avec
> highway=* (tag importance, c'est plus flou la frontière entre routes
> qu'entres voies ferrées où le réseau est plus "segmenté").
>
> Ma crainte c'est que ça finisse comme la proposition des tags
> public_transport=* : une bonne idée au départ, un bazar en pratique car les
> outils ne suivent pas (ou qu'à moitié). Ceci étant comme proposait marc, ça
> vaudrait le coup de documenter des exemples pour voir ce que ça donnerait
> concrètement.
>
> Cordialement,
>
> Adrien P.
>
> Le 25/02/2019 à 19:28, djakk djakk a écrit :
>
> Salut ! J’ai planché sur une nouvelle manière de tagger les routes (au
> sens large, ça comprend les pistes cyclables ou les chemins piétons) :
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
> (en anglais)
> J’en parle aussi sur la mailing-list tagging mondiale.
>
> J’attend vos réactions, critiques, nouvelles idées ;-)
>
> @+
> Julien “djakk”
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Une nouvelle manière de tagger les routes

[djakk djakk]

Salut ! J’ai planché sur une nouvelle manière de tagger les routes (au sens
large, ça comprend les pistes cyclables ou les chemins piétons) :
https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
(en anglais)
J’en parle aussi sur la mailing-list tagging mondiale.

J’attend vos réactions, critiques, nouvelles idées ;-)

@+
Julien “djakk”
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Origine des données Waze

[djakk djakk]

J’ai remarqué ça aussi, un parking assez tordu à mapper s’est retrouvé
identique dans waze. Par contre pas ceux à côté.

Julien « djakk »


Le mar. 22 janv. 2019 à 09:55, Nicolas Moyroud  a écrit :

> Bonjour,
>
> De même que Gwenaël je suis totalement opposé à l'idée d'introduire des
> "oeufs de pâques" dans OSM. Dans mes présentations d'OSM que je fais aux
> étudiants en géomatique, je ne me prive d'ailleurs pas pour dénigrer ces
> pratiques chez les producteurs de données géographiques propriétaires.
> C'est d'ailleurs un point qui les étonne, la plupart ne sont absolument
> pas au courant de ce genre de pratiques.
>
> Par contre le fait d'avoir des informations tellement détaillées (comme
> les chemins privés) qu'on puisse être quasiment sûrs qu'elles
> proviendraient d'OSM, là on est tout à fait dans l'esprit !
>
> Nicolas
>
> Le 21/01/2019 à 19:52, Gwenaël Jouvin via Talk-fr a écrit :
> > Bonsoir,
> >
> > Je fais une petite digression sur les « œufs de pâques », à mon avis il
> n’est pas acceptable de placer de fausses informations dans OSM puisque
> d’après ce que j’ai compris (ou comme je vois ce projet ;-) ), OSM se doit
> d’être la plus exacte possible, justement pour se démarquer des cartes
> commerciales ou privatives qui regorgent de ces pièges contre la
> contrefaçon.
> >
> > Par contre j’aime beaucoup l’idée de placer des chemins privés, il y en
> existe d’ailleurs déjà et ce sont des informations pertinentes afin de
> s’assurer que tel ou tel trajet est réalisable ou non.
> >
> > Gwenaël
>
> ___
> 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] Plus code grid service

[djakk djakk]

Well, it is possible for a human to memorize it :)

Julien « djakk »


Le lun. 19 nov. 2018 à 17:22, Mateusz Konieczny  a
écrit :

> It is still not clear to me why new way of writing latitude and longitude
> is supposed to be interesting.
>
> 19. Nov 2018 16:43 by drinc...@google.com:
>
> We're really excited to launch a free plus code grid service at
> https://grid.plus.codes
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

That is something that OSM should map instead of the official timetable :)

In Paris it is almost the same case, the bus does not follow their official
timetable due to grid locks.

Julien « djakk »


Le mer. 7 nov. 2018 à 00:16, Martin Koppenhoefer  a
écrit :

>
>
> sent from a phone
>
> > On 6. Nov 2018, at 15:41, djakk djakk  wrote:
> >
> > Martin, maybe locals do know their bus stop timetable, as they always
> use the service they may memorize the schedules ... ?
>
>
> there are no timetables and the service is notoriously bad and infrequent,
> while management scandals are frequent. This weekend there will be a
> referendum about closing the public company and procurement by tender.
>
> Cheers, Martin
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

For example in Japan transit companies sells their timetable for about
1000€ ... maybe copying the timetable is forbidden but Osm can have at
least an opening hour and a frequency for a line in Japan.
An other example, the city of Accra (Ghana) : only share taxis, no transit
authority, lines are already mapped in OSM, with a travel time and a
frequency.

Julien « djakk »


Le mer. 7 nov. 2018 à 14:37, Jonathon Rossi  a écrit :

> I've been following along the few threads to better understand this topic,
> however I'm still feeling that mapping complex timetables is a bit like
> mapping the full menu of a cafe or restaurant, or the room options at a
> hotel. These things vary whenever the service business chooses and it is
> close to impossible to keep it up to date.
>
> In Brisbane Australia, some PT timetables vary often especially with
> public holidays (local, state or federal), school holidays (which differ
> between schools) and especially with special events (sporting, concerts,
> etc). Sometimes timetables get more trips sometimes less, it can be quite
> variable throughout the year and not something that can be 100% codified
> into timetable rules, and obviously not known too far in advance.
>
> I appreciate that timetables are very useful for consumers of maps, and
> understand that in some cities timetables can be reverse engineered by
> being somewhat observable (I would think copying a full timetable off a
> sign would classify as an import), however are we concerned that this adds
> a massive burden to maintain this data in OSM and it is very likely to
> always be out of date? If it is always going to be out of date will any app
> developer even integrate this data into their app when they can use GTFS
> feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of
> either application been consulted?
>
> Having this data embedded in the OSM tags also forces apps to reduce their
> map cache duration to try to get more updated timetables.
>
> I'm not very experienced with PT in OSM, but I'd have thought improving
> the tags for mapping objects to GTFS feeds, including the GTFS endpoints
> and license info as tags, and maybe then adding the ability to discover the
> GTFS Realtime extension would be the way to go. I think this would give
> much more power to app developers. It does overlap a little with
> Transitland, but obviously OSM wouldn't be polling or hosting the feeds,
> that would be up to an application developer.
>
> Happy to hear any feedback if I've missed the point of this.
>
> On Tue, Nov 6, 2018 at 2:07 AM Jo  wrote:
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started creating
>> a new one. It differs in rather important ways from your proposal, so I
>> preferred not modifying your wiki page. I also think it's important to
>> decouple the (voting for a) full timetable solution from the solution where
>> tags are added to indicate interval during 'opening_hours' or a route,
>> which is a lot more likely to be accepted.
>>
>> So here goes:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> Please let me know what you think. What I still haven't figured out yet
>> is how to differ weekdays that fall in school holiday periods from "normal"
>> weekdays. So work in progress.
>>
>> Polyglot
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> --
> Jono
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Hello !

Ok for a google hangout ! I’m also available tonight and on Friday evening.

Julien « djakk »


Le mer. 7 nov. 2018 à 12:53, Jo  a écrit :

> Hi Tony,
>
> Could you also have a look at the proposal I created?
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> At the moment I'm looking into how to represent that in meaningful ways
> using MapCSS in JOSM, but I don't think that makes too much sense.
>
> For your use case where you want to do routing. The timetable relations
> give the possibility to calculate when a bus passes at a particular stop at
> a given time of day. And it's possible to see how long it takes to get from
> there to another stop or calculate at what time one arrives there. For
> complex routing involving transfers this will involve quite a bit of
> recursion, but it should be feasible.
>
> At the moment I'm looking how this can be rendered in meaningful ways and
> how data entry can be made as convenient as possible. (I think we need
> spreadsheet like functionality to accomplish that, I made an attempt here:
> https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
> .
> But we need more possibilities for indicating where a specific time on the
> schedule came from.
>
> Right now I have the following:
>
> Line (route_master relation)
>contains several:
>  Itineraries composes of (longest) stop sequences including ways
> (route relation)
> if referred to by 1 or more
>Actual stop sequences with time deltas (timetable relation)
>The stops in these relations are always a subset of the
> referre route relation
>
> I would also include a public_holidays relation in each route_master
> relation to avoid duplication but still enable which days get Sunday
> schedules and which days are in school holiday periods.
>
>
> If anyone feels like doing a Google Hangout to discuss this, let me know.
> I have time tonight and Friday evening
>
> Polyglot
>
> Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :
>
>> Hi
>>
>> I have worked in data analysis for many years, recently become interested
>> in PT and added routes to my locality. I look at PT timetables frequently
>> as much of my travel is by PT.
>>
>> My use case is that I want to find times and routes from A to B, I do not
>> know the route numbers or their actual route. I expect the system to be
>> able to give times and routes and any interchanges.
>>
>> As a system I fail to see how putting the timing detail on each stop will
>> enable me to efficiently perform that use case. From what is described
>> system would have to identify route, then iterate route to check if
>> destination is on route, if on route then  select time entry in A then a
>> time entry in B and ASSUME that they both relate to the same journey and
>> have been updated correctly. For connections/interchanges the same rules
>> apply. Those assumptions make storing the data against a stop
>> extraordinarily unreliable, the proposed method does not take shortened
>> journeys - eg school or factory journeys where the whole route is not
>> travelled  - into account.
>>
>> I suggest that the best way to get timetable data is to replicate the
>> present system that most PT organisations do - a table related to the
>> route. A timetable could be associated with an OSM route. A system will be
>> required to generate meaningful times and itineraries, so should we be
>> asking those existing OSM routing people what  is their preferred way to
>> store timetable data that can be updated reliably.
>>
>> Here in the UK timetable data is in the public domain - is that the case
>> in other places?
>>
>> TonyS
>>
>>
>>
>> On 06/11/2018 19:59, Jo wrote:
>>
>> Indeed, a mapper who wants to add this and who can't find the information
>> on the internet or in a booklet, would have travel to the first stop, take
>> note of all the departure times and then establish the deltas between all
>> the stops of the itinerary.
>> If that's the case, such a mapper would probably better use the tags
>> based method on the route relations.
>>
>> It all depends on how much detail you want to add (and maintain in the
>> long run).
>>
>> Another weakness of the relation pet stop/route pair method is that it
>> will be very hard to encode the exceptions; not on Wednesdays, only on
>> Fridays, etc.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 20:22 schreef djakk djakk :
>>
>>> Ok I see.
>>>
>>> I 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

:)

Le mar. 6 nov. 2018 à 20:55, Yves  a écrit :

> Are you looking for a general transit feed specification?
> :)
>
> Yves
>
> Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk 
> a écrit :
>>
>> Ok I see.
>>
>> I am still a bit reluctant to your proposal since the travelling time
>> between 2 stops can vary during the day, especially for train routes.
>> Ok there is the possibility of adding a new timetable relation ...
>>
>> Moreover, I think that data inputs from the ground can not be done with
>> your proposal (it needs to know the timetable for the whole line), we’ll
>> depend on GTFS file actually :-/
>>
>> Julien “djakk”
>>
>>
>>
>> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>>
>>> Yes, very hard to debug and we already established some change every few
>>> months. So after a change from the operator. One traveler will update one
>>> of those schedules, Another may do so for 3 stops down the line, in the
>>> mean time the stops in between and after are not updated yet. A maintenance
>>> nightmare. The way I proposed it, suffers less from that problem. When
>>> timetables change it's usually that trips are added or removed or their
>>> start time changes slightly. The time to get from one stop to the next will
>>> remain constant, most of the time.
>>>
>>> Jo
>>>
>>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>>>
>>>> I don’t get it ...
>>>>
>>>> With my point of view, one route with 15 stops has 15 timetables, each
>>>> timetable describes the arrival time and the departure time of several
>>>> trips at the stop.
>>>>
>>>> There must be the same number of trips along the stops’ timetables.
>>>> (Otherwise this is an other route).
>>>>
>>>> You mean, if somebody messed up and add an extra trip inside a
>>>> timetable, this would be hard to figure ?
>>>>
>>>> Julien “djakk”
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>>>
>>>>> If you have a single one for a stop/route pair, no problem. As soon as
>>>>> you have a few hundred and the information in them starts to conflict with
>>>>> other another timetable relation for the same route it will be extremely
>>>>> hard to figure out where it went wrong.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk >>>> >:
>>>>>
>>>>>> In which case a timetable per stop and per route is unmaintable ?
>>>>>>
>>>>>> Julien “djakk”
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> I think it is important to have an osm object describing the
>>>>>>> timetable user-oriented for simple editing without any tool.
>>>>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>>>>> import it later in osm without the need of any extra tool.
>>>>>>> Validator can be inside a tool.
>>>>>>>
>>>>>>> Julien « djakk »
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>>>>> timetable, the user have to refer to the closest previous bus stop 
>>>>>>>> having
>>>>>>>> an official timetable. So this kind of bus stop may not have a 
>>>>>>>> timetable in
>>>>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>>>>> habits the schedule).
>>>>>>>>
>>>>>>>>
>>>>>>>> Julien « djakk »
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>>>>>
>>>>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>>>>> relations! It seems to me that it would be a nighmare to try and 
>>>>>>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Ok I see.

I am still a bit reluctant to your proposal since the travelling time
between 2 stops can vary during the day, especially for train routes.
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with
your proposal (it needs to know the timetable for the whole line), we’ll
depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :

> Yes, very hard to debug and we already established some change every few
> months. So after a change from the operator. One traveler will update one
> of those schedules, Another may do so for 3 stops down the line, in the
> mean time the stops in between and after are not updated yet. A maintenance
> nightmare. The way I proposed it, suffers less from that problem. When
> timetables change it's usually that trips are added or removed or their
> start time changes slightly. The time to get from one stop to the next will
> remain constant, most of the time.
>
> Jo
>
> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>
>> I don’t get it ...
>>
>> With my point of view, one route with 15 stops has 15 timetables, each
>> timetable describes the arrival time and the departure time of several
>> trips at the stop.
>>
>> There must be the same number of trips along the stops’ timetables.
>> (Otherwise this is an other route).
>>
>> You mean, if somebody messed up and add an extra trip inside a timetable,
>> this would be hard to figure ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>
>>> If you have a single one for a stop/route pair, no problem. As soon as
>>> you have a few hundred and the information in them starts to conflict with
>>> other another timetable relation for the same route it will be extremely
>>> hard to figure out where it went wrong.
>>>
>>> Polyglot
>>>
>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>>
>>>> In which case a timetable per stop and per route is unmaintable ?
>>>>
>>>> Julien “djakk”
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>>> écrit :
>>>>
>>>>> I think it is important to have an osm object describing the timetable
>>>>> user-oriented for simple editing without any tool.
>>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>>> import it later in osm without the need of any extra tool.
>>>>> Validator can be inside a tool.
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>>> timetable, the user have to refer to the closest previous bus stop having
>>>>>> an official timetable. So this kind of bus stop may not have a timetable 
>>>>>> in
>>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>>> habits the schedule).
>>>>>>
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>>>
>>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>>> relations! It seems to me that it would be a nighmare to try and 
>>>>>>> maintain
>>>>>>> it that way. At first sight it seems simpler, but with the new proposal 
>>>>>>> i
>>>>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>>>>> together.
>>>>>>>
>>>>>>> If the vehicle remains in the station longer, the roles could become
>>>>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>>>>> the vehicle left at its first stop.
>>>>>>>
>>>>>>> Seeing the stops in the timetable relation in the order they are
>>>>>>> served also enables comparing this with the stops sequence in the route
>>>>>>> relation they refer to, adding additional possibilities for validation 
>>>>>>> of
>>>>>>> the data.
>>>>>>>
>&g

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Almost that ! Sometimes bus stops does not have their official timetable,
the user have to refer to the closest previous bus stop having an official
timetable. So this kind of bus stop may not have a timetable in osm (except
an osm mapper really wants to put it into osm, knowing per habits the
schedule).


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :

> You mean per stop/route pair? That's an incredible s amount of relations!
> It seems to me that it would be a nighmare to try and maintain it that way.
> At first sight it seems simpler, but with the new proposal i came up with,
> you can see how the stops of a variation in itinerary tie together.
>
> If the vehicle remains in the station longer, the roles could become
> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
> the vehicle left at its first stop.
>
> Seeing the stops in the timetable relation in the order they are served
> also enables comparing this with the stops sequence in the route relation
> they refer to, adding additional possibilities for validation of the data.
>
> The stops in a timetable sequence should always be a subset of the stops
> in a route relation and appear in the same order.
>
> Polyglot
>
>
> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>
>> I’ll agree with Leif, having a timetable relation per stop is better.
>>
>>
>> Yes Leif, there can be a delay expressed in minutes instead of an
>> arrival-departure pair of time.
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>> écrit :
>>
>>> In order to reduce the length of the value of the departures= tag,
>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>> écrit :
>>>
>>>> Martin, maybe locals do know their bus stop timetable, as they always
>>>> use the service they may memorize the schedules ... ?
>>>>
>>>> Julien
>>>>
>>>>
>>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>>
>>>>> Hi Leif,
>>>>>
>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>> creating a new one. It differs in rather important ways from your 
>>>>> proposal,
>>>>> so I preferred not modifying your wiki page. I also think it's important 
>>>>> to
>>>>> decouple the (voting for a) full timetable solution from the solution 
>>>>> where
>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>> which is a lot more likely to be accepted.
>>>>>
>>>>> So here goes:
>>>>>
>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>>
>>>>> Please let me know what you think. What I still haven't figured out
>>>>> yet is how to differ weekdays that fall in school holiday periods from
>>>>> "normal" weekdays. So work in progress.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>>>
>>>>>> Polyglot:
>>>>>>
>>>>> I think that having a timetable relation for each stop is less
>>>>>> complicated than having one per route.  There are several advantages to
>>>>>> this:
>>>>>> 1) People can easily add a single relation at a time, rather than
>>>>>> having to do the entire line at one time.  This could make it much easier
>>>>>> to, for example, have a StreetComplete quest asking "What are the arrival
>>>>>> times of bus X at this bus stop?"  iD could also have a field at bus 
>>>>>> stops
>>>>>> with "arrivals for each parent bus route" that would allow people to
>>>>>> seamlessly create timetable relations.  It also makes more features
>>>>>> possible in the future, such as additional tags to each timetable.
>>>>>> 2) The system is easier for newbies to learn to use.
>>>>>>
>>>>>> The disadvantage is that there are now a ton of relations per bus /
>>>>>> train / subway route.  Creating these could made easier by a new JOSM
>>>>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk  a écrit :

> I think it is important to have an osm object describing the timetable
> user-oriented for simple editing without any tool.
> The mapper is at a bus stop, takes a picture of the timetable, can import
> it later in osm without the need of any extra tool.
> Validator can be inside a tool.
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a écrit :
>
>> Almost that ! Sometimes bus stops does not have their official timetable,
>> the user have to refer to the closest previous bus stop having an official
>> timetable. So this kind of bus stop may not have a timetable in osm (except
>> an osm mapper really wants to put it into osm, knowing per habits the
>> schedule).
>>
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>
>>> You mean per stop/route pair? That's an incredible s amount of
>>> relations! It seems to me that it would be a nighmare to try and maintain
>>> it that way. At first sight it seems simpler, but with the new proposal i
>>> came up with, you can see how the stops of a variation in itinerary tie
>>> together.
>>>
>>> If the vehicle remains in the station longer, the roles could become
>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>> the vehicle left at its first stop.
>>>
>>> Seeing the stops in the timetable relation in the order they are served
>>> also enables comparing this with the stops sequence in the route relation
>>> they refer to, adding additional possibilities for validation of the data.
>>>
>>> The stops in a timetable sequence should always be a subset of the stops
>>> in a route relation and appear in the same order.
>>>
>>> Polyglot
>>>
>>>
>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>>
>>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>>
>>>>
>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>> arrival-departure pair of time.
>>>>
>>>> Julien « djakk »
>>>>
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>>> écrit :
>>>>
>>>>> In order to reduce the length of the value of the departures= tag,
>>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> Martin, maybe locals do know their bus stop timetable, as they always
>>>>>> use the service they may memorize the schedules ... ?
>>>>>>
>>>>>> Julien
>>>>>>
>>>>>>
>>>>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>>>>
>>>>>>> Hi Leif,
>>>>>>>
>>>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>>>> creating a new one. It differs in rather important ways from your 
>>>>>>> proposal,
>>>>>>> so I preferred not modifying your wiki page. I also think it's 
>>>>>>> important to
>>>>>>> decouple the (voting for a) full timetable solution from the solution 
>>>>>>> where
>>>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>>>> which is a lot more likely to be accepted.
>>>>>>>
>>>>>>> So here goes:
>>>>>>>
>>>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>>>>
>>>>>>> Please let me know what you think. What I still haven't figured out
>>>>>>> yet is how to differ weekdays that fall in school holiday periods from
>>>>>>> "normal" weekdays. So work in progress.
>>>>>>>
>>>>>>> Polyglot
>>>>>>>
>>>>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com
>>>>>>> >:
>>>>>>>
>>&

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each
timetable describes the arrival time and the departure time of several
trips at the stop.

There must be the same number of trips along the stops’ timetables.
(Otherwise this is an other route).

You mean, if somebody messed up and add an extra trip inside a timetable,
this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :

> If you have a single one for a stop/route pair, no problem. As soon as you
> have a few hundred and the information in them starts to conflict with
> other another timetable relation for the same route it will be extremely
> hard to figure out where it went wrong.
>
> Polyglot
>
> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>
>> In which case a timetable per stop and per route is unmaintable ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>> écrit :
>>
>>> I think it is important to have an osm object describing the timetable
>>> user-oriented for simple editing without any tool.
>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>> import it later in osm without the need of any extra tool.
>>> Validator can be inside a tool.
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>> écrit :
>>>
>>>> Almost that ! Sometimes bus stops does not have their official
>>>> timetable, the user have to refer to the closest previous bus stop having
>>>> an official timetable. So this kind of bus stop may not have a timetable in
>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>> habits the schedule).
>>>>
>>>>
>>>> Julien « djakk »
>>>>
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>
>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>> relations! It seems to me that it would be a nighmare to try and maintain
>>>>> it that way. At first sight it seems simpler, but with the new proposal i
>>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>>> together.
>>>>>
>>>>> If the vehicle remains in the station longer, the roles could become
>>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>>> the vehicle left at its first stop.
>>>>>
>>>>> Seeing the stops in the timetable relation in the order they are
>>>>> served also enables comparing this with the stops sequence in the route
>>>>> relation they refer to, adding additional possibilities for validation of
>>>>> the data.
>>>>>
>>>>> The stops in a timetable sequence should always be a subset of the
>>>>> stops in a route relation and appear in the same order.
>>>>>
>>>>> Polyglot
>>>>>
>>>>>
>>>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk >>>> >:
>>>>>
>>>>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>>>>
>>>>>>
>>>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>>>> arrival-departure pair of time.
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> In order to reduce the length of the value of the departures= tag,
>>>>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 
>>>>>>> ;
>>>>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>>>>
>>>>>>> Julien « djakk »
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> Martin, maybe locals do know their bus stop timetable, as they
>>>>>>>> always use the service they may memorize the schedules ... ?
>>>>>>>>
>>>>>>>> Julien
>>>>>>>>
>>>>>>>>
>>>>>>>> Le lun. 5 nov. 2

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I think it is important to have an osm object describing the timetable
user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import
it later in osm without the need of any extra tool.
Validator can be inside a tool.

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk  a écrit :

> Almost that ! Sometimes bus stops does not have their official timetable,
> the user have to refer to the closest previous bus stop having an official
> timetable. So this kind of bus stop may not have a timetable in osm (except
> an osm mapper really wants to put it into osm, knowing per habits the
> schedule).
>
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>
>> You mean per stop/route pair? That's an incredible s amount of relations!
>> It seems to me that it would be a nighmare to try and maintain it that way.
>> At first sight it seems simpler, but with the new proposal i came up with,
>> you can see how the stops of a variation in itinerary tie together.
>>
>> If the vehicle remains in the station longer, the roles could become
>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>> the vehicle left at its first stop.
>>
>> Seeing the stops in the timetable relation in the order they are served
>> also enables comparing this with the stops sequence in the route relation
>> they refer to, adding additional possibilities for validation of the data.
>>
>> The stops in a timetable sequence should always be a subset of the stops
>> in a route relation and appear in the same order.
>>
>> Polyglot
>>
>>
>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>
>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>
>>>
>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>> arrival-departure pair of time.
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>> écrit :
>>>
>>>> In order to reduce the length of the value of the departures= tag,
>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>
>>>> Julien « djakk »
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>>> écrit :
>>>>
>>>>> Martin, maybe locals do know their bus stop timetable, as they always
>>>>> use the service they may memorize the schedules ... ?
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>>>
>>>>>> Hi Leif,
>>>>>>
>>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>>> creating a new one. It differs in rather important ways from your 
>>>>>> proposal,
>>>>>> so I preferred not modifying your wiki page. I also think it's important 
>>>>>> to
>>>>>> decouple the (voting for a) full timetable solution from the solution 
>>>>>> where
>>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>>> which is a lot more likely to be accepted.
>>>>>>
>>>>>> So here goes:
>>>>>>
>>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>>>
>>>>>> Please let me know what you think. What I still haven't figured out
>>>>>> yet is how to differ weekdays that fall in school holiday periods from
>>>>>> "normal" weekdays. So work in progress.
>>>>>>
>>>>>> Polyglot
>>>>>>
>>>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>>>>
>>>>>>> Polyglot:
>>>>>>>
>>>>>> I think that having a timetable relation for each stop is less
>>>>>>> complicated than having one per route.  There are several advantages to
>>>>>>> this:
>>>>>>> 1) People can easily add a single relation at a time, rather than
>>>>>>> having to do the entire line at one time.  This could make it much 
>>>>>>> easier
>>>>>>> to, for example, have a StreetCo

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Martin, maybe locals do know their bus stop timetable, as they always use
the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started creating
> a new one. It differs in rather important ways from your proposal, so I
> preferred not modifying your wiki page. I also think it's important to
> decouple the (voting for a) full timetable solution from the solution where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured out yet is
> how to differ weekdays that fall in school holiday periods from "normal"
> weekdays. So work in progress.
>
> Polyglot
>
> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>
>> Polyglot:
>>
> I think that having a timetable relation for each stop is less complicated
>> than having one per route.  There are several advantages to this:
>> 1) People can easily add a single relation at a time, rather than having
>> to do the entire line at one time.  This could make it much easier to, for
>> example, have a StreetComplete quest asking "What are the arrival times of
>> bus X at this bus stop?"  iD could also have a field at bus stops with
>> "arrivals for each parent bus route" that would allow people to seamlessly
>> create timetable relations.  It also makes more features possible in the
>> future, such as additional tags to each timetable.
>> 2) The system is easier for newbies to learn to use.
>>
>> The disadvantage is that there are now a ton of relations per bus / train
>> / subway route.  Creating these could made easier by a new JOSM plugin.
>> Also, if someone wanted to delete all timetable relations that are part of
>> a route, they could simply use this overpass query to download the data
>> into JOSM and then delete all of the timetable relations:
>> https://overpass-turbo.eu/s/Dlf
>>
>> If people really prefer a single timetable relation for each route, then
>> I will go with that.
>>
>> Julien:
>> Why not have a "delay"="> this platform>" tag instead of separate arrivals/departures tags?
>>
>> Thanks,
>> Leif Rasmussen
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

... and/or an abbreviation with the frequency : departures=5:15 - 1:25
every 1:30 ~ 3 minutes
(This is for Rennes’ subway line)

Julien « djakk »


Le mar. 6 nov. 2018 à 16:07, djakk djakk  a écrit :

> I’ll agree with Leif, having a timetable relation per stop is better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :
>
>> In order to reduce the length of the value of the departures= tag, should
>> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>> écrit :
>>
>>> Martin, maybe locals do know their bus stop timetable, as they always
>>> use the service they may memorize the schedules ... ?
>>>
>>> Julien
>>>
>>>
>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>
>>>> Hi Leif,
>>>>
>>>> You made me do it! :-) I sort of stole your proposal and started
>>>> creating a new one. It differs in rather important ways from your proposal,
>>>> so I preferred not modifying your wiki page. I also think it's important to
>>>> decouple the (voting for a) full timetable solution from the solution where
>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>> which is a lot more likely to be accepted.
>>>>
>>>> So here goes:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>
>>>> Please let me know what you think. What I still haven't figured out yet
>>>> is how to differ weekdays that fall in school holiday periods from "normal"
>>>> weekdays. So work in progress.
>>>>
>>>> Polyglot
>>>>
>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>>
>>>>> Polyglot:
>>>>>
>>>> I think that having a timetable relation for each stop is less
>>>>> complicated than having one per route.  There are several advantages to
>>>>> this:
>>>>> 1) People can easily add a single relation at a time, rather than
>>>>> having to do the entire line at one time.  This could make it much easier
>>>>> to, for example, have a StreetComplete quest asking "What are the arrival
>>>>> times of bus X at this bus stop?"  iD could also have a field at bus stops
>>>>> with "arrivals for each parent bus route" that would allow people to
>>>>> seamlessly create timetable relations.  It also makes more features
>>>>> possible in the future, such as additional tags to each timetable.
>>>>> 2) The system is easier for newbies to learn to use.
>>>>>
>>>>> The disadvantage is that there are now a ton of relations per bus /
>>>>> train / subway route.  Creating these could made easier by a new JOSM
>>>>> plugin.  Also, if someone wanted to delete all timetable relations that 
>>>>> are
>>>>> part of a route, they could simply use this overpass query to download the
>>>>> data into JOSM and then delete all of the timetable relations:
>>>>> https://overpass-turbo.eu/s/Dlf
>>>>>
>>>>> If people really prefer a single timetable relation for each route,
>>>>> then I will go with that.
>>>>>
>>>>> Julien:
>>>>> Why not have a "delay"=">>>> at this platform>" tag instead of separate arrivals/departures tags?
>>>>>
>>>>> Thanks,
>>>>> Leif Rasmussen
>>>>> ___
>>>>> Tagging mailing list
>>>>> tagg...@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> Tagging mailing list
>>>> tagg...@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

In order to reduce the length of the value of the departures= tag, should
we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
[7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk  a écrit :

> Martin, maybe locals do know their bus stop timetable, as they always use
> the service they may memorize the schedules ... ?
>
> Julien
>
>
> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started creating
>> a new one. It differs in rather important ways from your proposal, so I
>> preferred not modifying your wiki page. I also think it's important to
>> decouple the (voting for a) full timetable solution from the solution where
>> tags are added to indicate interval during 'opening_hours' or a route,
>> which is a lot more likely to be accepted.
>>
>> So here goes:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> Please let me know what you think. What I still haven't figured out yet
>> is how to differ weekdays that fall in school holiday periods from "normal"
>> weekdays. So work in progress.
>>
>> Polyglot
>>
>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>
>>> Polyglot:
>>>
>> I think that having a timetable relation for each stop is less
>>> complicated than having one per route.  There are several advantages to
>>> this:
>>> 1) People can easily add a single relation at a time, rather than having
>>> to do the entire line at one time.  This could make it much easier to, for
>>> example, have a StreetComplete quest asking "What are the arrival times of
>>> bus X at this bus stop?"  iD could also have a field at bus stops with
>>> "arrivals for each parent bus route" that would allow people to seamlessly
>>> create timetable relations.  It also makes more features possible in the
>>> future, such as additional tags to each timetable.
>>> 2) The system is easier for newbies to learn to use.
>>>
>>> The disadvantage is that there are now a ton of relations per bus /
>>> train / subway route.  Creating these could made easier by a new JOSM
>>> plugin.  Also, if someone wanted to delete all timetable relations that are
>>> part of a route, they could simply use this overpass query to download the
>>> data into JOSM and then delete all of the timetable relations:
>>> https://overpass-turbo.eu/s/Dlf
>>>
>>> If people really prefer a single timetable relation for each route, then
>>> I will go with that.
>>>
>>> Julien:
>>> Why not have a "delay"=">> this platform>" tag instead of separate arrivals/departures tags?
>>>
>>> Thanks,
>>> Leif Rasmussen
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I’ll agree with Leif, having a timetable relation per stop is better.


Yes Leif, there can be a delay expressed in minutes instead of an
arrival-departure pair of time.

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :

> In order to reduce the length of the value of the departures= tag, should
> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a écrit :
>
>> Martin, maybe locals do know their bus stop timetable, as they always use
>> the service they may memorize the schedules ... ?
>>
>> Julien
>>
>>
>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>
>>> Hi Leif,
>>>
>>> You made me do it! :-) I sort of stole your proposal and started
>>> creating a new one. It differs in rather important ways from your proposal,
>>> so I preferred not modifying your wiki page. I also think it's important to
>>> decouple the (voting for a) full timetable solution from the solution where
>>> tags are added to indicate interval during 'opening_hours' or a route,
>>> which is a lot more likely to be accepted.
>>>
>>> So here goes:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>
>>> Please let me know what you think. What I still haven't figured out yet
>>> is how to differ weekdays that fall in school holiday periods from "normal"
>>> weekdays. So work in progress.
>>>
>>> Polyglot
>>>
>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>
>>>> Polyglot:
>>>>
>>> I think that having a timetable relation for each stop is less
>>>> complicated than having one per route.  There are several advantages to
>>>> this:
>>>> 1) People can easily add a single relation at a time, rather than
>>>> having to do the entire line at one time.  This could make it much easier
>>>> to, for example, have a StreetComplete quest asking "What are the arrival
>>>> times of bus X at this bus stop?"  iD could also have a field at bus stops
>>>> with "arrivals for each parent bus route" that would allow people to
>>>> seamlessly create timetable relations.  It also makes more features
>>>> possible in the future, such as additional tags to each timetable.
>>>> 2) The system is easier for newbies to learn to use.
>>>>
>>>> The disadvantage is that there are now a ton of relations per bus /
>>>> train / subway route.  Creating these could made easier by a new JOSM
>>>> plugin.  Also, if someone wanted to delete all timetable relations that are
>>>> part of a route, they could simply use this overpass query to download the
>>>> data into JOSM and then delete all of the timetable relations:
>>>> https://overpass-turbo.eu/s/Dlf
>>>>
>>>> If people really prefer a single timetable relation for each route,
>>>> then I will go with that.
>>>>
>>>> Julien:
>>>> Why not have a "delay"=">>> at this platform>" tag instead of separate arrivals/departures tags?
>>>>
>>>> Thanks,
>>>> Leif Rasmussen
>>>> ___
>>>> Tagging mailing list
>>>> tagg...@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] Chemin en bois sur pilotis

[djakk djakk]

Salut ! Moi dans ce cas j’ai simplement mis bridge=yes ;)
https://www.openstreetmap.org/#map=18/48.15156/-1.67961


Julien « djakk »


Le sam. 10 nov. 2018 à 12:02, Gwenaël Jouvin  a
écrit :

> Bonjour à tous,
>
> Récemment j’ai vu dans une forêt, un chemin construit en lattes de bois,
> le tout surélevé d’environ 30 cm à 50 cm au-dessus du sol à l’aide de
> pilotis.
>
> Je ne connais pas le terme technique qui désigne ce genre de chose, alors
> voici une illustration :
>
> https://www.visorando.com/images/original/chemin-sureleve-par-un-platelage-visorando-30127.jpg
>
>
> Actuellement il est taggé
> highway=path
> surface=wood
>
> … ce qui ne transcrit pas la particularité de l’aménagement. On pourrait
> éventuellement y ajouter la largeur.
>
> Cependant, existe-t-il un attribut particulier pour indiquer précisément
> que c’est un platelage surélevé ?
>
>
> Merci.
>
> ___
> 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] [OSM transport] Cartographie des arrêts de bus de substitution de la ligne RER C

[djakk djakk]

Je dirai que la ligne de substitution est une ligne irrégulière, ce qui se
verra quand l’utilisateur cherchera les horaires de la ligne.
Ajouter une info sur la fréquence de la ligne dans la relation ?

djakk


Le jeu. 11 oct. 2018 à 18:15, marc marc  a
écrit :

> Le 11. 10. 18 à 17:05, Charles MILLET a écrit :
> > Nous pensons utiliser quelque chose comme ça
> > substitution=yes
>
> sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
> en particulier, c'est un arrêt de bus, y dupliquer l'information
> de tous les type de lignes pouvant éventuellement l'utiliser ne semble
> à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque
> changement, il faut veiller à dupliquer le changement pour garder
> la cohérence, faire une analyse osmose ou autre pour surveiller
> les inévitables désynchronisation entre les 2 et avoir quelqu'un
> qui passe du temps à resynchroniser les données).
> Je pense que l'utilisation des données du type de ligne qui passe
> à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
> Mais je sais qu'on a au moins 2 champions de la duplication dans
> la communauté qui ne manqueront pas de faire valoir l'inverse :-)
>
> > subtitution:lines=RER C
>
> pour les relations représentant les lignes,
> Une possibilité serrait d'avoir exactement le même nom
> et donc j'aurais plutôt vu quelque chose genre
> name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
> le nom, le from, le to, la ref et la branche...)
> substitution=only (la ligne n'existe que quand l'autre est en panne)
> substitution:of=train (elle remplace une relation train)
> et éventuellement sur la relation du RER C:
> substitution:by=bus
> en ajoutant l'itinéraire de substitution dans la relation route_master
> on pourrait sans doute faciliter une utilisation futur + poussée.
> le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus
> fils d'une relation route_master=train
> ce serrait sans doute utile d'en discuter sur tagging
> avec une exemple de relation bus comparable à la relation rer
> histoire de rendre la chose compréhensible pour ceux qui n'ont
> rien de semblable chez eux.
> c'est sans doute un peu prématuré si pour le moment vous en êtes
> aux arrêts de bus eux-même.
>
> > Ces tag pourrons être complétés par une note au besoin.
>
> les notes peuvent être utile pendant l'expérience sur la première
> relation mais à long terme, des outils/contributeurs considèrent
> la note comme étant souvent le signe que c'est pas stable d’où
> le besoin de transmettre une information et qu'il faut donc
> un éventuel coup de main pour transformer la note en tag + adapté.
> url=la page wiki sur le changeset serrait très utile pour le
> contributeur qui veux en savoir plus sur le projet.
>
> Cordialement,
> Marc
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parking vélo dans un parking sous-terrain

[djakk djakk]

Bonne idées Florimond ! :)


djakk

Le mer. 3 oct. 2018 à 13:51, marc marc  a écrit :

> Le 03. 10. 18 à 13:35, Florimond Berthoux a écrit :
> > Comment cartographier un parking vélo dans un parking sous-terrain ?
>
> > Je vois deux possibilités, soit le parking sous-terrain n'est modélisé
> > que par un nœud alors j'ajouterais les tags:
> > amenity=parking
> > parking=underground
> > bicycle=yes
> > capacity:bicycle=XX
>
> cela me semble le plus raisonnable/utilisable pour un parking souterrain
>
> > Soit le parking sous-terrain est cartographié par une relation de
> > différents éléments. Dans ce cas je rajouterais un nœud
> > amenity=bicycle_parking.
>
> mais comme cette relation n'est utilisé par (quasi ?) personne,
> j'ajouterai un location=underground sur le nœud histoire
> de rendre l'information utilisable.
>
> Cordialement,
> Marc
> ___
> 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] Arceaux partagés motos / vélos

[djakk djakk]

rtains véhicules en plus de l'offre de
> >>> location et de sa gestion (bornes).
> >>>
> >>> Bref mon propos est simple, ne pas créer un tag pour chaque chose sur
> >>> terre, il faut factoriser afin de rendre plus simple l'ajout et
> >>> l'utilisation des données.
> >>>
> >>> Le mar. 25 sept. 2018 à 12:04, marc marc  a
> >>> écrit :
> >>>
> >>>> je partage l'avis de Jean-Yvon : une station de véhicule en partage
> (=un
> >>>> operateur y a mis des véhicules destinés à être emprunté), ce n'est
> >>>> vraiment pas du tout la même chose qu'un parking (on y met son propre
> >>>> véhicule qu'on viendra récupéré dans quelques minutes/heures/jours)
> >>>>
> >>>> c'est difficile d'invoquer un vice "tag pour le rendu"
> >>>> à propos d'un tag qui n'est pas rendu :-)
> >>>>
> >>>> Le 25. 09. 18 à 10:55, Florimond Berthoux a écrit :
> >>>>> Un parking de scooter (et de vélo et de trottinette) partagé n'a
> rien à
> >>>>> voir avec un parking ?
> >>>>> Je suis perplexe.
> >>>>>
> >>>>> (Oserais-je dire que « amenity=scooter_sharing » c'est du tag to
> render
> >>>> ?)
> >>>>>
> >>>>> Le lun. 24 sept. 2018 à 20:41,  a
> >>>> écrit :
> >>>>>
> >>>>>  Si je comprends bien, c'est du scooter partagé, rien à voir
> avec un
> >>>>>  parking.
> >>>>>
> >>>>>  Les emplacements des voitures en partage sont repérés avec la
> clé
> >>>>>      https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_sharing.
> >>>>>
> >>>>>  __amenity
> >>>>>  <https://wiki.openstreetmap.org/wiki/Key:amenity
> >>>>> __=__bicycle_rental__
> >>>>>  <
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbicycle_rental>
> >>>>>  pour les vélos en libre service.
> >>>>>
> >>>>>  Donc amenity=scooter_sharing ?
> >>>>>
> >>>>>  Jean-Yvon
> >>>>>
> >>>>>
> >>>>>  Le 24/09/2018 à 14:18, Florimond Berthoux -
> >>>>>  florimond.berth...@gmail.com  florimond.berth...@gmail.com>
> >>>> a
> >>>>>  écrit :
> >>>>>>  Je ne retrouve plus l'information, mais la SNCF à ouvert à
> gare de
> >>>>>>  Lyon (Paris) un stationnement pour le freefloating (scooter
> >>>>>>  électrique Cityscoot, trottinette électrique Lime, ...)
> >>>>>>
> >>>>>>  Alors si on suit la logique amenity=bicycle_parking il
> faudrait un
> >>>>>>  amenity=freefloating_scooter ? Étrange.
> >>>>>>  Cela se résout plus facilement avec le droit accès.
> >>>>>>  D'un point de vue utilisation de la BdD c'est plus simple
> aussi,
> >>>>>>  pas besoin de se faire une collection de tag pour trouver tous
> les
> >>>>>>  parkings de tous les types.
> >>>>>>
> >>>>>>
> >>>>>>  Le lun. 24 sept. 2018 à 13:01, djakk djakk <
> djakk.dj...@gmail.com
> >>>>>>  <mailto:djakk.dj...@gmail.com>> a écrit :
> >>>>>>
> >>>>>>  Merci Florimond tu as mis les mots sur un ressenti flou que
> >>>>>>  j’avais.
> >>>>>>
> >>>>>>  Je trouve que highway=cycleway est un raccourci bien
> pratique
> >>>>>>  mais il ne s’agirait que d’un alias vers un objet plus+
> >>>>>>  complexe ayant des valeurs par défaut.
> >>>>>>
> >>>>>>
> >>>>>>  djakk
> >>>>>>
> >>>>>>
> >>>>>>  Le lun. 24 sept. 2018 à 11:22, Florimond Berthoux
> >>>>>>   >>>>>>  <mailto:florimond.berth...@gmail.com>> a écrit :
> >>>>>>
> >>>>>>  Bonjour,
> >>>>>>
> >>>>>>  plus un pour :
> >>>>>>
> >>>>>>  Le jeu. 20 sept. 2018 à 17:54, djakk djakk
> >>>>>>  mailto:djakk.dj...@gmail.com>>
> a
> >>>>>>  écrit :
> >>>>>>
> >>>>>>
> >>>>>>  Ou revoir la méthode :
> >>>>>>  amenity=parking
> >>>>>>  bicycle=yes
> >>>>>>  motorcar=no
> >>>>>>  hgv=no
> >>>>>>  motorcycle=yes
> >>>>>>
> >>>>>>
> >>>>>>  Définir le droit d'accès et le type d'aménagement dans
> le
> >>>>>>  même tag est une erreur conceptuelle.
> >>>>>>  C'est d'abord un parking, autorisé aux deux roues
> (vélo +
> >>>>>>  moto), avec dessus une infra de type arceaux.
> >>>>>>
> >>>>>>  (Il y a le même problème avec le highway=cycleway, qui
> >>>>>>  définit à la fois une route et un droit d'accès.)
> ___
> 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] restrictions d'accès dans les voies de cimetières

[djakk djakk]

Il suffit d’ajouter un surface=excellent pour que le rendu du highway=track
change ;) Mais bon si c’est le cas le chemin est sans doute goudronné ->
highway=service du coup.


djakk

Le dim. 23 sept. 2018 à 22:32, Philippe Verdy  a écrit :

> de plus je ne vois pas trop en fin de compte la différence entre
> "access=permissive" et "access=restricted" qui me semblent indiquer la même
> chose et impliquer dans le deux cas l'existence de restrictions d'accès qui
> ne sont pas tranchés entre access=yes ou access=no.
>
> Le dim. 23 sept. 2018 à 20:49, marc marc  a
> écrit :
>
>> Le 23. 09. 18 à 19:19, Philippe Verdy a écrit :
>> > Quelle valeur indiquer ?
>>
>> mapper ce qui existe et non la législation.
>> highway=path si c'est étroit ou track si c'est assez large
>> que pour un véhicule de service y passe (sujet à controverse,
>> certain ne voyant dans track que l'aspect rural/agricole/forestier)
>> + access selon les panneaux présents
>> + barrier éventuelle à leur emplacement
>> + opening_hour éventuel
>>
>>
>> > - propriété publique mais d'accès restreint et réglementé dans un
>> espace
>> > délimité
>> > - propriété privée mais d'accès "permissif".
>>
>> on ne mape pas la propriété dans osm.
>> donc les 2 sont access=permissif
>> si tu veux maper l'opérateur public du parc operator:type=public
>> ___
>> 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] Arceaux partagés motos / vélos

[djakk djakk]

Merci Florimond tu as mis les mots sur un ressenti flou que j’avais.

Je trouve que highway=cycleway est un raccourci bien pratique mais il ne
s’agirait que d’un alias vers un objet plus+ complexe ayant des valeurs par
défaut.


djakk


Le lun. 24 sept. 2018 à 11:22, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Bonjour,
>
> plus un pour :
>
> Le jeu. 20 sept. 2018 à 17:54, djakk djakk  a
> écrit :
>
>>
>> Ou revoir la méthode :
>> amenity=parking
>> bicycle=yes
>> motorcar=no
>> hgv=no
>> motorcycle=yes
>>
>
> Définir le droit d'accès et le type d'aménagement dans le même tag est une
> erreur conceptuelle.
> C'est d'abord un parking, autorisé aux deux roues (vélo + moto), avec
> dessus une infra de type arceaux.
>
> (Il y a le même problème avec le highway=cycleway, qui définit à la fois
> une route et un droit d'accès.)
>
> Cordialement.
>
>
> --
> 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] Domaine public maritime et limites communales/intercommunales.

[djakk djakk]

Salut !

Je me suis effectivement posé la question du trait de côte dans osm ... ça
serait super intéressant d’avoir plusieurs lignes de côte (haute mer -
basse mer / fort coefficient - faible coefficient)


djakk

Le ven. 21 sept. 2018 à 18:30, Philippe Verdy  a écrit :

> Je commence à m'interroger sur l'inclusion dans le périmètre des communes
> (et des EPCI) des ilots côtiers qui font partie du domaine public maritime
> (national).
> En revanche pas de problème pour les inclure dans les arrondissements,
> départements et régions puisqu'il sont de la compétence des préfectures et
> sous-préfectures (qui représenent l'Etat).
>
> Ne pourrait-on pas créer une pseudo-commune avec admin_level=8, au minimum
> une par arrondissement, et nommée simplement "Domaine public maritime" ?
> Cette relation ferait partie des arrondissements, départements et régions,
> mais pas des communes ou leurs EPCI à fiscalité propre (elle pourrait en
> revanche faire partie de certains syndicats mixtes, dont ceux gérant les
> parcs naturels et associant communes, EPCI, départments, région, Etat)
>
> On reconnait ces îles et îlots hors périmètre communal/intercommunal non
> pas parce que qu'elles ne sont pas habitées ou font ou ne font pas partie
> d'une réserve naturelle maritime, mais par le fait que leur terrain émergé
> n'est PAS cadastré.
>
> On peut ajouter à admin_level=8 aussi un admin_type:FR pour indiquer que
> ce n'est pas une commune (ou commune nouvelle) mais le domaine public de
> l'Etat. Cependant il ne s'agit que de la partie terrestre de ce domaine
> maritime qui inclut aussi la partie maritime jusqu'aux limites des eaux
> territoriales.
>
> Hors là, si on y inclut les eaux territoriales, on tombe en fait sur la
> compétence des préfectures de régions (qui gèrent les régions maritimes, il
> n'y a pas d'arrondissement maritime, même si pour des raisons pratiques les
> préfectures de régions maritimes délèguent la gestion du secteur côtier
> émergé aux sous-préfets qui sont en relation directe avec les communes
> littorales, à qui ils confient aussi des missions de surveillance de ce
> domaine maritime, en échange de certains crédits de fonctionnement). Les
> communes en revanche ne sont pas chargées de la surveillance et le contrôle
> du domaine maritime immergé, mais ont une mission concernant l'estran,
> mission partagée aussi avec d'autres services comme les CROSS régionaux et
> les services nationaux comme la gendarmerie ou les CRS pour la surveillance
> des plages, sous l'autorité des préfectures départementales de police, et
> aussi la marine pour la défense.
>
> Donc peut-on affiner davantage le découpage administratif du littoral ?
>
> Que faire des plages (notamment leur partie immergeables sur l'estran),
> sachant qu'OSM a une définition différente de ses "lignes de côtes"
> (estimation visuelle sur la ligne de hautes-eaux) alors que les communes
> suivent une définition sur la "ligne de base", qui descend plus bas et
> inclut les entrées de ports et bassins fermés par des digues et les
> estuaires (avec un passage maritime "pas trop large" ou comprenant un
> chenal dragué par l'autorité portuaire locale utilisable même à marée basse
> la plupart du temps hors périodes de fortes marées, ou comprenant un
> système de retenue des eaux avec une barrière immergée) et pas trop larges;
> le trait de ligne de base est estimé aussi sur les ouvrages publics
> construits au travers (dont les tunnels, ponts et barrages et entrant dans
> la compétence soit des communes, soit des départements en tant que
> collectivités, soit plus rarement de l'Etat pour les nationales et
> concessions autoroutières) et inclut les "eaux intérieures (dont les
> bassins et ports et les estuaires soumis à la marée mais pas forcément
> complètement hors d'eau à cause des chenaux dragués).
>
> On retrouve ces compétences communales du domaine maritime sur l'estran ou
> les eaux intérieures dans le cadastre, mais rien au niveau du département
> (en tant que collectivité et non de leur préfecture/sous-préfecture). Et
> l'Etat ne semble pas délimiter vraiment autre chose que les limites des
> eaux territoriales et reste flou sur sa limite de gestion du littoral sur
> l'estran et dans les grands estuaires (là le plus précis pour nous reste
> encore ce que fait et surveille le SHOM mais assez souvent existe des
> conflits entre les communes et l'Etat au sujet de l'extension réelle ce ce
> littoral, sauf s'il y a eu des acquisitions par le conservatoire du
> littoral (mais celui-ci acquiert aussi des terrains cadastrés qui ne
> sortent pas des communes même s'ils sont ajoutés à ce domaine maritime qui
> n'est pas le même que le domaine maritime de l'Etat et est même souvent
> bien plus réduit et ne comprend justement pas les ports).
>
> Enfin il nous manque dans OSM les relations définissant correctement les
> régions maritimes (de compétence préfectorale) qui sont plus grandes que
> les régions-collectivités (formées exclusivement de communes 

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[djakk djakk]

Salut !

J’ai quelque idées :

Est-ce l’occasion d’utiliser le point-virgule pour faire une liste ?
amenity=motorcycle_parking;bicycle_parking (utilisé une trentaine de fois
selon taginfo)

Ou une nouvelle valeur : amenity=motorcycle_and_bicycle_parking

Ou revoir la méthode :
amenity=parking
bicycle=yes
motorcar=no
hgv=no
motorcycle=yes


djakk


Le jeu. 20 sept. 2018 à 17:25, Phyks  a écrit :

> Salut,
>
> Dans ma ville, la plupart des stationnements "vélos" sont en fait des
> stationnements "deux roues" avec des arceaux qui sont utilisables à la
> fois par les motos, les scooters et les vélos (sans distinction).
> Comment devrait-on tagger cela au mieux ?
>
> Il me semble qu'une proposition raisonnable serait un truc comme
>
>  access=yes
>  amenity=motorcycle_parking
>  bicycle=yes
>  bicycle_parking=stands
>  capacity=?
>  covered=no
>  fee=no
>
> mais cela est-il réellement optimal ?
>
> Le rendu par défaut des tuiles par défaut et OpenCycleMap ne va pas
> l'afficher (voir
> https://www.openstreetmap.org/node/5028869329#map=19/48.81712/2.31139
> par exemple qui n'est affiché nulle part).
>
> Bref, je suis preneur de retours sur cette situation (par défaut, j'ai
> l'impression que la plupart des gens les ont mis en parking vélos dans
> le coin).
>
> Merci,
> --
> Phyks
>
> ___
> 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] Parc de stationnement en Zone de rencontre

[djakk djakk]

Ta proposition ? Oui bonne idée.

djakk


Le mer. 19 sept. 2018 à 15:06, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Pas abonné pour le moment. Peux-tu retransmettre la proposition? Merci
>
> Le mer. 19 sept. 2018 à 14:55, djakk djakk  a
> écrit :
>
>> Excellent !
>>
>> Il y a justement une discussion en cours sur la taggin’ mondiale à propos
>> de la vitesse par défaut. Je viens de toucher un mot sur les “zones 30”
>> (C’est : [Tagging] maxspeed:type vs source:maxspeed // StreetComplet)
>>
>> djakk
>>
>> Le mer. 19 sept. 2018 à 14:34, Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com> a écrit :
>>
>>> Salut,
>>> J'ai pas vraiment pris le temps de m'interroger sur cette histoire de
>>> zone légale. Mais je vais aller dans ton sens sur ce sujet.
>>>
>>> Je pense que pour bien décomposer les éléments il faudrait en toucher un
>>> mot avec un juriste qui accepterai de nous aider ou via les universités de
>>> droits. C'est un sujet à proposer je pense.
>>>
>>> J'en reviens à la zone 50 en ville (zone légale 50) puis les zone 30
>>> puis les zones 20
>>> Les notions d'accès (private et permissive) car une voie ouverte à la
>>> circulation sans barrière physique est de fait dans la loi une voie privé
>>> ouverte à la circulation publique (dans mon métier ça a un impact sur notre
>>> activité)
>>>
>>> Mon problème et en lien avec le source:maxspeed=sign avec par exemple
>>> maxspeed=70. Vu que les panneaux de sortie et d'entrée de ville ne sont pas
>>> sur toutes les voies (problème de chemins classés en highway=residential ou
>>> l'inverse) les outils de propagation de vitesse par simulation entre en
>>> conflit car un bord est à 80km/h et l'autre des fois à 30km/h. (peut-être
>>> aussi un manque sur les vitesses en zone privé.
>>>
>>> Bref je vois plus un schéma découlant aussi de name du fait de ce soit
>>> une zone et que ce soit un critère lié au loi et règlement (code de la
>>> route) et que c'est pas lié uniquement à une notion de vitesse. Donc cette
>>> clé doit être décorrélé de maxspeed.
>>>
>>> je pense à un truc du genre *highway:legal_type*
>>>
>>> Cette clé a déjà été décrit pour les panneaux publicitaire et comblera
>>> emplement le dispositif de vitesse
>>>
>>> en agglo:
>>> Si tu es à 50 les vitesses sont implicites
>>> après on peut aussi le faire en explicite
>>> maxspeed=50
>>> *highway:legal_type=urban *ou  *highway:legal_type:FR=agglomération*
>>> Si c'est une voie à 70
>>> maxspeed=50
>>> *highway:legal_type=urban *ou  *highway:legal_type:FR=agglomération*
>>> maxspeed=70
>>> source:maxspeed=sign
>>>
>>> Le reste est dans le même contexte
>>>
>>> Ça règle aussi le problème des Voies vertes
>>> *highway:legal_type:FR=Voie Verte*
>>>
>>> Et évite de jouer juste sur des types de "voie spéciale" sachant que les
>>> voies vertes traversent des chemins de halage des voies de service etc avec
>>> des conditions de circulation très variables.
>>>
>>> Qu'en pensez-vous? On réutilise une clé existante qui colle à notre
>>> contexte. C'est quand mieux que d'avoir
>>> maxspeed:type=*
>>> source:maxspeed=FR:zone:30  ou FR:zone30
>>>
>>> Et avec ça, on libère et fait mieux correspondre la notion de
>>> source:maxspeed
>>>
>>> D'ailleurs il y a aussi des notions de vitesse que j'appelle "de bon
>>> sens" car à moins d'être avec un véhicule de rallye tu ne roules pas
>>> toujours au max de la vitesse légale (problème de visibilité, sinuosité,
>>> pente, nombre d'accès sur la voirie, espaces boisés etc avec passage de
>>> faune)
>>>
>>> Concernant les vitesses de circulation et les outils il faut voir de ce
>>> coté
>>> https://wiki.openstreetmap.org/wiki/Routing#Speed_data
>>>
>>> A+
>>>
>>> Le mer. 19 sept. 2018 à 12:02, djakk djakk  a
>>> écrit :
>>>
>>>> Ou plus simplement living_street=yes :)
>>>>
>>>>
>>>> djakk
>>>>
>>>>
>>>> Le mer. 19 sept. 2018 à 11:06, djakk djakk  a
>>>> écrit :
>>>>
>>>>> Salut !
>>>>>
>>>>> Dans cette situation, je vois 2 choses à cartographier sur les “way”
>>>>> du parking, l’aspect de la route (highway=serv

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[djakk djakk]

Excellent !

Il y a justement une discussion en cours sur la taggin’ mondiale à propos
de la vitesse par défaut. Je viens de toucher un mot sur les “zones 30”
(C’est : [Tagging] maxspeed:type vs source:maxspeed // StreetComplet)

djakk

Le mer. 19 sept. 2018 à 14:34, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Salut,
> J'ai pas vraiment pris le temps de m'interroger sur cette histoire de zone
> légale. Mais je vais aller dans ton sens sur ce sujet.
>
> Je pense que pour bien décomposer les éléments il faudrait en toucher un
> mot avec un juriste qui accepterai de nous aider ou via les universités de
> droits. C'est un sujet à proposer je pense.
>
> J'en reviens à la zone 50 en ville (zone légale 50) puis les zone 30 puis
> les zones 20
> Les notions d'accès (private et permissive) car une voie ouverte à la
> circulation sans barrière physique est de fait dans la loi une voie privé
> ouverte à la circulation publique (dans mon métier ça a un impact sur notre
> activité)
>
> Mon problème et en lien avec le source:maxspeed=sign avec par exemple
> maxspeed=70. Vu que les panneaux de sortie et d'entrée de ville ne sont pas
> sur toutes les voies (problème de chemins classés en highway=residential ou
> l'inverse) les outils de propagation de vitesse par simulation entre en
> conflit car un bord est à 80km/h et l'autre des fois à 30km/h. (peut-être
> aussi un manque sur les vitesses en zone privé.
>
> Bref je vois plus un schéma découlant aussi de name du fait de ce soit une
> zone et que ce soit un critère lié au loi et règlement (code de la route)
> et que c'est pas lié uniquement à une notion de vitesse. Donc cette clé
> doit être décorrélé de maxspeed.
>
> je pense à un truc du genre *highway:legal_type*
>
> Cette clé a déjà été décrit pour les panneaux publicitaire et comblera
> emplement le dispositif de vitesse
>
> en agglo:
> Si tu es à 50 les vitesses sont implicites
> après on peut aussi le faire en explicite
> maxspeed=50
> *highway:legal_type=urban *ou  *highway:legal_type:FR=agglomération*
> Si c'est une voie à 70
> maxspeed=50
> *highway:legal_type=urban *ou  *highway:legal_type:FR=agglomération*
> maxspeed=70
> source:maxspeed=sign
>
> Le reste est dans le même contexte
>
> Ça règle aussi le problème des Voies vertes
> *highway:legal_type:FR=Voie Verte*
>
> Et évite de jouer juste sur des types de "voie spéciale" sachant que les
> voies vertes traversent des chemins de halage des voies de service etc avec
> des conditions de circulation très variables.
>
> Qu'en pensez-vous? On réutilise une clé existante qui colle à notre
> contexte. C'est quand mieux que d'avoir
> maxspeed:type=*
> source:maxspeed=FR:zone:30  ou FR:zone30
>
> Et avec ça, on libère et fait mieux correspondre la notion de
> source:maxspeed
>
> D'ailleurs il y a aussi des notions de vitesse que j'appelle "de bon sens"
> car à moins d'être avec un véhicule de rallye tu ne roules pas toujours au
> max de la vitesse légale (problème de visibilité, sinuosité, pente, nombre
> d'accès sur la voirie, espaces boisés etc avec passage de faune)
>
> Concernant les vitesses de circulation et les outils il faut voir de ce
> coté
> https://wiki.openstreetmap.org/wiki/Routing#Speed_data
>
> A+
>
> Le mer. 19 sept. 2018 à 12:02, djakk djakk  a
> écrit :
>
>> Ou plus simplement living_street=yes :)
>>
>>
>> djakk
>>
>>
>> Le mer. 19 sept. 2018 à 11:06, djakk djakk  a
>> écrit :
>>
>>> Salut !
>>>
>>> Dans cette situation, je vois 2 choses à cartographier sur les “way” du
>>> parking, l’aspect de la route (highway=service + service=parking_aisle) et
>>> l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on
>>> utilise le panneau officiel “zone de rencontre” :
>>> highway_legal=living_street ?)
>>>
>>>
>>> djakk
>>>
>>>
>>> Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret <
>>> jerome.seigneu...@gmail.com> a écrit :
>>>
>>>> @Phyks C'est q'une clause de bon sens mais certains parking sont
>>>> affiché avec des vitesses de circulation à 10 20 ou 30 km.
>>>>
>>>> La loi dit:
>>>>
>>>> *  Article R. 413-18. Lorsque des parcs de stationnement de véhicules
>>>> sont aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent
>>>> circuler sur ceux-ci qu'à une allure très réduite et en prenant toute
>>>> précaution pour ne pas nuire aux piétons. *
>>>>
>>>> D'ailleurs la notion de nuire n'existe plus et à été remplacé par  « ne
>>>>

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[djakk djakk]

Ou plus simplement living_street=yes :)


djakk


Le mer. 19 sept. 2018 à 11:06, djakk djakk  a écrit :

> Salut !
>
> Dans cette situation, je vois 2 choses à cartographier sur les “way” du
> parking, l’aspect de la route (highway=service + service=parking_aisle) et
> l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on
> utilise le panneau officiel “zone de rencontre” :
> highway_legal=living_street ?)
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> @Phyks C'est q'une clause de bon sens mais certains parking sont affiché
>> avec des vitesses de circulation à 10 20 ou 30 km.
>>
>> La loi dit:
>>
>> *  Article R. 413-18. Lorsque des parcs de stationnement de véhicules
>> sont aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent
>> circuler sur ceux-ci qu'à une allure très réduite et en prenant toute
>> précaution pour ne pas nuire aux piétons. *
>>
>> D'ailleurs la notion de nuire n'existe plus et à été remplacé par  « ne
>> pas constituer un danger pour les piétons »
>>
>> Maintenant si tu roule dans un parking de supermarché tu peux avoir des
>> disposition qui font que tu peux rouler sans être confronté à de la
>> circulation piétonne
>> Exemple un stop à chaque ailes de parking. Dans le cas contraire il te
>> sera difficile voir même risqué de prendre de la vitesse si toutes les
>> voies à droite sont des priorités.
>>
>> La loi nous laisse un peu réfléchir et ne fixe pas de limite stricte
>> contrairement à ce qui est dit au permis... Mais difficile de faire un
>> évitement à plus de 10km ou un frainage d'urgence avec un volant déporté
>> dans une voiture d'autoécole...
>>
>> En clair si la police estime que tu mets en danger les usagers tu risques
>> une amande:
>> *Une vitesse excessive par rapport à la configuration des lieux est
>> sanctionnée au même titre qu’un excès de vitesse par une contravention de
>> 4ème classe (amende forfaitaire de 135 €), mais il n’y a pas de retrait de
>> point.  *
>>
>> C'est comme si t'es poursuivi par les motards de la gendarmerie alors que
>> tu roule 50km/h au dessus de la moyenne et qu'il n'ont pas de radars.
>>
>> Donc au final, si il n'y a pas de piétons et pas de panneaux et que tu es
>> en ville dans un parking avec des voies qui te permettent de rouler à cette
>> vitesse sans faire du drift, tu peux rouler à 50km/h si ça te chante.
>>
>> Bonne soirée
>>
>>
>>
>>
>> Le mar. 18 sept. 2018 à 22:19, Phyks  a écrit :
>>
>>> Salut,
>>>
>>>
>>> > En soit rien de franchement étonnant dans beaucoup de voie de service
>>> et de
>>> > parking de supermarché les voies sont déjà limité à 20 voir à 10km.
>>> Pour
>>> > info les voies de services n'ont pas de vitesse par défaut (ce sont les
>>> > logiciel de routing qui les déduises en fonction des voies de
>>> connexions).
>>> > En France les voies privés ouvertes à la circulation ne sont pas
>>> limité de
>>> > manière implicite c'est le même code donc les même conditon de
>>> circulation.
>>> > Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
>>> > t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
>>> > centre commerciaux.
>>>
>>> Mes deux centimes là-dessus, quand je passais le permis on m'avait
>>> explicitement dit qu'il fallait passer la première et y rester sur un
>>> parking de centre commercial, sinon c'était éliminatoire.
>>>
>>> J'ai aucune idée de si c'est retranscrit tel quel dans le code de la
>>> route ou si c'est une pratique exigée en plus des obligations légales,
>>> mais ça me semble difficile de rouler à plus que 10km/h en première :)
>>> --
>>> Phyks
>>>
>>> ___
>>> 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
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[djakk djakk]

Salut !

Dans cette situation, je vois 2 choses à cartographier sur les “way” du
parking, l’aspect de la route (highway=service + service=parking_aisle) et
l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on
utilise le panneau officiel “zone de rencontre” :
highway_legal=living_street ?)


djakk


Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> @Phyks C'est q'une clause de bon sens mais certains parking sont affiché
> avec des vitesses de circulation à 10 20 ou 30 km.
>
> La loi dit:
>
> *  Article R. 413-18. Lorsque des parcs de stationnement de véhicules sont
> aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent
> circuler sur ceux-ci qu'à une allure très réduite et en prenant toute
> précaution pour ne pas nuire aux piétons. *
>
> D'ailleurs la notion de nuire n'existe plus et à été remplacé par  « ne
> pas constituer un danger pour les piétons »
>
> Maintenant si tu roule dans un parking de supermarché tu peux avoir des
> disposition qui font que tu peux rouler sans être confronté à de la
> circulation piétonne
> Exemple un stop à chaque ailes de parking. Dans le cas contraire il te
> sera difficile voir même risqué de prendre de la vitesse si toutes les
> voies à droite sont des priorités.
>
> La loi nous laisse un peu réfléchir et ne fixe pas de limite stricte
> contrairement à ce qui est dit au permis... Mais difficile de faire un
> évitement à plus de 10km ou un frainage d'urgence avec un volant déporté
> dans une voiture d'autoécole...
>
> En clair si la police estime que tu mets en danger les usagers tu risques
> une amande:
> *Une vitesse excessive par rapport à la configuration des lieux est
> sanctionnée au même titre qu’un excès de vitesse par une contravention de
> 4ème classe (amende forfaitaire de 135 €), mais il n’y a pas de retrait de
> point.  *
>
> C'est comme si t'es poursuivi par les motards de la gendarmerie alors que
> tu roule 50km/h au dessus de la moyenne et qu'il n'ont pas de radars.
>
> Donc au final, si il n'y a pas de piétons et pas de panneaux et que tu es
> en ville dans un parking avec des voies qui te permettent de rouler à cette
> vitesse sans faire du drift, tu peux rouler à 50km/h si ça te chante.
>
> Bonne soirée
>
>
>
>
> Le mar. 18 sept. 2018 à 22:19, Phyks  a écrit :
>
>> Salut,
>>
>>
>> > En soit rien de franchement étonnant dans beaucoup de voie de service
>> et de
>> > parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour
>> > info les voies de services n'ont pas de vitesse par défaut (ce sont les
>> > logiciel de routing qui les déduises en fonction des voies de
>> connexions).
>> > En France les voies privés ouvertes à la circulation ne sont pas limité
>> de
>> > manière implicite c'est le même code donc les même conditon de
>> circulation.
>> > Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
>> > t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
>> > centre commerciaux.
>>
>> Mes deux centimes là-dessus, quand je passais le permis on m'avait
>> explicitement dit qu'il fallait passer la première et y rester sur un
>> parking de centre commercial, sinon c'était éliminatoire.
>>
>> J'ai aucune idée de si c'est retranscrit tel quel dans le code de la
>> route ou si c'est une pratique exigée en plus des obligations légales,
>> mais ça me semble difficile de rouler à plus que 10km/h en première :)
>> --
>> Phyks
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

C’est comme dire de ne pas tagger tous les tronçons de route classique mais
seulement au niveau des carrefours car le rendu se débrouillera ;-)


djakk


Le mer. 19 sept. 2018 à 09:51, djakk djakk  a écrit :

> Oui tu as raison pour le bac à sable.
>
> Je ne pense pas qu’il soit possible de calculer automatiquement les 2
> valeurs possibles de highway, par exemple :
> https://www.openstreetmap.org/#map=15/48.4506/0.1241
> Ou :
> https://www.openstreetmap.org/#map=17/49.35320/1.02963
>
> djakk
>
>
> Le mer. 19 sept. 2018 à 01:17, Philippe Verdy  a
> écrit :
>
>> encore une fois OSM n'est pas un bac à sable où on peut décider tout seul
>> de changer des tags abondamment utilisés et briser les règles
>> d'uniformisation. Si le but est de changer le rendu il vaut mieux en
>> discuter avec ceux qui maintiennent ces rendus pour modifier quelques
>> règles d'analyse des données. Cette analyse est possible et déjà faite par
>> exemple dans Osmose qui signale les incohérences.
>>
>> Le mer. 19 sept. 2018 à 00:23, djakk djakk  a
>> écrit :
>>
>>> Bon link_to et link_from ça ne marche pas, j’ai essayé !
>>>
>>> J’ai voulu tagger les bretelles autrement car je vois chaque bretelle
>>> faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la
>>> valeur de la route croisée par la route principale, dans les cas les plus
>>> simples. De ce point de vue, la bretelle ne fait pas partie de la route
>>> principale.
>>>
>>> Je remarque que les bretelles d’accès aux centres commerciaux sont
>>> taggées de ce point de vue (avec highway=service) par les contributeurs.
>>> Exemples :
>>> https://www.openstreetmap.org/#map=18/48.13893/-1.69541
>>> Https://www.openstreetmap.org/#map=17/48.14052/-1.76931
>>> https://www.openstreetmap.org/#map=18/47.69694/-0.87364
>>>
>>>
>>> djakk
>>>
>>>
>>> Le mar. 18 sept. 2018 à 11:20, djakk djakk  a
>>> écrit :
>>>
>>>> Oui, aussi.
>>>>
>>>>
>>>> djakk
>>>>
>>>> Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :
>>>>
>>>>> Le 18 septembre 2018, djakk djakk a écrit :
>>>>>
>>>>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que
>>>>> tu
>>>>> > n'écrives ce mail :
>>>>> > https://www.openstreetmap.org/changeset/62524278
>>>>> >  :O
>>>>> >
>>>>>
>>>>> Une explication ne signifie pas accord de celui qui la reçoit.
>>>>>
>>>>> --
>>>>> Alain Rpnpif
>>>>>
>>>>> ___
>>>>> 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] Les bretelles

[djakk djakk]

Oui tu as raison pour le bac à sable.

Je ne pense pas qu’il soit possible de calculer automatiquement les 2
valeurs possibles de highway, par exemple :
https://www.openstreetmap.org/#map=15/48.4506/0.1241
Ou :
https://www.openstreetmap.org/#map=17/49.35320/1.02963

djakk


Le mer. 19 sept. 2018 à 01:17, Philippe Verdy  a écrit :

> encore une fois OSM n'est pas un bac à sable où on peut décider tout seul
> de changer des tags abondamment utilisés et briser les règles
> d'uniformisation. Si le but est de changer le rendu il vaut mieux en
> discuter avec ceux qui maintiennent ces rendus pour modifier quelques
> règles d'analyse des données. Cette analyse est possible et déjà faite par
> exemple dans Osmose qui signale les incohérences.
>
> Le mer. 19 sept. 2018 à 00:23, djakk djakk  a
> écrit :
>
>> Bon link_to et link_from ça ne marche pas, j’ai essayé !
>>
>> J’ai voulu tagger les bretelles autrement car je vois chaque bretelle
>> faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la
>> valeur de la route croisée par la route principale, dans les cas les plus
>> simples. De ce point de vue, la bretelle ne fait pas partie de la route
>> principale.
>>
>> Je remarque que les bretelles d’accès aux centres commerciaux sont
>> taggées de ce point de vue (avec highway=service) par les contributeurs.
>> Exemples :
>> https://www.openstreetmap.org/#map=18/48.13893/-1.69541
>> Https://www.openstreetmap.org/#map=17/48.14052/-1.76931
>> https://www.openstreetmap.org/#map=18/47.69694/-0.87364
>>
>>
>> djakk
>>
>>
>> Le mar. 18 sept. 2018 à 11:20, djakk djakk  a
>> écrit :
>>
>>> Oui, aussi.
>>>
>>>
>>> djakk
>>>
>>> Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :
>>>
>>>> Le 18 septembre 2018, djakk djakk a écrit :
>>>>
>>>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
>>>> > n'écrives ce mail :
>>>> > https://www.openstreetmap.org/changeset/62524278
>>>> >  :O
>>>> >
>>>>
>>>> Une explication ne signifie pas accord de celui qui la reçoit.
>>>>
>>>> --
>>>> Alain Rpnpif
>>>>
>>>> ___
>>>> 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] Les bretelles

[djakk djakk]

Bon link_to et link_from ça ne marche pas, j’ai essayé !

J’ai voulu tagger les bretelles autrement car je vois chaque bretelle
faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la
valeur de la route croisée par la route principale, dans les cas les plus
simples. De ce point de vue, la bretelle ne fait pas partie de la route
principale.

Je remarque que les bretelles d’accès aux centres commerciaux sont taggées
de ce point de vue (avec highway=service) par les contributeurs. Exemples :
https://www.openstreetmap.org/#map=18/48.13893/-1.69541
Https://www.openstreetmap.org/#map=17/48.14052/-1.76931
https://www.openstreetmap.org/#map=18/47.69694/-0.87364


djakk


Le mar. 18 sept. 2018 à 11:20, djakk djakk  a écrit :

> Oui, aussi.
>
>
> djakk
>
> Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :
>
>> Le 18 septembre 2018, djakk djakk a écrit :
>>
>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
>> > n'écrives ce mail :
>> > https://www.openstreetmap.org/changeset/62524278
>> >  :O
>> >
>>
>> Une explication ne signifie pas accord de celui qui la reçoit.
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> 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] Changement unilatéral de la définition de tags

[djakk djakk]

Le sourire était plutôt crispé j’aurai dû mettre :-] !

djakk

Le mar. 18 sept. 2018 à 23:26, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

>
>
> Le mar. 18 sept. 2018 à 23:03, marc marc  a
> écrit :
>
>> djakk n'est pas un bleu même s'il est rarement aussi actif ici :)
>>
> Maoui! Il est même plus ancien contributeur que moi! Ben désolé mais en
> effet c'est pas un novice ce qui n'étonne d'autant plus.
>
> @djakk fait de l'humour dans ces changeset
> *(ne pas expérimenter ici en fait :) )*
> 
>
> Ben c'est pas un bac à sable donc non... J'ai demandé si l'on pouvait en
> mettre un en place pour des projets et des tests de comparaison sur la
> liste dev mais je pense pas avoir ciblé la bonne liste peut être tech est
> plus approprié.
> @marc marc  on a la possibilité de mettre ça
> en place ou vous avez une doc pour mettre un serveur en place "from
> scratch". Le but c'est d'avoir une image et de faire les test dessus.
> Pouvoir faire des modif dessus sans impacté le système en place et ainsi
> s'en servir pour présenter aussi des cas d'étude sur du routing ou du
> géocodage.
>
> Merci
>
>
>
>
> Cordialement,
> Jérôme Seigneuret
> ___
> 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] Changement unilatéral de la définition de tags

[djakk djakk]

Oui Marc j’ai pensé sournoisement à la mauvaise fois mais l’envie de
travailler sérieusement prend le dessus très très vite :) Explications
après le prochain paragraphe. (Oui la valeur trunk est pourrie il faudrait
peut être dire huge)

Normalement j’avais mis la bonne source pour la clé traffic (données venant
de chaque département - j’ai supposé que c’est copiable pour osm, ai-je bon
?)

Voilà ce que j’ai répondu à Stereo du Data Working group qui m’interpellait
sur un changeset récent :

« Traffic » était une première piste, la clé a toujours son intérêt (à
condition que les donnés soient copiables : la donnée vient des
départements, alors j’ai supposé que c’était compatible avec osm).
L’analyse des données du comptage routier permet d'ébaucher un réseau
routier pas forcément évident. On voit l’impact des quatre-voies : les
automobilistes ne prennent plus l’ancienne grande route naturellement la
plus directe mais la quatre-voies puis une route secondaire pas forcément
adaptée. Ça donne un réseau en arêtes de poisson autour de la quatre-voies.
La clé « traffic » ne suffit pas car le trafic interurbain (c’est-à-dire :
entre deux aires urbaines) est en général faible, du coup il faut une clé
pour classifier un itinéraire interurbain (highway_class). Alors : faut-il
une clé spéciale pour les itinéraires à l’intérieur d’une aire urbaine
(routes périurbaines, autoroutes uniquement urbaines ou Grands Boulevards
dans une ville ayant un périphérique pour le trafic de transit ?), ç’a à
l’air tentant, je vais réfléchir.
L’aspect de la route rentre aussi en compte : ça ressemble à une autoroute,
à une semi-autoroute, à une grande route classique ? (-> clé looks_like)
Je n’oublie pas l’aspect administratif : officiellement une autoroute ou
une « route pour automobiles » (clé legal).
Pour finir (pour le moment ?), il y a la performance de la route :
l’aménagement routier par rapport à son trafic (carrefour à feu connu pour
être générateur de bouchon, échangeur autoroutier dit « mal foutu » ...)
(clé performance)

@+ djakk

Ce que je pense traduire pour taggin’ mondial.
Bonus : la clé footway_class et la clé cycleway_class pour les itinéraires
pédestres et cyclables.


djakk


Le mar. 18 sept. 2018 à 23:04, Philippe Verdy  a écrit :

> Pour info une lecture pertiennte concernant le zonage urbain de l'INSEE
>
> https://www.insee.fr/fr/information/2115011
>
> Plus de concepts sur
>
> https://www.insee.fr/fr/information/2114631
>
> qui présente les données d'études proposées sur
>
> https://www.insee.fr/fr/recherche/recherche-geographique?debut=0
>
> L'INSEE n'est pas non plus la seule institution française à faire du
> zonage en France.
>
> Le mar. 18 sept. 2018 à 22:40, François Lacombe 
> a écrit :
>
>> Le mar. 18 sept. 2018 à 22:31, Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com> a écrit :
>>
>>> Certains sujets sont portés par peu de personnes car cela nécessite des
>>> connaissances métier (réseaux électriques, eau, télécom) et dont certaines
>>> informations de schématisation sont trop complexes
>>> Je parle pour  InfosReseaux  qui s'est occupé de compléter les pages
>>> concernant les réseaux électriques.
>>> D'autres touches beaucoup plus de gens et sont aussi contrôlé par
>>> beaucoup plus de personnes et retouché aussi par bien plus de monde.
>>>
>>
>> Merci :)
>>
>> Je me souviens aussi avoir commencé maladroitement en éditant directement
>> une page de features en 2012, la considérant peu à mon gout.
>> C'est le métier qui rentre.
>>
>> Penser que si on atteint le consensus même partiel, sa contribution a
>> plus de chances d'être adoptée et utilisée.
>> Il faut de l’endurance
>>
>> Bonne soirée
>>
>> François
>> ___
>> 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] zones de parcmètres

[djakk djakk]

Ok :)

Le mar. 18 sept. 2018 à 19:07, Philippe Verdy  a écrit :

> C'est pas si hors sujet que ça ! Les stationnements isolés en slalom sont
> aussi un problème dans OSM, difficiles à modéliser correctement sans
> découper très fortement les rues: on doit les marquer individuellement, le
> modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
> ils ont été mis en place que les riverains sont finalement très mécontents
> de la physionomie que prend leur quartier mis à l'écart du reste de la
> ville. Et ça se voit rapidement.
>
> On a réduit de façon mineure un problème pour en créer d'autres bien plus
> graves qui se font sentir rapidement (fermeture des commerces, désertion
> des services publics, suppression/détournement des lignes de transport,
> baisse de la valeur en revente des résidences. Difficultés d'accès pour les
> livraisons, temps de parcours allongés, même augmentation du danger pour
> les cyclistes, coût des accidents, absence de présence de la police (sauf
> pour verbaliser les résidents!), hausse des assurances et des incivilités
> et de la criminalité...
>
> Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
> d'entretenir les espaces verts, la collecte et le recyclage des ordures
> ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
> dégradent vite et vite se transforment en ghettos délaissés. Les
> propriétaires cessent aussi l'entretien régulier des locations ou leurs
> locations ne trouvent plus preneur et les tarifs baissent alors que la
> pression immobilière s'accroît encore plus dans les centres-villes qui
> restent bien desservis par les transports même quand il y a des zones
> piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).
>
> Je ne suis pas du tout convaincu que ce système a même renforcé la
> sécurité routière et que cela a accu encore plus le prix des places de
> stationnement ailleurs: cela accroit le saupoudrage résidentiel périurbain
> et la pression publique pour des lignes périurbaines supplémentaires, et de
> façon générale le besoin accru en transports publics (de plus en plus
> couteux pour les intercommunalités) et les temps de transports. Au final,
> on déplace le problème et renforce la pression des espaces dédiés aux
> voitures dans les zones périurbaines "rurbanisées" (pas mieux loties an
> services publics, mais avec plus de constructions de parkings et une
> artificialisation accrue des sols et un gaspillage des espaces ruraux
> naturels et agricoles).
>
> Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
> voiture particulière ni apporter une réelle "tranquilité" pour les
> résidents de ces rues transformées en îles-ghettos. Au final on force des
> populations à aller plus loin alors que la ville devrait au contraire se
> densifier et se mixifier davantage.
>
> Le mar. 18 sept. 2018 à 17:30, djakk djakk  a
> écrit :
>
>> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
>> trouve :)
>>
>> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
>> la peine.
>>
>>
>> djakk
>>
>>
>> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
>> écrit :
>>
>>> note : les polygones s'appliquent essentiellement au stationnement le
>>> long des voies publiques, mais excluent les aires de staionnement avec
>>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>>> trous disséminés.
>>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>>> stationnement sans conducteur visible à proximité immédiate ou encore au
>>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>>> barrière avec un ticket qui facturera en sortie les premières secondes de
>>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>>> horodateurs).
>>> En gros les zones de stationnement sont peut-être affichées sommairement
>>> sur les sites des municipalités, à titre informatif, mais le terrain
>>> détaille les condi

Re: [OSM-talk-fr] Impasse

[djakk djakk]

Un tribunal, ou une université, ou une sous-préfecture, je le résumerai à
des emplois de bureau ...

Mais, ça n’est pas le bon sujet ! ;P

Pour les impasses, en faisant une requête overpass-turbo, je me rend compte
que le noexit sur les ways est pas mal utilisé malgré “l’interdiction” du
wiki ...


djakk


Le lun. 17 sept. 2018 à 20:57, Philippe Verdy  a écrit :

> J'en reviens donc à l'idée d'ajouter dans OSM les limites des unités
> urbaines (au sens de l'INSEE) maintenant fixées plus ou moins sur les
> "pays" (anciens pays Voynet, réformés par les lois depuis 2014, dont la loi
> SRU et maintenant composés d'intercommunalités entières).
>
> Ca limite l'impact : le Pays de Rennes par exemple comprend Rennes
> Métropole dont Rennes est la "ville" centre. mais les autres
> intercommunalités autour n'ont pas de "ville" ("city") centre. Mais au
> mieux des "town".  ET on évite des trucs classés par djakk comme "city"
> tels que, en Bretagne: Callac, Merdrignac, Collinée, Plélan-le-Grand. En
> revanche, Redon et Fougères passent le critère en tant que ville centre de
> leur pays... mais pas Vitré (exception due cependant à la dualité de
> l'arrondissement de Fougères-Vitré où l'Etat a accepté de maintenir des
> services délocalisés à Vitré).
>
> On pourrait avoir d'autres critères comme la présence d'un tribunal
> d'instance ou un tribunal du commerce mais la réforme profonde de
> l'institution judiciaire en fait fermer beaucoup...
>
> La présence d'une université est discutable (les universités bretonnes ont
> ouvert diverses "antennes" hors de leur siège) mais est pourtant un signe
> de dynamisme économique des commerces et services. La présence d'un lycée
> ne me parait pas pertinente ou suffisante (des lycées déménagent aussi pour
> s'installer en périphérie des villes). Mais pour les universités (publiques
> ou reconnues d'intéret public comme lm'université catholique d'Angers...
> une exception qu'on n'a pas besoin de gérer car Angers est clairement déjà
> une ville sans ce critère et a aussi une université publique) on a une
> liste complète facilement atteignable.
>
>
>
>
> Le lun. 17 sept. 2018 à 20:44, Philippe Verdy  a
> écrit :
>
>> Je vois que djakk continue de changer les villes en Bretagne, Pays de la
>> Loire, Normandie. Apparemmetn il a pris le parti pris d'upgrader les
>> communes centre des intercommunalités, mais attention elles bougent
>> beaucoup, et leur siège n'est pas toujours dans la ville centre (au sens du
>> zonage urbain de l'INSEE).
>>
>> Je pense que l'upgrade ne devrait concerner QUE les villes centre des
>> "pays" (ayant un ou plusieurs SCOTs, il y en a plusieurs généralement quand
>> un des EPCI est une métropole ou une communauté urbaine, pas une simple
>> communauté d'agglomération), et que les pays sont plus ou moins calqué sur
>> les "unités urbaines" de l'INSEE, ou sinon les villes centre des aires
>> urbaines de population suffisante.
>>
>> Mais on n'a pas encore défini les seuils, pour se passer de la règle
>> actuelle de la population municipale (où on garde certaines exptions pour
>> les seuils quasiment atteints ou qui ont été atteints il y a encore peu de
>> temps, pas plus de 20 ans AMHA, même si la population a légèrement baissé
>> depuis, ou si c'est une ville chef-lieu de département, en excluant les
>> chef-lieux d'arrondissements en phase de désuétude, et upgradant en "city"
>> les villes chef-lieux de régions (celles d'avant la réforme de fusion des
>> régions) y compris les régions d'autre-mer, mais pas les petites
>> collectivités d'outre-mer insulaires (elles ont déjà un capital=3 mais si
>> on parle de Saint-Pierre à CPM, c'est clairement pas une "city" au
>> détriment des villes canadiennes voisines comme Halifax)
>>
>> On a des données objectives sur les unités urbaines et les aires urbaines.
>>
>> Le lun. 17 sept. 2018 à 15:04, JB  a écrit :
>>
>>> Euh,
>>> On pourrait avoir une vue d'ensemble, de conflits d'intérêts possibles,
>>> de projets perso/professionnels derrière tout ça ?
>>> Ça ressemble de plus en plus à un taggage « pour mon projet ».
>>> D'abord on redéfinit les villes (tiens, ça aiderait bien pour de la
>>> moyenne/petite échelle), puis les trunk (idem), puis les bretelles
>>> (chouette, encore pareil), les impasses (on les supprimera du graphe
>>> routier). Ça râle un peu, alors on utilise un tag en plus «looks_like» pour
>>> ne pas modifier les autres. La suite, ce sera d'ajouter color=* sur les
>>> ways pour ne pas le coder dans la feuille de style ?
>>>

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[djakk djakk]

Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation de
Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas vérifié si le
contenu est cohérent).
L’argument qui a fait mouche chez moi : l’absence de retro-compatibilité.

Je présenterai sur la mailing-list tagging (mondiale) un moyen d’arriver à
une définition commune dans le monde entier pour la définition des routes,
en contournant l’actuelle clé highway au lieu de changer brutalement la
définition de ses valeurs. Je trouve que c’est améliorer Openstreetmap de
gommer (autant que possible) les différences entre pays sur les définitions
de valeurs.
(Comment ? en décomposant ce qui fait une route, de l’aspect visuel à la
définition administrative à l’utilisation plus ou moins intensive, pour du
trajet interurbain ou du trajet intra-urbain).


@+
djakk


Le mar. 18 sept. 2018 à 09:31, Christian Quest  a
écrit :

> Le dim. 16 sept. 2018 à 15:43, djakk djakk  a
> écrit :
>
>> Je pense que je rajoute de l’information sans en supprimer ... ? Bon
>> certes je chamboule l’existant ...
>>
>> djakk
>>
>
> Dommage de procéder ainsi "en force".
>
> Le tagging sur OSM fonctionne grâce à un consensus, il faut le respecter
> ou ouvrir une discussion (large) pour faire naître un nouveau consensus et
> ne pas "chambouler" ainsi l'existant, au risque d'un douloureux retour de
> flamme.
>
>
> --
> 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] SOTM-FR 2019 et Fotoquest GO

[djakk djakk]

Bonjour sebseb ! Bienvenue !

Oh, le fond de carte de fotoquest est openstreetmap :) Il y aura peut être
un entrefilet dans weeklyosm à ce sujet ?


djakk


Le mar. 18 sept. 2018 à 17:43, Philippe Verdy  a écrit :

> En gros c'est une sorte de Pokemon Go pour trouver un trésor (1 ou 2 euros
> par photo géolocalisée au point prédéfini, les points étant disposés sur un
> maillage carré quasi régulier tous les kilomètres, cela fait juste une
> photo par kilomètre carré. Mais les points désignés sont choisis un peu au
> hasard et pas accessibles (les photos les plus valorisées sont au milieu de
> lacs ou étangs ou dans des zones privées).
>
> Je ne vois pas trop ce que va faire l'aspect scientifique du projet avec
> des photos sur un maillage aussi lâche. Si toutes les emplacements proposés
> sont visités, cela coûterait une fortune et je doute de la rentabilité
> réelle. Pour moi c'est plus un jeu mobile comme Pokemon Go, mais on ne peut
> pas y jouer longtemps ou on oblige les joueurs à prendre des risques et
> bafouer la loi et le droit privé, et aussi dépenser beaucoup en déplacement
> (bien plus que la rémunération proposée au final chaque joueur ne fera
> qu'un cliché ou deux et l'appli ensuite ne sert plus à grand chose, sauf
> comme support de diffusion publicitaire).
>
> Je me demande même si l'appli n'est pas là non pas pour obtenir les
> photos, mais plutôt les parcours géolocalisés utilisés pour parvenir aux
> points proposés, et mesurer les temps d'accès, bref collecter les traces
> GPS (plus ou moins précises sur les mobiles) encore très utilisées en
> Allemagne.
>
> Si l'appli ne décolle pas en France (sauf quelques points visités ça et là
> sans doute par des visiteurs germanophones) c'est parce qu'elle n'a aucune
> description en français, et la page "à propos" en allemand mélange tout y
> compris des clauses de vie privée (pour le RGPD sans doute) assez obscures.
> J'ai donc du mal à être convaincu du bénéfice qu'on aurait en France, en
> comparaison de Mapillary qui a des buts plus clairs, et sinon de l'imagerie
> aérienne (maintenant de très bonne qualité en France métropolitaine) et des
> données open data des services publics et exploitants privés de concessions
> publiques.
>
>
>
> Le mar. 18 sept. 2018 à 16:06,  a écrit :
>
>>
>>
>> Bonjour à tous,
>> je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois.
>> J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête
>> mais à tout hasard ;)
>>
>> J'ai vu que la ville de Montpellier était seule candidate pour le State
>> Of The Map FR de l'année prochaine
>> et sauf erreur de ma part la date de proclamation des résultats est
>> dépassée mais je n'ai pas vu de confirmation...
>> J'ai loupé quelque chose ?
>>
>> Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je
>> souhaite évoquer ;)
>> Connaissez vous http://fotoquest-go.org/en/map/ ou
>> http://fotoquest-go.org/en ?
>> C'est une initiative autrichien de sciences participatives relatives à
>> l'occupation du sol.
>> A priori ça n'a pas trop de succès, notamment sur le territoire français
>> mais je trouve le sujet intéressant.
>>
>> Bien cordialement
>> S. Silvestre
>>
>> ___
>> 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] zones de parcmètres

[djakk djakk]

(Je répondais à Philippe)

Le mar. 18 sept. 2018 à 17:30, djakk djakk  a écrit :

> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
> trouve :)
>
> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
> la peine.
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
> écrit :
>
>> note : les polygones s'appliquent essentiellement au stationnement le
>> long des voies publiques, mais excluent les aires de staionnement avec
>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>> trous disséminés.
>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>> stationnement sans conducteur visible à proximité immédiate ou encore au
>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>> barrière avec un ticket qui facturera en sortie les premières secondes de
>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>> horodateurs).
>> En gros les zones de stationnement sont peut-être affichées sommairement
>> sur les sites des municipalités, à titre informatif, mais le terrain
>> détaille les conditions réelles avec une précision bien supérieure et un
>> équipement ou marquage détaillé.
>>
>> Taguer au niveau des voies publiques sera nettement supérieur (et on
>> pourra aussi délimiter les véritables "parking lanes" ont il y a
>> effectivement des places, ou des emplacements individuels qu'on peut taguer
>> directement
>>
>> Les emplacements individuels sont dans des rues résidentielles de plus en
>> plus nombreuses où les municipalités les installent avec sens de
>> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
>> côté des emplacements, la deuxième formant des zones d'attente. Le but de
>> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
>> pas (pas évident quand on en trouve même dans des rues où circulent des bus
>> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
>> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
>> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
>> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
>> stationnement (le stationnement par côté alterné disparait un peu partout)
>> et réduit largement le nombre de places disponibles, pour forcer les
>> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
>> en commun dans le centre. Ces places isolées en slalom sont souvent
>> gratuites (au risque et péril du propriétaire du véhicule) car la
>> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
>> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
>> ou doivent payer cher des stationnements loin de chez eux ou louer des
>> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
>> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
>> livraisons à domicile sont également difficiles, comme les déménagements.
>>
>> Si le but était de réduire la vitesse ou le traffic, il était suffisant
>> de mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards
>> qui se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux
>> en toute saison et à toute heure pour les cyclistes  qui ne bénéficient pas
>> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
>> ces stationnements isolés qui transforment une rue résidentielle en piste
>> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
>> propres résidents et ne réduit pas les accidents (mais favorisent le
>> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
>> assurances...). Au final cela coûte cher à tout le monde et cela isole des
>> quartiers qui se voient vidés aussi d'activités, de commerces et services
>> pour les transformer en banlieues ou ghettos sociaux.
>>
>>
>> Le mar. 18 sept. 2018 à 16:05, djakk djakk  

Re: [OSM-talk-fr] zones de parcmètres

[djakk djakk]

Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
trouve :)

Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
la peine.


djakk


Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a écrit :

> note : les polygones s'appliquent essentiellement au stationnement le long
> des voies publiques, mais excluent les aires de staionnement avec
> entrées/sorties de parking dédiées qui ont leurs propres règles.
> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
> trous disséminés.
> Je pense que cela devrait plutôt être tagué le long des voies, en même
> temps que les "parking lanes" et où sont disposés (à vue) aussi les
> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
> stationnement sans conducteur visible à proximité immédiate ou encore au
> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
> barrière avec un ticket qui facturera en sortie les premières secondes de
> dépassement, car dans ce cas cela devient payant dès la première minute aux
> horodateurs).
> En gros les zones de stationnement sont peut-être affichées sommairement
> sur les sites des municipalités, à titre informatif, mais le terrain
> détaille les conditions réelles avec une précision bien supérieure et un
> équipement ou marquage détaillé.
>
> Taguer au niveau des voies publiques sera nettement supérieur (et on
> pourra aussi délimiter les véritables "parking lanes" ont il y a
> effectivement des places, ou des emplacements individuels qu'on peut taguer
> directement
>
> Les emplacements individuels sont dans des rues résidentielles de plus en
> plus nombreuses où les municipalités les installent avec sens de
> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
> côté des emplacements, la deuxième formant des zones d'attente. Le but de
> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
> pas (pas évident quand on en trouve même dans des rues où circulent des bus
> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
> stationnement (le stationnement par côté alterné disparait un peu partout)
> et réduit largement le nombre de places disponibles, pour forcer les
> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
> en commun dans le centre. Ces places isolées en slalom sont souvent
> gratuites (au risque et péril du propriétaire du véhicule) car la
> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
> ou doivent payer cher des stationnements loin de chez eux ou louer des
> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
> livraisons à domicile sont également difficiles, comme les déménagements.
>
> Si le but était de réduire la vitesse ou le traffic, il était suffisant de
> mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards qui
> se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux en
> toute saison et à toute heure pour les cyclistes  qui ne bénéficient pas
> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
> ces stationnements isolés qui transforment une rue résidentielle en piste
> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
> propres résidents et ne réduit pas les accidents (mais favorisent le
> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
> assurances...). Au final cela coûte cher à tout le monde et cela isole des
> quartiers qui se voient vidés aussi d'activités, de commerces et services
> pour les transformer en banlieues ou ghettos sociaux.
>
>
> Le mar. 18 sept. 2018 à 16:05, djakk djakk  a
> écrit :
>
>> Yo !
>>
>> Est-ce que tu penses tagger la zone payante avec un polygone ?
>> Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
>> dans des polygones, faire des polygones qui se superposent et donner un
>> indice pour choisir le bon polygone à un point donné.
>>
>>
>> djakk
>>
>> Le

Re: [OSM-talk-fr] zones de parcmètres

[djakk djakk]

Yo !

Est-ce que tu penses tagger la zone payante avec un polygone ?
Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
dans des polygones, faire des polygones qui se superposent et donner un
indice pour choisir le bon polygone à un point donné.


djakk

Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a écrit :

> Le 2018-09-18 15:30, Florian LAINEZ a écrit :
> > Hello,
> > En ville, le stationnement est souvent régulé avec des zones.
> > Celles-ci portent souvent un nom de couleur, mais ce n'est pas
> > toujours le cas.
> > Sous quel tag signaleriez-vous ça ?
> >
> > Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
> > https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
> > Je m'intéresse pour l'instant aux parcmètres de la ville de
> > Montrouge et j'ai documenté ça ici :
> > https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres
> >
> > La première proposition était charge=FR:Montrouge:zone rouge mais à
> > priori le tag "charge" indique plutôt des prix, pas des zones.
> >
> > overpasse m'informe qu'en France, les tags suivants sont utilisés,
> > même s'ils sont assez peu répandus :
> > parking:ticket:zone
> > parking_tickets:zone:FR
> > parking_tickets:zone:colour
> > vending_machine:zone
> >
> > Le plus clair et universel me parait parking:ticket:zone=nom de la
> > couleur
> > Et vous ?
> >
> > --
> >
> > FLORIAN LAINEZ
> > @overflorian [1]
> >
>
> Ça serait intéressant : À Rennes on a bien indiqué les zones, mais sous
> la forme :
>
> note=green zone
>
> par exemple...
>
> ___
> 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] Les bretelles

[djakk djakk]

Oui, aussi.


djakk

Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :

> Le 18 septembre 2018, djakk djakk a écrit :
>
> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
> > n'écrives ce mail :
> > https://www.openstreetmap.org/changeset/62524278
> >  :O
> >
>
> Une explication ne signifie pas accord de celui qui la reçoit.
>
> --
> Alain Rpnpif
>
> ___
> 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] Les bretelles

[djakk djakk]

Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
n'écrives ce mail :
https://www.openstreetmap.org/changeset/62524278
 :O

Le mar. 18 sept. 2018 à 09:48, Philippe Verdy  a écrit :

> Note: djakk djakk s'est maintenant lancé dan la conversion de "village" en
> "town", en piochant au hasard (là encore en Bretagne et à proximité autour
> en Basse-Normandie, Maine, Anjou, Loire-Atlantique et Vendée).
> Du coup on a des villages mieux classés que les réelles villes pourtant
> pas loin.
> Et ça se voit dans le rendu final par défaut sur osm.org !
> Il n'y a pas de critère bien défini. On dirait qu'il a décidé de piocher
> non pas les bourgs-centre des bassins de vie comme il semble l'indiquer
> mais n'importe quelle commune siège d'une communauté de communes (dont
> certaines n'existent déjà plus depuis début 2017 ou sont devenues des
> communes nouvelles).
>
> Note: les intercommunalités depuis 2017 ont toutes au moins 15 000
> habitants, mais ça s'est fait de façon forcée, et pas forcément selon les
> bassins de vie (qui sont plutôt concertés au niveau des "pays" qui
> regroupaient déjà des intercommunalités mais ont été aussi redessinés un
> peu lorsque les intercommunalités ont été forcées de fusionner).
>
> Je ne pense pas que les intercommunalités soient pertinentes, d'autant
> plus que leur siège n'est pas forcément non plus dans la commune centre. La
> distribution des présences de services publics résulte d'accords locaux
> entre communes, le siège de l'intercommunalité résulte aussi de choix
> budgétaires et des ressources immobilières, ou de la présence de lignes de
> transports. Et même regroupées de force, les intercommunalités ne sont pas
> centrées sur leur ville siège dont le bassin de vie et l'attractivité
> réelle peut sortir aussi de leur propre territoire et couvrir des communes
> de l'intercommunaltié voisine.
>
> Je suggère de ne pas expérimenter ces changements dans la base OSM
> elle-même mais plutôt de mettre au point une base à part sous forme de
> liste à partir d'une feuille de calcul pour créer un CSV et générer une
> carte uMap permettant de visualiser ces listes sous forme de nuage de
> points selon plusieurs critères. Ca permet de ne pas aller trop vite dans
> la sélection, vérifier la densité des points selon le niveau de zoom,
> ajuster les critères pertinents à retenir sur chaque niveau de zoom, et
> ensuite définir éventuellement des tags OSM adaptés, et d'en discuter et
> les documenter sur une liste internationale.
>
> Et ensuite cela permettra aussi de faire les éventuels changements dans
> les clés existantes sans en oublier et non au hasard, et même de les
> vérifier automatiquement (par exemple, analyse Osmose vérifiant ces
> critères). Le rendu suivra ensuite concernant les éventuelles clés
> supplémentaires documentées sur lesquelles on aura importé correctement les
> valeurs de façon cohérente et vérifiable. Le rendu ensuite pourra suivre et
> s'adapter aux critères retenus pour chacun de ses niveaux de zoom. ou en
> fonction de la densité relative des libellés
>
> En attendant, les changements apportés sont plus une pollution et sont une
> gêne visuelle évidente pour les réutilisateurs des cartes rendues
> standards, notamment pour les rendus voisins des niveaux de zoom 9-10-11 en
> France.
>
>
>
> Le mar. 18 sept. 2018 à 09:26, Christian Quest 
> a écrit :
>
>> Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo 
>> a écrit :
>>
>>> > Du coup je propose link_from et link_to : pour une bretelle dans le
>>> > sens autoroute vers tertiary, on aura link_from=motorway et
>>> > link_to=tertiary.
>>>
>>> Cette information peut être calculé depuis la topologie et là n'apporte
>>> rien, même pas de la cohérence.
>>>
>>
>> Je ne vois pas l'intérêt non plus.
>>
>> L'info est déjà dans la topologie des données et une requête postgis (ou
>> autre) permet de savoir à quoi est connecté un tronçon de _link si on en a
>> vraiment besoin.
>>
>> Les données OSM sont des données GEO et à ce titre, on a plein
>> d'informations latentes que nous offrent la topologie et la géo, même si
>> elle ne figurent pas sur chaque objet en tant que tel.
>> Par contre pour tirer le maximum des données OSM il faut savoir exploiter
>> topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à
>> rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne
>> seront pas évident à conserver à jour).
>>
>> --
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Et l’aéroport Charles de Gaulle avec ses commerces, ses employés et ses
hôtels, capitale de zone d’emploi selon l’INSEE, est-il une ville ? :)

Je serai très apolitique et loin des frontières administratives et de la
densité du bâti pour la clé place, d’où mon intérêt pour les zones
d’emploi, les bassins de vie, et il y a aussi l’aire urbaine.


djakk

Le lun. 17 sept. 2018 à 11:32, Rpnpif  a écrit :

> Le 17 septembre 2018, ades a écrit :
>
> > La def donnée par l’Insee parrait plus appropriée :  >2000 habitants +
> dist. entre bât < 200 m .
> > L’ajout de la présence de services (qui avait été ajoutée et que Jérôme
> a supprimé) me semble pourtant bien correspondre à ce qu’est une ville
>
> Oui, calculer cette distance entre bâti n'est pas simple sauf à
> utiliser des chiffres extérieurs.
>
> De même pour la présence de services, quels services, combien, sur
> quels critères objectifs les choisir ?
> Un bourg avec un très gros ensemble d'une certaine activité (par
> exemple un très gros hôpital, ou bien trois grosses sociétés) et avec
> 1500 habitants est-il une ville ?
>
> De même, une station balnéaire de 1800 habitants l'hiver et de 15000
> pendant 2 mois l'été et dont les 3/4 des commerces sont fermés
> 10 mois dans l'année est-elle une ville ?
>
> --
> Alain Rpnpif
>
> ___
> 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] Classement ville/village - city/town/village

[djakk djakk]

Oui effectivement ! Je me suis rendu compte que la clé place manque de
granuralité, du coup je suis revenu en arrière, en ajoutant tout de même
l’info capital:INSEE=“zone d’emploi”.

Ca serait bien de passer à une granularité plus forte, passer de village -
town - city à village - small_town - large_town - small_city - medium_city
- large_city - metropolis.
Ancenis serait pas mal en large_town ou en small_city ? Angers serait une
medium_city, Nantes une large_, Paris une metropolis.

Seulement ces valeurs qui étaient parfois rendues par la feuille de style
“officielle” ont été supprimées : en pratique on ne va pas utiliser une
valeur qui efface la ville de la carte ...

Du coup je compte demander à gravitystorm/openstreetmap-carto de reprendre
en compte ces valeurs, avant de changer les valeurs de place ... on risque
de me répondre qu’il faut d’abord utiliser la valeur avant de la prendre en
compte :-]


djakk


Le dim. 16 sept. 2018 à 20:23, Stéphane Péneau 
a écrit :

> Je disais ça en rigolant, mais lorsque je vois par exemple le "bourg"
> d'Ancenis, commune de 7800 habitants, qui passe de place=village à
> place=city, je rigole un peu moins.
> Ensuite, lorsque je vois que tu as modifié la page wiki du tag "place"
> pour que ça convienne à ta volonté, je commence à trouver ça pas drôle du
> tout.
>
> Que tu sois bourré d'énergie pour faire bouger les choses, super, mais que
> tu le fasses sans tenir compte de ce qui fait la force d'Osm, c'est à dire
> sa communauté, alors là je suis moins d'accord.
>
> Franchement, Ancenis, au même niveau que Nantes, dans les 10 plus
> importantes villes de france, faut pas déconner
>
> Stf
>
>
> Le 16/09/2018 à 18:39, djakk djakk a écrit :
>
> Ahah :)
>
>
> Le dim. 16 sept. 2018 à 18:32, Stéphane Péneau 
> a écrit :
>
>> Wow wow !! Dis-nous un peu ce que tu as modifié.
>> Tu fais un peu peur là ! On dirait que tu tournes à la Red-Bull 24/24
>> depuis quelque temps !
>>
>> Stf
>>
>>
>> Le 16/09/2018 à 15:50, djakk djakk a écrit :
>>
>> Yo,
>>
>> bon après avoir modifié les villes du grand ouest, je me rend compte
>> qu’il manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin
>> de : village (les “village”) - gros village (les “Town”) - petite ville
>> (exemple : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?)
>> - grosse ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city
>> ?)
>>
>>
>> djakk
>>
>> Le mar. 11 sept. 2018 à 15:04, Philippe Verdy  a
>> écrit :
>>
>>> on a déjà les capital=yes (pour les capitales nationales) et
>>> capital= pour les niveaux inférieurs
>>>
>>> Attributs un peu redondant avec les "admin_centre" des relations
>>> précisant ces niveaux, mais il y a des utilisations de ces attributs pour
>>> ne pas avoir à consulter la liste de toutes les relations qui pourraient
>>> référencer un noeud place=*, et ensuite les télécharger toutes pour voir si
>>> cette référence a un rôle admin_centre (qui plus est n'est pas toujours
>>> unique par relation, par exemple dans des pays où peuvent coexister
>>> plusieurs "capitales" selon l'usage:  administratif, législatif,
>>> présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois
>>> aussi...)
>>>
>>> Le mar. 11 sept. 2018 à 14:55, djakk djakk  a
>>> écrit :
>>>
>>>> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple
>>>> je verrai Figeac comme une “city” car le seul grand ensemble urbain
>>>> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac
>>>> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça
>>>> serait même “village”.
>>>>
>>>> Comme pour les “highway” une rue tertiary de Paris à dans doute autant
>>>> de circulation qu’une “primary” de Figeac.
>>>>
>>>> La définition de “city” sur le wiki anglais parle de relativité :  Use
>>>> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag
>>>> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest
>>>> settlement or settlements within a territory,
>>>>
>>>>
>>>> djakk
>>>>
>>>>
>>>> Le mar. 11 sept. 2018 à 12:33, Rpnpif  a écrit :
>>>>
>>>>> Le 10 septembre 2018, djakk djakk a écrit :
>>>>>
>>>>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone
>>>>> d’emploi
>>>

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Ahah :)


Le dim. 16 sept. 2018 à 18:32, Stéphane Péneau 
a écrit :

> Wow wow !! Dis-nous un peu ce que tu as modifié.
> Tu fais un peu peur là ! On dirait que tu tournes à la Red-Bull 24/24
> depuis quelque temps !
>
> Stf
>
>
> Le 16/09/2018 à 15:50, djakk djakk a écrit :
>
> Yo,
>
> bon après avoir modifié les villes du grand ouest, je me rend compte qu’il
> manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin de :
> village (les “village”) - gros village (les “Town”) - petite ville (exemple
> : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) - grosse
> ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city ?)
>
>
> djakk
>
> Le mar. 11 sept. 2018 à 15:04, Philippe Verdy  a
> écrit :
>
>> on a déjà les capital=yes (pour les capitales nationales) et
>> capital= pour les niveaux inférieurs
>>
>> Attributs un peu redondant avec les "admin_centre" des relations
>> précisant ces niveaux, mais il y a des utilisations de ces attributs pour
>> ne pas avoir à consulter la liste de toutes les relations qui pourraient
>> référencer un noeud place=*, et ensuite les télécharger toutes pour voir si
>> cette référence a un rôle admin_centre (qui plus est n'est pas toujours
>> unique par relation, par exemple dans des pays où peuvent coexister
>> plusieurs "capitales" selon l'usage:  administratif, législatif,
>> présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois
>> aussi...)
>>
>> Le mar. 11 sept. 2018 à 14:55, djakk djakk  a
>> écrit :
>>
>>> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple
>>> je verrai Figeac comme une “city” car le seul grand ensemble urbain
>>> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac
>>> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça
>>> serait même “village”.
>>>
>>> Comme pour les “highway” une rue tertiary de Paris à dans doute autant
>>> de circulation qu’une “primary” de Figeac.
>>>
>>> La définition de “city” sur le wiki anglais parle de relativité :  Use
>>> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag
>>> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest
>>> settlement or settlements within a territory,
>>>
>>>
>>> djakk
>>>
>>>
>>> Le mar. 11 sept. 2018 à 12:33, Rpnpif  a écrit :
>>>
>>>> Le 10 septembre 2018, djakk djakk a écrit :
>>>>
>>>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone
>>>> d’emploi
>>>> > implique être place=Town au moins.
>>>>
>>>> Oui mais non, il ne faut pas oublier que la population des villes et
>>>> villages en Grande-Bretagne est souvent plus importantes qu'en France,
>>>> que celle des villages et villes de Lozère est différente (inférieure)
>>>> de celle du Nord de la France ou de l'Ouest.
>>>>
>>>> Ne pas oublier aussi que certains maires se font mousser en appelant
>>>> ville leur village, que les gens de l'Ouest appelle village, les
>>>> hameaux et bourg le... bourg principal.
>>>>
>>>> Faute de mieux, je pense que le wiki français distinguant en fonction de
>>>> la population fait un bon compromis.
>>>>
>>>> Ce n'est que mon avis.
>>>>
>>>> --
>>>> Alain Rpnpif
>>>>
>>>> ___
>>>> 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 
> listTalk-fr@openstreetmap.orghttps://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] Classement ville/village - city/town/village

[djakk djakk]

Oui bon j’ai mes marottes :P

Tu trouves les tags mauvais proposes donc des améliorations au lieu de
suggérer de ne rien faire :O

Le dim. 16 sept. 2018 à 18:33, ades  a écrit :

> Et bien bon courage, place est renseigné 5 091 400 fois par 59 683
> contributeurs, ‘city’ est utilisé 19446 fois, town 109 939 fois , village 1
> 229 929 fois; ça te fait du pain sur la planche ;-) à moins qu’un grand
> manitou US te licencie avant que tu finisse cette modeste tâche  ;-)
>
> Plus sérieusement peu importe la pertinence ou pas de tes remarques ou
> modifications,  les tags sont tous mauvais, ils constituent juste une
> partie d'une règle du jeu et si tu joues, tu accepte la règle… Tu peux
> proposer de la modifier mais faut poser la question avant et en discuter.
>
> Maintenant quand tu auras fini les ‘place’ je te recommande de te pencher
> sur ‘landuse’  et ‘nature’ par exemple tu aurais du grain à moudre ;-)
>
> > Le 16 sept. 2018 à 15:50, djakk djakk  a écrit :
> >
> > Yo,
> >
> > bon après avoir modifié les villes du grand ouest, je me rend compte
> qu’il manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin
> de : village (les “village”) - gros village (les “Town”) - petite ville
> (exemple : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?)
> - grosse ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city
> ?)
> >
> >
> > 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

Re: [OSM-talk-fr] Impasse

[djakk djakk]

Pas de soucis Frédéric  ;) En fait je parle de sujets sur lesquels j’ai une
vue depuis un certain temps ;)

J’ai réfléchi au préprocess mais ça ne marche pas dans certains cas (le
réseau routier d’une île ou d’une péninsule).


djakk


Le dim. 16 sept. 2018 à 16:03, Frédéric Rodrigo  a
écrit :

> Le 16/09/2018 à 15:37, djakk djakk a écrit :
> > Salut !
> > Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin
> > d’avoir l’information sur toutes les way de l’impasse. But =
> > transmettre l’info au moteur de rendu.
> > Je croyais que noexit était fait pour mais apparement c’est plutôt
> > pour ne pas affoler les éditeurs sur une éventuelle mauvaise connexion
> > avec une autre way.
> > Dois-je continuer à utiliser noexit=yes sur les ways, ou trouver une
> > autre clé ?
> >
> > PS : difficile de calculer ça, pensez au réseau routier de Belle-Île ;)
> >
>
> Désolé de te répondre comme ça.
>
> Mais vu tes dernières propositions et ta façon de partir bille en tête.
> Je pense que pour l'instant l'important est de rien faire et surtout de
> na pas modifier en masse OSM ou d'inventer des tags ou des usages. Le
> plus important est peut-être déjà de réparer ce que tu as fait.
>
> Tu as visiblement des besoins particulier de rendu, regarde du coté du
> préprossing ce qu tu peux faire, et c'est faisable.
>
> Frédéric.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Yo,

bon après avoir modifié les villes du grand ouest, je me rend compte qu’il
manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin de :
village (les “village”) - gros village (les “Town”) - petite ville (exemple
: Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) - grosse
ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city ?)


djakk

Le mar. 11 sept. 2018 à 15:04, Philippe Verdy  a écrit :

> on a déjà les capital=yes (pour les capitales nationales) et
> capital= pour les niveaux inférieurs
>
> Attributs un peu redondant avec les "admin_centre" des relations précisant
> ces niveaux, mais il y a des utilisations de ces attributs pour ne pas
> avoir à consulter la liste de toutes les relations qui pourraient
> référencer un noeud place=*, et ensuite les télécharger toutes pour voir si
> cette référence a un rôle admin_centre (qui plus est n'est pas toujours
> unique par relation, par exemple dans des pays où peuvent coexister
> plusieurs "capitales" selon l'usage:  administratif, législatif,
> présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois
> aussi...)
>
> Le mar. 11 sept. 2018 à 14:55, djakk djakk  a
> écrit :
>
>> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple
>> je verrai Figeac comme une “city” car le seul grand ensemble urbain
>> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac
>> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça
>> serait même “village”.
>>
>> Comme pour les “highway” une rue tertiary de Paris à dans doute autant de
>> circulation qu’une “primary” de Figeac.
>>
>> La définition de “city” sur le wiki anglais parle de relativité :  Use
>> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag
>> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest
>> settlement or settlements within a territory,
>>
>>
>> djakk
>>
>>
>> Le mar. 11 sept. 2018 à 12:33, Rpnpif  a écrit :
>>
>>> Le 10 septembre 2018, djakk djakk a écrit :
>>>
>>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone
>>> d’emploi
>>> > implique être place=Town au moins.
>>>
>>> Oui mais non, il ne faut pas oublier que la population des villes et
>>> villages en Grande-Bretagne est souvent plus importantes qu'en France,
>>> que celle des villages et villes de Lozère est différente (inférieure)
>>> de celle du Nord de la France ou de l'Ouest.
>>>
>>> Ne pas oublier aussi que certains maires se font mousser en appelant
>>> ville leur village, que les gens de l'Ouest appelle village, les
>>> hameaux et bourg le... bourg principal.
>>>
>>> Faute de mieux, je pense que le wiki français distinguant en fonction de
>>> la population fait un bon compromis.
>>>
>>> Ce n'est que mon avis.
>>>
>>> --
>>> Alain Rpnpif
>>>
>>> ___
>>> 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] Changement unilatéral de la définition de tags

[djakk djakk]

Je pense que je rajoute de l’information sans en supprimer ... ? Bon certes
je chamboule l’existant ...

djakk

Le dim. 16 sept. 2018 à 13:51, Philippe Verdy  a écrit :

> Djakk aussi met des noexit=yes un peu partout (sur les voies, pas sur le
> noeud final, et même quand elles ont pourtant bien une issue!)
>
> Le dim. 16 sept. 2018 à 13:48, Philippe Verdy  a
> écrit :
>
>> De même djakk a transformé unilatéralement des "highway=trunk_link" en
>> "highway=tertiary"+"link=trunk" ! Ce ne sont même plus des bretelles, alors
>> même qu'une partie de la voie est encore à 110 km/h, et qu'il n'y a
>> strictement aucune adresse le long de ces voies de décélération en sens
>> unique, et qu'elles ne font pas du tout partie du réseau "tertiaire"
>> (normalement partie du réseau communal, pas intercommunal).
>>
>> Evoquer ici des solutions à son "problème" ne signifie pas qu'il n'y a a
>> pas d'autres alternatives ni d'autres méthodes déjà existantes pour
>> consolider les pratiques. Djakk clairement fait du tagging pour le rendu
>> façon Michelin (interdit pour des raisons de droit d'auteur en plus) ! Nous
>> on veut s'appuyer sur des données objectives et raisonnablement observables
>> ou vérifiables dans des données libres, pas sur des cartes propriétaires.
>>
>> Le dim. 16 sept. 2018 à 13:40, Philippe Verdy  a
>> écrit :
>>
>>> De même le reclassement par djakk de la D29 autour de Rennes de
>>> "primary" en "trunk" est totalement faux.
>>> Voilà qui va compliquer notre tâche en plus pour requalifier les limites
>>> de 90 à 80.
>>>
>>> Merci djakk de ne pas continuer sur cette voie et même annuler ton
>>> "essai". Clairement la D29 n'est pas du tout comme la rocade de Rennes,
>>> c'est un itinéraire bis recommandé poru les poids lourds pour éviter la
>>> rocade, mais pas du tout de même type.
>>>
>>> Le dim. 16 sept. 2018 à 13:23, Philippe Verdy  a
>>> écrit :
>>>
 Note: djakk s'est aussi lancé dans le changement de type de toutes les
 bretelles pour coller au rendu Michelin (dont le design est lui aussi
 protégé par son droit d'auteur, donc à ne pas reproduire tel quel, d'autant
 que les cartes Michelin sont remplies "d'oeufs de Pâques" comme on le voit
 dans le cas de la N175 qui devient une impasse sur un pont ! Donc merci de
 ne PAS utiliser Michelin comme source, elle n'est PAS libre).

 Là aussi je ne suis pas d'accord, cela a été fait sans concertation. On
 peut discuter et comparer, mais avant de changer les choses, il faut savoir
 l'impact que ça aura car ce n'est pas du tout ce qui est documenté pour
 l'instant (donc ce sera incohérent).

 Ce que fait djakk n'a donc strictement aucun intérêt pour l'instant, il
 vient compliquer les choses sans se demander l'impact que cela aura pour
 les autres: ce sont des clés déjà utilisées depuis longtemps et partout.
 Les outils d'analyse sont égalemetn basés sur les règles existantes et il
 va donc créer donc des tas de nouveaux signalements
 d'anomalies/incohérences.


 Le dim. 16 sept. 2018 à 12:34, Philippe Verdy  a
 écrit :

> Là) je trouve que ces changements de typologies de villes est
> excessif. Pour Redon ce n'est clairement pas une "city": par sa population
> non, par celle de son agglomération non plus. Ce n'est pas un chef-lieu
> d'arrondissement non plus.
>
> Pour Laval on peut discuter. Pour Fougères et Vitré c'est deux
> "demi-chef-lieux" d'un même arrondissement (créé il y a une poignée
> d'années en le séparant de celui de Rennes), mais ce ne sont pas des 
> "city"
> et restent des "towns". De même pour Dinan.
>
> Concerant les nouveaux tags que djakk ajoute, il s'ajoute aussi à
> "traffic=*" qui existait aussi (valeurs="heavy", "trunk"... pas toujours
> consistante) de même que "motorway=yes".
>
>
> Le dim. 16 sept. 2018 à 12:19, Rpnpif  a écrit :
>
>> Le 15 septembre 2018, Axelos a écrit :
>>
>> > Le 15/09/2018 à 00:45, Jérôme Amagat a écrit :
>> > > pour moi, les trunk c'est des presque autoroutes. Des routes qui
>> permettent
>> > > d'aller plus vite que des routes "normales".
>> > > Rien a voir avec les routes pour automobiles, il y a des tag pour
>> indiquer
>> > > les véhicules autorisés ou non et il y a tellement de cas
>> différent avec
>> > > des route pour automobile sauf ..., des "petites" routes réservé
>> au auto,
>> > > des "grande" routes où les vélo peuvent aller... en plus les
>> règle sont
>> > > différentes dans tout les pays.
>> > > highway=trunk n'est pas le seul tag avec highway=* qui pose des
>> soucis...
>> >
>> > En fait si j’interprète correctement, c'est la définition des voies
>> > rapides / voies express ?
>>
>> Bonjour,
>>
>> Et bien ne vous en faites pas car Djakk n'a attendu personne !
>> Il est en train d'ajouter des tags personnels (legal et performance)

[OSM-talk-fr] Impasse

[djakk djakk]

Salut !
Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin d’avoir
l’information sur toutes les way de l’impasse. But = transmettre l’info au
moteur de rendu.
Je croyais que noexit était fait pour mais apparement c’est plutôt pour ne
pas affoler les éditeurs sur une éventuelle mauvaise connexion avec une
autre way.
Dois-je continuer à utiliser noexit=yes sur les ways, ou trouver une autre
clé ?

PS : difficile de calculer ça, pensez au réseau routier de Belle-Île ;)

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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

J’ai supprimé du coup, et je ferai la demande à un admin, merci Philippe !

djakk


Le dim. 16 sept. 2018 à 12:04, Philippe Verdy  a écrit :

> Bref demande à un admin de supprimer ces images. Pour la discussion il
> était suffisant de mettre un lien vers le site Michelin qui les héberge
> (sous forme de carte interactive).
> Effectivement Michelin fait un rendu des bretelles en fonction du type de
> route mineure connectée et non du type de route majeure (nos tags OSM
> "highway=*_link")... la plupart du temps mais pas partout ! C'est son choix
> de rendu.
>
> Le dim. 16 sept. 2018 à 11:55, Philippe Verdy  a
> écrit :
>
>> Attention ces cartes Michelin ne sont pas libres de droit. Cela ne
>> devrait pas être sur le wiki.
>>
>> Le dim. 16 sept. 2018 à 11:45, djakk djakk  a
>> écrit :
>>
>>> Nooon pas le tag mono-utilisateur ! (la punition :) )
>>>
>>> J’ai mis 2 extraits de carte Michelin sur ma page wiki :
>>> wiki.openstreetmap.org/wiki/User:Djakk
>>>
>>>
>>> djakk
>>>
>>> Le sam. 15 sept. 2018 à 11:25, marc marc  a
>>> écrit :
>>>
>>>> le preprocesseur peux tres bien analyser la moindre diff
>>>> c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie
>>>> toutes les bretelles d'une route pour mettre à jour un tag
>>>> mono-utilisateur :)
>>>>
>>>> publie qlq part stp un extrait rendu osm <> rendu avec ta modif
>>>> (ou extrait michelin), j'ai du mal a imaginer la chose.
>>>>
>>>>
>>>> Le 15. 09. 18 à 11:01, djakk djakk a écrit :
>>>> > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour
>>>> > récupérer l’info, mais en pratique difficile de faire un
>>>> pré-processeur
>>>> > pour les données énormes et très mouvantes d’osm. De plus, je pense
>>>> que
>>>> > pour les collectrices c’est impossible d’y arriver.
>>>> >
>>>> > Le rendu correspondrait à la plupart des cartes, par exemple les
>>>> cartes
>>>> > Michelin papier.
>>>> >
>>>> >
>>>> > djakk
>>>> >
>>>> > Le sam. 15 sept. 2018 à 10:09, marc marc >>> > <mailto:marc_marc_...@hotmail.com>> a écrit :
>>>> >
>>>> > Bonjour djakk,
>>>> >
>>>> > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
>>>> >
>>>> >  > si on relie une autoroute à une tertiary, on pourrait
>>>> >  > choisir au niveau du rendu de ne pas afficher la bretelle.
>>>> >
>>>> > je ne suis pas sur de comprendre.
>>>> > De quel rendu tu parles ? un rendu perso ?
>>>> > tu peux poster qlq part un extrait de carte qui n'afficherait pas
>>>> > certains bretelles parce que autoroute-tertiary  ?
>>>> >
>>>> >  > Impossible en l’état actuel.
>>>> >
>>>> > Parmis les spécialistes des styles de rendu, quelqu'un confirme
>>>> > qu'on ne peux pas récupérer le type de voie inférieur connectée à
>>>> un
>>>> > bretelle ?
>>>> > si c'était confirmée, cela me semble bien + un problème de rendu
>>>> > qu'un problème de donnée.
>>>> > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
>>>> > pour le cas oä cela serait nécessaire (mais j'ai du mal a
>>>> comprendre le
>>>> > cas réel d'utilisation)
>>>> >
>>>> > Cordialement,
>>>> > Marc
>>>> > ___
>>>> > Talk-fr mailing list
>>>> > Talk-fr@openstreetmap.org <mailto: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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

On n’a pas le droit pour donner un exemple d’autre carte ? :-/

djakk

Le dim. 16 sept. 2018 à 11:56, Philippe Verdy  a écrit :

> Attention ces cartes Michelin ne sont pas libres de droit. Cela ne devrait
> pas être sur le wiki.
>
> Le dim. 16 sept. 2018 à 11:45, djakk djakk  a
> écrit :
>
>> Nooon pas le tag mono-utilisateur ! (la punition :) )
>>
>> J’ai mis 2 extraits de carte Michelin sur ma page wiki :
>> wiki.openstreetmap.org/wiki/User:Djakk
>>
>>
>> djakk
>>
>> Le sam. 15 sept. 2018 à 11:25, marc marc  a
>> écrit :
>>
>>> le preprocesseur peux tres bien analyser la moindre diff
>>> c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie
>>> toutes les bretelles d'une route pour mettre à jour un tag
>>> mono-utilisateur :)
>>>
>>> publie qlq part stp un extrait rendu osm <> rendu avec ta modif
>>> (ou extrait michelin), j'ai du mal a imaginer la chose.
>>>
>>>
>>> Le 15. 09. 18 à 11:01, djakk djakk a écrit :
>>> > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour
>>> > récupérer l’info, mais en pratique difficile de faire un
>>> pré-processeur
>>> > pour les données énormes et très mouvantes d’osm. De plus, je pense
>>> que
>>> > pour les collectrices c’est impossible d’y arriver.
>>> >
>>> > Le rendu correspondrait à la plupart des cartes, par exemple les
>>> cartes
>>> > Michelin papier.
>>> >
>>> >
>>> > djakk
>>> >
>>> > Le sam. 15 sept. 2018 à 10:09, marc marc >> > <mailto:marc_marc_...@hotmail.com>> a écrit :
>>> >
>>> > Bonjour djakk,
>>> >
>>> > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
>>> >
>>> >  > si on relie une autoroute à une tertiary, on pourrait
>>> >  > choisir au niveau du rendu de ne pas afficher la bretelle.
>>> >
>>> > je ne suis pas sur de comprendre.
>>> > De quel rendu tu parles ? un rendu perso ?
>>> > tu peux poster qlq part un extrait de carte qui n'afficherait pas
>>> > certains bretelles parce que autoroute-tertiary  ?
>>> >
>>> >  > Impossible en l’état actuel.
>>> >
>>> > Parmis les spécialistes des styles de rendu, quelqu'un confirme
>>> > qu'on ne peux pas récupérer le type de voie inférieur connectée à
>>> un
>>> > bretelle ?
>>> > si c'était confirmée, cela me semble bien + un problème de rendu
>>> > qu'un problème de donnée.
>>> > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
>>> > pour le cas oä cela serait nécessaire (mais j'ai du mal a
>>> comprendre le
>>> > cas réel d'utilisation)
>>> >
>>> > Cordialement,
>>> > Marc
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org <mailto: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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Nooon pas le tag mono-utilisateur ! (la punition :) )

J’ai mis 2 extraits de carte Michelin sur ma page wiki :
wiki.openstreetmap.org/wiki/User:Djakk


djakk

Le sam. 15 sept. 2018 à 11:25, marc marc  a
écrit :

> le preprocesseur peux tres bien analyser la moindre diff
> c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie
> toutes les bretelles d'une route pour mettre à jour un tag
> mono-utilisateur :)
>
> publie qlq part stp un extrait rendu osm <> rendu avec ta modif
> (ou extrait michelin), j'ai du mal a imaginer la chose.
>
>
> Le 15. 09. 18 à 11:01, djakk djakk a écrit :
> > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour
> > récupérer l’info, mais en pratique difficile de faire un pré-processeur
> > pour les données énormes et très mouvantes d’osm. De plus, je pense que
> > pour les collectrices c’est impossible d’y arriver.
> >
> > Le rendu correspondrait à la plupart des cartes, par exemple les cartes
> > Michelin papier.
> >
> >
> > djakk
> >
> > Le sam. 15 sept. 2018 à 10:09, marc marc  > <mailto:marc_marc_...@hotmail.com>> a écrit :
> >
> > Bonjour djakk,
> >
> > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
> >
> >  > si on relie une autoroute à une tertiary, on pourrait
> >  > choisir au niveau du rendu de ne pas afficher la bretelle.
> >
> > je ne suis pas sur de comprendre.
> > De quel rendu tu parles ? un rendu perso ?
> > tu peux poster qlq part un extrait de carte qui n'afficherait pas
> > certains bretelles parce que autoroute-tertiary  ?
> >
> >  > Impossible en l’état actuel.
> >
> > Parmis les spécialistes des styles de rendu, quelqu'un confirme
> > qu'on ne peux pas récupérer le type de voie inférieur connectée à un
> > bretelle ?
> > si c'était confirmée, cela me semble bien + un problème de rendu
> > qu'un problème de donnée.
> > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
> > pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre
> le
> > cas réel d'utilisation)
> >
> > Cordialement,
> > Marc
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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] Les bretelles

[djakk djakk]

Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour
récupérer l’info, mais en pratique difficile de faire un pré-processeur
pour les données énormes et très mouvantes d’osm. De plus, je pense que
pour les collectrices c’est impossible d’y arriver.

Le rendu correspondrait à la plupart des cartes, par exemple les cartes
Michelin papier.


djakk

Le sam. 15 sept. 2018 à 10:09, marc marc  a
écrit :

> Bonjour djakk,
>
> Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
>
> > si on relie une autoroute à une tertiary, on pourrait
> > choisir au niveau du rendu de ne pas afficher la bretelle.
>
> je ne suis pas sur de comprendre.
> De quel rendu tu parles ? un rendu perso ?
> tu peux poster qlq part un extrait de carte qui n'afficherait pas
> certains bretelles parce que autoroute-tertiary  ?
>
> > Impossible en l’état actuel.
>
> Parmis les spécialistes des styles de rendu, quelqu'un confirme
> qu'on ne peux pas récupérer le type de voie inférieur connectée à un
> bretelle ?
> si c'était confirmée, cela me semble bien + un problème de rendu
> qu'un problème de donnée.
> s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
> pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le
> cas réel d'utilisation)
>
> Cordialement,
> Marc
> ___
> 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] Les bretelles

[djakk djakk]

Oui, en fait il s’agit du type de la voie qui est 2ème dans le classement
des voiries que connecte la bretelle : motorway vers secondary, tertiary et
primary -> on retiendra primary.


djakk


Le ven. 14 sept. 2018 à 23:23, Philippe Verdy  a écrit :

> on a déjà les clés destination=* et sinon ces bretelles aboutissent à une
> extrémité sur plusieurs routes de type différent à leur jonction. Je vois
> mal comment désigner le type de l'autre côté quand il peut y en avoir
> plusieurs (souvent aussi la destination est vers un rond-point, mais il
> hérite de la typologie le plus importante des voies connectées).
> On ne peut pas tout mettre dans un tag et en pratique ces bretelles font
> partie de la voie principale qu'elles connectent. Le seul fait de voir un
> "*_link" signifie déjà qu'il y a une connexion entre deux types, on connait
> l'un et l'autre est un type inférieur.
>
> Le ven. 14 sept. 2018 à 21:40, djakk djakk  a
> écrit :
>
>> Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la
>> valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)
>>
>>
>> djakk
>>
>> Le ven. 14 sept. 2018 à 18:46, djakk djakk  a
>> écrit :
>>
>>> Salut !
>>>
>>> Une autre chose me tarabusce au sujet des routes dans osm, c’est
>>> l’absence d’info sur le type de route joint par une bretelle
>>> (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une
>>> autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On
>>> ne sait pas directement.
>>>
>>> Et je trouve cette information plus importante. En effet, si on relie
>>> une autoroute à une autoroute, ou si on relie une autoroute à une tertiary,
>>> on pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
>>> Impossible en l’état actuel.
>>>
>>> Du coup je propose link_from et link_to : pour une bretelle dans le sens
>>> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.
>>>
>>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la
valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)


djakk

Le ven. 14 sept. 2018 à 18:46, djakk djakk  a écrit :

> Salut !
>
> Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence
> d’info sur le type de route joint par une bretelle (highway=*_link),
> c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas
> d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement.
>
> Et je trouve cette information plus importante. En effet, si on relie une
> autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on
> pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
> Impossible en l’état actuel.
>
> Du coup je propose link_from et link_to : pour une bretelle dans le sens
> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.
>
> djakk
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[djakk djakk]

Oui j’ai été complètement cavalier dans ma manière de faire ! Cela me
travaille à chaque fois que je regarde une carte osm :)
C’est pas comme si la situation précédente était satisfaisante: il y avait
de nombreuses guerres d’édition car la définition FR était ambiguë.
Je serai très attentif à mes messages privés sur osm et au “revert”, je ne
partirai pas dans des guerres d’édition, je verrai qui est “chaud” sur le
sujet. (Car si pas de réponse sur la mailing-list, c’est que personne n’est
intéressé par le sujet ... sur la mailing-list mais tout le monde n’est pas
sur la ML !)

djakk


Le ven. 14 sept. 2018 à 11:31, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> oui en effet @Axelos   Dans ce cas j'avoue que ça
> aurait une utilité. Sachant que c'est comme un raccourci une voie à 110
> permet l'accès au véhicule agricoles que le permet pas les voies avec
> panneau C107. C'est là tous le problème. On se retrouve donc avec des
> panneaux pour autoriser les engin agricole à rouler...
>
> Les routes pour automobile impose le même mode de fonctionnement q'une
> autoroute. Les trunck en France ont été défini sur une logique de vitesse
> en sur le fait d'avoir au moins de voies séparé par terre-plein central...
>
> Bref ça fait bien longtemps que l'on discute de définir un modèle
> présentant des exemples de cas pour définir des logiques (interurbaines ou
> extraurbaines) mais faire un tableau et le valider en ayant l'accord de la
> plus part n'est pas simple.
>
> On doit bien pouvoir identifier des cas où cela est utile de choisir un
> certains type de clé. Sans devoir uniquement se baser sur un référentiel où
> la volonté d'une commune à monter qu'une voie est un axe majeur quand ce
> n'est pas le cas.
>
> A défaut d'explications clair et d'une logique bien défini on se retrouve
> à voir tout et son contraire...
>
> Si l'on veut améliorer ce système il faudrait encore en définir un modèle
> plus clair (ne serait ce que pour notre territoire) car ce sujet revient
> sans cesse sans y répondre ou avec des réponse complètement contraire.
>
> Ce travail a déjà été initié mais sans aboutir il me semble car la
> priorité avait été donner pour compléter les voies manquante et adjoindre
> les noms pour le projet BANO. Maintenant, c'est classification ont deux
> objectifs:
> - le routing
> - l'accessibilité
>
> La base ne sert pas à définir une logique de règlementaire (sinon c'est
> une autre clé)
>
> Si l'on veut aussi définir des règles pour choisir comment taguer les
> voies non classifiées et les chemins et voie de service.
> Pour les chemins je crois que réglementairement il n'y a pas lieux d'y
> mettre des panneaux de sortie et entrée de ville.
> Merci de me confirmer ce sujet si vous en avait l'occassion.
>
> Que voulons nous et quelles limites on y met?
> Bonne journée.
>
>
> Le jeu. 13 sept. 2018 à 19:44, Axelos  a écrit :
>
>> Le 13/09/2018 à 16:03, Christian Rogel a écrit :
>> >> Le 12 sept. 2018 à 20:10, JB  a écrit :
>> >>
>> >> Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet
>> a été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières
>> années. Tu as tenté de relancer la discussion sans grande réussite il y a
>> quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre cette
>> fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui semble le
>> compromis le plus stable ou au mieux le moins bancal, t'empêchera-t-il
>> de dormir tranquille ?
>> >> Je pense que le panier de crabes est mieux ainsi, en équilibre, que si
>> on le retourne une fois encore. Je pense que tu risques de te frotter à des
>> résistances locales à plusieurs endroits, à des conflits d'éditions, qui
>> montent parfois vite en tension lorsque la modification est faite par des
>> contributeurs distants. Es-tu sûr que le jeu en vaille la chandelle ?
>> >> JB.
>> >>
>> >> Le 12/09/2018 à 12:59, djakk djakk a écrit :
>> >>> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je
>> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies
>> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et
>> d’autres cas)
>> >>>
>> >>> djakk
>> >>>
>> >>>
>> >>> Le lun. 10 sept. 2018 à 19:49, djakk djakk > <mailto:djakk.dj...@gmail.com>> a écrit :
>> >>> Coucou !
>> >>>
>> >>> Je reviens sur cette histoire de highway=trunk qui diffère selon les
>> pays.
>> >>>
>> >>> Je pense qu’il est important d’avoir pour chaque clé-valeur une
>

[OSM-talk-fr] Les bretelles

[djakk djakk]

Salut !

Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence
d’info sur le type de route joint par une bretelle (highway=*_link),
c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas
d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement.

Et je trouve cette information plus importante. En effet, si on relie une
autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on
pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
Impossible en l’état actuel.

Du coup je propose link_from et link_to : pour une bretelle dans le sens
autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.

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

Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[djakk djakk]

Alors selon moi l'interêt c’est d’avoir une cohérence avec le Royaume-Uni,
terre de référence pour osm ; un nouveau niveau de classification des
routes (je “vois” que j’en ai besoin dans certains cas, exemple dans mon
premier mail) ; décoreler les 5 caractéristiques d’une voie : la hiérarchie
dans le réseau routier (dévolu à la clé “highway” - sauf pour le cas des
autoroutes), ses caractéristiques physiques (aussi performance) dévolu aux
clés “expressway” et “lane”, son accessibilité (foot=no ou motorroad=yes),
son intensité de trafic (clé traffic) et ses vitesses limites (clé
maxspeed). (Je rejoins ce que tu dis en fait il me semble)

J’ai mûri ça de longue date, du coup je me suis permis de mettre à jour le
wiki !


djakk

Le mer. 12 sept. 2018 à 20:51, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Bonjour,
> En soit c'est un débat de longue date dont je ne ressortirai pas les
> archives. La hiérarchie des voie n'est pas classé seulement sur des
> vitesses. Les règles établi reprennent en grande partie ce que l'on peut
> exploiter sur le référentiel route 500...
>
> On a des petits malin qui pour des raisons de règlementation préfèrent
> casser le schéma routier "hiérarchisé" parce une voie secondaire à une
> portion de zone 30 ou de zone de rencontre... Sauf que c'est une réalité
> terrain. Certaine commune sont traversé par une voie et comme c'est une
> zone de passage de piéton on se retrouve avec des zone à 20 ou 30km/h pour
> des routes départementales...
>
> Bref qu'apporte les expressway ou de reclasser des voies en trunk?
>
> Les modèles classifié sont fais pour fournir des propositions d'itinéraire
> en fonction de deux critères qui donne un poids au tronçon parcouru. en
> clair c'est comme des coefficients pondérateur.
>
> Une voieie en faite c'est quatre choses :
> - type de route permettant de définir si elle est destiné à accompagner
> les voyageurs vers une destination plus ou moins éloigné (on a aussi les
> panneaux de circulation qui donne du sens au catégorie)
> - vitesse des parcours (on a des nationales ou les vitesses sont plus
> importantes que certaines autoroutes l'A709 est limité à 90km/h et sert de
> périphérique. Ça n'en reste pas moins une autoroute)
> - l'accès sert à absorber une quantité de véhicule par heure (oui mais
> quel ratio définir et seul les DDT on réllement le moyens de faire parler
> le traffic... avec les service de voirie équiper de capteur)
> - le droit et les contraintes légale de circulation (ce dernier point est
> utiliser pour générer de nouvelle clé et type de voie qui dans certains cas
> casse le schéma précédent)
>
> D'où la problématique des trunk, living_street
>
>
>
>
>
>
> Le mer. 12 sept. 2018 à 13:00, djakk djakk  a
> écrit :
>
>> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je
>> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies
>> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et
>> d’autres cas)
>>
>> djakk
>>
>>
>> Le lun. 10 sept. 2018 à 19:49, djakk djakk  a
>> écrit :
>>
>>> Coucou !
>>>
>>> Je reviens sur cette histoire de highway=trunk qui diffère selon les
>>> pays.
>>>
>>> Je pense qu’il est important d’avoir pour chaque clé-valeur une
>>> définition commune au monde entier (autant que possible ) et qu’un 5e
>>> niveau dans la hiérarchie des “highways”
>>> serait souhaitable : residential/unclassified - tertiary - secondary -
>>> primary - trunk.
>>>
>>> Du coup, il s’agirait de reprendre pour la France le classement anglais
>>> des highways, où le trunk désigne une super-route pas forcément de type
>>> autoroutier.
>>>
>>> Par exemple pour différencier la N12 et la D31 à Ernée (
>>> https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12 serait à
>>> mettre en trunk - comme à priori toutes les nationales restant en France.
>>>
>>> Pour retrouver les informations actuellement fournies par le trunk
>>> français : la classification administrative avec le panneau “route pour
>>> automobiles”, on a la clé-valeur “motorroad=yes”.
>>> Il faut inventer une nouvelle clé pour désigner une route dénivelée (pas
>>> de carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile pour
>>> les cas où la route ressemble à une route pour automobiles dénivelée, mais
>>> ça n’en est pas une officiellement, exemple : la N12 au niveau de
>>> Goussainville :
>>> https://www.openstreetmap.org/#map=16/48.7718/1.5526
>>> ).
>>>
>>>
>>> djakk
>>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[djakk djakk]

Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je
réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies
en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et
d’autres cas)

djakk


Le lun. 10 sept. 2018 à 19:49, djakk djakk  a écrit :

> Coucou !
>
> Je reviens sur cette histoire de highway=trunk qui diffère selon les pays.
>
> Je pense qu’il est important d’avoir pour chaque clé-valeur une définition
> commune au monde entier (autant que possible ) et qu’un 5e niveau dans la
> hiérarchie des “highways”
> serait souhaitable : residential/unclassified - tertiary - secondary -
> primary - trunk.
>
> Du coup, il s’agirait de reprendre pour la France le classement anglais
> des highways, où le trunk désigne une super-route pas forcément de type
> autoroutier.
>
> Par exemple pour différencier la N12 et la D31 à Ernée (
> https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12 serait à
> mettre en trunk - comme à priori toutes les nationales restant en France.
>
> Pour retrouver les informations actuellement fournies par le trunk
> français : la classification administrative avec le panneau “route pour
> automobiles”, on a la clé-valeur “motorroad=yes”.
> Il faut inventer une nouvelle clé pour désigner une route dénivelée (pas
> de carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile pour
> les cas où la route ressemble à une route pour automobiles dénivelée, mais
> ça n’en est pas une officiellement, exemple : la N12 au niveau de
> Goussainville :
> https://www.openstreetmap.org/#map=16/48.7718/1.5526
> ).
>
>
> djakk
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

Oui je sais la situation administrative actuelle, mais en me baladant sur
osm, j’ai vu une gare éponyme, un parking “du centre”, du foncier dense, un
théâtre “de saint-Quentin-en-Yvelines” : c’est physiquement le centre d’une
ville appelée “saint-Quentin-en-Yvelines” non ?

Pour Marne-la-Vallée on n’a pas cette possibilité d’en marquer le centre
comme ça.


djakk


Le mar. 11 sept. 2018 à 21:54, Philippe Verdy  a écrit :

> D'accord aussi avec ça. L'utilisateur est trompé par l'expression
> administrative "ville nouvelle" qui est même obsolète aujourd'hui.
> Si on veut parler objective de ville, l'INSEE fournit une meilleure
> référence avec son découpage urbain (qui n'a rien à voir avec le découpage
> administratif, mais commence maintenant à être sérieusement pris en compte
> par les collectivités et EPCI sommée d'établir des PLUi après l'échec des
> PLU maintenant transférés aux EPCI qui doivent aussi les intégrer aux
> SCOT's ainsi que d'autres plans comme le PLU, le PDU, le PLH, le PADD et
> doivent obligatoirement les faire évaluer et réviser au plus tard 6 ans
> après leur instauration). Le plan urbain intervient maintenant aussi dans
> la régulation routière. Il traduit le terrain réel et la façon dont il doit
> être utilisé ou pas, avec obligation de préserver l'environnement rural et
> éviter le saupoudrage urbain et l'explosion des couts des services publics
> qui doivent se regrouper, mais aussi limiter les disparités territoriales.
> La notion de "ville" a longtemps été utilisée comme argument commercial et
> politique. Les lois Grenelle I et II, et SRU sont passées, les économies
> budgétaires s'imposent alors que les dettes explosent car on développait
> les villes avec une vision à court terme. Maintenant il faut développer
> "durable": ce n'est pas juste une question d'écologie, mais une obligation
> économique (mais avec de fortes résistantes car il va falloir tout
> réadapter, à commencer par les industries et le commerce).
>
>
> Le mar. 11 sept. 2018 à 21:29, marc marc  a
> écrit :
>
>> Mais Saint-Quentin-en-Yvelines n'est pas une ville
>> c'est une communauté d’agglomération déjà renseignée
>> avec https://www.openstreetmap.org/relation/49584
>> et dont les différents villes/villages constituant
>> sont eux aussi déjà renseigné dans osm.
>> du coup je ne comprend pas trop le sens de l'objet
>> que tu as crée hormis forcé un rendu artificiel.
>>
>>
>> Le 11. 09. 18 à 15:24, djakk djakk a écrit :
>> > Je me suis trompé je voulais dire commune administrative et *village*
>> > physique. Par exemple on peut avoir une seule commune administrative
>> qui
>> > réunit 2 villages physiques, exemple : Lit-et-Mixe avec Lit et Mixe,
>> > Budapest avec Buda et Pest, Saint-Julien-en-Born avec Saint-Julien et
>> > Contis-Plage.
>> >
>> >
>> > Le mar. 11 sept. 2018 à 15:13, marc marc > > <mailto:marc_marc_...@hotmail.com>> a écrit :
>> >
>> > Bonjour,
>> >
>> > c'est quoi une commune physique et une commune administrative ?
>> > J'ai l'impression qu'on s'enfonce en plein dans tag pour le
>> rendu... :(
>> >
>> > PS: le rôle label est purement et simplement ignoré par le rendu
>> > osm.org <http://osm.org>
>> >
>> > Cordialement,
>> > Marc
>> >
>> > Le 11. 09. 18 à 15:07, djakk djakk a écrit :
>> >  > Dans cette logique de nom de commune administratif / nom de
>> commune
>> >  > physique, j’ai créé un noeud place=city pour
>> > Saint-Quentin-en-Yvelines ;)
>> >  >
>> >  >
>> >  > djakk
>> >  >
>> >  > Le mar. 11 sept. 2018 à 12:53, Philippe Verdy <
>> verd...@wanadoo.fr
>> > <mailto:verd...@wanadoo.fr>
>> >  > <mailto:verd...@wanadoo.fr <mailto:verd...@wanadoo.fr>>> a
>> écrit :
>> >  >
>> >  > Attention au placement de ce "label" pour les communes
>> > nouvelles, ce
>> >  > peut être un noeud mais tagué PAS un place=village/town si
>> on le
>> >  > place hors agglomération entre plusieurs.
>> >  > Sur le terrain les noms des communes nouvelles ne sont pas
>> > présentes
>> >  > sur les panneaux, les communes déléguées gardant leur
>> > toponymie, au
>> >  > mieux cela apparait sur les entrées de villages comme "
>> > (commune
>> >  > de )" la mention en

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

Je me suis trompé je voulais dire commune administrative et *village*
physique. Par exemple on peut avoir une seule commune administrative qui
réunit 2 villages physiques, exemple : Lit-et-Mixe avec Lit et Mixe,
Budapest avec Buda et Pest, Saint-Julien-en-Born avec Saint-Julien et
Contis-Plage.


Le mar. 11 sept. 2018 à 15:13, marc marc  a
écrit :

> Bonjour,
>
> c'est quoi une commune physique et une commune administrative ?
> J'ai l'impression qu'on s'enfonce en plein dans tag pour le rendu... :(
>
> PS: le rôle label est purement et simplement ignoré par le rendu osm.org
>
> Cordialement,
> Marc
>
> Le 11. 09. 18 à 15:07, djakk djakk a écrit :
> > Dans cette logique de nom de commune administratif / nom de commune
> > physique, j’ai créé un noeud place=city pour Saint-Quentin-en-Yvelines ;)
> >
> >
> > djakk
> >
> > Le mar. 11 sept. 2018 à 12:53, Philippe Verdy  > <mailto:verd...@wanadoo.fr>> a écrit :
> >
> > Attention au placement de ce "label" pour les communes nouvelles, ce
> > peut être un noeud mais tagué PAS un place=village/town si on le
> > place hors agglomération entre plusieurs.
> > Sur le terrain les noms des communes nouvelles ne sont pas présentes
> > sur les panneaux, les communes déléguées gardant leur toponymie, au
> > mieux cela apparait sur les entrées de villages comme " (commune
> > de )" la mention entre parenthèses indiquant en plus petits
> > caractères le nom de la commune nouvelle, mais nulle part sur les
> > panneaux directionnels.
> > Bref le nom de commune nouvelle est un nom purement administratif et
> > il est suffisant de l'indiquer dans la relation de niveau 8 de la
> > commune nouvelle.
> >
> >
> > Le mar. 11 sept. 2018 à 12:14, Rpnpif  > <mailto:rpn...@trob.eu>> a écrit :
> >
> > Le 10 septembre 2018, Jérôme Amagat a écrit :
> >
> >  > Il ne faut pas confondre commune dun côté et ville ( village
> > hameau) de
> >  > l'autre.
> >  > Dans osm les communes c'est la relation avec admin_level=8 et
> > la ville
> >  > c'est place=*
> >  > Dans la plupart des communes de France la commune à le même
> > nom que le
> >  > village principal mais pas partout.
> >  >
> >  > Dans le cas de cette commune le officiel name sur les place=
> > est inutile.
> >  > Les place sont dans les limite de la relation se la commune
> > donc pas la
> >  > peine de rajouter le nom de la commune.
> >  > Je mettrait plutôt place=village pour les 2 "Lit" et aussi
> > "mixe". La
> >  > distinction entre un hameau et un village est pas très claire
> > mais pour moi
> >  > c'est son "importance". "Mixe" sert au nom de la commune, ça
> > a été une
> >  > commune et ça semble être plus habité que pas mal de village
> > de France donc
> >  > je mettrais "village"
> >
> > Bonjour,
> >
> > C'est le cas des nouvelles communes où fréquemment elles
> > n'ont pas le même nom que le village principal, ce qui pose des
> > problèmes de rendu parfois. Par exemple, le nom de la nouvelle
> > commune
> > masque le nom du village principal, pourtant encore
> majoritairement
> > utilisé par la population et pour longtemps, et ce même avec un
> > agrandissement presque maximal.
> >
> > J'ai testé avec succès la relation frontière (boundary)
> > appliquée sur
> > un point avec le rôle de « label ». Il est alors possible de
> > placer ce
> > point sur un emplacement adapté où apparaîtra le nom de la
> nouvelle
> > commune.
> >
> > --
> > Alain Rpnpif
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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] Lit-et-Mixe

[djakk djakk]

Dans cette logique de nom de commune administratif / nom de commune
physique, j’ai créé un noeud place=city pour Saint-Quentin-en-Yvelines ;)


djakk

Le mar. 11 sept. 2018 à 12:53, Philippe Verdy  a écrit :

> Attention au placement de ce "label" pour les communes nouvelles, ce peut
> être un noeud mais tagué PAS un place=village/town si on le place hors
> agglomération entre plusieurs.
> Sur le terrain les noms des communes nouvelles ne sont pas présentes sur
> les panneaux, les communes déléguées gardant leur toponymie, au mieux cela
> apparait sur les entrées de villages comme " (commune de )" la
> mention entre parenthèses indiquant en plus petits caractères le nom de la
> commune nouvelle, mais nulle part sur les panneaux directionnels.
> Bref le nom de commune nouvelle est un nom purement administratif et il
> est suffisant de l'indiquer dans la relation de niveau 8 de la commune
> nouvelle.
>
>
> Le mar. 11 sept. 2018 à 12:14, Rpnpif  a écrit :
>
>> Le 10 septembre 2018, Jérôme Amagat a écrit :
>>
>> > Il ne faut pas confondre commune dun côté et ville ( village hameau) de
>> > l'autre.
>> > Dans osm les communes c'est la relation avec admin_level=8 et la ville
>> > c'est place=*
>> > Dans la plupart des communes de France la commune à le même nom que le
>> > village principal mais pas partout.
>> >
>> > Dans le cas de cette commune le officiel name sur les place= est
>> inutile.
>> > Les place sont dans les limite de la relation se la commune donc pas la
>> > peine de rajouter le nom de la commune.
>> > Je mettrait plutôt place=village pour les 2 "Lit" et aussi "mixe". La
>> > distinction entre un hameau et un village est pas très claire mais pour
>> moi
>> > c'est son "importance". "Mixe" sert au nom de la commune, ça a été une
>> > commune et ça semble être plus habité que pas mal de village de France
>> donc
>> > je mettrais "village"
>>
>> Bonjour,
>>
>> C'est le cas des nouvelles communes où fréquemment elles
>> n'ont pas le même nom que le village principal, ce qui pose des
>> problèmes de rendu parfois. Par exemple, le nom de la nouvelle commune
>> masque le nom du village principal, pourtant encore majoritairement
>> utilisé par la population et pour longtemps, et ce même avec un
>> agrandissement presque maximal.
>>
>> J'ai testé avec succès la relation frontière (boundary) appliquée sur
>> un point avec le rôle de « label ». Il est alors possible de placer ce
>> point sur un emplacement adapté où apparaîtra le nom de la nouvelle
>> commune.
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> 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] Classement ville/village - city/town/village

[djakk djakk]

C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple je
verrai Figeac comme une “city” car le seul grand ensemble urbain alentours,
d’ailleurs capitale de sa zone d’emploi, par contre Figeac serait collée à
Rennes ça serait “Town” seulement et collée à Paris ça serait même
“village”.

Comme pour les “highway” une rue tertiary de Paris à dans doute autant de
circulation qu’une “primary” de Figeac.

La définition de “city” sur le wiki anglais parle de relativité :  Use the
place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag
<https://wiki.openstreetmap.org/wiki/Tag> to identify the largest
settlement or settlements within a territory,


djakk


Le mar. 11 sept. 2018 à 12:33, Rpnpif  a écrit :

> Le 10 septembre 2018, djakk djakk a écrit :
>
> > Par exemple : être la capitale d’un bassin de vie ou d’une zone d’emploi
> > implique être place=Town au moins.
>
> Oui mais non, il ne faut pas oublier que la population des villes et
> villages en Grande-Bretagne est souvent plus importantes qu'en France,
> que celle des villages et villes de Lozère est différente (inférieure)
> de celle du Nord de la France ou de l'Ouest.
>
> Ne pas oublier aussi que certains maires se font mousser en appelant
> ville leur village, que les gens de l'Ouest appelle village, les
> hameaux et bourg le... bourg principal.
>
> Faute de mieux, je pense que le wiki français distinguant en fonction de
> la population fait un bon compromis.
>
> Ce n'est que mon avis.
>
> --
> Alain Rpnpif
>
> ___
> 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] Classement ville/village - city/town/village

[djakk djakk]

Et est-ce qu’on dit qu’il ne peut y avoir qu’une seule place=city par zone
d’emploi ?
Reponse : non, certaines sont multipolaires, comme celle de
Roubaix-Tourcoing.


djakk


Le lun. 10 sept. 2018 à 22:02, djakk djakk  a écrit :

> Par exemple : être la capitale d’un bassin de vie ou d’une zone d’emploi
> implique être place=Town au moins.
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 21:43, djakk djakk  a
> écrit :
>
>> Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
>> seraient des critères intéressants.
>>
>>
>> djakk
>>
>> Le lun. 10 sept. 2018 à 21:37, deuzeffe  a
>> écrit :
>>
>>> On 10/09/2018 18:21, djakk djakk wrote:
>>> > Salut !
>>>
>>> Hello,
>>>
>>> > J’aimerai revenir sur la distinction ville/village - où plutôt
>>> > city/town/village : la page wiki française défini un classement par
>>> nombre
>>> > d’habitants, alors que la page wiki anglaise défini un classement par
>>> les
>>> > services accessibles (commerces, services) !
>>>
>>> J'espérais trouver une réponse en consultant le site l'INSEE : la
>>> classification française proposée par le wiki émane probablement du
>>> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
>>> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
>>> urbaines". (https://www.insee.fr/fr/information/2571258 )
>>>
>>> On n'est pas plus avancés :(
>>>
>>> --
>>> deuzeffe
>>>
>>> ___
>>> 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] Classement ville/village - city/town/village

[djakk djakk]

Par exemple : être la capitale d’un bassin de vie ou d’une zone d’emploi
implique être place=Town au moins.


djakk

Le lun. 10 sept. 2018 à 21:43, djakk djakk  a écrit :

> Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
> seraient des critères intéressants.
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 21:37, deuzeffe  a
> écrit :
>
>> On 10/09/2018 18:21, djakk djakk wrote:
>> > Salut !
>>
>> Hello,
>>
>> > J’aimerai revenir sur la distinction ville/village - où plutôt
>> > city/town/village : la page wiki française défini un classement par
>> nombre
>> > d’habitants, alors que la page wiki anglaise défini un classement par
>> les
>> > services accessibles (commerces, services) !
>>
>> J'espérais trouver une réponse en consultant le site l'INSEE : la
>> classification française proposée par le wiki émane probablement du
>> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
>> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
>> urbaines". (https://www.insee.fr/fr/information/2571258 )
>>
>> On n'est pas plus avancés :(
>>
>> --
>> deuzeffe
>>
>> ___
>> 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] Classement ville/village - city/town/village

[djakk djakk]

Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
seraient des critères intéressants.


djakk

Le lun. 10 sept. 2018 à 21:37, deuzeffe  a écrit :

> On 10/09/2018 18:21, djakk djakk wrote:
> > Salut !
>
> Hello,
>
> > J’aimerai revenir sur la distinction ville/village - où plutôt
> > city/town/village : la page wiki française défini un classement par
> nombre
> > d’habitants, alors que la page wiki anglaise défini un classement par les
> > services accessibles (commerces, services) !
>
> J'espérais trouver une réponse en consultant le site l'INSEE : la
> classification française proposée par le wiki émane probablement du
> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
> urbaines". (https://www.insee.fr/fr/information/2571258 )
>
> On n'est pas plus avancés :(
>
> --
> deuzeffe
>
> ___
> 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] Classement ville/village - city/town/village

[djakk djakk]

Oui Philippe ca sera plus+ subjectif. L’information population est déjà
renseignée une première fois alors on ne risque pas de perdre de l’info ...

Le lun. 10 sept. 2018 à 19:35, Jérôme Amagat  a
écrit :

> Il ne faut pas comparer avec les autre village d'osm mais avec les town.
> Dans osm comme je pense l'usage en France,  village est utiliser pour des
> "truc" tout petit si il y a une mairie par exemple. Et aussi pour des
> "truc" plus grand avec beaucoup de petit commerce.
>
> Le lun. 10 sept. 2018 à 19:12, Philippe Verdy  a
> écrit :
>
>> mais alors bon nombre de villages actuels passeraient en "town". LA
>> définition anglaise est un compromis local à l'Angleterre, la
>> classification s'est faite en fait pays par pays. En France c'est un
>> critère de population (avec quelques exceptions sur les populations très
>> approchantes, ou parce que c'est un centre *administratif*. Les commerces
>> ne sont pas suffisants pour changer ça, car il n'ont pas plus de priorité
>> que d'autres services et entreprises (et ne France les services publics son
>> nombreux et ont beaucoup d'activités), ou grandes assos d'utilité publique
>> (qui souvent aussi sont alors des employeurs), ou même les exploitations
>> agricoles !
>>
>> Plutôt que le nombre de commerces on pourrait retenir le nombre d'emplois
>> dans la commune, ce serait plus pertinent que les seuls commerces, mais les
>> activités et commerces ont un nombre variable (décroissant) d'emplois.
>> Enfin le commerce ne se réduit pas aux seules boutiques installées : il y a
>> aussi les marchés, la vente à domicile, la vente itinérante (food
>> trucks...), la vente sur Internet, et plein de services aux entreprises qui
>> n'ont pas pignon sur rue; enfin on peut ajouter les cabinets médicaux ou
>> d'infirmières...
>>
>> Difficile de trancher par un critère simple, d'autant plus que si on
>> compte uniquement les emplois on va exclure des grosses localités urbaines
>> résidentielles qui ne sont pas des villages, mais ont une population dense
>> et peu de commerce directement sur leur sol (de nos jours pleins de
>> commerces sont sortis des communes centre pour aller en périphérie
>> immédiate mais ils assurent pourtant une couverture commerciale et de
>> services qu'on peut appeler de proximité). Les communes ont souvent aussi
>> plusieurs bourgs, dont certains se sont développés au contact direct d'une
>> autre agglomération ou par facilité de transport ou la création d'activités
>> industrielles (mais pas forcément de commerce en vente directe, sauf les
>> itinérants ou un transport court pour rejoindre une zone commerciale
>> voisine.
>>
>> Au final ce sera soi très subjectif, donc partial.
>>
>> L'importance relative d'une commune ne dépend pas seulement du critère de
>> population, ou de sa classification en village/town/city, il y a d'autres
>> critères et on s'en rend compte dans les rendus qui vont additionner la
>> présence de plusieurs autres attributs (dont celui de "capital=*") ou
>> relations qui désigne les "admin_centre".
>>
>> Ce qu'on pourrait revoir c'est plutôt les seuils minimaux de population:
>> peut-être qu'on est trop sévère pour les "towns" et même les "cities".
>>
>>
>> Le lun. 10 sept. 2018 à 18:22, djakk djakk  a
>> écrit :
>>
>>> Salut !
>>>
>>> J’aimerai revenir sur la distinction ville/village - où plutôt
>>> city/town/village : la page wiki française défini un classement par nombre
>>> d’habitants, alors que la page wiki anglaise défini un classement par les
>>> services accessibles (commerces, services) !
>>>
>>> Je trouve la définition anglaise plus intéressante bien que moins nette.
>>>
>>> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
>>> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
>>> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
>>> d’A mériterait d'être classé en “Town” ...
>>>
>>>
>>> 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
>>
> ___
> 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] Classification des highway - trunk comme super-primary

[djakk djakk]

Coucou !

Je reviens sur cette histoire de highway=trunk qui diffère selon les pays.

Je pense qu’il est important d’avoir pour chaque clé-valeur une définition
commune au monde entier (autant que possible ) et qu’un 5e niveau dans la
hiérarchie des “highways”
serait souhaitable : residential/unclassified - tertiary - secondary -
primary - trunk.

Du coup, il s’agirait de reprendre pour la France le classement anglais des
highways, où le trunk désigne une super-route pas forcément de type
autoroutier.

Par exemple pour différencier la N12 et la D31 à Ernée (
https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12 serait à
mettre en trunk - comme à priori toutes les nationales restant en France.

Pour retrouver les informations actuellement fournies par le trunk français
: la classification administrative avec le panneau “route pour
automobiles”, on a la clé-valeur “motorroad=yes”.
Il faut inventer une nouvelle clé pour désigner une route dénivelée (pas de
carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile pour
les cas où la route ressemble à une route pour automobiles dénivelée, mais
ça n’en est pas une officiellement, exemple : la N12 au niveau de
Goussainville :
https://www.openstreetmap.org/#map=16/48.7718/1.5526
).


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

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

La définition anglaise : Towns normally have a good range of shops and
facilities which are used by people from nearby villages.


Le lun. 10 sept. 2018 à 18:21, djakk djakk  a écrit :

> Salut !
>
> J’aimerai revenir sur la distinction ville/village - où plutôt
> city/town/village : la page wiki française défini un classement par nombre
> d’habitants, alors que la page wiki anglaise défini un classement par les
> services accessibles (commerces, services) !
>
> Je trouve la définition anglaise plus intéressante bien que moins nette.
>
> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
> d’A mériterait d'être classé en “Town” ...
>
>
> djakk
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Salut !

J’aimerai revenir sur la distinction ville/village - où plutôt
city/town/village : la page wiki française défini un classement par nombre
d’habitants, alors que la page wiki anglaise défini un classement par les
services accessibles (commerces, services) !

Je trouve la définition anglaise plus intéressante bien que moins nette.

En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
d’A mériterait d'être classé en “Town” ...


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

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

... nat_name et official_name uniquement sur le noeud de la ville ou d’un
village principal bien sûr !


djakk

Le lun. 10 sept. 2018 à 17:16, djakk djakk  a écrit :

> Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
> Je n’ai pas touché au nom de la frontière administrative bien sûr.
>
> On fait pareil pour les communes fusionnées ?
>
> Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en zoom
> proche ...
>
>
> djakk
>
>
> Le jeu. 9 août 2018 à 14:20, Philippe Verdy  a écrit :
>
>> Pour les communes associées dans une fusion-association, ou pour les
>> communes déléguées dans les communes nouvelles, ou pour les arrondissements
>> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
>> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
>> fusionnée de droit est de niveau 8, et peut avoir aussi un
>> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
>> En règle générale place=* est indépendant de l'entité adminsitrative (on
>> devrait même se passer de "place=*" pour les relations, il est plus lié aux
>> nodes).
>> De même les chiffres de population devraient être sur la relation (quand
>> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
>> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
>> même relation dans certains cas pour certaines entités: 'de jure' contre
>> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
>> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
>> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
>> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
>> politique.
>>
>> Les statuts de "ville", "village", "borough" (admin_type=* sur les
>> relations administratives ou politiques ou autres) ne vont pas bien avec
>> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
>> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
>> aucun statut administratif et ne sont pas clairement délimités au sein de
>> l'entité administrative.
>>
>> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
>> plus large que l'entité administrative (notamment dans les grandes
>> métropoles, mais parfois aussi des villes plus petites, pour inclure une
>> partie de leur périphérie): les "place" correspondent mieux en France à ce
>> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
>> géographie administrative) qui évolue tout le temps et plus vite que la
>> géographie administrative.
>>
>> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
>> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
>> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
>> prend le pas
>>
>> Le "place=suburb" est plus pour la compatibilité des rendus génériques
>> internationaux: c'est une approximation permettant juste des comparaisons
>> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
>> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
>> administrative, et sinon pour donner une priorité estimée de "l'importance"
>> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
>> : ce "place=*" est juste un des critères possibles permettant de filtrer
>> les éléments à afficher en priorité).
>>
>>
>> Le 9 août 2018 à 11:20, djakk djakk  a écrit :
>>
>>> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
>>> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
>>> préférerai qu’on garde place=village ou place=town et que le détail
>>> administratif se fasse avec les admin_level= ...
>>> Car quand on se balade on ne ressent pas la ville ou le village par son
>>> côté administratif mais par son urbanisme et sa densité commerciale et sa
>>> densité de services.
>>>
>>> djakk
>>>
>>>
>>> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>>>
>>>> Le  4 août 2018, Stéphane Péneau a écrit :
>>>>
>>>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est
>>>> un
>>>> > peu délicat.
>>>> >
>>>> > En revanche, town pour un bourg d'un peu plus de 

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
Je n’ai pas touché au nom de la frontière administrative bien sûr.

On fait pareil pour les communes fusionnées ?

Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en zoom
proche ...


djakk


Le jeu. 9 août 2018 à 14:20, Philippe Verdy  a écrit :

> Pour les communes associées dans une fusion-association, ou pour les
> communes déléguées dans les communes nouvelles, ou pour les arrondissements
> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
> fusionnée de droit est de niveau 8, et peut avoir aussi un
> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
> En règle générale place=* est indépendant de l'entité adminsitrative (on
> devrait même se passer de "place=*" pour les relations, il est plus lié aux
> nodes).
> De même les chiffres de population devraient être sur la relation (quand
> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
> même relation dans certains cas pour certaines entités: 'de jure' contre
> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
> politique.
>
> Les statuts de "ville", "village", "borough" (admin_type=* sur les
> relations administratives ou politiques ou autres) ne vont pas bien avec
> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
> aucun statut administratif et ne sont pas clairement délimités au sein de
> l'entité administrative.
>
> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
> plus large que l'entité administrative (notamment dans les grandes
> métropoles, mais parfois aussi des villes plus petites, pour inclure une
> partie de leur périphérie): les "place" correspondent mieux en France à ce
> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
> géographie administrative) qui évolue tout le temps et plus vite que la
> géographie administrative.
>
> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
> prend le pas
>
> Le "place=suburb" est plus pour la compatibilité des rendus génériques
> internationaux: c'est une approximation permettant juste des comparaisons
> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
> administrative, et sinon pour donner une priorité estimée de "l'importance"
> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
> : ce "place=*" est juste un des critères possibles permettant de filtrer
> les éléments à afficher en priorité).
>
>
> Le 9 août 2018 à 11:20, djakk djakk  a écrit :
>
>> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
>> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
>> préférerai qu’on garde place=village ou place=town et que le détail
>> administratif se fasse avec les admin_level= ...
>> Car quand on se balade on ne ressent pas la ville ou le village par son
>> côté administratif mais par son urbanisme et sa densité commerciale et sa
>> densité de services.
>>
>> djakk
>>
>>
>> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>>
>>> Le  4 août 2018, Stéphane Péneau a écrit :
>>>
>>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est
>>> un
>>> > peu délicat.
>>> >
>>> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
>>> > suis pas trop d'accord. place=village est mieux adapté
>>> >
>>>
>>> Bonjour,
>>>
>>> En complément de la réserve de Stéphane, c'est le même problème avec la
>>> fusion récente de communes.
>>> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
>>> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>>>
>>> --
>>> Alain Rpnpif
>>

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[djakk djakk]

Salut !

Faut-il aller jusqu’à regarder les arrêtés municipaux ?
Je vois souvent des débuts de limitation à 30 avant un dos-d’âne pas suivi
d’un retour à 50 (Pas de 30 barré).


Julien djakk


Le lun. 10 sept. 2018 à 12:15, Rpnpif  a écrit :

> Bonjour,
>
> Personnellement, je coupe la route et j'y mets un maxspeed. Je trouve
> cela plus simple que d'y ajouter des traffic_* pour les panneaux.
> Et alors je n'ai pas de débordement.
>
> Par contre sur le terrain, oui on trouve de tout, mais j'essaie quand
> même de coller au plus près.
>
> --
> Alain Rpnpif
>
> Le 10 septembre 2018, Patrick BEGOU a écrit :
>
> > Bonjour,
> >
> > utilisateur d'Osmand depuis fin juillet, je me suis mis à corriger les
> > limites erronées depuis le passage à 80 km/h là où je constatais des
> > erreurs. Puis le côté addictif d'OSM m'a poussé à ajouter les limites
> > sur les routes qui n'en avaient pas et je me
> > trouve régulièrement devant des incohérences sur le terrain, du genre:
> >
> > Une zone 30 signalée dans la rue principale d'un village et pas dans les
> > rues transversales. Ce qui signifie que si on suit la signalisation à
> > la lettre, dans ces rues transversales on doit circuler à 30 en quittant
> > le village (puisqu'on n'a croisé aucun "fin de zone 30" et à 80
> > lorsqu'on s'y rend, ce qui semble très incohérent. Je ne me vois pas
> > rentrer un maxspeed:forward=30 et un maxspeed:backward=80.
> >
> > De même, je trouve régulièrement la situation suivante:
> > Limitation à 70 km/h.
> > Un peu plus loin, une intersection sans rappel de la limite à 70, donc
> > théoriquement fin de la limite imposée et retour à 80 km/h par défaut.
> > Et un peu plus loi un panneau "fin de limite à 70".
> >
> > Je me doute que l'idée dans l'esprit de ceux qui ont posé les
> > panneaux était de limiter jusqu'au panneau "fin de limite" mais la
> > réglementation dit que la limite s'arrête à l'intersection.
> >
> > Donc j'en viens à ma question: étant encore un contributeur récent, je
> > ne sais pas si il y a des habitudes, règles, bonnes pratiques dans ces
> > cas là:
> >
> > on inscrit ce que dit la loi même si ce n'est manifestement pas ce
> > qu'elle veut dire ?
> >
> > on inscrit ce que semble être l'esprit de la loi dans la zone
> > concernée, mais sans trop savoir pour le cas des zones 30 où placer
> > une limite qui n'est pas sur le terrain ?
> >
> > on n'inscrit rien du tout, seule façon à mon sens de n'inscrire que
> > ce qu'on trouve sur le terrain, tout en évitant de rentrer des
> > inepties ?
> >
> > Merci pour vos éclaircissements.
> >
> > Patrick
> >
> > ___
> > 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] micro-mapping de parkings

[djakk djakk]

Moi j’aime bien ce micro-mapping :)


djakk


Le dim. 26 août 2018 à 01:58, Philippe Verdy  a écrit :

> Les surfaces de parkings devraient être connectées, longées ou traversées
> par des rues ou voies d'accès. Les emplacements précis (forcément à côté)
> ne sont donc pas adaptés au amenity=parking.
> En revanche on peut tout à fait délimiter en évitant d'inclure des zones
> arborées/herbeuses ou réservées aux piétons (hors simples chemins qui les
> traverse), tant qu'on maintient une connexion aux voies d'accès.
> Les zones précises amenity=parking_space sont à inclure dans ces zones de
> parking et n'ont pas besoin d'être connectées car c'est le parking
> englobant qui les "connecte" au réseau
>
> Le sam. 25 août 2018 à 23:42, marc marc  a
> écrit :
>
>> Bonsoir,
>>
>> Le 25. 08. 18 à 23:03, Muselaar a écrit :
>> > https://www.openstreetmap.org/#map=19/47.63874/6.84850
>>
>> c'est une erreur.
>> il devrait y a avoir un seul parking qui englobe le tout.
>> si on veux renseigner au niveau de la place, il y a
>> amenity=parking_space dont l'utilité par ex est de renseigner
>> l'endroit précis d'une place PMR ou autre place "thématique"
>>
>> Cordialement,
>> Marc
>> ___
>> 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] Lieux-dits

[djakk djakk]

Tout à fait d’accord avec toi marc marc, j’en avais déjà parlé avec les
lieux-dits importés par verdy_p autour de Montgermont. La plupart des
lieux-dits n’existent que pour l’administration, ils ne sont plus connus du
reste de la population.

Alors, faut-il par défaut un place= administrative_locality ou autre quand
on recopie le cadastre ?

djakk


Le jeu. 23 août 2018 à 13:41, marc marc  a
écrit :

> Le 22. 08. 18 à 17:39, Christian Rogel a écrit :
> > La carte ne sera jamais trop chargée, c’est aux utilisateurs de filtrer
>
> 5ieme idée : si on suit les 4 premières, il y a aura
> tellement de lieu-dit que les cartes "standard" vont filtrer.
> donc on peux se demander quel ce qui est le plus utile ?
> encoder des infos masquées et peu utilisées ?
> quelqu'un va-t-il chercher le lieux-dit en plein champ ?
> ou rechercher l'ancien lieux-dit d'un champs devenu
> un lotissement dont on n'utilise plus que la nouvelle adresse ?
> sûrement que cela arrive mais cela doit être assez rare.
> les lieux-dits, c'est aussi en fonction de l'usage :
> Si le nom d'un lieu dit n'est jamais utilisé, ce n'est plus un lieu DIT.
> Si on voulait tous les lieux-dits, on aurait fait un import.
>
> si on veux faire de l'utile, je pense que les rues nommées manquantes
> sont une priorité... après à chacun de faire selon ses affinités bien
> évidement.
> ___
> 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] Lieux-dits

[djakk djakk]

Salut Valentin ! Quelles sont tes sources pour les lieux-dits ?

djakk


Le mer. 22 août 2018 à 12:06, Valentin GAUTREAU <
valentin.gautr...@valenting.fr> a écrit :

> Bonjour,
>
> J’ajoute depuis peu sur OSM les adresses et lieux-dits. Mais j’ai une
> question, faut-il vraiment tout ajouter sur les lieux-dits ? J'ai ajouté
> puis enlevé ce qui n'était pas rapprochable avec l'existant car il y a
> beaucoup de toponyme (parfois en doublons ou en 3 fois et ça charge
> énormément la carte).
>
> Merci d'avance.
>
> Valentin
>
> ___
> 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] nom du tunnel et nom de la voie utilisant le tunnel

[djakk djakk]

Problème voisin : le périphérique de Paris, avec pour chaque chaussée
“périphérique intérieure” et “périphérique extérieur” tout en ayant pour
nom “périphérique”


djakk


Le lun. 20 août 2018 à 09:56, Philippe Verdy  a écrit :

> il n'y a aucune raison que associated_street provoque cette erreur
> (d'autant plus que des voies ont deux noms en limite de commune, la même
> voie étant alors dans deux relations!)
>
> Le lun. 20 août 2018 à 08:11, Francescu GAROBY  a
> écrit :
>
>> "associated street" va provoquer une erreur, car un des noms de voie (le
>> tronçon qui portera le nom du pont/tunnel) ne correspondra pas au nom donné
>> à la relation.
>>
>>
>> Francescu
>>
>> Le dim. 19 août 2018 à 11:39, Philippe Verdy  a
>> écrit :
>>
>>> Il y a bien un "bridge_name". Cependant on a une alternative avec les
>>> relations:
>>> * associated street pour regrouper les segments d'une rue
>>> * les "routes" pour les segments d'itinéraires référencés (certains
>>> ayant des noms comme "L'Aquitaine" pour les autoroutes)
>>> * les fleuves et rivières aussi ont des noms locaux (ou qui peuvent
>>> changer le long du cours, notamment les cours d'eau internationaux)
>>> * les "lock_name" pour les noms d'écluse
>>> On a aussi les "alt_name" si on veut garder le nom de la rue et mettre
>>> le nom local du tunnel/pont/écluse comme nom local par défaut dans "name"
>>> (ce qui est souvent la meilleure solution: on privilégie le local)
>>>
>>>
>>> Le dim. 19 août 2018 à 11:32, David Crochet  a
>>> écrit :
>>>
 Bonjour

 j'ai pas chercher en profondeur mais que faire dans le cas où une voie,
 route, rue, passage utilise un tunnel (réciproquement un pont). Doit-il
 porter le nom du tunnel (et réciproquement) ou doit-il garder son nom,
 et dans ce dernier cas comment indiquer le nom du tunnel (et
 réciproquement)

 Pour un pont, l'astuce serait que l'emprise pourrait porter ce nom et
 non les voies qui l'emprunte. Mais je n'ai jamais vu d'emprise pour un
 tunnel.

 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
>>>
>>
>>
>> --
>> Francescu
>>
> ___
> 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] highway=* + area=yes vs area:highway=*

[djakk djakk]

No, all highways are areas :) Mapping them as a line is a manual
generalization ;)


djakk


Le ven. 10 août 2018 à 12:15, Andy Townsend  a écrit :

>
> > So basing on your opinions, it looks like highway=* + area=yes isn't
> incorrect, it's just not documented.
>
> I'd suggest that it depends what you're mapping. If it's a predominantly
> linear feature then it would be wrong to try and "somehow record the width"
> using area=yes on the highway tag - use area:highway (or width) for that.
>
> If it really is an area, then area=yes would make sense.  Most highways
> are not, though.
>
> Best Regards,
> Andy
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk