[Tagging] Link to stream of webcam

2020-09-04 Thread dktue

Hi,

I'd like to tag the link to the (current) JPEG-image of a webcam, but 
the wiki doesn't state how to do so [1].


Any suggestions how to tag this?

Cheers,
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance

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


Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-16 Thread dktue

Ok, then I'm going to edit the wiki [1] now.

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


Am 16.08.2020 um 15:07 schrieb Yves:

I derived, not copied :-)
Go on with proposed top, mid & bottom, Dktue.

I tried to be more specific and imply a meaning that is beyond 'the 
station at the top of the aerialway' because us dealing with a geo 
database, it's a bit clumsy to tag this, and I fear the proposal will 
attract some criticism, let see what happens !

Yves

Le 16 août 2020 13:53:31 GMT+02:00, Colin Smale 
 a écrit :


Nope You can't have a mid terminal, by definition. And as
"terminal" is used with similar semantics to "station" here, if
you start with aerialway:station you don't need to include
"terminal" or "station" in the value as well.

That web page doesn't refer at all to the "top station" or the
"bottom station", but it does refer to a "midstation"; I am not
sure what you actually derived from that page?


On 2020-08-15 18:25, Yves wrote:


Had a look at http://www.skilifts.org/old/glossary.htm, came up
with :

Aerialway:station=top_terminal, mid_terminal, bottom_terminal

Yves

___
Tagging mailing list
Tagging@openstreetmap.org <mailto: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] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-16 Thread dktue

So that would leave us with

    aerialway:station={bottom,mid,top}?

Am 16.08.2020 um 13:53 schrieb Colin Smale:


Nope You can't have a mid terminal, by definition. And as 
"terminal" is used with similar semantics to "station" here, if you 
start with aerialway:station you don't need to include "terminal" or 
"station" in the value as well.


That web page doesn't refer at all to the "top station" or the "bottom 
station", but it does refer to a "midstation"; I am not sure what you 
actually derived from that page?


On 2020-08-15 18:25, Yves wrote:


Had a look at http://www.skilifts.org/old/glossary.htm, came up with :

Aerialway:station=top_terminal, mid_terminal, bottom_terminal

Yves

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


Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-16 Thread dktue

Am 15.08.2020 um 18:25 schrieb Yves:

Had a look at http://www.skilifts.org/old/glossary.htm, came up with :

Aerialway:station=top_terminal, mid_terminal, bottom_terminal

I'd be totally fine with that aswell.

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


Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-15 Thread dktue

Am 15.08.2020 um 15:31 schrieb Colin Smale:


On 2020-08-15 15:15, dktue wrote:

The main thing is that people often refer to "Talstation" and 
"Bergstation" but this information is not machine-readeable but 
mostly encoded in the names of the stations. My goal ist to make this 
machine-readeable because it almost all cases people can refer to it 
even if they do not know the station's name. It's obvious what's 
meant in almost every case what I mean when I say "Bergstation 
Mutteralmbahn" [1] even if the station's name doesn't say so [2]. So 
let's put this into machine-readeable tags to enable applications to 
solve a problem not for specialists but for the general map purpose 
we're building.


In my opinion we did have the right discussion and have a very good 
proposed definition with easy values that people with a basic 
understanding of english can understand. Do you agree?


Yes, I agree, provided the values are "top/bottom" or "upper/lower" 
and not "head/base". Even "mountain/valley" could be problematic as it 
depends on the geography and not simply on the geometry (an 
end-station half-way up the mountain, what is that?). The distinction 
is purely about the altitude of the end-station relative to the other, 
not about whether it is surrounded by shops or rocks.


This will enable a user to select all top-stations for example, or to 
label the stations on a given cableway appropriately.



Well then I will put this into the wiki, ok? :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-15 Thread dktue
The main thing is that people often refer to "Talstation" and 
"Bergstation" but this information is not machine-readeable but mostly 
encoded in the names of the stations. My goal ist to make this 
machine-readeable because it almost all cases people can refer to it 
even if they do not know the station's name. It's obvious what's meant 
in almost every case what I mean when I say "Bergstation Mutteralmbahn" 
[1] even if the station's name doesn't say so [2]. So let's put this 
into machine-readeable tags to enable applications to solve a problem 
not for specialists but for the general map purpose we're building.


In my opinion we did have the right discussion and have a very good 
proposed definition with easy values that people with a basic 
understanding of english can understand. Do you agree?


[1] https://www.openstreetmap.org/way/26746748
[2] https://www.openstreetmap.org/node/293382166

Am 15.08.2020 um 15:03 schrieb Colin Smale:


It seems we can't even agree on what question to ask an "expert". 
@dktue I think you started this discussion... What was your intention 
at the time? Was it "how do we identify top/bottom stations on a cable 
car"? If you ask an "expert" you might get an answer involving the 
project numbers for the build phase, or the serial numbers of the 
pylons. Let's stop looking for even more solutions until we have 
clearly defined the problem. Otherwise you will end up with 100 
different "solutions" and an argument about which is best. If it's 
about tagging the stations as upper/mid/lower according to their 
altitude and topological location, then we are there already; you 
should prepare a tagging proposal and put it to the vote.


And bear in mind the values should ultimately be meaningful to a 
normal person, not just to a ski lift engineer, and to people with 
limited English (so using French/German/Italian nomenclature for 
example would not be helpful).


On 2020-08-15 14:37, Yves wrote:

Maybe (as always here) we are too few specialists on this list to 
find the right values. I know of two forum funivie.org and 
remontées-mécaniques.net that specialize in the field, but in Italian 
and French. Does anybody know of a similar community, but English 
speaking?

Maybe we could have good advice and get a few new mapper's on board.
Yves

___
Tagging mailing list
Tagging@openstreetmap.org <mailto: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] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-15 Thread dktue
For me both schemes would be fine. I have no problem using "lower", 
"upper" and "mid" even if the upper station is lower than some mid 
stations. The definition from the wiki will then still explain how to 
tag it and it's a rare case where the mapper probably will look for the 
definition in the wiki. And your improvement regarding the defition 
itself is absolutely correct. There's no need to state the fact that 
it's the opposite end. So I'll give it a new try:



Definition:

    aerialway:station=lower

for the station at the end of the aerialway with the lower altitude,

    aerialway:station=upper

for the station at the end of the aerialway with the higher altitude,

    aerialway:station=mid

for any station not being at the end of and aerialway.


Anyone who wants to improve or oppose to this definition?

Cheers
dktue


Am 15.08.2020 um 13:57 schrieb Colin Smale:


Yes, I object to the specific values, as I (and others) said earlier. 
The use of "base" and "head" is not intuitive and will lead to 
confusion and errors amongst non-fluent English speakers. More basic 
words like "top" and "bottom", or maybe "upper" and "lower", are 
preferable.


You can/should remove the word "opposite" from the definition; this 
will make it completely independent of the other definitions.


On 2020-08-15 13:44, dktue wrote:


To make in unambiguous, the definition would then be:

    aerialway:station=base

for the station at an end of the aerialway with the lower altitude,

    aerialway:station=head

for the station at the opposite end of the aerialway (hence with a 
higher altitude) and


    aerialway:station=mid

for any station not being at the end of and aerialway regardless of 
the altitude.



Anyone who wants to improve or oppose to this definition?

Cheers
dktue

Am 15.08.2020 um 13:37 schrieb Werner.Haag@leitstelle.tirol:


Hi,

it was mentioned, we have many aerialways in Tyrol and there are 
really cases where the mid station is the one with the highest altitude.
I found an example ("Schindlergratbahn", base 2035 m, mid 2643 m , 
head 2579 m, see link ). So i think, the second scheme with  base, 
mid, head could

be the better scheme.
_https://www.openstreetmap.org/way/23103020_

Werner


"Yves"  schrieb am 14.08.2020 18:07:53:

> Von: "Yves" 
> An: "Tag discussion, strategy and related tools"
> , "Mateusz Konieczny via Tagging"
> 
> Kopie: "Tagging" 
> Datum: 14.08.2020 18:09
> Betreff: Re: [Tagging] Antwort: Re: Aerialway stations
> 
> 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


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



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


___
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] Antwort: Re: Antwort: Re: Aerialway stations

2020-08-15 Thread dktue

To make in unambiguous, the definition would then be:

    aerialway:station=base

for the station at an end of the aerialway with the lower altitude,

    aerialway:station=head

for the station at the opposite end of the aerialway (hence with a 
higher altitude) and


    aerialway:station=mid

for any station not being at the end of and aerialway regardless of the 
altitude.



Anyone who wants to improve or oppose to this definition?

Cheers
dktue

Am 15.08.2020 um 13:37 schrieb Werner.Haag@leitstelle.tirol:


Hi,

it was mentioned, we have many aerialways in Tyrol and there are 
really cases where the mid station is the one with the highest altitude.
I found an example ("Schindlergratbahn", base 2035 m, mid 2643 m , 
head 2579 m, see link ). So i think, the second scheme with  base, 
mid, head could

be the better scheme.
_https://www.openstreetmap.org/way/23103020_

Werner


"Yves"  schrieb am 14.08.2020 18:07:53:

> Von: "Yves" 
> An: "Tag discussion, strategy and related tools"
> , "Mateusz Konieczny via Tagging"
> 
> Kopie: "Tagging" 
> Datum: 14.08.2020 18:09
> Betreff: Re: [Tagging] Antwort: Re: Aerialway stations
>
> 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


___
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] bridge:name and tunnel:name

2020-08-15 Thread dktue

Am 15.08.2020 um 11:18 schrieb Martin Koppenhoefer:

IMHO a tunnel is more than the way through it, the ventilation shafts, escape 
ways, also arguably all the tubes, could be considered „the tunnel“. The reason 
it is not done typically is that these features aren’t very visible (mostly 
underground) and hard to survey (you may not legally enter the escape ways 
usually, may not enter by bike or on foot).
For all of our common usecases, mapping the way through the tunnel and 
indicating it is inside a tunnel is sufficient, that’s why we do not map them 
in greater detail so far). An implicit tunnel is considered sufficient.

To come back to my original question: I'd like to change the wiki to say 
that tagging name=* for the road and tunnel:name=* for the tunnel's name 
is preferred. Anyone who opposes this opinion?


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


Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread dktue

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] bridge:name and tunnel:name

2020-08-14 Thread dktue



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

2020-08-14 Thread dktue



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] bridge:name and tunnel:name

2020-08-14 Thread dktue

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] Antwort: Re: Aerialway stations

2020-08-14 Thread dktue



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] Antwort: Re: Aerialway stations

2020-08-14 Thread dktue

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] Antwort: Re: Aerialway stations

2020-08-14 Thread dktue


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

2020-08-14 Thread dktue


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

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


Re: [Tagging] Antwort: Re: Aerialway stations

2020-08-14 Thread dktue



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 dktue



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] bridge:name and tunnel:name

2020-08-13 Thread dktue
I definitely agree: If the tunnel (or more often used: the bridge) is a 
separate object (e.g. man_made=bridge), then the tunnel's or bridge's 
name should go in the name-tag.


But my impression is that if it's the same object as the highway (or 
railway or waterway) itself then "tunnel:name" or "bridge:name" is 
definitely better.


Am 13.08.2020 um 15:31 schrieb Martin Koppenhoefer:



sent from a phone


On 13. Aug 2020, at 14:12, 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?



it depends on the kind of object. If you tag a road (highway) or other 
object that is inside a tunnel (tunnel=yes) then it seems logical to 
refer to the tunnel name with a specific tag like tunnel:name, and it 
seems advisable to even use this if the road has the same name as the 
tunnel (to remove ambiguity).
If on the other hand you add the tag to a tunnel object (e.g. tagged 
as man_made=tunnel, currently 1100 occurrences, 
https://taginfo.openstreetmap.org/tags/man_made=tunnel ) then the name 
should go into the „name“ tag



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] bridge:name and tunnel:name

2020-08-13 Thread dktue
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?


[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


Re: [Tagging] Aerialway stations

2020-08-13 Thread dktue
I think it's easy for a mapper to determine if a station is a 
bottom_station or a upper_station even if he doesn't know the exact 
elevation.


Am 13.08.2020 um 14:28 schrieb Colin Smale:


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

I think that it's quite hard for data consumers (again: think of an 
overpass-query to find all mid-stations) to determine which role a 
station has. Like Martin said: Why not just solve the (huge!) special 
case of mountain aerialways where we really have one bottom_station, 
zero or more mid_station and one upper_station?


Because cases that don't obviously fit that model will remain 
untagged, or get subjectively/wrongly tagged with this model or some 
other tags. There are many cases of arialways that start and finish at 
roughly the same level. Do they have two bottom stations, or two top 
stations, or do you force someone to make a judgement call as to which 
is slightly higher than the other?


If you want to find all mid-stations, do you want to find ALL 
mid-stations or are you happy with MOST or MANY or SOME?




Modelling reality is all about what to leave out. If top-stations, 
mid-stations and bottom-stations can be reliably derived from 
elevation and topology then there is no need to add a more explicit tag.



___
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] bridge:name and tunnel:name

2020-08-13 Thread dktue

Hi,

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?


Cheers
dktue

[1] https://wiki.openstreetmap.org/wiki/Key:tunnel

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


Re: [Tagging] Aerialway stations

2020-08-13 Thread dktue
I think that it's quite hard for data consumers (again: think of an 
overpass-query to find all mid-stations) to determine which role a 
station has. Like Martin said: Why not just solve the (huge!) special 
case of mountain aerialways where we really have one bottom_station, 
zero or more mid_station and one upper_station?


Am 12.08.2020 um 22:58 schrieb 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


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


Re: [Tagging] Aerialway stations

2020-08-12 Thread 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

2020-08-12 Thread 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

2020-08-12 Thread 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


[Tagging] Aerialway stations

2020-08-12 Thread 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] Riverbanks

2020-07-21 Thread dktue


 There is no way to calculate the "opinnion" of the community and 
authoritarian/dictator attitude of iD coders and lack of action ramped 
up usage of nerdy schema close to original OSM one.


 And there is nobody bold to solve this, as there is no governing 
body/expert group.


 Local communities can do it. In Lithuania nerdy scheme is prohibited 
in favour of clean and consistent data.



Good point! I'm discussing this with the German OSM-Community now in the 
forum [1].


[1] https://forum.openstreetmap.org/viewforum.php?id=14
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Riverbanks

2020-07-21 Thread dktue

Am 21.07.2020 um 10:55 schrieb Tomas Straupis:

2020-07-21, an, 11:20 dktue rašė:

Why do we need both variants and why don't we just say that
waterway=riverbank is preferred?

   There is an original OpenStreetMap water schema with lakes as
natural=water, reservoirs as landuse=reservoir, riverbanks as
waterway=riverbank etc. It is a perfectly working schema.

   At some point there was a new schema proposed with a totally nerdy
motivation "to make some sql's simpler". That new schema has no
advantage in cartography, GIS or IT sense. It is totally NERDY. This
nerdy scheme was ignored in the beginning but then came the iD which
took a totally non-analytical and authoritarian attitude and not only
chose to support nerdy water schema, but even decided to support ONLY
it. And in recent year iD coders went even further and started lying
to its users that original OpenStreetMap water schema is "deprecated'
even when it never was.

   So this is the reason why we have two schemas. It is very
unfortunate that there is no way to prohibit such nonsense nerdy
schemas into OpenStreetMap :-(
So why can't the wiki state: "If you tag, then please do so using 
waterway=riverbank" (as this is preferred by the *community*)?


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


[Tagging] Riverbanks

2020-07-21 Thread dktue

Hi,

the wiki [1] states for riverbanks that

"These water areas should be tagged as either of waterway=riverbank OR 
natural=water + water=river."


Why do we need both variants and why don't we just say that 
waterway=riverbank is preferred?


Cheers
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank

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


Re: [Tagging] Charging stations: socket::output -- which format for the value?

2019-07-30 Thread dktue



OSM typically places unit after the value.
For examples see 
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications
In Some cases the unit is omitted and a default is assumed. Would this 
default be "kW" in this case?



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


Re: [Tagging] Charging stations: socket::output -- which format for the value?

2019-07-29 Thread dktue
I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue <mailto:em...@daniel-korn.de>>:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other OSM-values
(no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for many 
people may be more evocative than Watt (everybody can imagine 30 
horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers for 
MW (e.g. needed for power generators). Presuming, we would have the 
same standard unit for all things power, and not different defaults 
for socket and say power stations.


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


[Tagging] Charging stations: socket::output -- which format for the value?

2019-07-29 Thread dktue

Hello,

the OSM-Wiki-page on charging stations [1] defines the tag 
socket::output=watt


wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would like to 
clearify this on the wiki-page.


Personally I would prefer "22000" as it fits with other OSM-values (no 
units).


Cheers,
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station

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


[Tagging] shop=clothes vs shop=fashion

2019-03-06 Thread dktue

Hello,

I currently found out that shops that sell clothes are either tagged with

    shop=clothes

or with

    shop=fashion

but I can't find out when to use which.

Can anybody clarify?

Cheers,
Daniel

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


[Tagging] Printing company for newspapers

2018-12-14 Thread dktue

Hi,

I would like to tag a company where newspapers are being printed, but I 
feel that shop=copyshop doesn't fit well.


My suggestion would be to go with craft=printer. Any opinions on that?

Cheers,
dktue

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


Re: [Tagging] emergency=control_centre

2018-12-09 Thread dktue

You're definitely right,

    office=control_centre

seems to be better suited.

Am 09.12.2018 um 20:52 schrieb Mateusz Konieczny:

Is there some reason to not use office=* like for other offices?


Dec 9, 2018, 4:04 PM by em...@daniel-korn.de:

Hello,

I would like to propose a tag for emergency control centers (the
place you reach when you call 112 in Europe).

My suggestion would be "emergency=control_centre".

Cheers,
dktue

___
Tagging mailing list
Tagging@openstreetmap.org <mailto: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] emergency=control_centre

2018-12-09 Thread dktue
By the way: We're currently using amenity=fire_station und 
emergency=ambulance_station -- which is confusing in my opinion.


Am 09.12.2018 um 18:12 schrieb Stefano Maffulli:
On Sun, Dec 9, 2018 at 8:16 AM Paul Allen > wrote:


Ambulance stations
(like fire stations) are places where people should be aware that
high speed emergency
vehicles may suddenly appear from.


This is a factor but not the main one for using emergency=fire_station 
or ambulance. These amenities and buildings are *resources* that are 
useful during or in the aftermath of disastrous event. The reason why 
I would want to map the building where ambulances and firestations 
with the emergency key, instead of the building or amenities is that 
this information has practical value for disaster preparation and 
response.


This conversation made me realize that the wiki page could use some 
more details on the scope of the emergency key, IMO, to also help mappers.



___
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] emergency=control_centre

2018-12-09 Thread dktue

You're definitely right. Good point!

I've been convinced that the office-key is a suitable place to put the tag.

Am 09.12.2018 um 17:15 schrieb Paul Allen:
On Sun, Dec 9, 2018 at 3:59 PM dktue <mailto:em...@daniel-korn.de>> wrote:


You're right, indeed. Office would definitely suit better.

But why are we using emergency=ambulance_station and not
building=ambulance_station?


In my experience, people don't come roaring out of houses at 70MPH 
with sirens blaring
and lights flashing.  In my experience, people don't come roaring out 
of offices at 70MPH
with sirens blaring and lights flashing.  However, ambulances may come 
roaring out of
ambulance stations at 70MPH with sirens blaring and lights flashing.  
Ambulance stations
(like fire stations) are places where people should be aware that high 
speed emergency

vehicles may suddenly appear from.

So emergency=ambulance_station is a better fit than 
office=ambulance_station or
building=ambulance_station.  Because there may be emergency traffic.  
The same does

not apply to control centres.

--
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] emergency=control_centre

2018-12-09 Thread dktue
You're right! But amenity=ambulance_station could be used. The point I 
tried to make was: Why are we using the emergency-key in that case at all.


Am 09.12.2018 um 17:01 schrieb Sergio Manzi:


Maybe because not all (/probably few.../) ambulance stations occupy an 
entire building?


On 2018-12-09 16:58, dktue wrote:
But why are we using emergency=ambulance_station and not 
building=ambulance_station?


___
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] emergency=control_centre

2018-12-09 Thread dktue

You're right, indeed. Office would definitely suit better.

But why are we using emergency=ambulance_station and not 
building=ambulance_station?


If we're doing so to make a grouping about emergency-related facilities, 
then we should go with an emergency-tag.


Am 09.12.2018 um 16:50 schrieb Markus:

office=public-safety_answering_point would probably fit better than
emergency=*. (In an emergency it might not help much to know where the
public-safety answering point is located.)

Regards
Markus

___
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] emergency=control_centre

2018-12-09 Thread dktue

Hello,

I would like to propose a tag for emergency control centers (the place 
you reach when you call 112 in Europe).


My suggestion would be "emergency=control_centre".

Cheers,
dktue

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


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-22 Thread dktue



Am 22.09.2018 um 00:29 schrieb Warin:

On 21/09/18 23:52, Martin Koppenhoefer wrote:


sent from a phone


On 21. Sep 2018, at 11:28, dktue  wrote:

but: it's not amenity=ambulance_station we're using at the moment. 
We're using emergency=ambulance_station -- so: How do we solve this?


I’m not sure what an ambulance station is, but not all of the 
features I have in mind (a place where ambulances and their staff are 
parked and waiting for orders, usually with a coordinating office and 
radio unit) are emergency related. Some organizations only provide 
ambulance transports for people with special requirements.




Here 'patent transport' is provided by the same organisation that 
provides ambulances.


They are co-located and have very similar vehicles, different colours 
and lettering. The staff that man them have less training.



If they were completely separate then I'd use different tags. But what 
tags to use?
Not emergency as they are scheduled and not urgent. Amenity? 
amenity=patient_transport?


Same here -- some organisation provide emergency medical services _and_ 
patient transport, some do only emergency medical services and some do 
only patient transport. I think there really is a need to differentiate 
that.


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


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-21 Thread dktue

I personally think that

    amenity=ambulance_station + building=ambulance_station

would work well and fit in the schema we're using for

    * schools
    * hospitals
    * fire stations

but: it's not amenity=ambulance_station we're using at the moment. We're 
using emergency=ambulance_station -- so: How do we solve this?



Am 21.09.2018 um 11:17 schrieb Anton Klim:
I’m not sure I understand why it would be a landuse instead of an 
amenity tag on the area, or the other way round? Are landuses supposed 
to be for larger areas?


21 сент. 2018 г., в 9:58, Colin Smale <mailto:colin.sm...@xs4all.nl>> написал(а):


What about landuse=ambulance_station on the area? What would the 
landuse be otherwise?


Asking for a friend...


On 2018-09-21 10:47, dktue wrote:


How about ambulance stations?

Should we tag the area with emergency=ambulance_station and the 
building with building=ambulance_station?


dktue

Am 21.09.2018 um 03:23 schrieb Mike H:
I've only mapped one station like this so far, but the area is 
actually rendered on the map. 
https://www.openstreetmap.org/way/616033018


On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer <mailto:t.pfei...@computer.org>> wrote:


Yes of course, I've been doing this for long already.

On 20.09.2018 14:06, Philip Barnes wrote:
> Yes, just go for it. Makes perfect sense.
>
> Phil (trigpoint)
>
> On 20 September 2018 12:56:03 BST, dktue
mailto:em...@daniel-korn.de>> wrote:
>
>     Hello,
>
>     I love how we map areas with amenity=school and buildings
inside of it
>     with building=school. The same goes for amenity=hospital and
>     building=hospital.
>
>     What I'd like to have is the same schema for
firestations: They often
>     have a large area and one or multiple buildings on it.
>
>     Should I go with amenity=fire_station for the area and
>     building=fire_station for the buildings inside of it?
>
>     Cheers,
>     dktue

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

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



___
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] Area of Firestations / Area of Ambulancestations

2018-09-21 Thread dktue

How about ambulance stations?

Should we tag the area with emergency=ambulance_station and the building 
with building=ambulance_station?


dktue

Am 21.09.2018 um 03:23 schrieb Mike H:
I've only mapped one station like this so far, but the area is 
actually rendered on the map. https://www.openstreetmap.org/way/616033018



On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer <mailto:t.pfei...@computer.org>> wrote:


Yes of course, I've been doing this for long already.

On 20.09.2018 14:06, Philip Barnes wrote:
> Yes, just go for it. Makes perfect sense.
>
> Phil (trigpoint)
>
> On 20 September 2018 12:56:03 BST, dktue mailto:em...@daniel-korn.de>> wrote:
>
>     Hello,
>
>     I love how we map areas with amenity=school and buildings
inside of it
>     with building=school. The same goes for amenity=hospital and
>     building=hospital.
>
>     What I'd like to have is the same schema for firestations:
They often
>     have a large area and one or multiple buildings on it.
>
>     Should I go with amenity=fire_station for the area and
>     building=fire_station for the buildings inside of it?
>
>     Cheers,
>     dktue

___
Tagging mailing list
Tagging@openstreetmap.org <mailto: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] Area of Firestations

2018-09-20 Thread dktue

Hello,

I love how we map areas with amenity=school and buildings inside of it 
with building=school. The same goes for amenity=hospital and 
building=hospital.


What I'd like to have is the same schema for firestations: They often 
have a large area and one or multiple buildings on it.


Should I go with amenity=fire_station for the area and 
building=fire_station for the buildings inside of it?


Cheers,
dktue

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


[Tagging] What is the height of this wall?

2018-08-30 Thread dktue

Hi,

have a look at this wall from the waterside [1]: It's probably 3 meter 
high. On the otherhand, from the other side [2] it's only about 80cm 
high. What is the height I should insert into the height-tag?


cheers,
dktue

[1] https://www.hauserfoto.com/img/s/v-3/p14189406-5.jpg
[2] 
http://thebirdsnewnest.com/tbnn/wp-content/uploads/2015/02/T%C3%BCbingen5.png


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


Re: [Tagging] Properties of swimming pools

2018-08-30 Thread dktue
I also think the temperature-tag-proposal was very well thought through. 
This is why I now used it to tag the temperature of the pools.


Am 30.08.2018 um 14:17 schrieb Paul Allen:
On Thu, Aug 30, 2018 at 12:34 PM, Warin <61sundow...@gmail.com 
> wrote:



Temperature, I am afraid, is mine.
https://wiki.openstreetmap.org/wiki/Proposed_features/Temperature



It seemed reasonably well thought out and written. Shame it failed.  
It seems it might
have been approved had you said the degree symbol was optional.  
People could use it
if they wished but people could omit it.  Parsers in renderers could 
cope with people using
symbols of similar appearance by simply ignoring anything that isn't a 
digit, a decimal point
and C or F, incidentally handling the degree symbol being optional.  
In fact your table of incorrect
usage shows the degree symbol on the corrected usages, so it appears 
even you consider it

optional.

The only thing I have a problem with is referring subjective 
temperatures to ambient.  For me, subjective
temperatures are referred to body temperature.  Is it warmer or colder 
than me?  Especially when dealing
with water I am going to immerse body parts in.  It makes even less 
sense to consider ambient temperature
when dealing with extreme ambient conditions.  An open-air swimming 
pool in the middle of winter might be
warmer than ambient by several degrees in the late afternoon when the 
air is cooling down but the thermal
inertia of the water keeps it warm, but it's still damned cold.  So 
I'd refer subjective temps to body temp
and add "ambient" as an objective value.  Which makes tap water (in 
most parts of the world) cold whether
it's colder or warmer than ambient, because it's colder than me (which 
is why it feels cold).


Can proposals be resurrected?  Or a new proposal started which is very 
similar but
with changes that might improve its chances of approval?  In any case, 
I'd use the tag if I needed to

specify a temperature on something.

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


[Tagging] Properties of swimming pools

2018-08-30 Thread dktue

Hello,

I would like to tag information about the water-temperature and the 
depth of the separate pools in the outdoor-swimming pool [1]. Are there 
any suggested tag-names or should I just go with "depth" and "temperature"?


cheers,
dktue


[1] https://www.openstreetmap.org/#map=19/48.51091/9.03987

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