Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Graeme Fitzpatrick
On Sun, 13 Dec 2020 at 12:14, Graeme Fitzpatrick 
wrote:

>
> Break - I've just found that there actually are a handful of
> club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
> although all are undocumented, so they will be fine.
>

Seeing that these are already in use, albeit in miniscule numbers, is there
any need to go through the full RFC & vote procedure, or can I just create
pages for them?

Thanks

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


[Tagging] Feature Proposal - RFC - wait

2020-12-12 Thread António Madeira

Greetings.

As discussed here in the mailing list, me and L___I have created a
proposal for the key "wait":
https://wiki.openstreetmap.org/wiki/Proposed_features/wait

Please, comment here in the list or in the wiki talk page.


Previous discussions:
https://lists.openstreetmap.org/pipermail/tagging/2020-May/052321.html
https://forum.openstreetmap.org/viewtopic.php?id=69011


Regards,
António.

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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Brian M. Sperlongano
> Break - I've just found that there actually are a handful of
> club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
> although all are undocumented, so they will be fine. Are we all in
> agreement though, that there should be no reference to "military" against
> Cadet groups (except, of course, for those countries where they *are*
> actually part of the military!)?
>

I would tend to agree - cadet groups are not a military service like an
army or navy.


> One other thing I've realised from this exercise is that the "Military"
> page needs further cleaning-up, but let's get this one out of the way
> first! :-)
>

Excellent - I look forward to your effort and enthusiasm trying to sort
this all out!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Graeme Fitzpatrick
On Sat, 12 Dec 2020 at 19:30, Martin Koppenhoefer 
wrote:

> Which military service are the Italian Carabinieri? The US Marines?
>
What about the Guardia di Finanza?
>

Yep, as mentioned previously, there will be a number of fine, fuzzy lines
(& yes, both words apply!) to sort out, mainly between "Police" &
"Military".

I can tell you that the US Marines belong to the US Marine Corps, which
comes under the overall command of the US Navy. The British Royal Marines,
however, are directly under command of the Royal Navy, with no intervening
command level.

No idea on the other two‽

I agree we will probably find use for both, a specific operator tag and a
> more generic attempt to put the things into boxes.
>

Yes, I agree.

In regard to operators - "USMC" or "United States Marine Corps", & the same
for all the other names ie abbreviated or spelt if full ?

Another couple of issues I've spotted as I've been looking at some of the
current listings for military=barracks.

Ex-military bases, now often either historical precincts / tourist
attractions / possibly ruins only eg Fort Lytton
https://www.openstreetmap.org/#map=17/-27.41058/153.15263,
https://fortlytton.org.au/ & many more similar worldwide. They were, but
are not now military areas, so how should we tag them?
museum + tourist attraction + was:landuse=military + was:military=base, or
ignore all reference to "military"?

The other one is Cadet units eg Army / Navy / Air Force Cadets? I don't
know about other countries, but in Australia at least, while they are named
"Australian Army Cadets", they are classified as a youth group only, & not
linked to the military forces in any way. So what should we tag their depot
/ training building as?

There used to be a tag for club+youth, but this was scrubbed in favour of
amenity =community_centre
 +
community_centre:for
=juvenile

The problem I have with that is that these buildings are not open to the
general public, or for use by other community groups, so they wouldn't meet
the usual criteria.

Break - I've just found that there actually are a handful of
club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
although all are undocumented, so they will be fine. Are we all in
agreement though, that there should be no reference to "military" against
Cadet groups (except, of course, for those countries where they *are*
actually part of the military!)?

One other thing I've realised from this exercise is that the "Military"
page needs further cleaning-up, but let's get this one out of the way
first! :-)

Thanks

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread stevea
Anders, I didn't see this until after I sent my reply.

I believe this list here is interested in what you call "missing features," as 
a list.  I look at them as challenges of ours or frustrations of yours which 
can either be explained or solved.  You might not like the explanations.

For example, if you were to expound upon differences between "mountain" (as 
Anders, or Sweden understands it) and natural=peak (as OSM understands it), 
we're listening.  You might be prompted to "make a proposal for mountain" or 
"write a wiki for how your first mountain=whatever or whatever=mountain tag you 
recently started to enter (because it is well thought-out, defined, follows 
sensible rules about 'what it is' and 'how it is tagged'...)" is now extant, 
and so on.

To solve such frustrations doesn't necessarily include this or that about 
mountaineering.  This is called reducing the map consumer's perspective, as you 
simply "tag well and accurately using a syntax expressing what you mean."  If 
there is no such tagging, we might support it (as new tagging and/or a new 
proposal) and maybe someday it will be rendered.  This is (partly) how our map 
data have grown, it is how our map data continue to grow.

SteveA

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread stevea
I don't approach this as getting solved in one multipolygon.  I might use two 
multipolygons, one tagged wetland=bog, another tagged wetland=marsh, both 
tagged natural=wetland.  Add name=* as appropriate.  Closed ways (plus other 
things, with other tags) do overlap (these two seem they should not).  Let 
renderers deal with such issues.

Different than natural=* tagging, there is also a proposal that includes an 
"unadorned" boundary=protected_area tag (on a closed way or a relation), 
without a protect_class tag (one is not known or is "less known").  This might, 
someday, render as a simple green line.  This conveys what is (an often legal) 
boundary, so it isn't natural=*.  See if this proposal 
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap your 
logic (and OSM's syntax, a boundary=protected_area tag, or its semantics, a 
perhaps-someday-drawn rendered green line) around this.  Untangling natural, 
leisure and boundary tagging is ahead in OSM, things do get better.

How (the Carto, for example) renderers draw natural=* on top of one another is 
actually a rich topic:  it can be said these behaviors are renderer specific.  
(Yes, Carto "drawing order" is not necessarily perfectly defined).  These are 
complex topics, getting better as proposals gain approval (a working strategy 
so far).  The example of natural=* tagging below is a topic of some confusion 
among mappers.  For example, I don't believe Carto rendering is perfectly 
predictable without first knowing "size of all overlapping polygons."  This can 
make "accurate" (or pleasing) natural tagging challenging or unpredictable in 
some circumstances.  I believe at least some of what is rendered has to do with 
the size (and order entered?) of overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable tagging 
them, as accurately as I know how, using OSM's wiki to describe tagging.  
Multipolygons differ from relations like them which aren't (like those tagged 
boundary=*), independently as far as renderers are concerned.  It is easy to 
get confused, confusion exists in the map:  semantics are blurry in some cases. 
 This gets better with worldwide consensus, over years.  This (how we learn to 
best tag and render) is an ongoing long-term OSM process.  As a mapper, "tag 
accurately first," then let renderers interpret.

SteveA

> On Dec 11, 2020, at 11:53 AM, Anders Torger  wrote:
> 
> Unfortunately I don't think that is possible.
> 
> Multipolygons may only contain ways that have either role as inner or as 
> outer. It may not contain other relations (still possible to upload, but not 
> considered right according to the wiki). What should the ways be?
> 
> We can't make the separate wetland parts as inner ways, (as areas formed by 
> the inner ways are subtracted from the multipolygon), and even if we try it 
> becomes illegal as inner ways cannot share segments with the outer way. We 
> can't make the parts as outers either as they share segments. The outer must 
> be the surrounding outline without the shared segments splitting the wetland 
> in parts, and there are no inners (unless the parts themselves has inners).
> 
> So then we have a multipolygon with just an outer. I could just as well be a 
> plain polygon made from a single closed way. This would work if drawing order 
> was defined, and that was the method I tried first. The container polygon 
> must have a natural tag as well (the logical would be wetland here without 
> further sub-classification). 
> 
> However the drawing order is not defined (I think, not 100% sure), so this is 
> by the renderer interpreted as a wetland lying on top of the other wetlands. 
> OSM-Carto will still render the insides, but the fill pattern of the outer 
> polygon is drawn on top.
> 
> On 2020-12-11 18:09, Brian M. Sperlongano wrote:
> 
>> Hello Anders,
>>  
>> I would recommend creating a multipolygon relation (type=multipolygon) with 
>> each of the wetland pieces, and set the name= and appropriate natural= and 
>> wetland= tags on the relation.
>> 
>> On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:
>> Hello,
>> 
>> I was on this list a while back expressing some frustration over 
>> limitations when tagging nature and thought about getting involved in a 
>> process for change, but I came to realize that it's not feasible for me 
>> in my current life situation, so I've decided to continue be a normal 
>> mapper as before, doing what I can do with features that exist today.
>> 
>> Anyway, if to be a mapper at all, I still like to solve some of my 
>> naming issues in the best/least bad ways possible today. I'm currently 
>> mapping a national park in Sweden, Muddus. It's in Laponia and consists 
>> of mighty wetlands and old forest. These wetlands are named, like is 
>> common in Sweden and Sami lands. For us navigating in wildlife, names in 
>> nature are important.
>> 
>> A wetland polygon can be named in OSM, so the situation is 

Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Martin Koppenhoefer


sent from a phone

> On 12. Dec 2020, at 23:43, Paul Johnson  wrote:
> 
> So what?  How are we going to improve if we're not willing to correct choices 
> that are objectively bad in retrospect?  Especially when fixing the problem 
> makes lane tagging more consistent for all lane types and easier for new 
> people to understand and map in the long term


use a different key for the different definition. Promote it and see if others 
join you.

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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Paul Johnson
On Sat, Dec 12, 2020 at 4:37 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 12, 2020, 18:27 by ba...@ursamundi.org:
>
>
>
> On Sat, Dec 12, 2020 at 11:22 AM Jan Michel  wrote:
>
> On 12.12.20 17:47, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel
> >  > > wrote:
> >
> > On 12.12.20 17:25, Paul Johnson wrote:
> >
> >  > Sure, if you manually torque tag it to match the incorrect
> >  > documentation.  As soon as you open the lane editor, it rightly
> > corrects
> >  > it to lanes=5, since you have 2 lanes in one way and 3 in the
> other.
> >
> > The "incorrect documentation" was voted on and it was approved.
> >
> >
> > I'm pretty sure it was done without consideration for reserved lanes as
> > lane access tagging wasn't something yet available.  Now it is, and it's
> > time to reconsider that.
>
> I'm refering to the proposal of exactly this: the :lanes extension. It
> was clearly and unambiguously taken into account:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag
>
>
> That specific anchor says it's completely sidestepping the issue while
> highlighting the shortcoming of lanes=* as it stands now.  We need to fix
> lanes=* to mean all lanes.  This isn't a hard change to make
>
> It would redefine widely used tag.
>

So what?  How are we going to improve if we're not willing to correct
choices that are objectively bad in retrospect?  Especially when fixing the
problem makes lane tagging more consistent for all lane types and easier
for new people to understand and map in the long term?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Mateusz Konieczny via Tagging



Dec 12, 2020, 18:27 by ba...@ursamundi.org:

>
>
> On Sat, Dec 12, 2020 at 11:22 AM Jan Michel <> j...@mueschelsoft.de> > wrote:
>
>> On 12.12.20 17:47, Paul Johnson wrote:
>>  > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel 
>>  > <>> j...@mueschelsoft.de>>  
>>  > > j...@mueschelsoft.de>> >> wrote:
>>  > 
>>  >     On 12.12.20 17:25, Paul Johnson wrote:
>>  > 
>>  >      > Sure, if you manually torque tag it to match the incorrect
>>  >      > documentation.  As soon as you open the lane editor, it rightly
>>  >     corrects
>>  >      > it to lanes=5, since you have 2 lanes in one way and 3 in the 
>> other.
>>  > 
>>  >     The "incorrect documentation" was voted on and it was approved.
>>  > 
>>  > 
>>  > I'm pretty sure it was done without consideration for reserved lanes as 
>>  > lane access tagging wasn't something yet available.  Now it is, and it's 
>>  > time to reconsider that.
>>  
>>  I'm refering to the proposal of exactly this: the :lanes extension. It 
>>  was clearly and unambiguously taken into account:
>>  >> 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag
>>
>
> That specific anchor says it's completely sidestepping the issue while 
> highlighting the shortcoming of lanes=* as it stands now.  We need to fix 
> lanes=* to mean all lanes.  This isn't a hard change to make
>
It would redefine widely used tag.

So we would need to resurcey all places where lanes tag is used.

And MapRoulette is not an answer in this case. It would only work if all 
11 millions tags would be in places where aerials is highly detailed, 
up to date and road is not covered by trees.

See https://taginfo.openstreetmap.org/keys/lanes

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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Paul Johnson
On Sat, Dec 12, 2020 at 11:22 AM Jan Michel  wrote:

> On 12.12.20 17:47, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel
> >  > > wrote:
> >
> > On 12.12.20 17:25, Paul Johnson wrote:
> >
> >  > Sure, if you manually torque tag it to match the incorrect
> >  > documentation.  As soon as you open the lane editor, it rightly
> > corrects
> >  > it to lanes=5, since you have 2 lanes in one way and 3 in the
> other.
> >
> > The "incorrect documentation" was voted on and it was approved.
> >
> >
> > I'm pretty sure it was done without consideration for reserved lanes as
> > lane access tagging wasn't something yet available.  Now it is, and it's
> > time to reconsider that.
>
> I'm refering to the proposal of exactly this: the :lanes extension. It
> was clearly and unambiguously taken into account:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag


That specific anchor says it's completely sidestepping the issue while
highlighting the shortcoming of lanes=* as it stands now.  We need to fix
lanes=* to mean all lanes.  This isn't a hard change to make, but it is a
necessary one to disambiguate lane tagging.

Which means any lane editor that sees the turn:lanes or access:lanes tag is
going to count that and go "OK, there's at least this many lanes" and fix
the count.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Jan Michel

On 12.12.20 17:47, Paul Johnson wrote:
On Sat, Dec 12, 2020 at 10:46 AM Jan Michel 
> wrote:


On 12.12.20 17:25, Paul Johnson wrote:

 > Sure, if you manually torque tag it to match the incorrect
 > documentation.  As soon as you open the lane editor, it rightly
corrects
 > it to lanes=5, since you have 2 lanes in one way and 3 in the other.

The "incorrect documentation" was voted on and it was approved.


I'm pretty sure it was done without consideration for reserved lanes as 
lane access tagging wasn't something yet available.  Now it is, and it's 
time to reconsider that.


I'm refering to the proposal of exactly this: the :lanes extension. It 
was clearly and unambiguously taken into account:

https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag



Setting tags according to documentation is hardly "torquing tags". 


Which "lane editor" do you refer to? If any tool does this, it needs
to be fixed.


JOSM.

Please be more precise. JOSM has no built-in lane-editor.




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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Paul Johnson
On Sat, Dec 12, 2020 at 10:46 AM Jan Michel  wrote:

> On 12.12.20 17:25, Paul Johnson wrote:
>
> > Sure, if you manually torque tag it to match the incorrect
> > documentation.  As soon as you open the lane editor, it rightly corrects
> > it to lanes=5, since you have 2 lanes in one way and 3 in the other.
>
> The "incorrect documentation" was voted on and it was approved.
>

I'm pretty sure it was done without consideration for reserved lanes as
lane access tagging wasn't something yet available.  Now it is, and it's
time to reconsider that.


> Setting tags according to documentation is hardly "torquing tags".

Which "lane editor" do you refer to? If any tool does this, it needs
> to be fixed.
>

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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Jan Michel

On 12.12.20 17:25, Paul Johnson wrote:

Sure, if you manually torque tag it to match the incorrect 
documentation.  As soon as you open the lane editor, it rightly corrects 
it to lanes=5, since you have 2 lanes in one way and 3 in the other.


The "incorrect documentation" was voted on and it was approved.
Setting tags according to documentation is hardly "torquing tags".
Which "lane editor" do you refer to? If any tool does this, it needs
to be fixed.


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


[Tagging] Feature Proposal - Voting - Hazards

2020-12-12 Thread Brian M. Sperlongano
Hello,

Voting is now open for a two-week period on the proposal "Hazards".  I wish
to express my sincere appreciation to the many of you that provided
valuable input during the development of this proposal.

Voting link:
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard#Voting
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Paul Johnson
On Sat, Dec 12, 2020 at 8:34 AM Jan Michel  wrote:

> On 12.12.20 14:25, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 5:25 AM Jan Michel
> >  > > wrote:
> >
> > Hi,
> > where do you see a problem here? The current situation might not be
> > perfect, but it is usable as it is. The only thing to keep in mind is
> > that the number of "lanes" does not need to match the number of
> entries
> > in the "XY:lanes" tags.
> >
> >
> > That disagrees with literally every lane editing and validation tool in
> > existence at this time.
>
> Please check for example this way:
>
> https://www.openstreetmap.org/way/406235586
>
> It perfectly validates in all tools I tried - JOSM, OSMI, Keepright...
> Rendering in the lane attribute style in JOSM is fine as well.
>
> Even the examples in the Wiki show exactly this:
>
> https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
>
> It was mentioned in the original proposal for the :lanes suffix 8 years
> ago.
>
> So, it *agrees* "with literally every lane editing and validation tool
> in existence" as well as documentation.
>

Sure, if you manually torque tag it to match the incorrect documentation.
As soon as you open the lane editor, it rightly corrects it to lanes=5,
since you have 2 lanes in one way and 3 in the other.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger

Thanks.

I appriciate that you say that features are actually missing in this 
context. The usual way things go when I've tried to discuss these issues 
in various OSM forums is that it's incredibly hard to get to a consensus 
that there actually even is a problem at all. I get suggestions to map 
it in some way that either not work at all or has no renderer support by 
any data user out there, and when I point out that the discussion just 
goes silent, and I'm probably just considered annoying.


If one gets past the first hurdle and actually gets to a consensus that 
these things cannot be done today, the next hurdle is "do we want to 
support this?". Also here I tend to get stuck in meta-discussions about 
how hard these features are to render quickly on a map or difficult it 
is to store in the database or show it in the tools, without anyone 
voicing any opinion for or against the desire to actually have this 
feature, just seemingly trying to kill it with arguments that it's just 
too hard to implement. OSM-folks often say that OSM should support not 
only mapping of streets as the name implies, but also nature. But when I 
point at specifics required to actually do this in a good way, I find 
myself stuck.


This wetland question was sort of put to an end with a reply "just name 
all parts the same". It does work for my particular use case, but as you 
point out it's far from a generic concept, and unlikely that it will be 
taken up by renderers as relation is missing. Wetlands do generally have 
sharp borders (although in the national park I'm mapping some of the 
wetlands are so large that they have different names in different 
places). When it comes to peninsulas, valleys, mountains, broad ridges, 
hills, slopes and more natural features we have names for, not so much. 
Personally I'm okay with just drawing an area on top, everyone 
understands that it's fuzzy. Just like we can do today with bays and 
straits. But as discussed in another post, there's overwhelming 
criticism from leading OSM profiles against having fuzzy areas in the 
main database so it's unlikely to happen. And as long as no widespread 
renderer actually uses the data and there's no wiki info on how to name 
these things there's no chance for this to catch on by regular mappers 
actually taking their time to put in the names.


Mountains are in OSM usually mapped as a point, a peak. However, 
mountaineering was not an interest among those that actually named the 
mouintains, so often what has a name is the mountain, not the peak 
itself. But as OSM doesn't support naming mountains, there's lot of 
misleading naming out there. Today I had a mountain to name, it has 
three peaks, but only one name, and the name is on the mountain not the 
peak. The list goes on. For anyone knowledgeable in cartography missing 
features like this are easily identified.


Sure we can choose to have a map that doesn't support them (and say that 
we only intend to support zoomed in urban contexts, I guess that's where 
the money is anyway), but it's not odd features in any way, any 
institutionally made map have them.


/Anders

On 2020-12-12 13:55, Martin Koppenhoefer wrote:

sent from a phone


On 12. Dec 2020, at 12:26, Anders Torger  wrote:

In the wetland case as described, there is no parent relation at all. 
The only thing that ties them together is implicitly by sharing 
borders and having the same name tag. It seems to me that an 
"official" way to edit should tie them together with a parent 
relation.



Yes, we do not have a way to map toponyms for larger areas when we
also want to map detailed landcover within. Christoph’s idea of using
the same names on the parts fails when the individual parts have
different names. We can’t map bigger geographic entities like deserts,
swamplands, forests, highlands (besides the names for the smallest
parts, or if they correspond to other entities with clear boundaries
like nature reserves, or maybe by overlapping the same kind of
objects, what is generally frowned upon)




The logical way would be a parent relation with type=wetland (and 
actually have the name only there, but no renderer today understands 
that, it needs to be on the separate parts as well). What should the 
roles be? The most logical way would be to leave role field empty.




Maybe a similar approach as the one for relations of type=group (i.e.
a relation type which explicitly “inherits” its meaning from the
members without the requirement but with the possibility for
additional tags, a place to put a name for the ensemble) could be
taken for area relations as well, e.g. the site relation could include
the different wetlands, and a name (and e.g. wikipedia/wikidata
reference, etc.) might be sufficient to map the “collective” of
things? The nature would be implied by its members.

The bigger such geographic entities become, the less you will
typically be able to draw a hard line (fuzzyness of many natural
borders, rather smooth 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
Indeed, place=locality seems to be a dead end, it's been misused quite 
much and there's talks about removing it from OSM-Carto, and you can't 
render good maps from it, so it's technically a poor concept as well. To 
render names properly for natural features the renderer needs to know 
the extent of the area, so when you zoom out it can sort and show labels 
at appropriate size (and advanced renderers can even bend and shape the 
names according to the containing area), just like it has always worked 
with lakes.


Another way would be to make tags like we have for populated places, 
hamlet, villages, etc where the name tag type decides its prominence. 
This makes sense for populated areas as the area size is not what 
decides its prominence but rather the population size. However for 
natural features I think the area concept is elegant, and also gives 
much more information than just having a tag, as for natural features 
it's not always obvious (like a city) where the feature roughly starts 
and ends, or even what it is. For natural features it's also common in 
cartography to shape the text according to the shape of the feature 
(there are a few examples of renderers doing this already with OSM 
lakes, like opentopomap.org), and having an area gives the renderer 
great information to work with. So I think named areas is the way to go 
for natural features.


Named areas on land, like the peninsula tag that exists today, makes the 
map data a bit crowded in the editor when you show all elements at once. 
I think it would work well enough as you just can filter them out in 
JOSM when editing other stuff, but the concept of named areas has got 
heavy criticism from leading OSM people so it seems to be impossible to 
get consensus for this in the main database. Peninsula and also the 
valley tags are ineffective due to this. Refusal to support/promote the 
feature in OSM hasn't meant that the names have disappeared from the 
real world though, so the need is still very much there. There just 
seems to be no way forward with the main database.


So the only viable option indeed seems to put these things in a separate 
database. Although I think it would be preferable to have this type of 
basic feature represented in the main database, I'm for anything that 
works.


However, how many mappers is willing to contribute to an extra database 
if there's no showcase of it actually being used in a map as accessible 
as osm.org? Wouldn't this database just fade away, just like so many 
OSM-related projects before it? I think that today map renderers has to 
lead the way showcasing great cartography, then mappers will follow. The 
other way around no longer works, the scope is just too big. As a 
mapper, I don't want to invent methods for basic mapping, I just want to 
go to a website and read how it should be done, do my mapping, and then 
see the result on a map freely accessible to anyone all over the world. 
To me that's the attraction of OSM and being a contributor. With a 
global scope of the map it's incredibly hard as in an individual mapper 
to start a geodata trend that grows and gets so big that some relevant 
render implementor actually starts using the data and show it on their 
maps.


Would it be possible to get a global map renderer tied to the project so 
the database is actually used? I think it will be next to impossible to 
grow the database with voluntary contributions if there is no map 
showing it in active use.


/Anders

On 2020-12-12 14:03, Martin Koppenhoefer wrote:

of course all of these could be tagged as place=locality nodes, but 
this is a compromise to drop a name, which does not allow to even guess 
about the extent,  shape or orientation.


My idea is to collectively curate a parallel dataset which can be used 
in addition. Just draw the thing roughly (thinking mainly about 
regional size features, not the very detailed OpenStreetMap editing map 
scale), e.g. here

geojson.io
and send it to me for inclusion ;-)

https://github.com/dieterdreist/OpenGeographyRegions

ideally you would also search the fitting wikidata object (the hope is 
to internationalize names through wikidata items).


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] Mapping bicycle-only turn lanes

2020-12-12 Thread Jan Michel

On 12.12.20 14:25, Paul Johnson wrote:
On Sat, Dec 12, 2020 at 5:25 AM Jan Michel 
> wrote:


Hi,
where do you see a problem here? The current situation might not be
perfect, but it is usable as it is. The only thing to keep in mind is
that the number of "lanes" does not need to match the number of entries
in the "XY:lanes" tags.


That disagrees with literally every lane editing and validation tool in 
existence at this time.


Please check for example this way:

https://www.openstreetmap.org/way/406235586

It perfectly validates in all tools I tried - JOSM, OSMI, Keepright...
Rendering in the lane attribute style in JOSM is fine as well.

Even the examples in the Wiki show exactly this:
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles

It was mentioned in the original proposal for the :lanes suffix 8 years ago.

So, it *agrees* "with literally every lane editing and validation tool 
in existence" as well as documentation.



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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Casper van Battum
Does the actual wetland have a name, or does the area which the wetland 
is part of have a name? If the latter is the case, I might just consider 
using a node with place=locality+name=(name) to tag it. It's typically 
used to tag "an unpopulated location for which there is no extant 
feature to which the tag could be associated" (source: wiki) but the 
danger is that you might start tagging for the renderer. I wouldn't use 
it if the /actual/ wetland is named, so if that's the case just ignore this.


Best, Casper

https://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality 



On 2020-12-11 17:07, Anders Torger wrote:

Hello,

I was on this list a while back expressing some frustration over 
limitations when tagging nature and thought about getting involved in 
a process for change, but I came to realize that it's not feasible for 
me in my current life situation, so I've decided to continue be a 
normal mapper as before, doing what I can do with features that exist 
today.


Anyway, if to be a mapper at all, I still like to solve some of my 
naming issues in the best/least bad ways possible today. I'm currently 
mapping a national park in Sweden, Muddus. It's in Laponia and 
consists of mighty wetlands and old forest. These wetlands are named, 
like is common in Sweden and Sami lands. For us navigating in 
wildlife, names in nature are important.


A wetland polygon can be named in OSM, so the situation is better than 
for example for named slopes (also common). However, a wetland here 
can consist of both bog and marsh (and it's important to make the 
difference, since one is easy to walk on, the other not so much). 
That's two different natural types and thus can't be in the same 
multipolygon (as outers).


Asking on OSM Help website for a solution I got the answer to make a 
new containing multipolygon and set the name on that. That would be 
quite elegant for sure, but JOSM warns about that, can't have a name 
without a type, and if I set the type, say natural=wetland without any 
subtype, I get a JOSM warning that I have natural features on top of 
eachother. If I still upload it OSM-Carto does render out the name but 
you can see that the wetland pattern of the outer polygon is drawn on 
top of the contained polygons, so it does not seem to be the way to do 
it.


The least bad way I've come up with is to just name all polygons 
belonging to the same wetlands the same, and hope for that in the 
future smart renderers will understand that polygons with shared 
borders and shared name is the same named entity.


Any ideas or suggestions?

/Anders

___
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] Mapping bicycle-only turn lanes

2020-12-12 Thread Paul Johnson
On Sat, Dec 12, 2020 at 5:25 AM Jan Michel  wrote:

> Hi,
> where do you see a problem here? The current situation might not be
> perfect, but it is usable as it is. The only thing to keep in mind is
> that the number of "lanes" does not need to match the number of entries
> in the "XY:lanes" tags.
>

That disagrees with literally every lane editing and validation tool in
existence at this time.


> On the other hand, the "lanes" tag has some real problems, e.g.
> lanes = 2
> lanes:psv = 1
> lanes:hov = 1
> Is there any lane for regular traffic or not?
>

That shouldn't be relevant to whether or not a lane counts as a lane


> In my opinion the "lanes" tag is just a rough estimate for the width and
> capacity of a road -


You're actually describing the width=* tag, not the lanes=* tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
To make it clearer, here's a screenshot of the result of a test using 
this method:


https://www.torger.se/anders/downloads/Screenshot_2020-12-12.png

OSM-Carto makes one name tag per sub-part instead of just one for the 
whole which is both undesired and ugly, but I've come to understand that 
OSM-Carto is not really for making good cartography but for a debugging 
view where low computational overhead is prioritized over good 
cartography. I think that design choice is unfortunate, but not 
something I can do anything about, it is what it is. We hope that 
"someone else" does the cartography bit. It does become a bit confusing 
though when the naming method looks incorrect on the de-facto reference 
map that OSM-Carto has become, especially when this naming method is not 
documented anywhere. So it seems unlikely that "someone else" will 
actually make the rendering correct if there is no documented way of how 
the data is organized in these naming situations.


The OSM way seems to be to let individual mappers make their own tagging 
to solve the problems they have. This ends up with a fragmented 
situation of diverse methods where none is big enough to catch on, and 
most mappers just choose the easy way out and just simplify the map so 
the simplest already established methods can be used. The easy way out 
for me here would be just to ignore that the wetlands are both bog and 
marsh and just make everything bog: problem solved by lowering geodata 
quality. And I think this is what many mappers do, it's very 
unsatisfying to map things that doesn't show up properly on any renderer 
one can find in use.


But this time I'll try to be a good OSM citizen and take the lead in 
tagging if necessary. I just need to know that the method I choose is 
the best so it at least have some chance of survival so that my work 
doesn't go to waste. There are more challenges coming up so more 
questions will probably land on this list.


/Anders

On 2020-12-12 12:23, Anders Torger wrote:
Sorry, I realize I have a followup question. Is this really the right 
way?


There's a difference from the Rhine example. With rivers all the
separate parts are tied together with a parent relation of the type
waterway, and the parts have roles like "main_stream".

In the wetland case as described, there is no parent relation at all.
The only thing that ties them together is implicitly by sharing
borders and having the same name tag. It seems to me that an
"official" way to edit should tie them together with a parent
relation.

The logical way would be a parent relation with type=wetland (and
actually have the name only there, but no renderer today understands
that, it needs to be on the separate parts as well). What should the
roles be? The most logical way would be to leave role field empty. To
summarize:

Suggested method of how to name a wetland that has more than one 
sub-type:


* Prerequisite: each sub-type (marsh, bog etc) is a polygon (or
multipolygon if required,
  for example if there's an inner water or forest) which shares
segments with the
  neighboring sub-type, ie the wetland is a single entity.
* Put the name on each part, same for all
* Create a relation with type=wetland (no sub-type) and include all
parts with role
  field empty, also name this relation with the same name (although no 
current

  renderer will care)

What do you think about this way? JOSM thinks it's fine at least, I
get no warnings :-).

(Note that there's another case that can be solved with just a single
multipolygon, when there's a single sub-type but the parts are
separated, so each part can be an outer, this is also (quite) common,
although more common for waters and islands than wetlands. The special
thing with the discussed case is that it's a single entity all parts
bordering to the next)

On 2020-12-11 20:55, Anders Torger wrote:

Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each
separate part so not exactly beautiful, but the data is there.

/Anders

On 2020-12-11 18:07, Christoph Hormann wrote:
Anders Torger  hat am 11.12.2020 17:07 
geschrieben:


The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same,


That is widely considered to be the correct way.  It is established
practice that mapping things like forest, wetland, farmland etc. can
be split to differentiate tagging (like leaf_type, wetland type, crop
etc.).  The name tag is then applied to all components.  Same as for
waterways or roads where you can also split and apply the name to the
components.

This also matches the general concept in OSM that names are typically
local properties and only locally verifiable.  The Rhine river is
called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.


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



Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Martin Koppenhoefer
of course all of these could be tagged as place=locality nodes, but this is a 
compromise to drop a name, which does not allow to even guess about the extent, 
 shape or orientation.

My idea is to collectively curate a parallel dataset which can be used in 
addition. Just draw the thing roughly (thinking mainly about regional size 
features, not the very detailed OpenStreetMap editing map scale), e.g. here 
geojson.io
and send it to me for inclusion ;-)

https://github.com/dieterdreist/OpenGeographyRegions

ideally you would also search the fitting wikidata object (the hope is to 
internationalize names through wikidata items).

Cheers Martin 


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Martin Koppenhoefer


sent from a phone

> On 12. Dec 2020, at 12:26, Anders Torger  wrote:
> 
> In the wetland case as described, there is no parent relation at all. The 
> only thing that ties them together is implicitly by sharing borders and 
> having the same name tag. It seems to me that an "official" way to edit 
> should tie them together with a parent relation.


Yes, we do not have a way to map toponyms for larger areas when we also want to 
map detailed landcover within. Christoph’s idea of using the same names on the 
parts fails when the individual parts have different names. We can’t map bigger 
geographic entities like deserts, swamplands, forests, highlands (besides the 
names for the smallest parts, or if they correspond to other entities with 
clear boundaries like nature reserves, or maybe by overlapping the same kind of 
objects, what is generally frowned upon)


> 
> The logical way would be a parent relation with type=wetland (and actually 
> have the name only there, but no renderer today understands that, it needs to 
> be on the separate parts as well). What should the roles be? The most logical 
> way would be to leave role field empty.



Maybe a similar approach as the one for relations of type=group (i.e. a 
relation type which explicitly “inherits” its meaning from the members without 
the requirement but with the possibility for additional tags, a place to put a 
name for the ensemble) could be taken for area relations as well, e.g. the site 
relation could include the different wetlands, and a name (and e.g. 
wikipedia/wikidata reference, etc.) might be sufficient to map the “collective” 
of things? The nature would be implied by its members.

The bigger such geographic entities become, the less you will typically be able 
to draw a hard line (fuzzyness of many natural borders, rather smooth 
transitions). If we want to map all those “meta areas” with names we would do 
well to think about additional ways of delimiting space (i.e. different kind of 
geometry objects), e.g. a fuzzy border could be represented by providing 
different points for which it seems undisputed that they are in or out of the 
area in question. This would be very lightweight for all mappers, because it 
avoids clear lines which are confusing when they do not correspond with 
something observable. It may be difficult to find these things though 
(obviously would require editor/tool support).


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
So your advice is to actually skip the parent relation object, and thus 
leave the parts separate and related implicitly just by shared borders 
and having the same name? Ok, fine by me.


I certainly agree with you that data users probably won't turn complex 
patterns into something meaningful, as there is no real standard 
documentation of how to map things, just a wiki of soft and incomplete 
"advice", and lots of dead-end methods that never catched on. I rather 
avoid wasting time on using/inventing yet another of those dead-end 
methods. I think a better way would be a well-documented OSM-standard 
where the standards organization on itself figure out needs and take the 
lead rather than anonymous individual mappers like myself must invent 
own methods for needs that are really quite basic. But that just won't 
happen, so I know that I'm probably just wasting my time mapping at this 
detail level. But the OSM way is to let mappers take the lead and 
renderers (maybe) come after, I think it's a very BAD way now when OSM 
is as large as it is, but it's the way it is, so I'm in a take it or 
leave it situation. I enjoy mapping and OSM is the only free alternative 
there is.


On 2020-12-12 12:43, Christoph Hormann wrote:

My strong advise is not to make this more complicated than it is and
especially not cargo cult some complex data model in the hope that
data users will turn this into something meaningful - they won't.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Christoph Hormann


> Anders Torger  hat am 12.12.2020 12:23 geschrieben:
> 
> Sorry, I realize I have a followup question. Is this really the right 
> way?
> 
> There's a difference from the Rhine example. With rivers all the 
> separate parts are tied together with a parent relation of the type 
> waterway, and the parts have roles like "main_stream".

No, waterway relations are like route relations for roads, they are purely 
optional and have nothing to do with the local naming of physical features.

My strong advise is not to make this more complicated than it is and especially 
not cargo cult some complex data model in the hope that data users will turn 
this into something meaningful - they won't.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Jan Michel

Hi,
where do you see a problem here? The current situation might not be 
perfect, but it is usable as it is. The only thing to keep in mind is 
that the number of "lanes" does not need to match the number of entries 
in the "XY:lanes" tags.


On the other hand, the "lanes" tag has some real problems, e.g.
lanes = 2
lanes:psv = 1
lanes:hov = 1
Is there any lane for regular traffic or not?

In my opinion the "lanes" tag is just a rough estimate for the width and 
capacity of a road - all actual numbers have to be read from more 
detailed tags such as cycleway, busway and all XY:lanes.


Jan


On 09.12.20 00:19, Paul Johnson wrote:
I've been saying for a while now that it's time we fix the tagging 
problems with bicycle and motorcycle lanes by /actually including them 
as lanes/, because it cleanly handles exactly this kind of situation 
concisely and cleanly.  They're still lanes, just a reserved kind of 
lane like a carpool lane or HOV lane.  JOSM already handles this with 
its lane tagging features beautifully.  Any data consumers that can deal 
with lane access (which, if they're not, this is /already/ a bug, 
because HOV and bus lanes are things, too) will be able to handle it 
without problems.


Or we can just keep trying to pretend bicycle lanes aren't actually 
lanes and try to figure out how to fix something while simultaneously 
keeping it permanently broken because the original lanes proposal only 
considered private motorists.



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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
Sorry, I realize I have a followup question. Is this really the right 
way?


There's a difference from the Rhine example. With rivers all the 
separate parts are tied together with a parent relation of the type 
waterway, and the parts have roles like "main_stream".


In the wetland case as described, there is no parent relation at all. 
The only thing that ties them together is implicitly by sharing borders 
and having the same name tag. It seems to me that an "official" way to 
edit should tie them together with a parent relation.


The logical way would be a parent relation with type=wetland (and 
actually have the name only there, but no renderer today understands 
that, it needs to be on the separate parts as well). What should the 
roles be? The most logical way would be to leave role field empty. To 
summarize:


Suggested method of how to name a wetland that has more than one 
sub-type:


* Prerequisite: each sub-type (marsh, bog etc) is a polygon (or 
multipolygon if required,
  for example if there's an inner water or forest) which shares segments 
with the

  neighboring sub-type, ie the wetland is a single entity.
* Put the name on each part, same for all
* Create a relation with type=wetland (no sub-type) and include all 
parts with role
  field empty, also name this relation with the same name (although no 
current

  renderer will care)

What do you think about this way? JOSM thinks it's fine at least, I get 
no warnings :-).


(Note that there's another case that can be solved with just a single 
multipolygon, when there's a single sub-type but the parts are 
separated, so each part can be an outer, this is also (quite) common, 
although more common for waters and islands than wetlands. The special 
thing with the discussed case is that it's a single entity all parts 
bordering to the next)


On 2020-12-11 20:55, Anders Torger wrote:

Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each
separate part so not exactly beautiful, but the data is there.

/Anders

On 2020-12-11 18:07, Christoph Hormann wrote:

Anders Torger  hat am 11.12.2020 17:07 geschrieben:

The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same,


That is widely considered to be the correct way.  It is established
practice that mapping things like forest, wetland, farmland etc. can
be split to differentiate tagging (like leaf_type, wetland type, crop
etc.).  The name tag is then applied to all components.  Same as for
waterways or roads where you can also split and apply the name to the
components.

This also matches the general concept in OSM that names are typically
local properties and only locally verifiable.  The Rhine river is
called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.


___
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] Mapping bicycle-only turn lanes

2020-12-12 Thread Jan Michel via Tagging

On 08.12.20 23:08, Mateusz Konieczny via Tagging wrote:

highway, name, lit=yes, surface=asphalt etc
oneway=yes
oneway:biycle=no
lanes=1 (as bicycle lanes are not counted)
vehicle:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes
turn:bicycle:lanes:forward=left|
turn:lanes:forward=|
vehicle:lanes:backward=no
bicycle:lanes:backward=designated
cycleway:left=lane
cycleway:right= - there is left turn lane only, so 
cycleway:right=lane would be
not entirely correct but there is a left turn lane, cycleway:right would 
be worse


In my opinion this is correct. There is no cycleway:right here. The 
:lanes tags describe the situation perfectly well.


You can add
cycleway:left:oneway = no
That adds "there is a cycleway on the left, and it can be used in both 
directions".


Jan


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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-12 Thread Minh Nguyen

Vào lúc 14:08 2020-12-08, Mateusz Konieczny via Tagging đã viết:

Mapper in Poland run into a tricky case and asked for help.

I am forwarding this a bit weird case.

Photo is at
https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_Brodzi%C5%84skiego_(5).jpg 


and depicts

- contraflow bicycle lane
- bicycle-only left turn lane (signed left turn)
- general purpose lane (unsigned turn)

How this should be tagged?

Following is my idea but...

highway, name, lit=yes, surface=asphalt etc
oneway=yes
oneway:biycle=no
lanes=1 (as bicycle lanes are not counted)
vehicle:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes
turn:bicycle:lanes:forward=left|
turn:lanes:forward=|
vehicle:lanes:backward=no
bicycle:lanes:backward=designated





cycleway:left=lane
cycleway:right= - there is left turn lane only, so 
cycleway:right=lane would be
not entirely correct but there is a left turn lane, cycleway:right would 
be worse


I've always understood the cycleway:left/right=lane to refer to the 
presence of a bike lane on one side of the physical roadway or the 
other, regardless of the direction that lane travels. After all, the 
keys aren't cycleway:forward/backward. For example, in a country that 
drives on the right, a contraflow bike lane on the right side of the 
roadway would be tagged cycleway:right=opposite_lane, not 
cycleway:left=lane.


A *:lanes key might be one way to clarify the layout of that part of the 
road: cycleway:left=lane cycleway:left:lanes=2. But note that the turn 
lane tagging you suggested above is distinct from the considerations 
around cycleway:*; your suggested tagging for turn lanes seems 
reasonable to me.


[1] https://taginfo.openstreetmap.org/keys/cycleway%3Aright%3Alanes

--
m...@nguyen.cincinnati.oh.us


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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Martin Koppenhoefer


sent from a phone

> On 12. Dec 2020, at 06:59, Joseph Eisenberg  
> wrote:
> 




> All names are opaque to computers, so we use standardized tags which can be 
> translated one time, instead of needing to translate an operator=* tag for 
> every language and every country to make it usable. 


yes, but if the Chinese Navy does not fit what you expect from a navy it is 
more misleading than helpful. Which military service are the Italian 
Carabinieri? The US Marines? 

What about the Guardia di Finanza?

I agree we will probably find use for both, a specific operator tag and a more 
generic attempt to put the things into boxes.

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