Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

It says in the proposal the the vertical bar is an alternative. You can still 
use hypens, however vertical bar is more explicit. With a addr:range however 
hypens should be enough.
-- 


23 Dec 2020, 22:59 by tagging@openstreetmap.org:

> As I understand, it would mean that 40-48 range would need to be
> recorded as addr:housenumber=40|48 rather than more natural
> addr:housenumber=40-48
>
> Dec 23, 2020, 21:06 by t...@fitchfamily.org:
>
>> Vertical bar character is already in use for turn lanes[1]. Not a big deal 
>> to type it, at least on a US keyboard. Certainly easier to type it than to 
>> enter two key/value pairs for the same information. Seems like a poor reason 
>> to avoid it since it is one of the few characters that seems unlikely to 
>> exist on an address in the wild.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications_per_lane
>>
>>> On Dec 23, 2020, at 11:46 AM, Mateusz Konieczny via Tagging 
>>>  wrote:
>>>
>>> I am not so happy about it.
>>>
>>> Typing that would be extremely unnatural.
>>>
>>> Maybe better have additional add:range:from= addr:range:to=
>>> for ranges?
>>>
>>> Dec 23, 2020, 20:10 by tagging@openstreetmap.org:
>>> Im gping to update the proposal tonight, when I have time.
>>>
>>> I currently think suggesting a new character, | , used to explicitally 
>>> specify ranges. The advantage of this is that ypu can interpolation 
>>> hypenated addresses, e.g. :
>>>
>>> addr:housenumber="19-100|19-200"
>>>
>>> Would imply : 19-100, 19-102, 19-104, 19-106 etc.
>>>
>>> Renderers can use "19-100 to 19-200"
>>>
>>> Hypens would be accepted, but this is clearer.
>>>
>>> The problem is that now you will have to get every single renderer and 
>>> geocoder to understand this (which will take months ,even years).
>>>
>>>
>>>
>>> --
>>> 23 Dec 2020, 16:29 by lon...@denofr.de:
>>> On Mon, Dec 21, 2020 at 07:05:10PM +0100, ipswichmapper--- via Tagging 
>>> wrote:
>>> Okay. In this case I can rename to proposal page to "addr:range".
>>>
>>> This new tag:
>>>
>>> - applies to nodes and closed ways that have addr:housenumber
>>> - "addr:range=n" means every nth house is counted in a range
>>> - "addr:range=even/odd" means every even/odd house is counted
>>> - "addr:range=all" means every house is counted (default value for a 
>>> housenumber tag with a hyphen in it if no range is given).
>>> - "addr:range=no" means that the housenumber tag is NOT a range of values 
>>> but rather a single housenumber.
>>>
>>> It's better. It would resolve half the issue. addr:housenumber would still
>>> have a double interpretation but it's the smaller of the two issues.
>>>
>>> addr:housenumber:range would capture a bit better what the tag means
>>> but it starts to get uncomfortably long.
>>> "addr:range=all" is the default because that is what the wiki says and what 
>>> software like streetcomplete suggests. Many buildings with multiple 
>>> housenumbers are tagged like this.
>>>
>>> That would only make sense, when you define addr:range as being
>>> applicable to housenumbers with hyphens only. However your definition
>>> above was imo more sensible:
>>> "applies to nodes and closed ways that have addr:housenumber"
>>>
>>> If you look at all nodes and ways with addr:housenumbers 99.999% have
>>> a addr:range=no. So that makes more sense as a default then.
>>> However, software can create different defaults for different countries. 
>>> For example, in the UK a hypenated address most probably means a range of 
>>> even/odd addresses (so "addr:range=2")
>>>
>>> What are your thoughts on this?
>>> Also, I had linked the talk-gb thread, which discusses how 
>>> addr:interpolation on closed ways and nodes is already standard. That is 
>>> the problem with suggesting a new tag. This proposal would now require 
>>> informing multiple mappers to switch up the taggong scheme.
>>>
>>> My guess would be that the main reason that people started using the
>>> hyphen notation with addr:housenumber is that they wanted something
>>> human readable on the map. And addr:housenumber was already rendered.
>>>
>>> With that

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

Hello everyone,

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:range

Here is the updated page. There may be some mistakes / it may not be completely 
done yet, but it gives a rough overview of addr:range.

Thanks,
IpswichMapper-- 
 Sent with Tutanota, the secure & ad-free mailbox: 
 https://tutanota.com


23 Dec 2020, 21:04 by tagging@openstreetmap.org:

> Thats what the addr:range tag is for
>
> I have explained this in a previous message on this mailing list. I'll update 
> the wiki proposal page so that it much clearer how addr:range works compared 
> to trying to explain in on a mailing list.
>
> Thanks, 
> IpseichMapper 
> -- 
>
>
>
> 23 Dec 2020, 20:38 by dieterdre...@gmail.com:
>
>>
>>
>> sent from a phone
>>
>>> On 23. Dec 2020, at 20:12, ipswichmapper--- via Tagging 
>>>  wrote:
>>>
>>> addr:housenumber="19-100|19-200"
>>>
>>> Would imply : 19-100, 19-102, 19-104, 19-106 etc.
>>>
>>
>>
>> it could also imply 19-100, 19-101, 19-102...
>> and you also can’t know which numbers are included and which do not exist 
>>
>> Cheers Martin
>>
>
>

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

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

How would this break routing and navigation? As far as I know, geocoders 
currently read hypenated addresses as ranges anyway (correct me if I'm wrong) 
so this proposal won't change what happens to hypenated addresses without 
addr:range tag. (Ime. Navigation is already broken in NYC)

IpswichMapper
---


21 Dec 2020, 19:44 by kevin.b.ke...@gmail.com:

>
>
> On Mon, Dec 21, 2020 at 2:15 PM ipswichmapper--- via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> What do you mean by this? You would have to tag with addr:range=no, as that 
>> is not a default value.
>>
>> However, don't see this as a downside. Currently, software such as OSMand 
>> interprets hypenated addresses as a range anyway, so requirement to  tag 
>> addr:range=no would be a benefit.
>>
>
> Ouch.  So every building in Queens, NY (one of the five boroughs of New York 
> City, with about 2.3 million inhabitants) would need to have an 
> 'addr:range=no' tag added in order not to break routing and navigation there?
>
>
> -- 
> 73 de ke9tv/2, Kevin
>

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

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

What do you mean by this? You would have to tag with addr:range=no, as that is 
not a default value.

However, don't see this as a downside. Currently, software such as OSMand 
interprets hypenated addresses as a range anyway, so requirement to  tag 
addr:range=no would be a benefit.

IpswichMapper
-- 
 


21 Dec 2020, 18:27 by zelonew...@gmail.com:

> Would this work for addressing schemes that use a hyphenated prefix?
>
> In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix 
> in addresses to determine which sector of the island an address is located.  
> So an address might be something like "99-123 Kamehameha Highway".  Would 
> this scheme work for an apartment complex that's addressed something like 
> 99-100 through 99-200 ?
>
> On Mon, Dec 21, 2020 at 1:15 PM Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> I like this new tag.
>>
>> I had proposing something like that on my TODO list.
>>
>> I added it in >> https://www.openstreetmap.org/changeset/96211869 
>> <https://www.openstreetmap.org/changeset/96211869#map=17/50.07743/19.93381=N>
>> to mark addr:housenumber=1-3 as a single address, not a range
>> (based on survey that I remember well)
>>
>> Dec 21, 2020, 19:05 by >> tagging@openstreetmap.org>> :
>>
>>> Okay. In this case I can rename to proposal page to "addr:range".
>>>
>>> This new tag:
>>>
>>> - applies to nodes and closed ways that have addr:housenumber
>>> - "addr:range=n" means every nth house is counted in a range
>>> - "addr:range=even/odd" means every even/odd house is counted
>>> - "addr:range=all" means every house is counted (default value for a 
>>> housenumber tag with a hyphen in it if no range is given).
>>> - "addr:range=no" means that the housenumber tag is NOT a range of values 
>>> but rather a single housenumber.
>>>
>>> "addr:range=all" is the default  because that is what the wiki says and 
>>> what software like streetcomplete suggests. Many buildings with multiple 
>>> housenumbers are tagged like this.
>>>
>>> However, software can create different defaults for different countries. 
>>> For example, in the UK a hypenated address most probably means a range of 
>>> even/odd addresses (so "addr:range=2")
>>>
>>> What are your thoughts on this?
>>>
>>> Also, I had linked the talk-gb thread, which discusses how 
>>> addr:interpolation on closed ways and nodes is already standard. That is 
>>> the problem with suggesting a new tag. This proposal would now require 
>>> informing multiple mappers to switch up the taggong scheme.
>>>
>>> Thanks,
>>> IpswichMapper
>>>
>>> -- 
>>>
>>>
>>> 21 Dec 2020, 15:19 by >>> lon...@denofr.de>>> :
>>>
>>>> On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging 
>>>> wrote:
>>>>
>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
>>>>>
>>>>> Quick proposal I just created to accept this form of tagging. This 
>>>>> follows from a discussion on the Talk-GB mailing list.
>>>>>
>>>>> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
>>>>>
>>>>>
>>>>> Please comment if there are issues with accepting this form of tagging.
>>>>>
>>>>
>>>> I dislike this kind of tagging to the point that I've refused to
>>>> support it in Nominatim in the past. See
>>>> https://github.com/osm-search/Nominatim/issues/565>>>>  for the full 
>>>> disucssion.
>>>>
>>>> The problem is that it makes the interpretation of addr:housenumber and
>>>> addr:interpolation dependent on the presence of another tag.
>>>>
>>>> Note that addr:housenumber=40-48 can be a valid housenumber. Example:
>>>> https://www.openstreetmap.org/way/285077586>>>>  So to know if the tag 
>>>> needs
>>>> to be interpreted as a single housenumber or as a housenumber range
>>>> you need to check if the node/way has a addr:interpolation tag in addtion
>>>> to the addr:housenumber tag.
>>>>
>>>> Similarly, a way with addr:interpolation needs to be processed in two
>>>> different ways: If a addr:housenumber is present, then assume it's a
>>>> building and parse the addr:housenumber tag to get the range. If no
>>>> housenumber is on the way, assume it is a good old interpolation line
>>>> and look at the housenumbers along the nodes of the way.
>>>>
>>>> I find this kind of double meaning for tagging confusing and error-prone.
>>>> But I might be fighting wind mills here.
>>>>
>>>> Sarah
>>>>
>>>>
>>>> ___
>>>> 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] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

Okay. In this case I can rename to proposal page to "addr:range".

This new tag:

- applies to nodes and closed ways that have addr:housenumber
- "addr:range=n" means every nth house is counted in a range
- "addr:range=even/odd" means every even/odd house is counted
- "addr:range=all" means every house is counted (default value for a 
housenumber tag with a hyphen in it if no range is given).
- "addr:range=no" means that the housenumber tag is NOT a range of values but 
rather a single housenumber.

"addr:range=all" is the default  because that is what the wiki says and what 
software like streetcomplete suggests. Many buildings with multiple 
housenumbers are tagged like this.

However, software can create different defaults for different countries. For 
example, in the UK a hypenated address most probably means a range of even/odd 
addresses (so "addr:range=2")

What are your thoughts on this?
Also, I had linked the talk-gb thread, which discusses how addr:interpolation 
on closed ways and nodes is already standard. That is the problem with 
suggesting a new tag. This proposal would now require informing multiple 
mappers to switch up the taggong scheme.

Thanks,
IpswichMapper
-- 


21 Dec 2020, 15:19 by lon...@denofr.de:

> On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging wrote:
>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
>>
>> Quick proposal I just created to accept this form of tagging. This follows 
>> from a discussion on the Talk-GB mailing list.
>>
>> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
>>
>>
>> Please comment if there are issues with accepting this form of tagging.
>>
>
> I dislike this kind of tagging to the point that I've refused to
> support it in Nominatim in the past. See
> https://github.com/osm-search/Nominatim/issues/565 for the full disucssion.
>
> The problem is that it makes the interpretation of addr:housenumber and
> addr:interpolation dependent on the presence of another tag.
>
> Note that addr:housenumber=40-48 can be a valid housenumber. Example:
> https://www.openstreetmap.org/way/285077586 So to know if the tag needs
> to be interpreted as a single housenumber or as a housenumber range
> you need to check if the node/way has a addr:interpolation tag in addtion
> to the addr:housenumber tag.
>
> Similarly, a way with addr:interpolation needs to be processed in two
> different ways: If a addr:housenumber is present, then assume it's a
> building and parse the addr:housenumber tag to get the range. If no
> housenumber is on the way, assume it is a good old interpolation line
> and look at the housenumbers along the nodes of the way.
>
> I find this kind of double meaning for tagging confusing and error-prone.
> But I might be fighting wind mills here.
>
> Sarah
>
>
> ___
> 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] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes

Quick proposal I just created to accept this form of tagging. This follows from 
a discussion on the Talk-GB mailing list.

https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html


Please comment if there are issues with accepting this form of tagging.

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

Hello everyone,

I haven't really explained myself since I cancelled this proposal 7 days ago. 
However, just now this proposal was mentioned on WeeklyOSM, so I just want to 
clarify why I have cancelled this proposal.

>From reading all these comments, it is clear a "crossing=priority" is not a 
>good tag. In many places, pedestrians always have priority at intersections 
>even if there is no crossing. The "crossing=priority", however, assumed that 
>the crossing is marked (if it gives priority). This is because of my 
>experience in the UK. 

Furthermore, there seems to be much bigger structural problems with the current 
"crossing" tagging scheme. Therefore, a proposal to improve crossing should be 
more detailed and make more improvements.

My proposal was hacked together in about an hour, mainly because I wanted to 
see how to create proposals, but also because I thought this was a simply issue 
with the current tagging that could quickly be fixed. 

I don't have time to create a new, more detailed crossing proposal, but if 
anyone does, here is what should be done:

- A separate tag for priority e.g. "crossing:priority=yes", where yes indicates 
those who are using the crossing have immediate priority over those who are on 
the road.
- Potentially depreciating "crossing=uncontrolled" (but this would require 
"crossing=marked" and "crossing=unmarked" to be crystal clear.
- Making it clear what "crossing=marked" means. For example, does there need to 
be marking on the road? Or is tactile paving on the sidewalk considered 
"marked"?
- add additional tags to describe more of a crossing, for example 
"crossing:belisha_beacon=*", "crossing:kerb_extension", 
"crossing:buffer_marking" etc.
(see: 
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Fu%C3%9Fwege#Gehwegvorstreckung
 )
- What should be considered a crossing? If it is unmarked, is it a crossing at 
all? (Should all intersections be tagged as "unmarked crossings"? Are places 
with traffic islands (no kerbs) where people frequently cross considered as 
crossings even though they have no marking & no kerbs?)

All of these things (AND MORE) need to be considered properly when creating a 
new crossing proposal. 

If anyone has the time to do something like this, that would be great.

Thanks,
IpswichMapper
-- 
 


13 Dec 2020, 19:25 by tagging@openstreetmap.org:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
>
> Thanks,
> IpswichMapper
>

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

Yes, most likely this won't be required. However I have kept it there in case 
it works differently in other countries. Maybe not all zebra crossings in 
Singapore have belisha beacons (for example, I don't know if this is true). 
That is why I am leaving it open for discussion for now, if after the RFC it is 
decided that this is a bad idea I'll remove it.

Thanks,
IpswichMapper
-- 

13 Dec 2020, 19:50 by tagging@openstreetmap.org:

> It seems to be proposing also belisha_beacon=yes that
> is now unused
> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>
> At the same time it has 
> "However, in countries like the UK, where belisha beacons are used, every 
> single zebra crossing has belisha beacons installed, so there is no need to 
> tag them"
>
> There is also
> "Indicates the presence of a "belisha beacon" at the crossing. (Most likely 
> unnecessary, discuss below)"
>
> Given there is no indication that it would be useful or needed I think
> that it should be not proposed.
>
> If that it would be useful or needed it can be proposed separately.
>
> Note that having two proposals in one will result in people voting against
> if there are against any of them, so splitting would be a good idea
> anyway.
>
> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
>> 
>>
>> Here is my first proposal for a tag to describe pedestrian crossings where 
>> the pedestrian has right of way over all vehicles on the road from the 
>> moment they have indicated their intent to cross. I created this because 
>> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
>> proposal for more details.
>>
>> Thanks,
>> IpswichMapper
>>
>
>

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

[Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 


Here is my first proposal for a tag to describe pedestrian crossings where the 
pedestrian has right of way over all vehicles on the road from the moment they 
have indicated their intent to cross. I created this because "crossing=zebra" 
or "crossing=marked" aren't clear enough. Please read the proposal for more 
details.

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

[Tagging] Questions about public transport tagging

[ipswichmapper--- via Tagging]

Hello, I have quite a few questions about Public Transport related tagging in 
Openstreetmap.

My first question is about the "interval:conditional" & "opening_hours" tag for 
bus routes. The "Bus Route" page on the OSM wiki mentions this tag, but the 
train route or "public transport" route page does not mention this tag at all. 
So I wanted to ask, is this tag discouraged?

The disadvantage of this tag, obviously, is that it is quite difficult to 
maintain. However, I think it is possible. My method would be to make a table 
which contains all the public transport route relations in an area, and add a 
column for "last checked". This would display the last date that this public 
transport route was checked. Regular mappers can do a check of a bunch of 
public transport routes every few months to see if the opening_hours or 
interval:conditional has changed. (I plan on including this on a guide to 
mapping public transport routes that I will be making).

Here is the table for Ipswich:

https://wiki.openstreetmap.org/wiki/Ipswich#Public_Transport_Version_2

Note currently, this is not formatted how I described. The reason for this is 
because not every bus routes has been added, so instead of having a "last 
checked" column, there are four columns ("interval", "interval:conditional", 
"duration", "opening_hours"). This is because some of the unfinished routes 
still don't have these tags.

Second question is about mapping train route stops. If I understand correctly, 
you are meant to add the platform at which people wait with role "platform" as 
well as the stop position of the train with role "stop".

I see issue with this. Firstly, none of this is clarified on the wiki under 
train routes. Secondly, what if you don't know what platform the train will 
leave from? What if there is no platform? In the UK this isn't a problem as all 
train stations have platforms. However, in other countries, in rural areas, 
train stations may not have any built up platform, you just wait by the side of 
the railway.

Secondly, why do you have to map stops and not platforms? Again, if the train 
goes at different platforms, then the stop position will also be different. You 
may not know what the stop position is, in which case you chose a random point 
on the railroad. Instead, it would be much better if you could just mark the 
"station" as a member of the relation. However, there is no "station" role, so 
adding a station creates a role verification problem.

Last question is about "combining intervals". This is something that, if 
needed, can be asked about in another thread (as it needs more discussion). In 
many cases, multiple bus routes go down the same path for a significant section 
of their journey, and split near the end of their journey.  An example of this 
is route 66 & route 66A in Ipswich. [1][2][3]

For most of their journey, these buses have the same route. Combined, their 
interval is "every 20 minutes". The interval of 66A is every hour. The 66 has a 
20 minute interval, then a 40 minute one, then a 20 min one, etc.

If these were mapped separately, you a routing software wouldn't be able to 
compute that the interval is 20 minutes. So how can this be fixed?

The solution I can think of is to map a separate relation called ("66/66A") 
which is the combined route and give it a interval of 20 minutes. However, I'm 
pretty sure some tags would be needed to be made for this, because otherwise it 
breaks the ground rule (as there is no bus called "66/66A" in real life). 

Another interesting idea was suggested in this Reddit post:

https://old.reddit.com/r/openstreetmap/comments/jkdsjr/common_area_of_bus_routes/

That is that roads with multiple bus routes can be tagged with the bus route, 
instead of the other way route (to cut down on repetition).
Thanks,

IpswichMapper

[1]: https://www.openstreetmap.org/relation/190701
[2]: https://www.openstreetmap.org/relation/9984463
[3]: 
https://www.firstgroup.com/uploads/maps/FEC-Ipswich%20Reds%2066%20-%20Bus%20Times%20from%2025-10-20.pdf


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