Re: [Tagging] Roundtrip and closed loop in relations

[Francesco Ansanelli]

Dear Volker,

I saw that someone went ahead and changed the wiki again:

Use roundtrip=yes to indicate that start and end of a route are at the same
location.

I think this new definition matches your idea of roundtrip and it's fine
for both definitions.
My last offer is to abandon the closed_loop tag in favour of:

roundtrip:type=linear|circular

Do you agree?
Francesco


Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:

> Please revert the roundtrip wiki change, but let's put any other
> wiki-changes on halt for a moment.
> What we need to do is to find out how the roundtrip tag is being used (the
> wiki is suposed to document the actual use, not what the use should be) and
> in particular if there is a more-than sporadic use of roundtrip=yes|no for
> anything else than loop=yes|no.
> It's difficult to get reliable quantitative results, but:
> A fast overpass turbo wizard query
> "type:relation and route=bicycle and roundtrip=yes in
> Italy|France|England|USA|Bayern"
> resulted in
> Italy: 58 lines with at best a handful of them not closed loops
> France: 358 lines with maybe 10 non-loops
> England:  25 lines, all loops.
> USA:  29, about 6 non-loops
> Bavaria 213, did not find any non-loops
> For me this is a strong indication that the large majority of all cycle
> route relations in these countries that have a roundrip=yes are in fact
> loops and that that this is the de-facto use of the tag.
> I think this is a strong case against any change.
>
> Taginfo points in the same direction
> 12665 roundtrip=no
> 21774 roundtrip=yes
> 42 closed_loop=yes
> no closed_loop=no
>
> Volker
>
>
>
>
>
>
> On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
> wrote:
>
>> In my opinion the options are:
>>
>> - deprecate roundtrip in favour of 2 tags with a generally agreed naming
>> convention (best at this point)
>> - keep roundtrip and closed_loop with the wiki definition I did change
>> (relations must be updated accordingly)
>>
>> I read many of you asked a revert, I just want to point out that is not a
>> resolution because tag is currently messed up
>>
>> Il ven 20 dic 2019, 15:08 Steve Doerr  ha
>> scritto:
>>
>>> On 19/12/2019 22:48, Phake Nick wrote:
>>>
>>> Merriam Webster and some other resources you have quoted are dictionary
>>> for American English, not the variant of English used by OSM. Posts by
>>> original author of the topic on the wiki talk page have explained the
>>> meaning of the term in British English.
>>>
>>>
>>> The OED definitions read as follows:
>>>
>>> Originally U.S.
>>>  A. n.
>>>  1.
>>>  a. A journey to a place and back again, along the same route; (also) a
>>> journey to one or more places and back again which does not cover the same
>>> ground twice, a circular tour or trip.
>>>
>>>  b. Baseball. A home run. Cf. round-tripper n. 2.
>>>
>>>  2. In extended use and figurative, esp. (Mining and Oil Industry) an
>>> act of withdrawing and replacing a drill pipe.
>>>
>>>  3. Stock Market (originally U.S.). The action or an instance of buying
>>> and selling the same stock, commodity, etc., often simultaneously. Cf.
>>> round turn n. 4.
>>>
>>>  B. adj. (attributive). Chiefly North American.
>>>
>>>  1. Of or relating to a round trip (in various senses). Cf. return n.
>>> Compounds 1.
>>>
>>>  2. That makes or has made a round trip (literal and figurative).
>>>
>>>  C. adv. Chiefly North American.
>>>
>>>   As a round trip; by travelling to a place and back again.
>>>
>>> Note the frequent references to 'U.S.' and 'North American'. It's an
>>> American phrase, though now widely adopted in the UK.
>>>
>>> --
>>> Steve
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What access key for cargo bike ?

[Jan Michel]

I agree that "cargo_bike" is a nice word for this kind of vehicle.
However, I would like to point out that the term 'bike' is not very
common in OSM, mostly due to the ambiguity between 'bicycle' and
'motorcycle'. To prevent this, we should think about building a tag
around the terms bicycle and cargo, e.g. cargo_bicycle, or
bicycle:cargo.

On 21.12.19 01:30, Joseph Eisenberg wrote:

+1 for "cargo_bike", including cargo tricycles and pedalled electric
bicycles and trikes.



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

Re: [Tagging] Roundtrip and closed loop in relations

[Warin]

On 21/12/19 19:49, Francesco Ansanelli wrote:

Dear Volker,

I saw that someone went ahead and changed the wiki again:

Use roundtrip=yes to indicate that start and end of a route are at the 
same location.


I think this new definition matches your idea of roundtrip and it's 
fine for both definitions.

My last offer is to abandon the closed_loop tag in favour of:

roundtrip:type=linear|circular

Do you agree?


No.

"Type" means nothing. Perhaps roundtrip:route=*???

As for the values .. you will need to define them!

'My' local bus route starts off with ways that are used both directions 
.. and then separates into a loop where the segments are only used in 
one direction.


I could imaging routes that have several loops  used in one direction 
and then ways that are used in both directions .. arrr there is another  
route that does that ...


So what values will there be to cover complex cases???



Francesco


Il ven 20 dic 2019, 22:45 Volker Schmidt > ha scritto:


Please revert the roundtrip wiki change, but let's put any other
wiki-changes on halt for a moment.
What we need to do is to find out how the roundtrip tag is being
used (the wiki is suposed to document the actual use, not what the
use should be) and in particular if there is a more-than sporadic
use of roundtrip=yes|no for anything else than loop=yes|no.
It's difficult to get reliable quantitative results, but:
A fast overpass turbo wizard query
"type:relation and route=bicycle and roundtrip=yes in
Italy|France|England|USA|Bayern"
resulted in
Italy: 58 lines with at best a handful of them not closed loops
France: 358 lines with maybe 10 non-loops
England:  25 lines, all loops.
USA:  29, about 6 non-loops
Bavaria 213, did not find any non-loops
For me this is a strong indication that the large majority of all
cycle route relations in these countries that have a roundrip=yes
are in fact loops and that that this is the de-facto use of the tag.
I think this is a strong case against any change.

Taginfo points in the same direction
12665 roundtrip=no
21774 roundtrip=yes
42 closed_loop=yes
no closed_loop=no

Volker







On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli
mailto:franci...@gmail.com>> wrote:

In my opinion the options are:

- deprecate roundtrip in favour of 2 tags with a generally
agreed naming convention (best at this point)
- keep roundtrip and closed_loop with the wiki definition I
did change (relations must be updated accordingly)

I read many of you asked a revert, I just want to point out
that is not a resolution because tag is currently messed up

Il ven 20 dic 2019, 15:08 Steve Doerr mailto:doerr.step...@gmail.com>> ha scritto:

On 19/12/2019 22:48, Phake Nick wrote:

Merriam Webster and some other resources you have quoted
are dictionary for American English, not the variant of
English used by OSM. Posts by original author of the
topic on the wiki talk page have explained the meaning of
the term in British English.


The OED definitions read as follows:

Originally U.S.
 A. n.
 1.
 a. A journey to a place and back again, along the
same route; (also) a journey to one or more places and
back again which does not cover the same ground twice,
a circular tour or trip.

 b. Baseball. A home run. Cf. round-tripper n. 2.

 2. In extended use and figurative, esp. (Mining and
Oil Industry) an act of withdrawing and replacing a
drill pipe.

 3. Stock Market (originally U.S.). The action or an
instance of buying and selling the same stock,
commodity, etc., often simultaneously. Cf. round turn
n. 4.

 B. adj. (attributive). Chiefly North American.

 1. Of or relating to a round trip (in various
senses). Cf. return n. Compounds 1.

 2. That makes or has made a round trip (literal and
figurative).

 C. adv. Chiefly North American.

  As a round trip; by travelling to a place and back
again.

Note the frequent references to 'U.S.' and 'North
American'. It's an American phrase, though now widely
adopted in the UK.

-- 
Steve

___




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

Re: [Tagging] [Talk-us] Trunk VS primary,

[Mateusz Konieczny]

21 Dec 2019, 01:44 by ba...@ursamundi.org:

>
>
> On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny <> matkoni...@tutanota.com> 
> > wrote:
>
>>
>> 20 Dec 2019, 01:25 by >> ba...@ursamundi.org>> :
>>
>>> So, for example, in the US, instead of motorway, trunk, primary, secondary, 
>>> tertiary, perhaps something more like freeway, expressway, 
>>> major/minor_principal (just having this would fix a *lot* of problems with 
>>> Texas and Missouri and their extensive secondary systems), 
>>> major/minor_collector...the US just has a way more complex view of how 
>>> highways work.  
>>>
>>> Or at least some more serious consideration given to the proposal at >>> 
>>> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS>>>  (but perhaps 
>>> with "other principal arterials" as primary and a new "highway=quartinary".
>>>
>> Fitting thing like road classification
>> into UK system is irritating at times.
>>
>> But idea of each country with separate tags
>> for roads is simply a bad idea.
>>
>
> Could you expand on this?  Being able to speak each country's highway lingua 
> franca would make it a lot easier for OSM to become the Rosetta Stone of maps 
> simply from ease of classification.
>
I am consider it unlikely that it would make
anything easier.

Current solution is not ideal butfollowing each local and incompatible 
classification scheme instead seems to not be better.

I am 100% OK with tagging official road 
status somehow - US expressway,
US highway route, Polish droga wojewódzka,
Polish droga gminna and so on.

But as a new (maybe already existing)
tag.
But do not expect 1:1 mapping to highway tag value.
>  
>
>>
>> This info is probably worth recording,
>> but legal status should go into a separate tag.
>>
>
> Legal status of roads in the US isn't quite as clearcut as it is in the UK, 
> where the highway=* tag is literally equal to that country's legal 
> classification, plus private roads with significant public passage and/or 
> reach.  Off the top of my head we have 1 country, 2 states, 34 tribes, 77 
> counties and 597 towns, plus MacQuarie Group Australia running the turnpikes 
> and the Boy Scouts of America, Phillips 66, ConocoPhillips, or some 
> combination of the three, and potentially scores more private entities, 
> operating extensive networks of publicly accessible roads and highways in 
> Oklahoma.  And I generally consider myself lucky I have it > this>  
> straightforward in the US.
>
> Texas likely has similar situations but throw in the fact that they have 7 
> different state highway systems before you get into at least 3 more 
> (regional? state? private? unclear...) competing turnpike networks, sometimes 
> running side by side on the same right of way (consider TX 121 with the 
> George Bush Turnpike operated by the North Texas Transportation Agency 
> running down the median).
>
> Simply starting with the HFCS and expanding from that (particularly on the 
> freeway/expressway distinction, and having more levels between secondary and 
> unclassified) would be a fantastic boon to dealing with this mess in a more 
> concise fashion as it changes highway=* tagging from almost entirely 
> subjective to subjective but within a limited range.  Establish wiki pages 
> describing how each region works and let the consumers sort it out from there.
>
> At an absolute minimum, we really need to establish values lower than 
> tertiary yet above unclassified, and we definitely do need to make the 
> freeway/expressway distinction.
>
I consider any plan that would add new
highway values to be unlikely to succeed.

Consider introducing new tags instead.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Mateusz Konieczny]

21 Dec 2019, 01:09 by joseph.eisenb...@gmail.com:

> Above it was said that the highway=trunk vs highway=primary
> distinction is mostly for routing applications. But allowing a proper
> rendering is also a main goal of the road tagging system.
>
Yes, during my work on road display in
OSM Carto I really wished for consistent
use of highway=trunk as
"The most important roads on national
level, but not motorways".

I encountered some definitions of highway=trunk
describing this type of user,
but it is sadly not universally followed.

I think it would be desirable to use it this way,
rather than for tagging of "high performance
roads below motorway quality".
> While it's true that road class is useful for routing when there are
> two alterate routes, a main reason to tag highways with a certain
> class is to be able to render maps properly at different zoom levels.
>
> When you are making a high-scale, low-zoom-level map of a large area
> (say, the whole State of Alaska, all of England, or all of Australia),
> you will want to only render highway=motorway + highway=trunk, because
> showing all highway=primary would lead to rendering many smaller roads
> which are not reasonable to show at that scale in most places.
>
+1___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What access key for cargo bike ?

[Mateusz Konieczny]

20 Dec 2019, 14:07 by florimond.berth...@gmail.com:

> Well, I don’t know what the french law say, but that’s not an issue,
> we don’t tag the law ;)
> I’m really here just to know the english word.
> In France we also say "vélo cargo" (cargo bike), so I’d go for
> cargo_bike if none disapprove
>
cargo_bicycle seems clearly better for
consistency and clear differentiation from
motorcycles.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[Francesco Ansanelli]

And with existing tags how you describe it?

Il sab 21 dic 2019, 10:28 Warin <61sundow...@gmail.com> ha scritto:

> On 21/12/19 19:49, Francesco Ansanelli wrote:
>
> Dear Volker,
>
> I saw that someone went ahead and changed the wiki again:
>
> Use roundtrip=yes to indicate that start and end of a route are at the
> same location.
>
> I think this new definition matches your idea of roundtrip and it's fine
> for both definitions.
> My last offer is to abandon the closed_loop tag in favour of:
>
> roundtrip:type=linear|circular
>
> Do you agree?
>
>
> No.
>
> "Type" means nothing. Perhaps roundtrip:route=*???
>
> As for the values .. you will need to define them!
>
> 'My' local bus route starts off with ways that are used both directions ..
> and then separates into a loop where the segments are only used in one
> direction.
>
> I could imaging routes that have several loops  used in one direction and
> then ways that are used in both directions .. arrr there is another  route
> that does that ...
>
> So what values will there be to cover complex cases???
>
>
> Francesco
>
>
> Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:
>
>> Please revert the roundtrip wiki change, but let's put any other
>> wiki-changes on halt for a moment.
>> What we need to do is to find out how the roundtrip tag is being used
>> (the wiki is suposed to document the actual use, not what the use should
>> be) and in particular if there is a more-than sporadic use of
>> roundtrip=yes|no for anything else than loop=yes|no.
>> It's difficult to get reliable quantitative results, but:
>> A fast overpass turbo wizard query
>> "type:relation and route=bicycle and roundtrip=yes in
>> Italy|France|England|USA|Bayern"
>> resulted in
>> Italy: 58 lines with at best a handful of them not closed loops
>> France: 358 lines with maybe 10 non-loops
>> England:  25 lines, all loops.
>> USA:  29, about 6 non-loops
>> Bavaria 213, did not find any non-loops
>> For me this is a strong indication that the large majority of all cycle
>> route relations in these countries that have a roundrip=yes are in fact
>> loops and that that this is the de-facto use of the tag.
>> I think this is a strong case against any change.
>>
>> Taginfo points in the same direction
>> 12665 roundtrip=no
>> 21774 roundtrip=yes
>> 42 closed_loop=yes
>> no closed_loop=no
>>
>> Volker
>>
>>
>>
>>
>>
>>
>> On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
>> wrote:
>>
>>> In my opinion the options are:
>>>
>>> - deprecate roundtrip in favour of 2 tags with a generally agreed naming
>>> convention (best at this point)
>>> - keep roundtrip and closed_loop with the wiki definition I did change
>>> (relations must be updated accordingly)
>>>
>>> I read many of you asked a revert, I just want to point out that is not
>>> a resolution because tag is currently messed up
>>>
>>> Il ven 20 dic 2019, 15:08 Steve Doerr  ha
>>> scritto:
>>>
 On 19/12/2019 22:48, Phake Nick wrote:

 Merriam Webster and some other resources you have quoted are dictionary
 for American English, not the variant of English used by OSM. Posts by
 original author of the topic on the wiki talk page have explained the
 meaning of the term in British English.


 The OED definitions read as follows:

 Originally U.S.
  A. n.
  1.
  a. A journey to a place and back again, along the same route; (also) a
 journey to one or more places and back again which does not cover the same
 ground twice, a circular tour or trip.

  b. Baseball. A home run. Cf. round-tripper n. 2.

  2. In extended use and figurative, esp. (Mining and Oil Industry) an
 act of withdrawing and replacing a drill pipe.

  3. Stock Market (originally U.S.). The action or an instance of buying
 and selling the same stock, commodity, etc., often simultaneously. Cf.
 round turn n. 4.

  B. adj. (attributive). Chiefly North American.

  1. Of or relating to a round trip (in various senses). Cf. return n.
 Compounds 1.

  2. That makes or has made a round trip (literal and figurative).

  C. adv. Chiefly North American.

   As a round trip; by travelling to a place and back again.

 Note the frequent references to 'U.S.' and 'North American'. It's an
 American phrase, though now widely adopted in the UK.

 --
 Steve
 ___
>>>
>>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary

[Wolfgang Zenker]

* Joseph Eisenberg  wrote:
> Above it was said that the highway=trunk vs highway=primary
> distinction is mostly for routing applications. But allowing a proper
> rendering is also a main goal of the road tagging system.

> While it's true that road class is useful for routing when there are
> two alterate routes, a main reason to tag highways with a certain
> class is to be able to render maps properly at different zoom levels.

> When you are making a high-scale, low-zoom-level map of a large area
> (say, the whole State of Alaska, all of England, or all of Australia),
> you will want to only render highway=motorway + highway=trunk, because
> showing all highway=primary would lead to rendering many smaller roads
> which are not reasonable to show at that scale in most places.

> [..]

What makes the problem of road classification so hard is that we want it
to do different things at once. For rendering we have on the one hand
the requirement that we want to show all the "relevant" roads for a
given zoom level, on the other hand, as a map user I would expect that
a road shown as e.g. trunk in Massachusets would be quite similar in
characteristics to a road shown as trunk in Montana.

I suggest to keep the road classification consistent at least within
a country and try to solve the problem of roads in low-zoom maps at
the rendering level, by modifying the list of displayed road classes
until a target density of displayed roads is reached. That might
become easier to do when we move to vector tiles.

Wolfgang
( lyx@osm )

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

Re: [Tagging] Roundtrip and closed loop in relations

[Volker Schmidt]

This is missing the point.
I only want to point out that apparently roundtrip=yes without any
additional tagging is being used as meaning "this route is a loop" and
"round-trip=no" as meaning it's an A-to-b route. This should remain valid.
And let us consider how to cater for other cases.
Any retagging would mean a lot of manual work. I cannot see any simple way
(leaving out AI) to determine whether any given route is a loop or
something else.


On Sat, 21 Dec 2019, 11:27 Francesco Ansanelli,  wrote:

> And with existing tags how you describe it?
>
> Il sab 21 dic 2019, 10:28 Warin <61sundow...@gmail.com> ha scritto:
>
>> On 21/12/19 19:49, Francesco Ansanelli wrote:
>>
>> Dear Volker,
>>
>> I saw that someone went ahead and changed the wiki again:
>>
>> Use roundtrip=yes to indicate that start and end of a route are at the
>> same location.
>>
>> I think this new definition matches your idea of roundtrip and it's fine
>> for both definitions.
>> My last offer is to abandon the closed_loop tag in favour of:
>>
>> roundtrip:type=linear|circular
>>
>> Do you agree?
>>
>>
>> No.
>>
>> "Type" means nothing. Perhaps roundtrip:route=*???
>>
>> As for the values .. you will need to define them!
>>
>> 'My' local bus route starts off with ways that are used both directions
>> .. and then separates into a loop where the segments are only used in one
>> direction.
>>
>> I could imaging routes that have several loops  used in one direction and
>> then ways that are used in both directions .. arrr there is another  route
>> that does that ...
>>
>> So what values will there be to cover complex cases???
>>
>>
>> Francesco
>>
>>
>> Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:
>>
>>> Please revert the roundtrip wiki change, but let's put any other
>>> wiki-changes on halt for a moment.
>>> What we need to do is to find out how the roundtrip tag is being used
>>> (the wiki is suposed to document the actual use, not what the use should
>>> be) and in particular if there is a more-than sporadic use of
>>> roundtrip=yes|no for anything else than loop=yes|no.
>>> It's difficult to get reliable quantitative results, but:
>>> A fast overpass turbo wizard query
>>> "type:relation and route=bicycle and roundtrip=yes in
>>> Italy|France|England|USA|Bayern"
>>> resulted in
>>> Italy: 58 lines with at best a handful of them not closed loops
>>> France: 358 lines with maybe 10 non-loops
>>> England:  25 lines, all loops.
>>> USA:  29, about 6 non-loops
>>> Bavaria 213, did not find any non-loops
>>> For me this is a strong indication that the large majority of all cycle
>>> route relations in these countries that have a roundrip=yes are in fact
>>> loops and that that this is the de-facto use of the tag.
>>> I think this is a strong case against any change.
>>>
>>> Taginfo points in the same direction
>>> 12665 roundtrip=no
>>> 21774 roundtrip=yes
>>> 42 closed_loop=yes
>>> no closed_loop=no
>>>
>>> Volker
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
>>> wrote:
>>>
 In my opinion the options are:

 - deprecate roundtrip in favour of 2 tags with a generally agreed
 naming convention (best at this point)
 - keep roundtrip and closed_loop with the wiki definition I did change
 (relations must be updated accordingly)

 I read many of you asked a revert, I just want to point out that is not
 a resolution because tag is currently messed up

 Il ven 20 dic 2019, 15:08 Steve Doerr  ha
 scritto:

> On 19/12/2019 22:48, Phake Nick wrote:
>
> Merriam Webster and some other resources you have quoted are
> dictionary for American English, not the variant of English used by OSM.
> Posts by original author of the topic on the wiki talk page have explained
> the meaning of the term in British English.
>
>
> The OED definitions read as follows:
>
> Originally U.S.
>  A. n.
>  1.
>  a. A journey to a place and back again, along the same route; (also)
> a journey to one or more places and back again which does not cover the
> same ground twice, a circular tour or trip.
>
>  b. Baseball. A home run. Cf. round-tripper n. 2.
>
>  2. In extended use and figurative, esp. (Mining and Oil Industry) an
> act of withdrawing and replacing a drill pipe.
>
>  3. Stock Market (originally U.S.). The action or an instance of
> buying and selling the same stock, commodity, etc., often simultaneously.
> Cf. round turn n. 4.
>
>  B. adj. (attributive). Chiefly North American.
>
>  1. Of or relating to a round trip (in various senses). Cf. return n.
> Compounds 1.
>
>  2. That makes or has made a round trip (literal and figurative).
>
>  C. adv. Chiefly North American.
>
>   As a round trip; by travelling to a place and back again.
>
> Note the frequent references to 'U.S.' and 'North American'. It's an
> American phrase, tho

Re: [Tagging] [Talk-us] Trunk VS primary

[Joseph Eisenberg]

> I would expect that a road shown as e.g. trunk in Massachusets would be quite 
> similar in
characteristics to a road shown as trunk in Montana.

Characteristics always change strongly between rural areas and urban
areas: in most places a highway=primary will have several lanes in a
large city, but in a rural area it will usually be only one lane each
way. In a city the speed limit will often been 40 kmh (25 mph), but in
a rural area it might be 80 kmh (55 mph) on the same class of road.
Similarly, near-wilderness areas like Alaska can be expected to have
different road characteristics than more densely-populated rural
areas.

> try to solve the problem of roads in low-zoom maps at the rendering level, by 
> modifying the list of displayed road classes until a target density of 
> displayed roads is reached

That's the right solution for maps that are designed for a particular
region or country, but it is not feasible for automatically generated
maps with global coverage (like the 4 styles shown on
openstreetmap.org). The big problem is what happens at the borders
between areas: it could be quite confusing if the color or zoom level
of a certain highway tag suddenly changed at the border between Spain
and France for example.

- Joseph Eisenberg

On 12/21/19, Wolfgang Zenker  wrote:
> * Joseph Eisenberg  wrote:
>> Above it was said that the highway=trunk vs highway=primary
>> distinction is mostly for routing applications. But allowing a proper
>> rendering is also a main goal of the road tagging system.
>
>> While it's true that road class is useful for routing when there are
>> two alterate routes, a main reason to tag highways with a certain
>> class is to be able to render maps properly at different zoom levels.
>
>> When you are making a high-scale, low-zoom-level map of a large area
>> (say, the whole State of Alaska, all of England, or all of Australia),
>> you will want to only render highway=motorway + highway=trunk, because
>> showing all highway=primary would lead to rendering many smaller roads
>> which are not reasonable to show at that scale in most places.
>
>> [..]
>
> What makes the problem of road classification so hard is that we want it
> to do different things at once. For rendering we have on the one hand
> the requirement that we want to show all the "relevant" roads for a
> given zoom level, on the other hand, as a map user I would expect that
> a road shown as e.g. trunk in Massachusets would be quite similar in
> characteristics to a road shown as trunk in Montana.
>
> I suggest to keep the road classification consistent at least within
> a country and try to solve the problem of roads in low-zoom maps at
> the rendering level, by modifying the list of displayed road classes
> until a target density of displayed roads is reached. That might
> become easier to do when we move to vector tiles.
>
> Wolfgang
> ( lyx@osm )
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] [Talk-us] Trunk VS primary

[Mateusz Konieczny]

21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
> I suggest to keep the road classification consistent at least within
> a country and try to solve the problem of roads in low-zoom maps at
> the rendering level, by modifying the list of displayed road classes
> until a target density of displayed roads is reached. That might
> become easier to do when we move to vector tiles.
>
Seems not doable with OSM data - this
would require far more road classes
than we use.

lane and surface data is also almost
certainly not helpful here even with full
coverage

And it would result in weird transitions
between countries.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary

[Andy Townsend]

On 21/12/2019 11:40, Mateusz Konieczny wrote:


21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:

I suggest to keep the road classification consistent at least within
a country and try to solve the problem of roads in low-zoom maps at
the rendering level, by modifying the list of displayed road classes
until a target density of displayed roads is reached. That might
become easier to do when we move to vector tiles.

Seems not doable with OSM data - this
would require far more road classes
than we use.

lane and surface data is also almost
certainly not helpful here even with full
coverage

Renderers can certainly use tags other than "highway" when deciding what 
road class to render things as (I do that in a couple places in maps for 
UK/IE but not for trunk/primary, but if I was creating maps for the US I 
suspect I'd definitely try and use other tags along with the highway tag 
to influence road class at motorway/trunk/primary as well).


Specifically, if a tertiary is particular narrow it gets rendered as 
unclassified, and if an unclassified or residential is a gravel track it 
gets rendered as a track with public access. Specifically:


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L928

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L421

The "invented highway tags" set there are then used by

https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT/blob/master/roads.mss

Best Regards,

Andy


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

Re: [Tagging] [Talk-us] Trunk VS primary

[Mateusz Konieczny]

21 Dec 2019, 12:56 by ajt1...@gmail.com:

> On 21/12/2019 11:40, Mateusz Konieczny  wrote:
>
>>
>> 21 Dec 2019, 12:00 by >> wolfg...@lyxys.ka.sub.org>> :
>>
>>> I suggest to keep the road classification consistent at  least 
>>> within
>>> a country and try to solve the problem of roads in low-zoom  maps at
>>> the rendering level, by modifying the list of displayed  road 
>>> classes
>>> until a target density of displayed roads is reached. That  might
>>> become easier to do when we move to vector tiles.
>>>
>> Seems not doable with OSM data - this
>> would require far more road classes
>> than we use.
>>
>> lane and surface data is also almost
>> certainly not helpful here even with full
>> coverage
>>
>
> Renderers can certainly use tags other than "highway" when  deciding what 
> road class to render things as
>
>
I know, that is why I mentioned 
lane and surface tags
>
> Specifically, if a tertiary is particular narrow it gets rendered  as 
> unclassified, and if an unclassified or residential is a gravel  track it 
> gets rendered as a track with public access.
>
>
OSM Carto is using access tag in
this way. It works well for zoomed in
view but gets more problematic for
country level views or global ones.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Jarek Piórkowski]

On Fri, 20 Dec 2019 at 22:30, Paul Johnson  wrote:
>> > What I'm saying is highway=bundesstraße could be acceptable, but 
>> > straße=bundestraße wouldn't be.  Mostly so way type objects with highway=* 
>> >  are still potentially routable.
>>
>> How do you propose these "potential routable" fallback routers to
>> handle highway=Bürgersteig (a sidewalk) vs highway=Fahrradstraße (a
>> local street where bicycles have priority)?
>
> Same way I already consider highway=motorway:  Tag for access.  Assumptions 
> are OKish, but at least in north america, motorway and trunk (aka freeways 
> and expressways) are ambiguous for non-motorized modes.  Most states allow 
> nonmotorized modes on motorways, but 15 don't, and about 30 allow it when not 
> otherwise posted, so foot=no, bicycle=no is *NOT* a safe assumption for 
> freeways.  Especailly the farther west you go; for example, in British 
> Columbia, Washington and Oregon (where I grew up), a motorway is probably 
> safer for cyclists than your average city street with bicycle lanes (no 
> oncoming traffic, parking on the pavement is not permitted at all, roughly 
> 4.5m wide hard shoulders, 80-110km/h speed limits but that's 3m from anybody 
> walking or cycling, versus no sidewalks, 1.5-2m wide bicycle lanes and 60-90 
> km/h surface street speed limits, with both the speed limits and bicycle 
> lanes being next to never respected in the northwest).

Tagging exceptions is fine, but tagging every highway=footway aka
highway=chodnik with vehicle=no is going to be a bit silly I would
think.

You might know, but just to mention: the British Columbia comment is
not accurate in most of Lower Mainland (that one bit of Upper Levels
Highway notwithstanding). So if we are adding access tags to
distinguish urban vs rural realities, what's wrong with
highway=motorway as the base tag?

>> How will a router know
>> which highways can be used by trucks, buses, pedestrians, other than
>> with a giant lookup table?
>
> highway=* is a good start, which is why I'm in favor of "lower is better" 
> with the exiting system.

I'm sorry, I'm missing some context to understand this (or was this
meant to be "existing"?). To be more explicit, how would a router know
not to send trucks on highway=Fahrradstraße?

>> And if you do have a giant lookup table,
>> wouldn't be easier to have it in editors rather than in every single
>> data consumer?
>
> Not really.  UK concepts are entirely foreign to all but roadgeeks in North 
> America, and, judging by AARoads and NE2's history, not even then.

Sorry, I meant "editors" as in software, not as in humans. You specify
the road as "Oregon freeway", and JOSM/rapiD/whatever editor add tags
highway=motorway + bicycle=yes.

I'm totally onboard with additional tags to refine for local
realities. But keep the one tag already understood by all data
consumers.

Thanks,
--Jarek

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

Re: [Tagging] Roundtrip and closed loop in relations

[Francesco Ansanelli]

Il sab 21 dic 2019, 12:33 Volker Schmidt  ha scritto:

> This is missing the point.
> I only want to point out that apparently roundtrip=yes without any
> additional tagging is being used as meaning "this route is a loop" and
> "round-trip=no" as meaning it's an A-to-b route. This should remain valid.
>

It is.
Well, with latest wiki version:
Roundtrip=yes is A to B (to C?) to A.
Roundtrip=no is A to B (to C?)

And let us consider how to cater for other cases.
>

Sure .. but if you're open to the change..

Any retagging would mean a lot of manual work. I cannot see any simple way
> (leaving out AI) to determine whether any given route is a loop or
> something else.
>


I feel this is the right approach...
We can define how to fix existing routes as soon as we find an eligible
approach


>
> On Sat, 21 Dec 2019, 11:27 Francesco Ansanelli, 
> wrote:
>
>> And with existing tags how you describe it?
>>
>> Il sab 21 dic 2019, 10:28 Warin <61sundow...@gmail.com> ha scritto:
>>
>>> On 21/12/19 19:49, Francesco Ansanelli wrote:
>>>
>>> Dear Volker,
>>>
>>> I saw that someone went ahead and changed the wiki again:
>>>
>>> Use roundtrip=yes to indicate that start and end of a route are at the
>>> same location.
>>>
>>> I think this new definition matches your idea of roundtrip and it's fine
>>> for both definitions.
>>> My last offer is to abandon the closed_loop tag in favour of:
>>>
>>> roundtrip:type=linear|circular
>>>
>>> Do you agree?
>>>
>>>
>>> No.
>>>
>>> "Type" means nothing. Perhaps roundtrip:route=*???
>>>
>>> As for the values .. you will need to define them!
>>>
>>> 'My' local bus route starts off with ways that are used both directions
>>> .. and then separates into a loop where the segments are only used in one
>>> direction.
>>>
>>> I could imaging routes that have several loops  used in one direction
>>> and then ways that are used in both directions .. arrr there is another
>>> route that does that ...
>>>
>>> So what values will there be to cover complex cases???
>>>
>>>
>>> Francesco
>>>
>>>
>>> Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:
>>>
 Please revert the roundtrip wiki change, but let's put any other
 wiki-changes on halt for a moment.
 What we need to do is to find out how the roundtrip tag is being used
 (the wiki is suposed to document the actual use, not what the use should
 be) and in particular if there is a more-than sporadic use of
 roundtrip=yes|no for anything else than loop=yes|no.
 It's difficult to get reliable quantitative results, but:
 A fast overpass turbo wizard query
 "type:relation and route=bicycle and roundtrip=yes in
 Italy|France|England|USA|Bayern"
 resulted in
 Italy: 58 lines with at best a handful of them not closed loops
 France: 358 lines with maybe 10 non-loops
 England:  25 lines, all loops.
 USA:  29, about 6 non-loops
 Bavaria 213, did not find any non-loops
 For me this is a strong indication that the large majority of all cycle
 route relations in these countries that have a roundrip=yes are in fact
 loops and that that this is the de-facto use of the tag.
 I think this is a strong case against any change.

 Taginfo points in the same direction
 12665 roundtrip=no
 21774 roundtrip=yes
 42 closed_loop=yes
 no closed_loop=no

 Volker






 On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
 wrote:

> In my opinion the options are:
>
> - deprecate roundtrip in favour of 2 tags with a generally agreed
> naming convention (best at this point)
> - keep roundtrip and closed_loop with the wiki definition I did change
> (relations must be updated accordingly)
>
> I read many of you asked a revert, I just want to point out that is
> not a resolution because tag is currently messed up
>
> Il ven 20 dic 2019, 15:08 Steve Doerr  ha
> scritto:
>
>> On 19/12/2019 22:48, Phake Nick wrote:
>>
>> Merriam Webster and some other resources you have quoted are
>> dictionary for American English, not the variant of English used by OSM.
>> Posts by original author of the topic on the wiki talk page have 
>> explained
>> the meaning of the term in British English.
>>
>>
>> The OED definitions read as follows:
>>
>> Originally U.S.
>>  A. n.
>>  1.
>>  a. A journey to a place and back again, along the same route; (also)
>> a journey to one or more places and back again which does not cover the
>> same ground twice, a circular tour or trip.
>>
>>  b. Baseball. A home run. Cf. round-tripper n. 2.
>>
>>  2. In extended use and figurative, esp. (Mining and Oil Industry) an
>> act of withdrawing and replacing a drill pipe.
>>
>>  3. Stock Market (originally U.S.). The action or an instance of
>> buying and selling the same stock, commodity, etc., often simultaneously.
>> Cf.

Re: [Tagging] What access key for cargo bike ?

[Volker Schmidt]

Please keep in mind that in the EU the border between bicycle and (small)
motorcycle is between Pedelec (a bicycle) and S-Pedelec (a small
motorcycle). And cargo-bikes come in both flavours here.
As said before, access tags in Osm are describing the legal access
situation. BUT I'm pointing this out without having an idea how to solve
the issue.

On Sat, 21 Dec 2019, 11:24 Mateusz Konieczny, 
wrote:

>
>
> 20 Dec 2019, 14:07 by florimond.berth...@gmail.com:
>
> Well, I don’t know what the french law say, but that’s not an issue,
> we don’t tag the law ;)
> I’m really here just to know the english word.
> In France we also say "vélo cargo" (cargo bike), so I’d go for
> cargo_bike if none disapprove
>
> cargo_bicycle seems clearly better for
> consistency and clear differentiation from
> motorcycles.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[Phake Nick]

Reminder 1: There are loops within bus route doesn't mean the route is a
circular or round trip route.
Reminder 2: The roundtrip=* key is designed to use in combination with
hiking routes or bicycle routes. A hiking/bicyle route that goes A→B→A
which come back with the same start point with exact same alignment as the
other direction doesn't really mean anything so I don't think a special
value would be needed for such case. As for bus routes, whether or not it
goes back along same road doesn't really mean anything either.

在 2019年12月21日週六 17:28，Warin <61sundow...@gmail.com> 寫道：

> On 21/12/19 19:49, Francesco Ansanelli wrote:
>
> Dear Volker,
>
> I saw that someone went ahead and changed the wiki again:
>
> Use roundtrip=yes to indicate that start and end of a route are at the
> same location.
>
> I think this new definition matches your idea of roundtrip and it's fine
> for both definitions.
> My last offer is to abandon the closed_loop tag in favour of:
>
> roundtrip:type=linear|circular
>
> Do you agree?
>
>
> No.
>
> "Type" means nothing. Perhaps roundtrip:route=*???
>
> As for the values .. you will need to define them!
>
> 'My' local bus route starts off with ways that are used both directions ..
> and then separates into a loop where the segments are only used in one
> direction.
>
> I could imaging routes that have several loops  used in one direction and
> then ways that are used in both directions .. arrr there is another  route
> that does that ...
>
> So what values will there be to cover complex cases???
>
>
> Francesco
>
>
> Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:
>
>> Please revert the roundtrip wiki change, but let's put any other
>> wiki-changes on halt for a moment.
>> What we need to do is to find out how the roundtrip tag is being used
>> (the wiki is suposed to document the actual use, not what the use should
>> be) and in particular if there is a more-than sporadic use of
>> roundtrip=yes|no for anything else than loop=yes|no.
>> It's difficult to get reliable quantitative results, but:
>> A fast overpass turbo wizard query
>> "type:relation and route=bicycle and roundtrip=yes in
>> Italy|France|England|USA|Bayern"
>> resulted in
>> Italy: 58 lines with at best a handful of them not closed loops
>> France: 358 lines with maybe 10 non-loops
>> England:  25 lines, all loops.
>> USA:  29, about 6 non-loops
>> Bavaria 213, did not find any non-loops
>> For me this is a strong indication that the large majority of all cycle
>> route relations in these countries that have a roundrip=yes are in fact
>> loops and that that this is the de-facto use of the tag.
>> I think this is a strong case against any change.
>>
>> Taginfo points in the same direction
>> 12665 roundtrip=no
>> 21774 roundtrip=yes
>> 42 closed_loop=yes
>> no closed_loop=no
>>
>> Volker
>>
>>
>>
>>
>>
>>
>> On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
>> wrote:
>>
>>> In my opinion the options are:
>>>
>>> - deprecate roundtrip in favour of 2 tags with a generally agreed naming
>>> convention (best at this point)
>>> - keep roundtrip and closed_loop with the wiki definition I did change
>>> (relations must be updated accordingly)
>>>
>>> I read many of you asked a revert, I just want to point out that is not
>>> a resolution because tag is currently messed up
>>>
>>> Il ven 20 dic 2019, 15:08 Steve Doerr  ha
>>> scritto:
>>>
 On 19/12/2019 22:48, Phake Nick wrote:

 Merriam Webster and some other resources you have quoted are dictionary
 for American English, not the variant of English used by OSM. Posts by
 original author of the topic on the wiki talk page have explained the
 meaning of the term in British English.


 The OED definitions read as follows:

 Originally U.S.
  A. n.
  1.
  a. A journey to a place and back again, along the same route; (also) a
 journey to one or more places and back again which does not cover the same
 ground twice, a circular tour or trip.

  b. Baseball. A home run. Cf. round-tripper n. 2.

  2. In extended use and figurative, esp. (Mining and Oil Industry) an
 act of withdrawing and replacing a drill pipe.

  3. Stock Market (originally U.S.). The action or an instance of buying
 and selling the same stock, commodity, etc., often simultaneously. Cf.
 round turn n. 4.

  B. adj. (attributive). Chiefly North American.

  1. Of or relating to a round trip (in various senses). Cf. return n.
 Compounds 1.

  2. That makes or has made a round trip (literal and figurative).

  C. adv. Chiefly North American.

   As a round trip; by travelling to a place and back again.

 Note the frequent references to 'U.S.' and 'North American'. It's an
 American phrase, though now widely adopted in the UK.

 --
 Steve
 ___
>>>
>>>
>
> __

Re: [Tagging] Roundtrip and closed loop in relations

[Volker Schmidt]

On Sat, 21 Dec 2019 at 14:43, Phake Nick  wrote:

> Reminder 1: There are loops within bus route doesn't mean the route is a
> circular or round trip route.
>
Fully agreed. That's why I am saying we need to alok at this with a bit of
calm. There plenty of diferent route toplogies

Reminder 2: The roundtrip=* key is designed to use in combination with
> hiking routes or bicycle routes. A hiking/bicyle route that goes A→B→A
> which come back with the same start point with exact same alignment as the
> other direction doesn't really mean anything so I don't think a special
> value would be needed for such case. As for bus routes, whether or not it
> goes back along same road doesn't really mean anything either.
>

Fully agreed.
We never looked at this and tagged different route types (bus and bicycle
for example) independently folowuìing essentially different topological
approaches.
Bus routes are (always?) tagged as unidirectional routes. The same bus line
that connects A <> B is represented by two bus routes A > B and B > A.
But, by tradition, or whatever reason, a topologically equivalent bicycle
route A <> B is represented by a single, mostly bidirectional route A <> B,
where the few pieces where the A > B route differs from the B > A route
(for example for roundabouts or cycle paths on both sides of a road) are
handled by route segments whose ways are tagged with role=forward|backward
within the relation.

By the way, these loop segments are, at least within the route network in
Italy, tagged with role=forward|backward differently from the definition in
the cycle routes wiki page

(" *Relation role*: Cycle routes sometimes have different paths depending
on the direction you are travelling. In this case, ways in the relation
should have a role of *forward* or *backward* as described in
Relation:route#Members
. The direction
is rendered on the cycle map (example

).")
in the sense that loop sections that are to be followed in the A > B
direction are marked with role=forward  and loop sections that are to be
ridden in the B > A direction are marked with role=backward.
But that is a different story that needs sorting out as well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[marc marc]

I always thought that routrip=yes was an alternative when there is no
start and end point to enter in from=* to=* key.
Otherwise circular routes with a known start/end point can enter
as from=A via=B to=A.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary

[Wolfgang Zenker]

* Mateusz Konieczny 
> 21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
>> I suggest to keep the road classification consistent at least within
>> a country and try to solve the problem of roads in low-zoom maps at
>> the rendering level, by modifying the list of displayed road classes
>> until a target density of displayed roads is reached. That might
>> become easier to do when we move to vector tiles.

> Seems not doable with OSM data - this
> would require far more road classes
> than we use.

Why would we need more road classes for that? This would only be an
issue if the difference between two "adjacent" classes would be so big
that you would jump from "almost none" to "to many to display" in one
step.

> lane and surface data is also almost
> certainly not helpful here even with full
> coverage

> And it would result in weird transitions
> between countries.

Only if road density changes rapidly at the border, and then we would
just depict the weird transition that exists in reality.

I think it might be possible to upgrade the "minimum zoom level to
display" on a way if there are no already displayed ways in an area,
maybe only if it connects to an already displayed way (recursive).
That way we would boost the minimum zoom level of e.g.
https://www.openstreetmap.org/way/196509120 to zoom-level 11 or maybe
even 9, even with it being just a low quality dirt track going near an
obscure archaeological site in the middle of nowhere.

Wolfgang
( lyx@osm )

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

Re: [Tagging] [Talk-us] Trunk VS primary

[Mateusz Konieczny]

21 Dec 2019, 15:29 by wolfg...@lyxys.ka.sub.org:

> * Mateusz Konieczny 
>
>> 21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
>>
>>> I suggest to keep the road classification consistent at least within
>>> a country and try to solve the problem of roads in low-zoom maps at
>>> the rendering level, by modifying the list of displayed road classes
>>> until a target density of displayed roads is reached. That might
>>> become easier to do when we move to vector tiles.
>>>
>> Seems not doable with OSM data - this
>> would require far more road classes
>> than we use.
>>
>
> Why would we need more road classes for that? This would only be an
> issue if the difference between two "adjacent" classes would be so big
> that you would jump from "almost none" to "to many to display" in one
> step.
>
Exactly.

There are many places where motorway 
and trunk is not enough
(as trunks are not used for roads
forming core network but for expressways).

Adding also primary roads pushes it into 
unacceptable many roads forming blobs.

>> lane and surface data is also almost
>> certainly not helpful here even with full
>> coverage
>>
>> And it would result in weird transitions
>> between countries.
>>
>
> Only if road density changes rapidly at the border, and then we would
> just depict the weird transition that exists in reality.
>
In case of using regions not matching countries
you will still have weird transitions on borders of regions.
> I think it might be possible to upgrade the "minimum zoom level to
> display" on a way if there are no already displayed ways in an area,
> maybe only if it connects to an already displayed way (recursive).
> That way we would boost the minimum zoom level of e.g.
> https://www.openstreetmap.org/way/196509120 to zoom-level 11 or maybe
> even 9, even with it being just a low quality dirt track going near an
> obscure archaeological site in the middle of nowhere.
>
I had some ideas, none managed to deal
with "weird borders somewhere".___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Sat, Dec 21, 2019 at 6:37 AM Jarek Piórkowski 
wrote:

> On Fri, 20 Dec 2019 at 22:30, Paul Johnson  wrote:
> >> > What I'm saying is highway=bundesstraße could be acceptable, but
> straße=bundestraße wouldn't be.  Mostly so way type objects with highway=*
> are still potentially routable.
> >>
> >> How do you propose these "potential routable" fallback routers to
> >> handle highway=Bürgersteig (a sidewalk) vs highway=Fahrradstraße (a
> >> local street where bicycles have priority)?
> >
> > Same way I already consider highway=motorway:  Tag for access.
> Assumptions are OKish, but at least in north america, motorway and trunk
> (aka freeways and expressways) are ambiguous for non-motorized modes.  Most
> states allow nonmotorized modes on motorways, but 15 don't, and about 30
> allow it when not otherwise posted, so foot=no, bicycle=no is *NOT* a safe
> assumption for freeways.  Especailly the farther west you go; for example,
> in British Columbia, Washington and Oregon (where I grew up), a motorway is
> probably safer for cyclists than your average city street with bicycle
> lanes (no oncoming traffic, parking on the pavement is not permitted at
> all, roughly 4.5m wide hard shoulders, 80-110km/h speed limits but that's
> 3m from anybody walking or cycling, versus no sidewalks, 1.5-2m wide
> bicycle lanes and 60-90 km/h surface street speed limits, with both the
> speed limits and bicycle lanes being next to never respected in the
> northwest).
>
> Tagging exceptions is fine, but tagging every highway=footway aka
> highway=chodnik with vehicle=no is going to be a bit silly I would
> think.
>
> You might know, but just to mention: the British Columbia comment is
> not accurate in most of Lower Mainland (that one bit of Upper Levels
> Highway notwithstanding). So if we are adding access tags to
> distinguish urban vs rural realities, what's wrong with
> highway=motorway as the base tag?
>
> >> How will a router know
> >> which highways can be used by trucks, buses, pedestrians, other than
> >> with a giant lookup table?
> >
> > highway=* is a good start, which is why I'm in favor of "lower is
> better" with the exiting system.
>
> I'm sorry, I'm missing some context to understand this (or was this
> meant to be "existing"?). To be more explicit, how would a router know
> not to send trucks on highway=Fahrradstraße?
>
> >> And if you do have a giant lookup table,
> >> wouldn't be easier to have it in editors rather than in every single
> >> data consumer?
> >
> > Not really.  UK concepts are entirely foreign to all but roadgeeks in
> North America, and, judging by AARoads and NE2's history, not even then.
>
> Sorry, I meant "editors" as in software, not as in humans. You specify
> the road as "Oregon freeway", and JOSM/rapiD/whatever editor add tags
> highway=motorway + bicycle=yes.
>

Under state law, except where bicycle=no, it appears Oregon is actually
foot=yes, bicycle=designated on all state-operated highways these days,
with the entire state highway system (or it's bicycle bypasses instead
where present) being part of that state's RCN.  Not that this says anything
about actual ridability in Oregon, since most state highways outside of
urban centers do not have bicycle lanes or hard shoulders except for
freeways.  I'm glad that Osmand has "allow motorways" as an option in
bicycle mode, as, if you have the endurance required inherent (emergency
stopping only, even for cyclists, despite potentially extreme distances
between exits; barring physical barriers or mechanical issues preventing
it, you must keep moving) as, especially in western Oregon and the Portland
area specifically, the freeway is probably your best, if not only, bet.

I'd be down for something similar to that.  I'm really not in favor of
using trunk for anything other than expressways though, mostly because
there's an upward creep problem in US tagging already and expressways are a
special case for driving anyway.

Would also be nice if there was an *actually easy* scheme for handling
presets that deal with complicated rules to explicitly tag regional
situations.  Like, for example, you're editing a highway in Oklahoma that
has minspeed=* set, bicycle=no and foot=no automatically get added.  If
that way is part of a bicycle route relation, then it gets
bicycle=designated added automatically, instead.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[Warin]

On 21/12/19 21:25, Francesco Ansanelli wrote:

And with existing tags how you describe it?


I don't.


Il sab 21 dic 2019, 10:28 Warin <61sundow...@gmail.com 
> ha scritto:


On 21/12/19 19:49, Francesco Ansanelli wrote:

Dear Volker,

I saw that someone went ahead and changed the wiki again:

Use roundtrip=yes to indicate that start and end of a route are
at the same location.

I think this new definition matches your idea of roundtrip and
it's fine for both definitions.
My last offer is to abandon the closed_loop tag in favour of:

roundtrip:type=linear|circular

Do you agree?


No.

"Type" means nothing. Perhaps roundtrip:route=*???

As for the values .. you will need to define them!

'My' local bus route starts off with ways that are used both
directions .. and then separates into a loop where the segments
are only used in one direction.

I could imaging routes that have several loops  used in one
direction and then ways that are used in both directions .. arrr
there is another  route that does that ...

So what values will there be to cover complex cases???



Francesco


Il ven 20 dic 2019, 22:45 Volker Schmidt mailto:vosc...@gmail.com>> ha scritto:

Please revert the roundtrip wiki change, but let's put any
other wiki-changes on halt for a moment.
What we need to do is to find out how the roundtrip tag is
being used (the wiki is suposed to document the actual use,
not what the use should be) and in particular if there is a
more-than sporadic use of roundtrip=yes|no for anything else
than loop=yes|no.
It's difficult to get reliable quantitative results, but:
A fast overpass turbo wizard query
"type:relation and route=bicycle and roundtrip=yes in
Italy|France|England|USA|Bayern"
resulted in
Italy: 58 lines with at best a handful of them not closed loops
France: 358 lines with maybe 10 non-loops
England:  25 lines, all loops.
USA:  29, about 6 non-loops
Bavaria 213, did not find any non-loops
For me this is a strong indication that the large majority of
all cycle route relations in these countries that have a
roundrip=yes are in fact loops and that that this is the
de-facto use of the tag.
I think this is a strong case against any change.

Taginfo points in the same direction
12665 roundtrip=no
21774 roundtrip=yes
42 closed_loop=yes
no closed_loop=no

Volker







On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli
mailto:franci...@gmail.com>> wrote:

In my opinion the options are:

- deprecate roundtrip in favour of 2 tags with a
generally agreed naming convention (best at this point)
- keep roundtrip and closed_loop with the wiki definition
I did change (relations must be updated accordingly)

I read many of you asked a revert, I just want to point
out that is not a resolution because tag is currently
messed up

Il ven 20 dic 2019, 15:08 Steve Doerr
mailto:doerr.step...@gmail.com>> ha scritto:

On 19/12/2019 22:48, Phake Nick wrote:

Merriam Webster and some other resources you have
quoted are dictionary for American English, not the
variant of English used by OSM. Posts by original
author of the topic on the wiki talk page have
explained the meaning of the term in British English.


The OED definitions read as follows:

Originally U.S.
 A. n.
 1.
 a. A journey to a place and back again, along
the same route; (also) a journey to one or more
places and back again which does not cover the
same ground twice, a circular tour or trip.

 b. Baseball. A home run. Cf. round-tripper n. 2.

 2. In extended use and figurative, esp. (Mining
and Oil Industry) an act of withdrawing and
replacing a drill pipe.

 3. Stock Market (originally U.S.). The action or
an instance of buying and selling the same stock,
commodity, etc., often simultaneously. Cf. round
turn n. 4.

 B. adj. (attributive). Chiefly North American.

 1. Of or relating to a round trip (in various
senses). Cf. return n. Compounds 1.

 2. That makes or has made a round trip (literal
and figurative).

 C. adv. Chiefly North Amer

Re: [Tagging] What access key for cargo bike ?

[Martin Koppenhoefer]

sent from a phone

> On 20. Dec 2019, at 14:09, Florimond Berthoux  
> wrote:
> 
> Well, I don’t know what the french law say, but that’s not an issue,
> we don’t tag the law ;)
> I’m really here just to know the english word.
> In France we also say "vélo cargo" (cargo bike), so I’d go for
> cargo_bike if none disapprove.


I would be interested in the implications, if there is cargo_bicycle=yes, does 
it imply I can go there with a regular bicycle as well? In case it is 
bicycle=yes, is it valid for cargo bicycles as well? And the same for no-cases. 
If there is no legal definition that distinguishes cargo bicycles from other 
bicycles, who decides what a cargo bicycle is?
Or is it maybe a question of courtesy not to park a regular bike on a cargo 
bike stall? In this case it wouldn’t be an access tag IMHO.


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Martin Koppenhoefer]

sent from a phone

> On 21. Dec 2019, at 01:10, Joseph Eisenberg  
> wrote:
> 
> Unfortunately, the road classification system in parts of Continental
> Europe was different, so mappers in some major countries, including
> Germany and France, chose to use highway=trunk as synonym for
> "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> major roads tagged as highway=primary.


actually not, the motorroad tag was introduced by the Germans (AFAIK) to 
express a typical access situation on many trunks but also some primaries 
(motorway like access), so that trunk (motorway like physical construction) and 
access could be tagged orthogonally. There are also some trunks that permit 
slower traffic in Germany.

Cheers Martin 


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

Re: [Tagging] [Talk-us] Trunk VS primary,

[Joseph Eisenberg]

Thank you for the correction. So highway=trunk in German is similar to
expressway=yes in the USA?

Joseph

On Sun, Dec 22, 2019 at 6:49 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 21. Dec 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > Unfortunately, the road classification system in parts of Continental
> > Europe was different, so mappers in some major countries, including
> > Germany and France, chose to use highway=trunk as synonym for
> > "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> > major roads tagged as highway=primary.
>
>
> actually not, the motorroad tag was introduced by the Germans (AFAIK) to
> express a typical access situation on many trunks but also some primaries
> (motorway like access), so that trunk (motorway like physical construction)
> and access could be tagged orthogonally. There are also some trunks that
> permit slower traffic in Germany.
>
> Cheers Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Martin Koppenhoefer]

sent from a phone

>> On 21. Dec 2019, at 22:54, Joseph Eisenberg  
>> wrote:
> Thank you for the correction. So highway=trunk in German is similar to 
> expressway=yes in the USA?


I am not familiar with US tagging, but the expressway page says they must be 
dual carriageways and can have at grade intersections:
https://wiki.openstreetmap.org/wiki/Key:expressway

the German trunks must not have at grade intersections (like motorways) and can 
be single carriageway (but do not allow overtaking using the opposite 
direction).


Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Joseph Eisenberg]

Do highway=trunk in German always have a physical barrier such a kerb
to separate the two directions, even if they are not a dual
carriageway?

The English highway=trunk page says this about Germany "The
carriageways are separated physically or by road markings".

An automated translation of the German page suggests that these
"Autobahnähnliche Straße" can be translated "expressways".

But it's not clear how they are distinguished from highway=motorway
features in Germany.

I think this shows the disadvantage of determing the top-level highway
feature tag (primary, trunk) based on certain physical and legal
characteristics rather than on class in the road network: a number of
different features are combined in one tag which might better be
seprate tags like "expressway=yes" + "motorroad=no" +
"dual_carriageway=yes" + "acces=" etc. to express the important
characteristics of the road.

Joseph Eisenberg

On 12/22/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>>> On 21. Dec 2019, at 22:54, Joseph Eisenberg 
>>> wrote:
>> Thank you for the correction. So highway=trunk in German is similar to
>> expressway=yes in the USA?
>
>
> I am not familiar with US tagging, but the expressway page says they must be
> dual carriageways and can have at grade intersections:
> https://wiki.openstreetmap.org/wiki/Key:expressway
>
> the German trunks must not have at grade intersections (like motorways) and
> can be single carriageway (but do not allow overtaking using the opposite
> direction).
>
>
> Cheers Martin

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

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Sat, Dec 21, 2019 at 3:48 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 21. Dec 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > Unfortunately, the road classification system in parts of Continental
> > Europe was different, so mappers in some major countries, including
> > Germany and France, chose to use highway=trunk as synonym for
> > "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> > major roads tagged as highway=primary.
>
>
> actually not, the motorroad tag was introduced by the Germans (AFAIK) to
> express a typical access situation on many trunks but also some primaries
> (motorway like access), so that trunk (motorway like physical construction)
> and access could be tagged orthogonally. There are also some trunks that
> permit slower traffic in Germany.
>

I would also consider a "super two" or similar undivided design to be a
trunk.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging