Re: [Tagging] new page for tree_lined=*

[Peter Elderson]

Martin Koppenhoefer:

> I think we can assume that a line of trees in the middle is sufficient to
> make mappers use 2 highways instead of 1!? How can we distinguish between
> the following sections
> tree - road - tree - road - tree
> and
> tree - road - tree - tree - road - tree
> and
> tree - road - tree - significant “void“ space - tree - road - tree?
>

I would not make too much of it. The attribute gives the aspect of the
road, not the actual feature with details. So, all cases: both roads look
tree lined at both sides, so they get tree_lined=both.

If the space is significant, better map it as a landuse feature. Sometimes
a complete wildlife reserve can be found between road halves.

Example:  trees - road - trees - cycleway : the road gets tree_lined=both
and the cycleway tree_lined=left (assuming forward direction of the way and
righthand driving).

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

[Alan Mackie]

On Sat, 15 Aug 2020 at 18:12, Paul Allen  wrote:

> On Sat, 15 Aug 2020 at 17:05, Steve Doerr  wrote:
>
>> On 12/08/2020 19:27, Paul Allen wrote:
>>
>>
> I would interpret 'Collects', 'Issues', 'Spreads', and possibly 'Sinks' as
>> verbs in the third person singular, rather than plural nouns.
>>
>
> That's a bit of an issue, although I think you've included the kitchen
> sink.
>
> Kitchen sinks are more of an indoor tagging thing. :-P


> It is not unknown in English for verbs to get nouned and nouns to get
> verbed.
> Especially in technical English like mapology.
>
> This might affect how we tag them, as we mainly use nouns and adjectives,
>> I think.
>>
>
> As used by OS, these are nouns.  If we had non-cartographic equivalents in
> British English then maybe we should use those instead.  If we decide that
> we want to tag such things in the first place.
>
> --
> 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] Tagging specialized head lice removal salons

[Martin Koppenhoefer]

sent from a phone

> On 16. Aug 2020, at 01:06, Graeme Fitzpatrick  wrote:
> 
> I'd leave it up to his listed website, &, if necessary, his receptionist :-)


or just the name, people could google for the website ;-)
Seriously, I am in favor of adding such detail in a semantic way. If we all do 
it chances are that it could work out, and in the meantime it is not doing any 
harm. For sure a person reading the tag could form an idea what kind of place 
it is, much better as with the website link alone

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 16. Aug 2020, at 01:06, Graeme Fitzpatrick  wrote:
> 
> Having said that, though, I'd also agree with you that lice is a "health" 
> issue, so healthcare= seems a better option.


+1, while not actually dangerous in most cases (transmission of other diseases 
is possible in theory), the mere fact these parasites are living on someone’s 
head is considered a “parasitic disease”.

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

Re: [Tagging] Tagging specialized head lice removal salons

[Graeme Fitzpatrick]

On Sun, 16 Aug 2020 at 06:16, Lisbeth Salander  wrote:

> The only reason I even proposed healthcare is because, well, it *is* a
> hygiene and health problem... and both amenity and shop seemed too
> generic.
>
I did just have a thought, remembering that a while ago a new tag went
through for the sort-of, *very* broadly similar :-) footwear
decontamination:
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dfootwear_decontamination
as a man_made=, so amenity= *could* possibly work?

Having said that, though, I'd also agree with you that lice is a "health"
issue, so healthcare= seems a better option.

> On Fri, 14 Aug 2020, Graeme Fitzpatrick 
>  wrote:
>
> I've just had a hip replacement done, so saw the orthopaedic surgeon this
> week for a follow up. While I was waiting, his receptionist took a call, &
> had to tell the caller that "I'm sorry, Dr doesn't work on wrists. He
> specialises in hips & knees"
>
> How would we map that? healthcare=orthopaedics +
> healthcare:speciality=hips;knees?
>

To be honest, I wouldn't!

I'd leave it up to his listed website, &, if necessary, his receptionist :-)

Thanks

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

Re: [Tagging] new page for tree_lined=*

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 17:31, Peter Elderson  wrote:
> 
> a continuous line of evenly spaced trees at both sides, sometimes also in the 
> middle, sometimes double or triple rows at each side, often with a separately 
> lined cycleway and tree_lined ditches.


thank you for bringing up middle rows, and double and triple rows. While these 
can be mapped as individual tree rows, it might also be interesting to have a 
scheme (similar to the lanes scheme) to add these layouts as an attribute. I 
think we can assume that a line of trees in the middle is sufficient to make 
mappers use 2 highways instead of 1!? How can we distinguish between the 
following sections
tree - road - tree - road - tree
and
tree - road - tree - tree - road - tree
and
tree - road - tree - significant “void“ space - tree - road - tree?

Cheers Martin 




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

[Tagging] Feature Proposal - Voting - Green alley

[- -]

Hi all,

I'd like to revive an old proposal, namely the "*Green alley*".

Description:
A green alley is a service alley that a group of local residents embellish
with vegetation, such as trees, vines and flowers. This collective effort
results in a better quality of life for residents in addition to reduce the
phenomenon of urban heat islands.

Cities with a special program can support these renaturalization efforts by
providing tools and special materials, or by performing special roadwork
such as digging holes for plants and trees.

Link to the wiki:
https://wiki.openstreetmap.org/wiki/Proposed_features/green_alley

Original discussion on tagging mailing list:
https://lists.openstreetmap.org/pipermail/tagging/2013-August/014514.html

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

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

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 17:33, Arne Johannessen  wrote:
> 
> Therefore, the tunnel's name is the primary name for that particular way, and 
> thus belongs into the name=* tag.
> 
> The full name tagging for a road tunnel should usually look like this:
> 
> name=The Tunnel
> highway:name=The Road


I would see this as an awkward exception to the whole system if we followed 
your reasoning and said that in the case of highway=* + a specific property 
this property would change the semantics and the property would define the 
feature while the highway (or waterway) would become secondary.

To me it seems clear that a tunnel is often more than just the road leading 
through it, so that the logical consequence is that the tunnel=yes is 
interpreted as a thing being inside a tunnel (i.e. tunnel is implicit), just as 
it is the case with bridges (man_made=bridge is the bridge, bridge=yes means on 
a bridge).

Also note that highway:name is objectively an unused tag with only 188 
occurrences for a total of 178 million highway objects, many of them being in 
china where mapping is underdeveloped due to the general ban of distributed 
citizen mapping.

Also compare this to 12815 occurrences of tunnel:name.

I see your interpretation as a change in paradigm and would invite you to 
formally propose it with the proposal process in order to check the support of 
the community, if you really believe this definition would be beneficial.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 19:12, Paul Allen  wrote:
> 
> If we decide that
> we want to tag such things in the first place.


as there was significant discussion how to tag them, it doesn’t seem that not 
mapping them is an option we still have to discuss 


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 Fri, 14 Aug 2020, Paul Allen  wrote:


Yeah, we try to avoid putting two top-level tags on the same object
because
of nasal demons: http://catb.org/jargon/html/N/nasal-demons.html


That's awfully pessimistic, but I see your point. I suppose having some
hairdressers rendered as generic healthcare providers will be
confusing... and no general-purpose renderer will adapt to something as
minor as this. So I'll relent.

I'd really like a tag we could use for both hairdressers and
specialists, but unless we find a less monstrous version of
lice_removal_treatment_on_premise=yes I'll let it go.

On Fri, 14 Aug 2020, Martin Koppenhoefer  wrote:


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

I'm in the same boat, actually. In Spanish these are never called
"clinics", they're either "centros de eliminación de piojos" (lice
elimination centres) or "peluquerías de piojos" (lice hairdressers).

I don't know what's the expectation in English-speaking countries, but I
find it difficult to categorise this as a clinic. I'm not even sure if
they operate under the same laws as speech therapists and typical
clinics in Spain; I think not.

The only reason I even proposed healthcare is because, well, it /is/ a
hygiene and health problem... and both amenity and shop seemed too generic.

On Fri, 14 Aug 2020, Graeme Fitzpatrick  wrote:


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

How would we map that? healthcare=orthopaedics +
healthcare:speciality=hips;knees?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Allen]

On Sat, 15 Aug 2020 at 17:05, Steve Doerr  wrote:

> On 12/08/2020 19:27, Paul Allen wrote:
>
>
I would interpret 'Collects', 'Issues', 'Spreads', and possibly 'Sinks' as
> verbs in the third person singular, rather than plural nouns.
>

That's a bit of an issue, although I think you've included the kitchen sink.

It is not unknown in English for verbs to get nouned and nouns to get
verbed.
Especially in technical English like mapology.

This might affect how we tag them, as we mainly use nouns and adjectives, I
> think.
>

As used by OS, these are nouns.  If we had non-cartographic equivalents in
British English then maybe we should use those instead.  If we decide that
we want to tag such things in the first place.

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

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

[Yves]

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] Waterway equivalent of noexit=yes?

[Steve Doerr]

On 12/08/2020 19:27, Paul Allen wrote:

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


I would interpret 'Collects', 'Issues', 'Spreads', and possibly 'Sinks' 
as verbs in the third person singular, rather than plural nouns. This 
might affect how we tag them, as we mainly use nouns and adjectives, I 
think.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Yves]

Interesting:
https://pistetopowder.com/the-new-schindlergratbahn-lift/
Quote:
Facts & Figures

Bottom station: 2,035 m
Middle station: 2,643 m
Mountain station: 2,579

OK, maybe 'head' is not ideal, but I think it's worth to find something else 
than 'upper'
Yves 

Le 15 août 2020 13:37:31 GMT+02:00, Werner.Haag@leitstelle.tirol a écrit :
>
>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

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

[Arne Johannessen]

dktue  wrote:
> Am 15.08.2020 um 11:18 schrieb Martin Koppenhoefer:
>> [...] 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.

Yes. This was my point exactly.


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

Yes, I oppose, as I've said in my earlier message.


The way I see it, a road is represented as a series of OSM ways. A tunnel is 
typically represented by adding the tag tunnel=yes to one of them. For that 
particular way (!), the fact that there is a tunnel is usually more important 
than the fact there is a road. Common usage reflects this as well (e. g. in 
radio traffic reports). Therefore, the tunnel's name is the primary name for 
that particular way, and thus belongs into the name=* tag.

The full name tagging for a road tunnel should usually look like this:

name=The Tunnel
highway:name=The Road

Possible alternative (some duplication, but perhaps more clear?):

name=The Tunnel
tunnel:name=The Tunnel
highway:name=The Road

IIUC, the proposed change would basically result in:

name=The Road
highway:name=The Road
tunnel:name=The Tunnel

Coming from current practice, I'd say this tagging is correct if and only if 
locals actually commonly refer to the section of road inside the tunnel by the 
road name instead of the tunnel name most of the time.

I'm sure that's true for some tunnels, but I am not currently aware of even a 
single one of those. It's clearly not the typical case. Therefore, the proposed 
change doesn't seem like a good idea to me.


As a counter-proposal for the tunnel=* page, we could perhaps replace the name 
sentence with something like this:

[[
The common name of a tunnel should usually be tagged as name=*. If whatever 
goes through the tunnel has a separate name, that name may be added using e. g. 
highway:name=*. If necessary (e. g. to avoid doubt), the tag tunnel:name=* may 
be added containing the name of the tunnel, specifically.
]]


 currently says:
| 
| Names recorded in name=* tag are ones that are locally used, [...]
| 
| It should be the most prominent signposted name or the most
| common name actually used to refer to a given object, [...]


-- 
Arne Johannessen



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

Re: [Tagging] new page for tree_lined=*

[Peter Elderson]

Nederland has an awful lot of ways, waterways, railways, rivers, parkings,
churchyards, and other linear and area features which are lined with a row
of trees. And if I say a row of trees, think of 10 Km almost straight with
a continuous line of evenly spaced trees at both sides, sometimes also in
the middle, sometimes double or triple rows at each side, often with a
separately lined cycleway and tree_lined ditches.

Even in the woods, roads often have a separate distinct tree lining, often
between the road and the cycleways on both sides.

As it is a distinctive and verifiable (by survey, by viewers and by
satellite imagery) attribute of the road, it is worth mapping as
secondary tag. The purpose varies and can be guessed but seldom verified,
so best not try to define by purpose, just map what you see. Unlike
cycleways and sidepaths along roads, no routing has to be done over a line
of trees, but the attribute is nice to know for cyclists, hikers and
motorists.

One thing: we have tree rows in the middle of a road, not always combined
with a side tree row.
Maybe map that as a tree_row feature?

About generic: I wouldn't call tree_lined a generic attribute. It
specifically says the feature is lined by trees. Generic tagging IMO would
be: lined=* where the value specifies which lining is used.
If you want further specification of the tree_line details, I would suggest
to use natural=tree_row and tag everything you wish to record about the
trees.

I don't really care if it's on a separate tree_line page.

Best, Peter Elderson


Op vr 14 aug. 2020 om 01:08 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

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

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

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

[Martin Koppenhoefer]

sent from a phone

>> On 15. Aug 2020, at 13:47, Mateusz Konieczny via Tagging 
>>  wrote:
> I oppose such potential removal


here is an example:
https://wiki.openstreetmap.org/wiki/Highways

this is maybe not bad as a general overview, but then it duplicates significant 
part of the information from the individual pages, without being exhaustive 
though, hence contradicting sometimes the specific tag pages. In other words, 
people who want to inform themselves have to read more (because they will read 
the same thing multiple times) and will remain confused by the contradictions.

The page is actually very poor, due to some severe errors, e.g.
“ Motorways are sole roads that are tagged based on physical characteristics 
and tagged with highway=motorway and highway=motorway_link.”

to me, this seems utterly nonsense, as motorways are legally defined (and also 
because there are other highway classes where the distinction is by physical 
characteristics, e.g. path vs. track).


Also the following sentence hurts: “There is group of roads are tagged based on 
importance in road network”

This is supposed to be the introduction to roads in OpenStreetMap, can there 
really be so many orthographic errors? What’s the image we are conveying, how 
much would you think you can rely on information that is presented with this 
level of care?


Another example: “ highway=unclassified is a bit special here, given confusing 
name (it is not for roads that are not classified) and has no link variant”

-> It does not say what unclassified is used for, only what it isn’t.

Another example from the summary page: “ highway=path needs tags to designate 
what traffic is legally allowed or may be appropriate. Use access=*, bicycle=*, 
foot=* and other access tags.”


This is actually wrong because path does not “need” other qualifying tags in 
general, and because the generic „access“ should not be added to a path 
typically. 
There is also no mention of „designated“ as value for bicycle or foot, so 
without reading the path page it is not helpful.


Other problems are that it doesn’t make clear that the highway also represents 
sidewalks. For example the sentence “If only buses are allowed then access=no 
together with bus=yes would be appropriate.” is only true for a road or 
carriageway without sidewalks, because this will also prevent pedestrians from 
being routed over this way.

I would prefer to give relevant information on  
https://wiki.openstreetmap.org/wiki/Key:highway which gives an overview as 
well, transfer otherwise missing stuff from the “Main Article” and delete these 
overviews, as apparently nobody is interested in keeping an eye on them against 
well meaning but ultimately defacing “improvements”.

I could go on (or improve the page, which I have also just done, regarding 
bridges), but IMHO the problem is we have only limited capacities so we will 
have to concentrate our efforts. Having the information on less places is not 
bad, let’s start by removing these well meaning duplications ;-)
Or make reviewed versions of these (thinking of them as introductions), and 
block them from general editing. Changes could still be applied, but would have 
to be discussed and approved before they went live (more a kind of git style), 
not for the wiki in general, but for these “Main articles” (and not instantly, 
but after we all have looked through the current state and removed at least the 
obvious errors ;-) ).

Cheers Martin 



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

Re: [Tagging] new page for tree_lined=*

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 13:47, Mateusz Konieczny via Tagging 
>  wrote:
> 
> I oppose such potential removal


referring to which page?

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

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

[Paul Allen]

On Sat, 15 Aug 2020 at 02:36, Tod Fitch  wrote:

>
> One question I have on this is how much are the OS maps tailored to the UK
> environment?
>

The OS maps of the UK are very much tailored to the UK environment.  I
don't know if they are, or ever were, responsible for mapping portions of
the British Empire and possessions.

I’ve only been to the UK a couple of times but my impression is there isn’t
> much arid or even semi-arid land there to be mapped.
>

Not much.  Not any, that I can think of (but I don't know the entire UK in
great
detail).  That just means that we cannot look to Ordnance Survey for clues
as
to what tagging might be useful for arid areas.  It can still provide clues
for
what we might find useful when mapping terrain that is wet, cold, and full
of
sheep. :)  There is no point re-inventing the wheel, but we shouldn't assume
that other people's wheels are perfect.

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

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

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

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

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

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

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

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

[Yves]

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
https://lists.openstreetmap.org/listinfo/tagging

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

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

[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 [1] 
>> 
>> 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
 

Links:
--
[1] https://www.openstreetmap.org/way/23103020___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

As long as it explicitly notes that 
name and tunnel:name may be the same
I am ok with that

15 Aug 2020, 12:19 by em...@daniel-korn.de:

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

Re: [Tagging] new page for tree_lined=*

[Mateusz Konieczny via Tagging]

I oppose such potential removal

15 Aug 2020, 12:47 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 15. Aug 2020, at 07:32, Volker Schmidt  wrote:
>>
>> would suggest to create a single wiki page for tree-lined road mapping, so 
>> that we have one place where we describe the three different approaches for 
>> mapping them.
>>
>
>
> we have one place (the wiki) and the possible ways are linked between each 
> other. Setting up an additional page only creates more places to maintain and 
> which risk of getting out of sync.
> I would rather propose the opposite, removing those generic pages for 
> features which aren’t feature definitions but collections of tags (e.g. 
> „speed limits“).
>
>
> 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] Antwort: Re: Antwort: Re: Aerialway stations

[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

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

[Werner . Haag]

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

Re: [Tagging] new page for tree_lined=*

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 07:32, Volker Schmidt  wrote:
> 
> would suggest to create a single wiki page for tree-lined road mapping, so 
> that we have one place where we describe the three different approaches for 
> mapping them.


we have one place (the wiki) and the possible ways are linked between each 
other. Setting up an additional page only creates more places to maintain and 
which risk of getting out of sync.
I would rather propose the opposite, removing those generic pages for features 
which aren’t feature definitions but collections of tags (e.g. „speed limits“).


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

Re: [Tagging] new page for tree_lined=*

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 07:32, Volker Schmidt  wrote:
> 
> I do see these issues with adding sidewalks and cycle paths, where we have a 
> similar choice between mapping as separate objects or as road property.


it is often perceived as an either or choice, but there is no reason to not do 
both.

Looking at the discussion here, I am thinking it might eventually be better to 
use a different tag for the property I have in mind, because “tree_lined” is 
very generic, while I am mostly after scenic, specifically planted trees, not 
incidentally occurring trees. 
Maybe a subtag tree_line=avenue would make sense?
Osm history shows that every time where a generic word is used to tag a 
specific feature or property, the meaning of the tag becomes blurred after a 
while.

Cheers Martin 


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

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

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

[Martin Koppenhoefer]

sent from a phone

> On 15. Aug 2020, at 01:21, Arne Johannessen  wrote:
> 
> That's precisely why man_made=tunnel is so rare.



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.


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