[OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

Bonjour à toutes et à tous,

Nous avons pas mal avancé sur la question d'un rendu cyclable libre,
alternatif à OpenCycleMap, avec Florimond depuis nos derniers messages
en février dernier sur cette liste.

Depuis, OSM-Fr a pu nous mettre en place un serveur pour le rendu monde
du style (un grand merci à l'asso !) et le style est donc désormais
visible pour le monde entier sur https://www.cyclosm.org/.

Le code est toujours libre et disponible sur
https://github.com/cyclosm/cyclosm-cartocss-style/. Les tuiles générées
par OSM-FR sont disponibles sur
https://dev.{s}.tile.openstreetmap.fr/cyclosm/{z}/{x}/{y}.png.


La motivation principale guidant les choix de rendus pour l'instant est
d'avoir un rendu adapté à tous les cyclistes cyclistes (urbains,
vélotaffeurs, ou cyclotouristes en rando) pour se repérer et s'orienter
à vélo. Ce rendu permet aussi aux contributeurs de repérer et identifier
les aménagements cyclables manquants. Ceci motive le rendu d'un certain
nombre d'éléments nouveaux tels que les ralentisseurs ou les sas vélos,
déjà traités, ou les cédez-le-passage-cycliste, à venir.


N'hésitez pas à ouvrir des tickets sur Github ou à commenter ici, nous
serions très intéressés par des retours sur cette première version.
Toute aide supplémentaire sur ce rendu est la bienvenue également :)

Pour ceux qui seront au State of the Map à Heidelberg, n'hésitez pas à
venir en discuter de vive voix à 17h aujourd'hui ! :)

Bonne journée !
-- 
Phyks

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

Re: [Talk-GB] TfL cycle data published - schema mapping

[jc129--- via Talk-GB]

Hi Martin,
A few comments from a non-cyclist:

• Cycle parking on/off carriageway:
Suggest location=carriageway could be invented instead?

• Two-tier cycle parking:
There's also bicycle_parking=double_decker/double_deck/double_deck_stands 
in use combined total of 6 instances. I don't have a preference for 
which tag is used.

• Side-road entry treatment:
The sidewalk=yes tag is already in use as an attribute of highway=* 
when it is not known which side(s) of a street has sidewalks. 
I would tag this node as highway=crossing and traffic_calming=table. 
If the adjacent highway already has cycleway:sideroad_continuity=yes 
I'm not convinced why you need a continuous=yes tag on the crossing 
node as well especially as there appears to be tactile_paving on the 
example photo too. 
Is there something special about these crossings that vehicles/cyclists 
turning into/out of the side-road must give way to pedestrians?

Kind Regards,
Jez C

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

Re: [talk-cz] Nový kruhový objezd namalovat

[Michal Poupa]

Ve Waze je to jednoduché a už je tam. Tady je hardcore.


21. 9. 2019 v 0:33, Jan Macura :
> 
> 
> Ahoj,
> 
> fakt? Po těch letech? :-O
> Z katastrální mapy to vidět není. Projektovou dokumentaci k tomu na webu 
> nenacházím. Chtělo by to vytáhnout kolo a požídit to GPX ;-)
> Ale nějak jsem ho tam čmárnul, aby bylo jasný, že tam je...
> 
> H.
> 
> 
> 
>> On Fri, 20 Sep 2019 at 22:00, Václav Kroupar  wrote:
>> Já se před nedávnem pokusil namalovat kruhák 
>> https://www.openstreetmap.org/way/710502150 Měl jsem k tomu GPX. Jestli mě 
>> někdo sledoval, tak si myslel, že jsem magor a kroužím tam na kole jak 
>> zmatená včela. Zatím mi za to nikdo nevynadal a dnes jsem si vzpomněl na 
>> výrobu kruhů, tak jsem jej ještě upravil.
>> Máme k tomu novému kruháku podklady?
>> 
>> Vašek
>> -- Původní e-mail --
>> Od: Michal Poupa 
>> Komu: OpenStreetMap Czech Republic 
>> Datum: 20. 9. 2019 20:43:09
>> Předmět: [talk-cz] Nový kruhový objezd namalovat 
>> bohužel neumám ho namalovat 
>> Cheb - křížení - Písečná - Osvobození
>> 
>> https://www.openstreetmap.org/way/339707479#map=19/50.06724/12.37129  
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] bus stop (correction)

[Jack Armstrong via talk]

Correction to my last email. Below is the correct text. Sorry about that.--If I understand your question correctly, the route number is part of a "relation". Go to the link below. https://www.openstreetmap.org/edit#map=23/39.54962/-104.99612With your mouse, select the Bus Stop node. Look to the left side of your screen. Scroll down to see the tags attached to this Bus Stop.Below the tags, you will see a relation in blue font. In this case the route number is, "RTD Route 0". If you scroll over the blue font text with your cursor you will see the road lights up in blue.The route number is placed in the route relation.See, "Adding a bus route to OpenStreetMap" here;https://wiki.openstreetmap.org/wiki/Buses#Adding_a_bus_route_to_OpenStreetMap-Original Message- From: 80hnhtv4a...@bk.ru
Sent: Sep 20, 2019 9:03 PM
To: Jack Armstrong 
Subject: Re: [OSM-talk] bus stop



	
 	
		
		




ok!
 
but where is the route number, if i am looking at a map i need to know what 
route,
 
if i am standing there i know what road i am on.


 

From: Jack 
Armstrong via talk 
Sent: Friday, September 20, 2019 8:45 PM
To: osm 
Cc: Jack Armstrong 
Subject: Re: [OSM-talk] bus stop
 
local_ref 
can be used for a platform 
numberhttps://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_positionhttps://www.openstreetmap.org/edit#map=23/39.54962/-104.99612___talk 
mailing 
listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk




		
	
	
www.theaveragenomad.com

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

Re: [OSM-talk] bus stop

[Jack Armstrong via talk]

If I understand your question correctly, the route number is part of a "relation". Go to the link below. https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_positionWith your mouse, select the Bus Stop node. Look to the left side of your screen. Scroll down to see the tags attached to this Bus Stop.Below the tags, you will see a relation in blue font. In this case the route number is, "RTD Route 0". If you scroll over the blue font text with your cursor you will see the road lights up in blue.The route number is placed in the route relation.See, "Adding a bus route to OpenStreetMap" here;https://wiki.openstreetmap.org/wiki/Buses#Adding_a_bus_route_to_OpenStreetMap-Original Message-
From: 80hnhtv4a...@bk.ru
Sent: Sep 20, 2019 9:03 PM
To: Jack Armstrong 
Subject: Re: [OSM-talk] bus stop



	
 	
		
		




ok!
 
but where is the route number, if i am looking at a map i need to know what 
route,
 
if i am standing there i know what road i am on.


 

From: Jack 
Armstrong via talk 
Sent: Friday, September 20, 2019 8:45 PM
To: osm 
Cc: Jack Armstrong 
Subject: Re: [OSM-talk] bus stop
 
local_ref 
can be used for a platform 
numberhttps://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_positionhttps://www.openstreetmap.org/edit#map=23/39.54962/-104.99612___talk 
mailing 
listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk




		
	
	


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

Re: [talk-au] Topic B: inconsistencies, idiosynchrosies and vagueness

[Warin]

There are inconsistencies from one place to another around the world.
These idiosyncrasies are what make the world so interesting for travellers.
OSM needs to cater for that.

Reading the OSM wiki can be reading the last change by some editor 
'fixing' it for their view, which may well be fine for their part of the 
world but not meet your view out your window.

Some mappers now ignore the wiki.

For Australian specific thing - this list and the wiki guidelines are 
your friend.
Changing the Australian Guide wiki is usually done by consultation here, 
so you get a broader view than a single idea.


On the general wiki .. vagueness may well be in place to allow for these 
world variations. Changing it is difficult in that others may object to 
your changes... the problem becomes one of reaching an agreement.. and 
then someone else objects etc.



On 21/09/19 12:02, Sebastian S. wrote:

Hi Andrew, I fully, whole heartedly agreed.
Wiki is supposed so evolve.
Gardening to fix little broken or spelling issues.
Bigger changes are best outlined here on the list to capture common 
sentiment.


I must admit I often just look up things in the wiki, so for me it is 
mostly a reference and it takes more commitment to actually improve. 
To update e.g. tagging guideline aspects one would first need to step 
back, which is what you seem to have done.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 September 2019 10:45:44 am AEST, Andrew Harvey 
 wrote:


I completely agree the "how to map" of OpenStreetMap (not just
tags, but also things like when to split a highway, when to snap
nodes, what should be mapped etc) is full of "inconsistencies,
idiosyncrasies and vagueness". But when I look at where OSM is
today I think we've done a pretty amazing job all things
considered, yes we still have much more work to do, but being a
mostly volunteer self organising community the best way to make
OSM stronger is hands on driving this change.

I think the easiest way to get started is improving documentation
on the wiki, documenting all the different "how to map" concepts
used today, documenting these "inconsistencies, idiosyncrasies and
vagueness", then as a community we can refine approaches to
eventually resolve these issues. There's a lot of precedent in OSM
for deprecating things when we have better/more commonly used.

Any time you encounter an inconsistencies I'd encourage you to
raise it, either on the globally tagging list, or if it's local
here on talk-au.

On Sat, 21 Sep 2019 at 09:57, Herbert.Remi via Talk-au
mailto:talk-au@openstreetmap.org>> wrote:

A special thank you for the links yesterday. I have read them.
"Australian Tagging Guidelines" and "Good practice" are worth
knowing and I am very grateful for our forefathers that put so
much effort into writing these documents. It worth noting,
however, when you compared the two that they are riddled with
inconsistencies, idiosyncrasies and vagueness. It is worth
remembering this when we experience another of those "I am
right, you are wrong" conversations.
Reading "Australian Tagging Guidelines," I thought of Geffory
Rush from Pirates of the Carribean, "they are more guidelines
than rules." Unapproved tracktypes for 4WD (inventing tags,
don't exist but perhaps they should) and small towns called
cities so they appear the map (mapping for the renderer), and
the principle of "we map what is there" but then don't map
what is private (often difficult to verify too). The
descriptions are full of contradictions and vagueness. The
"Lifecycle prefix" wikitext needs more work, particularly
examples of use to get consistency in its application. As much
of it is not rendered (Mapnik), mapping it could be considered
as a low priority.
Harry Wood's blog "community smoothness" addresses vagueness
in language and how everybody has a different opinion of what
a text means. That is not new of course and with certainty,
everybody has an opinion about what the right way is. It is
human nature, when it comes to our own beliefs, every evidence
supporting it is embraced and every evidence against excluded.
Finally, it is easy to forget that the Wiki is written in
dozens of different languages and there will be
inconsistencies between Wiki entries in different languages. I
can verify that for two. English and German wiki pages
descriptions are not surprisingly culture-specific (see also
the chemist/pharmacy/drug store discussion for AU/UK/US
comparison).
Despite our best efforts inconsistencies, idiosyncrasies and
vagueness will reign in the OSM anarchy.
___

Re: [talk-au] topic A: the platform itself

[Sebastian S.]

Hello, 
I think it is important to be precise in the language we use. Therefore I'd 
like to point out that this is a mailing list and not a forum.

If you find the UI poor then this likely due to the way you use the mailing 
list.

Browsing the archives on the list website is not how I participate on current 
topics.

I use mostly my phone's email client. My email client does thread topics 
together which allows to follow or skip certain topics.

Just thought I throw this in because when people speak of a forum I don't think 
of this mailing list and forum UI has in my view no relevance to mailing list 
UI.

Cheers, Seb
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 20 September 2019 5:25:18 pm AEST, Edoardo Neerhut  
wrote:
>Thanks for bringing this up Herbert.
>
>*Similar sentiments*
>This has actually been bothering me the last few weeks as I started to
>realise how much of my day is spent reading through talklists that do
>not
>have relevance to me or that I do not have time to respond to. For
>those of
>us subscribed to multiple talklists, it becomes a very time consuming
>and
>inefficient communication method.
>
>The problem is that you need to read every single one in case you miss
>something relevant. There are lot of good conversations taking place
>and I
>wish I had time to engage more, but I need to be selective.
>
>*The platform*
>I like the idea of a forum which can be categorised and allow the
>viewer to
>make quicker decisions about which topics that would like to engage
>with.
>Whether that is the OpenStreetMap forum or something else doesn't
>bother
>me. Although the OpenStreetMap forum would make sense so that people
>can
>find it easily.
>
>Slack is very convenient, but it is not good for important discussions
>because the messages get archived unless you sign up to a cost
>prohibitive
>plan which our community would not be able to afford.
>
>*Setting a standard*
>I am not sure any of this can be dictated, but it is a good discussion
>to
>have and I would be interested to see how the rest of the community
>feels.
>Of course asking here is inherently going to target those already using
>the
>talklists, so I will bring this up in other places as well.
>
>Overall I support the interest to discuss this on a more efficient,
>intuitive platform.
>
>On Fri, 20 Sep 2019 at 09:10, David Wales 
>wrote:
>
>> I am a member of some international OSM Slack channels.
>>
>> However, because it requires a whole different app (which I only have
>> space for on my computer), I only check it monthly at best.
>>
>> On the other hand, I read every talk-au message within a few days of
>> original posting, because they all arrive in my email inbox on my
>phone.
>>
>> If the number of talk-au emails reaches overwhelming levels, it might
>be
>> necessary to investigate other solutions. However, I don't think we
>have
>> reached that point yet.
>>
>> If we ever did explore alternatives, I would prefer an open platform,
>> which we can host ourselves, rather than Slack or some other
>proprietary
>> system.
>>
>> Regards,
>> David
>>
>> On 20 September 2019 4:31:44 pm AEST, Frederik Ramm
>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:
>>>
 I will post several concerns and information on several issues, but
>the
 first is this platform itself.

>>>
>>> You call this platform a "forum" which is ok in the abstract sense,
>but
>>> note that there is actually an Australia forum in addition to this
>>> Australia mailing list
>>> (https://forum.openstreetmap.org/viewforum.php?id=24). The forum
>>> provides a slightly different user experience but is used less.
>>>
>>> In other countries, people have set up Slack channels or Facebook
>groups
>>> or even more esoteric channels of communication, in addition of or
>as a
>>> replacement for mailing lists - browse
>>> https://github.com/osmlab/osm-community-index if you want to get an
>idea.
>>>
>>> There's no strict rule about where the OSM community should discuss
>>> their issues, however media that requires prior registration with a
>>> third-party entity - like Slack or Facebook - are sometimes frowned
>upon
>>> as they give control over who can participate to that third party
>and
>>> might require the participant to agree to wide-ranging exploitation
>of
>>> their personal data by a commercial entity.
>>>
>>> In Germany where I hail from, the forum and the mailing list are
>used by
>>> about the same number of (but largely different) people, and since
>the
>>> total number of contributors is large enough to guarantee lively
>>> discussion on both, that's totally fine. Germany also has mailing
>lists
>>> for individual states but they are used very little, and even
>>> state-specific issues would often be discussed on the nationwide
>list to
>>> ensure they get enough attention.
>>>
>>> Speaking very generally, OSM has achieved the success it has with a
>>> "just do it" attitude: Instead of 

Re: [talk-au] Topic B: inconsistencies, idiosynchrosies and vagueness

[Sebastian S.]

Hi Andrew, I fully, whole heartedly agreed.
Wiki is supposed so evolve. 
Gardening to fix little broken or spelling issues.
Bigger changes are best outlined here on the list to capture common sentiment.

I must admit I often just look up things in the wiki, so for me it is mostly a 
reference and it takes more commitment to actually improve. To update e.g. 
tagging guideline aspects one would first need to step back, which is what you 
seem to have done.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 21 September 2019 10:45:44 am AEST, Andrew Harvey  
wrote:
>I completely agree the "how to map" of OpenStreetMap (not just tags,
>but
>also things like when to split a highway, when to snap nodes, what
>should
>be mapped etc) is full of "inconsistencies, idiosyncrasies and
>vagueness".
>But when I look at where OSM is today I think we've done a pretty
>amazing
>job all things considered, yes we still have much more work to do, but
>being a mostly volunteer self organising community the best way to make
>OSM
>stronger is hands on driving this change.
>
>I think the easiest way to get started is improving documentation on
>the
>wiki, documenting all the different "how to map" concepts used today,
>documenting these "inconsistencies, idiosyncrasies and vagueness", then
>as
>a community we can refine approaches to eventually resolve these
>issues.
>There's a lot of precedent in OSM for deprecating things when we have
>better/more commonly used.
>
>Any time you encounter an inconsistencies I'd encourage you to raise
>it,
>either on the globally tagging list, or if it's local here on talk-au.
>
>On Sat, 21 Sep 2019 at 09:57, Herbert.Remi via Talk-au <
>talk-au@openstreetmap.org> wrote:
>
>> A special thank you for the links yesterday. I have read them.
>"Australian
>> Tagging Guidelines" and "Good practice" are worth knowing and I am
>very
>> grateful for our forefathers that put so much effort into writing
>these
>> documents. It worth noting, however, when you compared the two that
>they
>> are riddled with inconsistencies, idiosyncrasies and vagueness. It is
>worth
>> remembering this when we experience another of those "I am right, you
>are
>> wrong" conversations.
>> Reading "Australian Tagging Guidelines," I thought of Geffory Rush
>from
>> Pirates of the Carribean, "they are more guidelines than rules."
>Unapproved
>> tracktypes for 4WD (inventing tags, don't exist but perhaps they
>should)
>> and small towns called cities so they appear the map (mapping for the
>> renderer), and the principle of "we map what is there" but then don't
>map
>> what is private (often difficult to verify too). The descriptions are
>full
>> of contradictions and vagueness. The "Lifecycle prefix" wikitext
>needs more
>> work, particularly examples of use to get consistency in its
>application.
>> As much of it is not rendered (Mapnik), mapping it could be
>considered as a
>> low priority.
>> Harry Wood's blog "community smoothness" addresses vagueness in
>language
>> and how everybody has a different opinion of what a text means. That
>is not
>> new of course and with certainty, everybody has an opinion about what
>the
>> right way is. It is human nature, when it comes to our own beliefs,
>every
>> evidence supporting it is embraced and every evidence against
>excluded.
>> Finally, it is easy to forget that the Wiki is written in dozens of
>> different languages and there will be inconsistencies between Wiki
>entries
>> in different languages. I can verify that for two. English and German
>wiki
>> pages descriptions are not surprisingly culture-specific (see also
>the
>> chemist/pharmacy/drug store discussion for AU/UK/US comparison).
>> Despite our best efforts inconsistencies, idiosyncrasies and
>vagueness
>> will reign in the OSM anarchy.
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] bus stop

[Jack Armstrong via talk]

local_ref can be used for a platform number

https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position

https://www.openstreetmap.org/edit#map=23/39.54962/-104.99612

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

Re: [talk-au] Topic B: inconsistencies, idiosynchrosies and vagueness

[Andrew Harvey]

 I completely agree the "how to map" of OpenStreetMap (not just tags, but
also things like when to split a highway, when to snap nodes, what should
be mapped etc) is full of "inconsistencies, idiosyncrasies and vagueness".
But when I look at where OSM is today I think we've done a pretty amazing
job all things considered, yes we still have much more work to do, but
being a mostly volunteer self organising community the best way to make OSM
stronger is hands on driving this change.

I think the easiest way to get started is improving documentation on the
wiki, documenting all the different "how to map" concepts used today,
documenting these "inconsistencies, idiosyncrasies and vagueness", then as
a community we can refine approaches to eventually resolve these issues.
There's a lot of precedent in OSM for deprecating things when we have
better/more commonly used.

Any time you encounter an inconsistencies I'd encourage you to raise it,
either on the globally tagging list, or if it's local here on talk-au.

On Sat, 21 Sep 2019 at 09:57, Herbert.Remi via Talk-au <
talk-au@openstreetmap.org> wrote:

> A special thank you for the links yesterday. I have read them. "Australian
> Tagging Guidelines" and "Good practice" are worth knowing and I am very
> grateful for our forefathers that put so much effort into writing these
> documents. It worth noting, however, when you compared the two that they
> are riddled with inconsistencies, idiosyncrasies and vagueness. It is worth
> remembering this when we experience another of those "I am right, you are
> wrong" conversations.
> Reading "Australian Tagging Guidelines," I thought of Geffory Rush from
> Pirates of the Carribean, "they are more guidelines than rules." Unapproved
> tracktypes for 4WD (inventing tags, don't exist but perhaps they should)
> and small towns called cities so they appear the map (mapping for the
> renderer), and the principle of "we map what is there" but then don't map
> what is private (often difficult to verify too). The descriptions are full
> of contradictions and vagueness. The "Lifecycle prefix" wikitext needs more
> work, particularly examples of use to get consistency in its application.
> As much of it is not rendered (Mapnik), mapping it could be considered as a
> low priority.
> Harry Wood's blog "community smoothness" addresses vagueness in language
> and how everybody has a different opinion of what a text means. That is not
> new of course and with certainty, everybody has an opinion about what the
> right way is. It is human nature, when it comes to our own beliefs, every
> evidence supporting it is embraced and every evidence against excluded.
> Finally, it is easy to forget that the Wiki is written in dozens of
> different languages and there will be inconsistencies between Wiki entries
> in different languages. I can verify that for two. English and German wiki
> pages descriptions are not surprisingly culture-specific (see also the
> chemist/pharmacy/drug store discussion for AU/UK/US comparison).
> Despite our best efforts inconsistencies, idiosyncrasies and vagueness
> will reign in the OSM anarchy.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] bus stop

[Joseph Eisenberg]

On 9/21/19, 80hnhtv4a...@bk.ru <80hnhtv4a...@bk.ru> wrote:
> yes the iD
>
> if i put in the route no. in the name space, the wiki's say that is wrong or
> the route no is optional.

Do you mean, in the name field of the highway=bus_stop node?

The name of a highway=bus_stop should be the name of the bus stop, not
the route number of the bus line that stops there.

Use a route relation with type=route, route=bus to add the route number:
https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus

This is done because some bus stops are used by more than one route.

However, you can also use a different tag to add the reference number
of the route on the highway=bus_stop object. There is a tag
route_ref=* which is pretty common, though it's not yet been
documented on the wiki:

https://taginfo.openstreetmap.org/keys/route_ref

So if you have a bus stop and the sign says "bus stop number 1234" and
it's for bus route A1, you could tag this way:

highway=bus_stop
ref=1234
route_ref=A1

But ideally you might also make a type=route + route=bus relation too,
because most database users are not going to know about route_ref

- Joseph Eisenberg

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

[talk-au] Topic B: inconsistencies, idiosynchrosies and vagueness

[Herbert.Remi via Talk-au]

A special thank you for the links yesterday. I have read them. "Australian 
Tagging Guidelines" and "Good practice" are worth knowing and I am very 
grateful for our forefathers that put so much effort into writing these 
documents. It worth noting, however, when you compared the two that they are 
riddled with inconsistencies, idiosyncrasies and vagueness. It is worth 
remembering this when we experience another of those "I am right, you are 
wrong" conversations.
Reading "Australian Tagging Guidelines," I thought of Geffory Rush from Pirates 
of the Carribean, "they are more guidelines than rules." Unapproved tracktypes 
for 4WD (inventing tags, don't exist but perhaps they should) and small towns 
called cities so they appear the map (mapping for the renderer), and the 
principle of "we map what is there" but then don't map what is private (often 
difficult to verify too). The descriptions are full of contradictions and 
vagueness. The "Lifecycle prefix" wikitext needs more work, particularly 
examples of use to get consistency in its application. As much of it is not 
rendered (Mapnik), mapping it could be considered as a low priority.
Harry Wood's blog "community smoothness" addresses vagueness in language and 
how everybody has a different opinion of what a text means. That is not new of 
course and with certainty, everybody has an opinion about what the right way 
is. It is human nature, when it comes to our own beliefs, every evidence 
supporting it is embraced and every evidence against excluded.
Finally, it is easy to forget that the Wiki is written in dozens of different 
languages and there will be inconsistencies between Wiki entries in different 
languages. I can verify that for two. English and German wiki pages 
descriptions are not surprisingly culture-specific (see also the 
chemist/pharmacy/drug store discussion for AU/UK/US comparison).
Despite our best efforts inconsistencies, idiosyncrasies and vagueness will 
reign in the OSM anarchy.___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk] Fwd: Re: bus stop

[80hnhtv4agou--- via talk]

Ok !
 
it is “hail and ride” but i am in the USA, we do not say it that way, as it 
say’s you put it on the way, road line
 
i have been using the point, and putting it on the side of the road.
 
but our signs have numbers on it.
 
the fields are wrong for our standards, and the only field that shows on 
the standard web edit map is name.

all i know to use is the ID edit.

From: Joseph Eisenberg
Sent: Friday, September 20, 2019 5:44 PM
To: OpenStreetMap talk mailing 
list
Subject: Re: [OSM-talk] bus stop
 
If a bus stop sign has a number, you can add this to the highway=bus_stop 
node with ref=*
 
BTW, I wouldn’t call “hail and ride” part of tyr public_transport proposal. 
As the link shows, it’s clearly a separate proposal. But it sounds sensible, 
and 
I agree that if a route has no fixed stops it makes sense to just create a 
route 
relation and only add the first and last stop as highway=bus_stop.
 
That’s what works here in Indonesia, where most local buses will pick up or 
drop off passengers anywhere along the route.
 
Joseph
 
On Sat, Sep 21, 2019 at 3:14 AM Johnparis 
< ok...@johnfreed.com > wrote:
>If the bus route does not have fixed stops, it is a hail-and-ride route, 
>  not a fixed-stop route. Public Transport v2 takes both possibilities into 
>  account.
> 
>The route relation should include all the road segments involved, and the 
>  relevant segments should have the role:
>hail_and_ride
> 
>See  https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride
> 
>As to the name vs number, the agreed naming convention is pretty clearly 
>  spelled out in PTv2. Usually something like this:
> 
>For the route master ... Bus 2: City Hall <-> Library (or you can 
>  use <=> or ↔) 
>For one variant ... Bus 2: City Hall -> Library (or you can use => 
>  or →)
>For another variant ... Bus 2: Library -> City Hall
> 
>etc.
> 
>I have ridden buses in many US cities (although never a hail-and-ride) 
>  and they fit nicely into this format.
> 
>The line number itself goes in the ref tag in the route 
>  relation.
> 
> 
> 
> 
> 
>On Fri, Sep 20, 2019 at 5:03 PM john whelan 
>  < jwhelan0...@gmail.com > wrote:
>>I'm not sure this is quite the place for this discussion but Europe 
>>also has some bus routes that pick up and drop off on request.  Just 
>>don't map none existent stops. 
>> 
>>Ottawa Canada has fixed stops as do many other locations in North 
>>America.
>> 
>>I suggest you try to map following the wiki map features.  If 
>>someone is changing your tags then discuss the matter with them as is the 
>>traditional way to resolve the problem.
>> 
>>Cheerio John
>> 
>>On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- 
>>via talk, < talk@openstreetmap.org > 
>>wrote:
>>>europe vs. united states,
>>> 
>>>https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>> 
>>>1. does not match the way we catch the bus in the usa and the fields 
>>>  are to strict.
>>> 
>>>2. is a place where i will stand to catch the bus, sign or no sign 
>>>  etc.
>>> 
>>>3. the map point reflects the area and stops are not set in stone but 
>>>  is based on a driver etc.
>>> 
>>>4. bus stops are numbered routes as on the sign, the fields do not 
>>>  reflect or allow for this, just the name,
>>> 
>>>the standard web edit map reflects points not route lines, google 
>>>  puts in a no. not a line.
>>> 
>>>looking at a map numbers are more important than names and not all 
>>>  stops have names like
>>> 
>>>someone's driveway.
>>> 
>>>  ___

--


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

Re: [OSM-talk] bus stop

[Joseph Eisenberg]

"the only field that shows on the standard web edit map is name"

Are you talking about the editor called "iD" which you open when
clicking "Edit" at the top of the page?

If you would like to request that iD adds support for reference
numbers ("ref") for highway=bus_stop you can do that at
https://github.com/openstreetmap/iD/issues/ - but please search first
to see if this has been discussed or proposed previously, before
creating a new "issue" to request this feature.

You should also check what the wiki page says about bus stops:
https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop
- It looks like "ref=*" is already suggested for the Reference
(number) of the bus stop, so it shouldn't be a problem.

Joseph Eisenberg

On 9/21/19, 80hnhtv4a...@bk.ru <80hnhtv4a...@bk.ru> wrote:
>
> Ok !
>
> it is “hail and ride” but i am in the USA, we do not say it that way, as it
> say’s you put it on the way, road line
>
> i have been using the point, and putting it on the side of the road.
>
> but our signs have numbers on it.
>
> the fields are wrong for our standards, and the only field that shows on
> the standard web edit map is name.
>
> all i know to use is the ID edit.
>
>
>
>
> From: Joseph Eisenberg
> Sent: Friday, September 20, 2019 5:44 PM
> To: OpenStreetMap talk mailing
> list
> Subject: Re: [OSM-talk] bus stop
>
> If a bus stop sign has a number, you can add this to the highway=bus_stop
> node with ref=*
>
> BTW, I wouldn’t call “hail and ride” part of tyr public_transport proposal.
> As the link shows, it’s clearly a separate proposal. But it sounds sensible,
> and
> I agree that if a route has no fixed stops it makes sense to just create a
> route
> relation and only add the first and last stop as highway=bus_stop.
>
> That’s what works here in Indonesia, where most local buses will pick up or
> drop off passengers anywhere along the route.
>
> Joseph
>
> On Sat, Sep 21, 2019 at 3:14 AM Johnparis
> < ok...@johnfreed.com > wrote:
>>If the bus route does not have fixed stops, it is a hail-and-ride route,
>>  not a fixed-stop route. Public Transport v2 takes both possibilities into
>>
>>  account.
>>
>>The route relation should include all the road segments involved, and the
>>  relevant segments should have the role:
>>hail_and_ride
>>
>>See  https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride
>>
>>As to the name vs number, the agreed naming convention is pretty clearly
>>  spelled out in PTv2. Usually something like this:
>>
>>For the route master ... Bus 2: City Hall <-> Library (or you can
>>  use <=> or ↔)
>>For one variant ... Bus 2: City Hall -> Library (or you can use =>
>>  or →)
>>For another variant ... Bus 2: Library -> City Hall
>>
>>etc.
>>
>>I have ridden buses in many US cities (although never a hail-and-ride)
>>  and they fit nicely into this format.
>>
>>The line number itself goes in the ref tag in the route
>>  relation.
>>
>>
>>
>>
>>
>>On Fri, Sep 20, 2019 at 5:03 PM john whelan
>>  < jwhelan0...@gmail.com > wrote:
>>>I'm not sure this is quite the place for this discussion but Europe
>>>also has some bus routes that pick up and drop off on request.  Just
>>>don't map none existent stops.
>>>
>>>Ottawa Canada has fixed stops as do many other locations in North
>>>America.
>>>
>>>I suggest you try to map following the wiki map features.  If
>>>someone is changing your tags then discuss the matter with them as is
>>> the
>>>traditional way to resolve the problem.
>>>
>>>Cheerio John
>>>
>>>On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou---
>>>via talk, < talk@openstreetmap.org >
>>>wrote:
europe vs. united states,

https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform

1. does not match the way we catch the bus in the usa and the fields
  are to strict.

2. is a place where i will stand to catch the bus, sign or no sign
  etc.

3. the map point reflects the area and stops are not set in stone but
  is based on a driver etc.

4. bus stops are numbered routes as on the sign, the fields do not
  reflect or allow for this, just the name,

the standard web edit map reflects points not route lines, google
  puts in a no. not a line.

looking at a map numbers are more important than names and not all
  stops have names like

someone's driveway.

  ___
>

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

Re: [OSM-talk] bus stop

[Joseph Eisenberg]

If a bus stop sign has a number, you can add this to the highway=bus_stop
node with ref=*

BTW, I wouldn’t call “hail and ride” part of tyr public_transport proposal.
As the link shows, it’s clearly a separate proposal. But it sounds
sensible, and I agree that if a route has no fixed stops it makes sense to
just create a route relation and only add the first and last stop as
highway=bus_stop.

That’s what works here in Indonesia, where most local buses will pick up or
drop off passengers anywhere along the route.

Joseph

On Sat, Sep 21, 2019 at 3:14 AM Johnparis  wrote:

> If the bus route does not have fixed stops, it is a hail-and-ride route,
> not a fixed-stop route. Public Transport v2 takes both possibilities into
> account.
>
> The route relation should include all the road segments involved, and the
> relevant segments should have the role:
> hail_and_ride
>
> See https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride
>
> As to the name vs number, the agreed naming convention is pretty clearly
> spelled out in PTv2. Usually something like this:
>
> For the route master ... Bus 2: City Hall <-> Library (or you can use <=>
> or ↔)
> For one variant ... Bus 2: City Hall -> Library (or you can use => or →)
> For another variant ... Bus 2: Library -> City Hall
>
> etc.
>
> I have ridden buses in many US cities (although never a hail-and-ride) and
> they fit nicely into this format.
>
> The line number itself goes in the ref tag in the route relation.
>
>
>
>
>
> On Fri, Sep 20, 2019 at 5:03 PM john whelan  wrote:
>
>> I'm not sure this is quite the place for this discussion but Europe also
>> has some bus routes that pick up and drop off on request.  Just don't map
>> none existent stops.
>>
>> Ottawa Canada has fixed stops as do many other locations in North America.
>>
>> I suggest you try to map following the wiki map features.  If someone is
>> changing your tags then discuss the matter with them as is the traditional
>> way to resolve the problem.
>>
>> Cheerio John
>>
>> On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- via talk, <
>> talk@openstreetmap.org> wrote:
>>
>>> europe vs. united states,
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>>
>>> 1. does not match the way we catch the bus in the usa and the fields are
>>> to strict.
>>>
>>> 2. is a place where i will stand to catch the bus, sign or no sign etc.
>>>
>>> 3. the map point reflects the area and stops are not set in stone but is
>>> based on a driver etc.
>>>
>>> 4. bus stops are numbered routes as on the sign, the fields do not
>>> reflect or allow for this, just the name,
>>>
>>> the standard web edit map reflects points not route lines, google puts
>>> in a no. not a line.
>>>
>>> looking at a map numbers are more important than names and not all stops
>>> have names like
>>>
>>> someone's driveway.
>>>
>>>
>>> ___
>>> 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-cz] Nový kruhový objezd namalovat

[Jan Macura]

Ahoj,

fakt? Po těch letech? :-O
Z katastrální mapy to vidět není. Projektovou dokumentaci k tomu na webu
nenacházím. Chtělo by to vytáhnout kolo a požídit to GPX ;-)
Ale nějak jsem ho tam čmárnul, aby bylo jasný, že tam je...

H.



On Fri, 20 Sep 2019 at 22:00, Václav Kroupar  wrote:

> Já se před nedávnem pokusil namalovat kruhák
> https://www.openstreetmap.org/way/710502150 Měl jsem k tomu GPX. Jestli
> mě někdo sledoval, tak si myslel, že jsem magor a kroužím tam na kole jak
> zmatená včela. Zatím mi za to nikdo nevynadal a dnes jsem si vzpomněl na
> výrobu kruhů, tak jsem jej ještě upravil.
> Máme k tomu novému kruháku podklady?
>
> Vašek
> -- Původní e-mail --
> Od: Michal Poupa 
> Komu: OpenStreetMap Czech Republic 
> Datum: 20. 9. 2019 20:43:09
> Předmět: [talk-cz] Nový kruhový objezd namalovat
>
> bohužel neumám ho namalovat
> Cheb - křížení - Písečná - Osvobození
>
> https://www.openstreetmap.org/way/339707479#map=19/50.06724/12.37129
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Chyby RUIAN, jak na opravy a reklamace

[Jan Macura]

Ahoj,

dík za odkazy. Označil jsem ty prehistorické stránky za zastaralé. Je
otázka, asi hlavně na jejich původní autory, zda už nejsou zralé úplně ke
smazání, aby nemátly případné nové čtenáře. Stránku RÚIAN jsem lehce
aktualizoval.

Zbývají ještě nějaké otázky k zodpovězení? :-)

H.

On Fri, 20 Sep 2019 at 18:11, Vladimír Slávik 
wrote:

> Ahoj, díky, PointInfo je skutečně odpověď na skoro vše!
>
> Pokud jde o wiki,
> https://wiki.openstreetmap.org/wiki/Cs:R%C3%9AIAN#Nalezen.C3.A9_chyby_v_R.C3.9AIAN
> je naprosto zavádějící - neříká nic o PointInfo, ale zato zmiňuje stránku
> https://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby , což je ta
> prehistorie. Mimo to je tam ještě i
> https://wiki.openstreetmap.org/wiki/Cs:RUIAN/nove_budovy .
>
> Díky!
> V.
>
>
> Dne 19.9.2019 v 16:50 Jan Macura napsal(a):
>
> Ahoj,
>
> myslím, že odpověď ad 2 je stáhnout si do JOSM doplněk PointInfo. Návod na
> wiki je "lehce" zastaralý, ale obecně platný:
> https://wiki.openstreetmap.org/wiki/Cs:R%C3%9AIAN#PointInfo_-_dopln.C4.9Bk_JOSM
>
> Jinak můžeš pls dát odkaz na "nějaký seznam na wiki, který je tři roky
> nehnutý"? Hnul bych s ním. Díky.
>
> H.
>
> On Thu, 19 Sep 2019 at 10:22, Vladimír Slávik 
> wrote:
>
>> Ahoj,
>> brodím se jednou vesnicí (Dolní Újezd, Svitavy) kde zřejmě proběhlo
>> nějaké to tracerováníčko od německých přátel a tak. Není to až tak
>> hrozné, ale leccos nesouhlasí s realitou. Tak mám pár dotazů...
>>
>> 1) Jak vlastně určím co je skutečný stav? Mám v JOSM stažené data, mám
>> zapnutou vrstvu z poloha.net. Vidím něco co není budova, vedle zase pro
>> změnu chybí kus budovy, a třetí je křivá. Stav dat OSM odpovídá té
>> vrstvě z poloha.net. Ale když si vezmu to RUIAN ID co máme v OSM a jdu
>> hlásit chybu přes formulář, otevře se mi úplně jiný stavební objekt.
>> Takže je to asi blbě celé na entou. Co s tím?
>>
>> 2) Nejsem schopný dohledat žádné vodítko komu a jak hlásit chyby,
>> ačkoliv tady diskuse v minulosti proběhla. Oficiální formuláře vidím.
>> Pak je ta věc na poloha.net, kde vůbec netuším co to je a co to dělá
>> (návod?) a jak se přidat do toho zřejmě seznamu lidí co můžou hlásit
>> chyby. No a ještě je nějaký seznam na wiki, který je tři roky nehnutý.
>>
>> Kacířská myšlenka - když mají v digitálu tak každý dvanáctý dům, a z
>> toho skoro všechny blbě, tak se nebudu obtěžovat úřední fikcí. To by
>> bylo totiž třeba nahlásit celou vesnici :D Kde je to tragické, smažu
>> ruianové tagy, ať to jde do... pozadí... a upravím správně podle KM a
>> satelitu. Názory? A bonus, jak zamezit náletu klikacích kobylek když se
>> za chvíli objeví v nějakém feedu že se tam dá něco naklikat?
>>
>> (Jo, miluju to celé k sežrání... ale to je asi dostatečně známo.)
>>
>> VS
>>
>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>
> ___
> talk-cz mailing 
> listtalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-bo] Taller comunitario de mapas en Hackmeeting

[Noemi Nahomy]

buenisimo :D

El vie., 20 sept. 2019 a las 17:56, Marco Antonio (<
marcoantoniofr...@gmail.com>) escribió:

> On Thu, 19 Sep 2019 at 15:26, Noemi Nahomy  wrot
> > Este sábado en el hackmeeting tenemos un taller de mapeo comunitario
> quedan todos y todas invitados a participar .
> >
> > Aquí un poco más de información sobre la dinámica.
> > https://osm.bolivia.bo/taller.html
>
> Qué genial, el otro día estaba revisando unos enlaces y encontré algo
> que podría servir al taller...
>
> un mapa de las calles sin nombre en LaPAz-El Alto
> http://qa.poole.ch/?zoom=5=-16.43=-64.50
>
> Abrazos,
>
> Marco Antonio
>
___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [Talk-GB] TfL cycle data published - schema mapping

[Rob Nickerson]

Hi Martin,

I've started to look at this but only got as far as Advanced Stop Lines
(ASL) and Crossings. I've raised issues on the GitHub:
https://github.com/cyclestreets/tflcid-conversion/issues

So far of the new tags I have only reviewed ASL position
(left/right/center). I'm not a fan of the new tag as I think the name is
wrong and (more importantly it doesn't allow for mixed cases such as Right
AND Left). The TfL guide suggests mixed cases are possible. Can you see any
in the data?

Given that we are talking about the position that the cycle lane feeder
joins the ASL "reserviour" then my suggestion is to use:

   - asl:feeder:right = yes
   - asl:feeder:left = yes

Or some such like.

Best regards,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] école primaire

[deuzeffe]

On 19/09/2019 10:27, Christian Quest wrote:

Le mer. 18 sept. 2019 à 21:57,  a écrit : >> En 
toute logique, maternelle, élémentaire et primaire sont trois options

d'amenity=school.


G.



+1


+1 itou.
--
deuzeffe

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

Re: [talk-cz] Nový kruhový objezd namalovat

[Václav Kroupar]

Já se před nedávnem pokusil namalovat kruhák https://www.openstreetmap.org/
way/710502150 Měl jsem k tomu GPX. Jestli mě někdo sledoval, tak si myslel,
že jsem magor a kroužím tam na kole jak zmatená včela. Zatím mi za to nikdo
nevynadal a dnes jsem si vzpomněl na výrobu kruhů, tak jsem jej ještě
upravil.
Máme k tomu novému kruháku podklady?

Vašek
-- Původní e-mail --
Od: Michal Poupa 
Komu: OpenStreetMap Czech Republic 
Datum: 20. 9. 2019 20:43:09
Předmět: [talk-cz] Nový kruhový objezd namalovat
"
bohužel neumám ho namalovat 
Cheb - křížení - Písečná - Osvobození



https://www.openstreetmap.org/way/339707479#map=19/50.06724/12.37129
(https://www.openstreetmap.org/way/339707479#map=19/50.06724/12.37129)  



 ___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Nový kruhový objezd namalovat

[Michal Poupa]

bohužel neumám ho namalovat
Cheb - křížení - Písečná - Osvobození

https://www.openstreetmap.org/way/339707479#map=19/50.06724/12.37129
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] bus stop

[Johnparis]

If the bus route does not have fixed stops, it is a hail-and-ride route,
not a fixed-stop route. Public Transport v2 takes both possibilities into
account.

The route relation should include all the road segments involved, and the
relevant segments should have the role:
hail_and_ride

See https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride

As to the name vs number, the agreed naming convention is pretty clearly
spelled out in PTv2. Usually something like this:

For the route master ... Bus 2: City Hall <-> Library (or you can use <=>
or ↔)
For one variant ... Bus 2: City Hall -> Library (or you can use => or →)
For another variant ... Bus 2: Library -> City Hall

etc.

I have ridden buses in many US cities (although never a hail-and-ride) and
they fit nicely into this format.

The line number itself goes in the ref tag in the route relation.





On Fri, Sep 20, 2019 at 5:03 PM john whelan  wrote:

> I'm not sure this is quite the place for this discussion but Europe also
> has some bus routes that pick up and drop off on request.  Just don't map
> none existent stops.
>
> Ottawa Canada has fixed stops as do many other locations in North America.
>
> I suggest you try to map following the wiki map features.  If someone is
> changing your tags then discuss the matter with them as is the traditional
> way to resolve the problem.
>
> Cheerio John
>
> On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- via talk, <
> talk@openstreetmap.org> wrote:
>
>> europe vs. united states,
>>
>> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>
>> 1. does not match the way we catch the bus in the usa and the fields are
>> to strict.
>>
>> 2. is a place where i will stand to catch the bus, sign or no sign etc.
>>
>> 3. the map point reflects the area and stops are not set in stone but is
>> based on a driver etc.
>>
>> 4. bus stops are numbered routes as on the sign, the fields do not
>> reflect or allow for this, just the name,
>>
>> the standard web edit map reflects points not route lines, google puts in
>> a no. not a line.
>>
>> looking at a map numbers are more important than names and not all stops
>> have names like
>>
>> someone's driveway.
>>
>>
>> ___
>> 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: [talk-cz] Chyby RUIAN, jak na opravy a reklamace

[Vladimír Slávik]

Ahoj, díky, PointInfo je skutečně odpověď na skoro vše!

Pokud jde o wiki, 
https://wiki.openstreetmap.org/wiki/Cs:R%C3%9AIAN#Nalezen.C3.A9_chyby_v_R.C3.9AIAN 
je naprosto zavádějící - neříká nic o PointInfo, ale zato zmiňuje 
stránku https://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby , což je ta 
prehistorie. Mimo to je tam ještě i 
https://wiki.openstreetmap.org/wiki/Cs:RUIAN/nove_budovy .


Díky!
V.


Dne 19.9.2019 v 16:50 Jan Macura napsal(a):

Ahoj,

myslím, že odpověď ad 2 je stáhnout si do JOSM doplněk PointInfo. 
Návod na wiki je "lehce" zastaralý, ale obecně platný: 
https://wiki.openstreetmap.org/wiki/Cs:R%C3%9AIAN#PointInfo_-_dopln.C4.9Bk_JOSM


Jinak můžeš pls dát odkaz na "nějaký seznam na wiki, který je tři roky 
nehnutý"? Hnul bych s ním. Díky.


H.

On Thu, 19 Sep 2019 at 10:22, Vladimír Slávik 
mailto:slavik.vladi...@seznam.cz>> wrote:


Ahoj,
brodím se jednou vesnicí (Dolní Újezd, Svitavy) kde zřejmě proběhlo
nějaké to tracerováníčko od německých přátel a tak. Není to až tak
hrozné, ale leccos nesouhlasí s realitou. Tak mám pár dotazů...

1) Jak vlastně určím co je skutečný stav? Mám v JOSM stažené data,
mám
zapnutou vrstvu z poloha.net . Vidím něco co
není budova, vedle zase pro
změnu chybí kus budovy, a třetí je křivá. Stav dat OSM odpovídá té
vrstvě z poloha.net . Ale když si vezmu to
RUIAN ID co máme v OSM a jdu
hlásit chybu přes formulář, otevře se mi úplně jiný stavební objekt.
Takže je to asi blbě celé na entou. Co s tím?

2) Nejsem schopný dohledat žádné vodítko komu a jak hlásit chyby,
ačkoliv tady diskuse v minulosti proběhla. Oficiální formuláře vidím.
Pak je ta věc na poloha.net , kde vůbec netuším
co to je a co to dělá
(návod?) a jak se přidat do toho zřejmě seznamu lidí co můžou hlásit
chyby. No a ještě je nějaký seznam na wiki, který je tři roky nehnutý.

Kacířská myšlenka - když mají v digitálu tak každý dvanáctý dům, a z
toho skoro všechny blbě, tak se nebudu obtěžovat úřední fikcí. To by
bylo totiž třeba nahlásit celou vesnici :D Kde je to tragické, smažu
ruianové tagy, ať to jde do... pozadí... a upravím správně podle KM a
satelitu. Názory? A bonus, jak zamezit náletu klikacích kobylek
když se
za chvíli objeví v nějakém feedu že se tam dá něco naklikat?

(Jo, miluju to celé k sežrání... ale to je asi dostatečně známo.)

VS


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


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



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

Re: [Talk-it] spiaggia a bordo fiume

[Cascafico Giovanni]

Credo layer=1 dovrebbe bastare. Ma non è detto che mapnik lo consideri.

Il ven 20 set 2019, 17:10 emmexx  ha scritto:

> Non sono per nulla esperto riguardo le modalità di mappatura di fiumi
> con relativi dettagli.
> Volevo inserire una spiaggia ma il rendering finisce per piazzarla in
> mezzo al fiume. Questo perché il riverbank tiene conto delle piene
> (disastrose) e non del livello "normale" del fiume. E la spiaggia in
> questione si trova all'interno del riverbank.
> Che criterio usare per tener conto della prevalenza nel tempo del greto
> del fiume?
> Nell'ipotesi di modificare il riverbank per accomodare la spiaggia, per
> coerenza bisognerebbe anche modificare il resto del riverbank del fiume
> o quanto meno delle zone adiacenti. Solo che mi pare un lavoraccio.
> Ci sono alternative? Ad esempio taggare la spiaggia con un nodo con dei
> tag approppriati (e magari l'indicazione che potrebbe essere soggetta a
> piene)?
>
> grazie
> maxx
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] spiaggia a bordo fiume

[emmexx]

Non sono per nulla esperto riguardo le modalità di mappatura di fiumi
con relativi dettagli.
Volevo inserire una spiaggia ma il rendering finisce per piazzarla in
mezzo al fiume. Questo perché il riverbank tiene conto delle piene
(disastrose) e non del livello "normale" del fiume. E la spiaggia in
questione si trova all'interno del riverbank.
Che criterio usare per tener conto della prevalenza nel tempo del greto
del fiume?
Nell'ipotesi di modificare il riverbank per accomodare la spiaggia, per
coerenza bisognerebbe anche modificare il resto del riverbank del fiume
o quanto meno delle zone adiacenti. Solo che mi pare un lavoraccio.
Ci sono alternative? Ad esempio taggare la spiaggia con un nodo con dei
tag approppriati (e magari l'indicazione che potrebbe essere soggetta a
piene)?

grazie
maxx

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

Re: [OSM-talk] bus stop

[john whelan]

I'm not sure this is quite the place for this discussion but Europe also
has some bus routes that pick up and drop off on request.  Just don't map
none existent stops.

Ottawa Canada has fixed stops as do many other locations in North America.

I suggest you try to map following the wiki map features.  If someone is
changing your tags then discuss the matter with them as is the traditional
way to resolve the problem.

Cheerio John

On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- via talk, <
talk@openstreetmap.org> wrote:

> europe vs. united states,
>
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>
> 1. does not match the way we catch the bus in the usa and the fields are
> to strict.
>
> 2. is a place where i will stand to catch the bus, sign or no sign etc.
>
> 3. the map point reflects the area and stops are not set in stone but is
> based on a driver etc.
>
> 4. bus stops are numbered routes as on the sign, the fields do not reflect
> or allow for this, just the name,
>
> the standard web edit map reflects points not route lines, google puts in
> a no. not a line.
>
> looking at a map numbers are more important than names and not all stops
> have names like
>
> someone's driveway.
>
>
> ___
> 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] bus stop

[80hnhtv4agou--- via talk]

europe vs. united states,
 
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
 
1. does not match the way we catch the bus in the usa and the fields are to 
strict.
 
2. is a place where i will stand to catch the bus, sign or no sign 
etc.
 
3. the map point reflects the area and stops are not set in stone but is 
based on a driver etc.
 
4. bus stops are numbered routes as on the sign, the fields do not reflect 
or allow for this, just the name,
 
the standard web edit map reflects points not route lines, google puts in a 
no. not a line.
 
looking at a map numbers are more important than names and not all stops 
have names like
 
someone's driveway.
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Supervision des relations (itinéraires de randonnées, fleuves...)

[Yves P.]

—
Yves Pratter




> Le 20 sept. 2019 à 16:04, Frédéric Rodrigo  a écrit :
> 
> Osmose analyse déjà les relations de transport en commun pour la continué et 
> les relations de de vélo et de rando pour vérifier les droit access. La 
> continuité des ces dernière pourrait aussi rentrer dans Osmose.
Les rivières et tous (?) les itinéraires de randonnées (VTT, cheval…) ont aussi 
besoin de contrôles.

> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_relation_route_access.py
Ce n’est pas plutôt celui-là qui servirait de modèle ?
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_relation_public_transport.py

En le simplifiant, quoi que pour la rando, il n’y a pas d’arrêt mais des 
panneaux (qui doivent se trouver à proximité de l’itinéraire).


Comme je n’utilise que 10% des capacités d’Osmose, a-t-il un mécanisme 
quelconque pour me « prévenir » dès qu’une relation précise (nom, ID) ou près 
de chez moi est cassée ?

Merci d’avance pour ton éclairage,

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

Re: [OSM-talk-fr] Supervision des relations (itinéraires de randonnées, fleuves...)

[Frédéric Rodrigo]

Osmose analyse déjà les relations de transport en commun pour la 
continué et les relations de de vélo et de rando pour vérifier les droit 
access. La continuité des ces dernière pourrait aussi rentrer dans Osmose.

Si vous le voulez, commencez par ouvrir un ticket sur le Gitlab d'Osmose.

https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_relation_route_access.py


Le 19/09/2019 à 16:30, Cyrille37 OSM via Talk-fr a écrit :

Le 19/09/2019 à 12:21, osm.sanspourr...@spamgourmet.com a écrit :
En interactif, http://ra.osmsurround.org fait ce que tu veux, là j'ai 
juste un peu automatisé. 


Merci pour le lien. Ça tombe bien car l'analyseur de relation en lien 
sur osmose ne fonctionne plus:


http://analyser.openstreetmap.fr/cgi-bin/index.py
HTTP 500 Internal Error

(je transmets à tech@)

Cyrille37.



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




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

Re: [Talk-GB] TfL cycle data published - schema mapping

[Martin - CycleStreets]

https://bikedata.cyclestreets.net/tflcid/conversion/

I'll shortly e-mail again with more detailed commentary on various 
aspects of what is shown, in particular cases where new tags are 
suggested.


As shown on that webpage, most of the data in the CID can be represented by 
OSM tags through a reasonable straight-forward one-to-one mapping. However, 
the following cases are the exceptions.


What are people's thoughts about these suggested new tags?


NEW TAGS PROPOSED

The schema mapping spreadsheet identifies the following cases where the CID 
has data types that are not ordinarily present in OSM:


• ASL position (left/right/center): OSM represents ASLs, but the entry lane 
has not historically been represented. This may be useful for more advanced 
cycle routing (e.g. a right-entry lane may be unrealistic for a child 
cyclist to negotiate). A new tag, asl_position={left|right|center} is 
proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#asl_fdrigh

• Stepped cycle track: Hybrid cycle lanes have long been the source of 
debate in OSM. The new CID data may provide an impetus for starting to 
resolve this. cycleway:track=hybrid is proposed as a backwards-compatible 
addition that elaborates on cycleway=track.

https://bikedata.cyclestreets.net/tflcid/conversion/#clt_stepp

• Mandatory/Advisory Cycle Lane: OSM has no differentiation between 
mandatory (solid white line) and advisory (dashed white line) lane, 
probably because this distinction is rare elsewhere in the world. A new tag 
cycleway:lane={mandatory|advisory} is proposed as a backwards-compatible 
addition that elaborates on cycleway=lane. This would be useful for routing 
engines, who could infer a level of commitment to cyclists at each such 
location.

https://bikedata.cyclestreets.net/tflcid/conversion/#clt_mandat

• Cycle Lane/Track Priority: This refers to whether the cycle lane 
continues across the sideroad, i.e. has priority. This is the standard 
situation abroad, but sadly in the UK it is not common, resulting in 
arduous and reduced-safety stop-start cycling in the case of a shared-use 
pavement. A new tag cycleway:sideroad_continuity=yes is proposed as a 
backwards-compatible addition that elaborates on cycleway={lane|track}.

https://bikedata.cyclestreets.net/tflcid/conversion/#clt_priori

• Cycle parking on/off carriageway: This is not represented in OSM, as it 
does not really matter hugely to cyclists. However, this may be useful in 
pedestrian routing, as pavement cycle parking can be an obstruction. A 
simple new tag carriageway=yes is proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#prk_carr

• Cyclehoop: No such tag currently (though bicycle_parking=bollard is 
similar), but volume of these in the CID makes this worth trying to 
represent. It represents a form of cycle parking that ideally ought to be 
improved through replacement with real stands rather than retrofitting 
poles essentially to facilitate fly-parking (which can then be disruptive 
to the visually-impaired). Accordingly, advocacy groups may well find this 
useful. A new tag bicycle_parking=cyclehoop is proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#prk_hoop

• Wheel-rack cycle parking: This is unfortunately increasingly common in 
this UK. It is not currently represented as a specific cycle parking type 
in OSM. A new tag bicycle_parking=upright_stands is proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#prk_wheel

• Two-tier cycle parking: This is unfortunately becoming more and more 
present in the UK, but bizarrely OSM does not have a representation in 
widespread use currently, with only 6 instances worldwide of 
bicycle_parking=two_tier. It is proposed this be used, which will hopefully 
then galvanise usage beyond London.

https://bikedata.cyclestreets.net/tflcid/conversion/#prk_tier

• Early-release signals: Currently no support for this, but may be useful 
in improving cycle safety in routing. A new tag 
traffic_signals:bicycle_early_release=yes is proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#sig_early

• Side-road entry treatment: This refers to when a continuous pavement (to 
the benefit of pedestrians) is created across a sideroad, which ostensibly 
doubles as a form of traffic calming, which accounts for its presence in 
the CID. A new tag, continuous=yes, is proposed, to be used in combination 
with sidewalk=yes, as the continuity aspect is really what is important 
here rather than it forming a traffic calming hump as such.

https://bikedata.cyclestreets.net/tflcid/conversion/#trf_entry

• Sinusoidal shape of traffic hump/cushion: This is a property rather than 
traffic calming type itself. New tag sinusoidal=yes is proposed.

https://bikedata.cyclestreets.net/tflcid/conversion/#trf_sinuso


PROBLEMATIC TAG REPRESENTATION OF CID ATTRIBUTES

Fields needing significant discussion:

• Cyclists dismount: This is unfortunately a can of worms and may not be 
resolvable 

Re: [OSM-talk] stalking, or stepping on someone's toes (area) ?

[Mateusz Konieczny]

19 Sep 2019, 23:34 by talk@openstreetmap.org:

> also i get messages from the same person with bus stops saying i have done it 
> wrong
>  
> without telling where it is a rule
>
Is (s)he sending private messages or commenting in edit discussions in 
changesets?
In the first case - I would ask for more detail/explanation.
In the second case - can you link this changesets with such comments?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.23.0

[Joseph Eisenberg]

OpenStreetMap Carto (the default stylesheet on the OSM website) has
released version v4.23.0 today.

Changes include:

- The low priority layers were changed to use the same labeling
algorithm as the other layers
This fixes a bug which rendered `parking` icons twice, among others.

- Restored rendering of landcover text labels on points
For some time some features mapped as nodes, like sports_centres,
did not have a label.

- Adjust `aerodrome` initial & final zoom levels
Aerodrome text labels start a little later, but also continue to
higher zoom levels

- Adjusted width of `hedge` & `citywall` up to z20, adjusted hedge color

- Increased `office=` initial zoom level to z18 and moved some
undocument or deprecated values to z19

- Created new layer for `ref` of
`highway=residential/unclassified/track` (#3709)
Changes `ref` to standard halo-radius, oblique font, and same size
as `name` at >z17

- Added fill colors for `wetland=mangrove/saltmarsh/reedbed`
Also adds salt dots pattern for `wetland=saltmarsh`

Once changes are deployed on the openstreetmap.org it will take couple
of days before all tiles show the new rendering.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.22.0...v4.23.0

We welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues, and we
welcome new contributors who might be interested in solving one of the
many open issues.

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

Re: [OSM-talk-fr] Fwd: "Guide" à l'entrée d'une écluse ou d'un pont mobile

[Yves P.]

> Ce ne sont pas des ENC mais des IENC / ECDIS intérieur.
> 
> Et les cartes en France sont disponibles et gratuites :
> https://www.vnf.fr/vnf/services/cartes-electroniques-de-navigation-ecdis/ 
> 
> 
Je connaissais mais sur le moment je n’avais pas compris ta remarque à propos 
de regarder la S-57 (la carte électronique au format S-57 et maintenant S-100).
J’utilisais OpenCPN  qui fonctionne sur Mac/PC/Linux.
Voici un lien vers les cartes disponible gratuitement en ligne :
https://opencpn.org/OpenCPN/info/chartsource.html

Pour info, le pont en question est aux Pays-Bas, mais effectivement il doit y 
avoir la même chose en France 
Je n’arrive pas à charger les cartes là-bas…

En Allemagne, les cartes IENC sont visualisables en surcouche des cartes OSM / 
OpenSeaMap / OpenRiverBoatMap (de Yohan Boniface) :
https://maps.grade.de/?zoom=18=49.48455=8.51075=0BTFFTFFF
 


> Donc tu regardes comme ils ont représenté le rail.
> 
> 
Je ne trouve pas de structures comme celles-ci…
Ce que j’ai pu voir de plus proche, c’est des pontons et des dauphins.

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

Re: [OSM-talk-be] Hechtel_Eksel

[joost schouppe]

Hoi Sus,
Het ligt niet aan de import tool, maar aan de data zelf. In het CRAB zelf
bestaat de postcode 3941 niet meer. Dat is heel bizar, ik vind er ook neits
over terug op het internet. Ik vraag het eens na bij de gemeente zelf.


Op vr 20 sep. 2019 om 11:33 schreef Sus Verhoeven :

> Hooi,
> Ik gebruik nog regelmatig de Crab import tool om nieuwe huizen en adressen
> op te sporen. bv:
>
> http://crab-import.osm.be/import.html?pcode=3940=true=true=true=true=
>
> Eksel had vroeger postcode 3940 en Hechtel 3941, die zijn nu samen onder
> Hechtel-Eksel en enkel postcode 3940 werkt nog in de import tool, al de
> vorige straatnamen van 3941 staan nu onder 3940 maar geven foutmeldingen
> die ik er niet uit krijg. Postcode 3941 wordt niet meer aanvaard in de
> import tool.
>
> De adres validator van Bpost meldt  de 3941 nog  als bestaande postcode.
>
> Wie helpt mij want om dat zelf op te lossen ben ik wat te oud geworden. ;-)
>
> Sus
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

[OSM-talk-be] Hechtel_Eksel

[Sus Verhoeven]

Hooi,
Ik gebruik nog regelmatig de Crab import tool om nieuwe huizen en adressen
op te sporen. bv:
http://crab-import.osm.be/import.html?pcode=3940=true=true=true=true=

Eksel had vroeger postcode 3940 en Hechtel 3941, die zijn nu samen onder
Hechtel-Eksel en enkel postcode 3940 werkt nog in de import tool, al de
vorige straatnamen van 3941 staan nu onder 3940 maar geven foutmeldingen
die ik er niet uit krijg. Postcode 3941 wordt niet meer aanvaard in de
import tool.

De adres validator van Bpost meldt  de 3941 nog  als bestaande postcode.

Wie helpt mij want om dat zelf op te lossen ben ik wat te oud geworden. ;-)

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

Re: [Talk-ee] pöördepiirangud ringristmikel

[tõnis kärdi]

Tundub, et äkki, vist, võib-olla... Äkki keegi saaks üle vaadata, kas nii 
võiks sobida [1]. Üks, mis natuke segadust tekitab, on bussiliinide 
relatsioonid.

parimat,
Tõnis
(@tkardi)

[1] https://www.openstreetmap.org/#map=17/58.38379/26.72675

teisipäev, 17. september 2019 19:59.58 UTC+3 kirjutas JaakL:
>
>
> Ma paneks selge eraldussaarega osa tänavast kahe joonega, nagu pakud välja.
>
> Jaak
>
> > On 17 Sep 2019, at 11:41, tõnis kärdi > 
> wrote:
> > 
> > Hei,
> > 
> > milline peaks olema õige kodeering selliste (vt [1]) pöörangute 
> piiramiseks ringristmike maha- ja pealesõitude kaudu? Pöördepiirang? 
> Looduses on seal Narva maanteel _eraldussaar_ [2], millest 
> liiklusseadustiku järgi üle liikuda ei tohiks. Või oleks korrektne antud 
> juhul Narva mnt üldse kahe, eraldatud sõidusuundadega joonega välja 
> joonistada?
> > 
> > Parimat,
> > Tõnis
> > (a.k.a @tkardi)
> > 
> > [1] 
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=58.38642%2C26.72447%3B58.38599%2C26.72735#map=19/58.38601/26.72676
> > [2] 
> https://xgis.maaamet.ee/maps/XGis?app_id=UU82A_id=at=1=1553=928=11,659452.57568361,6474975.7995605=SHYBR_ALUS01_82A=0,SHYBR_ALUS02_82A=1
> > ___
> > Talk-ee mailing list
> > tal...@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-ee
>
>
> ___
> Talk-ee mailing list
> tal...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ee
>
>___
Talk-ee mailing list
Talk-ee@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ee

[OSM-talk-fr] Josm wiki traduction : "choisir les traces visibles"

[lenny.libre]

Bonjour.

Je voulais traduire la page 
https://josm.openstreetmap.de/wiki/Help/Action/ChooseTrackVisibility, 
mais avant j'aurais voulu comprendre le fonctionnement.


J'ouvre deux de mes traces qui ont toutes les deux des images, JOSM me 
créé pour chacune un calque gpx et un calque marqueur.


Si je "clique+bouton droit" individuellement sur les calques gpx, dans 
le menu contextuel j'ai bien le choix "choisir les traces visibles" puis 
j'ai la fenêtre décrite dans le wiki ; mais je n'arrive pas à 
sélectionner les deux calques en même temps pour obtenir avoir le choix 
et afficher la fenêtre avec les deux calques.


Je ne dois pas avoir les bons éléments ???

Cordialement

Leni


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

Re: [OSM-talk-fr] Fwd: "Guide" à l'entrée d'une écluse ou d'un pont mobile

[osm . sanspourriel]

Yves, merci de t'être planté en disant :

> c'est maritime, pas fluvial
Car il y a une variante pour les voies navigables.

Ce ne sont pas des ENC mais des IENC / ECDIS intérieur.

Et les cartes en France sont disponibles et gratuites :
https://www.vnf.fr/vnf/services/cartes-electroniques-de-navigation-ecdis/

Donc tu regardes comme ils ont représenté le rail.

Jean-Yvon

Le 20/09/2019 à 08:53, Yves P. - yves.prat...@gmail.com a écrit :

Bonjour,

J'ai renvoyé ma question à Claude Marani qui connaît bien le monde 
fluvial.

J'ai regardé du côté de la S57


et j'ai fait  choux blanc.

Suite à ton indice, j'ai trouvé cette bible "Symboles, abréviations et
termesutilisés sur les cartes marines papier
"
Mais rien de probant non plus (normal ? c'est maritime, pas fluvial)

D'après
https://wiki.openstreetmap.org/wiki/Key:seamark:obstruction:category,
seamark:obstruction:category=boom pourrait le faire (en plus
d'autres tags) mais ils disent que c'est une structure flottante.

d’après l’ouvrage ci-dessus, /containment booms (logs)/ = parcs à bois

Ce matin j'ai trouvé Signalisation pour la navigation intérieure

mais je n'ai pas avancé.

On va voir si Claude répond...

--
Yves

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

Re: [talk-au] topic A: the platform itself

[Marc Gemis]

Please allow me to share some experiences of moving to another
platform we had in our community.

In Belgium we moved from the mailing list to Matrix/Riot . Most active
participants in the community made the move, but in the process we
lost some people
Matrix/Riot is good for short questions, but is IMHO very bad for
longer discussions. We have 1 or 2 people that insist on using the
forum, so some things have to be repeated there.

When I look at the neighbouring countries, it notice that it is
difficult to move people from one platform to another. Some stick with
mail, some with the forum, etc.

It will probably be hard to convince people to use a new platform and
they will be the first to pinpoint any weaknesses in the new platform
and either go back to the old platform or "leave" the community.


Just my 2 cents

regards

m

On Fri, Sep 20, 2019 at 9:27 AM Edoardo Neerhut  wrote:
>
> Thanks for bringing this up Herbert.
>
> Similar sentiments
> This has actually been bothering me the last few weeks as I started to 
> realise how much of my day is spent reading through talklists that do not 
> have relevance to me or that I do not have time to respond to. For those of 
> us subscribed to multiple talklists, it becomes a very time consuming and 
> inefficient communication method.
>
> The problem is that you need to read every single one in case you miss 
> something relevant. There are lot of good conversations taking place and I 
> wish I had time to engage more, but I need to be selective.
>
> The platform
> I like the idea of a forum which can be categorised and allow the viewer to 
> make quicker decisions about which topics that would like to engage with. 
> Whether that is the OpenStreetMap forum or something else doesn't bother me. 
> Although the OpenStreetMap forum would make sense so that people can find it 
> easily.
>
> Slack is very convenient, but it is not good for important discussions 
> because the messages get archived unless you sign up to a cost prohibitive 
> plan which our community would not be able to afford.
>
> Setting a standard
> I am not sure any of this can be dictated, but it is a good discussion to 
> have and I would be interested to see how the rest of the community feels. Of 
> course asking here is inherently going to target those already using the 
> talklists, so I will bring this up in other places as well.
>
> Overall I support the interest to discuss this on a more efficient, intuitive 
> platform.
>
> On Fri, 20 Sep 2019 at 09:10, David Wales  wrote:
>>
>> I am a member of some international OSM Slack channels.
>>
>> However, because it requires a whole different app (which I only have space 
>> for on my computer), I only check it monthly at best.
>>
>> On the other hand, I read every talk-au message within a few days of 
>> original posting, because they all arrive in my email inbox on my phone.
>>
>> If the number of talk-au emails reaches overwhelming levels, it might be 
>> necessary to investigate other solutions. However, I don't think we have 
>> reached that point yet.
>>
>> If we ever did explore alternatives, I would prefer an open platform, which 
>> we can host ourselves, rather than Slack or some other proprietary system.
>>
>> Regards,
>> David
>>
>> On 20 September 2019 4:31:44 pm AEST, Frederik Ramm  
>> wrote:
>>>
>>> Hi,
>>>
>>> On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:

 I will post several concerns and information on several issues, but the
 first is this platform itself.
>>>
>>>
>>> You call this platform a "forum" which is ok in the abstract sense, but
>>> note that there is actually an Australia forum in addition to this
>>> Australia mailing list
>>> (https://forum.openstreetmap.org/viewforum.php?id=24). The forum
>>> provides a slightly different user experience but is used less.
>>>
>>> In other countries, people have set up Slack channels or Facebook groups
>>> or even more esoteric channels of communication, in addition of or as a
>>> replacement for mailing lists - browse
>>> https://github.com/osmlab/osm-community-index if you want to get an idea.
>>>
>>> There's no strict rule about where the OSM community should discuss
>>> their issues, however media that requires prior registration with a
>>> third-party entity - like Slack or Facebook - are sometimes frowned upon
>>> as they give control over who can participate to that third party and
>>> might require the participant to agree to wide-ranging exploitation of
>>> their personal data by a commercial entity.
>>>
>>> In Germany where I hail from, the forum and the mailing list are used by
>>> about the same number of (but largely different) people, and since the
>>> total number of contributors is large enough to guarantee lively
>>> discussion on both, that's totally fine. Germany also has mailing lists
>>> for individual states but they are used very little, and even
>>> state-specific issues would often be discussed on the nationwide list to
>>> ensure 

Re: [Talk-lv] osm tikšanās 26. septembrī

[Rihards]

On 16.09.19 19:49, Rihards wrote:
> Nu ko - daudz kas tiek zīmēts, bet nav bijušas īsti iespējas aprunāties
> par jaunumiem.
> Varbūt ir jautājumi vai zināmi cilvēki, kas labprāt sāktu zīmēt karti?
> 
> Mēģināsim biežāk tikties un  apspriest to visu :)
> 
> Tātad, 26. septembrī 18:00 tiekamies Teikas Ezītī:
> https://www.openstreetmap.org/node/5600450921 .

Ja pievienosies, lūdzu piesakies
https://www.eventbrite.com/e/osm-latvia-meetup-tickets-73075427571 :)

> Potenciālas tēmas - droši sūtiet ko citu interesējošu.
> * name-suggestion-index, Wikidata integrācija
> * OSM lietošana Jūrtakas lapā, takas iezīmēšana
> * Nosaukumu standarti (piemēram, "Rimi", "Rimi Alfa" vai "Rimi Hyper";
> "top!", Top" vai vēl kā)
-- 
 Rihards

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

Re: [talk-au] topic A: the platform itself

[Edoardo Neerhut]

Thanks for bringing this up Herbert.

*Similar sentiments*
This has actually been bothering me the last few weeks as I started to
realise how much of my day is spent reading through talklists that do not
have relevance to me or that I do not have time to respond to. For those of
us subscribed to multiple talklists, it becomes a very time consuming and
inefficient communication method.

The problem is that you need to read every single one in case you miss
something relevant. There are lot of good conversations taking place and I
wish I had time to engage more, but I need to be selective.

*The platform*
I like the idea of a forum which can be categorised and allow the viewer to
make quicker decisions about which topics that would like to engage with.
Whether that is the OpenStreetMap forum or something else doesn't bother
me. Although the OpenStreetMap forum would make sense so that people can
find it easily.

Slack is very convenient, but it is not good for important discussions
because the messages get archived unless you sign up to a cost prohibitive
plan which our community would not be able to afford.

*Setting a standard*
I am not sure any of this can be dictated, but it is a good discussion to
have and I would be interested to see how the rest of the community feels.
Of course asking here is inherently going to target those already using the
talklists, so I will bring this up in other places as well.

Overall I support the interest to discuss this on a more efficient,
intuitive platform.

On Fri, 20 Sep 2019 at 09:10, David Wales  wrote:

> I am a member of some international OSM Slack channels.
>
> However, because it requires a whole different app (which I only have
> space for on my computer), I only check it monthly at best.
>
> On the other hand, I read every talk-au message within a few days of
> original posting, because they all arrive in my email inbox on my phone.
>
> If the number of talk-au emails reaches overwhelming levels, it might be
> necessary to investigate other solutions. However, I don't think we have
> reached that point yet.
>
> If we ever did explore alternatives, I would prefer an open platform,
> which we can host ourselves, rather than Slack or some other proprietary
> system.
>
> Regards,
> David
>
> On 20 September 2019 4:31:44 pm AEST, Frederik Ramm 
> wrote:
>>
>> Hi,
>>
>> On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:
>>
>>> I will post several concerns and information on several issues, but the
>>> first is this platform itself.
>>>
>>
>> You call this platform a "forum" which is ok in the abstract sense, but
>> note that there is actually an Australia forum in addition to this
>> Australia mailing list
>> (https://forum.openstreetmap.org/viewforum.php?id=24). The forum
>> provides a slightly different user experience but is used less.
>>
>> In other countries, people have set up Slack channels or Facebook groups
>> or even more esoteric channels of communication, in addition of or as a
>> replacement for mailing lists - browse
>> https://github.com/osmlab/osm-community-index if you want to get an idea.
>>
>> There's no strict rule about where the OSM community should discuss
>> their issues, however media that requires prior registration with a
>> third-party entity - like Slack or Facebook - are sometimes frowned upon
>> as they give control over who can participate to that third party and
>> might require the participant to agree to wide-ranging exploitation of
>> their personal data by a commercial entity.
>>
>> In Germany where I hail from, the forum and the mailing list are used by
>> about the same number of (but largely different) people, and since the
>> total number of contributors is large enough to guarantee lively
>> discussion on both, that's totally fine. Germany also has mailing lists
>> for individual states but they are used very little, and even
>> state-specific issues would often be discussed on the nationwide list to
>> ensure they get enough attention.
>>
>> Speaking very generally, OSM has achieved the success it has with a
>> "just do it" attitude: Instead of saying, 15 years ago, "BEFORE we
>> start, let's come up with a good data scheme and a feature catalogue",
>> people said "let's just start and then fix things as we go along".
>>
>> My recommendation would be to just stat discussing whatever needs
>> discussing on the talk-au mailing list and branch out as the need
>> arises. If something is worth discussing then a non-ideal UI should not
>> be the blocker, and if it is, then maybe the issue is not so important.
>>
>> Bye
>> Frederik
>>
>> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] topic A: the platform itself

[David Wales]

I am a member of some international OSM Slack channels.

However, because it requires a whole different app (which I only have space for 
on my computer), I only check it monthly at best.

On the other hand, I read every talk-au message within a few days of original 
posting, because they all arrive in my email inbox on my phone.

If the number of talk-au emails reaches overwhelming levels, it might be 
necessary to investigate other solutions. However, I don't think we have 
reached that point yet.

If we ever did explore alternatives, I would prefer an open platform, which we 
can host ourselves, rather than Slack or some other proprietary system.

Regards,
David

On 20 September 2019 4:31:44 pm AEST, Frederik Ramm  wrote:
>Hi,
>
>On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:
>> I will post several concerns and information on several issues, but
>the
>> first is this platform itself. 
>
>You call this platform a "forum" which is ok in the abstract sense, but
>note that there is actually an Australia forum in addition to this
>Australia mailing list
>(https://forum.openstreetmap.org/viewforum.php?id=24). The forum
>provides a slightly different user experience but is used less.
>
>In other countries, people have set up Slack channels or Facebook
>groups
>or even more esoteric channels of communication, in addition of or as a
>replacement for mailing lists - browse
>https://github.com/osmlab/osm-community-index if you want to get an
>idea.
>
>There's no strict rule about where the OSM community should discuss
>their issues, however media that requires prior registration with a
>third-party entity - like Slack or Facebook - are sometimes frowned
>upon
>as they give control over who can participate to that third party and
>might require the participant to agree to wide-ranging exploitation of
>their personal data by a commercial entity.
>
>In Germany where I hail from, the forum and the mailing list are used
>by
>about the same number of (but largely different) people, and since the
>total number of contributors is large enough to guarantee lively
>discussion on both, that's totally fine. Germany also has mailing lists
>for individual states but they are used very little, and even
>state-specific issues would often be discussed on the nationwide list
>to
>ensure they get enough attention.
>
>Speaking very generally, OSM has achieved the success it has with a
>"just do it" attitude: Instead of saying, 15 years ago, "BEFORE we
>start, let's come up with a good data scheme and a feature catalogue",
>people said "let's just start and then fix things as we go along".
>
>My recommendation would be to just stat discussing whatever needs
>discussing on the talk-au mailing list and branch out as the need
>arises. If something is worth discussing then a non-ideal UI should not
>be the blocker, and if it is, then maybe the issue is not so important.
>
>Bye
>Frederik
>
>-- 
>Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
>E008°23'33"
>
>___
>Talk-au mailing list
>Talk-au@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-GB] September East Midlands meeting change of venue to Sheffield

[SK53]

Dear All,

As I will not be back from State of the Map in time for our scheduled
meeting and the people who are likely to be there are not from Nottingham,
we have changed the venue to the Devonshire Cat, Sheffield at 19:30 on
Tuesday.

I hope to update the wiki sometime today, but John Stanworth & John Baker
(rovastar) are co-ordinating the gathering.

This is also good time to give advance notice that our next Derby meeting
in November will be at the Brunswick near Derby Station.

Both changes reflect a real extension in range for our attendees, in large
measure due to John Stanworth's enthusiasm.

Cheers,

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

Re: [OSM-talk-fr] Fwd: "Guide" à l'entrée d'une écluse ou d'un pont mobile

[Yves P.]

Bonjour,

J'ai renvoyé ma question à Claude Marani qui connaît bien le monde  fluvial.

> J'ai regardé du côté de
> la S57
> 
> et j'ai fait  choux blanc.
>
Suite à ton indice, j'ai trouvé cette bible "Symboles, abréviations et
termesutilisés sur les cartes marines papier
"
Mais rien de probant non plus (normal ? c'est maritime, pas fluvial)

> D'après
> https://wiki.openstreetmap.org/wiki/Key:seamark:obstruction:category,
> seamark:obstruction:category=boom pourrait le faire (en plus d'autres tags)
> mais ils disent que c'est une structure flottante.
>
d’après l’ouvrage ci-dessus, *containment booms (logs)* = parcs à bois

Ce matin j'ai trouvé Signalisation pour la navigation intérieure

mais je n'ai pas avancé.

On va voir si Claude répond...

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

Re: [OSM-talk] lines, drawing.

[Marc Gemis]

The screenshots you attached in the private mail, are those of the
iD-editor. The wiki page describes the "default" map shown on e.g.
www.openstreetmap.org.


regards

m.

On Thu, Sep 19, 2019 at 4:32 PM <80hnhtv4a...@bk.ru> wrote:
>
> The drawing do not match the current drawing on the web edit map.
>
> the colors on the edit map do not match the info page.
>
> the rail platform on the web edit page is gone.
>
> the rail platform on the page is gone.
>
> https://wiki.openstreetmap.org/wiki/File:Rendering-highway_railway_platform_area.png
>
> From: Marc Gemis
> Sent: Thursday, September 19, 2019 8:59 AM
> To: 80hnhtv4a...@bk.ru
> Cc: osm
> Subject: Re: [OSM-talk] lines, drawing.
>
> Maybe a stupid question, but what has to be fixed on that page? Can
> you provide a bit more detail?
>
>
> On Thu, Sep 19, 2019 at 3:47 PM 80hnhtv4agou--- via talk
>  wrote:
> >
> > can someone fix this page ?
> >
> > https://wiki.openstreetmap.org/wiki/LinesTab
> > ___
> > 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-au] topic A: the platform itself

[Frederik Ramm]

Hi,

On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:
> I will post several concerns and information on several issues, but the
> first is this platform itself. 

You call this platform a "forum" which is ok in the abstract sense, but
note that there is actually an Australia forum in addition to this
Australia mailing list
(https://forum.openstreetmap.org/viewforum.php?id=24). The forum
provides a slightly different user experience but is used less.

In other countries, people have set up Slack channels or Facebook groups
or even more esoteric channels of communication, in addition of or as a
replacement for mailing lists - browse
https://github.com/osmlab/osm-community-index if you want to get an idea.

There's no strict rule about where the OSM community should discuss
their issues, however media that requires prior registration with a
third-party entity - like Slack or Facebook - are sometimes frowned upon
as they give control over who can participate to that third party and
might require the participant to agree to wide-ranging exploitation of
their personal data by a commercial entity.

In Germany where I hail from, the forum and the mailing list are used by
about the same number of (but largely different) people, and since the
total number of contributors is large enough to guarantee lively
discussion on both, that's totally fine. Germany also has mailing lists
for individual states but they are used very little, and even
state-specific issues would often be discussed on the nationwide list to
ensure they get enough attention.

Speaking very generally, OSM has achieved the success it has with a
"just do it" attitude: Instead of saying, 15 years ago, "BEFORE we
start, let's come up with a good data scheme and a feature catalogue",
people said "let's just start and then fix things as we go along".

My recommendation would be to just stat discussing whatever needs
discussing on the talk-au mailing list and branch out as the need
arises. If something is worth discussing then a non-ideal UI should not
be the blocker, and if it is, then maybe the issue is not so important.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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