Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Tobias Wrede]

Am 20.03.2020 um 16:38 schrieb Paul Allen:
On Fri, 20 Mar 2020 at 13:50, Tobias Wrede <mailto:l...@tobias-wrede.de>> wrote:



I don't get your point here. Either someone wanted a package
delivered to his residence. In that case they gave the wrong
address information to the delivery guys.

Around here, the delivery guys get it wrong even when they have the full
address and no PO boxes involved.  The problem comes when the package
is addressed to the PO box and then the delivery guys do the "last mile"
getting it from the PO Box to the physical location, and get that wrong.

It seems I have a different understanding of the concept PO box. Around 
here if you have a PO box mail is delivered there and you go yourself 
pick it up, convenient for people who are rarely at home or get huge 
amounts of mail. In more rural areas I have seen letter boxes in one 
central point of a several km2 area or a box/bag at the next major road 
where mail is delivered to. Again you go there yourself to pick it up.


I must admit I fail to understand your kind of PO box. One delivery 
company delivers to the PO box (which address/location is known) and 
then some other guys pick the mail up there and take it to your home 
which they don't know anything about? Sounds strange to me.


Regardless of type of address shouldn't a shipment not always have the 
receiver's name on, too?




But as long as we tag phone numbers, websites, fax numbers etc. I
cannot see why we should discourage it, either.

If we're just mapping things that a paper map shows, we wouldn't map 
post/zip
codes either.  In some cases this other information, even PO Box, is 
useful,

so people WILL map it.  It's better we come up with a way of doing it than
have all those people come up with their own way.

I don't say we should do as a paper map creator does. I see why we map 
phone numbers: I am  in an unfamiliar area, look for a restaurant on the 
map, find one and then call ahead to see if they can accommodate me. If 
it's the day before I might look up the email address and drop them an 
email. But I see really rare cases where I would find a business on a 
map and then send a letter or parcel there. But as I said I'm fine with 
people tagging delivery a addresses deviating from physical addresses if 
they want to. I just should go in the contact name space in my opinion.


Tobias

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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Tobias Wrede]

Hi,

Am 20.03.2020 um 12:30 schrieb Paul Allen:


One of the parcel
delivery companies noted for delivering to the wrong
address (Hermes and DHL, I'm looking at you) has
dumped a package outside my door.  The address is
PO Box 123.  Which of the houses near me has that
mailing address?

I don't get your point here. Either someone wanted a package delivered 
to his residence. In that case they gave the wrong address information 
to the delivery guys. Should have given them a street/number or whatever 
is needed in your area to find the place. Or they wanted to have the 
package delivered to their PO Box, then the address information needs to 
be tagged to the post office where the PO Box is located and they need 
to chose a delivery company able to deliver to PO boxes.


(sorry for reordering)


So is PO box, etc. useful?  Yep.


I personally cannot really see a usecase. But as long as we tag phone 
numbers, websites, fax numbers etc. I cannot see why we should 
discourage it, either.


Tobias


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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Tobias Wrede]

Hi Warin.

Isn't the addr:* scheme used to describe the physical address of a 
location/building/amentiy/etc.?


PO Boxes, privat bags etc. are addresses where mail for someone residing 
at said location is delivered to.


As addr:* I would always put in what is needed to find the place as a 
visitor and that is a housenumbet and street, a house name or any other 
place name. And sometimes there might be nothing besides city or postcode.


Mail delivery address I would expect to find under the contact:* scheme 
if at all.


Tobias



While there are methods of entering street addresses there don't appear
to be any way to enter addresses that use Post Office Boxes and other
delivery types.

There is a proposal to may the existence of PO Boxes but no way to enter the
address data for those that use them.

As well as PO Boxes there exits several types of delivery methods in
Australia, below are listed all of the officially accepted types with their
officially accepted abbreviations.

Care of Post Office  CARE PO

Community Mail Agent.  CMA

Community Mail Bag CMB

Community Postal Agent  CPA

General Post Office Box GPO BOX

Locked Bag LOCKED BAG

Mail Service MS

Post Office Box PO BOX

Roadside Delivery  RSD

Roadside Mail Box/Bag  RMB

Roadside Mail Service  RMS

Private Bag  PRIVATE BAG

These all appear in the same placement of the addressed article. Perhaps
a new tag addr:delivery_type=* could be used?

Examples>

Mr Smith

PRIVATE BAG 32

Tennant Creek

Northern Territory  0862

addr:delivery_type=PRIVATE BAG 32

Mr Jones

GPO BOX 3

Sydney

NSW 2000

addr:delivery_type=GPO BOX 3

In these cases there is no house number, street. There are still
city/state/country and postal codes.

--

References?

https://en.wikipedia.org/wiki/Roadside_Mail_Box

https://www.staff.uwa.edu.au/facilities/mail/formats

https://meteor.aihw.gov.au/content/index.phtml/itemId/430096

https://www.barklyhomestead.com.au/  -'contact us' they use PMB for
Private Mail Bag.




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

Re: [Tagging] Whispering asphalt

[Tobias Wrede]

Am 02.05.2019 um 23:23 schrieb Yuri Astrakhan:
I don't think we should do asphalt classification -- too difficult for 
many cases, and very little value, especially in this case because it 
is not the "type" of asphalt, it is rather a "feature" of asphalt. 
Multiple features could exist in the same asphalt - e.g. it could have 
noise-canceling qualities, or it could have under-surface charging, or 
it could have solar panels integrated into it, or it could have high 
melting point so it works well under sun.


In other words, I think it should be a yes flag, something like  
noise_reducing_surface=yes


I would question to use any qualification at all. Whatever is now called 
a quiet/whispering/noise reducing asphalt will have become a standard in 
a couple of years and then a new type even more noise reducing will have 
been invented. Will we then have 
noise_reducing_surface=no|little|yes|yes_yes|definitely_yes?


If someone cannot resist I would second Yuri's suggestion.

Tobias


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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Tobias Wrede]

Am 30.04.2019 um 20:18 schrieb s8evq:

- bidirectional=no
- signed_oneway=yes
- signed_direction=yes
- designated_direction=forward|both|backward
- signed=forward|backward|both|none

Personally, I like signed_direction=yes. It's simple and avoids using the word 
oneway.
Also, using the value forward|backward might not be necessary, as it's possible 
to deduce this from the order of ways in the relation.

signed_direction=yes is not intuitive in my opinion. Mappers might apply 
it ("yes, there is a signed direction") but might forget to put the 
members in the right order. Having a forward|backward|both|none in there 
might make it more obvious to take care to apply the tag correctly.


Tobias


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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Tobias Wrede]

Am 30.04.2019 um 21:05 schrieb Kevin Kenny:

On Tue, Apr 30, 2019 at 2:19 PM s8evq  wrote:

Personally, I like signed_direction=yes. It's simple and avoids using the word 
oneway.
Also, using the value forward|backward might not be necessary, as it's possible 
to deduce this from the order of ways in the relation.

The forward/backward direction cannot be deduced from the order of the
ways if the relation contains fewer than three ways.



Do you suggest to stick with (counter)clockwise then?

Is there really a use case? How many circular routes are made up of only 
one or two ways? I suppose one could add the information to the ways 
then in that special case.


The counter(clockwise) designation doesn't work well in cases of 
touching or crossing ways (figure 8 shaped trails for example) or when 
alternative routes are included in the relation.


Tobias


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

Re: [Tagging] RFC - Connectivity

[Tobias Wrede]

Leif, there already is a similar proposal: 
https://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes
It has never left draft status but it has been used by some mappers. 
There even is a JOSM plugin to create such relations.


Tobi

Am 23.04.2019 um 16:32 schrieb Simon Poole:


Be prepared for everybody to jump on you, because: 
https://wiki.openstreetmap.org/wiki/Proposed_features/transit


Am 22.04.2019 um 17:55 schrieb Leif Rasmussen:

Hi everyone!
I have recently been mapping a lot of turn:lanes information on 
highways in my area, but ran into the issue that turn:lanes fails to 
store all of the necessary information in many junctions.  Multi-lane 
roundabouts, single point urban interchanges, 5 way intersections 
with divided roads, and other cases are all too complex for 
turn:lanes to handle.


Because of this, I have created a proposal for a simple type of 
from-via-to relation that would provide information about how lanes 
in the "from" way connect to those in the "to" way at any point where 
it isn't clear.  These relations are very similar to turn 
restrictions, and like turn restrictions, wont be needed in most 
intersections.


The relation would also be able to store the same information as 
could have been possible with transit:lanes, just without the many 
maintenance issues that came that system.



https://wiki.osm.org/wiki/Proposed_features/Connectivity


All feedback on how to potentially improve the proposal would be 
highly appreciated!


Thanks,
Leif Rasmussen

___
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 - Camp_site=camp_pitch

[Tobias Wrede]

Am 17.04.2019 um 13:32 schrieb marc marc:

Le 17.04.19 à 11:34, Sven Geggus a écrit :

tourism=camp_site
camp_site=camp_pitch

which would make sense, as single pitch camp-sites_do_  exist.

indeed, but a parking with one place, is not mapped as amenity=parking
parking=parking_space


Actually, your example Sven makes perfect sense exactly in the case 
where the camp site consists of one camp pitch. That's the usual 
interpretation of tags following the scheme A=B, B=C, e. g. 
tourism=information + information=board: an information board, 
highway=crossing + crossing=uncontrolled: an uncontrolled crossing, 
tourism=museum + museum=history: a history museum.


So under tourism=camp_site + camp_site=camp_pitch I would expect a (one) 
camp pitch camp site.


On the other hand parts of bigger things are often mapped by repeating 
the main tag, e. g. (copied from Marc):


a part of the amenity=parking is amenity=parking_space
a part of a leisure=sports_centre is leisure=pitch [...]

So why not tourism=camp_pitch within tourism=camp_site by the same logic?

Tobi

 



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

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

[Tobias Wrede]

Hi,

I follow Martin's reasoning that camp_site=camp_pitch more looks like it 
being a specification of camp_site rather than describing a feature 
within. Following Marc's examples (parking and sports centre) 
tourism=camp_pitch (following tourism=camp_site and 
tourism=caravan_site) would be my preferred choice. Even more so, as it 
wouldn't look as if a camp_pitch could not be used within a caravan_site.


On the other hand I have used camp_site=camp_pitch before myself and I 
am unsure if retagging these x'000 existing occurrences would make sense.


Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 18.02.2019 um 00:48 schrieb Dave F via Tagging:
As already stated, sidewalk is to indicate a physical object. Sidewalk 
has no legal implications. 'Foot' is used purely to indicate legality.


So? I don't think this is disputed.

The reasoning here is that the absence of a sidewalk in some situations 
goes along with a foot=no signage. Think of a motorized-traffic only 
overpass. So now if StreetComplete finds a situation with sidewalk=no 
and no foot=* tagged it merely asks if that is a situation where the 
original mapper forgot to put the access=no on the road or not.


Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 17.02.2019 um 17:45 schrieb Martin Koppenhoefer:
this is oversimplified, you are indeed legally required to walk on the 
road even in the presence of sidewalks: if carrying big loads.


Sure there are exceptions to every rule. We usually don't map that.

When there is no signage, foot=no is incorrect and will not represent 
the situation on the ground.
I don't agree. There are various cases where legal situation is not 
defined by signage.
If nobody should ever walk in that underpass, authorities should put a 
sign to prevent them, come on, it’s Germany,  in Italy they do it:

https://www.google.com/maps/@41.9072106,12.5050822,0a,75y,340.46h,91.26t/data=!3m4!1e1!3m2!1sdU0xMXx0zp9JjpMHB24tOQ!2e0

You of all should no how much more regulated Italy is in many aspects 
compared to Germany.
Nobody sane would anyway walk into a traffic tunnel without pedestrian 
spaces, regardless of the instructions your navigation device issues ;-)


Exactly, but how should the router know that? And not everyone listening 
to navigation instructions is able to assess the complete situation or 
find alternatives.


Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 15.02.2019 um 17:09 schrieb Hubert87:


why not use foot=use_sidepath and/or sidewalk=no? In combination with 
hw=primary/secondary, routers should be able to work out that that 
route is a bad one.


Well, not all foot=no roads do have a sidepath. And anyway this 
discussion is on whether the sidewalk=none and absence of a foot=* 
warrants asking the user for it.


Also OT the city should declare that tunnel a motorroad, or put up 
signs disallowing pedestrians and bicycle riders (and horses), like 
opposite direction 
 
of your first example.


Also people using routers should apply common sense, too. Or stay at home.

Well, tell that the city. I could list you any number of cases in my 
city where the officials have not signed everything we would like it in 
OSM. We also need to apply common sense when mapping.


Tobias W



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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 17.02.2019 um 20:44 schrieb Andy Townsend:

I don't think that a "global" encouragement to add foot=no makes sense; 
there'll be lots of countries where it'd be silly.

I don't think the app "encourages" anything. In this quest the app 
merely speculates that the sidewalk=none could maybe warrant a foot=no 
and asks the user if that is the case.


As others and I have pointed out this speculation is not so ill-founded 
for some situations (e. g. bridges, tunnels) but overdoes it for the 
standard roads out there.


Tobias W


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 17.02.2019 um 21:57 schrieb Dave F via Tagging:
I should have been clearer. I was indicating a case where foot=no 
would be appropriate, but I should have stated there are also cases 
where 'yes' or 'designated' are required. I'm still unsure why Tobias 
W. thinks tracks shouldn't be queried at all yet residential roads 
should.


Don't misunderstand - I'm not advocating the use of the app. I'm 
dubious about it's quality if Tobias Z. can spend "3+ years" 
developing it, yet not read the wiki. This query should be retitled to 
something like 'do pedestrians have legal access to this street?' 
Hopefully that would deter users from adding either yes or no when 
they're unsure which it is or even if it required at all.


Cheers
DaveF

On 17/02/2019 19:44, Mark Wagner wrote:

Tracks are often "access=private" for everyone, so there's no reason to
call out foot access in particular.

We are discussing a quest whose basis is the speculation that a 
sidewalk=none could also warrant a foot=no. I was thinking about how 
likely that is in different situations. And I think it is very unlikely 
for tracks. I don't think I have ever seen a track with a sidewalk so 
not having a sidewalk is pretty meaningless in regards to  being a 
candidate for this quest.


Tobias W-


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 15.02.2019 um 11:54 schrieb Rory McCann:

On 14/02/2019 19:51, Tobias Zwick wrote:

> Let's be pragmatic: We don't tag things just because and also do not
> live in clouds. So, why do we tag access restrictions at all? -

(IMO) To record the *legal* restrictions. 

> To be of use for routing and other use cases where it is relevant
> whether something is accessible or not, simple as that.
> The reason for it being (not) accessible is secondary


Unfortunately, the legal situation is not always as clear as we wish to. 
There are a lot of grey zones and we need to apply common sense when 
tagging the access rules.


Here are a few situations where I would not hesitate to put a foot=no on 
the road even if there is no corresponding traffic sign.


Pedestrians can take the level footpaths/sidewalks instead taking the 
underpass: 
https://www.openstreetmap.org/way/6187386#map=18/50.94224/6.95277. There 
is no signage forbidding foot traffic. 
(https://www.google.de/maps/@50.978,6.9530483,3a,60y,190.35h,87.27t/data=!3m6!1e1!3m4!1sQMNheDoeod1aqNAV9jAkzQ!2e0!7i13312!8i6656)


Tobias' example: One big crossing. Pedestrians ought to take the foot 
ways on the perimeter: 
https://www.openstreetmap.org/way/188015318#map=19/53.54798/10.00603 
(https://www.google.de/maps/place/Deichtorpl.,+Hamburg/@53.546,10.0054334,194a,35y,39.47t/data=!3m1!1e3!4m5!3m4!1s0x47b18ee36713d14d:0x9845bddee686!8m2!3d53.5477326!4d10.0057289)


Pedestrians ought to take the bridge here. There are no traffic lights 
for pedestrians but there is no signage either forbidding pedestrians: 
https://www.openstreetmap.org/way/258669865#map=19/51.03936/7.05248


By German law you are required to use footpaths if they exists on the 
road. In these examples there are no footpaths on the roads so you 
should be able to use the carriageways. But is that what the planners 
intended and would it make sense at all?


I am with you regarding cases where some mappers might just tag a road 
foot=no if they feel it is too dangerous for the pedestrians or too 
unnerving for the car drivers and where there is no real designated 
alternative. We shouldn't do that.


Tobias




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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 15.02.2019 um 12:35 schrieb Tobias Zwick:

So, while a tag to denote that a road is rural does not exist (yet), I could 
filter out uninteresting roads using tell-tale tags.

So, I could further filter out roads with..

- lit != yes (so, also if lit is not set) to exclude most of the 
rural/undeveloped roads. For UK, it is not even tell-tale

- motorway, motorroad anyway

- any but paved roads

- perhaps even only oneway roads?? (asking for input here) Because the cases I 
mentioned are in the majority oneway-lanes

- perhaps also only ask for a sidewalk in the first place if the road is tagged 
as lit=yes? Asking for input.

Tobias

So I just posted another mail at the same time you did. As far as I am 
concerned roads that are most likely to merit a foot=no are


- all highway road types except tracks and except where foot=no is 
regionally implied


- where there is no sidewalk

any that have one of:
- bridge=yes
- tunnel=yes
- ford=yes
- oneway=yes
- bicycle=no/private/...
- bicycle_road=yes (?) Not sure if there are countries where a 
bicycle_road would forbit foot traffic in absence of sidewalks


you could also exclude highways that are part of a hiking route (might 
be difficult with relations and might overdo it).


lit=* is to fuzzy in my opinion to be useful.

Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 14.02.2019 um 23:32 schrieb Tobias Zwick:

Agreed. I don't see much of a difference between residential and higher
class roads. I would even argue that around here a sidewalk=no + foot=no
is even less likely on higher class roads than on residentials.

How so?


Think of all the residential roads in cities that get a higher class 
tagging because of their function in the road network. They are mostly 
not different from hw=residential in regards to foot=y/n. And also the 
many roads outside built-up areas have mostly no restrictions. Roads 
with separate foot/cycle ways or with sidewalks are the clear minority 
and still are often the only means of traveling by foot. The majority of 
unclassified, tertiary etc. roads is very unlikely to have a foot 
limitation.



I have the impression, we (all) have different kinds of road in
mind, when arguing whether or not an explicit foot=yes/no is reasonable
or not.
I have these kind of road (sections) in mind that I already mentioned:
underpasses, tunnels, bridges, but also (large) intersections,
roundabouts, links between roads and any other occurances where in OSM,
multiple ways are drawn even though in reality, it is just one road.
So, what kind of roads do you have in mind?

I see the problem for those roads and that's why I repeatedly suggested 
to find a narrower filter that indicates a likelihood to be foot=no, 
like tunnel=yes, bridge=yes or oneway=yes. I don't see the highway tag 
as a suitable filter at all.


Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 14.02.2019 um 22:10 schrieb Volker Schmidt:
I am sorry, this is not the correct approach. We have here plenty of 
streets in other categories (unclassified|teritery|secondary|primary) 
without sidewalk where it is perfectly legal for pedestrians to use 
the road. This does not say whether it's safe to walk on them. If 
people now start putting foot=no because they want to prevent people 
from walking on the these roads because it's unsafe, then we create a 
nice mess. You should map the deviation from the default (foot=no), 
not confirm a default (foot=yes).


Agreed. I don't see much of a difference between residential and higher 
class roads. I would even argue that around here a sidewalk=no + foot=no 
is even less likely on higher class roads than on residentials.



On Thu, 14 Feb 2019 at 21:50, Tobias Zwick > wrote:


No, I didn't. I explained the quest here:
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042860.html

In a nutshell: foot=yes/no is only asked if sidewalk=no is tagged.


ok. I somehow mixed that up.


Tobias

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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 14.02.2019 um 21:28 schrieb Kevin Kenny:

On Thu, Feb 14, 2019 at 3:13 PM Tobias Wrede  wrote:

Still, they are the very minority of situations where a residential (or
any other road) has no sidewalk.

Local cultural assumptions are in play here!

In my (suburban) township, few residential roads have sidewalks, so
the ones without sidewalks are hardly in the minority. People walk on
the ones without sidewalks all the time - about half my daily walk to
and from work is on sidewalk-less roads (and the other half is on a
shared cycleway).


I probably was a bit unclear. I meant to say that for situations where a 
residential has not sidewalk the cases with foot=no are in the minority 
and foot=yes are the majority.



But I think we're in "violent agreement" that the default of foot=yes
for highway=residential is sensible, and that tagging something that's
the default already is nearly worthless.


Yes, agreed.

Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 14.02.2019 um 20:50 schrieb Tobias Zwick:

Alright, I will change it so that the question whether a road is
accessible for pedestrians is never asked for residential roads (and
living streets, service roads, pedestrians roads) for v10.1

I think you lost me. Didn't you explain in the beginning that this quest 
was asked for residentials only anyway? What will remain then?


You could modify so that the question is asked only for bridges, tunnels 
or where bicycle=no exists and where there is no sidewalk.


Tobias


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Wrede]

Am 14.02.2019 um 19:51 schrieb Tobias Zwick:

This is, by the way, a bit of a different topic now, because the thread
was originally about tagging foot=yes on residential, not whether
foot=yes/no is limited to a *legal* access restriction. Anyway:

I doubt access restrictions are used that way in reality.


In my experience they are mostly. Granted, the legal interpretation 
might be stretched a bit sometimes.



Same with Germany/UK. Some posters mentioned, that on any road without a
sidewalk and without an explicit access restriction for pedestrians,
pedestrians are allowed. Okay, that is new to me, but if this is true,
then this is also a case where the law (massively) diverges from the
actual reality on the ground. I am sure the police would find something
else to charge you with when you take a walk on for example this busy
intersection https://www.openstreetmap.org/way/188015324 , like,
hindrance of traffic. Note that the road authority also did not bother
to put any signs there [*]
(Google Streetview:
https://www.google.de/maps/@53.5483485,10.0055799,3a,73y,176.82h,81.92t/data=!3m6!1e1!3m4!1sBSZx5A6MNVRKd0qN6MIanQ!2e0!7i13312!8i6656
)

Incidentally, that section is also tagged with foot=no.


Well, IANAL but I guess this whole intersection gordian knot could be 
interpreted as being one street and pedestrians are still rquired by 
German law to use the circumferencing footways and not the several 
carriageways.



I have no statistics up my sleeve, but I firmly believe that this is no
exception, because, common sense.


I'm with you here regarding the tunnels. Around here I have seen "no 
pedestrians" signs at tunnel entrances, there are non around your 
example street. So while legally it might be ok to walk there I would 
also tend to foot=no them.




[*] And exactly these situations were the ones I had in mind when
designing the discussed quest for StreetComplete, by the way.


Still, they are the very minority of situations where a residential (or 
any other road) has no sidewalk. In my view the negative impact of the 
many, many foot=yes set by the quest outweighs the benefit of finding 
the few exceptions to the rule. As suggested somewhere else maybe you 
should try to limit the quest to bridges, tunnels or where there is 
already a bicycle=no.





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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 18.01.2019 um 09:48 schrieb Marc Gemis:

So limiting it to named trails would be an option, however, the
tourist agencies seem to replace all such named walks with walking
node networks, so "trails" are now everywhere.
This means that you can start almost anywhere on a signposted walk.
Just take a look at
https://hiking.waymarkedtrails.org/#?map=9!50.9966!4.9715 and see how
fine mazed the orange networks are in Flanders and The Netherlands.
Note that not all network routes are mapped in Flanders yet and they
also rolled out a virtual network, which is no longer marked along the
way, but for which you need an app or GPS. So some holes will have to
be filled on the waymarkedtrails map.

So I wonder whether we should map all trial x road junctions as
trailheads or limit them to places with more facilities (just to be
clear, locally, in Flanders). I don't know.


I see your point. I had forgotten about node networks. While I haven't 
really seen any for hiking yet personally, they are also growing here 
for the cycling network. And of course they are mapped as route 
relations. I'm not sure if I should reconsider my earlier suggestion to 
put trailheads on anything in a route relation or not. While you clearly 
also have to enter a node network somewhere I see them more as a general 
navigation aid than a "trail". Whenever I use them I start from home or 
wherever I am, find my way to the closest node in the general direction 
and take it from there. I don't go to that node by car or bus first. 
It's probable that I already enter the network somewhere inbetween two 
nodes.


So I wouldn't consider every node as a trailhead. And i would not put a 
trailhead on every intersection of a road and a network leg. If there 
was a somehow designated or customary place, though, where you would 
start hiking/cycling on the node network that could be marked as a 
trailhead with the same rights as on a "classical trail".


Does that make sense?

Tobi


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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 17.01.2019 um 08:32 schrieb Marc Gemis:

A trailhead is the start of a trail, but I haven't seen the definition
of a trail yet.

An American trail seems like a long distance walking route in the
wilderness. It's probably the same in Australia, Is that
interpretation correct ? Is that a requirement for a trail ? If so,
you will be disappointed by what there trails are behind the
trailheads in The Netherlands (or Belgium).


From my European view I would exclude the wilderness bit. A lot of 
marked trails here path trough built-up area. There are even specific 
trails mostly through very urban area. I would say a trail is anything 
that would qualify for a route=hiking/bicycle/mtb/horse (possibly ski, 
snowmobile, inline_skates,... , I've never dealt with the latter ones).


I would also encourage including the trailhead in the respective route 
relation(s) with role=trailhead.


Tobias


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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 11.01.2019 um 18:15 schrieb Andy Townsend:

On 11/01/2019 17:05, Peter Elderson wrote:

 The Trans-Pennine Trail trailhead is a trailhead


No - it really isn't.  That was my entire point.  I'm willing to bet a 
small round of beer in the pub up the road that almost no-one walking 
past that info board will say "oh look - that's a trailhead for the TPT".


I wouldn't agree here. Even if your pub patrons wouldn't call it a 
trailhead it is one. The TPT purposely makes  a detour to the South to 
meet Chesterfield station. 
(https://www.google.com/maps/d/embed?mid=1u1vrqls0lVh49X3ZpT7Bh2728Q8=53.244018099803014%2C-1.4135915937870323=15 
Isn't the trail mapped in OSM?) It might not have a big signpost "here 
be trails" but it meets the consensus definition of a trailhead, namely 
giving easy access to a trail. On top it even has an information board, 
parking, rail station, toilets in the station, pub up the road, ... It's 
quite a posh trailhead actually ( :-) to use some other participant's 
words here).


The position of the new board you mapped is not the trailhead, though. 
I'm with you that far.


The problem with trying to shoe-horn other features into a particular 
definition is that it dilutes the value of the features with that tag 
that have already been mapped - in this case trailheads where 
"everyone" will agree that they are trailheads.



+1

That's not to say that the features that you're trying to record 
aren't very important - I'm sure that they are, and it would make 
total sense for a Dutch-focused transport, cycling or 
wanderroute-oriented map to show them. 

Absolutely.

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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 11.01.2019 um 15:45 schrieb Kevin Kenny:


Despite your repeated denials, you're continuing to try to invent a 
set of definitions that, at least in NL, will encompass all TOPs and 
nothing else. If that's your aim, then invent a tag for TOP and use it,


That's a good summary I can second. Peter, there are probably a lot of 
TOPs that are trailheads or where a trailhead is part of them. But there 
are other TOPs that are not trailheads in the spirit of the original 
proposal (to my understanding) nor the consensus that has been come up 
in this discussion. I pointed out a couple of the latter earlier (I did 
not search for those explicitly they were the first ones that I randomly 
selected from an overpass turbo query).


I also still stand by my earlier suggestion: Mark the trailheads as such 
(preferably as a point on a path/track/etc.) with hw=trailhead. Mark the 
TOPs with a separate node or in some cases better even area and a new 
key/value pair designating it as such. Several suggestions have been 
made in this thread (tourism=, leisure=, designation=, ...). If you 
must, use the same node for hw=trailhead and whatever=TOPorWhatNot but I 
would advise against that.




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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 03.01.2019 um 00:57 schrieb Peter Elderson:


About the use of referencing tags. I agree this is not yet the best 
result. Wikipedia links to the dutch page for TOP's (as they are 
called here), I think that is correct. url links to a site which lists 
all the official dutch trailheads. website links to the recreational 
publishing sites of different official operators. Each province has 
its own operator (and trailhead style).  Some of those have a web page 
for each trailhead, others have a simple list, others an interactive 
map or search function... and they reorganise quite often. Permalinks? 
What? Never heard of...) so we don't link deep but refer to a 
list/search/map/filter page.




Op wo 2 jan. 2019 om 23:43 schreef Tobias Wrede <mailto:l...@tobias-wrede.de>>:



As a side note: Looking at the examples I found that you added
keys like
wikipedia=nl:Toeristisch Overstappunt
url=https://gpsfietsroutesnederland.nl/toeristische-overstappunten/
website=https://www.natuurpoorten.nl/

<https://gpsfietsroutesnederland.nl/toeristische-overstappunten/website=https://www.natuurpoorten.nl/>

These are all generic references that could be added to the OSM wiki
page. On the individual trailheads I would expect a website of the
specific trail.

Would you add https://www.government.nl/topics/primary-education to all 
amenity=school in the Netherlands? Or 
wikipiedia=nl:Lijst_van_hogeronderwijsinstellingen_in_Nederland for all 
amenity=university? Or wikipedia=nl:Lijst_van_rivieren_in_Nederland to 
all the rivers? Or even wikipedia=nl:Rivier?


I think the Wikipedia and website links should be very specific to the 
individual object and not replace a dictionary.


Tobias

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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 05.01.2019 um 20:57 schrieb Peter Elderson:

I can see your argument.

First question: what's the harm in combining highway=trailhead and 
tourism=information? Note: I'm not asking this defensively or to 
advocate it, just want to understand where the problem lies.


First of all I think this mixes two distinct features into one as I 
described before: 1) the actual trail access, i. e. a point on the trail 
or a highway section leading to it and 2) the information infrastructure 
(information board, stele, you name it).




Op za 5 jan. 2019 om 12:23 schreef Tobias Wrede <mailto:l...@tobias-wrede.de>>:


I think the thought of the  old proposal was to mark the point on
a trail where to access it, hence hw=. Peter was more going in the
direction of marking the point where we find information on how to
access the trail (name, information board, sign, stele, ...),
hence tourism=information + information=.

I think we should stick to the good old OSM rule "one feature - one OSM 
element" 
(https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element). 
Obviously, the highway access and the information can be very close by, 
but pointing again at the TOP examples I mentioned before it's not 
always the case. So I am really in favor in separating them.


Secondly, combining those makes it difficult for data consumers. Unless 
they explicitly search for the combination of highway=trailhead and 
tourism=information and treating the node separately, they might run 
into problems. A renderer could for example display all information 
boards on the map. But they might handle all highway elements before in 
their processing chain and hence ignore the second top level key tourism 
all together. In the end we would neither see the highway=trailhead nor 
the information=board on the map.


Tobias

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

Re: [Tagging] Trail register

[Tobias Wrede]

Am 05.01.2019 um 08:24 schrieb Warin:

On 05/01/19 14:02, Graeme Fitzpatrick wrote:


On Sat, 5 Jan 2019 at 07:23, Jmapb > wrote:


On 1/4/2019 4:10 PM, Kevin Kenny wrote:

> Has anyone here tagged anything similar to the case I have in
mind of,
> "you must sign in/sign out/record your passage, and here's
where you
> do it?"

Personally I'd be inclined to ignore the legal thou-shalt-sign-in
aspects here and simply tag the register because it's a good
landmark.
Probably just "man_made=trail_register", keep it simple and
unambiguous.


We have a similar'ish set-up where you sometimes have to pay to take 
your car into various National Parks :-(


Err no that is a different thing entirely.
A trail register is to indicate your intention to start a walk or when 
completed that you have finished a walk. You give personal details - 
who you are, the date, when you expect to finish, possibly even ICE 
details (In Case of Emergency).


What Graeme is talking about is an entrance fee.
Similar to a car park where you have to pay at some place. 
man_made=payment_point? And link it using a site relation?


I agree. While both require you to register the intention and 
consequences are very different. Friend of mine who were canoeing on the 
Yukon many years ago told me they were required to register with the 
local police or ranger stations (don't remember exactly). So the 
register could also be an office not merely a book in a box. As such I 
also suggest to separate it from the tourism=register. I have never 
heard of registers in Kevin's sense in Austria so I am pretty sure they 
are the "I was here" type. They are pretty common there, often having 
stamps inside for you later getting a certificate showing up with a 
fully stamped booklet at the tourism office.


I would make up something new. Graem's suggestion is as good as any.

Tobias

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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 03.01.2019 um 00:57 schrieb Peter Elderson:
Thanks for the comments. Please understand that the mentioned proposal 
is not my proposal.


You were referring to it and in my opinion you tried to tweak it a bit 
too much for your purposes. But let's continue this on the other 
sub-thread. :-)




To see the trails starting at one of these places you best look at 
Nederland on waymarkedtrails. They all have multiple hiking/foot 
routes and walking routes to hop on, and most support other modalities.


I had looked at a few examples also on waymarkedtrails and often found 
no real trails nearby. e.g.:


https://www.openstreetmap.org/node/6141092007#map=16/52.3836/5.6325
https://hiking.waymarkedtrails.org/#routelist?map=16!52.3836!5.6325

or

https://www.openstreetmap.org/node/6141092027/#map=15/51.4414/5.8639
https://hiking.waymarkedtrails.org/#routelist?map=15!51.4414!5.8648 
(knooppuntennetwerk close by but not a named trail)


The latter TOP is named "Natuurpoort De Peel". So I was wondering are 
these realy trailheads (in the sense of you can access some or several 
trails here) or are these just designated general recreation spots?


Tobias

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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 04.01.2019 um 18:18 schrieb Peter Elderson:

Let's agree to agree!

Op vr 4 jan. 2019 om 16:52 schreef Kevin Kenny 
mailto:kevin.b.ke...@gmail.com>>:


On Fri, Jan 4, 2019 at 8:30 AM Peter Elderson mailto:pelder...@gmail.com>> wrote:
> I'm trying to go for the minimal tagging that supports the most
of the use cases. Which is a node tagged highway=trailhead. It's
up to mappers / communities if and how they will apply and embed
that according to local, regional or country-specific needs or
definitions. Or maybe decide it's not useful in that situation at all.

If the definition is "a designated or customary place where a trip on
a trail begins or ends," I'm entirely on board.

I'm perfectly fine with this. Now an open question is still where to 
place this tag and how to combine it. The stalled hw=trailhead proposal 
specifically suggests to place a trailhead node alone or on a piece of 
highway: "A trailhead should be mapped as a node or a node that is part 
of a trail segment (i.e.,highway 
=path 
) and should be 
tagged primarily as highway 
=trailhead 
." 
At least I would rephrase that to something along "... or a node that is 
part of the trail segment or a highway leading to its trail(s)."


More problematic is the question of combination. I'm pretty much opposed 
to giving this object two top level keys: highway=trailhead and 
tourism=information. I think the thought of the  old proposal was to 
mark the point on a trail where to access it, hence hw=. Peter was more 
going in the direction of marking the point where we find information on 
how to access the trail (name, information board, sign, stele, ...), 
hence tourism=information + information=.


I would still try to separate the elements. We leave it with 
hw=trailhead + possibly a name + possibly including it in the route 
relation for the actual access point. Additionally, we map the 
amenities: information board, parking, toilets, picknick site etc. I'd 
welcome introducing something like tourism=information + 
information=trailhead or tourism=information + information=board + 
board_type=trailhead. Since a trailhead could be marked by other objects 
than a board the former might be more universal.


For the dutch case that would mean removing the hw=trailhead from all 
the points and changing the tourism=... to something new we agree on.


Tobias

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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Am 02.01.2019 um 19:42 Kevin Kenny wrote:


At the risk of repeating myself:

I think I'd need more concrete examples before I'd support such a
proposal.


Yes, I second this request.


If 'trailhead' degenerates into 'any intersection of a trail and a
highway' (which is what it is in that National Park Service database)
then it's kind of redundant.


My examples below show they are rather a placeholder for 'any 
intersection of a trail and a highway' .



It appears to me that the Europeans have
a more specific idea of what a 'trailhead' is - but I don't quite
understand that idea, and I suspect that's because there are no
trailheads of that sort near me, despite the fact that I'm within an
hour's drive of hundreds of hiking trails, including a handful of 'big
name' long-distance ones.
Please don't generalize. From a German perspective I share your 
uneasiness (see my earlier remarks). Funnily, I always had the 
impression that in the US you have the more specific idea of what a 
trailhead is. :-)



I looked at some of the trailheads in the Netherlands 
(http://overpass-turbo.eu/s/EV4):


https://www.openstreetmap.org/node/6141092027
https://www.openstreetmap.org/node/6141092007
https://www.openstreetmap.org/node/6141092068

All were tourism=information + information=board but none were in any 
way connected to a trail let alone to any other highway=* feature. Often 
there wasn't even a tagged route/trail nearby. As such I understand the 
hw=trailhead is important to find such trail on the map in the first 
place if the trail itself is not or cannot be mapped.


What I don't understand is why the highway tag is used to carry the 
information. The way you have mapped the trailheads Peter I would leave 
them under some subkey of information, e.g. tourism=information + 
information=board + board_type=trailhead.


In the proposal the hw=trailhead is supposed to "be mapped as a node or 
a node that is part of a trail segment (i.e.,highway=path) and should be 
tagged primarily as highway=trailhead". 
(https://wiki.openstreetmap.org/wiki/Proposed_features/trailhead#Tagging)


As a side note: Looking at the examples I found that you added keys like
wikipedia=nl:Toeristisch Overstappunt
url=https://gpsfietsroutesnederland.nl/toeristische-overstappunten/
website=https://www.natuurpoorten.nl/

These are all generic references that could be added to the OSM wiki 
page. On the individual trailheads I would expect a website of the 
specific trail.


Regards,

Tobias


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

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Wouldn't it make sense to add the trail head (node) to a route relation 
with role=trail_head?


Am 01.01.2019 um 12:54 schrieb Peter Elderson:
At this point, I settle for just requiring that it's a named location 
visibly designated as access point for one ore more recreational routes.


So just a node tagged highway=trailhead and name=.

Which node? Well, if it's just the start with a name on a guidepost, 
use the guidepost node. If it's an information board with the name, 
use that. If there is a flagpole or a stele or say a statue of the 
pioneer who walked it first, use that. If there is none of that, use 
the location which presents itself naturally as a starrting point when 
you get there. If there is no such location, then it's not a trailhead!


Anything else: optional, map and tag as seems appropriate.




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

Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia

[Tobias Wrede]

In Germany my experience is that actually most hotels in the cities 
charge for parking. On the other hand you find very very few that call 
themselves "motel". I can only think of one currently that does, and it 
is located within a motorway rest area. The exception is the chain Motel 
One which is a very typical _h_otel often located in city centers 
offering only limited parking.


When I think of a motel I always picture those with doors opening to the 
car park from US movies. Now that several comments here indicate that 
the only practical distinction today is the name on the front sign I 
come to think that we could abandon the tag altogether. What value does 
it generate for the data consumer if tourism=motel and tourism=hotel is 
all but the same and practical distinction could for both be made by 
subtags parking=y/n, parking:fee=y/n, etc?


Tobias


Am 24.12.2018 um 01:12 schrieb Joseph Eisenberg:
In the USA, we would also assume a motel offers free parking. Hotels 
may charge extra for parking, especial if located downtown or next to 
an airport.


Is this also the case in Europe and Australia?
On Mon, Dec 24, 2018 at 8:55 AM Dave Swarthout 
mailto:daveswarth...@gmail.com>> wrote:


"Today the main difference seems to be the sign out front.  If a
hostelry calls itself a motel, it is a motel.  If it calls itself
a hotel, it is a hotel.  Local licensing authorities do not
differentiate between them and they are regulated identically, so
far as I can tell. I'd say the definition should be based on what
is written on the sign on the hostelry."

+1

That's my main criterion for tagging an accommodation as a  motel.
I agree with Volker's points and Allan's view on this.

Happy Holidays

Dave

On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard mailto:al...@mustard.net>> wrote:

Motel = MOtor hoTEL

The major difference between a 'hotel" and a "motel"
originally was the configuration of the building with respect
to parking.  At a traditionally designed motel, the cars are
parked outside the units, which typically open to the
outdoors, not to a hallway, so that patrons of the motel may
come and go freely to their automobiles.  Length of stay is
immaterial.

The first motels appeared on the Lincoln Highway in the 1920s,
if memory serves, and had little carports capable of
accommodating a Model T Ford-sized automobile next to a cabin
(yes, the first motels featured cabins, not rooms in a larger
building).

Then along came Motel 6, so called because it charged $6 per
night back in the day (it featured coin-operated TVs and you
paid extra for everything but the bed, bath, and four walls). 
Many Motel 6s had hallways, and that changed the design, but
they still catered to transients en route from Point A to Point B.

Today the main difference seems to be the sign out front.  If
a hostelry calls itself a motel, it is a motel.  If it calls
itself a hotel, it is a hotel. Local licensing authorities do
not differentiate between them and they are regulated
identically, so far as I can tell.  I'd say the definition
should be based on what is written on the sign on the
hostelry. These are my two cents' worth based on 30+ years of
travel, including a few cross-country trips across America as
well as extensive on-ground travel in Mexico, Russia, and
central Europe.

Cheers and Merry Christmas to all!
apm-wa


On Sun, Dec 23, 2018 at 4:33 AM bkil http://bkil.hu>+a...@gmail.com > wrote:

I've made a major rewording of this tag. Please review and
don't hesitate to comment or improve if I've mistakenly
changed the meaning of the tag:


https://wiki.openstreetmap.org/w/index.php?title=Tag%3Atourism%3Dmotel=revision=1755686=1561324

Source: based on Wikipedia and recent mapping experience:

https://www.openstreetmap.org/changeset/65702446#map=9/47.1412/18.6632

It also looks like some have used the word motel for what
should have been pensions and guest houses around here,
I'll also fix these later.
___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging

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



-- 
Dave Swarthout

Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___

Re: [Tagging] Trailhead tagging

[Tobias Wrede]

Hi eveyone,

Am 21.12.2018 um 19:55 schrieb Peter Elderson:
Well, in Nederland I'm through, got them all. To initiate a rendering 
on osm-carto the usage should increase by some 500+ (now on 1400+). I 
need Germany or Italy!


While on vacation I have mapped trail heads in the US pretty much the 
way Kenny has described it. I've never come across the trail head tag so 
far. In the US trail heads I have encountered were often marked as such 
having some signpost giving information on length, difficulty, 
accessibility etc. And often there was a road sign saying "xyz trail 
head". Often there is a single or very few trails departing there and 
each trail only has one or two access points that are called a trail 
head. (disclaimer: I am sure there are other situations but these are 
the ones I have encountered while on vacation).


In Germany, though, the concept of trail head is not so widely used for 
hiking trails. Very often trails are interconnected forming a mesh and 
are accessible from various locations. What we rather have are marked 
parking lots called "Wanderparkplatz", i. e. "hiking parking lot". There 
is even an official traffic sign: 
https://de.wikipedia.org/wiki/Datei:Zeichen_317_-_Wandererparkplatz,_StVO_1992.svg. 
The more fancy ones have a map of the surroundings showing all hiking 
trails of the area, possibly with length, hiking duration and 
difficulty. Often there is a waste bin, sometimes a pickinick table, 
very often it's only a few parking spots off the road crossing a forest. 
These hiking parking lots are very often not dedicated to a certain 
trail, though. Often you find them in places where there are footways 
but no marked or named hiking trails at all.


As far as I see we don't currently designate these hiking parking lots 
as such. They are just amenity parking connected to some paths/hiking 
routes plus possibly having an information board mapped. I wouldn't be 
opposed somehow tagging the Wanderparkplatz designation, not sure a 
highway-tag would be right with the amenity, though.


Having this said there are of course also some trail heads in Germany 
that more fit to what I described for the US or what you might have in 
the Netherlands. But they are the minority here I would say.


all the best for the new Year
Tobias



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

Re: [Tagging] Tagging a named river bend

[Tobias Wrede]

Am 28.09.2018 um 03:06 schrieb Dave Swarthout:
@Joseph - I wanted to avoid using that particular top-level tag, 
waterway, because there would be no simple way to add a name different 
from that of the waterway=river itself. Unless we invent a new tag 
something like name:bend=Harper Bend.


The key "natural" is so weighted with controversy already, I'd prefer 
not to use that one either. But I'm not opposed if we can all agree on 
its use here.


On Fri, Sep 28, 2018 at 7:54 AM Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


[...]
Another option would be natural=bend or natural=river_bend, because
natural=* is used for all sorts of geographic features in the natural
landscape, including water features like bays, straights, etc.

Joseph

Natural=* might be controversial. But in my opinion a river bend is very 
similar to a bay, strait, fjord etc. These are all parts of a bigger 
water body with diffuse boarders. I'd like to keep in line with those 
established taggings. It could be natural=river_section, which could 
serve for bends, straights, widenings, narrowings, pits in the river 
bed, etc., or more specific natural=river_bend.


Having that said, I admit that would we not already have those key/value 
pairs I might rather go for something better indicating we are talking 
about something water related.


Tobi

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

Re: [Tagging] Slow vehicle turnouts

[Tobias Wrede]

I would leave the short passing_place as is, i.e. the one that also 
gives space to pass oncoming traffic. For the ones intended for letting 
same direction traffic pass I would really not differentiate by short 
(what is short?), long or alternating.


/Tobi

Am 08.09.2018 um 02:29 schrieb Warin:
If the short 'passing_place' is tagged the same as a longer lane .. 
then how is it distinguished?


You cannot count on the mapper to mark the length of it every time.
So a 100 meter one could have the same tagging as a 10 meter one. That 
is not good.


I think the present tag of passing_place needs to be retained with the 
present definition.


If the use of the lanes tag or a separate service road tag is not good 
enough for these longer 'turn outs' then there needs to be some new tag.



On 06/09/18 22:56, Tobias Wrede wrote:

Hi,

I've just come back from three weeks vacation in the Sierra Nevada 
with an RV. I've used turnouts there extensively. Mostly, they were 
long enough to me not having to stop while I let the traffic pass. 
But there were also the occasional ones (marked) that were just a 10m 
paved patch next to the normal lane.


In Sweden they have a lot of 2+1 roads and they seem to become 
popular with planners in Germany, too 
(https://en.wikipedia.org/wiki/2%2B1_road). Basically, it's a 
permanently alternating long turnout. :-) I would be overshooting to 
explicitly mark every two lane bit as a turnout or passing lane.


I favor the idea of marking turnouts, passing lanes and 2+1 roads all 
the same by using the lanes tagging scheme. For explicit (short) 
turnouts we might want to create a new value for turn:lanes=pass or 
something like that.


Tobi


Am 05.09.2018 um 03:13 schrieb Dave Swarthout:
@Warin, Thanks for clearing up my confusion about passing places. 
These turnouts are definitely not the same. A vehicle should never 
stop in one. They are about 1/4 mile long and some but not all have 
painted lines to separate the highway proper from the turnout lanes. 
In the U.S., where we drive on the right, such lanes are always on 
the right-hand side of the highway, and although they aren't signed 
as one way, it's sensible to include that tag IMO. In practice, a 
slow-moving vehicle turns off the main highway, slows down enough to 
allow following vehicles time to pass on the left, after which it 
returns to the main highway.


Given that the passing_place tag defines the situation you describe, 
and indeed was created to model it, I'm not sure modifying its 
definition to include ways would be a good idea. In addition, the 
term "passing" or, in the EU, "overtaking", implies that the passing 
vehicle does so on the left (U.S.) while these turnouts are always 
on the right. Hence my reluctance to redefine that tag.


Dave

On Tue, Sep 4, 2018 at 6:55 PM Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>> wrote:


On 04/09/18 21:04, Martin Koppenhoefer wrote:



2018-09-04 12:42 GMT+02:00 Dave Swarthout
mailto:daveswarth...@gmail.com>>:


Summarizing recent comments:
Martin wrote:
> what’s wrong with passing place? Seems to describe the same thing

I thought so too until I noticed that the Wiki says
passing_place is used for nodes only, using logic that
escapes me, so I began searching for another method. I also
considered modifying that definition so it includes ways
but was reluctant to start that battle even though that
still seems a good solution.




I would be in favor of adding the possibility to tag
highway=passing_place on ways, there is already a tiny fraction
tagged on ways (although the percentage currently makes it
clear they are outliers). There's a general problem with using
nodes for features like these: they don't have a direction, so
you can't state where the widening takes place.


Passing places are not long.
Most of them are just long enough to squeeze in a car and
caravan ... just.
You are supposed to come to a complete stop to let others pass
in either direction.
They are usually on single lane, two way roads.

So a passing place .. you have to stop in it. You cannot keep
moving as you would with any distance of extra lane.




For the lanes approach: I would only use this if the place has
some length (more than 5-10 meters you may typically find on a
track) AND if there are lane markings (general requirement for
lanes).

Cheers,
Martin


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



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



--
Dave Swa

Re: [Tagging] Slow vehicle turnouts

[Tobias Wrede]

The solid line is a special case. So many other turn-outs/climbing 
lanes/... have a dashed line or even no line at all. I wouldn't make a 
difference based on markings.


I also strongly favor the lines solution but wonder if we could not 
stretch the turn key a bit. Something along 
turn:lanes:forward=through|turn-out.


/Tobi


Am 10.09.2018 um 19:54 schrieb Paul Johnson:
I don't think so.  Really the only thing throwing this off seems to be 
the same thing throwing off people who think bus and bicycle lanes 
shouldn't be counted as lanes: the solid line.


On Mon, Sep 10, 2018, 11:50 Kevin Kenny > wrote:


It seems to me that the key attribute of the 'climbing lane' situation
that Dave mentions is that it's an additional lane. It's provided for
slow-moving vehicles, sure, but that's really a special case of the
near-universal convention that slow-moving traffic gives way to
overtaking traffic by moving to the outside (that is, in North
America, to the right). The difference, at least where I am, between a
climbing lane and another ordinary lane is a subtle one: you don't
have to move to the outside if nobody's trying to overtake, rather
than a "keep right except to pass" rule. You get 90% of the way there
by simply having the correct number of lanes:forward and
lanes:backward. Is adding a lane that much more complicated than
drawing a parallel way?
On Mon, Sep 10, 2018 at 11:31 AM Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>
wrote:
>
> I'd say that it would be better to leave them unmapped than to
incorrectly map them as separate service roads.
> If they are only divided by a single painted line, they are just
lanes, not a separate roadway.
> And it's not too difficult to split the way twice and paste on a
couple of tags
>
> On Mon, Sep 10, 2018 at 10:17 PM Dave Swarthout
mailto:daveswarth...@gmail.com>> wrote:
>>
>> Wow, thanks for the help, Markus. I really appreciate it.
>>
>> But I must say, if I have to use that method to tag all the
turnouts on the Sterling Highway, I'm going to leave them
unmapped. Life is too short and there is a lot of other mapping
yet to do in Alaska.
>>
>> Although these lanes are not physically separated by a barrier
other than a painted line, I'm going to opt for the service road
scenario. It is simple, much, much less error prone to map, and
IMHO, would do the job better than the lanes technique.
>>
>> Thanks to all,
>>
>> Dave
>>
>> On Mon, Sep 10, 2018 at 6:51 PM SelfishSeahorse
mailto:selfishseaho...@gmail.com>> wrote:
>>>
>>> On Mon, 10 Sep 2018 at 11:17, Dave Swarthout
mailto:daveswarth...@gmail.com>> wrote:
>>> > I'm still not convinced the lanes:smv tagging scenario is
the best solution but were I to change my mind, how would I tag my
turnouts?  Here is another screen shot of the particular section
of highway with a turnout on both sides of the road that I've been
discussing (59.752103, -151.766395 ) with the ways removed for
clarity:
https://www.dropbox.com/s/nm6iahw9ch79tuh/slow_vehicle_turnout.jpg?dl=0
>>>
>>> I would probably split the road at every place where an additional
>>> lane begins or ends, i.e. four times, and would tag the
sections as
>>> follows from right to left (this is the direction of the
highway way):
>>>
>>> lanes=2
>>>
>>> lanes=3
>>> lanes:forward=2
>>> lanes:backward=1
>>> smv:lanes:forward=|designated
>>> overtaking:lanes:forward=yes|no
>>>
>>> lanes=4
>>> lanes:forward=2
>>> lanes:backward=2
>>> smv:lanes:forward=|designated
>>> smv:lanes:backward=|designated
>>> overtaking:lanes:forward=yes|no
>>> overtaking:lanes:backward=yes|no
>>>
>>> lanes=3
>>> lanes:forward=1
>>> lanes:backward=2
>>> smv:lanes:backward=|designated
>>> overtaking:lanes:backward=yes|no
>>>
>>> lanes=2
>>>
>>> In case the turnouts were separated by a barrier, i think your
idea
>>> with highway=service + service=slow_vehicle_turnout would make
sense.
>>>
>>> Regards
>>> Markus
>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>> ___
>> 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 

Re: [Tagging] What is a terrace after all?

[Tobias Wrede]

Am 10.09.2018 um 02:27 schrieb André Pirard:
What should I do? building=terrace 
 describes 
mapping separate houses as an *alternative*.

Erase what another mapper did, and replace that element with houses?


That's what I do. You may keep the original outline to keep some history 
but mapping the individual houses (building=house) stores more 
information so should be the preferred way.




While waiting, I converted them to landuse=terraced (invisible).


That on the other had is bad practice in my opinion. The landuse of the 
whole area should be "residential". The terrace does not get an extra 
landuse. Having many building=house sharing walls identifies terraces 
well enough I would say.


cheers, Tobi


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

Re: [Tagging] Slow vehicle turnouts

[Tobias Wrede]

Hi,

I've just come back from three weeks vacation in the Sierra Nevada with 
an RV. I've used turnouts there extensively. Mostly, they were long 
enough to me not having to stop while I let the traffic pass. But there 
were also the occasional ones (marked) that were just a 10m paved patch 
next to the normal lane.


In Sweden they have a lot of 2+1 roads and they seem to become popular 
with planners in Germany, too 
(https://en.wikipedia.org/wiki/2%2B1_road). Basically, it's a 
permanently alternating long turnout. :-) I would be overshooting to 
explicitly mark every two lane bit as a turnout or passing lane.


I favor the idea of marking turnouts, passing lanes and 2+1 roads all 
the same by using the lanes tagging scheme. For explicit (short) 
turnouts we might want to create a new value for turn:lanes=pass or 
something like that.


Tobi


Am 05.09.2018 um 03:13 schrieb Dave Swarthout:
@Warin, Thanks for clearing up my confusion about passing places. 
These turnouts are definitely not the same. A vehicle should never 
stop in one. They are about 1/4 mile long and some but not all have 
painted lines to separate the highway proper from the turnout lanes. 
In the U.S., where we drive on the right, such lanes are always on the 
right-hand side of the highway, and although they aren't signed as one 
way, it's sensible to include that tag IMO. In practice, a slow-moving 
vehicle turns off the main highway, slows down enough to allow 
following vehicles time to pass on the left, after which it returns to 
the main highway.


Given that the passing_place tag defines the situation you describe, 
and indeed was created to model it, I'm not sure modifying its 
definition to include ways would be a good idea. In addition, the term 
"passing" or, in the EU, "overtaking", implies that the passing 
vehicle does so on the left (U.S.) while these turnouts are always on 
the right. Hence my reluctance to redefine that tag.


Dave

On Tue, Sep 4, 2018 at 6:55 PM Warin <61sundow...@gmail.com 
> wrote:


On 04/09/18 21:04, Martin Koppenhoefer wrote:



2018-09-04 12:42 GMT+02:00 Dave Swarthout
mailto:daveswarth...@gmail.com>>:


Summarizing recent comments:
Martin wrote:
> what’s wrong with passing place? Seems to describe the same thing

I thought so too until I noticed that the Wiki says
passing_place is used for nodes only, using logic that
escapes me, so I began searching for another method. I also
considered modifying that definition so it includes ways but
was reluctant to start that battle even though that still
seems a good solution.




I would be in favor of adding the possibility to tag
highway=passing_place on ways, there is already a tiny fraction
tagged on ways (although the percentage currently makes it clear
they are outliers). There's a general problem with using nodes
for features like these: they don't have a direction, so you
can't state where the widening takes place.


Passing places are not long.
Most of them are just long enough to squeeze in a car and caravan
... just.
You are supposed to come to a complete stop to let others pass in
either direction.
They are usually on single lane, two way roads.

So a passing place .. you have to stop in it. You cannot keep
moving as you would with any distance of extra lane.




For the lanes approach: I would only use this if the place has
some length (more than 5-10 meters you may typically find on a
track) AND if there are lane markings (general requirement for
lanes).

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



--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

___
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] shop=discount

[Tobias Wrede]

Am 25.06.2018 um 17:12 schrieb Mateusz Konieczny:


24. Jun 2018 22:17 by dieterdre...@gmail.com 
:


sent from a phone

On 24. Jun 2018, at 22:00, Mateusz Konieczny
mailto:matkoni...@tutanota.com>> wrote:

It sounds like any type of shop may have discount shop variation.


usually the term discount shop refers to shops selling food “from
the pallet”, i.e. a smaller selection and less laborious
presentation, tending to bigger packages, for a cheaper price.
Sometimes also with supposed inferior quality. Nowadays also
typically sell occasionally selected non-food stuff according to
the season (like tools, clothing, toys, even electronics like 1
laptop or 1 phone), but usually only from 2-3 boxes, it does not
take significant space.


So it is shop=convenience that is selling “from the pallet” and is 
likely to be a cheaper?




Reading shop=discount first the kind of shop sprang to my mind that sell 
all kinds of stuff in the range of 1-5€. Here they often have names like 
1€ Store, 99c Store etc.


Looking at usages on Overpass Turbo indeed many of the occurrences are 
that kind of stores (shop=variety?). But there are also a lot of 
supermarkets (Aldi etc) with this tag, as well as drug stores and 
hardware stores it seems (I had to guess from the name where I did not 
recognize it).


To me its obvious that the tag in its current usage is totally unusable 
as it does not denote at all what I can expect to buy in the store. 
Rather there could be a tag as discount=yes showing it's some kind of 
discount store along the special shop=* tag.


So I'm perfectly fine with discouraging the use on the wiki page but I 
would not simply call it a duplicate of shop=variety but refer to likely 
tags as shop=supermarket/convenience/variety.


Tobias

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

Re: [Tagging] drop covered=booth?

[Tobias Wrede]

Am 18.06.2018 um 22:21 schrieb Paul Allen:


Then again, I've never seen an outdoor public phone that isn't in a 
booth also lack an acoustic hood.  So should
mappers and consumers assume a hood is present unless booth is 
specified?  Except I can conceive of a phone
in a building passage having neither a booth nor a hood (seems 
unlikely, but possible).


You might be surprised. Deutsche Telekom's answer to vandalized phone 
booths, the "Basistelefon":

https://commons.wikimedia.org/wiki/File:Öffentliches_Telefon.JPG

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

[Tagging] pied headquarters (was: emergency=lifeguard)

[Tobias Wrede]

Speaking of the wiki. May any native speaker explain to me what 
"operated _pied_ headquarters" are? What does "pied" mean" Or am I 
missing an obvious typo here?


from the wiki: "The station is near to be guarded waters and serves the 
emergency services of the organization as operated pied headquarters and 
guard. " 
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dwater_rescue_station



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

Re: [Tagging] emergency=lifeguard

[Tobias Wrede]

Am 19.06.2018 um 13:41 schrieb Martin Koppenhoefer:



water_rescue_station vs. lifeguard_base

there are 216 emergency=water_rescue_station which to me seems a 
pretty self explanatory tag to indicate a somehow permanent presence 
of lifeguards with some infrastructure. The wiki says it is in 
proximity to the water surface it is guarding. The other tag is 
emergency=lifeguard_base with 240 uses and defined as the "main 
building" where the administrative work gets done and equipment and 
vehicles are "stored".
I do not think we should merge those former 2 tags, they are both 
documented and clearly describe something very different. I agree the 
decision to use emergency=lifeguard_base for the office and storage 
building could be questioned, regarding the word "lifeguard base" 
(which to me suggests a place where lifeguards operate / supervise, 
not where they do the paperwork, as it is intended according to the 
wiki) and maybe also regarding the choice of "emergency" as a key, 
although this could be argumented because they are part of "emergency" 
services somehow.


Maybe I do see a clear separation in the wiki pages. It is a very 
unpractical one, though. In most cases I know a Water Rescue Station and 
a Lifeguard Base would share the same facility with the same people 
manning them. And checking some sample usages I strongly suspect that 
most tagged Lifeguard Bases should rather be Water Rescue Stations or 
sometime even Lifeguard Towers or Platforms. When looking for the 
emergency relevant facility you would rather look for the rescue station 
than for the admin building, wouldn't you?





There are also 443 emergency=lifeguard_tower
to me this looks like a clear tag, and I see no benefit in changing 
this to 2 tags like emergency=lifeguard  and lifeguard=tower.




Maybe it's better to just introduce a new emergency=lifeguard in
addition to the existing emergency=lifguard_base, that way Bryan
can offer that in iD and existing tags, data consumers and wiki
doesn't need to be changed. It's a non-breaking change then
instead of a breaking change.




as the lifeguard base is defined for storage and administration, it 
doesn't seem to fit with the expectations one would have from a 
potential new emergency=lifeguard.
I don't see why the expectation should be different since Lifeguard Base 
already is under the emergency category. I would concur putting it under 
office might make more sense.


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

Re: [Tagging] emergency=lifeguard

[Tobias Wrede]

Am 11.06.2018 um 23:09 schrieb Graeme Fitzpatrick:
Had a look at https://de.wikipedia.org/wiki/Wasserrettungsstation & 
it's a purely German organisation, which would appear to be life 
guards, although with possibly a bit of Coast Guard / Marine Rescue 
included?


Actually, this would be the general German term for a lifeguard base. 
They are manned/run by different organisations (DLRG, ASB, Wasserwacht). 
To my knowledge they only do near shore rescuing for swimmers, surfers, 
light boats etc. Off-shore rescuing more intended for rescuing ships' 
crews is done by German Coast Guard (Küstenwache, state run) or more 
often by another non-governmental organization called Deutsche 
Gesellschaft zur Rettung Schiffbrüchiger.


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

Re: [Tagging] Street exits

[Tobias Wrede]

Hi,

Am 15.06.2018 um 18:14 schrieb osm.tagg...@thorsten.engler.id.au:


They DO have exactly this type of living street in the Netherlands 
too, see https://nl.wikipedia.org/wiki/Woonerf


But the particular street Peter is talking about is, on purpose, NOT 
such a living street.


The street itself is a normal residential street, with sidewalks and 
raised kerbs. You can easily see that if you follow it along with 
streetview.


The only thing “special” about it is the way how they designed the 
point where it exits into the other street.


I can’t remember having seen this particular design (exit into another 
street designed like a living street or driveway, but the street 
itself being just a normal street) anywhere else.




Actually, we have the same thing in Germany. It's not only for living 
streets as Martin already pointed out but also for any other streets 
exiting over a lowered curb. Traffic exiting from such street has to 
behave the same way as when exiting from a driveway, i. e. drive with 
extreme caution and wait for any other traffic including pedestrians to 
pass (§10 StVO). I have no clue, though, if there is any established 
tagging for that here.


Tobias


Cheers,

Thorsten

*From:*yo paseopor 
*Sent:* Saturday, 16 June 2018 01:59
*To:* Tag discussion, strategy and related tools 


*Subject:* Re: [Tagging] Street exits

In Spain when we have this kind of exit applies the traffic sign and 
the rules of living street, as you can see in
https://www.google.nl/maps/@41.2187293,1.7332079,3a,44.9y,155.43h,88.86t/data=!3m9!1e1!3m7!1swoQsNOW-rj_haPcAnawoYw!2e0!7i13312!8i6656!9m2!1b1!2i40 
 
, a normal street becomes living at the end and the exit to another 
"normal street". In OSM is 
https://www.openstreetmap.org/#map=19/41.21845/1.73337


I'm wondering if instead of not having the same traffic sign it would 
be the same thing...


Salut i mapes

yopaseopor



___
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] Combined use of addr:place and addr:street

[Tobias Wrede]

Am 14.07.2017 um 14:32 schrieb Martin Koppenhoefer:


2017-07-14 10:16 GMT+02:00 Tobias Wrede <l...@tobias-wrede.de 
<mailto:l...@tobias-wrede.de>>:



Have a look at this place "Siesel":
http://www.openstreetmap.org/#map=17/51.22209/7.90369
<http://www.openstreetmap.org/#map=17/51.22209/7.90369>. The
hamlet is called Siesel and officially all the streets there do
not have a name (you can check on the "NRW-Atlas: ALKIS" layer 
that all streets are just designated "Weg" i. e. "Street"). From

an official address point of view all houses there should have
addr:place=Siesel and addr:housenumber=nn.



is "nn" meant to be literally the string "nn"? (btw: NN in German 
usage is a placeholder referring to people). In Italy, quite 
frequently in the countryside, there is the abbreviation "snc" to say 
"no housenumber", but I wouldn't add this in addr:housenumber as it's 
not a housenumber (you can find it in official lists in the 
housenumber field though).


Na. "nn" is meant to be a placeholder for the actual number: 12, 13, 14 
etc.


On the ground, tough, they have put up the usual German street
name signs all showing "Siesel". So from an on the ground point of
view all houses there should have addr:street=Siesel and
addr:housenumber=nn. What to do now?




 it's by definition we refuse to have both tags, as addr:place is 
defined for places without streetnames



Well that's the question here, isn't it? Is it by definition or not?

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

Re: [Tagging] Combined use of addr:place and addr:street

[Tobias Wrede]

For what it's worth answering a bit late. I am not sure I completely agree.

2017-06-23 10:18 GMT+01:00 Martin Koppenhoefer >:





   I agree with you, either use
   addr:place

   or use
   addr:street

   As the reason for using addr:place is that there isn't a street to
   which the address refers, I also don't see which street should go
   into addr:street, it makes no sense.


Have a look at this place "Siesel": 
http://www.openstreetmap.org/#map=17/51.22209/7.90369. The hamlet is 
called Siesel and officially all the streets there do not have a name 
(you can check on the "NRW-Atlas: ALKIS" layer  that all streets are 
just designated "Weg" i. e. "Street"). From an official address point of 
view all houses there should have addr:place=Siesel and 
addr:housenumber=nn. On the ground, tough, they have put up the usual 
German street name signs all showing "Siesel". So from an on the ground 
point of view all houses there should have addr:street=Siesel and 
addr:housenumber=nn. What to do now? I would say that in this case we 
could perfectly well have both addr:place and addr:street.


I agree this is borderline but I don't see why we should categorically 
refuse to have both tags.


Note that I just searched my mind for a case where this could happen. 
The actual tagging here is just using the addr:street.


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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 16.05.2017 um 23:42 schrieb John Willis:

On May 16, 2017, at 4:29 PM, Tobias Wrede <l...@tobias-wrede.de> wrote:

May I suggest to focus the proposal on the frontend for now?

The front end is the most difficult part, and having a proposal that covers the 
chain and many permutations is important.

For example, I would _never_ go to a UPS sort facility to ship a package, but I 
imagine some do in other countries.
In that respect UPS is not any different from a supermarket or a dry 
cleaner. You go to the shop=supermarket or shop=dry clener but not 
Tesco's warehouse or the central dry cleaning facility.



But tagging a giant commercial warehouse with a package window as 
"shop=courier" seems wrong.
If they have a package window I would definitely tag that with 
shop=courier, but not the whole warehouse.



People may come to the courier=* wiki page to tag a courier's warehouse that 
they see their package is at. Being able to tag it is important. I have added 
regional_hub warehouses in google Maps when I find my package is first accepted 
into the tracking system there. People search for where those facilities are 
all the time.
So that's why a propose shop or amenity. That's clearly the place a 
regular customer goes. The warehouse/sorting hub could get a 
building=warehouse or whatsoever. Taggers should be able to make that 
differentiation. They don't tag the cold storage warehouse around as 
supermarket, either.

After thinking about it a bit, I think we should limit this to 
non-freight/logistics and create a separate logistics=*for trucking/freight/etc 
later. But you should be able to tag a commercial warehouse as part of the 
courier=* tag.


IMHO The problem at hand is how does a regular OSM user find a courier. 
At least for me I need a courier less often than a supermarket but 
significantly more often than a pharmacy. So from my viewpoint we should 
really focus on the shop aspect for now. You now suggest to later 
introduce a logistics=* structure. I think in the backend the 
distinction between courier and freight services gets more complicated 
to not doable. I would really like to not think about that at all for now.


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 16.05.2017 um 12:20 schrieb Warin:

On 16-May-17 06:01 PM, Martin Koppenhoefer wrote:


The tag in the first proposal wasn't chosen badly, it was insufficiently 
defined. Office is not a good tag for the public facing frontend with counters 
etc.


I disagree.
Shops frequently have counters etc for the public facing front end.
Some offices do too... lawyers, accountants, insurance, etc... have a counter 
for customers to arrive at.
Should all these things be lumped in to the key amenity??? I think not!
Office is the correct place for it./"A place predominantly selling services." 
/Nothing here about how it is configured.
I generaly agree with an office being /"a place //predominantly selling 
services"/ but maybe the definition is not specific enough. Let's have a 
look at some examples. Laundries, dry cleaners, hairdressers, massage 
shops, tattoo parlours, money lenders, lottery shops, ticket shops, 
copyshops all predominantly sell services, yet they are all classified 
being shops. Banks and post offices are amenities. I would say a courier 
outlet is much more like a laundry or a copyshop than like a lawyer or 
inscurance. On the other hand it is very close to a post office. So 
amenity and shop come to my mind way before an office.



In another post Andrew Davidson has correctly identified 'Post Office' and
they are, I would, think to most people around the world viewed differently 
from couriers.

I will quote it here to save you looking:
/The Universal Postal Union is an international organisation  that 
coordinates postal policies among its 192 member countries. One of the requirements of membership is that countries must nominate 
the "operator or operators officially designated to operate postal 
services" on their territory (//http://www.upu.int/uploads/tx_sbdownloader/questionnaireNotificationOfTheEntityResponsibleCircularLetterEn.pdf//). /


Well, times are changing and I wouldn't use UPU for any definition on 
our side. Would you call a DHL parcel outlet a post office? DHL being a 
brand of Deutsche Post is the German operator officially designated to 
operate postal services as defined by UPU.


While a post office seems to still be a certain institution in many 
countries in many others it is not. I cannot even recall when I have 
been to one the last time. All these other available places that have 
sprung up over the past years (couriers, postal shops inside shops, 
private mail operators etc.) take up most of the post office functions. 
So I am very reluctant to treat them any differently.


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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 16.05.2017 um 10:27 schrieb Marc Gemis:

On Tue, May 16, 2017 at 10:01 AM, Martin Koppenhoefer
 wrote:

For shops that offer courier services as a minor part / not primarily, it 
should be a property for the shop, maybe with the carrier in the key, e.g. 
amenity=fuel, courier:UPS=yes?

Maybe it's a silly idea, but why do not we map this as 2 nodes  ? This
way, we do not have to come up with 2 sets of keys (one for
amenity=courier and one on anything else).
Both nodes could be connected via a "shop"-relation or whatever you
want to name it.


We need to differentiate a bit more. Here in Germany and I believe it 
happened elsewhere we have former post offices (Deutsche Post) that were 
integrated into other shops keeping almost all of their former functions 
and services, except providing PO boxes and extended business services 
(mass mailing etc.). But then their is a high varity of different 
service combinations. Some offer (some) banking services, some don't. 
Some offer registered mail, others don't. Some just ship parcels, some 
have also regular mail. All of these offer Deutsche Post (incl. DHL) 
services. And then there are the competitors, too.


What I want to say is it's not just placing a second node somewhere. We 
need to define where post_office stops and where courier begins or how 
we describe the situations otherwise.


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 15.05.2017 um 14:59 schrieb John Willis:

My email accidentally got sent before I was finished, but I think you see where 
I am going.

What you write makes a lot of sense. Just, that a lot of that exactly 
applies to post offices/postal services as well. So why should 
post_office be an amenity and courier a shop? I still suggest to somehow 
unify post_office and courier, but I admit I don't have a good solution 
to do that.


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Hi,

Am 15.05.2017 um 12:45 schrieb muzirian:
I think I tried to address suggestions made.Are you suggesting to 
scrap the proposal and use post office instead?


Regards


Well, when reading through the comments of the no voters (and the 
comments here in the thread) I believe that it was only a small concern 
that office would fit better than amenity. Actually, I myself find 
amenity much better than office. The bigger concerns focused indeed 
around how to reasonably differentiate and use a=post_office and 
a/o=courier, especially in worlds where there is no clear 
differentiation (any more).


I'm totally for introducing some new tagging allowing for describing 
courier services. But I am at the same time against setting another 
narrowly defined tag into stone where we need a broader approach. I 
believe we need something that
a) is able to describe a "traditional" postal service as it is still 
found in many countries by whatever that means there,

b) is able to describe outlets of private/new mail services,
c) is able to describe outlets of private/new parcel/courier services,
d) is able to describe any mixture or subset thereof,
e) is able to describe mail and courier related services offered by 
other amenities on behalf of the mail/courier companies (shipping 
parcels in a grocery store, mailing letters in a tobacco shop, ...).


I don't propose any ready solution for that. It could mean we stay with 
just amenity=post_office and add appropriate sub tags (something like 
post_office:mail=yes/no/shipping, 
post_office_parcels=yes/no/shipping/receiving, 
post_office:banking=yes/no, ). Or something else.


Coming back to your original question: I don't see how mainly changing 
the proposal from a=courier to o=courier addresses any of those raised 
questions I just described.


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Hi  Kelvin,

I still don't see how this proposal addresses any of the many concerns 
brought forward in the previous amenity=courier voting or this thread. 
Just changing amenity to office doesn't make the whole 
post-office/courier tagging any better (quite the opposite in my opinion).


Tobi


Am 12.05.2017 um 11:43 schrieb muzirian:

Is it okay to push this to voting again?

Regards


On Wed, Apr 26, 2017 at 2:08 PM, John Willis <jo...@mac.com 
<mailto:jo...@mac.com>> wrote:




On Apr 25, 2017, at 8:46 PM, Tobias Wrede <l...@tobias-wrede.de
<mailto:l...@tobias-wrede.de>> wrote:

Am 25.04.2017 um 11:21 schrieb John Willis:

If I search for a supermarket and you send me to a 7-11, you failed.


I partly agree but when I tag Walmart or Trader Joe's as a
supermarket's brand that carries a clear expectation towards the
assortment of the store.


I didn’t send it to the mailing list by accident: here is the
message he is quoting from in it’s entirety

Javbw


~




On Apr 25, 2017, at 8:43 PM, Tobias Wrede <l...@tobias-wrede.de
<mailto:l...@tobias-wrede.de>> wrote:

a supermarket's brand that carries a clear expectation towards
the assortment of the store.


This is true for all businesses in all counties. The regional
assumption of what goods/services are available varies not only by
"brand", but what each type of shop offers varies by culture -
similar to what is available at a "drug store" and a "pharmacy". A
drug store in the US often has a prescription pharmacy in the back.
What is considered a "prescription" and what is OTC is similar to
the regional variation with of what is offered at a supermarket or
a post office, but at least there is a clear separation between
OTC and prescription drugs in most countries.

A Supermarket or department store o might also have most of what a
drug store offers and a pharmacy (like target did). But in other
cultures, for cultural or legal reasons, they might be separated,
like here in Japan. So there is a need for both a "pharmacy"
(chemist?) and a "drug store".

Whereas in the US, we would need a way to tag the prescription
pharmacy as an amenity offered by a drug store or a department store.

I cannot think of a "pharmacy" shop that only sells perception
medication and nothing else in the US - they are are (seemingly)
always part of a larger drug store that sells chocolate and
vitamins and OTC drugs and other not-drug stuff the Prescription
drugs are just another thing they offer. But in Japan, the OTC
stuff is separated from the prescription stuff, and a prescription
shop is very tiny and sells (basically) only perceptions, nothing
else _at all_.

Trying to tie them together saying "they both sell medicines" and
"we can separate them by brand" and "we have so many variations we
need to tag them in a different manner" breaks the tagging system
for all of them completely, and does little to address the need
for the "amenity" tag needed to add it onto larger businesses that
offer an entire business' service as a department in their store -
like a garden center at DIY shop, a custom-order cake shop inside
a supermarket, or package drop-off for a courier at a
convenience store.

Javbw.

___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
<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] Very large multipolygons

[Tobias Wrede]

Am 02.05.2017 um 11:05 schrieb Frederik Ramm:

Hi,

I have removed three very large multipolygons from OSM today.

* I DELETED a "place=sea" for the Adriatic Sea
(http://www.openstreetmap.org/relation/4590486) because I think we
shouldn't even start with that kind of thing (place=ocean name=Atlantic
anyone?).

I don't concur. True, it's very disputable where to draw the boundaries 
but sea areas have long-standing and daily used names the same way as 
other named places with vague extent (forrests, mountains (not peaks), 
desserts, meadows, neighbourhoods to name a few). So why not sea areas? 
In fact, I am missing more of these. I have often tried to look up such 
features and had to resort to Google maps to find out.


Maybe it's wiser to use a place node (like Skaggerak 
http://www.openstreetmap.org/node/4789456526#map=9/57.8572/8.9511) than 
an area but I would not delete the information  completely.


Tobi

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

Re: [Tagging] mandatory restriction with via way as members

[Tobias Wrede]

Am 02.05.2017 um 10:11 schrieb Martin Koppenhoefer:

On 2. May 2017, at 08:53, Michael Tsang  wrote:

What would you say this restriction means? Does it mean that once a vehicle 
starts the from way it must go along the whole length to the to way?


it means you can't go any other way than to the to way, you might stop though, (unless 
there are other restrictions preventing you from doing so). Not entirely sure about 
backing up, but likely can't do it either (because if you go to the via way you have to 
follow the "only" restriction).

I would understand it the same way. To be a little bit more concrete: If 
you come from the northbound Gloucester Rd via the nothern loop (way 
46615969) onto Victoria Park Rd (way 46615970 and onward) you must 
continue on the northern bit of westbound Gloucester Rd (way 244383612) 
and you are not allowed to take the middle or southern Gloucester Rd 
(244383597 and 486608995). If you come from the secondary Gloucester Rd 
(way 486608999), the other bit of Victoria Park Rd (way 87081210), 
Cannon St or Percival St, though, you may continue on either the 
northern, middle or southern part of Gloucester Rd.


This arrangement looks a bit strange to me. Is this what you intended to 
tag? If there is such rule set in place on is there not any physical 
barrier on the road preventing the lane changes? That case might warrant 
splitting the raod into two parallel segments.


Thank god I never had to drive own-handed in HK. :-)
Tobi

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

Re: [Tagging] Proper parking lot separation

[Tobias Wrede]

Am 28.04.2017 um 09:44 schrieb Warin:


The disadvantage is that it lacks the where these things are in the 
larger parking area.

Unless you map each as a separate area.
That you have to do anyhow if you want to make any distinction. Unless 
you just tag different capacities.


Tobi

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

Re: [Tagging] Proper parking lot separation

[Tobias Wrede]

Am 28.04.2017 um 02:04 schrieb Warin:

On 28-Apr-17 09:43 AM, John Willis wrote:

When tagging a large facility I need:

- car(understood)


 - car with trailer (usual in home renovation/building centres)


-bus
-"large" (truck/tanker/semi,etc)
-motorbike (understood)
-disabled car only
-disabled bus only
-bicycle (understood)


Truck only, bus only, large only, car with/without trailer only etc. 
could mostly be denoted by using the appropriate access tags. That has a 
couple of drawback, though:

a) it breaks with already having motorcycle_parking and bicycle_parking
b) it makes it more difficult to interpret by renderers  (though not 
impossible)


As an advantage it's easy to have a parking lot for both buses and 
trucks vs buses only. Just add the appropriate access tags and do not 
worry about which amenity=? to use.


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 25.04.2017 um 11:21 schrieb John Willis:

If I search for a supermarket and you send me to a 7-11, you failed.

Post offices have different scopes in different places, ways we 
usually separate by tag, because we separate "duckiness" by tag. This 
varies by region, so we need a way to represent both, and we have 
existing tags as well.
[...] This is not something left to "operator". Brand is for 
separating similar items - a Burger King vs a McDonalds - not to 
separate steakhouses from a butcher shop. We are deciding where to 
draw the lines on scope, like convenience stores, markets, 
supermarkets, and malls.


I partly agree but when I tag Walmart or Trader Joe's as a supermarket's 
brand that carries a clear expectation towards the assortment of the store.



The sticky point seems to be that because nationalized post services 
and commercial courier services are available in different places 
*beyond* the traditional offices - buying stamps at a gas station, box 
shops that ship via post and courier systems, etc, that the "amenity" 
of a location that offers post/courier service is blurred in many 
places, or the post''s importance in some places has dwindled, 
relegating it to be a courier. We should be figuring out how to handle 
assigning the "amenity" of those services (similar to how a hotel has 
a workout room, but that doesn't make the hotel a gym) to other kinds 
of businesses, in a way where we can have multiple values. A hotel has 
parking, a pool, gym, etc, but it is foremost a "hotel" with various 
amenities. Having a dedicated courier or post office tag isn't so much 
of an issue - in many places with a traditional post system, it is 
still different enough to warrant separate tags. it's adding these 
courier/post options to other businesses or shops that needs to be 
worked out. Mashing post offices and courier services together is not 
going to solve that issue nor improve OSM tagging in any appreciable way.


[...]
Having a tagging system to add that onto another shop sounds like that 
is what people are looking for, if I understand correctly.


At least that is part of it. Along the convenience store supermarket 
analogy maybe we need something like the amenity=post_office for the 
traditional ones and an amenity=shipping_services (just a working title) 
for everything else, not just couriers. That would work at least for the 
dedicated shops. For the in-shop services provided in kiosks etc. it 
might be a different tagging.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 25.04.2017 um 10:29 schrieb Marc Gemis:
On Tue, Apr 25, 2017 at 9:17 AM, Tobias Wrede <l...@tobias-wrede.de> 
wrote:

With this proposal how would I tag an amenity that sells stamps, offers
registered mail, receives parcels but does not accept commercial mass 
mail
and does not offer banking services? It's not a "traditional post 
office".

amenity=courier ; brand = ...
or
amenity=postal_office ; brand=...


Yes. But which?

What I want to say is that simply introducing a *=courier  along the 
already existing amenity=post_office opens more questions for me than it 
answers.


Don't get me wrong. I am totally in favor of a tag I can attach to a UPS 
store or a kiosk shipping DHL parcels. I just think that leaving 
post_office as it is and simply adding a courier tag ignores the 
situation of changing ways theses services are delivered today.


Tobi

resending to the list. darned. How do I get Thunderbird to answer to the 
list automatically?



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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 25.04.2017 um 05:13 schrieb Marc Gemis:

I still believe that for the feature at hand it is enough to have
amenity=courier, just so we can distinguish it from the traditional
postal_office. Do we need subtags for courier yet ? I do not think so.

We are mapping supermarkets/convenience stores which offer different
products/services for more than 10 years without subtags to
differentiate between hypermarkets, discounters, supermarkets that
offer a services of a licensed butcher, etc. Any attempt on adding
detail to this was seen as unneeded for OSM, yet we demand this level
of detail from a 1.0 proposal for courier services ?

If we are mapping supermarkets with different services and that is 
enough why do we need to distinguish between a "traditional post office" 
and a courier?


From reading the posts to this list I understand countries like Japan 
and UK still have a very distinct separation between the two. OK. If 
there is the Royal Mail and the Japan Post they can be tagged as 
operator or brand to make that clear then in my opinion.


But in many countries, including Germany there are so many shades of 
gray between a full service traditional post office and a pure parcel 
drop-off/pick up service I wouldn't know how to draw the line. All the 
"traditional" post offices are couriers as well. And they are banks 
("Postbank" in Germany, which belongs to Deutsche Bank nowadays). On the 
extreme side there are offices of different postal services fully 
dedicated to letter related services, there are couriers (various 
companies) and there are Postbank "financial centers". And then there is 
everything between, as stand-alone shops or embedded into a convenience 
store, kiosk, bakery etc.


With this proposal how would I tag an amenity that sells stamps, offers 
registered mail, receives parcels but does not accept commercial mass 
mail and does not offer banking services? It's not a "traditional post 
office".


Tobi

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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 16.04.2017 um 17:30 schrieb muzirian:
>And (speaking as an American), if someone asked me to direct them to 
a post office, unless they were obviously about to send a parcel, I 
wouldn't send them to FedEx or the local copy shop (most of which 
offer shipping services, and some of which also offer a mailbox service).


Thanks for clarifying the case for US, I guess this is the same for 
most places.


Regards
Kelvin
Since sending someone to the nearest post office from here (in Germany) 
would require quite a bit of walking I'd rather ask if the person could 
also do with a Deutsche Post (DHL) parcel shop (in the same street) 
where they can send parcels and buy stamps, a Hermes parcel shop (two 
blocks away) where they can end parcels or a Deutsche Post franchised 
branch (500 m away) where they can send parcels and letters, buy stamps, 
send registered mails. But maybe they want to rent a PO Box or like to 
submit commercial mail (at discount) either for which they need the real 
post office 5km away. Which of those is amenity post_office now?


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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Tobias Wrede]

Am 15.04.2017 um 20:04 schrieb Marc Gemis:

As I wrote before, it is not because something does not exists in one
country, that one has to vote against a proposal. One has to try to
understand that different countries with different traditions and
tagging needs.


Exactly, but these proposals do no help in that respect, either.


So in case there would be a office of one of those couriers where one
can only bring parcels, it would be nice to have a different key.

I also do not understand why people do not want that there are 2
different "top" level tags for those two concepts. If you need to use
the data, you can still merge the 2 features. That is much easier than
trying to split them, especially since the proposed tagging is
amenity=post_office and amenity=post_office + courier=yes. Which means
that the current data consumers will make no difference between the
two.

We have different words for the two concepts in many languages, so why
can't we use those two words in mapping/tagging ?
Ten years ago I would have agreed. Today there are not two (2) concepts 
anymore but there is a wide range of different marketing channels used 
offering the discussed services to varying degrees. It has been noted 
several times in this thread what people would point to if asked for the 
nearest post office. I must admit I would really have to think hard 
where to find the nearest "traditional" one.


In my area in Germany only the big main "Deutsche Post" offices of a 
city have survived. All the rural and suburban offices have been closed 
and their services are now carried out in so called Deutsche Post 
branches by tobacco shops, bakeries, laundries, kiosks, you name it. I 
guess most of them offer letter and parcel related services but not all 
of them offer banking related services, none have PO boxes. Then there 
are parcel shops of Deutsche Post located in the same kind of amenities 
that focus more on the parcel business but some of them also sell stamps 
for letters (but you would fail to leave a registered mailing there). 
Poste restante for letters and parcels is possible in some but not in 
others.


Then there are several competitors of Deutsche Post in the latter 
business, many only operating in certain regions. They have offices, 
too. Are these post offices? But many (all?) of those do not offer 
parcel services let alone banking services.


The couriers also operate via parcel shops like Deutsche Post. I haven't 
seen a real UPS or other brand's outlet around here but thy might exist.


Stamps can be bought and sometimes letters can be mailed in many 
souvenir and tobacco shops, too, without any affiliation to a post office


So, disapproving of amenity/office=courier does not mean I ignore other 
countries' traditions and tagging needs. I disapprove because this pair 
of post_office and courier would polarize the services where there is no 
clear differentiation anymore in many places. Keeping post_office and 
courier as two distinct amenities/offices would in the same way ignore 
some countries' traditions and tagging needs.


Rather than having this new proposal for a courier office tweaked and 
pressed through I would prefer a generally revised tagging scheme in 
that context.


Tobi

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

Re: [Tagging] mandatory restriction with via way as members

[Tobias Wrede]

Hi Michael,

Am 15.04.2017 um 11:14 schrieb Paul Johnson:


On Thu, Apr 13, 2017 at 11:36 AM, Michael Tsang > wrote:


I have created a restriction (mandatory route) where if vehicles
coming from way must go through a section of a trunk route before
leaving it. Assume that an only_straight_on relation has been
created with from A-C, via C-K-E (C-K-E is a single way but K is
connected to D and J) and to E-G.


A little hard to tell here, can you annotate an aerial for your 
example for a better visualization?




I'd say the only straight on retriction is ambigious here. It's not 
clear if A-C-B or A-C-L is allowed or not. I would split the way C-K-E 
at K and make several no turns restrictions via a node.


Or do you mean to say it is allowed to go B-C-K-D but not A-C-K-D? Then 
I would second Paul's request for an example (aerial, place on the map).


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

Re: [Tagging] Spillways

[Tobias Wrede]

Hello,

actually, I have used
   warterway=spillway
   intermittent=yes
in the past, reasoning that this particular spillway 
(http://www.openstreetmap.org/way/451309286) is rarely put to use, while 
others might be more permanently flooded (regularly during high tides 
for example)


Tobias

Am 23.03.2017 um 12:58 schrieb John Sturdy:
I suppose  waterway=weir plus intermittent=yes would describe it, but 
I don't think that's as good as a specific spillway tag.


On Thu, Mar 23, 2017 at 6:52 AM, Andrew Harvey 
> wrote:


On 22 March 2017 at 16:56, Dave Swarthout > wrote:
> Weir does not seem appropriate for this type of thing. There is
a tag,
> waterway=spillway, that seems like a good fit - 81 uses so far.

I've seen these tagged as waterway=drain which is close but agree that
waterway=spillway is better. Would be great to have this documented on
the wiki.

___
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] Busways

[Tobias Wrede]

Am 06.11.2016 um 10:15 schrieb Tijmen Stam:

On 06-11-16 02:30, Mark Wagner wrote:


How sure are you that the situations are similar?  A bus-only driveway
giving access to a transit center and a bus-only road through a city
are both "access=no, psv=designated", but they're not similar sorts of
things.


Not at all. But in Europe (the Netherlands, Germany, France) the 
practice seems to be (from my inspection) to tag busways as 
highway=service (with appropriate tags) 


Actually, the only busway coming to my mind around here (Cologne area) 
is tagged as hw=residential and has been since the beginning. It's in 
shape and appearance a continuation of a proper (normal access) 
hw=residential into a hw=primary through a small stretch of wood.


Then I looked around with overpass turbo a bit (looking for vehicle=no 
and bus=yes or psv=yes). You are right, many cases are tagged with 
hw=service. Then again many of those are indeed service ways as they 
give access to bus stops.


Of proper busways still many are tagged with hw=service but as many also 
with hw=residential. Of the former I would have tagged many as hw=x_link 
or hw=residential myself.


Cheers, Tobias

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

Re: [Tagging] Masts vs Towers yet again

[Tobias Wrede]

Am 15.04.2016 um 17:43 schrieb Martin Koppenhoefer:

there's clearly a difference in meaning  (the words are not synonymous), so why 
would we want to remove this distinction?


If there clearly was a difference in meaning or better if there was a 
clear difference in meaning we wouldn't have the discussion. I got 
confused myself in the past when trying to find the right tag.



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

Re: [Tagging] Masts vs Towers yet again

[Tobias Wrede]

Maybe before discussing if some structure is better named tower or mast 
you/we should reflect why we should make a distinction at all:


Is the difference whether...
1) the structure is free-standing or not?
2) the structure has one contact point to the ground or several?
3) there are rooms/accommodations on the structure or not?
4) the structure is covered or not?
5) the structure is accessible for service only or more frequently accessed?
6) anything else or any combination of the above?

And could not some of those distinctions relayed in another way? E. g. a 
single column mast could be tagged as a point vs a wider (power) tower 
as an area with the appropriate extent. An accessible structure with 
rooms could be tagged additionally as building=yes.


So what's the point in distinguishing mast from tower at all?

Am 15.04.2016 um 17:07 schrieb Dave Swarthout:
You want to retag communication towers that are identical in structure 
to the power towers on the Wiki page as masts? I would disagree 
totally with that idea. A mast does not have legs in common American 
usage.


Is that your thrust or do you have another term in mind?

On Fri, Apr 15, 2016 at 6:53 PM, Malcolm Herring 
> wrote:


On 15/04/2016 12:39, Dave Swarthout wrote:

I think you had better make the requirements for tower less
strict.


The whole point of my definitions is to *NOT* use the word "tower"
for communications masts. I am trying to resolve the ambiguity by
choosing one in preference to the other, even though a given
structure may be locally known by the other word.



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




--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com


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


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