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

[Mark Wagner]

On Wed, 12 Aug 2020 19:37:40 +0100
Paul Allen  wrote:

> On Wed, 12 Aug 2020 at 18:36, Tod Fitch  wrote:
> 
> > Not yet mapped, but my prototype case can be seen in the Bing
> > Imagery with an area that collect water around 33.99268,-116.22239
> > and flows generally to the east and north only to dissipate around
> > 33.06076,-116.06077. 
> 
> There's water there?  It looks like the surface of Mars.  I can see
> subtle features
> but I'd hesitate to call them water from Bing imagery alone.  Could
> be deer trails
> for all I can tell.

If you're familiar with that sort of terrain, the streams are
blindingly obvious (Esri Clarity is probably a better choice than Bing
for spotting them).

> > The collection area is no problem nor is the ephemeral waterway
> > until about 33.03910,-116.099138 where it start bifurcating into
> > smaller and smaller channels which eventually disappear.
> >  
> 
> Either I'm looking at the wrong place, or the USGS Topographic Map
> layer thinks
> things are somewhat different, at least in the rainy season.  It
> looks like you have
> a number of sinks and, generally north-east of the sinks, issues (as
> Ordnance Survey
> would call them), on intermittent streams (if I'm interpreting USGS
> symbols correctly).

Probably the best place to see spreading would be around Coyote Lake at
34.1618, -116.2123; there are additional "spread out and disappear"
patterns at the north and south ends of the lakebed.

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.

-- 
Mark

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

Re: [Tagging] Tagging specialized head lice removal salons

[Martin Koppenhoefer]

sent from a phone

> On 12. Aug 2020, at 23:54, Lisbeth Salander  wrote:
> 
> Maybe
> healthcare=head_lice_removal would be more succinct?


+1


> 
> As a bonus, that tag works both on its own and for hairdressers
> (shop=hairdresser + healthcare=head_lice_removal).


+1


> Map renderers should
> ensure a consistent ruling to decide on an icon, but it would simplify
> greatly both edits and queries.


the major renderers will likely only pick up the tag when its usage gets into 
the thousands, which is a challenging objective for a relatively rare feature 
like this, but you can set up your own overlay, which is not very complicated. 
(Maybe I‘m misguided and this feature is more frequent elsewhere, around here 
you go to the pharmacy, get a suitable product and do the treatment yourself).


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

Re: [Tagging] Tagging specialized head lice removal salons

[Lisbeth Salander]

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

> You're saying people with head lice are just as attractive as those
without them? :)

Touché. You got me there hahahahah

> It's about as close as we have, as I see it.  Podiatrists are
healthcare=clinic + 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.

(By the way, I forgot to thank dieterdreist for linking to the Proposal
process page. There are still a lot of subtleties like this one that I
would like to iron out before, though.)

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

> 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...

...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. 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?


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

Re: [Tagging] Tagging specialized head lice removal salons

[Paul Allen]

On Wed, 12 Aug 2020 at 22:54, Lisbeth Salander  wrote:

> All good ideas except beauty=*, I'm sorry. That recommendation makes
> sense in most cases, but if head lice was a beauty treatment we wouldn't
> need clinics for detecting head lice in the first place hahaha.
>

You're saying people with head lice are just as attractive as those without
them? :)

>
> healthcare=clinic + healthcare:specialty=head_lice_removal would work,
> but these salons aren't expected to offer medical services.


It's about as close as we have, as I see it.  Podiatrists are
healthcare=clinic
+ 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.


> Maybe healthcare=head_lice_removal would be more succinct?
>

You may have more opposition to adding to healthcare than to
healthcare:speciality.  But I could well be wrong about that.

>
> As a bonus, that tag works both on its own and for hairdressers
> (shop=hairdresser + healthcare=head_lice_removal). Map renderers should
> ensure a consistent ruling to decide on an icon,


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...


> but it would simplifygreatly both edits


I think not.  I suspect iD authors would be upset at having to special-case
a top-level tag onto shop=hairdresser, whereas adding it to beauty=* in
the wiki ought to mean iD picks it up automatically (if it supports beauty=*
on hairdressers at all).

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

Re: [Tagging] Tagging specialized head lice removal salons

[Lisbeth Salander]

All good ideas except beauty=*, I'm sorry. That recommendation makes
sense in most cases, but if head lice was a beauty treatment we wouldn't
need clinics for detecting head lice in the first place hahaha.

healthcare=clinic + healthcare:specialty=head_lice_removal would work,
but these salons aren't expected to offer medical services. Maybe
healthcare=head_lice_removal would be more succinct?

As a bonus, that tag works both on its own and for hairdressers
(shop=hairdresser + healthcare=head_lice_removal). Map renderers should
ensure a consistent ruling to decide on an icon, but it would simplify
greatly both edits and queries.


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

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

[Tod Fitch]

Not yet mapped, but my prototype case can be seen in the Bing Imagery with an 
area that collect water around 33.99268,-116.22239 and flows generally to the 
east and north only to dissipate around 33.06076,-116.06077. The collection 
area is no problem nor is the ephemeral waterway until about 
33.03910,-116.099138 where it start bifurcating into smaller and smaller 
channels which eventually disappear.

Cheers,
Tod

> On Aug 12, 2020, at 10:03 AM, Joseph Eisenberg  
> wrote:
> 
> Would waterway=spreads only be used for intermittent streams/rivers where the 
> waterway spreads out and evaporates on the surface?
> 
> If the water appears to sink into sand, gravel or fractured karst rock, would 
> we want a different tag instead, e.g. waterway=sink?
> 
> I understand that natural=cave_entrance can also be used when a waterway 
> drops into a sinkhole or other open cave entrance, often found in limestone 
> (karst) geology areas.
> 
> -- Joseph Eisenberg
> 
> On Wed, Aug 12, 2020 at 9:52 AM Paul Allen  > wrote:
> On Wed, 12 Aug 2020 at 17:07, Tod Fitch  > wrote:
> 
> To clarify it for me, the a “waterway=spread” tag would be used on a node 
> (rendered possibly as an asterisk) or on a way? Or either depending the 
> situation?
> 
> I'd say "spreads" rather than "spread" because that's the term OS uses.  I've 
> only
> ever seen OS use it on the terminal node of a waterway.  More of a crow's-foot
> symbol than an asterisk, usually, but an asterisk works.  I have no idea how
> you'd render it sensibly on a way.  I assume you're thinking of something 
> like a
> very sandy river bed where the water sometimes gets further than other times,
> depending on conditions.  I'd be happy enough with a single node, because
> that's better than we have now.  If you can justify applying it to a way and
> think there's a need then do so, but if you're just trying to keep QA tools
> happy...
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Colin Smale]

So what is wrong with ele=* on the stations and the topography of the
line? Completely (for OSM purposes) objective and uncontroversial. The
data consumer/renderer can make their own mind up about nomenclature.
Many of these lifts go up to go down, or go down to go up, as they cross
ridges and valleys. One man's incline on a segment of the route is
another man's decline based on the station altitudes. Let's tag the
facts, and not subjective naming. 

On 2020-08-12 22:47, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 12. Aug 2020, at 21:39, Yves  wrote:
>> 
>> Alexey, you're right, anyway physical properties like incline are better 
>> tagged on way than on relations.
> 
> and horizontal aerialways aren't completely unheard of either. The incline 
> solution works only for a subset of aerialways. Generally, for horizontal 
> aerialways top and bottom / valley do not apply, i.e. the original question 
> is directly related to a specific (frequent) configuration: an aerialway 
> which surmounts a significant height difference. We do not have to find a 
> universal solution if the question relates only to this special case.
> 
> 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] Aerialway stations

[Martin Koppenhoefer]

sent from a phone

> On 12. Aug 2020, at 21:39, Yves  wrote:
> 
> Alexey, you're right, anyway physical properties like incline are better 
> tagged on way than on relations.


and horizontal aerialways aren’t completely unheard of either. The incline 
solution works only for a subset of aerialways. Generally, for horizontal 
aerialways top and bottom / valley do not apply, i.e. the original question is 
directly related to a specific (frequent) configuration: an aerialway which 
surmounts a significant height difference. We do not have to find a universal 
solution if the question relates only to this special case.

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

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

[Tod Fitch]

> On Aug 12, 2020, at 4:49 AM, Paul Allen  wrote:
> 
> On Tue, 11 Aug 2020 at 19:19, Tod Fitch  > wrote:
> 
> It occurred to me that the area where water flow disappears is indeterminate 
> [1], thus the problem mapping it.
> 
> Ordnance Survey represents this as a sort of star of very short waterways
> at the approximate point of disappearance and labels them "spreads."
> 
> The map is representative.  We can tolerate precisely specified amounts of
> doubt and uncertainty.  The name "spreads" indicates the indeterminacy even
> if we map it as a node.  Just as we render a spring as a circle on the
> map, an asterisk would do for spreads.
> 
> Perhaps a “indeterminate=yes” tag on the last node of a water way that 
> “peters out” [2] could be used to signal the QA tools that the end of a water 
> way is not a mistake.
> 
> If we tag it as waterway=spreads the indeterminacy is implied and QA tools
> can be happy there is no mistake.
> 
> Might be useful in cases other than an ephemeral water way in the desert 
> though I haven’t thought of one yet.
> 
> Useful in coastal waterways that peter out in sand above high water.  Or 
> coastal
> waterways that peter out in sand just below high water when the tide is out - 
> they
> haven't carved a channel down to the low water mark, they just vanish into the
> sand (but QA tools won't have a problem with those if they connect to the high
> water mark).  And yes, there are coastal waterways that carve a channel 
> through
> a beach right down to low water and others that just peter out on the beach
> close to high water.
> 

To clarify it for me, the a “waterway=spread” tag would be used on a node 
(rendered possibly as an asterisk) or on a way? Or either depending the 
situation?

Thanks!
Tod





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Yves]

Alexey, you're right, anyway physical properties like incline are better tagged 
on way than on relations.
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Alexey Zakharenkov]

My imagination draws an aerialway that goes over a hill, with or without a mid-station at the top. So, potentially incline is not even a property of a route=aerialway relation, but of an aerialway way segment. 12.08.2020, 18:57, "Kevin Broderick" :In the case of Gaislachkoglbahn, it appears to be two separate tramways (and tagged as such), with adjacent terminals. If the carriers (gondola cabins, tram cars, chairs, etc) don't continue through the station, I think it would be a drive or return terminal, not a mid-station; that particular case would be two terminals (for two different tramways) housed in the same building. Bearing in mind subway mapping practice, this would rather be mapped as one station and two stop_area relationscombined into a transfer (stop_area_group), the two station objects being stop_positions instead. Best regards,Alexey Zakharenkov ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Allen]

On Wed, 12 Aug 2020 at 18:36, Tod Fitch  wrote:

> Not yet mapped, but my prototype case can be seen in the Bing Imagery with
> an area that collect water around 33.99268,-116.22239 and flows generally
> to the east and north only to dissipate around 33.06076,-116.06077.
>

There's water there?  It looks like the surface of Mars.  I can see subtle
features
but I'd hesitate to call them water from Bing imagery alone.  Could be deer
trails
for all I can tell.


> The collection area is no problem nor is the ephemeral waterway until
> about 33.03910,-116.099138 where it start bifurcating into smaller and
> smaller channels which eventually disappear.
>

Either I'm looking at the wrong place, or the USGS Topographic Map layer
thinks
things are somewhat different, at least in the rainy season.  It looks like
you have
a number of sinks and, generally north-east of the sinks, issues (as
Ordnance Survey
would call them), on intermittent streams (if I'm interpreting USGS symbols
correctly).

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

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

[Paul Allen]

On Wed, 12 Aug 2020 at 18:06, Joseph Eisenberg 
wrote:

> Would waterway=spreads only be used for intermittent streams/rivers where
> the waterway spreads out and evaporates on the surface?
>

I hadn't even considered its use with intermittent streams.

>
> If the water appears to sink into sand, gravel or fractured karst rock,
> would we want a different tag instead, e.g. waterway=sink?
>

Not really.  There's no hole it goes down.  At least that's how it appears
on OS
maps.  They show waterways that just terminate, which I assume are sinks
(and we probably need a tag such as waterway=sink for the ones that
aren't big/deep enough to qualify as natural=sinkhole).  Ordnance Survey
also shows, and labels, spreads.

OS appears to have renamed or deleted their terminology pages because I can
no longer find them in Google.  But I eventually found this copy:
https://www.lib.cam.ac.uk/files/os-mastermap-real-world-object-catalogue.pdf
which says:

The source of a river is defined by one of the following terms:
Collects - where the source is a bog or a marsh
Spring - where the source is a natural spring
Issues - where the source is an emission from an agricultural drain, or
where the stream re-emerges from underground

Where a river disappears underground the point will be described Sinks.
Where a river spreads on a sand or shingle beach, or in a marsh, it will be
described Spreads

We have springs and sinkholes.  We don't really need collects if we map the
marsh
and the waterway that issues from it.  For completeness it would be nice to
have
issues, sinks and spreads.  We don't have to copy what others do, but it's
possible they did things that way for good reason...

I understand that natural=cave_entrance can also be used when a waterway
> drops into a sinkhole or other open cave entrance, often found in limestone
> (karst) geology areas.
>

And then forms, at least in part, an underground river.  That's a whole
nother
can of worms.  And doesn't seem to match the definition of spreads.

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

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

[Joseph Eisenberg]

Would waterway=spreads only be used for intermittent streams/rivers where
the waterway spreads out and evaporates on the surface?

If the water appears to sink into sand, gravel or fractured karst rock,
would we want a different tag instead, e.g. waterway=sink?

I understand that natural=cave_entrance can also be used when a waterway
drops into a sinkhole or other open cave entrance, often found in limestone
(karst) geology areas.

-- Joseph Eisenberg

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

> On Wed, 12 Aug 2020 at 17:07, Tod Fitch  wrote:
>
>>
>> To clarify it for me, the a “waterway=spread” tag would be used on a node
>> (rendered possibly as an asterisk) or on a way? Or either depending the
>> situation?
>>
>
> I'd say "spreads" rather than "spread" because that's the term OS uses.
> I've only
> ever seen OS use it on the terminal node of a waterway.  More of a
> crow's-foot
> symbol than an asterisk, usually, but an asterisk works.  I have no idea
> how
> you'd render it sensibly on a way.  I assume you're thinking of something
> like a
> very sandy river bed where the water sometimes gets further than other
> times,
> depending on conditions.  I'd be happy enough with a single node, because
> that's better than we have now.  If you can justify applying it to a way
> and
> think there's a need then do so, but if you're just trying to keep QA tools
> happy...
>
> --
> 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] Waterway equivalent of noexit=yes?

[Paul Allen]

On Wed, 12 Aug 2020 at 17:07, Tod Fitch  wrote:

>
> To clarify it for me, the a “waterway=spread” tag would be used on a node
> (rendered possibly as an asterisk) or on a way? Or either depending the
> situation?
>

I'd say "spreads" rather than "spread" because that's the term OS uses.
I've only
ever seen OS use it on the terminal node of a waterway.  More of a
crow's-foot
symbol than an asterisk, usually, but an asterisk works.  I have no idea how
you'd render it sensibly on a way.  I assume you're thinking of something
like a
very sandy river bed where the water sometimes gets further than other
times,
depending on conditions.  I'd be happy enough with a single node, because
that's better than we have now.  If you can justify applying it to a way and
think there's a need then do so, but if you're just trying to keep QA tools
happy...

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

Re: [Tagging] Aerialway stations

[Joseph Eisenberg]

There are 2 lines of the Metrocable gondola system in Medellín, Colombia
which have 4 stations each (one has 5 stations, but that actually appears
to be 2 different cable loops)
https://en.wikipedia.org/wiki/Metrocable_(Medell%C3%ADn)

The variety of different types of "aerialway" is quite large, since there
are urban systems and tourist systems in flat regions (theme parks) as well
as mountain areas.

-- Joseph Eisenberg

On Wed, Aug 12, 2020 at 8:04 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit 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] Aerialway stations

[Kevin Broderick]

In the case of Gaislachkoglbahn, it appears to be two separate tramways
(and tagged as such), with adjacent terminals. If the carriers (gondola
cabins, tram cars, chairs, etc) don't continue through the station, I think
it would be a drive or return terminal, not a mid-station; that particular
case would be two terminals (for two different tramways) housed in the same
building.

I'm not aware of any circuit-shaped tramways where the drive/return is
actually the same structure.

On Wed, Aug 12, 2020 at 11:48 AM dktue  wrote:

> Hi,
>
> 1) maybe "station=lower_station" would be clearer
> 2) I couldn't find any real-world example
> 3) Probably this would be the definition of a mid-station.
>
> Interesting example:
> https://www.openstreetmap.org/node/1613091788
>
> Here within the same building we have "Talstation" ("valley station") and
> "Bergstation" ("mountain station") of the aerialway "Gaislachkoglbahn"
> wheres the arealway itself is separated in to sections name
> "Gaislachkoglbahn I" (lower) and "Gaislachkoglbahn II" (upper). I think
> because people have to get out and change the aerialway to proceed furtuher
> to the top it's correct that this is not a mid-station. I would expect from
> a mid-station that I can get off but I might be able to stay and go further.
>
> Cheers
> dktue
>
> Am 12.08.2020 um 17:02 schrieb Mateusz Konieczny via Tagging:
>
> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit tagging?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[dktue]

If the concern is for routing, that's a slightly bigger challenge—some 
tramways load only at one end, some load at both (e.g. the gondola 
linked above), others load primarily at one end with limited loading 
at the other in various special conditions, sometimes event-specific, 
and often with different capacities (many, if not most, ski lifts have 
higher uphill than downhill capacities). one_way=* seems to be a 
possible solution, but I don't know how you'd tag "one_way=yes; except 
when hosting a wedding at the top, or for employees to get down at the 
end of the shift"



I think that aspect is perfectly covered with

aerialway:access=entry/exit/both/no

https://wiki.openstreetmap.org/wiki/Tag:aerialway=station

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

Re: [Tagging] Aerialway stations

[Kevin Broderick]

>From an 'information about aerial tramways" standpoint, I believe that it
would be preferable to label the drive, midstation, and return terminals as
such. While they are often for vertical-oriented transport, aerialways are
sometimes used for horizontal transport, e.g.
https://www.openstreetmap.org/way/46351339#map=18/44.53063/-72.78456=D
terminal=drive
terminal=return
terminal=mid

It is worth noting that ski lifts are often described as "top-drive" or
"bottom-drive" (i.e. the powered bullwheel is at the top in some cases and
at the bottom in others), but it doesn't take a ton of tramway knowledge to
figure out which is which (drive infrastructure is usually pretty obvious).

If the concern is for routing, that's a slightly bigger challenge—some
tramways load only at one end, some load at both (e.g. the gondola linked
above), others load primarily at one end with limited loading at the other
in various special conditions, sometimes event-specific, and often with
different capacities (many, if not most, ski lifts have higher uphill than
downhill capacities). one_way=* seems to be a possible solution, but I
don't know how you'd tag "one_way=yes; except when hosting a wedding at the
top, or for employees to get down at the end of the shift"

On Wed, Aug 12, 2020 at 11:04 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit 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
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[dktue]

Hi,

1) maybe "station=lower_station" would be clearer
2) I couldn't find any real-world example
3) Probably this would be the definition of a mid-station.

Interesting example:
https://www.openstreetmap.org/node/1613091788

Here within the same building we have "Talstation" ("valley station") 
and "Bergstation" ("mountain station") of the aerialway 
"Gaislachkoglbahn" wheres the arealway itself is separated in to 
sections name "Gaislachkoglbahn I" (lower) and "Gaislachkoglbahn II" 
(upper). I think because people have to get out and change the aerialway 
to proceed furtuher to the top it's correct that this is not a 
mid-station. I would expect from a mid-station that I can get off but I 
might be able to stay and go further.


Cheers
dktue

Am 12.08.2020 um 17:02 schrieb Mateusz Konieczny via Tagging:

1) is bottom station always in valley?
(This should be fixable)

2) is there case of 2 and more middle
stations?

3) is there case of one station being both
top and bottom station at once?

Also, it uses single known tag, not
new discussion purpose ones.

Though, yes processing would be
much more complicated.

I would consider also tagging elevation
(ele tag from what I remember).


12 Aug 2020, 16:31 by em...@daniel-korn.de:

Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:

dktue:

Hi,

I was wondering why there's no way to distinguish valley
and upper stations of
aerialways in OpenStreetMap.

Usually an aerialway consists of

 * one valley station
 * zero or more mid stations
 * one upper station (or "mountain station")

What do you think you tagging this information with


You could tag the aerialway with incline=up/down

 station=valley_station/mid_station/upper_station

?

Cheers
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station

That's true but I think it would be very hard for consumers to
extract this information (think of an overpass-query to find all
mid stations). Would there be any advantage in following your
suggestions instead of explicit 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] Aerialway stations

[Mateusz Konieczny via Tagging]

1) is bottom station always in valley?
(This should be fixable)

2) is there case of 2 and more middle
stations?

3) is there case of one station being both
top and bottom station at once?

Also, it uses single known tag, not
new discussion purpose ones.

Though, yes processing would be
much more complicated.

I would consider also tagging elevation
(ele tag from what I remember).

12 Aug 2020, 16:31 by em...@daniel-korn.de:

> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
>> dktue:
>>
>>> Hi,
>>>
>>> I was wondering why there's no way to distinguish valley and upper stations 
>>> of
>>> aerialways in OpenStreetMap.
>>>
>>> Usually an aerialway consists of
>>>
>>>   * one valley station
>>>   * zero or more mid stations
>>>   * one upper station (or "mountain station")
>>>
>>> What do you think you tagging this information with
>>>
>>
>> You could tag the aerialway with incline=up/down
>>
>>>  station=valley_station/mid_station/upper_station
>>>
>>> ?
>>>
>>> Cheers
>>> dktue
>>>
>>> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>>>
> That's true but I think it would be very hard for consumers to extract this 
> information (think of an overpass-query to find all mid stations). Would 
> there be any advantage in following your suggestions instead of explicit 
> 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] Aerialway stations

[dktue]

Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:

dktue:

Hi,

I was wondering why there's no way to distinguish valley and upper stations of
aerialways in OpenStreetMap.

Usually an aerialway consists of

  * one valley station
  * zero or more mid stations
  * one upper station (or "mountain station")

What do you think you tagging this information with


You could tag the aerialway with incline=up/down


  station=valley_station/mid_station/upper_station

?

Cheers
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station

That's true but I think it would be very hard for consumers to extract 
this information (think of an overpass-query to find all mid stations). 
Would there be any advantage in following your suggestions instead of 
explicit tagging?


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

Re: [Tagging] Aerialway stations

[Niels Elgaard Larsen]

dktue:
> Hi,
> 
> I was wondering why there's no way to distinguish valley and upper stations of
> aerialways in OpenStreetMap.
> 
> Usually an aerialway consists of
> 
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
> 
> What do you think you tagging this information with


You could tag the aerialway with incline=up/down

>  station=valley_station/mid_station/upper_station
> 
> ?
> 
> Cheers
> dktue
> 
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


-- 
Niels Elgaard Larsen

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

[Tagging] Aerialway stations

[dktue]

Hi,

I was wondering why there's no way to distinguish valley and upper 
stations of aerialways in OpenStreetMap.


Usually an aerialway consists of

 * one valley station
 * zero or more mid stations
 * one upper station (or "mountain station")

What do you think you tagging this information with

 station=valley_station/mid_station/upper_station

?

Cheers
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station

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

Re: [Tagging] Tagging specialized head lice removal salons

[Paul Allen]

On Wed, 12 Aug 2020 at 13:28, Martin Koppenhoefer 
wrote:

>
> I agree with Paul that those which are also hairdressers should probably
> get an additional property, although I would not use “beauty” as key for
> this.


I'm not impressed with the idea of using beauty=* for describing what
services
are offered by hairdressers, but the wiki documents it as being what should
be
used.  I can see the reasoning as some types of hairdressing services can be
considered to be beauty treatments.  So I went with the flow rather than
opening
up a second front for us all to fight on. :)

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

Re: [Tagging] Tagging specialized head lice removal salons

[Martin Koppenhoefer]

sent from a phone

> On 12. Aug 2020, at 14:26, Martin Koppenhoefer  wrote:
> 
> 
> 
> sent from a phone
> 
>>> On 12. Aug 2020, at 13:55, Lisbeth Salander  wrote:
>> For the
>> moment, I filled in general `healthcare` tags:
>> https://www.openstreetmap.org/node/7806359146
> 
> 
> I agree with Paul that those which are also hairdressers should probably get 
> an additional property, although I would not use “beauty” as key for this. 
> Either you would use a healthcare-subtag like
> healthcare:specialty=head_lice_removal (or treatment or whatever) or even a

specific tag like
head_lice_removal=yes

Similarly, as a main tag, 
amenity=head_lice_removal
or
healthcare=head_lice_removal would be ok (I would not subtag them as 
dermatologists, if all that they offer is head lice removal).

You do not need an approval to use a tag in OpenStreetMap, but there is a 
proposal process which you are encouraged to use in order to get a formally 
discussed and approved tag.
It is outlined here:

https://wiki.openstreetmap.org/wiki/Proposal_process

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

Re: [Tagging] Tagging specialized head lice removal salons

[Martin Koppenhoefer]

sent from a phone

>> On 12. Aug 2020, at 13:55, Lisbeth Salander  wrote:
> For the
> moment, I filled in general `healthcare` tags:
> https://www.openstreetmap.org/node/7806359146


I agree with Paul that those which are also hairdressers should probably get an 
additional property, although I would not use “beauty” as key for this. Either 
you would use a healthcare-subtag like
healthcare:specialty=head_lice_removal (or treatment or whatever) or even a 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging specialized head lice removal salons

[Paul Allen]

On Wed, 12 Aug 2020 at 12:55, Lisbeth Salander  wrote:

>
> I'm asking for the proper way to tag a salon which only locates and
> removes head lice. (Probably not every country has these
> super-specialized salons) A quick search online suggests that some of
> them double as hairdressers.
>

The ones that double as hairdressers should probably be tagged as
hairdressers and add a beauty=value_to_be_decided_for_louse_treatment.

>
> The latest salon I added doesn't advertise any other service besides
> lice removal, so `amenity=clinic` or `amenity=doctors` seem ill-fitting.
>

The closest fit would appear to be healthcare=clinic +
healthcare:speciality=value_to_be_decided_for_louse_treatment

Technically it's a category of dertmatology but I think it would be
misleading to label the speciality as dermatology.

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

[Tagging] Tagging specialized head lice removal salons

[Lisbeth Salander]

This is supposed to start a new topic in the Tagging mailing lists. If
it doesn't, please close it or move it. I'm not all that familiar with
mailing lists.

I'm asking for the proper way to tag a salon which only locates and
removes head lice. (Probably not every country has these
super-specialized salons) A quick search online suggests that some of
them double as hairdressers.

The latest salon I added doesn't advertise any other service besides
lice removal, so `amenity=clinic` or `amenity=doctors` seem ill-fitting.
I tried searching on the wiki for "lice", "louse", "parasites", and I
could not find other salons that could serve as a reference. For the
moment, I filled in general `healthcare` tags:
https://www.openstreetmap.org/node/7806359146

The website for that particular chain of salons has front pages in
Spanish, English and Catalan: https://helppiojitos.com/

Is it possible to decide on a standard tagging for this and add it to
the wiki? I'd be willing to translate the page to Spanish and Galician.

Thanks in advance.


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

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

[Paul Allen]

On Tue, 11 Aug 2020 at 19:19, Tod Fitch  wrote:

>
> It occurred to me that the area where water flow disappears is
> indeterminate [1], thus the problem mapping it.
>

Ordnance Survey represents this as a sort of star of very short waterways
at the approximate point of disappearance and labels them "spreads."

The map is representative.  We can tolerate precisely specified amounts of
doubt and uncertainty.  The name "spreads" indicates the indeterminacy even
if we map it as a node.  Just as we render a spring as a circle on the
map, an asterisk would do for spreads.

Perhaps a “indeterminate=yes” tag on the last node of a water way that
> “peters out” [2] could be used to signal the QA tools that the end of a
> water way is not a mistake.


If we tag it as waterway=spreads the indeterminacy is implied and QA tools
can be happy there is no mistake.


> Might be useful in cases other than an ephemeral water way in the desert
> though I haven’t thought of one yet.
>

Useful in coastal waterways that peter out in sand above high water.  Or
coastal
waterways that peter out in sand just below high water when the tide is out
- they
haven't carved a channel down to the low water mark, they just vanish into
the
sand (but QA tools won't have a problem with those if they connect to the
high
water mark).  And yes, there are coastal waterways that carve a channel
through
a beach right down to low water and others that just peter out on the beach
close to high water.

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