Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 02:43:03PM +0100, Peter Elderson wrote:
> I like Sarah's proposal too, especially for walking routes. I'm not sure it
> would work for complex PT routes, where routability is involved.
> 
> One issue: a route relation can be a route on it's own AND part of a longer
> route (or node network), on any level of the hierarchy. segment=yes would
> not cover that, I think?

In that case, nothing would be needed. It is only important to know when
a relation is not a route on its own. Because then that route can be ignored
in lists or when adding markings to the map.

Sarah

> And when naming parts, you'll have to cover the case that a route can be
> part of multiple longer routes, the route itself may contain smaller parts
> that are also part of multiple routes.
> Parts can have any of the network tags.
> 
> This complication is not created by Sarah's idea, but I would like to see
> that solved too.
> 
> Fr gr Peter Elderson
> 
> 
> Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst  >:
> 
> > marc marc wrote:
> > > imho nearly no routing tools (nor foot nor bus) is currently
> > > able to use a relation type=route with relations as child.
> >
> > cycle.travel can.
> >
> > I don't particularly care what's decided, but I would like it to be
> > consistent (which right now it certainly isn't), and personally I don't see
> > the need for type=superroute when you can just have relations as children
> > of
> > type=route. I like Sarah's proposal for route_segment=yes.
> >
> > Richard
> >
> >
> >
> > --
> > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> >
> > ___
> > 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] Mapping deforestation wikipage

[Lorenzo Stucchi]

Hi,

The idea is for sure to check the date of the imagery and map when new imagery 
are available and we can consider also the time step between the different 
satellite imagery.

The fact that some contributor modify the data is not a problem because they 
will done adding new information and this is just an improvement in the data.

Think like they are highway, I can’t known what is the type of the highway but 
I can cleary see that its a road, so I can map it as highway=road with all the 
problem of this case. But un other user with better knowledge can identify 
which type of highway.
In a similar way there is just a different structure of classification, and 
when better imagery or generally better info are available the tag landcover 
will be improved with the more detailed tag.

For what regards the history I’m agree with Martin.

Best,
Lorenzo


Il giorno 15 mar 2019, alle ore 08:32, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> ha scritto:

> “The idea is to have mapathon in
> different time, when new imagery are
> available and after check what
> changed searching in the database

In this case you only need to map the area of woodland or forest now, and it’s 
no problem to leave other landuse and natural areas unmapped.

But it may be difficult to use the OSM database for checking changes over time, 
if you would like scientific, publishable results.

To properly compare the current woodland area with the area in a couple of 
years, you will need to make sure that the aerial imagery that you use now is 
all from the same year.

Then, when you repeat the project in 1 or 2 years, you need to have new imagery 
from around the same time, and you should map the woodland or forested areas 
using the same standard and methods as they first time. This will be easiest if 
you remap everything from scratch the second time as well.

If you try to use the OSM database both times, you may find that other mappers 
have changed things in the meantime. Perhaps they have changed some of your 
landuse=forest to natural=wetland wetland=mangrove, because they know the area 
better. Perhaps they have mapped a new palm
oil plantation based on local information, but it isn’t visible in the aerial 
imagery. How will you deal with such changes?

So it is great to add the forest or wood areas to OSM right now based on the 
latest aerial imager.

But you should plan to keep your own copy of the database to compare with and 
edit in the future. If you do this right it could be professionally-quality 
data for environmental research, but that means you need to keep a copy of the 
data that won’t change, and use that for comparison in the future.

___
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] Superroutes - good, bad or ugly?

[Peter Elderson]

For map display, I can see that. The ways are added to a higher level (if
one exist) and the symbol is ignored.

I am not sure about routing/navigating. especially network routing. I
imagine a network router has to create an instant route, so it has to
decide whether to use the segment or not. The higher relations may not
apply, but the segment may be useable for the instant route. I think the
routing algorithm would need a tag for that?

I also think in the course of time, many segments will not be part of any
relation any more. At first they might be shared, but they may be removed
from the higher relation(s), the mapper doesn't know that (s)he was the
last user, so will not modify the segent relation.

Fr gr Peter Elderson


Op za 16 mrt. 2019 om 08:25 schreef Sarah Hoffmann :

> On Fri, Mar 15, 2019 at 02:43:03PM +0100, Peter Elderson wrote:
> > I like Sarah's proposal too, especially for walking routes. I'm not sure
> it
> > would work for complex PT routes, where routability is involved.
> >
> > One issue: a route relation can be a route on it's own AND part of a
> longer
> > route (or node network), on any level of the hierarchy. segment=yes would
> > not cover that, I think?
>
> In that case, nothing would be needed. It is only important to know when
> a relation is not a route on its own. Because then that route can be
> ignored
> in lists or when adding markings to the map.
>
> Sarah
>
> > And when naming parts, you'll have to cover the case that a route can be
> > part of multiple longer routes, the route itself may contain smaller
> parts
> > that are also part of multiple routes.
> > Parts can have any of the network tags.
> >
> > This complication is not created by Sarah's idea, but I would like to see
> > that solved too.
> >
> > Fr gr Peter Elderson
> >
> >
> > Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst <
> rich...@systemed.net
> > >:
> >
> > > marc marc wrote:
> > > > imho nearly no routing tools (nor foot nor bus) is currently
> > > > able to use a relation type=route with relations as child.
> > >
> > > cycle.travel can.
> > >
> > > I don't particularly care what's decided, but I would like it to be
> > > consistent (which right now it certainly isn't), and personally I
> don't see
> > > the need for type=superroute when you can just have relations as
> children
> > > of
> > > type=route. I like Sarah's proposal for route_segment=yes.
> > >
> > > Richard
> > >
> > >
> > >
> > > --
> > > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> > >
> > > ___
> > > 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] Feature Proposal - RFC - police=*

[Jan S]

Am Fr., 15. März 2019 um 17:48 Uhr schrieb marc marc <
marc_marc_...@hotmail.com>:

> Le 15.03.19 à 17:16, Jan S a écrit :
> > I sense dissent here about the future use of amenity=police. Would it be
> a possible solution to keep amenity=police for public-facing police
> stations only,
>
> that's the current meaning.
>
> > but invite mappers on the wiki to nevertheless add police=station, so
> that in the future the majority of police stations will hopefully also
> carry the police=station tag?
>
> at the risk of repeating myself, some mappers disapprove of having to
> enter the same information twice because of the coexistence of 2 tags
> with the same meaning.
> you can of course try your luck by submitting this idea grouped with the
> rest of your proposal... or you can separate this conflicting idea to
> increase the chances of adoption of the main part of your propal,
> it's up to you (I'll separate).
>
> anyway, even if it passes, it is unfortunately inevitable that the 2
> tags get out of sync and then the meaning gets worse than before:
> if a mapper deletes the only-one tag from a police station,
> his intention is clear, it's not more a police station.
> if a mapper deletes only one of the 2 tags from a police station, has he
> done so because the police station is closed (and the other must also be
> deleted) or because he wants to delete one of the 2 duplicated schemes?
>
> this "dual-schema" period is really painful, which is why I find it
> preferable that it be as short as possible.
> in this perspective, I am in favor of first promoting all police=* who
> currently do not have a tag and once this scheme is well known/used,
> do another operation to try to switch amenity=police to police=station
> (and, I repeat, do not underestimate the enormous resistance of some
> community members who think (imho wrongly) that frequent tags should be
> kept immutable for eternity.)
>

I have prepared the proposal for a transition period that hopefully won't
break current mapping and rendering by maintaining amenity=police for
public-facing police stations, but inviting mappers to tag these stations
also as police=station.

All other police facilites, that may currently have been tagged erroneously
as amenity=police would be tagged only as police=*, while public-facing
police stations shall be double-tagged as amenity=police and
police=station. It can then be decided in the future whether amenity=police
will prevail or whether public-facing police stations will be exclusively
tagged as police=station, in order to be consistent with other police
facilites.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Martin Koppenhoefer]

sent from a phone

> On 16. Mar 2019, at 13:11, Jan S  wrote:
> 
> All other police facilites, that may currently have been tagged erroneously 
> as amenity=police would be tagged only as police=*,


The „problem“ with this approach is that maps who base the presence of objects 
in their renderings on the presence of specific keys will likely not happen to 
find these police=* things in their database. Depending on how relevant the 
objects are for the specific map, this may be desirable or not. Just as a point 
of consideration. Of course in theory who defines the filtering rules for the 
keys might add „police“, but in practice it takes a lot of time to establish a 
new key as standard.

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Jan S]

Am Sa., 16. März 2019 um 15:09 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> > On 16. Mar 2019, at 13:11, Jan S  wrote:
> >
> > All other police facilites, that may currently have been tagged
> erroneously as amenity=police would be tagged only as police=*,
>
>
> The „problem“ with this approach is that maps who base the presence of
> objects in their renderings on the presence of specific keys will likely
> not happen to find these police=* things in their database. Depending on
> how relevant the objects are for the specific map, this may be desirable or
> not. Just as a point of consideration. Of course in theory who defines the
> filtering rules for the keys might add „police“, but in practice it takes a
> lot of time to establish a new key as standard.
>
> Sure, but currently amenity=police is used indiscriminately on many
police-related objects, no matter whether they are important or providing
background services. There are several instances of police barracks or
warehouses mapped as amenity=police, although they clearly don't provide
service to the public. So you basically can't rely on OSM to find a police
station in case of an emergency. I think that's worse than maybe losing
some other police facilities from certain maps.

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Martin Koppenhoefer]

sent from a phone
> On 16. Mar 2019, at 15:53, Jan S  wrote:
> 
> So you basically can't rely on OSM to find a police station in case of an 
> emergency.


let us not overemphasize the emergency in this context. In an urgent emergency 
you would expect the police to come to you rather than the opposite.

I agree that we should have an amenity tag for police stations (this still 
means many of them would be closed after office times, for example in Germany), 
and that amenity=police was defined so since the beginning.
And it appears that other police facilities and non public operations also bear 
the tag.

We could try to migrate those other police amenities to amenity=police_facility 

some would better be retagged as office, but if you want a tag which more 
reliably states “police station”, it looks like a new subtag e.g. 
police=station could work.

There are already 22 of them ;-)
https://taginfo.openstreetmap.org/keys/police#values
Most common (the only significantly used) value for “police” is 
“traffic_police” (987 uses). This is a type of police, not a type of facility.

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

[Tagging] Proposal: add Tag:route=share_taxi and Tag:route=minibus for public transportation relationship

[Phake Nick]

In Hong Kong, it is previously decided that, when tagging routes or
access restriction of public service vehicles, a large-sized
franchised bus can be represented with key/value or "bus", a green
minibus can be represented with key/value of "minibus", while a red
minibus can be represented with the key/value of "share_taxi", because
of different nature of all these service. See
https://wiki.openstreetmap.org/wiki/WikiProject_Hong_Kong/Transport/Public_transport
.

However, in the PTv2 tagging scheme, it does not include support for
either route=minibus nor route=share_taxi, and alternative schemes
like route=bus+bus=minibus or route=bus+bus=share_taxi being proposed
also doesn't seems to receive any support so far. As such I would like
to propose including the tag value of route=minibus and
route=share_taxi into the PTv2 tagging scheme in order to represent
those minibus routes in the OSM database via the PTv2 tagging scheme.

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

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
> 在 2019年3月14日週四 20:38，Simon Poole  > 寫道：
>
> Some more comments:
>
> - the OH values are currently always evaluated in the local time zone
> (or to go even a bit further in a local context as the location they
> apply to is always known), so a time zone indicator would be only
> needed
> in the cases that require different processing, the question is if
> that
> is common enough to justify the additional complication.
>
> The three most prominent area that are still using the calendar
> nowadays are China, Korea, Vietnam. Each of them have their own
> version of this lunar calendar with the most notable difference being
> the meridian used to create the calendar. So that once in a few years
> you could see reports saying that the lunar calendar and the festival
> that depends on it are not correct on some software.
>
> Let's say you represent the Lunar New Year as L01 01. The software can
> assume it mean Chinese New Year in China, Vietnamese New Year in
> Vietnam, and Korean New Year in Korea. So far so good. But then these
> festivals aren't just celebrated within these three countries. Places
> like Thailand, Indonesia, Japan, Australia, America, and many other
> countries around the world all have different events that would take
> place for the Lunar New Year. Sometimes they're commercial events that
> are currently catering specifically to Chinese New Year. Sometimes
> they are diaspora population that celebrate the festival on the same
> day as their parent countries. You cannot know which exact day it's
> referring to without referring to the timezone being used to calculate
> the calendar, and at least it need to specify
> Korean/Chinese/Vietnamese version and that is assuming the region will
> not create any new timezone in the future, like how time changes
> related to the Vietnamese war caused the North Vietnam and South
> Vietnam celebrated the new year at different date back then and
> resulted in some military advantages.

That's all fine and dandy, but the OSM opening_hours tags is for the
opening hours of facilities and similar, not a general purpose event
description facility. So I would expect that a shop in AUS that is
closed on a Chinese holiday to indicate that in a local Gregorian
calendar fashion.

>
> One might think it'd be easier to add CNY/KNY/VNY into the variable
> holiday separately like easter instead, but there are a number of
> other events that're celebrated based on local lunar calendar and is
> celebrated at more places than those aforementioned countries, like
> Confucius birthday, mid-autumn festival, double nine festival, and so
> on. If calendar-specific version of all these holidays are all getting
> their own values as variable-holiday then there would be too many of them.
>
> And there also other scenario that timezone value is useful, for
> instance iirc Fiji decided that the country will implement DST but the
> school system operation time will not follow the transition. Or in
> places like Xinjiang or West Bank where there are two different
> timezones used by different population living in same area.
>
>
> - Summer and winter solstice can be, as far as I can see, modelled as
> additional variable_date values (currently only "easter" is
> defined), I
> would avoid qualifying them with months as again, that require parser
> changes that will cause issues.
>
>
> Except other solar terms are still used. For example March equinox and
> September equinox are national holiday in Japan. Setsubun celebration
> in Japan is mainly a day before first solar term in February but also
> a day before first solar term in May, August, November. Qing Ming
> (mainly China, Korea, etc.) is the first solar term in April.
>
>
> - Lunar months: are there any common names for these instead of just
> numbering? And how are the "leap" variants supposed to be different?
>
> Simon
>
>
> It is usually just numbering, but in Chinese there are nickname for
> the 11th and 12th month, while in Japanese there are nickname for all
> the months. Consider that those nick name are less popular,
> regional-specific and language-specific, it seems like it would be a
> bad idea to name them after the months.
> The "leap" version are for when a year have 13 lunar months. Instead
> of naming the additional month the 13th month, various criteria are
> used to select one of those thirteen months, and then name it as the
> "leap" version of the previous month. There are on average about 7
> years with leap month in every 19 years.
>
>
The whole reason that the OH spec is such a mess is because it tries to
remain human readable (for non-nerds), I doubt that there is any support
for suddenly departing from that. A OH evaluator needs to have the logic
for determining if it is a leap year or whatever, the OH grammar simply
needs to define strings which correspond to the commo

Re: [Tagging] Expand the key:opening_hours

[Phake Nick]

Of course such shop will also need to indicate the closing date in
Gregorian calendar fashion, but as those date are not fixed, if you are
typing that information in Gregorian calendar into OSM then you're
effectively inputting one-off event into OSM that needs to be changed every
year to match the calendar of the year.

在 2019年3月17日週日 01:57，Simon Poole  寫道：

>
> Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
>
> 在 2019年3月14日週四 20:38，Simon Poole  寫道：
>
>> Some more comments:
>>
>> - the OH values are currently always evaluated in the local time zone
>> (or to go even a bit further in a local context as the location they
>> apply to is always known), so a time zone indicator would be only needed
>> in the cases that require different processing, the question is if that
>> is common enough to justify the additional complication.
>>
> The three most prominent area that are still using the calendar nowadays
> are China, Korea, Vietnam. Each of them have their own version of this
> lunar calendar with the most notable difference being the meridian used to
> create the calendar. So that once in a few years you could see reports
> saying that the lunar calendar and the festival that depends on it are not
> correct on some software.
>
> Let's say you represent the Lunar New Year as L01 01. The software can
> assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam,
> and Korean New Year in Korea. So far so good. But then these festivals
> aren't just celebrated within these three countries. Places like Thailand,
> Indonesia, Japan, Australia, America, and many other countries around the
> world all have different events that would take place for the Lunar New
> Year. Sometimes they're commercial events that are currently catering
> specifically to Chinese New Year. Sometimes they are diaspora population
> that celebrate the festival on the same day as their parent countries. You
> cannot know which exact day it's referring to without referring to the
> timezone being used to calculate the calendar, and at least it need to
> specify Korean/Chinese/Vietnamese version and that is assuming the region
> will not create any new timezone in the future, like how time changes
> related to the Vietnamese war caused the North Vietnam and South Vietnam
> celebrated the new year at different date back then and resulted in some
> military advantages.
>
> That's all fine and dandy, but the OSM opening_hours tags is for the
> opening hours of facilities and similar, not a general purpose event
> description facility. So I would expect that a shop in AUS that is closed
> on a Chinese holiday to indicate that in a local Gregorian calendar fashion.
>
>
> One might think it'd be easier to add CNY/KNY/VNY into the variable
> holiday separately like easter instead, but there are a number of other
> events that're celebrated based on local lunar calendar and is celebrated
> at more places than those aforementioned countries, like Confucius
> birthday, mid-autumn festival, double nine festival, and so on. If
> calendar-specific version of all these holidays are all getting their own
> values as variable-holiday then there would be too many of them.
>
> And there also other scenario that timezone value is useful, for instance
> iirc Fiji decided that the country will implement DST but the school system
> operation time will not follow the transition. Or in places like Xinjiang
> or West Bank where there are two different timezones used by different
> population living in same area.
>
>
>> - Summer and winter solstice can be, as far as I can see, modelled as
>> additional variable_date values (currently only "easter" is defined), I
>> would avoid qualifying them with months as again, that require parser
>> changes that will cause issues.
>>
>
> Except other solar terms are still used. For example March equinox and
> September equinox are national holiday in Japan. Setsubun celebration in
> Japan is mainly a day before first solar term in February but also a day
> before first solar term in May, August, November. Qing Ming (mainly China,
> Korea, etc.) is the first solar term in April.
>
>
>> - Lunar months: are there any common names for these instead of just
>> numbering? And how are the "leap" variants supposed to be different?
>>
>> Simon
>>
>
> It is usually just numbering, but in Chinese there are nickname for the
> 11th and 12th month, while in Japanese there are nickname for all the
> months. Consider that those nick name are less popular, regional-specific
> and language-specific, it seems like it would be a bad idea to name them
> after the months.
> The "leap" version are for when a year have 13 lunar months. Instead of
> naming the additional month the 13th month, various criteria are used to
> select one of those thirteen months, and then name it as the "leap" version
> of the previous month. There are on average about 7 years with leap month
> in every 19 years.
>
>>
> The whole reason that the OH spec is such 

Re: [Tagging] Feature Proposal - Voting - Top up v4

[bkil]

We have a use case in Hungary that you may consider to cover. Many
people pay their bills at the post office through money transfer
orders printed on small yellow printed paper slips (so called "Csekk"
or "Sárga csekk").

It is commonly offered by energy companies, municipal fees (waste
disposal, water, etc.), telco (Internet service providers, phone, TV)
and the government (for any kind of fee related to official inquiries,
taxes, registration, etc). The post office has deployed numerous
vending machines to automate the payment of these orders (they call it
"Posta Csekkpont").

TESCO offers a competing service with their own network of vending
machines, but it is only possible to pay a small subset of bills
there, because they aren't providing real money transfers, rather a
kind of B2B network to commit these transfer at a lower cost without
paying the Post office.

Could you please recommend a combination of tags that we should use
for these two networks?

Unfortunately, most of the links I have are in Hungarian, but do reach
out to me if you need more information:
https://en.wikipedia.org/wiki/Money_order#Money_orders_around_the_world

https://www.posta.hu/vallalkozasoknak/penzforgalmi_szolgaltatasok/keszpenzatutalasi_megbizas_sarga_csekk
https://tesco.hu/markak-es-szolgaltatasok/szolgaltatasok/csekkpont/
http://nol.hu/gazdasag/csekkbefizetes-ejjel-nappal-automatakkal-probalkozik-a-posta-1505003
https://www.tozsdeforum.hu/szemelyes-penzugyek/napi-penzugyek/elindult-a-tesco-csekkpont-szolgaltatasa-45547.html
http://www.tescomagyarorszag.hu/hu/sajt%C3%B3/sajt%C3%B3k%C3%B6zlem%C3%A9nyek/article/226-csekkponttal-indul-a-tesco

On Tue, Jan 29, 2019 at 4:06 PM Daniele Santini  wrote:
>
> The first voting for the Top up  proposal was rejected. I have changed the 
> proposal removing the most disliked parts and started a new voting: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> Kind regards
> --
> Daniele Santini
> http://www.dsantini.it
> ___
> 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 - police=*

[Mateusz Konieczny]

Mar 16, 2019, 3:53 PM by grimpeu...@gmail.com:

> Am Sa., 16. März 2019 um 15:09 Uhr schrieb Martin Koppenhoefer <> 
> dieterdre...@gmail.com > >:
>
>> > On 16. Mar 2019, at 13:11, Jan S <>> grimpeu...@gmail.com 
>> > >> > wrote:
>>  > 
>>  > All other police facilites, that may currently have been tagged 
>> erroneously as amenity=police would be tagged only as police=*,
>>  
>>  
>>  The „problem“ with this approach is that maps who base the presence of 
>> objects in their renderings on the presence of specific keys will likely not 
>> happen to find these police=* things in their database. Depending on how 
>> relevant the objects are for the specific map, this may be desirable or not. 
>> Just as a point of consideration. Of course in theory who defines the 
>> filtering rules for the keys might add „police“, but in practice it takes a 
>> lot of time to establish a new key as standard.
>>  
>>
> Sure, but currently amenity=police is used indiscriminately on many 
> police-related objects, no matter whether they are important or providing 
> background services. There are several instances of police barracks or 
> warehouses mapped as amenity=police, although they clearly don't provide 
> service to the public. So you basically can't rely on OSM to find a police 
> station in case of an emergency. I think that's worse than maybe losing some 
> other police facilities from certain maps.
>
Some police facilities will remain mistagged, no matter tagging scheme.

Have you already fixed such objects or opened OSM notes mentioning mistaggings?

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Mateusz Konieczny]

Mar 16, 2019, 3:08 PM by dieterdre...@gmail.com:

>> On 16. Mar 2019, at 13:11, Jan S <>> grimpeu...@gmail.com 
>> >> > wrote:
>>
>> All other police facilites, that may currently have been tagged erroneously 
>> as amenity=police would be tagged only as police=*,
>>
>
>
> The „problem“ with this approach is that maps who base the presence of 
> objects in their renderings on the presence of specific keys will likely not 
> happen to find these police=* things in their database.
>
Why not? Is it concern about technical difficulties or that they would be 
unaware that 
this tag exists?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Paul Johnson]

On Fri, Mar 15, 2019 at 3:24 AM Charles MILLET 
wrote:

> Taginfo shows it is not the preferred method 979<3562
>
> https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1
>
> https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane
>
> *=opposite_lane is/was well understood as far as I know (I am regularly
> "teaching" OSM using the bicycle wiki page as reference).
>
> Why using two tags when one works well, when the value opposite_lane
> exists and the interpretation is the same?
>
> I can understand the more structured aspect but using the :oneway value
> not to traduce the oneway but its direction is not clean for me. Why not
> using something with backward and forward in this case?
>
> Just my opinion but if "cycleway:left:oneway=-1" is officially preferred
> I will use it and promote it.
>

I'd honestly rather see bicycle tagging as part of the general lane tagging
scheme more widely adopted, since there may be more than one bicycle lane
each direction, and it's placement within the roadway may not necessarily
be the edge of the road.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Joseph Eisenberg]

The key “police” is not currently on the list of features that import as a
polygon in osm2pgsql, when mapped as a closed way.

So renderers and other database users that rely on osm2pgsql will need to
add the “police” key to the lua transformations list and reimport the
database.

This is easy for cartographers that make insividual maps, but it’s a major
undertaking for the main OSM servers, which is only done every couple of
years. So it will take some time before any objects tagged “police=station”
without an “amenity” tag could be rendered on the Standard map layer on OSM.

This shouldn’t be a problem for things like warehouses, non-public offices,
vehicle impound facilities etc. But it requires patience for police
stations.

-Joseph

On Sun, Mar 17, 2019 at 4:16 AM Mateusz Konieczny 
wrote:

>
> Mar 16, 2019, 3:08 PM by dieterdre...@gmail.com:
>
> On 16. Mar 2019, at 13:11, Jan S  wrote:
>
> All other police facilites, that may currently have been tagged
> erroneously as amenity=police would be tagged only as police=*,
>
>
>
> The „problem“ with this approach is that maps who base the presence of
> objects in their renderings on the presence of specific keys will likely
> not happen to find these police=* things in their database.
>
> Why not? Is it concern about technical difficulties or that they would be
> unaware that
> this tag exists?
> ___
> 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 - Voting - Top up v4

[Phake Nick]

The scheme seems a bit unnecessarily confusing by being unnecessarily
specific. Like what tag should I use for a place that can top up my Alipay
account directly?

在 2019年1月29日週二 23:06，Daniele Santini  寫道：

> The first voting for the Top up  proposal was rejected. I have changed the
> proposal removing the most disliked parts and started a new voting:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> Kind regards
> --
> Daniele Santini
> http://www.dsantini.it
> ___
> 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 - police=*

[Lionel Giard]

That's why the proposal state that we will keep the amenity=police tag on
the public-facing object so that they will still be backward compatible at
the moment. Thus, the "technical" problem doesn't exist, and if we drop the
amenity tag in the end, it will be probably after (at least) a year - if we
look at others tag changes in the past. Thus database users should have
plenty of time to adapt if needed ! ;-)

Le sam. 16 mars 2019 à 23:23, Joseph Eisenberg 
a écrit :

> The key “police” is not currently on the list of features that import as a
> polygon in osm2pgsql, when mapped as a closed way.
>
> So renderers and other database users that rely on osm2pgsql will need to
> add the “police” key to the lua transformations list and reimport the
> database.
>
> This is easy for cartographers that make insividual maps, but it’s a major
> undertaking for the main OSM servers, which is only done every couple of
> years. So it will take some time before any objects tagged “police=station”
> without an “amenity” tag could be rendered on the Standard map layer on OSM.
>
> This shouldn’t be a problem for things like warehouses, non-public
> offices, vehicle impound facilities etc. But it requires patience for
> police stations.
>
> -Joseph
>
> On Sun, Mar 17, 2019 at 4:16 AM Mateusz Konieczny 
> wrote:
>
>>
>> Mar 16, 2019, 3:08 PM by dieterdre...@gmail.com:
>>
>> On 16. Mar 2019, at 13:11, Jan S  wrote:
>>
>> All other police facilites, that may currently have been tagged
>> erroneously as amenity=police would be tagged only as police=*,
>>
>>
>>
>> The „problem“ with this approach is that maps who base the presence of
>> objects in their renderings on the presence of specific keys will likely
>> not happen to find these police=* things in their database.
>>
>> Why not? Is it concern about technical difficulties or that they would be
>> unaware that
>> this tag exists?
>> ___
>> 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] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 15/3/19 9:30 pm, Martin Koppenhoefer wrote:

these tags are stating different things though:



How are they different? If I have a oneway=yes way:

A--->B

oneway:bicycle=no tells me that bicycles can pass along this way A->B 
and B->A


exactly the same case if there is any of the tags:
cycleway:[left|right|both|none]:oneway=[-1|no]


They tell me the same thing. The point of this discussion is what the 
*preferred* method should be not how many different ways there are to 
tag the same piece of information. My point is simply why should mappers 
be told to prefer the less used and less likely to be consumed option 
rather than the much more common option?



cycleway:left:oneway=-1 on the other hand is describing a dedicated 
cycling infrastructure 


No it doesn't. What infrastructure, if any, is provided for cyclists is 
described by the cycleway=* tag. So in this case if that tag is 
accompanied by:


cycleway:left=shared

then there is no dedicated cycling infrastructure.

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 15/3/19 8:03 pm, Richard Fairhurst wrote:


On topic: I don't have a great preference for either tagging scheme (they're
both a bit ungainly, I've found them both a bit of a PITA to support in
cycle.travel's tag parsing). cycleway=opposite_lane is concise but unclear.


That's interesting to hear. I've always thought it was fairly simple. I 
picture it as having a oneway=yes A->B


cycleway=opposite

There is no specific cycling infrastructure in either direction but 
bicycles can travel A->B and B->A


cycleway=opposite_lane

There is no cycling infrastructure for cyclist riding A->B but there is 
a lane for cyclist riding B->A (and cyclists can ride in both directions)


cycleway=lane

Cyclist can ride A->B and they are provided with a lane

cycleway=lane
oneway:bicycle=no

Cyclists can ride in both directions and both directions have cycling 
infrastructure provided.


As you've actually consumed the data I'm interested to know what 
problems you have found as I think that this is one thing that is 
missing from most tagging debates on this list. It's all very nice to 
have the world's greatest tagging scheme but it's useless if no one can 
consume it at the end.



Regardless, both are in widespread use so the wiki should document both.



I don't think this is about if the alternative method should be 
documented. The problem is more that the wiki was changed to suggest the 
that alternative is now the recommended approach. By all means document 
the alternative but you should also be honest and also document how rare 
it is in comparison to the dominant method.


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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Hubert87]

In general, I agree with Martin.

Am 16.03.2019 um 23:43 schrieb Andrew Davidson:

On 15/3/19 9:30 pm, Martin Koppenhoefer wrote:

these tags are stating different things though:



How are they different? If I have a oneway=yes way:

A--->B

oneway:bicycle=no tells me that bicycles can pass along this way A->B 
and B->A

Correct.


exactly the same case if there is any of the tags:
cycleway:[left|right|both|none]:oneway=[-1|no]


No, not exactly the same: cycleway:[left|right|both|none]:oneway=no 
implies oneway:bicycle=no, but no vice versa.
cycleway:[left|right|both|none]:oneway=[-1] does not imply 
oneway:bicycle=no (maybe oneway:bicycle=no -1), since there could be 
edge cases, where a cyclist could use the cycleway to get for B to A, 
but has no option to go from A to B.





They tell me the same thing. The point of this discussion is what the 
*preferred* method should be not how many different ways there are to 
tag the same piece of information. My point is simply why should 
mappers be told to prefer the less used and less likely to be consumed 
option rather than the much more common option?



cycleway:left:oneway=-1 on the other hand is describing a dedicated 
cycling infrastructure 


No it doesn't.

Yes it does, in principle.
What infrastructure, if any, is provided for cyclists is described by 
the cycleway=* tag. So in this case if that tag is accompanied by:


cycleway:left=shared

then there is no dedicated cycling infrastructure.

I'm confused. Did you mean shared_lane? cycleway=shared has been 
relieved by segregated=no or it was assumed that cycleways are shared 
with pedestrians.
Any way, that only means that cycleway:left:oneway=-1 implies 
oneway:bicycle=no; again IF bicycle can go both ways. (otherwise it 
implies oneway:bicycle=no -1)
And amusing you did mean shared_lane, it is kind of the default, and 
usually requires some kind marking to make able to map it.



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

Re: [Tagging] Feature Proposal - RFC - police=*

[Martin Koppenhoefer]

sent from a phone

> On 16. Mar 2019, at 23:18, Joseph Eisenberg  
> wrote:
> 
> This shouldn’t be a problem for things like warehouses, non-public offices, 
> vehicle impound facilities etc. But it requires patience for police stations.


those vehicle facilities are places you have to go to in order to get your 
vehicle back, so they are public facing, but they aren’t police stations 

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

sent from a phone

> On 16. Mar 2019, at 23:43, Andrew Davidson  wrote:
> 
> So in this case if that tag is accompanied by:
> 
> cycleway:left=shared
> 
> then there is no dedicated cycling infrastructure


49 out of 65000. There are some thousand of shared_lane though. I didn’t know 
this tag, historically the cycleway tags were used for bicycle infrastructure, 
seems people are working to change this.

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Warin]

On 17/03/19 03:15, Martin Koppenhoefer wrote:





sent from a phone
On 16. Mar 2019, at 15:53, Jan S > wrote:


So you basically can't rely on OSM to find a police station in case 
of an emergency.



let us not overemphasize the emergency in this context. In an urgent 
emergency you would expect the police to come to you rather than the 
opposite.


If you are being assaulted, it is better to run towards the police 
rather than away.




I agree that we should have an amenity tag for police stations (this 
still means many of them would be closed after office times, for 
example in Germany), and that amenity=police was defined so since the 
beginning.
And it appears that other police facilities and non public operations 
also bear the tag.


We could try to migrate those other police amenities to 
amenity=police_facility


some would better be retagged as office, but if you want a tag which 
more reliably states “police station”, it looks like a new subtag e.g. 
police=station could work.


Why have amenity=police_facility where that too will have to have sub 
tags .. possibly more police=* values?


Why not simply accept the key police=* and be done with the intermediate 
step of amenity=police or amenity=police_facility or 
amenity=police_office ro amenity=police_garage etc... ?


There are already 22 of them ;-)
https://taginfo.openstreetmap.org/keys/police#values


Any if the key police=* how many will then become used?

Most common (the only significantly used) value for “police” is 
“traffic_police” (987 uses). This is a type of police, not a type of 
facility.


A 'type' of police in some police facility.


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

Re: [Tagging] Feature Proposal - RFC - police=*

[Graeme Fitzpatrick]

On Sun, 17 Mar 2019 at 09:36, Martin Koppenhoefer 
wrote:

> those vehicle facilities are places you have to go to in order to get your
> vehicle back, so they are public facing
>

But only by prior arrangement, or on certain days eg when there's an
auction of abandoned vehicles.

At all other times, they are not open to the public (or, at least, the ones
around here aren't!)

Thanks

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Warin]

On 17/03/19 11:43, Graeme Fitzpatrick wrote:


On Sun, 17 Mar 2019 at 09:36, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:


those vehicle facilities are places you have to go to in order to
get your vehicle back, so they are public facing


But only by prior arrangement, or on certain days eg when there's an 
auction of abandoned vehicles.


Martin is thinking of vehicles towed away from parking illegally, not 
abandoned vehicles.

They too may have hours of operation, but they are open frequently.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Graeme Fitzpatrick]

On Sun, 17 Mar 2019 at 11:49, Warin <61sundow...@gmail.com> wrote:

>
> Martin is thinking of vehicles towed away from parking illegally, not
> abandoned vehicles.
> They too may have hours of operation, but they are open frequently.
>

Depending on who's towed it, from where, why, that may also be the towies
yard, not a police yard.

Thanks

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 17/3/19 10:18 am, Hubert87 wrote:


No, not exactly the same: cycleway:[left|right|both|none]:oneway=no 
implies oneway:bicycle=no, but no vice versa.
cycleway:[left|right|both|none]:oneway=[-1] does not imply 

> oneway:bicycle=no (maybe oneway:bicycle=no -1)

Nice straw man you've made there. I didn't say that either of those 
forms of tagging imply the other. What I said was that both forms 
indicate that cyclists can ride in both directions and asked why should 
mappers be advised to use the more rare, less likely to be consumed, 
version when they both mean the same thing?


since there could be 
edge cases, where a cyclist could use the cycleway to get for B to A, 
but has no option to go from A to B.


Here is a crazy idea: how about oneway:bicycle=-1? Nice and simple, 
saves you from having to add tags that indicate bicycles can't travel in 
the forward direction, and may actually be noticed by data consumers who 
are likely to be also be looking for oneway:bicycle=no.


And amusing you did mean shared_lane, it is kind of the default, and 
usually requires some kind marking to make able to map it.




Nope. I mean cycleway=shared as defined on the wiki page (from late 2011 
onward, so I didn't think it was such a new and radical idea). In 
Australia the only difference between cycleway=shared and 
cycleway=shared_lane can be one of these signs:


https://www.alamy.com/cyclists-share-the-road-sign-australia-image224679530.html

maybe every 5 to 10 km. I feel so much safer now...

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 17/3/19 10:42 am, Martin Koppenhoefer wrote:



49 out of 65000. 


Not sure what I am supposed to do with this factoid. Maybe if I try and 
explain the problem in a form that you can't just look up on taginfo:


Let's say we have two keys: key_a and key_b. key_a can have a number of 
values:


value_1: which also implies the presence of an object of type O
value_2: which also implies the absence of an object of type O

and for both values of key_a there is also key_b which can have a number 
of values but let's assume that this is value_3 for both cases. So the 
logical problem is that both values of key_a map to the same value of 
key_b, making it is impossible to definitively state if an object of 
type O is present or not given only the fact that key_b=value_3.


There are some thousand of shared_lane though. I didn’t know this tag, 
historically the cycleway tags were used for bicycle infrastructure, 
seems people are working to change this.


I hadn't realised that shared was so new and radical. However if you 
want to make cycleway:[...]:oneway=-1 the recommended way to map these 
things then you are going to have to have a value for cycleway that will 
work to replace the existing tag cycleway=opposite. I suppose that an 
option would be to recommend that mappers don't use cycleway=opposite 
and just use oneway:bicycle=no instead.


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

Re: [Tagging] Feature Proposal Approved - boundary=aboriginal_lands

[Alan McConchie]

After a few months of discussion and refinement in the default OSM style sheet, 
and then a few more weeks of waiting for the styles to percolate to the 
rendering servers, we can now see aboriginal areas showing up on the map! 
Please take a moment to check the map in any parts of the world you're familiar 
with, to see if the aboriginal_lands and protect_class=24 features are showing 
up as we expect them to, or if there are any obvious ones missing.

Again, thanks to everyone who help get this tag discussed, approved, and 
finally added to the map!

Alan

> On Dec 13, 2018, at 4:20 PM, Alan McConchie  wrote:
> 
> The voting period for boundary=aboriginal_lands has now closed, and there 
> were 45 votes in favor and 7 against, so the tag has now been approved. 
> 
> I created the new wiki page for the tag here: 
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands
> 
> The map rendering still needs a bit of discussion about colors (to avoid 
> color conflict with the same brown used by zoos and theme parks) but this is 
> not the place for that conversation. The github issue remains open for debate 
> here: https://github.com/gravitystorm/openstreetmap-carto/issues/3520
> 
> So what's next? It now appears that "boundary=aboriginal_lands" is synonymous 
> with "boundary=protected_area" + "protect_class=24", and both tagging styles 
> have roughly similar usage in the database. I'm curious to see over time 
> whether mappers start to use "boundary=aboriginal_lands" more frequently, or 
> if people keep using both. Perhaps at some point in the future we can have a 
> discussion about whether to deprecate the "boundary=protected_area" + 
> "protect_class=24" approach, or if we should just keep supporting both 
> methods in simultaneously. But I'm not in a hurry to start that discussion 
> right now.
> 
> 
> Thanks to everyone who took part in this discussion and who voted on the 
> proposal!
> 
> Alan
> 
> 
>> On Nov 24, 2018, at 4:38 PM, Alan McConchie  wrote:
>> 
>> The tag boundary=aboriginal_lands has been discussed on-and-off for a long 
>> time in OSM. I'd like to raise the topic one last time and hopefully come to 
>> some consensus about it.
>> 
>> The tag proposal on the wiki dates from 2008, but the original proposal was 
>> from the user Sam Vekemans (username acrosscanadatrails) who is no longer 
>> participating in OpenStreetMap, as far as I can tell. He never moved the 
>> proposal to a vote, so the page has remained in the proposal state all this 
>> time.
>> 
>> Here's the proposal: 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands
>> 
>> (I've tried to updated the wiki page somewhat, but leaving the discussion 
>> intact)
>> 
>> In the following years, some people have started using that proposed tag, 
>> mostly in Canada and somewhat in the United States. 
>> 
>> Here's the overpass query for boundary=aboriginal_lands: 
>> http://overpass-turbo.eu/s/DV4
>> 
>> There has also been extensive discussion over the years on the 
>> boundary=aboriginal_lands page, and it seems like the consensus is that the 
>> tag is necessary and better than any alternatives. But it was never voted on 
>> as a proposal.
>> 
>> In the intervening years, tagging native reservations with 
>> boundary=protected_area + protect_class=24 has also gained popularity. This 
>> tag combination seems to be popular in South America, Australia, and also in 
>> parts of the United States. I can't find any evidence for why people chose 
>> this tag combination instead of boundary=aboriginal_lands. It appears that 
>> the tags are pretty much interchangeable. Most of the features in Brazil 
>> however are tagged incorrectly for the renderer, mixing 
>> leisure=nature_reserve with protect_class=24, so that the areas show up on 
>> the default renderer with the nature reserve green style.
>> 
>> Here's the overpass query for protect_class=24: 
>> http://overpass-turbo.eu/s/DV5
>> 
>> Wiki page for boundary=protected_area: 
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
>> 
>> In 2014, there were three messages on the tagging mailing list, from Paul 
>> Johnson and Clifford Snow. 
>> https://lists.openstreetmap.org/pipermail/tagging/2014-November/020160.html 
>> But at that time, we didn't come any answers.
>> 
>> There seems to be no argument about whether or not aboriginal areas are 
>> important features that should be mapped. The only question is how to tag 
>> them.
>> 
>> So the question is:
>> 
>> Should we use the single tag boundary=aboriginal_lands for these areas? Or 
>> should we deprecate that tag (in other words, reject the proposal) and 
>> instead use boundary=protected_area + protect_class=24?
>> 
>> 
>> I'd like to officially open the voting period now, so we can once and for 
>> all come to a conclusion on this 10-year-long discussion. Please review the 
>> discussion on the wiki page and cast your vote at the bottom: 
>> 
>> https://w

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Graeme Fitzpatrick]

On Sun, 17 Mar 2019 at 13:21, Andrew Davidson  wrote:

> In Australia the only difference between cycleway=shared and
> cycleway=shared_lane can be one of these signs:
>

Or even
https://www.google.com/maps/@-28.0766007,153.4447888,3a,20.7y,49.91h,89.96t/data=!3m6!1e1!3m4!1s3dPlQ9YxNBm-7lRm4GOUPg!2e0!7i13312!8i6656

& back another 30 m's or so

https://www.google.com/maps/@-28.0767024,153.296,3a,27.3y,57.48h,86.03t/data=!3m6!1e1!3m4!1sj4MRicAAxp4hNWeZbBs-zg!2e0!7i13312!8i6656

Did somebody say something about marking lanes by the way!

Thanks

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