Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Hello,

En fait, certains ont sorti l'arme fatale qu'il y avait deja beaucoup trop
d'objets emergency=fire_hydrant pour en changer vers quelque chose de plus
cohérent
En plus de l'argument de Viking qui veut des données taillées pour
alimenter les GPS de ses collègues.
Je ne suis pas trop d'accord avec les deux idées, néanmoins en faisant le
compromis là-dessus, j'espère qu'ils accepteront de supprimer fire_hydrant:
et suction_point: du noms des clés :)

Pour le split, si il n'y a pas d'harmonisation entre fire_hydrant et
suction_point, tout peut être traité d'un seul coup non ?


François

Le 21 août 2017 à 02:02, marc marc  a écrit :

> et la proposition est de qualité même si comme toi, je pense qu'il
> aurait fallu profiter de l'occasion pour harmoniser +.
>
> Il serrait pratique qu'il coupe sa propal en 2 pour faire voter la
> première partie où il semble y avoir une unanimité même si on chipote
> encore sur certains détails.
> ___
> 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] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

Sarah, how would I set the node cache file to the repserv.apply_diffs()?
The idx param is passed to the apply_file() - for the initial PBF dump
parsing, but I don't see any place to pass it for the subsequent diff
processing.  I assume there must be a way to run .apply_diff() that will
download the minute diff file, update node cache file with the changed
nodes, and afterwards call my way handler with the updated way geometries.

Also, I assume you meant dense_file_array, not dense_file_cache. So in my
case I would use one of these idx values when calculating way centroid, and
None otherwise:
sparse_mem_array
dense_mmap_array
sparse_file_array,my_cache_file
dense_file_array,my_cache_file

Thanks!


On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann  wrote:

> On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > mmd, the centroids are calculated with this code, let me know if there
> is a
> > better way, I wasn't aware of any issues with the minute data updates.
> >   wkb = wkbfab.create_linestring(obj)
> >   point = loads(wkb, hex=True).representative_point()
> > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
>
> It doesn't look like you have any location cache included when
> processing updates, so that's unlikely to work.
>
> Minutely updates don't have the full node location information.
> If a way gets updated, you only get the new list of node ids.
> If the nodes have not changed themselves, they are not available
> with the update.
>
> If you need location information, you need to keep a persistent
> node cache in a file (idx=dense_file_cache,file.nodecache)
> and use that in your updates as well. It needs to be updated
> with the fresh node locations from the minutely change files
> and it is used to fill the coordinates for the ways.
>
> Once you have the node cache, you can get the geometries for
> updates ways. This is still only half the truth. If a node in
> a way is moved around, then this will naturally change the
> geometry of the way, but the minutely change file will have
> no indication that the way changed. Normally, these changes are
> relatively small and for some applications it is good enough
> to ignore them (Nominatim, the search engine, does so, for example).
> If you need to catch that case, then you also need to keep a
> persistent reverse index of which node is part of which way
> and for each changed node, update the ways it belongs to.
> There is currently no support for this in libosmium/pyosmium.
> So you would need to implement this yourself somehow.
>
> Kind regards
>
> Sarah
>
> >
> > Your query is correct, and you are right that (in theory) there shouldn't
> > be any ways without the center point. But there has been a number of ways
> > with only 1 point, causing a parsing error "need at least two points for
> > linestring". I will need to add some special handling for that
> > (suggestions?).
> >
> > You can see the error by adding this line:
> >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > The whole query --  http://tinyurl.com/ydf4qd62  (you can create short
> urls
> > with a button on the left side)
> >
> > On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> >
> > > Hi,
> > >
> > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > >
> > > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > > possible to crudely filter ways by location
> > >
> > > out of curiosity, can you say a few words on how your overall approach
> > > to calculate centroids for ways? As we all know it's an endless pain to
> > > get that information out of minutely diffs :)
> > >
> > > I have to say that I'm pretty much unfamiliar with SPARQL and just
> tried
> > > the following query. My expectation was that I won't get any results,
> > > making me wonder if my query has some issue?
> > >
> > > SELECT * WHERE {
> > >   ?osmId osmm:type 'w' .
> > >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > > } LIMIT 100
> > >
> > >
> > > BTW: A quick search on Github yielded the following:
> > > https://github.com/nyurik/osm2rdf. Would that be the right place to
> look
> > > for more details?
> > >
> > > Best,
> > > mmd
> > >
> > >
> > > --
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > talk mailing list
> > > talk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk
> > >
>
> > ___
> > 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: [OSM-talk-fr] le festival de tout les highway :-)

[Jérôme Amagat]

Le 21 août 2017 à 01:47, marc marc  a écrit :

> Le 21. 08. 17 à 01:27, Jérôme Amagat a écrit :
> > oui pour moi c'est c'est un gros problème des tag highway=*, on mélange
> > des choses différentes et donc après c'est difficiles de choisir le bon
> tag.
> > motorway c'est un type de route on utilise ce tag en regardant son
> > aspect et les règle qui s'y applique.
> je n'ai pas fait de comparaison internationale mais niveau français et
> suisse, le critère n'est clairement pas l'aspect, mais le panneau.
> Si tu as un panneau autoroute, cela en est une. Sinon non.
> qu'importe quelle est dégradée ou limitée à 80km/h sur un contournement.
> idem pour trunk
>

Oui mais le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2
voies séparées bandes d’arrêt d'urgence... et sur les règles a respecter,
pas de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
routes...


>
> > primary, secondary, tertiary c'est en fonction de l'importance dans le
> > réseau routier, en gros utiliser pour faire des grandes distances, des
> > moyennes ou des plus courtes.
> la distance, cea ne dépend que ton trajet :-)
> j'aurais plutôt dis que primary connecte des entités d'importance +
> élevée que ceux du tertiary
>

oui mais c'est la même chose ce que je veux dire c'est que si tu réalises
un trajet entre 2 patelins paumés (et que tu veux être rapide sans utiliser
autoroute et trunk) normalement tu vas passer une grande partie de ton
voyage sur une primary. Il y a de bonne chance que tu fasse unclassified ->
tertiary -> secondary -> primary -> secondary  -> tertiary  -> unclassified.


> > Pour trunk, on c'est pas c'est quoi le critère, quand je lis çà :
> > (https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk) "highway=trunk
> > for high performance roads that don't meet the requirement for motorway"
> > je dirais qu'il faut choisir a la tête : si on y roule plus vite que sur
> > d'autre type de route. Mais ici :
> je n'ai pas la même lecture.
> pour moi c'est "quasi-autoroute" mais il manque souvent qlq détails à
> ces routes pour être des autoroutes, souvent entrée trop courte.
> Donc trunk est entre autoroute et primaire.
>

oui mais c'est quoi qui manque exactement le 2x2voies les entrée trop
courte... et c'est dure de savoir ce qu'il y a entre autoroute et primaire
vu que pour ces 2 type de route les critere sont bien different. Certaine
route tertiaire sont plus proche en passant dessus d'une autoroute que
certaine route primaire.

>
> > highway=residential, c'est juste une route en zone résidentiel (donc
> > choix à la tête) ou c’est une route qui sert qu'aux résidents de la rue
> > (et des quelques rue environnantes) (donc choix grâce à son utilisation)?
> j'ai toujours considéré comme "route avec des maisons environnantes".
> ce n'est à mes yeux pas un access=destination version "plusieurs rues"
>

Moi ce que je comprend du wiki
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dresidential c'est que
c'est lié a l'utilisation qui est faite de la route et pas au lieu ou elle
se trouve.

>
> > highway=living_street, il faut utiliser ce tag suivant les règle qui s'y
> > applique mais qu'est ce qu'on fait quand cette route est aussi un
> > morceau de route du réseau tertiary, par exemple?
> > highway=living_street;tertiary ?
>
> l'urbanisme est à revoir dans ce cas :-)
> mais il me semble évident que c'est highway=living_street.
> Dans la même optique, on ne met pas highway=secondary;tertiary sur les
> sections communes.
>

Il y a a plusieurs endroits en france dans osm des départementales qui ont
tout pour être une tertiary et où quelqu'un a mit highway=living_street (je
n'ai pas vu de mes yeux si c'est vraiment une zone limitée à 20 km/h avec
priorité aux piétons)


>
> > il y a aussi highway=path choisi à la tête
> pas compris le problème/question
>

le probleme c'est, par exemple, pour un chemin en ville pas assez large
pour les voitures et interdit aux véhicules a moteur qui est surtout
utilisé par les piétons mais où les cyclistes ont le droit de passer il
faut utiliser quoi? highway=path avec motor=no (et en option bicyle=yes et
foot=yes)  ou highway=footway et bicyle=yes ou meme highway=cycleway et
foot=yes
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Jérôme Amagat]

Je rappelles que les relations network n'est sur le wiki qu'a l’état de
proposition, que cette proposition date de 2008, que rien n'a bougé sur
cette proposition depuis 2013 (et plus après 2009 ce n'est que pour ajouté
des exemples). Il y a des ajouts sur la page de discutions un peu plus
récent 2014 mais il sont négatif a l'ajout de ces relations.

Cette relation, ça serait juste, mettre tous les éléments qui ont le même
tag network=* dans une même relation (ou que les type=route_master) donc
c'est faire une liste, une catégorie ce qui ne se fait pas dans osm. Si
l'on veux tous les élément d'un même réseau il y a d'autre moyen de les
obtenir que de créer ce type de relation. Si c'est pour pouvoir mettre
quelque part le vrai nom du réseau pourquoi ne pas le mettre directement
dans le tag network=*.

Si vous pensez que ces relation doivent exister, remettez un peu a jour la
page de proposition avec des exemples qui existent encore et allez parler
d'un vote de cette proposition sur la liste tagging (en anglais :) ) .

Sinon pourquoi ne pas créer des relations pour tous les objets qui ont le
même operator comme par exemple EDF et vu que le même nom pourrait être
utilisé ailleurs dans le monde il faudrait pour tout les tag operator=*
ajouter "fr_" devant le nom comme par exemple operator=fr_EDF.

Pareil pour les nom de rue addr:street=*, par exemple, il faudrait
différencier l'"Avenue du général de Gaulle" des différentes villes, c'est
pas les mêmes. On fait quoi on préfixe avec le nom des ville? De toute
façon les noms on les mets que sur le tag name=* donc il n'a pas à être sur
addr:street=* donc on peut y mettre quelque chose qui servira de référence
pour chaque rue différente dans le monde. et on crée une relation pour
chaque rue où on met dans name=* le vrai nom de la rue. A mer**, ça existe
déjà, c'est les relation associatedStreet mais là on n'a pas modifié ce
qu'on met dans addr:street pour que 2 rues différentes n'est pas la même
valeurs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

et la proposition est de qualité même si comme toi, je pense qu'il 
aurait fallu profiter de l'occasion pour harmoniser +.

Il serrait pratique qu'il coupe sa propal en 2 pour faire voter la 
première partie où il semble y avoir une unanimité même si on chipote 
encore sur certains détails.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[marc marc]

Le 21. 08. 17 à 01:27, Jérôme Amagat a écrit :
> oui pour moi c'est c'est un gros problème des tag highway=*, on mélange 
> des choses différentes et donc après c'est difficiles de choisir le bon tag.
> motorway c'est un type de route on utilise ce tag en regardant son 
> aspect et les règle qui s'y applique.
je n'ai pas fait de comparaison internationale mais niveau français et 
suisse, le critère n'est clairement pas l'aspect, mais le panneau.
Si tu as un panneau autoroute, cela en est une. Sinon non.
qu'importe quelle est dégradée ou limitée à 80km/h sur un contournement.
idem pour trunk

> primary, secondary, tertiary c'est en fonction de l'importance dans le 
> réseau routier, en gros utiliser pour faire des grandes distances, des 
> moyennes ou des plus courtes.
la distance, cea ne dépend que ton trajet :-)
j'aurais plutôt dis que primary connecte des entités d'importance + 
élevée que ceux du tertiary

> Pour trunk, on c'est pas c'est quoi le critère, quand je lis çà : 
> (https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk) "highway=trunk 
> for high performance roads that don't meet the requirement for motorway" 
> je dirais qu'il faut choisir a la tête : si on y roule plus vite que sur 
> d'autre type de route. Mais ici : 
je n'ai pas la même lecture.
pour moi c'est "quasi-autoroute" mais il manque souvent qlq détails à 
ces routes pour être des autoroutes, souvent entrée trop courte.
Donc trunk est entre autoroute et primaire.

> highway=residential, c'est juste une route en zone résidentiel (donc 
> choix à la tête) ou c’est une route qui sert qu'aux résidents de la rue 
> (et des quelques rue environnantes) (donc choix grâce à son utilisation)?
j'ai toujours considéré comme "route avec des maisons environnantes".
ce n'est à mes yeux pas un access=destination version "plusieurs rues"

> highway=living_street, il faut utiliser ce tag suivant les règle qui s'y 
> applique mais qu'est ce qu'on fait quand cette route est aussi un 
> morceau de route du réseau tertiary, par exemple? 
> highway=living_street;tertiary ?

l'urbanisme est à revoir dans ce cas :-)
mais il me semble évident que c'est highway=living_street.
Dans la même optique, on ne met pas highway=secondary;tertiary sur les 
sections communes.

> il y a aussi highway=path choisi à la tête
pas compris le problème/question
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de bus en site propre

[marc marc]

Le 20. 08. 17 à 21:45, osm.sanspourr...@spamgourmet.com a écrit :

> lanes :bus 
> =* semble plus pour des 
> voies réservées.

oui lanes ne convient que pour une site propre accolé à la route

une voie physiquement séparé, n'est-ce très ressemblant à une avenue 
dont les 2 sens sont séparés d'arbre ou une voie de déserte ?
https://wiki.openstreetmap.org/wiki/FR:Frontage_road
dans les 2 cas, on n'utilise pas service mais une tag de route normal 
(residential par exemple) auquel il suffirait d'ajouter les tag access

je me demande si l'utilisation de service ne vient pas simplement du nom 
erronée "voie de service" parfois utilisée pour décrire le site propre.
Parce qu'à mes yeux, un site propre n'est pas un highway=service

Le 21. 08. 17 à 00:48, Jérôme Amagat a écrit :
 > il y a bien service=bus
 > Je pense donc que ce tag devrait disparaître du wiki.
même avis.
surtout qu'un service=driveway décrit parfaitement le chemin privé qui 
mènerait par exemple au dépot de bus.
c'est donc leur logiciel qui a un bug, il devrait tenir compte des access
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Bonsoir à tous,

Il y a actuellement des discussions en cours autour de la carto des bornes
à incendie.
Services d'urgence et Bnhynoteam, c'est pour vous

https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions

Globalement ca tourne autour de l'ordre à mettre dans certaines clés.
Et ajouter quelques renseignements supplémentaires :
- Tailles et types de connecteurs
- Couleurs, dispositifs réfléchissants
- Type de clés nécessaires pour ouvrir les bouches

De mon point de vue, les namespaces fire_hydrant: et suction_point:
devraient être supprimés pour avoir des clés plus légères et polyvalentes.
On a aussi discuté de la pertinence de regrouper les bornes pressurées et
les points de captage sous une même clé emergency=water_supply (ou
apparenté), mais apparemment ça ne fait pas l'unanimité.

Bref, si vous avez des remarques ou des retours à faire, c'est le moment
avant le vote qui aura lieu après que tous les points ouverts à la
discussion ne soient refermés.

Vu qu'il y a une nouvelle liste tagging-fr à laquelle tout le monde n'est
pas encore abonné, j'ai envoyé ce mail aux deux ML ;)

A+

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

Re: [OSM-talk-fr] Trunk

[Jérôme Amagat]

Le 20 août 2017 à 15:22, djakk djakk  a écrit :

> Cela dit, l'idéal serait de distinguer importance du réseau et type de
> route : on pourrait avoir des "motorway primary" et des "motorway
> secondary" (ou plutôt des "motorway trunk" et des "motorway primary"),
> exemple avec l'A106 en région parisienne qui pourrait être qualifiée
> d'autoroute secondaire.
>

oui pour moi c'est c'est un gros problème des tag highway=*, on mélange des
choses différentes et donc après c'est difficiles de choisir le bon tag.
motorway c'est un type de route on utilise ce tag en regardant son aspect
et les règle qui s'y applique.
primary, secondary, tertiary c'est en fonction de l'importance dans le
réseau routier, en gros utiliser pour faire des grandes distances, des
moyennes ou des plus courtes.
Pour trunk, on c'est pas c'est quoi le critère, quand je lis çà : (
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk) "highway=trunk for
high performance roads that don't meet the requirement for motorway" je
dirais qu'il faut choisir a la tête : si on y roule plus vite que sur
d'autre type de route. Mais ici :
https://wiki.openstreetmap.org/wiki/Key:highway on place trunk au dessus de
primary et donc comme les routes les plus importantes du pays.

D'ailleurs il y  a d'autres problèmes avec highway=*
highway=residential, c'est juste une route en zone résidentiel (donc choix
à la tête) ou c’est une route qui sert qu'aux résidents de la rue (et des
quelques rue environnantes) (donc choix grâce à son utilisation)?

highway=living_street, il faut utiliser ce tag suivant les règle qui s'y
applique mais qu'est ce qu'on fait quand cette route est aussi un morceau
de route du réseau tertiary, par exemple? highway=living_street;tertiary ?

il y a aussi highway=path choisi à la tête et highway=footway et cycleway
choisit en fonction des utilisateurs de la voie mais qui permet de supers
combos footway avec bicycle=yes et cycleway avec foot=yes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[François Lacombe]

Le 20 août 2017 à 20:37,  a écrit :

> Mais comme dit malicieusement François, si vous voulez, allez parler de
> nouveaux tags là-bas, on continuera de parler des tags ici
>

Ce n'était pas exactement ce que je voulais dire.
On parle bien des tags où on veut, le problème c'est que les conclusions
des discussions sont rarement capitalisées dans le pot commun.
Donc on peut bien en parler, mais si personne ne le sait il ne se passera
jamais rien


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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Vincent de Château-Thierry]

Bonsoir,

Le 20/08/2017 à 12:13, Christian Rogel a écrit :


Il y a quelques années, la vitalité de cette liste était ausculptée de temps en 
temps.


Oui j'ai notamment le souvenir de stats par Pieren...


Je fais le constat un peu pessimiste que, justement en dehors du tagging, seuls 
l’opendata et le tagging in-door sont des thèmes
réguliers.
Les compte-rendus d’action collective sont devenus rares, d’autant que le CA 
d’OSM Fr néglige d’y faire un minimum
de communication, car, s’il n’est pas opportun de bombarder un organe de la 
communauté non-organisée, cela n’est pas
une bonne raison pour disparaître des radars.
Ainsi, la consultation en cours des « mandataires » ayant fonctionné les années 
passées dans le but de rénover cette
mission mérite d’être répercutée. Cela pourrait susciter des candidatures.


D'accord là dessus. Et concernant les mandataires, c'est prévu, j'en ai 
parlé le 27/7 sur ca@ comme d'une action à venir. J'y travaille avec 
Tony, à mon retour de vacances.



On attend les retours de ceux qui ont été au State of the Map qui est en cours 
au Japon, mais, personne n’a pensé en en parler.


Il y aura ! Laisse leur le temps de rentrer ;)

vincent

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

Re: [OSM-talk-fr] ligne de bus en site propre

[Jérôme Amagat]

Sur la page : https://wiki.openstreetmap.org/wiki/Key:service
il y a bien service=bus mais cela a été ajouté, si on regarde l'historique,
le 17 mai 2017.
Et la page : https://wiki.openstreetmap.org/wiki/Tag:service%3Dbus
et un peu plus vieille novembre 2016 et donne comme raison pour la création
de ce tag :
"Some bus companies using OSM for routing exclude all highway
=service
 from their
routers unless they are also tagged service
=*bus*, so in order for
these routers to work appropriately, service lanes at bus stations used by
the mentioned companies need to be tagged with this."
ça ne me semble pas être une bonne raison pour utiliser ce tag.
Je pense donc que ce tag devrait disparaître du wiki.

Le 20 août 2017 à 22:48, Axelos  a écrit :

> Coucou,
>
> Le 20/08/2017 à 22:21, osm.sanspourr...@spamgourmet.com a écrit :
> > Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).
> >
> > Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier ce que
> > je dois mettre).
> >
> > Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite à
> > mettre service=bus.
>
> De mon coté j'utilise plutôt psv=yes aussi ( exemple
> http://osm.org/way/149797721 )
> De mémoire le choix est simplement dû au fait que psv inclus les taxis
> en plus des bus.
>
> --
>
> Je cherche à protéger ma vie privée numérique,
> s’il vous plaît faites-le aussi pour moi,
> choisissez une adresse de courriel alternative respectueuse.
>
> ___
> 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: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Dave F]

I will revert

DaveF

On 12/08/2017 22:39, Andrew Black wrote:



On 12 August 2017 at 13:12, Dave F > wrote:


Hi
I'm unsure if Northern Ireland, Wales & England should be tagged
as 'states'.

A new user's changeset comment:
Adding more info. is_in:country_code was missing. Also classified
Northern Ireland as a state so it appears in the same priority as
Wales. Was unclassified before


Doesn't make sense to me.

"A high-level sub-national political entity 
(Wikipedia-16px.png Federated state 
) in several large 
countries such as USA ("State"), Australia ("State"), Canada 
("Province"). May also be applicable in other countries and languages, 
"Provincia", "Estado", "Land" - whether is should be used is up to you 
and mappers in your own country."


 We are not a federated country. Suggest we revert it. Why is Wales a 
state in the first place.


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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Christian Rogel]

> Le 2017 Eost 20 à 20:37, osm.sanspourr...@spamgourmet.com a écrit :
>> Je fais le constat un peu pessimiste que, justement en dehors du tagging, 
>> seuls l’opendata et le tagging in-door sont des thèmes réguliers.
> Et comme le tagging in-door est du tagging...
> D'accord avec les autres remarques de Christian R.

Pour être plus précis, depuis plus d’un an, il ya 2 thèmes récurrents sur 
Talk-fr, qui sont l’opendata et la vérification de la qualité (autour d’Osmose, 
donc le « SAV » du tagging).
Le tagging in-door celui des gares des lignes de transport s’y sont ajoutés et 
ont beaucoup augmenté le trafic en juin-juillet.
L’amorce de la discussion sur les « trunk » a accru le poids des sujets sur le 
tagging.

A propos du manque de nouvelles sur la partie organisée de l’écosystème d’OSM, 
je rappelle qu’en juin, le bureau de la Fondation a reconnu l’association 
OpenStreetMap France, comme l’un de ses « chapitres locaux ». Cela donne une 
visibilité  plus grande à certaines réalisations des mappeurs français, qu’ils 
soient, ou non, membres d’OSM France.

Autre sujet qui concerne tout le monde : fêterons-nous d’une manière ou d’une 
autre le 13ème anniversaire d’OSM, née le 9 août 2004 ?



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

Re: [OSM-talk-fr] ligne de bus en site propre

[Axelos]

Coucou,

Le 20/08/2017 à 22:21, osm.sanspourr...@spamgourmet.com a écrit :
> Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).
> 
> Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier ce que
> je dois mettre).
> 
> Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite à
> mettre service=bus.

De mon coté j'utilise plutôt psv=yes aussi ( exemple
http://osm.org/way/149797721 )
De mémoire le choix est simplement dû au fait que psv inclus les taxis
en plus des bus.

-- 

Je cherche à protéger ma vie privée numérique,
s’il vous plaît faites-le aussi pour moi,
choisissez une adresse de courriel alternative respectueuse.

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

Re: [OSM-talk-fr] ligne de bus en site propre

[osm . sanspourriel]

C'est ici : https://wiki.openstreetmap.org/wiki/Key:service



Le 20/08/2017 à 22:34, Jo - winfi...@gmail.com a écrit :
ce maudit wiki :-) Je vais voir qu'est-ce qu'il y a marqué, mais sur 
la page du tag highway je ne trouve pas de service=bus.


Jo

2017-08-20 22:21 GMT+02:00 >:


Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).

Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier
ce que je dois mettre).

Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite
à mettre service=bus.

Jean-Yvon


Le 20/08/2017 à 22:09, Jo - winfi...@gmail.com
 a écrit :

Nous ne sommes pas tous partis :-) Pour les voiries réservées aux
bus j'utilise

highway=service
bus=yes
psv=yes
access=no

Polyglot

2017-08-20 21:55 GMT+02:00 David Crochet >:

Bonjour


Le 20/08/2017 à 21:45, osm.sanspourr...@spamgourmet.com
 a écrit :

lanes :bus
=* semble plus
pour des voies réservées.


Pour moi je le comprend comme toi : Parmis les n voies de
circulation de cette route, les bus sont réparties de la
façon suivante : *
et ce que tu présentes, c'est dans le cas d'un sens unique,
il faut ajouter backward et forward si nécessaire.

Cordialement

-- 
David Crochet



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





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




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





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


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

Re: [OSM-talk-fr] ligne de bus en site propre

[Jo]

ce maudit wiki :-) Je vais voir qu'est-ce qu'il y a marqué, mais sur la
page du tag highway je ne trouve pas de service=bus.

Jo

2017-08-20 22:21 GMT+02:00 :

> Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).
>
> Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier ce que
> je dois mettre).
>
> Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite à
> mettre service=bus.
> Jean-Yvon
>
>
> Le 20/08/2017 à 22:09, Jo - winfi...@gmail.com a écrit :
>
> Nous ne sommes pas tous partis :-) Pour les voiries réservées aux bus
> j'utilise
>
> highway=service
> bus=yes
> psv=yes
> access=no
>
> Polyglot
>
> 2017-08-20 21:55 GMT+02:00 David Crochet :
>
>> Bonjour
>>
>> Le 20/08/2017 à 21:45, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> lanes :bus
>> =* semble plus pour des
>> voies réservées.
>>
>>
>> Pour moi je le comprend comme toi : Parmis les n voies de circulation de
>> cette route, les bus sont réparties de la façon suivante : *
>> et ce que tu présentes, c'est dans le cas d'un sens unique, il faut
>> ajouter backward et forward si nécessaire.
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>> ___
>> 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] ligne de bus en site propre

[osm . sanspourriel]

Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).

Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier ce que 
je dois mettre).


Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite à 
mettre service=bus.


Jean-Yvon

Le 20/08/2017 à 22:09, Jo - winfi...@gmail.com a écrit :
Nous ne sommes pas tous partis :-) Pour les voiries réservées aux bus 
j'utilise


highway=service
bus=yes
psv=yes
access=no

Polyglot

2017-08-20 21:55 GMT+02:00 David Crochet >:


Bonjour


Le 20/08/2017 à 21:45, osm.sanspourr...@spamgourmet.com
 a écrit :

lanes :bus
=* semble plus pour
des voies réservées.


Pour moi je le comprend comme toi : Parmis les n voies de
circulation de cette route, les bus sont réparties de la façon
suivante : *
et ce que tu présentes, c'est dans le cas d'un sens unique, il
faut ajouter backward et forward si nécessaire.

Cordialement

-- 
David Crochet



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





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


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

Re: [Talk-de] Sand

[Marvin Gülker]

On Sun, Aug 20, 2017 at 06:02:59PM +0200, Markus wrote:
> Bis heute wusste ich nicht, dass Sand ein wertvoller Rohstoff ist, der
> weltweit kriminell und unwiederbringlich ausgebeutet wird.
> Handelsvolumen 70 Milliarden $, Inseln werden zerstört, Lebensräume
> verschwinden, Staatsgrenzen verschoben.
> 
> Es gibt also etwas zu mapen :-(
> https://www.arte.tv/de/videos/046598-000-A/sand-die-neue-umweltzeitbombe

Wer lieber liest: Die ZEIT hatte einen ausführlichen Artikel zu dem
Thema, der mittlerweile auf ZEIT Online verfügbar ist:
http://www.zeit.de/2014/34/strand-sand-verschwinden

> Mit herzlichem Gruss,
> Markus
> (der grad etwas besorgt ist über unsere Welt)

Es bleibt zu hoffen, dass der technische Fortschritt das Problem
rechtzeitig beseitigt...

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

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

Re: [OSM-talk-fr] ligne de bus en site propre

[Jo]

Nous ne sommes pas tous partis :-) Pour les voiries réservées aux bus
j'utilise

highway=service
bus=yes
psv=yes
access=no

Polyglot

2017-08-20 21:55 GMT+02:00 David Crochet :

> Bonjour
>
> Le 20/08/2017 à 21:45, osm.sanspourr...@spamgourmet.com a écrit :
>
> lanes :bus
> =* semble plus pour des
> voies réservées.
>
>
> Pour moi je le comprend comme toi : Parmis les n voies de circulation de
> cette route, les bus sont réparties de la façon suivante : *
> et ce que tu présentes, c'est dans le cas d'un sens unique, il faut
> ajouter backward et forward si nécessaire.
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de bus en site propre

[David Crochet]

Bonjour


Le 20/08/2017 à 21:45, osm.sanspourr...@spamgourmet.com a écrit :
lanes :bus 
=* semble plus pour des 
voies réservées.


Pour moi je le comprend comme toi : Parmis les n voies de circulation de 
cette route, les bus sont réparties de la façon suivante : *
et ce que tu présentes, c'est dans le cas d'un sens unique, il faut 
ajouter backward et forward si nécessaire.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] ligne de bus en site propre

[osm . sanspourriel]

Je parle bien d'un cas highway=service + service=bus.

Ce n'est pas une voie réservée mais une voie séparée physiquement du 
reste du trafic à cet endroit.


lanes :bus 
=* semble plus pour des 
voies réservées.


D'autres avis ? C'est vrai que maintenant les contributeurs transports 
sont sur leur liste ;-).


Jean-Yvon

Le 20/08/2017 à 21:11, marc marc - marc_marc_...@hotmail.com a écrit :

Le 20. 08. 17 à 20:42, osm.sanspourr...@spamgourmet.com a écrit :

JSOM rale sur service=bus pour cause de valeur peu usitée.

tu parles de highway=service + service=bus ?
je ne mettrais pas ce genre de tag même pour un site propre.
c'est pas mieux lanes:bus ? et/ou access=no + bus=yes ?
___
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] ligne de bus en site propre

[marc marc]

Le 20. 08. 17 à 20:42, osm.sanspourr...@spamgourmet.com a écrit :
> JSOM rale sur service=bus pour cause de valeur peu usitée.
tu parles de highway=service + service=bus ?
je ne mettrais pas ce genre de tag même pour un site propre.
c'est pas mieux lanes:bus ? et/ou access=no + bus=yes ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] ligne de bus en site propre

[osm . sanspourriel]

(c'est à propos de tags existants, j'ai le droit ;-)).

JSOM rale sur service=bus pour cause de valeur peu usitée.

Résultat j'ai mis bus=yes. Pourtant le wiki dit bien de mettre service=bus.

Bus=yes me semble plus générique car il permet tram=yes par exemple pour 
une voie tram+bus.


Le cas est peu fréquent mais sur certains ponts les trams roulent sur 
une voie partagée.


Je remets service=bus ? Dois-je laisser bus=yes ? On a par exemple pour 
cette voirie bicycle=no ce qui me semble cohérent.


Jean-Yvon

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[osm . sanspourriel]

Personnellement je n'ai aucun souvenir de message de Severin sur cette 
liste, hormis donc l'annonce de la création de cette liste.


J'espère que les contributeurs francophones resteront sur cette 
liste-ci, étant donné la proportion de messages tournant autour des tags 
sur cette liste-ci, il aurait été de bon ton d'en discuter ici avant.


Mais comme dit malicieusement François, si vous voulez, allez parler de 
nouveaux tags là-bas, on continuera de parler des tags ici.


Créer une ML spécifique, ça peut avoir un sens, je pense à la liste 
transports puisqu'il y a des choses assez spécifiques.


Les tags sont au contraire quelque chose d'assez partagé.


Je fais le constat un peu pessimiste que, justement en dehors du tagging, seuls 
l’opendata et le tagging in-door sont des thèmes réguliers.

Et comme le tagging in-door est du tagging...
D'accord avec les autres remarques de Christian R.

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

Re: [Talk-at] Löschung bzw. Änderungen von ca 240 Grenzen in AT

[Thomas Rupprecht]

>
> Wir hatten das schon mehrmals hier diskutiert, und ich bin noch immer der
> Meinung, dass es für jedes Objekt auf jedem offiziellen vorhandenen
> admin-level eine Relation geben sollte. Woher sollte eine Applikation, die
> alle Bezirke aus den DB zieht, sonst wissen, dass sie niedrigere
> admin-levels auch rausziehen muss und dass dann die Gemeinde "Steyr" auch
> als Bezirk mit dem Namen "Steyr-Stadt" zu zählen ist - oder noch besser,
> dass die Gemeinde Wien, die als Ganzes innerhalb des Bundeslandes
> Niederösterreich liegt, ihrerseits auch als eigenes Bundesland zu zählen
> ist? IMHO sollte das direkt aus OSM klar hervorgehen, und nicht eine
> möglicherweise schwer maschinenlesbare Liste außerhalb (Wiki oder sowas)
> erfordern.


Ich stimme dem voll und ganz zu. Das wird zur Auswertung eine Katastrophe


mfg Thomas Rupprecht
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-de] Sand

[Markus]

Liebe OSMer,

Bis heute wusste ich nicht, dass Sand ein wertvoller Rohstoff ist, der
weltweit kriminell und unwiederbringlich ausgebeutet wird.
Handelsvolumen 70 Milliarden $, Inseln werden zerstört, Lebensräume
verschwinden, Staatsgrenzen verschoben.

Es gibt also etwas zu mapen :-(
https://www.arte.tv/de/videos/046598-000-A/sand-die-neue-umweltzeitbombe

Mit herzlichem Gruss,
Markus
(der grad etwas besorgt ist über unsere Welt)





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

Re: [Talk-at] Löschung bzw. Änderungen von ca 240 Grenzen in AT

[Walter Nordmann]

Hi Friedrich,

"cadastral" ist mir auch nicht bekannt. 
naja, es gab weltweit einige (ca 130 cadastral und 30 cadastre), aber im 
wiki hab ich auch nix gefunden.
das ist eher ein Fall für die DWG. Wurde die schon benachrichtigt? 
Wenn ein Thema an verschiedenen Stellen diskutiert wird (ML, Webforum, 
Changesetdiskussionen), ist es schwer, einen Überblick über den Stand 
der Dinge zu bekommen.
DWG wollte ich euch überlassen. Würde ich aber begrüssen, falls ihr euch 
dazu durchringt. Und im Forum ist die Sache eh eingeschlafen.
Sorry für den Doppelpost, aber die Sache ging im Forum los und ich 
wollte/musste euch einbeziehen.


Gruss
walter aka wambacher


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

Re: [Talk-at] Löschung bzw. Änderungen von ca 240 Grenzen in AT

[Walter Nordmann]

Hi Robert,

Am 19.08.2017 um 14:08 schrieb Robert Kaiser:

ohne komische Dinge wie "cadastral" zu haben (was heißt das überhaupt?).

Das sind anscheinen "Gemeinden, die keine Gemeinden sind"  oder auch 
reine Ortsteile?
Rein formal haben die wohl keine Administration und daher nach der 
Meinung des Kollegens wohl bounday=administrative nicht "verdient".


Lustigerweise hat er den tag boundary=cadastral gewählt, obwohl es auch 
boundary=cadastre gibt. Zusammen genau 400. Ich werde jedenfalls für 
eine Splittergruppe von 0.1% der Boundaries keine Spezialbehandlung in 
meine Software einbauen. Somit ist eine Qualitätsanalyse und deren 
Export mit der Boundary Map nicht möglich.


werdet glücklich damit. :(

Bei der Frage der identischen Grenzen mit unterschiedlichem Adminlevel 
bin ich aber seiner Meinung. Zudem bin ich das schon seit Jahren in DE 
so gewohnt. Bei uns hat jede Grenze immer nur das niedrigste AL, was 
vorhanden ist. Dazu haben wir allerdings Gemeindeschlüssel, mit denen 
man das prima auseinanderklamüsern kann. Müsstet ihr eigentlich auch haben.


Gruss
walter aka wambacher

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

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Cela dit, l'idéal serait de distinguer importance du réseau et type de
route : on pourrait avoir des "motorway primary" et des "motorway
secondary" (ou plutôt des "motorway trunk" et des "motorway primary"),
exemple avec l'A106 en région parisienne qui pourrait être qualifiée
d'autoroute secondaire.

Mais, évoluons petit à petit :)


Le dim. 20 août 2017 à 15:09, djakk djakk  a écrit :

> Il y a aussi l'intérêt d'une harmornisation des définitions de "trunk"
> entre les différents pays du monde ; j'ai lancé en parallèle une discussion
> sur t...@openstreetmap.org à ce sujet.
>
>
> djakk
>
> Le dim. 20 août 2017 à 14:59, djakk djakk  a
> écrit :
>
>> Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
>> avoir une hiérarchisation plus fine. Et le classement du réseau breton en
>> "autoroute osm", j'approuve !
>>
>>
>> djakk
>>
>> Le dim. 20 août 2017 à 13:36, Christian Rogel <
>> christian.ro...@club-internet.fr> a écrit :
>>
>>>
>>> Le 2017 Eost 18 à 12:20, djakk djakk  a écrit :
>>>
>>> Salut,
>>>
>>> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>>>
>>> Moi je serai pour utiliser la définition anglaise et japonaise (un
>>> niveau de classification de route parmi les autres, au-dessus de primary).
>>> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
>>> intégralement en "trunk" malgré les traversées de villages et les portions
>>> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
>>> classification "route pour automobiles" donc ouvert aux vélos et aux
>>> piétons).
>>>
>>> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même
>>> si c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
>>> limitation par défaut d'une 2*2 voies est 110km/h).
>>>
>>> Je ne vois pas de 3e option.
>>>
>>> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>>>
>>>
>>> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>>>
>>>- dans la mesure où la réglementation évolue, soit vers une
>>>différenciation (voie rapide vs boulevard urbain, abaissement pour 
>>> certains
>>>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>>>critère pour juger des qualités des routes. Cela paraît même un peu « old
>>>school »
>>>- La question est autant de pouvoir surclasser certaines « primary »
>>>que de cesser de coller sans réflexion au schéma mental des 
>>> fonctionnaires
>>>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>>>différencient (et l’IGN les suit, bien sûr) les voies express des
>>>autoroutes, alors que l’expérience conducteur le dément
>>>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x
>>>2 (réseau breton, charentais, N 4, etc.), soit les classer classer
>>>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>>>- Décaler la qualification des niveaux supérieurs donnerait des
>>>marges pour hiérarchiser plus finement les autres voies
>>>
>>>
>>>
>>> Christian R.
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Il y a aussi l'intérêt d'une harmornisation des définitions de "trunk"
entre les différents pays du monde ; j'ai lancé en parallèle une discussion
sur t...@openstreetmap.org à ce sujet.


djakk

Le dim. 20 août 2017 à 14:59, djakk djakk  a écrit :

> Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
> avoir une hiérarchisation plus fine. Et le classement du réseau breton en
> "autoroute osm", j'approuve !
>
>
> djakk
>
> Le dim. 20 août 2017 à 13:36, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>>
>> Le 2017 Eost 18 à 12:20, djakk djakk  a écrit :
>>
>> Salut,
>>
>> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>>
>> Moi je serai pour utiliser la définition anglaise et japonaise (un niveau
>> de classification de route parmi les autres, au-dessus de primary).
>> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
>> intégralement en "trunk" malgré les traversées de villages et les portions
>> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
>> classification "route pour automobiles" donc ouvert aux vélos et aux
>> piétons).
>>
>> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même
>> si c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
>> limitation par défaut d'une 2*2 voies est 110km/h).
>>
>> Je ne vois pas de 3e option.
>>
>> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>>
>>
>> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>>
>>- dans la mesure où la réglementation évolue, soit vers une
>>différenciation (voie rapide vs boulevard urbain, abaissement pour 
>> certains
>>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>>critère pour juger des qualités des routes. Cela paraît même un peu « old
>>school »
>>- La question est autant de pouvoir surclasser certaines « primary »
>>que de cesser de coller sans réflexion au schéma mental des fonctionnaires
>>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>>différencient (et l’IGN les suit, bien sûr) les voies express des
>>autoroutes, alors que l’expérience conducteur le dément
>>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x 2
>>(réseau breton, charentais, N 4, etc.), soit les classer classer
>>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>>- Décaler la qualification des niveaux supérieurs donnerait des
>>marges pour hiérarchiser plus finement les autres voies
>>
>>
>>
>> Christian R.
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
avoir une hiérarchisation plus fine. Et le classement du réseau breton en
"autoroute osm", j'approuve !


djakk

Le dim. 20 août 2017 à 13:36, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Eost 18 à 12:20, djakk djakk  a écrit :
>
> Salut,
>
> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>
> Moi je serai pour utiliser la définition anglaise et japonaise (un niveau
> de classification de route parmi les autres, au-dessus de primary).
> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
> intégralement en "trunk" malgré les traversées de villages et les portions
> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
> classification "route pour automobiles" donc ouvert aux vélos et aux
> piétons).
>
> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même si
> c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
> limitation par défaut d'une 2*2 voies est 110km/h).
>
> Je ne vois pas de 3e option.
>
> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>
>
> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>
>- dans la mesure où la réglementation évolue, soit vers une
>différenciation (voie rapide vs boulevard urbain, abaissement pour certains
>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>critère pour juger des qualités des routes. Cela paraît même un peu « old
>school »
>- La question est autant de pouvoir surclasser certaines « primary »
>que de cesser de coller sans réflexion au schéma mental des fonctionnaires
>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>différencient (et l’IGN les suit, bien sûr) les voies express des
>autoroutes, alors que l’expérience conducteur le dément
>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x 2
>(réseau breton, charentais, N 4, etc.), soit les classer classer
>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>- Décaler la qualification des niveaux supérieurs donnerait des marges
>pour hiérarchiser plus finement les autres voies
>
>
>
> Christian R.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Löschung bzw. Änderungen von ca 240 Grenzen in AT

[Friedrich Volkmann]

On 19.08.2017 14:08, Robert Kaiser wrote:

Walter Nordmann schrieb:

Da mir manche Änderungen nicht geheuer sind, hatte ich im Forum
nachgefragt und als Antwort bekommen "ja, ist ok so".

https://forum.openstreetmap.org/viewtopic.php?id=59448


Und nachdem ich da reingelesen habe, ist das wohl endgültig das Ende davon,
dass mich Grenzen noch kümmern. Ich hatte extra Steyr auf zwei Relationen
gemacht, weil IMHO es wichtig ist, alle mit den "richtigen" admin-levels
drin zu haben, auch wenn die zwei levels haben (was heißt, es muss für jeden
level ein Objekt geben) damit jemand einfach alle Geminden oder alle Bezirke
rausziehen kann, ohne komische Dinge wie "cadastral" zu haben (was heißt das
überhaupt?).


"cadastral" ist mir auch nicht bekannt. Bitte alle diese Änderungen 
rückgängig machen. In NÖ habe ich gerade einen dieser Changesets revertiert, 
weil ich am Schneeberg die Gemeinden nicht mehr gefunden habe. Aber ich 
sehe, dass da noch viel mehr Changesets sind; das ist eher ein Fall für die 
DWG. Wurde die schon benachrichtigt? Wenn ein Thema an verschiedenen Stellen 
diskutiert wird (ML, Webforum, Changesetdiskussionen), ist es schwer, einen 
Überblick über den Stand der Dinge zu bekommen.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 20/08/2017 à 12:13, Jo a écrit :
Pouvez-vous me pointer sur une relation network utilisé dans le schéma 
public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où 
il me semblerait utile.
La relation 
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Network est sur 
plusieurs réseaux, il semblerait que ceux du wiki aient utilisé un modèle


l'Ain
https://wiki.openstreetmap.org/wiki/France:Ain/car.ain.fr#Relation_type.3Dnetwork
https://www.openstreetmap.org/relation/4487554
Lila
https://www.openstreetmap.org/relation/1733465
Tours
https://www.openstreetmap.org/relation/2680020
Tan
https://www.openstreetmap.org/relation/1733024
Toulouse
https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun#R.C3.A9seau_Tiss.C3.A9o
https://www.openstreetmap.org/relation/1518272
Haute-Garonne
https://www.openstreetmap.org/relation/1546978
Londres
https://wiki.openstreetmap.org/wiki/London_public_transport_tagging_scheme/Examples#Query_by_relation_type.3Dnetwork.2C_name.3DLondon_Buses
...



Mais j'ajoute network et operator sur tous les objets, les relations 
route et route_master et les noeuds 
highway=bus_stop/public_transport=platform.


Pas sur les noeuds public_transport=stop_position, car je n'ajoute 
jamais des détails sur ces noeuds-là. Pas sur les ways 
public_transport=platform/highway=platform non plus. Et pas non plus 
sur les ways fermés amenity=shelter/shelter_type=public_transport. 
Leur operator ne m'intéresse pas du tout.


Polyglot

2017-08-20 12:02 GMT+02:00 marc marc >:


Le 20. 08. 17 à 11:20, lenny.libre a écrit :
> 4- Bien que le wiki l'indique sur chaque objet,
quelle page ?

> est-il nécessaire de mettre "network" (et "network:wikidata")
sur tous les objets ?

selon moi, non c'est une mauvaise habitude.
il faudrait le mettre sur la relation la + haute, éventuellement
sur les
variations des routes par facilité, mais pas sur les objets physiques.

>      - _relation "network"_ : le tag doit être présent
même avis

>      - _relation "route_master"_ membre de la relation
"network", il me
> semble que la relation n'a pas besoin du tag supplémentaire "network" ;
même avis

> par contre si "route_master" n'était pas membre d'une telle
relation il
> faudrait le mettre ou créer la relation "network" ?
si on a crée une relation network, c'est pour l'utiliser. alors il
faut
y ajouter les nouveaux membres dès que possible et/ou créer les
nouvelles relations si un nouveau réseau apparaît.

>      - _relation "route"_ : le tag "network" ne me semble pas
utile, sur
> cette relation, puisqu'il est porté par la relation "route_master"
même avis

>      - _"public_transport=platform"_ il me semble que les tags
"network"
> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
> relation "route" ou "public_transport=stop_area"
ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir
ou un
abribus fait partir d'un réseau de transport en commun. c'est du
mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
routes, les carrefours, les lampes qui éclairent la route, la station
d'essence où le bus fait le plein, ...

>      - "_public_transport=__stop_position"_ ne me semble pas
nécessaire,
même incohérence

>      - "_public_transport=__stop_area"_ il me semble utile

La seule utilité que je vois c'est une situation temporaire. tu passes
devant un arrêt, tu notes les lignes de bus sur un node physique pour
mémoriser l'info vu sur le terrain.
Plus tard toi ou quelqu'un d'autre les migrera dans les relations.
Dans ce sens là c'est utile puisque cela permet de retrouver
facilement
les ajouts à faire, les lignes à créer, les réseaux qui manquent.

> ou bien vaut-il mieux être redondant pour favoriser la
réutilisation des
> données utilisation ?

ce n'est pas de la redondance, c'est le chat qui se mord la queue.
certains dupliquent cela sur tout les objets pour dire qu'ensuite
c'est
utile pour retrouver les objets afin de les rajouter dans les
relations
d’où proviennent l'info à la base. Si l'info était correcte au début,
rien n'a été amélioré. si l'info était incorrecte, rien n'a été
amélioré
non plus.
___
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] Trunk

[Christian Rogel]

> Le 2017 Eost 18 à 12:20, djakk djakk  a écrit :
> 
> Salut, 
> 
> Je reviens sur ce sujet épineux qu'est la classification "trunk". 
> 
> Moi je serai pour utiliser la définition anglaise et japonaise (un niveau de 
> classification de route parmi les autres, au-dessus de primary). 
> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait 
> intégralement en "trunk" malgré les traversées de villages et les portions à 
> 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de 
> classification "route pour automobiles" donc ouvert aux vélos et aux 
> piétons).  
> 
> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même si 
> c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la limitation 
> par défaut d'une 2*2 voies est 110km/h). 
> 
> Je ne vois pas de 3e option. 
> 
> But du jeu = mettre à jour le Wiki qui est contradictoire ;)

Ayant déjà soulevé cette question, je rappelle ma vision du problème :
dans la mesure où la réglementation évolue, soit vers une différenciation (voie 
rapide vs boulevard urbain, abaissement pour certains axes), il est de plus 
plus incohérent de faire de la vitesse autorisée un critère pour juger des 
qualités des routes. Cela paraît même un peu « old school »
La question est autant de pouvoir surclasser certaines « primary » que de 
cesser de coller sans réflexion au schéma mental des fonctionnaires de 
l’Équipement qui n’ont pasque des critères routiers, quand ils différencient 
(et l’IGN les suit, bien sûr) les voies express des autoroutes, alors que 
l’expérience conducteur le dément
On peut, soit reclasser comme « motorway » certaines liaisons 2 x 2 (réseau 
breton, charentais, N 4, etc.), soit les classer classer « motorroad » l(est-il 
normal que nous n’utilisions pas cet attribut ?)
Décaler la qualification des niveaux supérieurs donnerait des marges pour 
hiérarchiser plus finement les autres voies


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Well, it is technically possible, but I was thinking about performance and
stylesheet-maintenance issues ;)


Le dim. 20 août 2017 à 12:49, ajt1...@gmail.com  a
écrit :

> On 20/08/2017 11:36, djakk djakk wrote:
> >
> > Why I want to do that ? To improve openstreetmap, this is a worldwide
> > map and the renderer can't be adapted by countries.
> >
>
> Sure it can - it's perfectly possible for a render to use a
> location-sensitive rendering (I've just done it myself).
>
> Best Regards,
>
> Andy
>
>
> ___
> 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: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Philippe Verdy]

Rennes et Nantes l'utilisent, ce qui facilite le gros du chantier (même
s'il y a une page wiki dédiée, mais tout le monde ne sait pas éditer le
wiki non plus, c'est un autre outil de suivi).
Les autoroutes françaises l'utilisent. Les routes européennes l'ont
utilisé, mais ça a été supprimé depuis que les super-route ont été mises en
place (segmentation par pays) au lieu de remplacer les "route" ou
"route_master" par les nouvelles "super_route". (Eurovélo les a utilisé:
même problème).

Visiblement certains n'aiment pas les relations network chez eux : chaque
pays semble adopter ses méthodes de travail... une des raisons sans doute
de la création des "super-routes" qui reporte le problème ailleurs mais
n'aide pas du tout à garder une cohérence d'ensemble et la stabilité des
outils et méthodes utilisées, comme si une seule méthode permettait de
gérer ce chantier complexe et de longue haleine demandant beaucoup de
travail sur des zones très étendues sur lesquelles il est difficile de
maintenir la cohérence d'ensemble.

Il semble que la priorité soit de gérer les transport agglomération par
agglomération, mais le nombre d'interlocuteurs (collectivités, exploitants
concessionnaires, exploitants fournisseurs, fournisseurs annexes) et
l'intermodalité (multiples moyens de transport avec leurs propres règles
internes et schéma de tagging) n'aide pas à gérer ça simplement avec des
tags uniques. §Je vois mal comment se passer des relations, même si des
outils pour les éditer, et travailler dessus mais aussi les utiliser
commencent à apparaitre): supprimer directement sans s'intérroger sur les
outils qui voudraient les exploiter (avec de bonnes raisons) est à mon avis
une mauvaise idée: cela brise la volonté de structurer ça et ne fait que
retarder la maintenance et évite bloque ensuite le développement des outils
spécifiques et des réutilisations finales.

Du coup, ce qui est régulièrement cassé (abusivement à mon avis, comme si
ces objets n'existaient pas) est mis en oeuvre par des tas de bases
externes déconnectées, maintenues séparément et à grand frais, en divisant
les contributeurs en communautés plus petites et en favorisant l'émergence
de solutions propriétaires sur ces bases tierces, qui elles font toutes
l'effort de créer ces objets structurants. Cette suppression rend donc en
fait service à d'autres sources cartographiques propriétaires qui elles
vont vendre et restreindre les accès: Briser cet effort de rationalisation
c'est aider Google à faire ce qu'OSM par son incohérence se refuse en core
à faire


Le 20 août 2017 à 12:13, Jo  a écrit :

> Pouvez-vous me pointer sur une relation network utilisé dans le schéma
> public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où il me
> semblerait utile.
>
> Mais j'ajoute network et operator sur tous les objets, les relations route
> et route_master et les noeuds highway=bus_stop/public_transport=platform.
>
> Pas sur les noeuds public_transport=stop_position, car je n'ajoute jamais
> des détails sur ces noeuds-là. Pas sur les ways 
> public_transport=platform/highway=platform
> non plus. Et pas non plus sur les ways fermés 
> amenity=shelter/shelter_type=public_transport.
> Leur operator ne m'intéresse pas du tout.
>
> Polyglot
>
> 2017-08-20 12:02 GMT+02:00 marc marc :
>
>> Le 20. 08. 17 à 11:20, lenny.libre a écrit :
>> > 4- Bien que le wiki l'indique sur chaque objet,
>> quelle page ?
>>
>> > est-il nécessaire de mettre "network" (et "network:wikidata") sur tous
>> les objets ?
>>
>> selon moi, non c'est une mauvaise habitude.
>> il faudrait le mettre sur la relation la + haute, éventuellement sur les
>> variations des routes par facilité, mais pas sur les objets physiques.
>>
>> >  - _relation "network"_ : le tag doit être présent
>> même avis
>>
>> >  - _relation "route_master"_ membre de la relation "network", il me
>> > semble que la relation n'a pas besoin du tag supplémentaire "network" ;
>> même avis
>>
>> > par contre si "route_master" n'était pas membre d'une telle relation il
>> > faudrait le mettre ou créer la relation "network" ?
>> si on a crée une relation network, c'est pour l'utiliser. alors il faut
>> y ajouter les nouveaux membres dès que possible et/ou créer les
>> nouvelles relations si un nouveau réseau apparaît.
>>
>> >  - _relation "route"_ : le tag "network" ne me semble pas utile, sur
>> > cette relation, puisqu'il est porté par la relation "route_master"
>> même avis
>>
>> >  - _"public_transport=platform"_ il me semble que les tags "network"
>> > sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
>> > relation "route" ou "public_transport=stop_area"
>> ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
>> abribus fait partir d'un réseau de transport en commun. c'est du
>> mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
>> routes, les carrefours, les lampes qui éclairent la route, la station

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Andrew Hain]

While you can do that, it diminishes one of our most important offers, that we 
have a map of the whole world.

--
Andrew

From: ajt1...@gmail.com 
Sent: 20 August 2017 11:46:28
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] Highway=trunk : harmonization between countries ?

On 20/08/2017 11:36, djakk djakk wrote:
>
> Why I want to do that ? To improve openstreetmap, this is a worldwide
> map and the renderer can't be adapted by countries.
>

Sure it can - it's perfectly possible for a render to use a
location-sensitive rendering (I've just done it myself).

Best Regards,

Andy


___
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: [OSM-talk-fr] Camping fermé : supprimer? ajouter tag?

[Shohreh]

Merci. Bon à savoir.



--
View this message in context: 
http://gis.19327.n8.nabble.com/Camping-ferme-supprimer-ajouter-tag-tp5900976p5901018.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[ajt1...@gmail.com]

On 20/08/2017 11:36, djakk djakk wrote:


Why I want to do that ? To improve openstreetmap, this is a worldwide 
map and the renderer can't be adapted by countries.




Sure it can - it's perfectly possible for a render to use a 
location-sensitive rendering (I've just done it myself).


Best Regards,

Andy


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

I'm pretty sure that the use of "trunk" in UK or in Japan is about the
importance of the road, not about its characteristics :
https://www.mapillary.com/map/im/vBqrj5uGYBw05cd57g9TAg (this is the trunk
road linked in my previous mail ; there is pavement on the right side)

Why I want to do that ? To improve openstreetmap, this is a worldwide map
and the renderer can't be adapted by countries.


Le dim. 20 août 2017 à 11:45, Marc Gemis  a écrit :

> > So basically: please don't go adjusting roads in the US away from
> > established rough consensus because you think it ought to be different.
>
> or anywhere else I would say :-)
>
I'll adjust the wiki first >:>  ^-^
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Christian Rogel]

> Le 2017 Eost 20 à 00:12, marc marc  a écrit :
> 
> Bonsoir,
> 
> Le 19. 08. 17 à 22:16, Severin Menard a écrit :
>> annoncer la création de la liste de discussion OSM tagging-fr
> C'est en soi une très bonne idée que de fédérer la francophonie.
> 
> Mais quand je vois que pour la discussion de certains tag, on n'est 
> parfois pas nombreux à en discuter sur talk-fr, je me demande si diviser 
> avec une ml supplémentaire n'est pas contre productif,


On verra, si cette liste attirera les mappeurs passionnés, mais, il n’y a eu 
aucune raison de bien définie.
La liste Talk-fr avait vu sa fréquentation chuter au printemps et c’est les 
fils sur le tagging qui l’ont ranimée.
Si ces fils sont transférés vers Tagging-fr, que restera-t’il sur Talk-fr ?

Il y a quelques années, la vitalité de cette liste était ausculptée de temps en 
temps.
Je fais le constat un peu pessimiste que, justement en dehors du tagging, seuls 
l’opendata et le tagging in-door sont des thèmes
réguliers.
Les compte-rendus d’action collective sont devenus rares, d’autant que le CA 
d’OSM Fr néglige d’y faire un minimum
de communication, car, s’il n’est pas opportun de bombarder un organe de la 
communauté non-organisée, cela n’est pas
une bonne raison pour disparaître des radars.
Ainsi, la consultation en cours des « mandataires » ayant fonctionné les années 
passées dans le but de rénover cette 
mission mérite d’être répercutée. Cela pourrait susciter des candidatures.
On attend les retours de ceux qui ont été au State of the Map qui est en cours 
au Japon, mais, personne n’a pensé en en parler.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Jo]

Pouvez-vous me pointer sur une relation network utilisé dans le schéma
public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où il me
semblerait utile.

Mais j'ajoute network et operator sur tous les objets, les relations route
et route_master et les noeuds highway=bus_stop/public_transport=platform.

Pas sur les noeuds public_transport=stop_position, car je n'ajoute jamais
des détails sur ces noeuds-là. Pas sur les ways
public_transport=platform/highway=platform non plus. Et pas non plus sur
les ways fermés amenity=shelter/shelter_type=public_transport. Leur
operator ne m'intéresse pas du tout.

Polyglot

2017-08-20 12:02 GMT+02:00 marc marc :

> Le 20. 08. 17 à 11:20, lenny.libre a écrit :
> > 4- Bien que le wiki l'indique sur chaque objet,
> quelle page ?
>
> > est-il nécessaire de mettre "network" (et "network:wikidata") sur tous
> les objets ?
>
> selon moi, non c'est une mauvaise habitude.
> il faudrait le mettre sur la relation la + haute, éventuellement sur les
> variations des routes par facilité, mais pas sur les objets physiques.
>
> >  - _relation "network"_ : le tag doit être présent
> même avis
>
> >  - _relation "route_master"_ membre de la relation "network", il me
> > semble que la relation n'a pas besoin du tag supplémentaire "network" ;
> même avis
>
> > par contre si "route_master" n'était pas membre d'une telle relation il
> > faudrait le mettre ou créer la relation "network" ?
> si on a crée une relation network, c'est pour l'utiliser. alors il faut
> y ajouter les nouveaux membres dès que possible et/ou créer les
> nouvelles relations si un nouveau réseau apparaît.
>
> >  - _relation "route"_ : le tag "network" ne me semble pas utile, sur
> > cette relation, puisqu'il est porté par la relation "route_master"
> même avis
>
> >  - _"public_transport=platform"_ il me semble que les tags "network"
> > sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
> > relation "route" ou "public_transport=stop_area"
> ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
> abribus fait partir d'un réseau de transport en commun. c'est du
> mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
> routes, les carrefours, les lampes qui éclairent la route, la station
> d'essence où le bus fait le plein, ...
>
> >  - "_public_transport=__stop_position"_ ne me semble pas nécessaire,
> même incohérence
>
> >  - "_public_transport=__stop_area"_ il me semble utile
>
> La seule utilité que je vois c'est une situation temporaire. tu passes
> devant un arrêt, tu notes les lignes de bus sur un node physique pour
> mémoriser l'info vu sur le terrain.
> Plus tard toi ou quelqu'un d'autre les migrera dans les relations.
> Dans ce sens là c'est utile puisque cela permet de retrouver facilement
> les ajouts à faire, les lignes à créer, les réseaux qui manquent.
>
> > ou bien vaut-il mieux être redondant pour favoriser la réutilisation des
> > données utilisation ?
>
> ce n'est pas de la redondance, c'est le chat qui se mord la queue.
> certains dupliquent cela sur tout les objets pour dire qu'ensuite c'est
> utile pour retrouver les objets afin de les rajouter dans les relations
> d’où proviennent l'info à la base. Si l'info était correcte au début,
> rien n'a été amélioré. si l'info était incorrecte, rien n'a été amélioré
> non plus.
> ___
> 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] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 20. 08. 17 à 11:39, Philippe Verdy a écrit :
> L'outil semble aussi vouloir chercher les arrêts avec cette clé
quel outil ?
ce serrait l'occasion de leur soumettre le problème vu qu'en l'état
1) leur outil ne trouve pas tous les arrêts vu le mix de façon de faire
2) cela est un frein pour mettre fin au mix qui pose problème au no 1
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 20. 08. 17 à 11:20, lenny.libre a écrit :
> 4- Bien que le wiki l'indique sur chaque objet,
quelle page ?

> est-il nécessaire de mettre "network" (et "network:wikidata") sur tous les 
> objets ?

selon moi, non c'est une mauvaise habitude.
il faudrait le mettre sur la relation la + haute, éventuellement sur les 
variations des routes par facilité, mais pas sur les objets physiques.

>  - _relation "network"_ : le tag doit être présent
même avis

>  - _relation "route_master"_ membre de la relation "network", il me 
> semble que la relation n'a pas besoin du tag supplémentaire "network" ; 
même avis

> par contre si "route_master" n'était pas membre d'une telle relation il 
> faudrait le mettre ou créer la relation "network" ?
si on a crée une relation network, c'est pour l'utiliser. alors il faut 
y ajouter les nouveaux membres dès que possible et/ou créer les 
nouvelles relations si un nouveau réseau apparaît.

>  - _relation "route"_ : le tag "network" ne me semble pas utile, sur 
> cette relation, puisqu'il est porté par la relation "route_master"
même avis

>  - _"public_transport=platform"_ il me semble que les tags "network" 
> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une 
> relation "route" ou "public_transport=stop_area"
ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un 
abribus fait partir d'un réseau de transport en commun. c'est du 
mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les 
routes, les carrefours, les lampes qui éclairent la route, la station 
d'essence où le bus fait le plein, ...

>  - "_public_transport=__stop_position"_ ne me semble pas nécessaire, 
même incohérence

>  - "_public_transport=__stop_area"_ il me semble utile

La seule utilité que je vois c'est une situation temporaire. tu passes 
devant un arrêt, tu notes les lignes de bus sur un node physique pour 
mémoriser l'info vu sur le terrain.
Plus tard toi ou quelqu'un d'autre les migrera dans les relations.
Dans ce sens là c'est utile puisque cela permet de retrouver facilement 
les ajouts à faire, les lignes à créer, les réseaux qui manquent.

> ou bien vaut-il mieux être redondant pour favoriser la réutilisation des 
> données utilisation ?

ce n'est pas de la redondance, c'est le chat qui se mord la queue.
certains dupliquent cela sur tout les objets pour dire qu'ensuite c'est 
utile pour retrouver les objets afin de les rajouter dans les relations 
d’où proviennent l'info à la base. Si l'info était correcte au début, 
rien n'a été amélioré. si l'info était incorrecte, rien n'a été amélioré 
non plus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Marc Gemis]

> So basically: please don't go adjusting roads in the US away from
> established rough consensus because you think it ought to be different.

or anywhere else I would say :-)

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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Philippe Verdy]

"network=*" sur les relations "type=route" est pour l'instant nécessaire
pour pas mal d'outils qui justement cherchent ces routes en utilisant cette
clé (et aussi la clé "operator=*" comme discriminant quand il y a plusieurs
opérateurs d'un même réseau), car le numéro de ligne n'est pas suffisant.
C'est le cas pour les outils basés sur Overpass qui sont utilisés sans
nécessairemetn restreindre la zone de recherche avec une "bounding box".
L'outil semble aussi vouloir chercher les arrêts avec cette clé; il fait
ensuite les rapprochements manquants et tente de concilier plusieurs
versions du schéma Public Transport ("v1" et v2).
Cependant il n'en tient pas compte encore pour les recherches de
correspondances (tous opérateurs confondus à partir d'un arrêt trouvé, mais
il a du mal à trouver pas mal de correspondances quand les "zones d'arrêt",
ou "stop_area" sont étendues car il n'interprète pas encore ces relations).
Les schémas de transport sont encore à l'étape de conception et il y aura
des changements pour les stabiliser. Par prudence je conserverais donc
encore ces clés, les relations n'étant pas encore utilisées complètement
par tous les outils qui font des analyses différentes ou choisissent
d'ignorer une partie des données.

En revanche "network:wikidata=*" n'a pas lieu d'être en dehors de la
relation "type=network", bien que des réseaux de transport n'ont aucune
relation pour ça: dans ce cas ce sera mis sur la relation "route" ou
"route_master" (ou "super_route" qui est apparue plus récemment pour
grouper plusieurs relations "route" segmentées par pays, le "route_master"
regroupant alors des "super_route" au lieu des "route", avec une
"super_route" par direction ou variante: ces super-routes sont utilisées
notamment pour les routes euro-vélo, ou routes européennes, ou certaines
routes ferroviaires internationales, qui en fait sont exploitées par des
opérateurs différents et gérées par des collectivités différentes
simplement associées dans le projet commun mais qui gèrent chacune
individuellement les accords avec les transporteurs exploitants) 

Le 20 août 2017 à 11:20, lenny.libre  a écrit :

>
> Le 09/08/2017 à 00:03, marc marc a écrit :
>
> Le 08. 08. 17 à 21:51, osm.sanspourr...@spamgourmet.com a écrit :
>
> 4- est-il nécessaire de mettre operator sur tous les objets ?
>
> Je voulais, sur ce fil, rester sur "network" et j'ai écris "operator", je
> plane vraiment.
>   Après quelques jours d’absence, je ré-écris le §
>
> 4- Bien que le wiki l'indique sur chaque objet, est-il nécessaire de
> mettre "network" (et "network:wikidata") sur tous les objets ?
>Pour les nouveaux objets créés, il me semble que ce n'est pas
> nécessaire sur tous :
>
> - *relation "network"* : le tag doit être présent + ajout du tag
> "network:wikidata"
>
> - *relation "route_master"* membre de la relation "network", il me
> semble que la relation n'a pas besoin du tag supplémentaire "network" ; par
> contre si "route_master" n'était pas membre d'une telle relation il
> faudrait le mettre ou créer la relation "network" ?
>
> - *relation "route"* : le tag "network" ne me semble pas utile, sur
> cette relation, puisqu'il est porté par la relation "route_master"
>
> - *"public_transport=platform"* il me semble que les tags "network"
> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
> relation "route" ou "public_transport=stop_area"
>
> - "*public_transport=**stop_position"* ne me semble pas nécessaire,
> il est sur la route et/ou platform et/ou "public_transport=stop_area"
>
> - "*public_transport=**stop_area"* il me semble utile
>
> ou bien vaut-il mieux être redondant pour favoriser la réutilisation des
> données utilisation ?
>
> Leni
>
>
> Tous les objets n'ont pas même "operator". La plateforme en tant
> qu'abris peut être géré par un pubeux. C'est pour ça que tu mets "oui" ?
> Si on mettait operator sur le stop_position, ce serait logiquement celui
> qui demande de repeindre la chaussée. Un intérêt ? De plus pas visible
> sur le terrain.
>
> J'ai exactement le même avis.
> mettre l'opérateur de la ligne de bus sur le mobilier urbain est souvent
> une info erroné.
> il faut soit faire des fouilles dans le contrat et responsabilité de qui
> s'occupe du mobilier urbain et de l'entretient de la chaussée pour
> trouver le bon responsable.
> soit ne rien mettre sur les éléments physiques (on ne met pas de tag
> opérateur sur un banc public ni sur le panneau routier, c'est la même chose)
>
> Pour les relations, si connu le mettre sur route_master
> sur les différentes versions de l'itinéraire, pq pas si c'est utile à
> quelqu'un, sinon cela se déduit du route_master
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 09/08/2017 à 00:03, marc marc a écrit :

Le 08. 08. 17 à 21:51,osm.sanspourr...@spamgourmet.com  a écrit :

4- est-il nécessaire de mettre operator sur tous les objets ?
Je voulais, sur ce fil, rester sur "network" et j'ai écris "operator", 
je plane vraiment.

  Après quelques jours d’absence, je ré-écris le §

4- Bien que le wiki l'indique sur chaque objet, est-il nécessaire de 
mettre "network" (et "network:wikidata") sur tous les objets ?
   Pour les nouveaux objets créés, il me semble que ce n'est pas 
nécessaire sur tous :


    - _relation "network"_ : le tag doit être présent + ajout du tag 
"network:wikidata"


    - _relation "route_master"_ membre de la relation "network", il me 
semble que la relation n'a pas besoin du tag supplémentaire "network" ; 
par contre si "route_master" n'était pas membre d'une telle relation il 
faudrait le mettre ou créer la relation "network" ?


    - _relation "route"_ : le tag "network" ne me semble pas utile, sur 
cette relation, puisqu'il est porté par la relation "route_master"


    - _"public_transport=platform"_ il me semble que les tags "network" 
sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une 
relation "route" ou "public_transport=stop_area"


    - "_public_transport=__stop_position"_ ne me semble pas nécessaire, 
il est sur la route et/ou platform et/ou "public_transport=stop_area"


    - "_public_transport=__stop_area"_ il me semble utile

ou bien vaut-il mieux être redondant pour favoriser la réutilisation des 
données utilisation ?


Leni



Tous les objets n'ont pas même "operator". La plateforme en tant
qu'abris peut être géré par un pubeux. C'est pour ça que tu mets "oui" ?
Si on mettait operator sur le stop_position, ce serait logiquement celui
qui demande de repeindre la chaussée. Un intérêt ? De plus pas visible
sur le terrain.

J'ai exactement le même avis.
mettre l'opérateur de la ligne de bus sur le mobilier urbain est souvent
une info erroné.
il faut soit faire des fouilles dans le contrat et responsabilité de qui
s'occupe du mobilier urbain et de l'entretient de la chaussée pour
trouver le bon responsable.
soit ne rien mettre sur les éléments physiques (on ne met pas de tag
opérateur sur un banc public ni sur le panneau routier, c'est la même chose)

Pour les relations, si connu le mettre sur route_master
sur les différentes versions de l'itinéraire, pq pas si c'est utile à
quelqu'un, sinon cela se déduit du route_master
___
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=trunk : harmonization between countries ?

[djakk djakk]

>
> So basically: please don't go adjusting roads in the US away from
> established rough consensus because you think it ought to be different.


Of course ;-)


Le dim. 20 août 2017 à 04:00, Greg Troxel  a écrit :

>
> djakk djakk  writes:
>
> > In England and Japan, trunk roads continue inside village boundaries.
> > https://www.openstreetmap.org/#map=16/52.2685/0.7700 ;
> > https://www.openstreetmap.org/#map=16/35.6261/139.1128
> > Trunk is used as a super-primary class of roads.
>
> Yes, but in the US, that's not what it means.  Trunk differs from
> primary mostly in physical characteristics.
>
> I don't really understand the UK/JP rules.
>
> > I think it is better to try to harmonize between countries, and to use
> the
> > English model all over the world than the one with the motor road sign.
> The
> > latter model can still exist thanks to motorroad=yes.
>
> We don't use the motorroad sign in the US.
>
> So basically: please don't go adjusting roads in the US away from
> established rough consensus because you think it ought to be different.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: FW: Open survey on participation biases in OSM

[Zoe Gardner]

Dear OSM talk subscriber



A few weeks ago I posted a diary entry introducing myself, my interests in
OSM and showcasing an upcoming survey for OSM editors. I am a Research
Fellow in the Nottingham Geospatial Institute at the University of
Nottingham, interested in participation biases in geospatial crowdsourced
projects such as OSM and other Volunteered Geographical Information (VGI)
projects. My current research project is concerned with the way in which
participation biases in OSM may potentially affect the usability of the
data that is collected and subsequently what is available to location based
service providers which use OSM as their primary geospatial database.



You can read the full  entry by clicking on my diary entries in this link:



https://www.openstreetmap.org/user/Geospa_gal




The project is motivated by recent research that has found a strong male
bias in OSM participation. This has led to assertions that various
geospatial knowledge could be under represented or poorly recorded on the
map. However, the actual consequences of this bias remain little explored
or reported. By collecting information about contributors to OSM, which can
then be analyzed along with their editing patterns, the impacts of this
bias might begin to be measured and therefore better understood. I have
therefore published an online survey designed to collect information
directly from OSM editors and I would like to invite as many of you as
possible to participate. The survey is anonymous and takes a couple of
minutes to complete.



If you are an OSM contributor and are interested in or would like to
participate in the study, please click on the link below, which will take
you to the Bristol Online Survey website where you will find more
information and an opportunity to participate in the survey. As a small
incentive, at the close of the survey in a few weeks’ time, 60 respondents
will be drawn at random to receive a £15 Amazon voucher.



To participate in the survey, click on the link below:



https://nottingham.onlinesurveys.ac.uk/osm-user-profiles



Please do think about participating. It is hoped that knowledge about the
way participation biases impact on crowdsourced maps will enable new
strategies to be developed to address any resulting voids in the geospatial
information provided by amateur mappers. In turn this could strengthen the
role played by platforms such as OSM in urban planning and sustainability
and raise the profile of the important mapping work that you all do.



In the meantime, if you would like to know more about me, my research
activities or the project, please visit my University webpage (link below)
and do not hesitate to get in touch directly or via the OSM messaging
service.



https://www.nottingham.ac.uk/engineering/people/zoe.gardner



Thank you

Zoe







This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk