date:20200814




Am 13.08.2020 um 19:06 schrieb Colin Smale:


On 2020-08-13 18:35, Werner.Haag@leitstelle.tirol wrote:


Hi,
in my opinion (i think dktue is right there) it should be easy for a 
user to distinguish or extract (overpass query) the upper, mid and 
lower stations.
That´s not possible at the moment in OSM. Elevation (ele tag) may be 
useful, but does not indicate whether a station is the lower or upper 
one.
On the other hand, a tagging with upper_station or lower_station is 
clear and self-explanatory.
It would also be a denormalisation of the data. In SQL terms you would 
use a subquery like "WHERE ele = MIN(SELECT ele FROM stations 
WHERE...)" although I suspect the usual use case will be looking for 
the whole line, so a simple "ORDER BY ele" would give you all you need 
to know - bottom station is first row, top station is last row, rows 
2..n-1 are mid stations. This would avoid any possibility of 
conflicting information, e.g. multiple stations tagged as top, or the 
station with the lowest elevation being tagged as top station.
All this is based on the assumption that the definition of the top 
station is the one with the highest altitude If any other factors 
are in play that could mean that this definition does not always hold 
true, then I am keen to hear It's best to check assumptions, even 
(especially?) if they do appear obvious.
I agree that this is denormalization, but: We still do this in OSM with 
addresses and zipcodes for example and this is a good thing to do: 
Because it allows to find potential errors in the data in an automated 
way. I think it's very hard to find a wrong ele-Tag but it would be easy 
to hint in a quality assurance tool that ele-Tag and station-Tag do 
conflict.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 06:57, Peter Elderson  wrote:
> 
> I can see how an area such as a parking, a churchyard or pedestrian area can 
> be tree lined.

I can also see this, but I’m not sure we should use this tag for it. Placement 
on area (borders) will vary a lot, and it would make more sense to require 
explicit trees compared to roads and waterways (IMHO)

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

Re: [Tagging] Antwort: Re: Aerialway stations




Am 13.08.2020 um 19:06 schrieb Colin Smale:


On 2020-08-13 18:35, Werner.Haag@leitstelle.tirol wrote:


Hi,
in my opinion (i think dktue is right there) it should be easy for a 
user to distinguish or extract (overpass query) the upper, mid and 
lower stations.
That´s not possible at the moment in OSM. Elevation (ele tag) may be 
useful, but does not indicate whether a station is the lower or upper 
one.
On the other hand, a tagging with upper_station or lower_station is 
clear and self-explanatory.
It would also be a denormalisation of the data. In SQL terms you would 
use a subquery like "WHERE ele = MIN(SELECT ele FROM stations 
WHERE...)" although I suspect the usual use case will be looking for 
the whole line, so a simple "ORDER BY ele" would give you all you need 
to know - bottom station is first row, top station is last row, rows 
2..n-1 are mid stations. This would avoid any possibility of 
conflicting information, e.g. multiple stations tagged as top, or the 
station with the lowest elevation being tagged as top station.
All this is based on the assumption that the definition of the top 
station is the one with the highest altitude If any other factors 
are in play that could mean that this definition does not always hold 
true, then I am keen to hear It's best to check assumptions, even 
(especially?) if they do appear obvious.


Your assumption is true. The upper_station is the one with the highest 
altitue whereas the exact altitude is not always known by mappers.


Just to put it in perspective as a mapper from Tyrol joined the 
discussion: In Tyrol alone (less than 10% of Austria's population) OSM 
shows more than 1000 (!) aerialways [1] and for probably each of them it 
would be pretty obvious to tag lower_station and upper_station. I think 
aerialways that go horizontal are an absolute niche. So why oppose to 
the suggested tagging of 
station=lower_station/mid_station/upper_station? What harm would this cause?


[1] http://overpass-turbo.eu/s/X2M
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread yvecai


On 14.08.20 10:00, dktue wrote:


So why oppose to the suggested tagging of 
station=lower_station/mid_station/upper_station? What harm would this 
cause?


There is concerns expressed by the tag value lower/upper that imply the 
elevation difference, do you want to tag this difference or someting 
else? In other word, can you draft here the definition for those values ?


Yves



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

Re: [Tagging] Antwort: Re: Aerialway stations


Am 14.08.2020 um 10:28 schrieb yvecai:

On 14.08.20 10:00, dktue wrote:


So why oppose to the suggested tagging of 
station=lower_station/mid_station/upper_station? What harm would this 
cause?


There is concerns expressed by the tag value lower/upper that imply 
the elevation difference, do you want to tag this difference or 
someting else? In other word, can you draft here the definition for 
those values ?


Yves


I would define it as:

lower_station: station that has the lowest elevation (exact elevation is 
not necessary to know, it's obvious)

upper_station: station that has the highest elevation
mid_station: any other station

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

Re: [Tagging] Antwort: Re: Aerialway stations



Am 14.08.2020 um 10:35 schrieb dktue:

Am 14.08.2020 um 10:28 schrieb yvecai:

On 14.08.20 10:00, dktue wrote:


So why oppose to the suggested tagging of 
station=lower_station/mid_station/upper_station? What harm would 
this cause?


There is concerns expressed by the tag value lower/upper that imply 
the elevation difference, do you want to tag this difference or 
someting else? In other word, can you draft here the definition for 
those values ?


Yves


I would define it as:

lower_station: station that has the lowest elevation (exact elevation 
is not necessary to know, it's obvious)

upper_station: station that has the highest elevation
mid_station: any other station
I want to add: At least in Germany, Switzerland and Austria there are 
well-established german words which you often find in the name of the 
stations themselves:


* "Talstation" ("valley station")
* "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
("summit station")

* "Mittelstation" ("mid station")

There should be a machine-readeably tagging to get this information that 
is so often encoded in the name. That's why I'm suggesting this tagging.


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

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread yvecai


On 14.08.20 10:40, dktue wrote:

I would define it as:

lower_station: station that has the lowest elevation (exact elevation 
is not necessary to know, it's obvious)

upper_station: station that has the highest elevation
mid_station: any other station
I want to add: At least in Germany, Switzerland and Austria there are 
well-established german words which you often find in the name of the 
stations themselves:


* "Talstation" ("valley station")
* "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
("summit station")

* "Mittelstation" ("mid station")

There should be a machine-readeably tagging to get this information 
that is so often encoded in the name. That's why I'm suggesting this 
tagging.



Then why not valley / mid / mountain as values ? If the mountain station 
is lower than the mid- one, there is no discussion.


But also, my feeling is that it's more defined by the destination of the 
stop rather than a property of the aerialway node in question: you 
expect maybe a restaurant in the 'mountain station', more rarely in the 
'valley station', you also expect to put your skis on or start riding 
your bike in the former, etc ...


There is more to a 'mountina station' than being up/down.

Yves



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

Re: [Tagging] Antwort: Re: Aerialway stations



Am 14.08.2020 um 10:53 schrieb yvecai:

On 14.08.20 10:40, dktue wrote:

I would define it as:

lower_station: station that has the lowest elevation (exact 
elevation is not necessary to know, it's obvious)

upper_station: station that has the highest elevation
mid_station: any other station
I want to add: At least in Germany, Switzerland and Austria there are 
well-established german words which you often find in the name of the 
stations themselves:


* "Talstation" ("valley station")
* "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
("summit station")

* "Mittelstation" ("mid station")

There should be a machine-readeably tagging to get this information 
that is so often encoded in the name. That's why I'm suggesting this 
tagging.



Then why not valley / mid / mountain as values ? If the mountain 
station is lower than the mid- one, there is no discussion.
I think the germany word "Talstation" ("valley station") is not flawless 
as a Talstation might not be in the valley but in the middle of the 
mountain. I think in the german language "Talstation" refers to the 
lowest station of an aerialway. That's why I think lower/mid/upper are 
better suited.
But also, my feeling is that it's more defined by the destination of 
the stop rather than a property of the aerialway node in question: you 
expect maybe a restaurant in the 'mountain station', more rarely in 
the 'valley station', you also expect to put your skis on or start 
riding your bike in the former, etc ...


There is more to a 'mountina station' than being up/down.

That true but I think there are different tags to add this information.

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

Re: [Tagging] Antwort: Re: Aerialway stations




14 Aug 2020, 10:53 by y...@mailbox.org:

> On 14.08.20 10:40, dktue wrote:
>
>>> I would define it as:
>>>
>>> lower_station: station that has the lowest elevation (exact elevation is 
>>> not necessary to know, it's obvious)
>>> upper_station: station that has the highest elevation
>>> mid_station: any other station
>>>
>> I want to add: At least in Germany, Switzerland and Austria there are 
>> well-established german words which you often find in the name of the 
>> stations themselves:
>>
>> * "Talstation" ("valley station")
>> * "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
>> ("summit station")
>> * "Mittelstation" ("mid station")
>>
>> There should be a machine-readeably tagging to get this information that is 
>> so often encoded in the name. That's why I'm suggesting this tagging.
>>
>>
> Then why not valley / mid / mountain as values ? If the mountain station is 
> lower than the mid- one, there is no discussion.
>
Become bottom station may be 
located not in the valley and top may
be on the hill, not mountain.


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

Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Jez Nicholson

Q: if I mark a road as tree_lined=both and later map all the individual
trees, do I remove the tree_lined=both tag as I now have finer detail?

On Fri, Aug 14, 2020 at 8:45 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Aug 2020, at 06:57, Peter Elderson  wrote:
> >
> > I can see how an area such as a parking, a churchyard or pedestrian area
> can be tree lined.
>
>
> I can also see this, but I’m not sure we should use this tag for it.
> Placement on area (borders) will vary a lot, and it would make more sense
> to require explicit trees compared to roads and waterways (IMHO)
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging specialized head lice removal salons

On Thu, 13 Aug 2020 at 00:35, Lisbeth Salander  wrote:

> On Wed, 12 Aug 2020 at 12:52, Paul Allen 
>  wrote:
>


> healthcare:speciality=podiatrist and they remove corns and verrucas. Your
> salons are removing unwanted stuff from the other end of the body. In fact,
> your salons are removing infectious parasites.  I think that qualifies them
> as clinics.
>
> The wiki also lists healthcare=podiatrist. (amenity=podiatrist has its
> own Item page at https://wiki.openstreetmap.org/wiki/Item:Q18252 but is
> probably deprecated.) I can't find a hard rule to decide between
> healthcare and healthcare:speciality; healthcare feels more to-the-point
> for me.
>
healthcare:speciality is a sub-tag of healthcare.  Healthcare itself is
generally with values like doctor, hospital, laboratory and clinic.  Some
values that are far more specific like speech_therapist seem to have
crept in that might be better as specialities.

I'd say the facilities offering headlice removal and nothing else are as
much
clinics as are podiatrists.  Others will disagree, some vehemently.


> healthcare:speciality=head_lice_removal certainly has a very slim chance
> of being rejected, so that's good to know.
>

I think it would be hard to find a valid objection to it.  But I expect
soimebody will
do so anyway.

> > Actually, that's a negative.  If it's a hairdresser offering louse
> removal as one of the services, wouldn't most people think of it as a
> hairdresser? And whichever way you answer that (it's a hairdresser or it's
> a louse remover) it's more code that has to be added to ensure correct
> handling of two top-level tags on a single object.  Having it as one of the
> "beauty" treatments offered by the hairdresser doesn't cause any extra
> problems. Admittedly, it's more complicated to query if you're in a strange
> place and suddenly in need of louse removal...
>
> You don't need specific code for this. Accidentally or not, icon renderers
> already decide between top-level tags in case of conflict (I think I
> remember Mapnik deciding amenity > shop when I really had no idea on how
> to tag a confectionery/café). If people think of them as hairdressers,
> you'd only need to ensure shop has a higher priority than healthcare...
>

That's one renderer at one point in time.  There are no guarantees Mapnik
will
not change.  There are no guarantees other renderers will do the same thing.

If you apply two top-level tags to the same object different renderers may
handle
it differently.  All renderers have to special-case such tagging, even if
it's only code
saying amenity > shop.

...and now you got me thinking about unintended consequences.
>
> I cross-checked the pages for both Key:healthcare and Key:shop.
> https://wiki.openstreetmap.org/wiki/Key:healthcare already lists some
> situation in which shops are linked to healthcare centres, and users are
> expected to map them exclusively as shops.
>
I don't think you can take specific examples and make that generalization.
In all the cases I can think of, that is the case, but there may be
exceptions.  However, I do think that a hairdresser offering head louse
removal is primarily a hairdresser, not a clinic.  But since I've never had
head lice and haven't had my hair cut in over 20 years, I may be missing
some nuances here.

> Seems like if someone still used both tags, the shop tag should have a
> higher priority. Is there any situation where both should be expected, yet
> healthcare should have higher priority than shop?
>
> Or is there another side I'm missing?
>
Yeah, we try to avoid putting two top-level tags on the same object because
of nasal demons:  http://catb.org/jargon/html/N/nasal-demons.html

-- 
Paul


> ___
> 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] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 12:13, Jez Nicholson  wrote:
> 
> Q: if I mark a road as tree_lined=both and later map all the individual 
> trees, do I remove the tree_lined=both tag as I now have finer detail?

as it is stated in the page, you should not do it. Having the individual trees 
mapped does not change the property of the road as being tree lined. Similarly, 
you can map individual trees within a tree row, but you do not have to.

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

Re: [Tagging] Waterway equivalent of noexit=yes?

On Thu, 13 Aug 2020 at 06:42, Mark Wagner  wrote:

>
> For a larger and far more dramatic example of this sort of situation,
> look at the area to the west of Death Valley Playa.  It looks like
> someone stacked hundreds of river deltas on top of one another, but
> forgot to add the water.
>

As I understand it (possibly not all that well) a sinkhole as the wiki
defines it
is a large hole in the ground which water enters and vanishes without
pooling.
What Ordnance Survey calls "sinks" appears to be more akin to a hole in a
golf
course that water enters and vanishes.  What Ordnance Survey calls "spreads"
is a sand or soil or gravel surface that water vanishes into without
pooling and
without there being any noticeable hole.

I'm not sure if any of those fit what you have and maybe what you have is
more of a network of intermittent streams.

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

Re: [Tagging] Tagging specialized head lice removal salons

sent from a phone

> On 14. Aug 2020, at 12:48, Paul Allen  wrote:
> 
> Some
> values that are far more specific like speech_therapist seem to have
> crept in that might be better as specialities.
> 
> I'd say the facilities offering headlice removal and nothing else are as much
> clinics as are podiatrists.

Maybe it’s because I am not an English native speaker, but I would expect 
something more than a head lice removal treatment place or a speech therapist 
when I see healthcare=clinic. I would see it as misleading promising a „clinic“ 
to the map user just to find out that it is a head lice removal or speech 
therapist.

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

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread Yves

Base / mid / head? 

Le 14 août 2020 10:59:11 GMT+02:00, dktue  a écrit :
>
>Am 14.08.2020 um 10:53 schrieb yvecai:
>> On 14.08.20 10:40, dktue wrote:
 I would define it as:

 lower_station: station that has the lowest elevation (exact 
 elevation is not necessary to know, it's obvious)
 upper_station: station that has the highest elevation
 mid_station: any other station
>>> I want to add: At least in Germany, Switzerland and Austria there are 
>>> well-established german words which you often find in the name of the 
>>> stations themselves:
>>>
>>> * "Talstation" ("valley station")
>>> * "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
>>> ("summit station")
>>> * "Mittelstation" ("mid station")
>>>
>>> There should be a machine-readeably tagging to get this information 
>>> that is so often encoded in the name. That's why I'm suggesting this 
>>> tagging.
>>>
>>>
>> Then why not valley / mid / mountain as values ? If the mountain 
>> station is lower than the mid- one, there is no discussion.
>I think the germany word "Talstation" ("valley station") is not flawless 
>as a Talstation might not be in the valley but in the middle of the 
>mountain. I think in the german language "Talstation" refers to the 
>lowest station of an aerialway. That's why I think lower/mid/upper are 
>better suited.
>> But also, my feeling is that it's more defined by the destination of 
>> the stop rather than a property of the aerialway node in question: you 
>> expect maybe a restaurant in the 'mountain station', more rarely in 
>> the 'valley station', you also expect to put your skis on or start 
>> riding your bike in the former, etc ...
>>
>> There is more to a 'mountina station' than being up/down.
>That true but I think there are different tags to add this information.
>
>___
>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] new page for tree_lined=*

On Fri, 14 Aug 2020 at 11:55, Martin Koppenhoefer 
wrote:

>
> as it is stated in the page, you should not do it. Having the individual
> trees mapped does not change the property of the road as being tree lined.
> Similarly, you can map individual trees within a tree row, but you do not
> have to.
>

If that is the case, I don't see the purpose of this tag.  If it's a case
of one or
the other then it serves a purpose: you can avoid tediously adding the tree
rows
and instead add the tree-lined property to save time.  It seems pointless
and
redundant to permit both, and is likely to lead to data inconsistencies over
time: trees get removed so the way tagged as a tree row is removed but
the mapper doesn't notice the tree-lined property on the object.

I'm also doubtful about the utility of the tag anyway.  How close do the
trees
have to be for an object to be tree-lined?  Exactly on the periphery/?
Within
a metre?  Two metres?  Ten metres?  A kilometre?  What if the trees line
only
three of four sides?  Or there are sizable gaps for the entrances?

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

Re: [Tagging] Antwort: Re: Aerialway stations


Am 14.08.2020 um 13:11 schrieb Yves:

Base / mid / head?

I'm definitely open for that! :-)

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

Re: [Tagging] Tagging specialized head lice removal salons

On Fri, 14 Aug 2020 at 12:13, Martin Koppenhoefer 
wrote:

>
> Maybe it’s because I am not an English native speaker, but I would expect
> something more than a head lice removal treatment place or a speech
> therapist when I see healthcare=clinic.

It's stretching the case, perhaps, but not breaking it.  If you wish to
propose
healthcare=piddling_little_jumped_up_overblown_service then I'd happily vote
for it.

> I would see it as misleading promising a „clinic“ to the map user just to
> find out that it is a head lice removal or speech therapist.
>

There are many types of clinic with different specialties.  I would hope
that a user
would look to see what type of clinic it is rather than wander into a
clinic and hope
it happens to specialize in that user's problem.  A user who goes to a
podiatrist
for an abortion is likely to be disappointed, yet they are both clinics.  A
hypnotherapist is unlikely to be able to cure a sexually transmitted
infection.  Etc.

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

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread Colin Smale

On 2020-08-14 13:14, dktue wrote:

> Am 14.08.2020 um 13:11 schrieb Yves: 
> 
>> Base / mid / head?
> I'm definitely open for that! :-)

OK, two people agree on the strings to use, but what are the semantics?
What sentence would go in the wiki to describe a) when to use the value
and b) what the value implies once it is in the OSM data? 

It sounds like it might be something like: 

base: the end station with the lower altitude 
head: the end station with the higher altitude 
mid: any station, not being a base or a head station, irrespective of
the altitude 

note: based purely on altitude, not arrival/departure inclination 

As to which key to use, how about aerialway:station={base,mid,head}?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new page for tree_lined=*

I feel that tree_lined=separate should be used if trees are separately mapped


Aug 14, 2020, 01:06 by dieterdre...@gmail.com:

> I’ve set up an initial documentation page for the tree_lined attribute (used 
> mainly in conjunction with highways and waterways) and welcome comments for 
> it:
>
> https://wiki.openstreetmap.org/wiki/Key:tree_lined
>
>
> This used to be a redirect to natural=tree_row (which is a different tag, as 
> it is for a feature, not an attribute). 
> There are also already translations in 
> cs, de, es and uk (also redirects), which should be updated.
>
> Cheers Martin 
>
>
> sent from a phone
>

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

Re: [Tagging] Antwort: Re: Aerialway stations




Am 14.08.2020 um 13:34 schrieb Colin Smale:


On 2020-08-14 13:14, dktue wrote:


Am 14.08.2020 um 13:11 schrieb Yves:

Base / mid / head?

I'm definitely open for that! :-)
OK, two people agree on the strings to use, but what are the 
semantics? What sentence would go in the wiki to describe a) when to 
use the value and b) what the value implies once it is in the OSM data?

It sounds like it might be something like:
base: the end station with the lower altitude
head: the end station with the higher altitude
mid: any station, not being a base or a head station, irrespective of 
the altitude

note: based purely on altitude, not arrival/departure inclination

That sounds perfectly reasoneable to me!


As to which key to use, how about aerialway:station={base,mid,head}?
I suggested station={base,mid,head} because we're using aerial=station 
and then it seemed natural to go with station=* but I'd be definitely 
happy with aerialway:station=*.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bridge:name and tunnel:name




Aug 13, 2020, 15:01 by em...@daniel-korn.de:

> Here's an example [1] where the name of the tunnel seems to be tagged as 
> "name". I'm not sure what the roads name is (might be Schlossbergtunnel, 
> Hegelstraße or Rheinlandstraße). Tagging it to tunnel:name would definitely 
> clarify on this.
>
> So is there a consensus that one should tag "tunnel:name" instead of "name" 
> for the name of the tunnel?
>
If name or road and tunnel is different - yes.

If name of tunnel is also name of road then name tag should be fine.


> [1] https://www.openstreetmap.org/way/4834663
>
>
> Am 13.08.2020 um 14:56 schrieb Matthew Woehlke:
>
>> On 13/08/2020 08.10, dktue wrote:
>>
>>> the wiki states since more than eight years that there's a debate about 
>>> wether one should tag "tunnel:name" or "name". [1]
>>>
>>> Is there any new opinion in the community on this topic that has not been 
>>> documented in the wiki?
>>>
>>
>> How is the tunnel tagged? If it's a highway that happens to be going through 
>> a tunnel (e.g. https://www.openstreetmap.org/way/361906432) I would expect 
>> that `name` is the name of the *road*, hence if the tunnel also has a name, 
>> it would need to be tagged in some other manner (e.g. tunnel:name).
>>
>> Note that my example *does* have the street name in `name`.
>>
>> If the tunnel is somehow tagged separately from the highway, then I could 
>> see that using `name` as the name of the tunnel. Of course, if the *road 
>> itself* is known by the same name as the tunnel, then it would also make 
>> sense to use `name`.
>>
>
>
> ___
> 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] new page for tree_lined=*

On Fri, 14 Aug 2020 at 12:41, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I feel that tree_lined=separate should be used if trees are separately
> mapped
>

What purpose does tree_lined=separate serve?  Inspection of the map shows
the object is tree-lined.

I still do not see a purpose for the attribute except as a convenient way
of avoiding mapping tree rows.  But the tree rows themselves may not fully
enclose the object whilst the tree_lined attribute implies they do.  It is
always
better to map the tree rows, anyway.

Is there a serious need (other than, say, one person's dissertation) to
perform
database queries to find objects that are tree-lined?  I can see the need to
find the nearest car park with disabled spaces, or vehicle charging points,
but
not for trees lining it.  That's probably just me, but trees lining a car
park do
not influence my choice of whether or not to use it.

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

Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Volker Schmidt

On Fri, 14 Aug 2020, 13:41 Mateusz Konieczny via Tagging, <
tagging@openstreetmap.org> wrote:

> I feel that tree_lined=separate should be used if trees are separately
> mapped
>

This would make it worse because you would have to add this to all objects
with tree lines already tagged with individual trees or tree lines.

Apart from that I would not advocate "overlapping" mapping with three
different schemes: individual trees a separate nodes, tree lines as
separate ways, and the new proposal.
On any given object there should never bee tree rows mapped in different
ways.

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

Re: [Tagging] bridge:name and tunnel:name


Am 14.08.2020 um 14:29 schrieb Mateusz Konieczny via Tagging:




Aug 13, 2020, 15:01 by em...@daniel-korn.de:

Here's an example [1] where the name of the tunnel seems to be
tagged as "name". I'm not sure what the roads name is (might be
Schlossbergtunnel, Hegelstraße or Rheinlandstraße). Tagging it to
tunnel:name would definitely clarify on this.

So is there a consensus that one should tag "tunnel:name" instead
of "name" for the name of the tunnel?

If name or road and tunnel is different - yes.

If name of tunnel is also name of road then name tag should be fine.

So in my example of "Schlossbergtunnel", how would you have it tagged?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Jarek Piórkowski

On Fri, 14 Aug 2020 at 08:34, Paul Allen  wrote:
> I still do not see a purpose for the attribute

That's not what the discussion is about though. The attribute has
already been used 1000 times so the wiki page is documenting the fact
that others saw a purpose for it.

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

Re: [Tagging] bridge:name and tunnel:name




Aug 14, 2020, 14:37 by em...@daniel-korn.de:

> Am 14.08.2020 um 14:29 schrieb Mateusz Konieczny via Tagging:
>  
>
>>
>>
>>
>> Aug 13, 2020, 15:01 by >> em...@daniel-korn.de>> :
>>
>>> Here's an example [1] where the name of the tunnel seems to  be 
>>> tagged as "name". I'm not sure what the roads name is  (might be 
>>> Schlossbergtunnel, Hegelstraße or Rheinlandstraße).  Tagging it to 
>>> tunnel:name would definitely clarify on this.
>>>
>>> So is there a consensus that one should tag "tunnel:name"  instead 
>>> of "name" for the name of the tunnel?
>>>
>> If name or road and tunnel is different - yes.
>>
>> If name of tunnel is also name of road then name tag shouldbe fine.
>>
> So in my example of "Schlossbergtunnel", how would you have ittagged?
>
given
"I'm not sure what the roads name is  (might be Schlossbergtunnel, 
Hegelstraße or Rheinlandstraße)."
it would be

tunnel:name=Schlossbergtunnel
fixme=not sure what the roads name is  (might be Schlossbergtunnel, 
Hegelstraße or Rheinlandstraße), maybe tunnel:name should be changed to name

and require more survey
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new page for tree_lined=*




Aug 14, 2020, 14:35 by vosc...@gmail.com:

>
>
> On Fri, 14 Aug 2020, 13:41 Mateusz Konieczny via Tagging, <> 
> tagging@openstreetmap.org> > wrote:
>
>> I feel that tree_lined=separate should be used if trees are separately mapped
>>
>
> This would make it worse because you would have to add this to all objects 
> with tree lines already tagged with individual trees or tree lines.
>
Not adding that tag would be even better, my comment should not be considered 
as support for it.

Maybe outright recommending removal after trees are mapped would be even better?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread Colin Smale

On 2020-08-14 13:55, dktue wrote:

> Am 14.08.2020 um 13:34 schrieb Colin Smale: 
> 
> On 2020-08-14 13:14, dktue wrote: 
> Am 14.08.2020 um 13:11 schrieb Yves: Base / mid / head? I'm definitely open 
> for that! :-)

OK, two people agree on the strings to use, but what are the semantics?
What sentence would go in the wiki to describe a) when to use the value
and b) what the value implies once it is in the OSM data? 

It sounds like it might be something like: 

base: the end station with the lower altitude 
head: the end station with the higher altitude 
mid: any station, not being a base or a head station, irrespective of
the altitude 

note: based purely on altitude, not arrival/departure inclination 
  That sounds perfectly reasoneable to me!

> As to which key to use, how about aerialway:station={base,mid,head}?
 I suggested station={base,mid,head} because we're using aerial=station
and then it seemed natural to go with station=* but I'd be definitely
happy with aerialway:station=*.

I suggested aerialway:station=* precisely to avoid overloading station=*
(different semantics under different circumstances). 

As a native English speaker by the way I would suggest that "top" and
"bottom" might be simpler instead of "base" and "head". Using easy words
means you don't need to explain it to people who either don't know the
words, or know them in a different context.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new page for tree_lined=*

On Fri, 14 Aug 2020 at 13:45, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Maybe outright recommending removal after trees are mapped would be even
> better?
>

Yes.

But we all know that many people don't read the wiki, they just go by what
the editor gives them.  They see a tree row in aerial imagery, so they add
it.
They don't think to check all the nearby objects that might have been given
a tree-lined attribute so they can remove it.  So we can recommend removal
of the attribute when actual tree rows are added but I wouldn't count on it
happening.

Better, I think, would be to recommend this attribute not be used.

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

Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-14 Thread Kevin Kenny

On Fri, Aug 14, 2020 at 7:08 AM Paul Allen  wrote:

> On Thu, 13 Aug 2020 at 06:42, Mark Wagner  wrote:
>
>>
>> For a larger and far more dramatic example of this sort of situation,
>> look at the area to the west of Death Valley Playa.  It looks like
>> someone stacked hundreds of river deltas on top of one another, but
>> forgot to add the water.
>>
>
> As I understand it (possibly not all that well) a sinkhole as the wiki
> defines it
> is a large hole in the ground which water enters and vanishes without
> pooling.
> What Ordnance Survey calls "sinks" appears to be more akin to a hole in a
> golf
> course that water enters and vanishes.  What Ordnance Survey calls
> "spreads"
> is a sand or soil or gravel surface that water vanishes into without
> pooling and without there being any noticeable hole.
>

The WIki picture of a sinkhole happens to be large, but in karst terrain
they come in all sizes. https://www.openstreetmap.org/node/5599524737 is a
sinkhole of quite a small stream. I couldn't find a good way to tag the
rise a short distance to the west.
https://www.openstreetmap.org/way/226924460 is a much larger sinkhole. In a
wet season there's significant outflow to the east, but in a dry season all
of the outflow from the lake runs through the caves, exiting through cracks
in the limestone below the cliffs to the east. Many of the small streams
thus formed haven't been mapped because there are significant technical
challenges to mapping them. GPS coverage at the cliff bases is so poor that
one would probably have to resort to alidade and plane table, and the
evergreen cover is dense enough that you can't see much that's useful on
satellite imagery.

I'm not sure if any of those fit what you have and maybe what you have is
> more of a network of intermittent streams.
>

What Mark is showing is usually called an alluvial fan.
https://en.wikipedia.org/wiki/Alluvial_fan
Some fans have well-defined (perennial or intermittent) distributary
streams flowing through them. Often, though, most of the stream channels
are ephemeral in nature. Sometimes an individual channel was cut in a
matter of hours by a debris flow coming from upriver.

In arid climates, it's entirely possible for the entire flow of the stream,
except during flash flooding events, to vanish by percolation and
evaporation, so that there is no river downstream. There's no well-defined
sinkhole, and no well-defined specific point at which it transitions from
perennial to intermittent, intermittent to ephemeral, ephemeral to a dry
wadi that has seen water only in geologic time, eventually disappearing
entirely into a salt flat.

It's relatively rare to find a fan that's still actively depositing
sediment. One example is that Mòlèqiē Hé (莫勒切河) in Xinjiang forms an
enormous and nearly unique one near 37.4°  north, 84.3° east.
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging specialized head lice removal salons

sent from a phone

> On 14. Aug 2020, at 13:28, Paul Allen  wrote:
> 
>> Martin Koppenhoefer  wrote:
>> 
>> Maybe it’s because I am not an English native speaker, but I would expect 
>> something more than a head lice removal treatment place or a speech 
>> therapist when I see healthcare=clinic.
> 
> It's stretching the case, perhaps, but not breaking it. 

to put it more bluntly: I see problems and no advantage with this specific  
subtagging approach. OpenStreetMap mostly uses duck tagging, and where more 
“structured” approaches have been used, it was mostly a disadvantage. Typically 
it meant that the “main tag” became useless because of its overly inclusive 
meaning and every meaningful distinction moved into a “secondary” tag which 
could have been used just as well without the main tag. In this case, the 
meaning would shift to healthcare:specialty and the term “clinic” would be 
extended to mean any kind of facility with outpatient treatment, including even 
those with just a single person offering some kind of special healthcare 
service for some hours a week (speech therapist).

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

Re: [Tagging] Antwort: Re: Aerialway stations




Am 14.08.2020 um 14:51 schrieb Colin Smale:


On 2020-08-14 13:55, dktue wrote:



Am 14.08.2020 um 13:34 schrieb Colin Smale:


On 2020-08-14 13:14, dktue wrote:

Am 14.08.2020 um 13:11 schrieb Yves:

Base / mid / head?

I'm definitely open for that! :-)

OK, two people agree on the strings to use, but what are the 
semantics? What sentence would go in the wiki to describe a) when to 
use the value and b) what the value implies once it is in the OSM data?

It sounds like it might be something like:
base: the end station with the lower altitude
head: the end station with the higher altitude
mid: any station, not being a base or a head station, irrespective 
of the altitude

note: based purely on altitude, not arrival/departure inclination

That sounds perfectly reasoneable to me!


As to which key to use, how about aerialway:station={base,mid,head}?
I suggested station={base,mid,head} because we're using 
aerial=station and then it seemed natural to go with station=* but 
I'd be definitely happy with aerialway:station=*.


I suggested aerialway:station=* precisely to avoid overloading 
station=* (different semantics under different circumstances).


As a native English speaker by the way I would suggest that "top" and 
"bottom" might be simpler instead of "base" and "head". Using easy 
words means you don't need to explain it to people who either don't 
know the words, or know them in a different context.



Well then it would be aerialway:station={bottom,mid,top}, right?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

2020-08-14 Thread Andy Townsend


On 12/08/2020 01:37, 80hnhtv4agou--- via Tagging wrote:
i have been to 11 stations in the last 3 weeks, the trains are not 
doing what the tags represent


If you've done this, and care that stop positions are mapped in the 
correct place, then I'd suggest that you actually map these stop 
positions (just as stop positions - don't worry about the relations).  
Add some sort of description that says in which circumstances a 
particular stop position would be used.


If you do that, people adding relations can use those stop positions as 
the see fit.  No-one can guarantee if or when they'll do that, but if 
they do, they'll be able to add the stop positions to relations.




Tuesday, August 11, 2020 7:25 PM -05:00 from Clay Smalley
:
You really need to stop calling people's edits "fake". It's
disrespectful. You're not in a position to determine whether my
edits were estimation or actually fictitious data.


Agree 100%.

No-one has a monopoly on "correct" information - everything is to some 
extent an abstraction.


Best Regards,

Andy


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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 13:13, Paul Allen  wrote:
> 
> What if the trees line only
> three of four sides?  Or there aresome  sizable gaps for the entrances?

indeed I would not suggest to use this on polygons, rather for linear features 
like roads and waterways. I’m specifically interested in roads with associated, 
purposefully planted tree roads (shade, scenic effect). 

If the trees get cut, and the mapping became inconsistent because of partial 
map maintenance, this could get detected automatically by QA tools (it isn’t 
something I would be specifically afraid of, errors can happen all the time, 
and when they are detected they will be fixed).

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 14:35, Paul Allen  wrote:
> 
> I still do not see a purpose for the attribute except as a convenient way
> of avoiding mapping tree rows.

routing. While it is not impossible to find tree lined roads by analyzing the 
context, it is an expensive calculation and will not typically be done by 
routing engines (also because they tend to discard things that aren’t POIs nor 
roads as one of the first steps).

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 14:37, Volker Schmidt  wrote:
> 
> Apart from that I would not advocate "overlapping" mapping with three 
> different schemes: individual trees a separate nodes, tree lines as separate 
> ways, and the new proposal.
> On any given object there should never bee tree rows mapped in different ways.

there isn’t overlap. It’s like mapping buildings and entrances. A tree row is a 
feature in its own right. The tree lined property is a road property. We are 
also mapping buildings and residential landuse and distinguishing residential 
roads. There is nothing special to this.

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

Re: [Tagging] new page for tree_lined=*



sent from a phone

> On 14. Aug 2020, at 16:00, Martin Koppenhoefer  wrote:
> 
> We are also mapping buildings and residential landuse and distinguishing 
> residential roads.


or street lights and the lit property on roads.

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 14:45, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Maybe outright recommending removal after trees are mapped would be even 
> better?

vandalism. It’s like suggesting removing the lit tag after street lamps have 
been added. Or some landuse after buildings have been mapped. Or removing the 
bridge attribute on roads after the bridge object has been mapped as 
man_made=bridge.

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

Re: [Tagging] bridge:name and tunnel:name

sent from a phone

> On 14. Aug 2020, at 14:31, Mateusz Konieczny via Tagging 
>  wrote:
> 
> If name of tunnel is also name of road then name tag should be fine.

how would you know whether the name is for the road or the tunnel if there is 
only a name tag? What about setting both tags with the same value in this case?

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

Re: [Tagging] Waterway equivalent of noexit=yes?

On Fri, 14 Aug 2020 at 14:21, Kevin Kenny  wrote:

>
> The WIki picture of a sinkhole happens to be large, but in karst terrain
> they come in all sizes. https://www.openstreetmap.org/node/5599524737 is
> a sinkhole of quite a small stream.
>

It's been a long time since I've been near (never on) karst.  The stuff I
saw had
no sign of running water or channels at the time but was pocked with many
holes
(presumably caused by rainfall alone) large enough for a person or a sheep
to fall into.

The way the wiki has it, I don't think sinkhole is appropriate for small
streams
vanishing into small holes that even a cat couldn't drop into.

>
> What Mark is showing is usually called an alluvial fan.
> https://en.wikipedia.org/wiki/Alluvial_fan
> Some fans have well-defined (perennial or intermittent) distributary
> streams flowing through them. Often, though, most of the stream channels
> are ephemeral in nature. Sometimes an individual channel was cut in a
> matter of hours by a debris flow coming from upriver.
>

Ah-ha.  I recently saw a network that could be one of those.  Search the map
for "Teifi Pools" then zoom out, a lot.  I fixed some lake names, fixed
which of
two tributaries was the main one on a river and a couple of streams, and
named
a couple of streams.  Oh, and added a dam to a reservoir. I didn't do
anything about
tweaking the waterways that had been crudely mapped, or adding the
tangle of waterways shown on OS OpenData StreetView that haven't been
mapped.  That might be an alluvial fan with intermittent and ephemeral
waterways,
although the slope countours don't seem to support that idea.  Doing a full
tidy-up
on that was more work than I felt like doing, so I didn't worry about it.

I wouldn't even have done that much, but the local newspaper mentioned the
area
and I corrected a few egregious errors as well as adding a locality so that
it
would at least turn up on a search.  Now I've had another look around the
wider area to try to identify if it's an alluvial fan I see more misnamed
streams
and missing streams.  I've just fixed some of them.  I want to forget the
entire place exists - far too much work to do it all right.

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

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread yvecai


I would propose, if you want to use altitude as a definition:

   bottom: the end station with the lower altitude
   up: the end station with the higher altitude
   mid: any station, not being a base or a head station, irrespective
   of the altitude

Or, alternatively one that does not compete with the ele tag and carry a 
destination meaning (my preference):


   base: the 'valley' station, usually with the lower altitude
   head: the 'mountain' or 'top' station, usually with the higher altitude
   mid: any station, not being a base or a head station.

aewrialway:station has my preference

Yves

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

Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-14 Thread Joseph Eisenberg

The “rise” where the stream comes back to the surface would usually be
mapped as natural=spring

If there is also a cave entrance at the same spot where the watercourse
exits a cave, then the tag natural=cave_entrance can be used

- Joseph

On Fri, Aug 14, 2020 at 6:21 AM Kevin Kenny  wrote:

> On Fri, Aug 14, 2020 at 7:08 AM Paul Allen  wrote:
>
>> On Thu, 13 Aug 2020 at 06:42, Mark Wagner  wrote:
>>
>>>
>>> For a larger and far more dramatic example of this sort of situation,
>>> look at the area to the west of Death Valley Playa.  It looks like
>>> someone stacked hundreds of river deltas on top of one another, but
>>> forgot to add the water.
>>>
>>
>> As I understand it (possibly not all that well) a sinkhole as the wiki
>> defines it
>> is a large hole in the ground which water enters and vanishes without
>> pooling.
>> What Ordnance Survey calls "sinks" appears to be more akin to a hole in a
>> golf
>> course that water enters and vanishes.  What Ordnance Survey calls
>> "spreads"
>> is a sand or soil or gravel surface that water vanishes into without
>> pooling and without there being any noticeable hole.
>>
>
> The WIki picture of a sinkhole happens to be large, but in karst terrain
> they come in all sizes. https://www.openstreetmap.org/node/5599524737 is
> a sinkhole of quite a small stream. I couldn't find a good way to tag the
> rise a short distance to the west.
> https://www.openstreetmap.org/way/226924460 is a much larger sinkhole. In
> a wet season there's significant outflow to the east, but in a dry season
> all of the outflow from the lake runs through the caves, exiting through
> cracks in the limestone below the cliffs to the east. Many of the small
> streams thus formed haven't been mapped because there are significant
> technical challenges to mapping them. GPS coverage at the cliff bases is so
> poor that one would probably have to resort to alidade and plane table, and
> the evergreen cover is dense enough that you can't see much that's useful
> on satellite imagery.
>
> I'm not sure if any of those fit what you have and maybe what you have is
>> more of a network of intermittent streams.
>>
>
> What Mark is showing is usually called an alluvial fan.
> https://en.wikipedia.org/wiki/Alluvial_fan
> Some fans have well-defined (perennial or intermittent) distributary
> streams flowing through them. Often, though, most of the stream channels
> are ephemeral in nature. Sometimes an individual channel was cut in a
> matter of hours by a debris flow coming from upriver.
>
> In arid climates, it's entirely possible for the entire flow of the
> stream, except during flash flooding events, to vanish by percolation and
> evaporation, so that there is no river downstream. There's no well-defined
> sinkhole, and no well-defined specific point at which it transitions from
> perennial to intermittent, intermittent to ephemeral, ephemeral to a dry
> wadi that has seen water only in geologic time, eventually disappearing
> entirely into a salt flat.
>
> It's relatively rare to find a fan that's still actively depositing
> sediment. One example is that Mòlèqiē Hé (莫勒切河) in Xinjiang forms an
> enormous and nearly unique one near 37.4°  north, 84.3° east.
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] new page for tree_lined=*

On Fri, 14 Aug 2020 at 14:55, Martin Koppenhoefer 
wrote:

>
> indeed I would not suggest to use this on polygons, rather for linear
> features like roads and waterways. I’m specifically interested in roads
> with associated, purposefully planted tree roads (shade, scenic effect).
>

 Around here there are roads several miles long lined with trees.  I've
rarely
mapped them unless there was a compelling reason, but adding this attribute
to the road doesn't really help.  There will be hundreds of metres that are
tree-lined, then anywhere from 10 to hundreds of metres of ordinary hedge,
then more trees.  It can be trees on both sides, or one side, or
alternating.
I hope you get the idea.  I don't think I've seen any stretch of road which
is continuously lined with trees along its entire length.  To use this
attribute I'd have to put many splits in the way.

I wouldn't use this attribute on anything around here.  I wouldn't recommend
that anybody else use it.  In fact, I'd recommend they don't.

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

Re: [Tagging] new page for tree_lined=*

On Fri, 14 Aug 2020 at 15:07, Martin Koppenhoefer 
wrote:

>
> > On 14. Aug 2020, at 14:45, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Maybe outright recommending removal after trees are mapped would be even
> better?
>
> vandalism. It’s like suggesting removing the lit tag after street lamps
> have been added. Or some landuse after buildings have been mapped. Or
> removing the bridge attribute on roads after the bridge object has been
> mapped as man_made=bridge.
>

You seem to be making a number of assumptions.

1) That "tree-lined" is a useful independent property of objects in the
same way that "lit" is.  I disagree.  It is, at best, a trivial property.

2) That "tree-lined" (which requires a query tool to find) is more useful
than a tree row for end users.  I disagree.

3) That, one day, routers might preferentially route along tree-lined roads
rather than non-tree-lined roads, in the same way they preferentially route
along lit roads.  Do any route along lit roads?  I can see that a router
which
offers walking routes might eventually prefer lit routes.

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 16:45, Paul Allen  wrote:
> 
> I wouldn't use this attribute on anything around here. 

that’s fine. Apparently this attribute wasn’t created for an area like yours. 
Nobody said you should use it. There are other areas in the world where these 
are common and seen as interesting features. There are even already specific 
maps that cater for them (I think I have seen one from the German automobile 
club ADAC), and here in Italy they are common. Many people love them because 
they provide shade and are perceived as beautiful, but particularly in Germany 
they are also perceived as dangerous sometimes, because young drunken drivers 
end their lifes on the tree trunks saturday nights in the countryside.

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

Re: [Tagging] Waterway equivalent of noexit=yes?

On Fri, 14 Aug 2020 at 15:42, Joseph Eisenberg 
wrote:

> The “rise” where the stream comes back to the surface would usually be
> mapped as natural=spring
>

Ordnance Survey makes the distinction between issues and springs.  An issue
is where a waterway reappears after a (natural, not a culvert) journey
underground.
A spring is, as far as I can tell, a result of rainfall percolating into
the ground rather
than the reappearance of a waterway that disappeared elsewhere.

Ordnance Survey also makes the distinction between springs and wells (as in
upwellings of water, I think, not as in holes somebody dug and dips a bucket
into) but I have yet to find out what that distinction is.

I'm not saying that OS is right to make those distinctions.  I'm not saying
we should automatically do what they do.  But I do think we ought to
consider
what they've done and think about it before committing ourselves.  Maybe see
what other national mapping agencies like USGS do.  If they do it, it's
probably for a reason (although it may be a bad one).

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

Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Justin Tracey

On 2020-08-14 10:48 a.m., Paul Allen wrote:
>
>
> 3) That, one day, routers might preferentially route along tree-lined
> roads
> rather than non-tree-lined roads, in the same way they preferentially
> route
> along lit roads.  Do any route along lit roads?  I can see that a
> router which
> offers walking routes might eventually prefer lit routes.
>
>
Not only are there routers that prefer lit routes, there are already
multiple routers that seek shade from things like trees (featured in the
last weeklyOSM):

http://k1z.blog.uni-heidelberg.de/2020/07/31/do-you-need-a-shady-route-because-it-is-too-hot-2/

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

Re: [Tagging] bridge:name and tunnel:name




Am 14.08.2020 um 16:21 schrieb Martin Koppenhoefer:

On 14. Aug 2020, at 14:31, Mateusz Konieczny via Tagging 
 wrote:

If name of tunnel is also name of road then name tag should be fine.


how would you know whether the name is for the road or the tunnel if there is 
only a name tag? What about setting both tags with the same value in this case?


I agree. That way tagging-errors or missing tagging is easier to detect

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

Re: [Tagging] Antwort: Re: Aerialway stations


Am 14.08.2020 um 16:37 schrieb yvecai:


I would propose, if you want to use altitude as a definition:

bottom: the end station with the lower altitude
up: the end station with the higher altitude
mid: any station, not being a base or a head station, irrespective
of the altitude

Or, alternatively one that does not compete with the ele tag and carry 
a destination meaning (my preference):


base: the 'valley' station, usually with the lower altitude
head: the 'mountain' or 'top' station, usually with the higher
altitude
mid: any station, not being a base or a head station.

aewrialway:station has my preference

Yves

I like both. Any other people here with a peference for one of Yves' 
schemes?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread Colin Smale

We really should avoid words like "usually. " If there exceptions to the 
elevation critérium, or if other factors are significant in working out the 
correct value, then this also needs documenting...



On 14 August 2020 17:05:37 CEST, dktue  wrote:
>Am 14.08.2020 um 16:37 schrieb yvecai:
>>
>> I would propose, if you want to use altitude as a definition:
>>
>> bottom: the end station with the lower altitude
>> up: the end station with the higher altitude
>> mid: any station, not being a base or a head station,
>irrespective
>> of the altitude
>>
>> Or, alternatively one that does not compete with the ele tag and
>carry 
>> a destination meaning (my preference):
>>
>> base: the 'valley' station, usually with the lower altitude
>> head: the 'mountain' or 'top' station, usually with the higher
>> altitude
>> mid: any station, not being a base or a head station.
>>
>> aewrialway:station has my preference
>>
>> Yves
>>
>I like both. Any other people here with a peference for one of Yves' 
>schemes?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

I strongly prefer up/top over head.

At least for me (not representative,
not a native speaker), head = up
is not clear.

14 Aug 2020, 17:05 by em...@daniel-korn.de:

> Am 14.08.2020 um 16:37 schrieb yvecai:
>  
>
>>
>> I would propose, if you want to use altitude as a definition:
>>
>>
>>> bottom: the end station with the lower altitude
>>> up: the end station with the higher altitude
>>> mid: any station, not being a base or a head  station, irrespective 
>>> of the altitude
>>>
>>
>> Or, alternatively one that does not compete with the ele tag  and 
>> carry a destination meaning (my preference):
>>
>>
>>> base: the 'valley' station, usually with the lower  altitude
>>> head: the 'mountain' or 'top' station, usually  with the higher 
>>> altitude
>>> mid: any station, not being a base or a head  station.
>>>
>>>
>>
>> aewrialway:station has my preference
>>
>>
>> Yves
>>
>>
> I like both. Any other people here with a peference for one of Yves'
> schemes?
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread Yves

I'm not a natural speaker, head like in where the aerialway is heading.
I propose the second scheme because of the duplicate meaning with ele in the 
definition, and because the aim of an aerialway could be lower than mid. 
Yves 

Le 14 août 2020 17:32:08 GMT+02:00, Mateusz Konieczny via Tagging 
 a écrit :
>I strongly prefer up/top over head.
>
>At least for me (not representative,
>not a native speaker), head = up
>is not clear.
>
>14 Aug 2020, 17:05 by em...@daniel-korn.de:
>
>> Am 14.08.2020 um 16:37 schrieb yvecai:
>>  
>>
>>>
>>> I would propose, if you want to use altitude as a definition:
>>>
>>>
 bottom: the end station with the lower altitude
 up: the end station with the higher altitude
 mid: any station, not being a base or a head  station, 
 irrespective of the altitude

>>>
>>> Or, alternatively one that does not compete with the ele tag  and 
>>> carry a destination meaning (my preference):
>>>
>>>
 base: the 'valley' station, usually with the lower  altitude
 head: the 'mountain' or 'top' station, usually  with the higher 
 altitude
 mid: any station, not being a base or a head  station.


>>>
>>> aewrialway:station has my preference
>>>
>>>
>>> Yves
>>>
>>>
>> I like both. Any other people here with a peference for one of Yves'
>> schemes?
>>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=yes on motorways

2020-08-14 Thread António Madeira via Tagging


So, should this contradiction be eliminated from the wiki or not?


Às 09:32 de 26/05/2020, Mateusz Konieczny via Tagging escreveu:

Based on my experience it is usually better to write something, even
not ideal and
ask for a review.

"Someone should write/expand it" is typically ignored.

May 26, 2020, 10:58 by vosc...@gmail.com:

Please come back to my original question: /I would like to
eliminate the contradiction in the wiki. What wording do you propose?/

On Tue, 26 May 2020 at 10:23, Jean-Marc Liotier mailto:j...@liotier.org>> wrote:

On 5/26/20 5:44 AM, Paul Johnson wrote:


It can't hurt to specify oneway=yes. I have noticed that
the JOSM style
that shows lane counts and lane use will sometimes not
show ways
properly if oneway=yes isn't there, but that's probably a
bug in the
style more than an indictment of implying oneway=yes.


I'm on the side of "team tag explicitly" on this.  If
anything, it gives validators more to work with if you start
doing something weird.


Isn't that what oneway=no is for ?

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



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


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

[Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent

2020-08-14 Thread Hidde Wieringa

Good day,

I am having trouble with the tourism tags caravan_site and camp_site,
specifically for the use case of finding a place to camp with a tent (so
not a caravan or a camper van).

My goal is to differentiate the two tags. Both tags allow tents, and
both allow camper vans and caravans. Both tags may or may not provide
facilities such as toilets, water, electricity, et cetera. In practice,
the only thing that differentiates a pitch for a tent versus a pitch for
a caravan or camper van, is the ground underneath (tents require some
sort of soft material like grass). This differentiating property is not
mentioned at all in the Wiki.

- The tag tents=yes/no (only listed in the camp_site Wiki) would be a
good way to find a place to camp with a tent, but almost none of the
caravan_site have this tag. All camp_sites in OSM I have camped on,
allowed tents.
- Some of the caravan_site have been tagged with amenity=parking or even
surface=asphalt and this would mean that camping with a tent is
definitely not possible.
- I noticed that both of the tags have status 'de facto', and no
proposals have been made for the definition of said tags. I found an
abandoned proposal [1] that has a good discussion about camping [2].
- Some camp_sites have a 'nested' polygon with a caravan_site. This
seems logical, and the caravan_site can be ignored, and the camp_site
can be used for camping with a tent.

Statistics from TagInfo: camp_site has ~100,000 uses, and caravan_site
has ~30,000 uses.

I ran a quick Overpass query for a small number of caravan sites (~15)
[3]. Some of them note on their website that camping with a tent is
possible, and the surface of the pitches seems to be grass. I am
wondering if these should be re-tagged as camp_site, or if I am missing
something.

My opinion would be that a camp_site should allow staying overnight with
many types of vehicles/tents, indicated by the tags listed clearly on
the wiki of camp_site. A caravan_site would allow staying overnight with
vehicles only, and not allow camping with a tent. Concretely the
sentence "They may also have some space for tents." on [4] is the
problem. Replacing the sentence on the wiki with "Camping with a tent is
not possible." would remove any ambiguity differentiating these tags.

Any comments are welcome. I am willing to update the wiki or draft a
proposal for differentiating these two tags, if necessary.

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
[2]
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_camp_site#caravan_site_separated.3F

[3] https://tyrasd.github.io/overpass-turbo

[4] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site

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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent




Aug 14, 2020, 20:49 by hi...@hiddewieringa.nl:

>
> My goal is to differentiate the two tags. Both tags allow tents,  and 
> both allow camper vans and caravans. Both tags may or may not  provide 
> facilities such as toilets, water, electricity, et cetera.  In practice, 
> the only thing that differentiates a pitch for a tent  versus a pitch for 
> a caravan or camper van, is the ground  underneath
>
>
Not only. There is also a question of access, there are places where caravans 
would be unable to
reach and/or it would be illegal. Such as mountaintop or place in a protected 
area restricting 
vehicle traffic.

>  (tents require some sort of soft material like grass).  This 
> differentiating property is not mentioned at all in the Wiki.
>
Feel free to mention it!

>
>
> - The tag tents=yes/no (only listed in the camp_site Wiki) would  be a 
> good way to find a place to camp with a tent, but almost none  of the 
> caravan_site have this tag. All camp_sites in OSM I have  camped on, 
> allowed tents.
>
>
>
It seems to me like tag worth adding - you can start mapping it, mention on 
caravan site on wiki
and maybe suggest support in various editors (if not rejected already and 
fitting)

>
>
>  -- I noticed that both of the tags have status 'de facto', and no  
> proposals have been made for the definition of said tags. 
>
>
>
This is typical for many OSM tags.

>
>
> I ran a quick Overpass query for a small number of caravan sites  (~15) 
> [3].
>
>
>
This is a very valuable method for exploring how tagging is used in practice.

>
>
>  Some of them note on their website that camping with a  tent is 
> possible, and the surface of the pitches seems to be  grass. I am 
> wondering if these should be re-tagged as camp_site,  or if I am missing 
> something.
>
>
>
> My opinion would be that a camp_site should allow staying  overnight with 
> many types of vehicles/tents, indicated by the tags  listed clearly on 
> the wiki of camp_site. A caravan_site would  allow staying overnight with 
> vehicles only, and not allow camping  with a tent. 
>
>
I think that something with space for 200 caravans and 2 tents would be well 
tagged as caravan_site.
Similarly, objects where tents are allowed only if there is plenty of free 
space.

> Concretely the sentence "They may also have some  space for tents." on 
> [4] is the problem. Replacing the sentence on  the wiki with "Camping 
> with a tent is not possible." would remove  any ambiguity differentiating 
> these tags.
>
The problem is that wiki edit will not magically resurvey all of them. With 
such de facto tags
it is typically too late to redefine them and OSM Wiki documents actual use.

> Any comments are welcome. I am willing to update the wiki or  draft a 
> proposal for differentiating these two tags, if necessary.
>
Thanks for posting to this list to discuss it!

I think that better way to handle this may be promotion of tag for marking
"are tents allowed here".

Maybe it is something that should be added as field to editors for relevant 
object?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=yes on motorways

It is nicer to avoid contradictions, but I am not planning to work on this 
specific case.

If you want you may propose specific edit and post it here for review 
(or make it and discuss if someone disagrees).

"Someone should write/expand it" is typically ignored.

Aug 14, 2020, 20:35 by tagging@openstreetmap.org:

> So, should this contradiction be eliminated from the wiki or not?
>  
>  
>  
> Às 09:32 de 26/05/2020, Mateusz  Konieczny via Tagging escreveu:
>
>> Based on my experience it is usually better to writesomething, even 
>> not ideal and
>> ask for a review.
>>
>> "Someone should write/expand it" is typically ignored.
>>
>> May 26, 2020, 10:58 by >> vosc...@gmail.com>> :
>>
>>> Please come back to my original question: >>> Iwould like to 
>>> eliminate the contradiction in the wiki. Whatwording do you 
>>> propose?
>>>
>>> On Tue, 26 May 2020 at 10:23,Jean-Marc Liotier <>>> 
>>> j...@liotier.org>>> > wrote:
>>>
 On 5/26/20 5:44 AM, Paul Johnson wrote:

>
>
>> It can't hurt to specify oneway=yes. I have  
>> noticed that the JOSM style
>> that shows lane counts and lane use will  
>> sometimes not show ways
>> properly if oneway=yes isn't there, but  that's 
>> probably a bug in the
>> style more than an indictment of implying  
>> oneway=yes.
>>
>
> I'm on the side of "team tagexplicitly" on this.  If 
> anything, it givesvalidators more to work with if you 
> start doingsomething weird.
>

 Isn't that what oneway=no is for ?

 ___
 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] new page for tree_lined=*




Aug 14, 2020, 16:04 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 14. Aug 2020, at 14:45, Mateusz Konieczny via Tagging 
>>  wrote:
>>
>> Maybe outright recommending removal after trees are mapped would be even 
>> better?
>>
>
>
> vandalism
>
This is typically used for deliberately malicious actions.

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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent


sent from a phone

> On 14. Aug 2020, at 20:51, Hidde Wieringa  wrote:
> 
> Both tags allow tents, and both allow camper vans and caravans.


interesting, I would have expected a caravan site to not permit tents by 
default.

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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent



sent from a phone

> On 14. Aug 2020, at 22:09, Mateusz Konieczny via Tagging 
>  wrote:
> 
> - The tag tents=yes/no (only listed in the camp_site Wiki) would be a good 
> way to find a place to camp with a tent, but almost none of the caravan_site 
> have this tag. All camp_sites in OSM I have camped on, allowed tents.
> It seems to me like tag worth adding - you can start mapping it, mention on 
> caravan site on wiki
> and maybe suggest support in various editors (if not rejected already and 
> fitting)


there are also camp sites that require you set up a tent (i.e. they would not 
let you sleep outside on the ground).


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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent



sent from a phone

> On 14. Aug 2020, at 22:24, Martin Koppenhoefer  wrote:
> 
>> Both tags allow tents, and both allow camper vans and caravans.
> 
> 
> interesting, I would have expected a caravan site to not permit tents by 
> default.


actually the caravan site puts it a little differently than the above summary:

“ They may also have some space for tents. If a site is primarily for tents, it 
should be tagged as tourism=camp_site”

so the tents, while possible, will play a minor role in caravan sites, 
according to the wiki, and it may not be possible to set them up at all.

Maybe, rather than tents=yes/no it could be a property like capacity:tents=n
where no would be expressed as n=0

looked it up, and bang, already in use: 
https://taginfo.openstreetmap.org/keys/capacity%3Atents#combinations


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

Re: [Tagging] new page for tree_lined=*

On Fri, 14 Aug 2020 at 15:56, Martin Koppenhoefer 
wrote:

>
> > On 14. Aug 2020, at 16:45, Paul Allen  wrote:
> >
> > I wouldn't use this attribute on anything around here.
>
>
> that’s fine. Apparently this attribute wasn’t created for an area like
> yours.

Apparently not.

Nobody said you should use it. There are other areas in the world where
> these are common and seen as interesting features.

Interesting, maybe.  A property of the road?  Not that I can see.  Speed
limit,
number of lanes, surface and lighting are all properties of the road.
Trees at
the side of the road are an incidental.  Fields at the side of the road are
an
incidental.  Quaint houses at the side of the road are an incidental.

> There are even already specific maps that cater for them (I think I have
> seen one from the German automobile club ADAC), and here in Italy they are
> common.

They are so common as to be inescapable here.  But not, I think of special
interest, perhaps because they are so common.  Here it would be as silly
as insisting on tagging hedge-lined roads, because hedges are prettier than
fences.  Maybe we should have fence-lined roads, too, because some fences
are pretty.

> Many people love them because they provide shade and are perceived as
> beautiful, but particularly in Germany they are also perceived as dangerous
> sometimes, because young drunken drivers end their lifes on the tree trunks
> saturday nights in the countryside.
>

Dangerous also, perhaps, because of leaves being shed in the autumn
resulting
in slippery road surfaces.

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 22:50, Paul Allen  wrote:
> 
> Trees at
> the side of the road are an incidental.  Fields at the side of the road are an
> incidental.  Quaint houses at the side of the road are an incidental.

no, the trees we are looking at are not incidental, they are part of the road. 
They are a feature of the road, are on the land of the road. The fields are 
beyond the road, they are on different grounds.

>  
>> There are even already specific maps that cater for them (I think I have 
>> seen one from the German automobile club ADAC), and here in Italy they are 
>> common.
> 
> They are so common as to be inescapable here.  But not, I think of special
> interest, perhaps because they are so common.  Here it would be as silly
> as insisting on tagging hedge-lined roads, because hedges are prettier than
> fences.  Maybe we should have fence-lined roads, too, because some fences
> are pretty.

Fences and hedges also are on private ground (at least this is the typical 
situation when the properties along the road have hedges or are fenced). There 
are some notable exceptions, e.g. motorways and high speed train routes. In 
these cases there would indeed be room for a specific tag on the road or 
railway as well.

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

Re: [Tagging] new page for tree_lined=*

On Fri, 14 Aug 2020 at 22:04, Martin Koppenhoefer 
wrote:

>
> On 14. Aug 2020, at 22:50, Paul Allen  wrote:
>
> Trees at
> the side of the road are an incidental.  Fields at the side of the road
> are an
> incidental.  Quaint houses at the side of the road are an incidental.
>
>
>
> no, the trees we are looking at are not incidental, they are part of the
> road. They are a feature of the road, are on the land of the road. The
> fields are beyond the road, they are on different grounds.
>

I start to suspect we're using different definitions of "road."  Or
different
definitions of "tree-lined."  Or different definitions of "tree."

I'd almost think you were talking of the landscaping feature of private
gardens known as an avenue (the word has been much debased in
English, where it used to correspond to the French allée) but this
discussion
appears to have been about roads in general, not ornamental ways.

>
> They are so common as to be inescapable here.  But not, I think of special
> interest, perhaps because they are so common.  Here it would be as silly
> as insisting on tagging hedge-lined roads, because hedges are prettier than
> fences.  Maybe we should have fence-lined roads, too, because some fences
> are pretty.
>
>
> Fences and hedges also are on private ground (at least this is the typical
> situation when the properties along the road have hedges or are fenced).
>

And this is the case for most of the roads around here, but the trees are
part
of the hedge.  On private ground.  You don't get to walk around the trunks
because of the hedge (or fence) between the trunks.  See, for example,
https://goo.gl/maps/QKsezC9bqsea1twy9 and keep going in that direction.
They're not ornamental or even for shade, they're windbreaks (or the
farmers have been too lazy to trim their hedges for many decades).

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

Re: [Tagging] oneway=yes on motorways

2020-08-14 Thread António Madeira via Tagging


In this

section, I suggest changing the text:
"These ways should all point direction of travel and be tagged with
oneway=yes."

to

"These ways should all point direction of travel and imply oneway=yes
(like junction=roundabout), therefore the oneway tag is redundant and
should be avoided."



Às 17:09 de 14/08/2020, Mateusz Konieczny via Tagging escreveu:

It is nicer to avoid contradictions, but I am not planning to work on
this specific case.

If you want you may propose specific edit and post it here for review
(or make it and discuss if someone disagrees).

"Someone should write/expand it" is typically ignored.

Aug 14, 2020, 20:35 by tagging@openstreetmap.org:

So, should this contradiction be eliminated from the wiki or not?



Às 09:32 de 26/05/2020, Mateusz Konieczny via Tagging escreveu:

Based on my experience it is usually better to write something,
even not ideal and
ask for a review.

"Someone should write/expand it" is typically ignored.

May 26, 2020, 10:58 by vosc...@gmail.com :

Please come back to my original question: /I would like to
eliminate the contradiction in the wiki. What wording do you
propose?/

On Tue, 26 May 2020 at 10:23, Jean-Marc Liotier
mailto:j...@liotier.org>> wrote:

On 5/26/20 5:44 AM, Paul Johnson wrote:


It can't hurt to specify oneway=yes. I have noticed
that the JOSM style
that shows lane counts and lane use will sometimes
not show ways
properly if oneway=yes isn't there, but that's
probably a bug in the
style more than an indictment of implying oneway=yes.


I'm on the side of "team tag explicitly" on this.  If
anything, it gives validators more to work with if you
start doing something weird.


Isn't that what oneway=no is for ?

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



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




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


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

Re: [Tagging] Tagging specialized head lice removal salons

On Fri, 14 Aug 2020 at 21:28, Paul Allen  wrote:

> There are many types of clinic with different specialties.  I would hope
> that a user
> would look to see what type of clinic it is rather than wander into a
> clinic and hope
> it happens to specialize in that user's problem.
>

& that can still happen with well-defined specialties!

I've just had a hip replacement done, so saw the orthopaedic surgeon this
week for a follow up. While I was waiting, his receptionist took a call, &
had to tell the caller that "I'm sorry, Dr doesn't work on wrists. He
specialises in hips & knees"

On Fri, 14 Aug 2020 at 12:13, Martin Koppenhoefer 
wrote:

> I would see it as misleading promising a „clinic“ to the map user just to
> find out that it is a head lice removal or speech therapist.

I would think that, in a majority of cases, the name would also give things
away? Somebody looking at a clinic called "No More Nits", isn't likely to
think it was a speech therapist, or a GP!

Thanks

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

Re: [Tagging] new page for tree_lined=*

sent from a phone

> On 14. Aug 2020, at 23:56, Paul Allen  wrote:
> 
> I'd almost think you were talking of the landscaping feature of private
> gardens known as an avenue

yes, think of these, but also on public roads (although they’re an ornamental 
feature and not just functional), basically these are landscape features, 
rhythm is important, it’s not just some trees scattered along a road

> this is the case for most of the roads around here, but the trees are part
> of the hedge.  On private ground.  You don't get to walk around the trunks
> because of the hedge (or fence) between the trunks.  See, for example,
> https://goo.gl/maps/QKsezC9bqsea1twy9 and keep going in that direction.

this is a hedge, or maybe natural=scrub, I would not use the tree_lined tag for 
these

> They're not ornamental or even for shade, they're windbreaks

yes, and to separate the street from the adjacent properties.

Here are some images I had in mind:

basically all of these:

https://duckduckgo.com/?q=allee+toskana&iax=images&ia=images

(note the German syntax ;-) )

https://duckduckgo.com/?q=allee+brandenburg&iar=images&iax=images&ia=images

I would have added more specific definitions like rhythm of trees, type of 
trees (usually the same or alternating), scenic intention, but as this is an 
existing tag it would have been useful to get feedback from those who have used 
the tag in the past, in order not to overload it with expectations which are 
not met by the actual usage.

AFAIR, tree_lined was a compromise because allée is a French term and people 
couldn’t agree on the meaning of “avenue”.

A part from real roads, these can also be found on private driveways, at least 
in Italy they are quite common in some regions.

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

Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Christian Müller via Tagging

> On Fri, 14 Aug 2020 at 14:33, Paul Allen via Tagging 
> mailto:tagging@openstreetmap.org]> wrote:

> Is there a serious need (other than, say, one person's dissertation) to 
> perform
> database queries to find objects that are tree-lined?  I can see the need to
> find the nearest car park with disabled spaces, or vehicle charging points, 
> but
> not for trees lining it.  That's probably just me, but trees lining a car 
> park do
> not influence my choice of whether or not to use it.

It may be important to the crazy people that still use their bicycle
in an otherwise air-conditioned, motorized world.  "Back in the days"
people with a less strange relation to mother nature knew that a tree
lined way has much more comfort cycling on if these trees spend shadow
on a sunny day.  If you do long-distance cycling it may be of interest
to find a route not predominantly exposed to sheer sun.

/rants on/
Unfortunately, most people do not seem to care.  Driving a car is
"god given" and if you say anything people go crazy.  If you don't
own something that makes noise and pollutes the environment, di-
rectly by fumes or indirectly by production (the electro hype),
you're deemed impotent or low-performing.  And anti-mobbing
courses are beyond the scope of OSM. :.p
/rants off/

Greetings

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

Re: [Tagging] bridge:name and tunnel:name

2020-08-14 Thread Arne Johannessen

dktue  wrote:
> 
> Here's an example [1] where the name of the tunnel seems to be tagged as 
> "name". I'm not sure what the roads name is (might be Schlossbergtunnel, 
> Hegelstraße or Rheinlandstraße).

It's not clear if the part of the road inside the tunnel is named at all 
(perhaps not, as it might not serve any practical purpose).

> Tagging it to tunnel:name would definitely clarify on this.

I see no problem with adding tunnel:name=* in addition to name=*.

However, name=* should always contain the primary name of a feature. For a road 
tunnel, the primary name is typically the tunnel's name, as the tunnel is 
usually a more prominent feature than the road is.

Therefore the tag name=Schlossbergtunnel shouldn't be removed.

> [1] https://www.openstreetmap.org/way/4834663

-- 
Arne Johannessen

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

Re: [Tagging] bridge:name and tunnel:name



sent from a phone

> On 15. Aug 2020, at 00:36, Arne Johannessen  wrote:
> 
> However, name=* should always contain the primary name of a feature. For a 
> road tunnel, the primary name is typically the tunnel's name, as the tunnel 
> is usually a more prominent feature than the road is.


IMHO a feature with highway=* and tunnel =yes is not a tunnel but a road inside 
a tunnel. Imagine a divided carriageway in the same tube, this is still one 
tunnel, not two.



> 
> Therefore the tag name=Schlossbergtunnel shouldn't be removed.


agreed 


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

Re: [Tagging] bridge:name and tunnel:name

2020-08-14 Thread Arne Johannessen

Martin Koppenhoefer  wrote:
> 
> IMHO a feature with highway=* and tunnel =yes is not a tunnel but a road 
> inside a tunnel.

IMHO it's not either/or, it's both at the same time.

But I don't think it really matters. In most cases, there is no practical 
difference between the road in a tunnel and the tunnel for a road. That's 
precisely why man_made=tunnel is so rare.

-- 
Arne Johannessen

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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent

But what do you do for a place, called a Camping Ground, that is a big area
of grass, mostly without defined "pitches" & where you can camp anyway you
like: sleep in your car; on the ground; in a tent / camper trailer /
caravan / motorhome?

Any period is acceptable, from one night only up to "by discussion with
management", although permanent residents aren't allowed.

Thanks

Graeme

On 14. Aug 2020, at 22:24, Martin Koppenhoefer 
> wrote:
>
> Both tags allow tents, and both allow camper vans and caravans.
>
>
>
> interesting, I would have expected a caravan site to not permit tents by
> default.
>
>
>
> actually the caravan site puts it a little differently than the above
> summary:
>
> “ They may also have some space for tents. If a site is primarily for
> tents, it should be tagged as tourism
> =camp_site
> ”
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=yes on motorways

On Sat, 15 Aug 2020 at 07:59, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> In this
> 
> section, I suggest changing the text:
> "These ways should all point direction of travel and be tagged with
> oneway=yes."
>
> to
>
> "These ways should all point direction of travel and imply oneway=yes
> (like junction=roundabout), therefore the oneway tag is redundant and
> should be avoided."
>

While I agree with you that the oneway tag is probably redundant, if we
remove them are we possibly opening ourselves / OSM to criticism "But my
GPS didn't say it was one-way only" (& yes, I have that little faith in any
number of drivers! :-()

Thanks

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

Re: [Tagging] Waterway equivalent of noexit=yes?