Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-24 Thread stevea
t; we've made, as OSM is supposed to be a geodatabase, not a geoservice 
> provider. I don't think that is how the typical mapper see it though.

OSM cares about renderings:  we offer four on our map page as a start of our 
data's capabilities.  OSM certainly improves, though pipelines / feedback loops 
for renderer improvement are complex and sometimes lengthy.  Evidently you 
don't understand this.  I don't fully understand it either, even over many 
years of email conversations with renderer authors — and I believe the vast 
majority of OSM Contributors don't understand it.  But the point of OSM is the 
data, not renderings.  Repeating myself, the easiest way for OSM to salve the 
sort of boo-boo you seem to have is to say "don't tag for the renderer" (and 
OSM doesn't often say why, or what complexities are behind that).  But as you 
repeatedly pick at this scab (as a long-time Contributor, I say OUCH!) we 
evidently have to bleed all over — again and again — with exhortations like 
these between us in a public forum.  I sincerely wish this weren't so ugly, 
Anders.  What part of "please stop complaining that renderings aren't to your 
liking" do you not understand?

OSM has a problem (I'd say moderate-sized) in that sometimes people tag to 
achieve particular renderings.  We shouldn't, as this results in poor, usually 
incorrect data entering the map.  To remedy this, we say "don't tag for the 
renderer."  You say "there's a bunch of differing opinions on how we should map 
and no uniform decision can be made...".  Anders, I assure you, despite your 
attempts to gaslight us into believing otherwise or redefining the project, it 
is an ironclad, uniform decision of OSM that we shouldn't tag for the renderer. 
 It won't work to continue complaining.

Do I make myself clear enough?  I have little energy and no desire to continue 
to defend against this list being baited or further misunderstandings of 
persistent, dead-end, ineffective approaches.  Anders, if you want to do 
something constructive on this list, I wish you would (following its 
established tenets, which I summarize above), but what you have been doing and 
how you do it (over and over again) isn't it.  Your point that "typical 
mappers" see things a certain way contradicts that OSM's data entry continues 
to grow, without them complaining that renderings aren't to their liking.

I'm reluctant to say it:  be constructive (ask relevant, judgement-free 
questions, offer relevant perspective...), or be gone.

I'd like to see this list extract some value from this discussion (I'm going to 
go take a refreshing shower).  I hope we can gain some value from the topics 
discussed.  In my opinion, we should not dwell on the mechanics of what has 
happened here, but rather its potential fertility, rather than its actual 

Tagging mailing list

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread stevea
We have a spot on the ocean shore, right at (below, at sea level) the entrance 
to a state park, in an urban area:  it's known locally as "the toilet bowl" and 
it's node/3370641047.

It's tagged hazard=yes (best I could do at the time, I suppose; I tagged it in 
2015) and "dangerous area, no swimming."

We can do better (now or soon).

> On Dec 23, 2020, at 9:40 PM, Graeme Fitzpatrick  wrote:
> On Thu, 24 Dec 2020 at 15:14, Brian M. Sperlongano  
> wrote:
> "I'd like to swim in a small pool with a waterfall".
> Good spot for one of your hazard tags!
> We have Natural Bridge nearby 
>  which is a hole cut in the roof of a cave by millions of year of rushing 
> water, making a waterfall.
> Unfortunately, over the years, despite warnings not to swim in there, quite a 
> few people have drowned, as the force of the falling water pulls them under & 
> back, they can't see & so run out of air :-(

Tagging mailing list

Re: [Tagging] Cartpath RFC

2020-12-23 Thread stevea via Tagging
Thank you immensely for doing your (our) homework, Minh!

Tagging mailing list

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread stevea
On North America's west coast and in "the West" (ern states of the USA), I've 
heard "hole" used for both fishing spots and swimming spots in creeks, streams 
and rivers (and "pools," what I often see called a "thickening" of the river, 
such as a calmer not-quite-eddy off to one side that might go a bit deeper than 
usual, sometimes with river-cliff diving!).

I've also seen "official" naming conventions on waterways like "Branciforte 
Creek Reach 2" where an urban river/creek becomes a concrete canal (named 
"Reach 1"), becoming channelized to flow into a more major waterway.  Los 
Angeles has a lot of these (concrete, channelized rivers) in its vast 
conurbation, very useful for flood control.

Yes, if I want to angle in a creek or river, I'll do it on public land, where 
there are plenty of opportunities (sometimes requiring a permit from state Fish 
& Game department, sometimes not).  Somebody wants to charge me money for a 
permit to fish on private land, I'll pass, thanks.  I realize that in some 
parts of the world, though, "that's how angling happens."

Two whole cents,
Tagging mailing list

Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-23 Thread stevea
On Dec 23, 2020, at 9:23 AM, Martin Søndergaard  
> While some might not agree with the tone of Anders, I do think his 
> "enthusiasm" has resulted in the most interesting discussion I have seen on 
> this list yet. And I want to give a few of my thoughts as well.


> On Tue, 22 Dec 2020 at 09:43, stevea  wrote:
> “Names in nature” is an interesting, complex, challenging, yes, even 
> strategic topic.  I think we can get closer to “better,” here on this list, 
> with good, respectful, effective dialog.  I look forward to that.
> In my opinion this problem is in no way limited to "names in nature". 
> Practically all place=* features (except the "Administratively declared 
> places" category), such as City, Town, Village, Hamlet, etc. are "fuzzy" 
> features, but no one seems to talk about them as such.

Excellent:  I am glad somebody took my relatively limited (we have to start 
dialog somewhere...) point and expanded upon what needs expansion.  I did not 
mean to "limit" what we discuss when I said what I said, as these are expansive 
topics and frequently not easy to discuss.

Thank you, Martin, for expounding upon many tangents of this thread and 
bringing them together in a way that lets us understand that "naming" and 
"fuzzy" and "nature" are not as precise as we might wish them to be.  We've got 
a real, live thread here, vibrant with great dialog!

Tagging mailing list

Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21 Thread stevea
On Dec 21, 2020, at 10:53 AM, Anders Torger  wrote:
> Cluttering could be a problem, but is an easy thing to solve with filters. As 
> I edit i national parks now I have this huge national park polygon covering 
> all work, which renders as a flat although half-transparent color in JOSM. 
> It's easy to remove with a filter though, but actually I'm not disturbed by 
> it enough to care to do it. If we actually define this as a feature we could 
> have a filter setup for these in our tools.

Anders, think about what you are saying:  defining fuzzy areas (work to do, 
work to achieve consensus...) virtually requires a tool filter for reducing or 
eliminating them from how many — even most — mappers view them?  That smacks 
(hard) of "OSM:  do something quite different from what you do (for me and my 
purposes) and then filter out the results (as noise) from your views of the 
data."  Do you see how this entire approach can be seen as offensive by OSM?  I 
don't want to stifle real questions about whether we want fuzzy areas, as it's 
a valid discussion.  But positing it like this is 100% a non-starter.

> The question becomes more complex as there are several types of these areas. 
> Regions in cities like this I haven't thought about before, I didn't know 
> that it existed. It has quite different impact than a plateau in the 
> mountains.

Yes, it does become more complex.  You haven't thought about these?  Thinking 
about these (and others like them, yet also unlike them) is required.  There 
are no shortcuts to that.

> I think it would be unfortunate if a few bad examples of fuzzy area use or 
> (simple) limitations in our tools block all use or further development of 
> them, as they are important for certain type of maps in certain areas.

Repeating myself:  "there is good design, there is bad design."  Which do you 
think OSM prefers?

> I guess cities can do well without region mapping or just use points which 
> there is a quite rich definition for already (neighboorhood etc),

Yes, the specifics of how to map "smaller conurbations" (within larger 
conurbations) is documented in our place=* wiki.  There is no need to guess at 
how to use nodes (or closed ways) to do this.  (Not "points").

> but making an outdoor/rural map without naming nature and without proper 
> support for zooming out (ie having some approximate size of the named 
> features), greatly cripples the capabilities of maps rendered for those areas.

There you go again:  you seem to persist with this basic understanding that 
OSM's rendered map data are "what OSM is."  No.  OSM is data.  Accurate, 
ground-verifiable (there are some specific exceptions, like boundaries), 
peer-reviewable, properly tagged (because consensus establishes the tagging 
scheme) data.  Stop tagging for the renderer!  (And / or build your own).

> Do you think there is a valid use for fuzzy areas in outdoor/rural areas, or 
> would you rather see them not being used there either?

I see potential value in the concept (a good place to start, as I have said).  
I don't see anything nearly enough for me to conclude (let alone even begin to 
consider, yet) that "fuzzy areas" should be "in" OSM.  In some separate, 
OSM-friendly (possibly to be mingled with OSM data) repository which can be 
cleverly blended?  Maybe.  I would need much more proposal-oriented specific 
propositions with which to evaluate that before I could proceed.  Should you 
wish to continue in this direction, please develop one (or several) such 
proposals (starting with familiarity with our culture, process and tools, then 
progressing through questions and dialog) and this community will consider it / 
them.  Jump up and down that "we are crippled because we don't do what you 
think we should do" (and don't currently, because it isn't what we do, it is 
what you THINK we SHOULD do), no.  This community should not consider repeated 
complaints that we do not do what one Contributor thinks we should do as valid 
methodology to quite radically alter our data model.  Such an approach is 
doomed to failure, and should be.  Constructive propositions to different ways 
of doing things?  Proposed as the community has evolved to discuss, develop and 
accept them?  Sure, we do that here.  Absorbing repeated complaints that we 
shouldn't continue with a working process and listen to one, persistent 
complainer?  Nope.  That's not how this project works.

Anders, honestly, I'm trying to help you.

Tagging mailing list

Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread stevea
Nice, Anders.  You can use taginfo to get "the raw numbers" (quantity) of a 
particular kind of tagging.  What might work specifically for you in this case 
is to use some well-crafted Overpass Turbo queries (over a specific area at 
first, you can use the "bbox" method of "what you see on-screen" or you can use 
the "geocodeArea" directive to restrict the query to a named place).  OT 
querying takes some practice to become skilled in its vast power to query OSM 
data, but it is worth investing in the learning curve to do this, as it is 
likely (imo) the most powerful tool we have to ask our data "what about this, 
like this?"

Usually, our wiki describe "tagging as is," what is known as "descriptive."  On 
occasion, some wiki will be "prescriptive," meaning "here is how one SHOULD 
tag, though I make a point to say that any wiki which does that should say so 

Good luck in your endeavors!


On Dec 21, 2020, at 9:56 AM, Anders Torger  wrote:
> I just discovered a strange(?) thing with the "natural=fell" tag which I 
> missed at first: on the wiki page there's two purposes defined of this single 
> tag, the first is landcover of bare mountain as discussed, and the other 
> purpose is, quote from the wiki:
> "In the north of England, and probably in other areas of Norse influence such 
> as Iceland, Norway and Sweden, there is a practice of naming the sides of 
> hills, fells, rather than peaks. A single hill can have different names on 
> different sides. This tag can be used to record such names."
> It's true that we do have such a practice although more so at lower 
> altitudes. I recently added such a name on an alpine mountain as a fell 
> cutout with a fixme tag (there is no other tag for slopes I think, didn't 
> realize that "fell" is it). However as said we have "fell" in that sense in 
> forested areas as well, even more common there.
> I guess if "fell without name tag" is defined as landcover, and "fell with 
> name tag" is defined as fuzzy area naming a side of a hill it could work, but 
> it's the first time I see this type of dual definition. Is it normal, or is 
> the wiki page just documenting how this tag have ended up being used?
> /Anders

Tagging mailing list

Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread stevea
On Dec 21, 2020, at 7:10 AM, Tomas Straupis  wrote:
> 2020-12-21, pr, 16:52 Anders Torger rašė:
>> But what to do if the things you want doesn't
>> really fit into what OSM currently is and strives to be...
>  We are ALL OSM community. If somebody tells you that "I am OSM and
> only A is right" - do not believe them.
>  YOU define what OSM is and where it is going to by DOING.
>  The more I look at it, the more it seems that fragmentation is
> inevitable. Question is how much will remain "common".

Thank you for saying it like this, Tomas.  Fragmentation happens, though it is 
not the end of OSM when it does.  Private projects, when they happen, don't 
necessarily harm OSM, they prove its strength as a solid foundation of data 
upon which are built bespoke / custom solutions.  These even can (and do?) 
"link up" to form a stronger fabric which "rides along with" the solid 
foundation.  There are examples of this in OSM right now.  Truly, a lot of what 
was said in the last few posts are bullseyes on a target:

• YOU define what OSM is by DOING (a crucially important truth!)

• While "local renderers" are by definition limited in their scope, they need 
not be limited in their use:  they can be practical/visual proofs of "better 
ways" (to do things), testing grounds for finding solutions to more 
international problems

• There are already local communities creating local cartographic data schemas, 
this is already being talked about as becoming more-widely and better 
integrated among data consumers (like yourself, Anders — that's how this works)

• Making OSM into what we might use in the future as a "baseline" map for a 
drop-in replacement for government maps (in Sweden, for example) will doubtless 
earn us growing contributions that surpass the government maps.  Yes, that's a 
fair bit of sweat, work and time, but it is worth it!  (That's a fantastic 
dream, well-stated and shared by many, Anders!)

• Agreeing on the goals FIRST (among peers who can, do and will work towards 
them) takes energy, but it is worth it!

• It is easy to get hooked on this kind of mapping / data / collaboration!  It 
works, it is a lot of fun.  Repeat ad infinitum.
Tagging mailing list

Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread stevea
 “issues” in the course of the dialog with someone who 
engages you here if and as they actually provide a blockade to forward 
movement.  Doing so beforehand is putting roadblocks in your own way, sometimes 
needlessly.  Haven’t you ever been surprised at discovering that what you think 
is wrong or broken about something isn’t even true in the first place, due to 
wrong assumptions on your part?  I have.  We all have.  This is part of a 
learning process that refines our thinking to avoid assumptions.  Of course, we 
must assume some things to posit something new.  Mostly, these are things which 
have already revealed themselves to us as “already true,” so “safe to assume” 
about.  More than a few of your assumptions are specious.  Please learn to 
assume less about “things OSM.”  It’s OK to assume about what you are certain 
you already know about mapping, or math, or computer or data science or 
mountaineering in Sweden.

> If OSM intends to be for all globally, there is a need to consider local 
> needs and respect local knowledge, not only consider a feature relevant if it 
> is has global spread. Maybe these natural=fell issues are specific to 
> Scandinavia (although I think Great Britian has similar), but they are real 
> here.

Good, now we’re talking.  I think natural=fell is widespread around the world.  
OSM must accommodate nuances about this if there is “more to it” than we now 
document or use in the map.  We have methods to do that, we have for many 
years.  For especially-local or even hyper-local map features, OSM does have 
plastic tagging that allows us to coin new tags for such things.  This happens. 
 Sometimes mappers who do this make a quick (and rough) job of it and this 
needs refining.  This happens, too.  Better is a thoughtful (and not as rough) 
job of it and it needs little or no refining.  This is called “design,” and 
there is poor design and good design.

> I try to make a case that it would be wise to render natural=fell, and 
> describe why. There's a closed issue report on OSM-Carto github about this 
> (yes I actually do some research before I post), and my arguments were shaped 
> by that thread, to proactively meet what came up there so we don't need to 
> have exactly the same discussion all over again.

Thank you.  I truly appreciate your diligence.  It can be helpful to link such 
things, as people do here with * and [1] tags that link such things.  This 
gives background and context to a thread that lets others pick up the pieces 
and jump in as fully informed as they might be (you’re helping them do so, so 
offer the help they need, please.  We are not mind readers).

> However, that I have a suggested solution doesn't mean that I'm open to other 
> suggestions, maybe an alpine tag for indicating nature above tree line for 
> example. I think it's however very difficult and not worthwhile to go very 
> specific for our fell habitat, which I also described in the original post.

There is an effective way to strike a balance in offering what might be an 
overwhelming amount of background (especially of “what you know to be true” and 
“how things ought to be”) and simply presenting a question about how you might 
go about doing something better in OSM.  If you find (here, via dialog) someone 
who can engage with you on your well-presented topics, well, "you’re off to the 
races” (productive dialog begins).  If not, you are having what is effectively 
a one-sided conversation.  Engage first.  Please.

> Heath below the tree line is quite easy to identify, as it's surrounded by 
> forest. Heath above the tree line is pretty chaotic, speckled with bare rock 
> and scree. Hence a generic tag "fell" would suit perfectly well, and is 
> already in existence, but it needs rendering in OSM-Carto to show mappers 
> that there is backing for this tag.

"If wishes were horses, beggars would ride.”  I have wishes that Carto renders 
this, or that, or in a particular way.  But wishing that renderings are this or 
that really isn’t what OSM is about.  Entering true-to-the-ground map data is.  
Rendering is a bonus you might or might not get to your heart’s desire.  If it 
is, that’s pretty neat when it happens, isn’t it?!  If not, complaining here is 
not the solution.

Thanks for answering and your attention.  I really do appreciate good dialog.

Tagging mailing list

Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread stevea
On Dec 20, 2020, at 11:39 PM, Anders Torger  wrote:
> I'm doing further mapping of Swedish national parks, now in the mountains, 
> and I have noted that natural=fell (habitat over tree line) is not rendered.
> Looking into why it seems that OSM-Carto implementors want more specific 
> landcover tags to be used. I don't think that (somewhat randomly) requiring 
> detailed landcover is a good design choice.

Can Anders write anything here without telling OSM that it is broken and we 
don't know what we are doing?

Anders, where did you study cartography or get an advanced degree in design?  
Ignoring the question speaks volumes.

> I think it would be better to have a defined hierarchy from more generic to 
> more specific tags so the map can evolve.

Thank you for your opinion.

> Taking the leap to high detail mapping directly makes covering the map very 
> slow and sometimes inaccurate.

Maybe.  Again, only maybe.  If you don't like OSM, you are welcome to not use 

> Fell in particular is in parts so heavily speckled with slightly different 
> covers it's hard to even see on the satellite photo what it is.

Complain, complain, complain.

> You can have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an 
> area. So I guess I make that heath then as it's dominant? That would however 
> be more misleading than actually setting a more generic tag like 
> natural=fell. Forcing detailed mapping where this is very difficult to do is 
> not a good idea.

Bleating, bleeeating to this list with little to no constructive 
bent to your complaints is not a good idea.

> When we get to even higher altitude the growth disappear and we have just 
> bare rock and scree so it becomes easier. It can at times be quite hard to 
> differ between bare rock or scree though (the resolution of the satellite 
> photos in the mountains is often not that great).

I'm beyond thinking that this barrage of "my preferences are the best" is not 
that great:  I'm already there!

> We already have more-generic-to-more-specific landcovers in other areas, you 
> can provide wood without specifying tree type for example, or wetland without 
> specifying type of wetland. (Parenthesis: going from more generic to more 
> specific by adding additional specifying tags is an elegant design, I think 
> it's a bit unfortunate that that design is mixed with a flat tag structure as 
> well, but that's the way it is...).

More than a bit unfortunate are posts by constant complainers.

> It seems like a very odd design choice to require more detailed mapping in 
> alpine areas where this is rather difficult. If we look into how official 
> maps do it in Sweden and Norway they don't have specific landcovers above the 
> tree line, they have just "fell", and in addition significant wetlands, plus 
> waters and streams of course.

It seems like a very odd choice to write to a list with little more than "you 
folks are wrong, why don't you simply do things the way that _I_ want them 
done?"  Even after we (I, others...) politely and patiently engage you, do you 
expect us to keep doing so when it appears you cannot write to this list with 
little more than a litany of complaints?

> Fell indicates where we have bare mountain (above treeline), which is the key 
> information outdoor goers need

Says you.  Others might agree, others disagree, not everybody thinks like you.  
OSM aims to be for all, not just you.

> plus waters and significant wetlands. Anyone that has been to these mountains 
> know that once above the tree line the land cover is quite predictable, it's 
> decided by altitude and steepness.

The reason humans make maps is because nature, the world around us, is always 
changing in some way and is absolutely NOT predictable.  Maps are an 
approximation of reality, not reality.  There is no such thing of value as 
"quite predictable."  The first time something happens that wasn't predicted, 
you'll learn the value of that.

> At the fell altitude contour lines is key information, not if it's a patch of 
> heath or bare rock, which rather just makes a map harder to read without 
> providing valuable information.

I'm pretty sure of one thing:  you are not hard to read.  I see your name in 
the From header and know that I'm about to read someone hostile to OSM who 
can't seem to make even constructive criticism.  It's all rock-throwing, here's 
what's wrong with you and why don't you do things my way?  (Without so much as 
a "please").

> So far I have tagged these areas with natural=fell. I'm thinking about adding 
> bare_rock at high altitude (and scree only when clear and significant), but 
> in the medium altitude where there is growth more detailed mapping becomes 
> very difficult. Heath would be the most natural generic tag for that area, 
> but then we loose the distinction that it's above the tree line, as there 
> already is some heath areas below the tree line. Maybe adding an extra tag 
> like 

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread stevea
I'm not sure how long it is, but California's Highway 1 along the Big Sur coast 
(a fairly well known, well loved road) has some equivalently lengthy (or 
longer) winding road signs I've seen.  If anyone cares to Mapillary-sniff, I 
recall one near Carmel Highlands (near the "pink hotel?") and another further 
south, near McWay Falls or is it more near JFBSP?  Esalen?  Definitely seen 
some around there).  Northbound you might have to look around Cambria, I don't 
often approach from that side (northbound).  Long, sinuous roads do happen and 
are sometimes even signed.  I think that despite how famous this drive is 
(about as well-driven as Yosemite National Park in summer), you don't want to 
be in a 12-meter motorhome on this road and not know what the next 200 
kilometers are going to be like (windy and very few places to pull over or park 
such a behemoth). Still, such "big traffic" (giant Recreational Vehicles) do 
make this trek.  Such a sign might make someone think twice and I think that's 
part of the reason Caltrans erects them.  And nobody likes getting stuck behind 
a slow, giant RV.

> On Dec 16, 2020, at 6:15 PM, Graeme Fitzpatrick  wrote:
> On Thu, 17 Dec 2020 at 11:24, Brian M. Sperlongano  
> wrote:

> Thanks for the comments!  For the specific linked case (winding road for 
> 74(!) miles), it seems that is already covered in the proposal - 
> hazard=curves and its sub-tags cover this, and if it truly is 74 consecutive 
> miles, that I would think it's just fine to tag 74 miles worth of ways in 
> this way.
> & we'll have to do the same for this! :-)

And the Nullarbor Plain (love that name) I think also famously has the longest 
straight stretch of railway on Earth.  I'd tend to say "railroad," US English 
being my mother tongue, "railroad" for "railway" being a US English dialect 
marker.  Like holding up three fingers in a certain way.  Or Ex-Wye-Zed vs. 
Ex-Wye-Zee.  It's a big world.  Lots of long, straight roads, lots of long, 
windy roads.

Tagging mailing list

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread stevea
I'm "one more OSM Contributor" volunteering my opinion here.  I voted for the 
hazard proposal as is, although my vote included the note that "this proposal 
is a solid foundation for the (hazard) syntax of both today and tomorrow."

There are such things:  OSM has many examples of where we begin something that 
is a well-thought-out sketch (or more, yet still recognizable as 
not-quite-complete) and then grows to a mature example of itself.  Perfection 
should not be the enemy of the good.  This is at least a good proposal, I'd 
even say "excellent," especially in its efforts to be comprehensive.  I say 
this neither to discourage the continuing good dialog here, nor the growth of 
"hazard" (syntax, wiki, usage in the map data...) into the future, but rather 
in harmony with those.  This puts me in agreement with Brian as he says 
"consider this proposal a starting point."  I'm saying "it's at least a good 
one, I'll even go 'excellent.'"

I believe the more voices we hear, the better.

Tagging mailing list

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

2020-12-15 Thread stevea
To share a local varietal, we have "Henry Cowell Redwoods State Park" and we 
have "Henry Cowell Redwoods State Park (Fall Creek Unit)," slightly 
non-contiguous but managed together.  In the real world (too) this sort of 
"grouping between things that belong together or are part of a same thing" can 
be tricky (in naming, categorizing...).

It appears California "decided to choose to at least do something about 
this..." (in this case) and threw a dart at the board, which stuck.  This is 
but one example of "grouping, naming, categorizing..." but it illustrates 
"throw a dart, locally, if nothing else has been done" and it might stick.  
We're doing that here.  Some darts haven't even yet been thought of.

A natural area grouping naming concept is an excellent starting place, even 
discovering that "there isn't one" (in OSM) doesn't mean one couldn't be spun 
up.  It could, sounds like it should.  It sounds like it's in the earlier 
stages of happening, here, now, offline with some (many?), in imaginations at 
least.  Good.

Lather, rinse, repeat.

(Like my oldest sister the artist says, "start with a concept.")

> On Dec 15, 2020, at 2:25 PM, Martin Koppenhoefer  
> wrote:
> Am Di., 15. Dez. 2020 um 08:51 Uhr schrieb Anders Torger :
> The simple answer is that this naming concept is fundamentally broken, and 
> that we need to have some other concept, such as fuzzy areas.
> I agree that there isn't really a concept for naming larger (natural) areas. 
> In OSM you can map areas of the same kind of thing and add the names for the 
> smallest entities (e.g. forest) to it, but you cannot add a name for several 
> parts of a forest together (when the parts themselves have names). Naming 
> works for administrative entities, countries, cities etc, but not for 
> geographic entities. 
> Cheers
> Martin
> ___
> Tagging mailing list

Tagging mailing list

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

2020-12-15 Thread stevea
That's a good question, Brian.  On its face, it would be more consistent to 
keep this in the place=* key.  I like both of your choices, as the concept 
doesn't really have a single word to describe "lakes" in the plural as distinct 
from the singular (as archipelago does for island).  The community can continue 
to discuss which might be better and why.

On Dec 15, 2020, at 9:09 AM, Brian M. Sperlongano  wrote:
> Wouldn't it be more consistent to keep it in the same key, and call it 
> place=lake_group?  Or even place=lakes?
> Would this be used for something like the Great Lakes in USA/Canada or is 
> that too large of a feature?

Tagging mailing list

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

2020-12-15 Thread stevea
+1.  Joseph's suggestion is a fine example of "OSM can and does coin new tags 
on occasion."  Adding a nice boost, there is a suggestion that "similar" 
tagging be used as an example of how to define / use / document the new tag.  

On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg  
> Re: “ a couple of islets with a collective name”
> We have a tag for that: place=archipelago for a group of islands. 
> There isn’t a common tag for a group of lakes with one name, probably because 
> this is only common in some countries, especially near the Arctic region. 
> We’ve talked about this issue before but did not find an existing tag.
> I would suggest a tag like natural=lake_group to be added to a multipolygon 
> which includes each of the lakes, similar to how archipelagos are mapped.

Tagging mailing list

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

2020-12-15 Thread stevea
That is stated even better than I meant to state.  Yes, JOSM's relation editor 
is "the best there is."

On Dec 15, 2020, at 1:21 AM, Peter Elderson  wrote:
> stevea :
> (Personally, I find JOSM’s relation editor to be one of its most elegant 
> features for a data structure as relatively complex as a relation. 
> I am not qualified to judge elegance, but I find JOSM's relation editor the 
> best there is. I don't think relations are very complex data structures, but 
> the construct is versatile. It's what people do with them that makes it 
> complex. But hey, the same goes for the node, the way and the area.

Tagging mailing list

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

2020-12-15 Thread stevea
A little less “my way is the right way” (complaining, plain and simple) and a 
little more “ah, OSM does what OSM does, I understand how I can both contribute 
AND make use of it,” please.  Lots of us do this (both) and actually improve 
the map while we’re at it!  (Map data, map documentation via wiki, map syntax 
via proposals, map renderers…).

Examples of “my way is the right way” in a recent post:

• (A renderer) doesn’t render wetland names at all (strange for a map with 
• You won’t find any renderer (except Ture’s) that does what I want
• “Well-established methods” don’t make sense
• A renderer needs to (have, see, make, do, calculate, merge)….
• However, it’s strange (in two different ways!) having an algorithm that needs 
• I don’t think anyone believes (something), that’s just a standard argument to 
neutralize criticism
• A data project that keeps saying “we’re a data project, you want rendering? 
Go write a renderer” isn’t exactly ideal for (me) making progress
• My opinion is that having limited and “soft advice” wiki of how geodata 
should be interpreted and rendered is a bad idea

At this point, I’m tempted to repeat “so, then, don’t use OSM, it doesn’t seem 
to be what you are looking for.”  However, the OP continues:

• “It” (you folks making this happen for me) could STILL work if an existing 
renderer simply decided to become my "wish slave” renderer rather than what I 
will disparage by calling “an example” or than “the one that you folks have 
chosen to call Standard” which I declare “does some things wrong.”  (Defects to 
spec are one thing, and good to track and fix as bugs or feature requests, then 
improvements.  THIS is something entirely different!)
• My wishes mean that you folks need to PROPERLY render “the concepts which is 
supposed to work.”  Oh, and if it DID work, as I wish it were to work, you 
folks might discover how inefficient your present algorithm is and how 
wrong-headed is your approach to “how data is arranged.”  Hey, the least you 
guys could do is allow a new concept (it’s fuzzy, sorry) to be introduced.  I 
mean, REALLY!  It’s so RISKY to “design data arrangement concepts without 
having an own renderer to test them with.”

At this point, I say (exhausted) “the data arrangement has been 
crowdsource-crafted by millions over decades” and “we DO have 'our own 
renderers' (to test them with).”  Wow!

Still, the OP continues:

• Hey, we have to (tag for the renderer, something we are clearly admonished 
not to do) to get specific tagging for the renderer!  I’m jumping up and down!
• Couldn’t you just make wetlands (for me, yes me, that’s me) the way that _I_ 
want them?  What’s wrong with you folks that you won’t or don’t?  I actually 
have to use YOUR data structures and read YOUR documentation to do this YOUR 
way!  Harumph!  Why can’t you simply read my mind and do it the way that I like?
• What I do is spend far more time spending time than what you do (or so — 
which only resounds as, effectively, selfish and/or whining)
• Imagine how much easier (for you) it would be if you "simply do” what _I_ 
want you to do
• Your tools are crude (for me to use).

(Personally, I find JOSM’s relation editor to be one of its most elegant 
features for a data structure as relatively complex as a relation.  But I 
digress).  Continuing the bleating:

• You need to do certain mapping operations by doing certain map operations, 
which I hereby complain about being too simplistic
• You could STILL “save yourselves” by doing things my way (after a hazy, 
unproven technique is sketched, while inventing “layers,” a concept that is 
nearly 100% unlikely to be ratified in OSM anytime soon)
• You must convert and generalize asap, because vector tiles will save us
• I have noticed that my fellow mappers in my country here DO pay attention to 
the admonishments to not map for the renderer, so I suppose “everybody” finds 
this a difficult to grasp concept.  (Nope).
• You sure ought to look into making things easier.  (For me).
• You sure ought to “think twice” about improvements that I don’t like, as it 
makes it more difficult (for me) to edit.

Whew, I need a shower!

CONSTRUCTIVE criticism to improve OSM is welcome.  Simply dumping on the 
project like I have summarized above wears out that welcome.  Not in a good way.

A couple hours ago, I was impressed with the direction of this thread, as I 
thought it was taking a turn of “people can improve OSM, people DO improve 
OSM.”  Then, the thread started to veer off the road again.  Keep it 
constructive, people, please!

Tagging mailing list

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

2020-12-14 Thread stevea
Fascinating thread, fascinating activities it seems to have given rise to!  I 
applaud this dialog as I enjoy it.

> On Dec 14, 2020, at 9:22 PM, Ture Pålsson via Tagging 
>  wrote:
>> 14 dec. 2020 kl. 22:30 skrev Anders Torger :
>> Cool! It would be really nice to see a demo :-)
> Rijmmoáhpe renders sort of reasonably now at . 
> (On the generated PDF, not on the ”slippy map”. And it’s a bit hard to find, 
> since my low-zoom tiles are so bad!). Or check my PDF at 
> .
> It still gets two labels because the area is split in half by Rijmmojåhko 
> flowing through it.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - crossing=priority

2020-12-13 Thread stevea
This is problematic to my thinking.  In California (my state), at an 
UNCONTROLLED intersection (no traffic_signal, stop sign, other traffic control 
device...), for example where the sidewalk "would continue to another sidewalk 
on the other side of the roadway," pedestrians ALWAYS have the right-of-way 
(over all vehicles) when they indicate it.  How do they indicate it?  By 
lifting one foot to step towards / into the intersection (from the sidewalk).  
Drivers must (by law) stop short of entering the intersection to allow the 
pedestrian to cross, once a pedestrian has so entered the crossing (even it if 
is unmarked or "invisible").

So, whatever proposal you come up with might properly need to be applied to 
every uncontrolled intersection (in California, and potentially many other 
places).  I ask you to keep this in mind as you craft the proposal.  As it is 
now, your proposal contradicts a fact now widespread here (and I expect more 
widely in the USA):  should it be approved, crossing=uncontrolled will describe 
crossings where VEHICLES have right-of-way.  That would break a lot of 
intersections so tagged today, making true exactly the opposite semantic on 
them, contradicting their existing meaning in our map.

Maybe I (we) should be discussing this in the proposal's Talk page rather than 
in this mail-list, I don't know.


> On Dec 13, 2020, at 11:25 AM, ipswichmapper--- via Tagging 
>  wrote:
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
> Thanks,
> IpswichMapper
> ___
> Tagging mailing list

Tagging mailing list

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

2020-12-13 Thread stevea
Peter, I think (but am not 100% certain) that super-relations are the data 
structure you look for, the "different type of relation."  It isn't QUITE a 
"different type" but rather a method of gathering relations together that 
structures them "sensibly," so, for example, a renderer can make sense of them. 
 We do this with the distinction between "plain" multipolygon relations and 
boundary relations, for example.  (The latter have some additional members in 
the relation with distinct "roles" and that makes them act — display — with 
certain behavior in the renderer).

Pilot projects are a good idea, but they need to be exceedingly clear and 
concise in what they are testing or developing (or both, and really, both in a 
back-and-forth is what works best in the long term).  So, "it's time to be 

If renderer authors / developers were to chime in here with their 
understandings / implementations of how "names of areas in super-relations" are 
understood and rendered, that would be helpful.  In fact, that seems like it is 
what is being "wished for," even if not explicitly:  a full explanation of how 
to best "name complex natural=* areas in multiple multipolygons."  If we don't 
get that dialog here, we can achieve the same results with experimentation and 

This (the wondering how things get rendered, or thinking that developing 
something new could get rendered, and importantly HOW this happens) can be a 
difficult topic in OSM.  It often frustrates, confuses and doesn't seem (to me) 
like it is talked about frequently enough.  However, "mapping, then rendering" 
is part of the wondrous magic of OSM.  I understandable that so much "that's 
really amazing" could easily give rise to "other things should be realized as 
just as amazing, too."  However, that's not how it works:  no matter how 
wonderful technology is, we always wish it could be something better.  But it 
doesn't GET better until we develop a path to get us there.  That starts with 
clear explanations, good intentions, skilled people and time.  This project 
does amazing things as we give ourselves these simple ingredients.


> On Dec 13, 2020, at 3:26 AM, Peter Elderson  wrote:
> My answer only targets the question in the subject.
> No matter whether you put the same name on all parts, or on or some kind of 
> collective, you need a way for data users to know that all the parts together 
> have a name. 
> Tagging the same name on all parts makes the name a free text id needing 
> uniqueness - for me a bad choice. 
> Yet another polygon around the area, don't like that. I think we have too 
> many of those already. 
> Tagging all parts with a truly unique Id in a special key could do the trick, 
> but who issues/manages the unique ids? 
> Putting the parts as members in a relation achieves the same: a unique Id 
> common to all the parts; the name tag and possible other common attributes go 
> on the relation. 
> This gives renderers the exact extent of the total area, and the extents of 
> the subareas, which can have names and other attributes of their own. 
> Since an MP does not cover all possible layouts, you would need a different 
> type of relation. Maybe an existing type can be used, or a specialised type 
> can be defined.
> I would think a pilot project could test the concept for mappers, renderers 
> and other data users. If succesful, showcase. If not, document and delete.
> Peter Elderson

Tagging mailing list

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

2020-12-13 Thread stevea
they don't, so they can't.  Instead, I'm asking you to be more descriptive, so 
we can both understand what might be done to assuage your sense that OSM is 
"broken."  In a broad sense, it isn't.  (It is broken in minor senses here and 
there, we hope to document and fix those).  Understandings might be broken, 
even among its contributors (and that's OK) — those can be fixed without coding 
or extensive (re-)documentation, but with good dialog like we have here.

"Mappers should take the lead," yes, of course:  that is the spirit of the 
project.  Renderers are "here to help," it's true, but they are not "wish 
factories" that "turn on a spot" (make significant change on short notice or 
with poor specification).  "That we still lack 'these' features 14 years in..." 
is not "witness to that" and I've been here for going on 12 years.  An 
"aircraft carrier" like OSM (meaning it has great mass and momentum in a 
certain direction) does not change bearing immediately, it takes a certain time 
and distance to "turn."  If we "need a render engine to take the lead," be that 
lead, don't wish for it.  If we need to define "how to arrange the data," then 
spend some time putting together proposals, and/or adding thoughtful, sane, 
sensible tags to the map and wiki-document them.  That's how this works.

It is helpful to remind us that "four or five methods of naming" results in 
confusion.  We know that.  Sometimes (as with landuse=forest), these persist:  
that wiki says there are SIX widely-tagged meanings for this tagging.  (And 
yes, that's messy).  We endeavor to get better with this and other ambiguities, 
but it isn't always easy, or it would be done by now.

What doesn't work is to unhelpfully say "it's messy" without either saying 
EXACTLY why, or complaining about it.  Trying different things to see what 
happens is a good first foray into adding helpful suggestions (and "here are my 
experiences with Carto when I tried tagging methods x, y and z").  Putting on 
your thinking cap (maybe collaborating with another local mapper thinking about 
and trying to solve the same things) about coming up with solutions are good 
next steps.  Eventually, you might put a proposal together to share with the 
wider community (like us, here).  This is OSM.  It's a process of always 
improving.  Because OSM can improve, and often does.  Largely, it does so 
through good, productive dialog (like us, here).  We're listening, really.  (I 
am, and I have invited you and invite you again to contact me off-list).


> On Dec 13, 2020, at 2:28 AM, Anders Torger  wrote:
> Here's a real example of how this naming scheme ends up looking:
> I have put the name on each part which is the enduring recommendation I've 
> got. Some parts are multipolygons, some are just closed ways, as required.
> I also added a relation on top. I've got advice against that as no renderer 
> will ever care, but I found that when editing it's hard to keep track of all 
> parts big and small if there is no relation, so I added it as a help for the 
> mapper. I set type=natural (to indicate that it's a natural object) and 
> natural=wetland (to indicate what type of natural it is, without having to 
> deduce from its members) and name on that relation. Nothing official, but at 
> least easy to filter out and find.
> In Sweden the land cover mapping is heavily behind so I've started a mapping 
> effort for natural areas and there are a bunch of naming problems to solve 
> for which there is no documented way to do. So I do these reference areas and 
> try to come up with the best methods (=least bad in some cases) so we in the 
> local Swedish OSM community have something to refer to when new mappers want 
> to help out and stumble into the same issues.
> As seen on the screenshot, the result in OSM-Carto looks pretty horrible, and 
> to my knowledge it will be as horrible in any other renderer out there as the 
> feature of naming "complex" nature just don't exist. It's the usual problem: 
> mappers won't map things that don't show up on any renderer (or displays 
> horribly like this), and renderers won't implement functions for things that 
> aren't mapped. The OSM way is that mappers should take the lead and renderers 
> will eventually follow (maybe). I think that process works really poorly 
> today (the main reason being that OSM is just too large and diverse now for 
> the original processes to work, in global scope every feature becomes just a 
> tiny special interest not worth considering). That we still lack these 
> cartography features 14 years into the project is witness to that. We need a 
> render engine to take the lead, and more well-defined standard of how to 
> arrange the data. I've got 4 - 5 different suggestions of how to put a name 
> on this wetland. Imagine if all those naming schemes gets used, what a mess 
> to implement a renderer...
> /Anders

Tagging mailing list

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

2020-12-13 Thread stevea
Thank you, Ture:  an excellent example and a great brief overview.  From my 
perspective (if I were more of an OSM beginner), I might ask about the example 
of "torp:"  might creating a tag like building=torp seem like it's on a good 
track?  Maybe not, as the value is a Swedish word, but there is an historical 
cognate in British English (more OSM-like for tagging purposes) of "thorpe" 
(maybe with an e at the end, maybe not) which came from, but doesn't really 
mean the same thing all by itself in English, more of a suffix in a 
village-name (like Scunthorpe or Maplethorp).  Looking at a picture of a "torp" 
in Sweden, and as a native (US) English speaker, I imagine a new tag for this 
might look something like building=summer_house or building=swedish_cottage or 
something along those lines that identify it as a quite-specific thing (as a 
distinct value of the building key).  So, this can be done in OSM:  such things 
do happen.

Regarding "bogs, slopes, mountains..." I hear loud and clear that there are 
challenges with the latter two.  The first, "bog" seems straightforward:  
natural=wetland + wetland=bog (and this combination does seem to be rendered in 
Carto in a specific way, distinct from wetland=marsh; the wikis display these 
differences, even at different zoom levels).

For slopes, I have noticed that "natural=ridge" has begun to render in Carto 
recently, but that's not quite the same as slope, but might begin to help if 
you must use a tag that renders today.  For mountains, I understand that this 
is NOT the same as natural=peak, so I think this mail-list would be interested 
to hear how a natural=peak and a mountain (as understood in Sweden, or perhaps 
"meant" on a map that calls such a thing what it calls it in Swedish on a map 
like Terrängkartan).  It seems those distinctions could be made in the form of 
an (early) wiki (if such tagging began, because it was well-formed enough to 
quickly draw up a wiki for it) or a proposal, which also seems it could be 
straightforward to write and gain approval.  There was a tag for natural=arete 
("a thin, almost knife-like, ridge of rock which is typically formed when two 
glaciers erode parallel U-shaped valleys") which became approved and then began 
to render.  (I had never heard of this, but when I read the wiki, I thought 
"OK, that simply means I've never heard of this, but it's real, so let's define 
it, document it and tag it).  So, this process is established and can happen 
for "swedish_mountain" (I'm making up an obviously unreal tag, but calling it 
in Swedish or maybe an equivalent-to-British-English word if that's possible) 
can open up possibilities for OSM can be the map Anders dreams of.  I think it 
can.  With explanation, some process being followed and some time, it can.

Yes, it IS nice when OSM has distinctions where distinctions are actually 
distinctions in the real world.  Let's make them together as a community so we 
can all share them!


> On Dec 13, 2020, at 2:10 AM, Ture Pålsson via Tagging 
>  wrote:
>> 12 dec. 2020 kl. 16:18 skrev 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. 
> Around where I live (Stockholm), most place=locality seem to refer to old 
> ”torp” [1] and other (at least historically) inhabited places. At least the 
> classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
> in production) rendered those differently from pure terrain names (upright 
> vs. italic font).
> Here in the lake Mälaren valley almost every square meter has been farmed at 
> some point, so most names refer to settled places (or archaeological traces 
> of them). Up north where I grew up, and where Anders seems to be mapping, you 
> get a lot more names that refer to bogs, slopes, mountains and that sort of 
> thing.
> It would be nice to have that distinction in OSM, too.
> [1]
> ___
> Tagging mailing list

Tagging mailing list

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.


Tagging mailing list

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


> 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 

Re: [Tagging] edit war related to tagging of a bus-only major road

2020-12-09 Thread stevea
Michael:  I suggest you explore our wiki .


> On Dec 9, 2020, at 6:36 AM, Michael Tsang  wrote:
> Dear all,
> I'm working with some roads in Central area in Hong Kong. Des Voeux Road 
> Central is considered one of the most important roads in the area which I 
> tagged it as highway=secondary, however another editor has repeatedly changed 
> it to highway=service on the fact that that road is closed to motor vehicles 
> except buses. An edit war has appeared.
> Here is the relevant changesets and ways:
> According to the wiki description of highway=secondary, such road "is not 
> part 
> of a major route, but nevertheless forming a link in the national route 
> network." Des Voeux Road Central (between Queensway and Pottinger Street) is 
> such a highway for buses only. Tens of bus routes are using this road to 
> serve 
> passengers between Wan Chai to Central, while other motor vehicles must use 
> the other highways in the region (also tagged as highway=secondary).
> However, a highway=service is "generally for access", and also "for access 
> for 
> parking, driveways and alleys". Des Voeux Road Central is definitely not the 
> case here. It is instead a major road in the road network usable by buses.
> What should I do here now?
> Michael
> -- 
> Sent from KMail___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-25 Thread stevea
I'm in California, where it's almost cliché we love our cars and car culture, 
but it is true that not only here but in many USA states, we have "drive-thru" 
COVID-19 testing centers.  I would guess that vaccination centers that are also 
"drive-thru" are likely soon (early 2021?), too.  These being mapped with 
"indefinite duration" seems a bit much (sorry, Brian), but they are usually 
more of a "pop-up" kind of thing:  one-time or "only on Saturdays" or something 
like that.  OSM could use the opening_hours syntax to describe the "when" of 
these being available.  But let's be clear on whether they are "testing" or 
"vaccination" (I have seen the former, but not yet the latter, unless for the 
usually-winter flu, not COVID-19).

Whether these belong in the healthcare=* key, I don't know.  The testing or 
vaccination aspect both are certainly a form of healthcare.  However, while 
COVID-19 is new, and there is now testing, but not vaccination (I expect there 
will be), regular-old "flu vaccines" (not testing for it, but a vaccine 
injection) are and have been widely available for years.  These are often at 
"drugstores" (in the USA, these are a sort of large variety store that has a 
full pharmacy in the back), and once becoming established at being a place 
where one can get your usually-in-autumn-or-winter flu vaccination, often 
perform this service year after year.  Some even advertise that they are free:  
it may be that an insurance certificate / card must be provided, rarely, though 
sometimes, even this is not required, especially for elderly / senior citizens. 
 I hope this helps.

Tagging mailing list

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread stevea
Brian, as someone who worked on these national rail relations (and still does, 
to some extent, though only around the edges), I agree with you that "very 
large" relations (in Amtrak we say that one route is >2500 relations and meets 
that standard of "very large") do exist.  And, they are unwieldy, especially 
for those who edit with "only" moderate (or less!) compute resources.  Such 
demands are partly why open mapping didn't happen until the 21st century:  our 
computers are just keeping up (as they do:  compute power fills niches of 
computing that the tech / hardware / software development only catches up to, 
it then begins to be used for those applications).  Desktop computers and Java 
/ early JOSM / Potlatch 1 and 2 around 2005 were an OK match for each other.  
OSM has grown these from there.  (Nicely, in my opinion, though there are 
always newer, faster technologies and software platforms to harness them).

AI on "bigger iron" is real today with what Facebook is doing in OSM with its 
machine learning toolchain.  Data structures must keep up.  Physics had to look 
to the ancients and see that 10 to the 100th power wasn't so big, there are 
Sanskrit words from long ago for what we consider fairly large numbers today.  
And so OSM must keep up with inventing its future (of data structures) capable 
of "keeping up with Earth as data."

Super-relations do seem the way to go:  so far, so good.  I don't know about 
"200 deep" but as things go much wider (but not much deeper than perhaps 
several "relation-levels" for now, let's say "great-great-grandparents" I can 
hold in my mind for now), they seem like they will suffice.  If we need that 
many "dimensions" (relations "deep," not necessarily wide, as data simply ARE 
wide, not necessarily deep, though we should be prepared to go deep if we need 
to) we can, as you say "go hundreds deep."

But yes, doing so both preserves the legacy of relations of relations (and even 
"of infinitum") we don't need to do that very often.  However, 
in train routes, there are now super-routes that exist that are "grandparents," 
so three deep.  This seems to be happening with bicycle routes, too and perhaps 
road routes, I'm not quite enough of a road geek to say yes or no, but I think 

Luckily, relational databases (like OSM) give us ways to link them all 
together, "walking up and down the chain of hierarchy."  Some software, use 
cases, routers, whatever...will be sophisticated to do this walking and "be 
smarter for doing so," presenting a much fuller, richer, complete universe of 
data, some (software) will not and will present a more "flat" view of the world 
(OSM's data, really, similar to looking at ways or nodes only but ignoring 

We both have and use methods to do this, so, "good."  But you are right to be 
talking about it, as data consumers, use cases, "those downstream" will need to 
have their antennae tuned to be paying attention to these "more sophisticated" 
ways of embedding hierarchy in our data.  We have been doing this since 
relations were developed in OSM, some data consumer softwares pay attention, 
some don't.  It's a real thing.  I like, for example, the way that Lonvia (in 
the series of overlay layers) allows and displays a 
view of relations and super-relations in the table of routes presented.  That's 
called "paying attention" and it's great when developers pay attention to these 
richnesses in the structure of our (sometimes hierarchical) data (so, thank you 
again, Sarah).  Being aware there IS a hierarchy is the first step to "walking 
it" and presenting its complexity to data consumers in ways that make sense for 
that sort of structure.

We'll solve coastline / water edges, it'll be mostly legacy (we've done it like 
this for quite some time) with a bit of "new methods of thinking about things" 
going forward.  This is how OSM works.  Talking about it is fine.  We're 
generating light, not heat.

A lot of people (Simon, Phake, Dave F, Clay, Mateusz, Christoph, Brian, Seth, 
Richard, more...) are quite right here.  Let's listen to each other.  We're all 
much MORE in agreement than disagreement.

Tagging mailing list

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-17 Thread stevea
DaveF:  I don’t wish to baffle, so I appreciate your clarifications.

I think we agree we don’t want “less correct” (out-of-date, etc.) data in OSM.  
We leave to the judgement of the Contributor whether data which are imported or 
curated from official sources IF those sources are of high enough quality 
(recent enough, accurate enough…) to enter into OSM.  If they are not, don’t 
import them.  That’s all I’m saying here.  I offer you my sincere apologies if 
I misinterpreted you.


On Nov 17, 2020, at 11:31 AM, Dave F via Tagging  
> On 17/11/2020 18:56, stevea wrote:
>>> I've found published data (from the authority
>>> authorised to amend the route) are often too inaccurate, out of date or
>>> lacking in detail to warrant transferring to OSM.
>> Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
>> "inaccurate, out-of-date or lacking in detail data" in OSM.
> I'm baffled how you could completely misinterpret my comment about NOT 
> entering data which would reduce the quality of the OSM database.
> DaveF

Tagging mailing list

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-17 Thread stevea
On Nov 17, 2020, at 7:43 AM, Seth Deegan  wrote:
> A contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
> Exactly.

I never said to NOT use source=* tags, they are correctly used on an individual 
datum if / as it might diverge from a greater set of data that otherwise has 
another source.  In short, if ALL of the data are from a single source, use a 
changeset comment to note this.  If not, source=* tags are appropriate.

> I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.

Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
"inaccurate, out-of-date or lacking in detail data" in OSM.

> I find the opposite and I mostly map cycle routes that are local and I have 
> personally traveled on (I live in the Chicago metropolitan area). There are 
> just too many sources for trail names and data from forest preserve 
> districts/counties, cities, regional routes, etc. that I make routes from. I 
> can't just remember all of the trail names I come across (I don't survey).

It is good to enter source data when you know them.  However, it won’t be the 
downfall of OSM if you don’t.

> What I still don't understand is why you all are discouraging the use of 
> source=* tag (or maybe you're not?). Because it seems that it can still be of 
> use to some people. Why not let users know on the Wiki page that they can use 
> the tag if they might find a specific source helpful to other users, but that 
> they shouldn't tag imagery or other general sources per-element and instead 
> tag it on the changeset? Thank you for agreeing ael.

I don’t believe I did “discourage” the use of source=* although I regret if I 
gave the list that impression.  I believe I said changeset comments noting the 
source of the data “largely deprecates” using specific source=* tags on each 
specific datum, because I have gotten in the habit of (and think it a good 
idea) keeping my changes to those which derive from a specific source (whether 
“official” data or not, as I’ll enter “personal survey” or “my own GPX tracks” 
if true) in a single changeset.  However, knowing it is true that this isn’t 
always the case, OSM does reserve the flexibility to say “from County of Foobar 
GIS Department” in a changeset comment while SOME data in that same changeset 
might contain individual source=* tags of “personal survey” or “GPS wander, 
2020-11-17,” for example.  This isn’t a perfect system, I will not get 
sanctioned if I don’t enter the true source of every single datum I enter in 
OSM, but I do strive to identify my sources, less so individual-datum-at-a-time 
(though, I’ll still do that if there is the divergence I note here), moreso via 
a changeset comment that identifies that most or all of my data are from a 
single source (like one layer of satellite imagery, for example).

Tagging mailing list

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread stevea
On Nov 16, 2020, at 9:00 PM, Seth Deegan  wrote:
> And of course, I have got this response before. But now that I think about 
> it, the limiting factors seem to be:
>   • Editors (I use iD primarily) do not allow you to easily see the exact 
> past history of an element.

OSM is not its software editors, they are merely tools for manipulating OSM's 
data, the software editors are not the underlying data themselves.  If a tool 
doesn’t do what you need it to do, either find or develop another one (or 
method) that does, or file a ticket (defect report) with the original tool, if 
you really believe it should provide the functionality you seem to be missing.  
If those seem to frustrate, there are good places to look (wiki…) and ask (talk 
pages…) for more direct help from people who might already know how to do what 
you’d like to do.

> Nor does really (why does it give a list of changed elements and map 
> area and not even allow you to see what tags and elements' geography are 
> changed!?).

I’m not quite sure of what your exact complaint is here, but if what you mean 
by “” is our website, then my reply would be that it does an OK job of 
this:  click the History button to get a recent-around-here list of 20 edits 
(click the Load More button for 20 more…and again and again if you like).  
Clicking on one specific changeset will “drill down” to the specific data 
elements changed in that changeset (to the degree they can be displayed in a 
narrow column on a web page, though there are numbered “pages” you can scroll 
through for copious amounts of data).  These are grouped by data type (nodes, 
ways and relations), which in turn can have their “history” displayed, by 
“version number.”  It’s basic, workaday metadata, but it’s quite useful and 
user-friendly, requiring no more complicated skill than to click-navigate on a 
web page.

> OSMcha only does it on a per-changeset basis. 
> does this perfectly. 
>   • What if the source is in a changeset 2+ changesets ago? I shouldn't 
> have to look back in the history to find a source.

Yes, sometimes you should.  I’ve been bitten quite a few times by assuming that 
the most recent author listed in a changeset is responsible for changing a 
particular datum IN that changeset, but actually, it was somebody else further 
back in history.  So, now I am much more careful to find out the REAL “most 
recent author of that particular datum,” meaning I DO have to go back two or 
even more versions to find out who that is.  (Then, of course, I politely 
contact them and ask “WTF WERE YOU THINKING?!” — um, I mean, “Hm, may I ask how 
you came about your edit on this particular element of OSM?”)

Good dialog here.

Tagging mailing list

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread stevea
On Nov 16, 2020, at 7:09 PM, Seth Deegan  wrote:
> May I ask why not source=*? I know it's basically depreciated, but many times 
> I find myself wondering where past mappers got the info for a route (this 
> happened just today). I would find it very helpful. It also doesn't require 
> the tagging of all of the ways.

The source=* tag is largely deprecated by use of changeset comments indicating 
the source of elements in that changeset.  Because every element in the OSM 
database (whether a node, way, closed way or relation) is associated with the 
changeset in which it was written to the database, it is easy to get from one 
to the other.  Much UI in OSM that indicates either a database identifying 
number (again, of node, way or relation) or a changeset identifying number will 
easily map (logically, from the database) from one to the other.  This also 
allows the “chain of history” and “datum version number” to happen.  JOSM’s 
“Get Info” show one-for-the-other, OSM’s web display allows you to “go from” 
one to another (click a changeset, get displayed the data associated with it, 
click a datum, get displayed the changeset associated with it), many tools in 
OSM make these associations easy.  OSM is a database, after all.  It’s good 
when we can leverage that with sensible methods.  Moving source=* to the 
changeset comment does this, in addition to encouraging sensible limiting of 
vast, many-data changesets to contain a limited (ideally, a single) source of 
those data.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-14 Thread stevea
Outstanding!  Here we see Lucas well-separating "meaning spaces" apart at the 
same time he's both looking towards the future as he offers others to sensibly 
extend the table given the structure he has started it with.  Bravo, sir.  Good 
things grow like this, with all the right ingredients in the mix to make it a 
future namespace and tagging scheme we can be proud of:  sensible, concise, 
tag-as-much-as-we-know-now (while there also being structure if there ARE more 
things we know and so can tag specifically).

The 21st century ahead for electricity.  Wow, that's an exciting place we 
imagine in many ways and we don't quite know now how it will unfold.  Tag what 
we know.  Sometimes some restructure happens.

I don't mind that we spell out our good methods as we go about making them.  
Sometimes simply agreeing on the specifics of our intentions (out loud) is a 
good idea.  There are all kinds of good examples in OSM already.

Map well.  I see Lucas mapping well and I am grateful to participate in the 
conversation.  So glad to see things vetted among others.

On Nov 14, 2020, at 5:43 PM, Lukas Richert  wrote:
> I was actually thinking of the type of battery, i.e. flywheel, LiOn, etc. 
> Although it would probably also be interesting to figure out a tagging scheme 
> to classify batteries by type, capacity etc. for the future. And it's true 
> that :grid, :generator, and :battery as second namespaces are redundant if 
> the source keys can be restricted to only being usable if the corresponding 
> infrastructure key is used. 
> The only issue I see with separating the tagging like this if the general 
> source of electricity is advertised (e.g. 'renewable' in a supermarket and 
> you can't determine if that's because they're connected to the grid or they 
> have a small wind turbine out back..rather unlikely but still). I think that 
> it's likely easy to tell or would also be advertised if they had a local 
> generator. Or perhaps would then have to be left untagged.
> If you'd like to add such a table to the wiki, feel free! :)

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-14 Thread stevea
Lukas:  Yes, I agree it seems like you are on a good track to thinking through 
the structure (of electricity and how it might be better / best tagged) in a 
deeper way that will allow you to design a robust syntax (tagging) for 
electricity.  However, whether this initial sketch is something that "should 
completely cover all cases..." really falls into the category of "only time 
will tell!"  It's good to be hopeful about one's own designs meeting present 
and future requirements, though it is much better to get other eyes on it (like 
you do here, and why our proposal process exists) so that you might enjoy the 
benefits of crowdsourcing, even when that is the sometimes head-scratching work 
of designing strong, sensible tagging.

I appreciate that you reflect back to the list here that deep thought about a 
rich, full world of possibilities for many, most or even all aspects of the 
semantics that you hope for the syntax to capture is a serious requirement for 
the development of good tagging schemes going forward in OSM.  May all of us 
who develop tags (whether with formal proposals or not by using free-form 
tagging that hasn't been used in OSM before) take the same care to design 
well-constructed syntax / tagging schemes.  Our map data deserve the most crisp 
syntax, fully devoid of ambiguity, that we are able to devise.


On Nov 14, 2020, at 9:20 AM, Lukas Richert  wrote:
> I've been thinking more about this and I think the subkeys grid, generator 
> and battery should cover any conceivable method (for now!) to acquire 
> electricity. So a grid is any collection of multiple 
> generators/batteries/substations/transformers, a generator is a device that 
> locally produces electricity and a battery (either chemical or mechanical) is 
> something that locally stores energy for later usage. 
> The possible values for any of these subkeys is then yes/backup/no (i.e. 
> electricity:battery=no), where yes means the device/grid is always connected 
> and it is usually (daily?) used. The term backup then means that the device 
> is only used when the usual device reaches its capacity or fails, so it is 
> not always on/connected. The type of backup, be it UPS or stand-by, and the 
> length of time that it can keep systems running could then also be tagged. To 
> specify exactly which devices are kept running it might then be useful to 
> have a relation-tagging scheme for circuits but I think this would be outside 
> the scope of the electricity tag which should only note the presence of the 
> systems in a building/amenity. This could then be a flag for e.g. firemen. 
> The term no would then just mean that the specified building amenity does not 
> have a grid/generator/battery. If it's unknown, it should be left untagged.
> I think this should completely cover all cases of buildings having 
> electricity? and the specific tagging for backup systems could then be 
> discussed separately. And if a new method of acquiring electricity is 
> introduced (wireless charging?) it could be easily added to the current 
> tagging.

Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-14 Thread stevea
Joseph, Kevin, Paul, Clifford, Martin, Peter, Tom, Brian, Andy, 
Graeme...everybody else here:  I love these conversations, thank you.

Tagging mailing list

Re: [Tagging] Tagging becoming more mature

2020-11-12 Thread stevea
On Nov 12, 2020, at 3:18 AM, bkil  wrote:
> Although, I understand that there could exist some special meanings of
> the word "park":

Jó napot, bikl!

There is quite a bit of history here, both past (early in OSM, as leisure=park 
developed and was both correctly and incorrectly deployed around the world), 
recently (as in a year ago / summer 2019 during the “leisure=park wiki 
incidents”) and presently (as in a developing draft proposal for Park boundary 
noted below).  I was and am personally involved in the latter two.

Differing definitions of “park” aren’t “special,” but differences in dialect.  
The wiktionary definitions are limited, as they don’t offer clear dialectical 
differences between British English and US English, where the distinctions are 
both real and quite sharp (the use of a certain idiolect of “park” often used 
in the US state of Colorado, as in the Middle Park basin, is noted in the 
wiktionary page as “US").  Better (for the present purpose we discuss now) is 
the very widely encompassing definition found at Wikipedia you quote, also 
repeatedly quoted in OSM’s wiki media (e.g. for both leisure=park as well as a 
proposal I co-author at ).  Coincidentally 
(and fulll disclosure), I believe I substantially wrote that introductory 
paragraph in the Wikipedia article’s definition, which if memory serves me, 
came from a talk-page contribution I made here in OSM (2011?  2012?).

> And anyway, terms must be understood in their GB sense within
> OpenStreetMap as declared by the project.

I disagree, with very narrow scope, in the instant (present) case.  Insisting 
on simplistic understandings of “GB English only” can cause outrageous 
misunderstandings, to which I can personally attest by being banned from wiki 
writing for two weeks last year as I struggled to untangle exactly this issue 
(though was plagued by a notorious OSM troll).  Much, much better (smarter for 
OSM, with much less rancor and long-term misunderstanding) is to more 
comprehensively understand that these linguistic differences are quite real, 
and to better accommodate them during OSM’s syntactic design phases (while 
“coining new tags” or attempting to better design tags, as we do here).

So, while leisure=park DOES remain (and should, for historical and “already 
established” reasons) in OSM, you can see how US English speakers, who have a 
MUCH broader definition of “park” than that in British (GB) English, are 
frustrated by the “limited” definition of leisure=park:  how do OSM 
Contributors in the USA, who speak US English and have thousands of what we 
call “parks” (but are NOT well-tagged with leisure=park), tag our “parks”?

We better develop that in our proposal, though are only in early stages now; it 
will take some time to complete the multiple proposal introductions that are 
planned to systematically roll out to gently do that (we hope).  But this 
process is now underway, thank you (all of OSM) for your patience.

Bottom line:  while it is good to know some of what appear to be “hard and fast 
rules of OSM,” (like “always GB English”), sometimes a greater / wider 
understanding of linguistics (dialects, how differences among them can be — 
even sometimes MUST be — accommodated in careful syntax / tagging in OSM) is 
deeply helpful to the project continuing to work (without misunderstanding and 
even rancor) internationally.  After all (and I don’t wish to be 
English-centric in our worldwide project, even as we use it here), there are 
dozens — perhaps in the low hundreds — of dialects of English around the world. 
 Avoiding misunderstandings based on these differences is something OSM wants 
to continue to do well into the future.  I know I certainly count myself among 
those wish this harmony to continue.  This can be difficult, and even (like 
here) sometimes must be explicitly spelled out, but with clarity, we can 
understand how to solve the difficulties of such dialectical ambiguities.

Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread stevea
nathan case wrote:
Not only is this often incredibly difficult to verify, it also leads to this 
complex situation of needing multiple tags for what are, essentially, the same 

A well-designed tagging scheme (doesn’t have to be a formal proposal, but 
benefits greatly by being dressed up as one) allows us, as other tagging 
schemes do, to apply tags sparsely if only sparse details are known about a 
feature to be mapped.  If greater detail is known, the syntax structure 
specifies how to denote it.  That’s an excellent example of one important part 
of good syntax design.

Tagging mailing list

[Tagging] Tagging becoming more mature

2020-11-11 Thread stevea
What I've said here (about ponds) is something I think a lot of us have long 
recognized:  syntactic design of the sort that Joseph originally expressed 
concern about, where maybe we deprecate a tag, somebody disagrees, somebody 
else proposes differences, yet somebody else says "the subject is richer than 
that and deserves a full design..." is hard work.

There is a fair bit of tagging in OSM which might be described as "poor in 
hindsight" that works (and in some cases worked) OK for a while, but when 
brought into the larger world, begins to crack around its edges.  Some of this 
is due to linguistic differences around the world (e.g. leisure=park 
conflicting with the use of "park" in US English), some of this is due to hasty 
and poor syntactic design of the tag in the first place.  Some of this is due 
to reasons I'm not mentioning, as maybe we don't even (yet) fully understand 
why some of what we do might not be quite good enough to grow into our future.

While I'm not proposing any specific fixes to these longer-term challenges to 
OSM, I am saying that good syntactic design (and when appropriate, formal 
proposals to implement them) is an important element to minimizing the risks of 
how we've been doing this during our first couple of decades.  As OSM grows 
from adolescence into adulthood, (16 years and growing!) I believe we can keep 
our "plastic tagging where we can coin a new key" so it remains intact, as such 
free-form tagging is an important flexibility built into the project.  However, 
as we mature, become more worldwide (linguistically diverse, accommodating 
similar-yet-different aspects of many things, both in slight naming differences 
and slight actual differences...) we must consider more mature methods to 
implement well-designed aspects like sound, future-proof tags.  This includes 
both improvements to existing tags as well as new tags.

I love the spirited discussions that happen here and other places in OSM where 
a variety of voices come together to discuss new ideas, new tags and new ways 
to map:  may this wonderful spirit live on forever in our project.  Yet, we can 
also simultaneously recognize that there are "grown-up" methods to designing 
"industrial strength, world-ready" aspects to the project that will last and 
last far into our future.  Let's find ways to keep both going strong, whether 
it's moving more to formal proposals (or not), other more formal methods (or 
not) and keeping great, inclusive, respectful dialog alive as we do so.

Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-11 Thread stevea
If we're going to do "this:"
> So perhaps we could create a new tag water=natural_pond for small, natural or 
> semi-natural lakes which are currently tagged as water=pond, and 
> water=artificial_pond or water=man_made_pond for the majority of water=pond 
> features which are clearly not natural, such as ponds in gardens.

it seems we should ponder (sorry, couldn't resist) the myriad possibilities for 
ponds both artificial AND natural and make a formal proposal that "covers all 
cases," at least as best we can in a formal proposal.  This would clarify 
(sorry, couldn't resist) what they're all "used for," as in settling in the 
case of a wastewater treatment plant, decorative as in somebody's backyard 
garden, natural, as in "shallow, nature-created, not-deep-enough to be called 
lake..." and so on.  Don't forget to consider (and document) potential overlap 
with things like leisure=swimming_pool and possibly others.

We might get a good start on doing this in a talk page, but I think it would 
greatly benefit from the thought that goes into a formal proposal:  worldwide 
consideration of the semantic space being described, rather clear syntax and 
namespaces described, how to decide one from the other, linguistic differences 
(as Joseph mentioned there can be a flattening in particular languages that 
might deserve extra clarity), how to migrate from existing tagging to the 
proposed tagging, and all the rest that formal proposals treat (what wiki need 
to update, et cetera).

I admire Joseph's "tossing here" what he wrote, as it gets things started, but 
I believe the subject is much richer than this.

It would also focus efforts by those who care and in as much detail and in one 
place as such a specific topic deserves.  While I don't write this to 
discourage posts to this list (I don't, as this list is a valuable place to 
discuss), I have also noticed a trend towards formal proposals.  "Ponds" seems 
like an excellent candidate for one.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-11 Thread stevea
That IS what I mean.  However, STILL left unsaid is that short of ringing the 
doorbell and asking the home / business owner "are your solar panels grid-tied, 
battery-feed, directly converted to an inverter...?" you don't really know.

How will you tag those buildings?  (I feel a nose sniffing up my, um, house).  
Really, there isn't any way to know, without getting creepy - snoopy.


> On Nov 11, 2020, at 3:45 PM, Lukas Richert  wrote:
> If I understood you correctly, this would fall under grid-connected houses 
> that I mentioned in the last example. This was the specific reason why I 
> think namespace tagging seems to be clearer. The house would then be tagged 
> with:
> building=house
> electricity=yes
> electricity:generator=yes
> electricity:grid=yes
> electricity:generator:origin=solar
> electricity:access=no
> By tagging both electricity:grid=yes and electricity:generator=yes this 
> specifies that the building is connected to both and both are routinely used. 
> In contrast, it would also be possible to tag electricity:generator=backup if 
> the generator is only on when the grid fails.
> Is this what you meant by grid-tie?
> Regards, Luke

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-11 Thread stevea
I hope this doesn't throw too much additional confusion into electricity:grid, 
but in many parts of the world (including where I am, California) a frequent 
method for connecting solar panels to both one's house / commercial building 
and the grid is to do what is known as "grid-tie," sometimes called "net 

Grid-tie means that during sunshine, the solar panels generate and "spin the 
electric meter backwards" (creating a credit to the customer with the electric 
company) and at night, when electricity use / loads create a debit (by drawing 
power directly from the grid / electric company), the meter "spins forward" as 
usual during power use.  Of course, the idea is that generation and load 
balance each other out during a billing cycle and this "net metering" nets out 
to about zero, so the customer has a near-zero bill.

That is prevalent enough in the world that if OSM is going to design a tag for 
electricity:grid, it really needs a syntactic accommodation for "grid_tie" or 
"net_metering" (which are essentially the same).  Especially as I'm not sure if 
this would go under electricity or electricity:source (which introduce at the 
same time), I haven't any specific suggestion on a key, tag or namespace, but I 
think it important to mention what I haven't seen in this discussion.

Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread stevea
On Nov 9, 2020, at 6:22 PM, Graeme Fitzpatrick  wrote:
> Yes, long, but not (yet!) tedious, at least to me! :-), as I both agree, & 
> disagree, with some of the points raised.
> Looking forward to the result of the discussions you both may have.

I appreciate that, Graeme.  As Anders gets back to me and we continue to hash 
out what I hope are understandings, with his permission I'll re-post those 
"results" back up here.  I HOPED that this wasn't too tedious, thanks for 
letting me know that being wordy is (sometimes) worth it.

Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread stevea
 makes a project 
> automatically mature. Another perfectly realistic scenario is that the a 
> project outgrows the initial processes making it stagnant in certain aspects 
> which causes various functionality gaps that wouldn't be expected of a 
> project of this age. It's my assessment that this is exactly the current 
> situation with OSM. No assessment is perfect and 100% complete, but for my 
> own purposes I've got enough of those indications to come to that conclusion. 
> This doesn't mean that it cannot change, but it's not something I can do. The 
> only thing I can do is to report what I see and then the rest of the 
> community can do whatever they like with it.

OSM, being "16 years old" isn't an automatic "well, if it is that old, it must 
be mature," I only said that because 16 years old, in the case of OSM, IS "old 
enough" to have developed a great deal (certainly not everything — "the map is 
never done") of the tagging and infrastructure it needs for people (like you) 
to map, and even map quite well.  It appears you continue to be frustrated with 
what you identify as "basic cartography features missing," yet I'm not 
convinced of that.  I still think there are tags you might use (or coin) that 
can create the sort of map data you believe should be in the map.  Though, 16 
years is also sort of "adolescent" or even "very young adult" stage (for human 
development), I'd even say that OSM is in a similar state of adolescence or 
young adulthood, and therefore in an interesting state of (early) maturity.  
Maybe OSM's lifespan / lifecycle has a timeframe similar to humans:  I wouldn't 
be surprised if OSM or something it might morph into is around in fifty or a 
hundred years from now.  OSM is simply a darn good idea and has become 
seriously established.

> In all, for me probably the wisest thing to do is to step back and continue 
> my casual contributions as needed for my bike routes, and keep and eye and 
> see what happens with OSM at large and locally in Sweden, but not engage in 
> detailed cartography until it can be represented well.

There you go again assuming that because "it isn't represented well" (in a 
particular renderer) OSM is at fault for having "features missing."  Not so.  I 
agree that this can be a concept that many struggle with, but I ask you to 
please separate these issues in your mind, as it resets your expectations 
properly.  Entering correct data into OSM as a database is the goal, seeing 
these data render in a particular renderer is a different task only 
tangentially related to the data being there.

> Regarding suggesting things, I think I have made plenty of suggestions, both 
> in terms of how features could possibly be implemented, and how priorities 
> could be changed etc, and many of these are just the same as many others have 
> suggested in one way or another. Of course, I cannot expect these to be 
> implemented just like that, and obviously many think that these suggestions 
> are outright poor ideas, perhaps the majority of the community. I don't know. 
> This is just a view of some random guy making a due diligence of the OSM 
> project from a Swedish casual mapper perspective:

In the list that you provide (excellent!), let's break the components into two 
broad classes:  those that are more "organizational" suggestions (expert 
groups, how to organize imports, community growth, marketing / "selling," OSMF 
board "roadmap,"...) and those that are specific to mapping issues (which you 
characterize as "basic cartographic features missing" which I don't believe is 
true, but rather a misunderstanding of how to enter data into OSM and perhaps 
see it render on renderer-A or renderer-B, perhaps not).

As I'm not on the board nor do I have any more "pull" (influence) over how the 
"higher level" tasks you identify play out in the future, let's subtract those 
(for now) from this tagging list discussion (as they aren't really appropriate 
here, though they are concerns of yours and should be addressed, just not here).

For the specifics of "how do I map these features?" concerns you have, again, 
let's take that off-list.  Those would be appropriate to discuss ON list, it's 
true, and maybe you publish the RESULTS of our off-list discussion here after 
we've emailed each other.  But I feel we have spent a great deal of time (and 
passion!) here on this list and it's getting tedious for other readers.  This 
thread is LONG!


Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread stevea
Oops, "dearth" of data, not "death."

Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread stevea
On Nov 8, 2020, at 7:58 AM, Anders Torger  wrote:
> I believe the processes available are limited in terms of fixing structural 
> problems.

You say you have long experience in open projects, that is a fantastic 
launchpad from which to join OSM and improve it, even criticize it.  I read 
that you (here, now) begin to identify what some of these "structural problems" 
actually are, but your major criticism seems to be that "processes available 
are limited" (I disagree), while my response has been that I agree with you 
that improvements in OSM take a (relatively) long time to fix.  Being 
consensus-based, OSM makes no apologies that major structural improvements take 
a (relatively) long time to fix, but major improvements usually DO take a long 
time to fix, regardless of organizational structure.  To wit, even if OSM were 
run by a single autocratic despot, major structural improvements would still 
take a relatively long time to fix.  This means "the processes available" being 
limited as specious (plausible, but wrong), as there is vast creativity on tap 
that OSM applies to solving problems:  this is another example of the power of 
crowdsourcing being unleashed performing powerfully.  Crowdsourcing doesn't 
apply simply to a bit of mapping here, a bit of mapping there adding up 
(though, that is true), it also applies to processes, code improvements / bug 
fixes, structural betterment, better wiki documentation, better tools and (over 
time), the voting in of better qualified board memberships which contribute 
sharper and better-applied skills to problems that need solving and 
improvements that need doing.  Sometimes there is "a step backward with two 
steps forward," but that is true in any organization.

OSM doesn't claim to be perfect, fast or complete.  It does get better, though 
slowly, that seems to be "baked in" to how OSM works.  It appears this may be 
too slowly for you, but I submit that this may not be true, should you apply 
some shoulder to the effort in appropriate places (improve the map, improve 
tools that provide you with your renderings...) rather than to complain.  
Especially as I (and others) might identify your complaints as 
misunderstandings that can be solved by working more within the established 
paradigms of OSM.  However, identifying problems is the first step in solving 
them, so I hear you, though mostly what I hear is frustration.  If you can 
propose better paradigms for OSM, you do have people listening.  (Though, this 
does not seem the proper venue to do so, we are likely putting people to sleep 

> It works well to add things into an existing structure (if you're not in a 
> hurry). A "GOOD idea" is thus one that takes little effort and has little 
> controversy, like adding a minor new tag preferably one which really don't 
> need to render on OSM-Carto. If you need to do something that requires 
> structural change or adjustment it seems you're in for a rough ride. Sure 
> that's natural of course, but it becomes a bit like trying to run a 
> multi-national company with no leadership, just consensus-voting with people 
> "on the floor" inside their own local bubble (like myself).

Yes.  So?  Structural change in OSM isn't "a rough ride," it is hard work and 
takes time.  That's a truth in any organization.

> The principle if you see a problem, then you fix it on your own: I know all 
> about it, I've worked in many open-source projects small and large and 
> released several on my own, some still in active use 20 years later. However 
> when something gets truly big, total decentralization can become problematic, 
> and at some point many can't thrive only on voluntary contributions, some 
> parts need professionalization and corporate sponsorship etc. Large 
> successful open-source projects have evolved their organizations to adapt to 
> new situations.

Propose specific changes, please.

> "Fix it on your own" is how imports seems to have been managed. With varying 
> success. It has worked well in countries were the community is strong and 
> technically skilled, but in countries with weaker local community, like 
> Sweden, it hasn't worked. I think the problem is that as OSM has grown so has 
> the technical expertise required to "fix it on your own" so the threshold has 
> just become too large for casual contributors. You basically need to be a 
> professional or have this as your only big hobby plus have developed 
> engineering skills to be able to make a good job, and judging from the 
> results exactly zero such people exists in Sweden. Therefore I think OSM 
> should strive to have a professionalized import task force where imports are 
> centralized, and merging with existing data is made by the crowd of casual 
> mappers according to clear guidelines.

If your community is "less strong," then please strengthen it.  That's why it 
hasn't worked and it has (a rather obvious) solution, defined right here.  You 
seem quite technical and 

Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread stevea
h is really odd. I don't even know where to send newcomers 
> when I want to show them what OSM can do. I think 
> should be an end user site, and say something like 
> could be the site as it is now. I think we need to think about how OSM is 
> experienced from the outside, unless we just want it to become a niche 
> handicraft object for ourselves. 

Thank you for your opinions.

> And by the way the website looks exactly the same it did like 10 years ago. 
> That's good for an edit website for insiders. It's not good for being the 
> face of OSM, and contributes to the view that development is glacial even if 
> a lot happens under the surface. Sure people like us usually don't like 
> website fashion, but we can't just ignore how OSM is experienced from the 
> outside. Oh well, we can, but I don't think it's a good idea long-term.

Thank you for your opinions.

> Garmin has a vector rendering of openstreetmap in their connect fitness web 
> app, they also have Google and HERE as alternative layers. The vector 
> openstreetmap layer is no way showing near what actually is in the current 
> database, and there's various artifacts. A huge lake where I live is missing 
> alltogether (probably because the polygon is made in some way that vector 
> engine can't understand). I think this is just one example what happens with 
> the fragmented landscape of OSM map providers and that our own maps are not 
> able to fulfill the needs of typical applications. Garmin as being hugely 
> popular in Sweden among fitness and outdoor people showing OSM in a rather 
> bad way. That's not helping the widespread view here that OSM is becoming 
> "obsolete".

Thank you for your opinions.

Anders, we want to help.  Let's take bite-size chews here, so we can masticate 
and swallow, without choking.  Rome wasn't built in a day.

Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-07 Thread stevea
y like that.

> To make it pleasing the resulting product should be good, and I think there 
> is more to do there, not the least for rural areas where the naming issues is 
> most evident.

Yes, there is ALWAYS "more to do" in OSM.  Consider this:  "the map is never 
done" and "the map is always getting better."  When I put those two together, 
it keeps me going in OSM.  We all have our favorite issues we might solve, may 
you find that focusing your efforts results in you (and others) achieving what 
you wish to see.  It can be done, I'll attest.  Certainly, this takes effort 
and often head-scratching, lengthy, sometimes difficult interactions with 
others and learning new things, yet those are part of the magic, charm and 
rewards I find contributing to OSM.

Tagging mailing list

Re: [Tagging] Basic cartography features missing, why?

2020-11-07 Thread stevea
rsistent perfectionist to actually care (sort of like an old-school 
> cartographer), and have the endurance to continue to care. It's much easier 
> to just skip the names that can't be mapped, or make them as a point and not 
> care that zoomed out maps don't work well. We've seen plenty of 
> desperate/chaotic use of place=locality tag just to get names when there is 
> no real support.

Yes, you need “endurance to care.”  Again, this comes with practice.  Learning 
what “works” in the map (how tagging becomes rendering, how poor tagging gets 
“weeded out,” how careful tagging gets reinforced and replicated…) and how to 
work with other people in the map who share your visions are all part of how 
OSM works.  Please resist the temptation to “skip what can’t be mapped” and 
keep asking the excellent questions you are asking to connect with others who 
might show you, “Anders, here is how the names CAN be mapped…” (in a context of 
“you might not know…” or “we might better wiki-document that for THIS feature — 
around here, as we have fjords, or glaciers, or whatever…THIS is how we map 
these).  It seems to me you are on the right track to doing these things and I 
want to encourage you to keep doing so.  There are not often “magic wands” that 
do the hard work of making “something special” out of “very little or almost 
nothing at all.”  However, there are helpful people and a lot of “machinery” 
(history, tagging schemes, collections of key-value pairs that mean to signify 
certain things…) to do so.  Ask.  Listen.  Seek other members of your community 
here.  Share your common goals and perhaps “regionalize” areas (you take north 
of here, I’ll do south and west of there…), and "we’ll see how far we get in a 
month.”  I and many other mappers have good success with these sorts of 
strategies and we build bicycle networks, train routes, hiking trails and city 
blocks, neighborhoods, shopping districts and power infrastructures, just to 
name a few.  The sky is the limit here on Earth and in OSM:  be imaginative and 
creative and let your ambitions and community share together and discover how 
high you can fly.

> If that's the case, then it maybe is better to just relax, let go, and let 
> OSM be what it is today and not try achieve what it can't do. For me this 
> means going back to just doing road work, and switch to the government maps 
> anytime I need a real map. I'm fine with that.

OSM is what you give to it and then you can take something of it and from it 
and say it is yours.  Giving is the first step in receiving, although there are 
many who simply avail themselves of the wondrous fruits of the OSM tree — there 
is nothing wrong with enjoying its resources, too.  However, if you CAN give 
(data, resources, local knowledge, skills, vision for the future, people skills 
like community development, writing skills like wiki documentation, or even 
just simply that you know the hours of when the coffee shop opening now happen 
an hour earlier on weekdays, please, contribute what you can to OSM.  As I do 
so, I find the rewards are amazing.  May you, as well.

OSM Volunteer since 2009

Tagging mailing list

Re: [Tagging] Parking fee only after some time period

2020-10-21 Thread stevea
On Oct 21, 2020, at 1:43 AM, Peter Elderson  wrote:
> towing_penalty=no means your car is towed away for free? In Nederland, towing 
> always comes with a penalty, even if you don't want your car back.
> Maybe a tag for consequences should be introduced. I suggest or_else=cargone.

What I mean by towing_penalty=yes is that it is POSSIBLE that you might get 
towed if you exceed the maxstay (or a semantic otherwise 
interpretable-from-the-tags).  What I mean by towing_penalty=no is that the 
particular "enforcement method" of getting towed to make you think twice about 
exceeding the maxstay isn't a chosen tool on this parking lot, and/or there is 
no sign so indicating.  (And as usual, if the tag is omitted, it isn't known to 
OSM, whether it is yes or no).

or_else=cargone did make me laugh out loud; thank you for that.
Tagging mailing list

Re: [Tagging] Parking fee only after some time period

2020-10-21 Thread stevea
In California, a common (not quite frequent, certainly not always) arrangement 
at malls, supermarkets and other places with parking lots (large and small) is 
a sign that reads "you can park here for three hours, but after that we have 
the right to tow your car away."  (Sometimes punctuated with 'video 
surveillance active' to make the point fairly direct and that "they mean 
business").  In my experience of driving-and-parking for many decades, I 
personally have never gotten towed (the few times I've gone over a time limit), 
I've never heard of anybody (that I personally know) getting towed, but I have 
seen the extremely infrequent tow truck towing a car that has likely been there 
a while — perhaps it was abandoned, used for illegal purposes or was otherwise 
a public nuisance.

So, while that "moderately serious consequence" of getting towed is possible, 
it's rare.  And, while this is not a "fee," it certainly turns into a fairly 
large one once the bottom-line-costs, tow truck driver and storage charges (per 
day, usually) are added together and paid to get one's car back from the 
impound lot.

If you are writing a proposal, this is a reality in certain parts of the world 
the proposal should consider, if it wants to convey the full situation (on 
Earth, in cars, with humans, on parking lots).  In short, what appears to be 
"simply" a fee can be fairly full-throated when it comes to describing the 
entire semantic richness of the situation.

A tag like maxstay is a good beginning.  An additional tag of something like 
towing_penalty=yes|no is a start down this road.

Tagging mailing list

Re: [Tagging] railway=station areas

2020-10-17 Thread stevea
There really is a time, place, realm to cleave a sensible split between public 
and private.  Choose the correct register, yes, please.  Chill jets, everyone.  
Mapping in public like we do has its difficulties.
I know it takes time to work things out, so let's work things out!
I think we were talking about railway=station areas, yes?

Tagging mailing list

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

2020-10-12 Thread stevea
Majorities can be built with reason and well-written proposals.  They really 
can.  This is where and when OSM can be at its best.

Am I saying "rig an election" or "throw votes in an unethical manner"?  Of 
course not.  I'm talking about building real grass-roots support for good ideas 
that are well-stated and agreeable.  That actually happens.  And when it does, 
good for us.


Tagging mailing list

Re: [Tagging] railway=station areas

2020-10-09 Thread stevea
There are times and places when / where "keeping plural tagging schemes" is a 
smarter method to interpret OSM's data.  (Many, in fact).  Saying "this how we 
should map" (being 'prescriptive') is not the same as wishful thinking.  Being 
'descriptive' and saying "this is how we do map" (as we quote taginfo) is 
(rather) simply looking at existing data in a particular way.

We're smart.  We're people.  Let's stay smart and be smart.  Tagging evolves, 
tagging has legacies.  We must live with this seeming dichotomy and manage it 
simultaneously.  Mechanical consumers of OSM's data do get smarter, too.  
(Though I don't think the machine learning is anywhere near sentient!)

These (railway stations) are nodes, these are polygons.  These have many 
methods of interpreting them, so interpret them.  We might (I think we do) 
improve them as they evolve.  There are good methods for these to evolve, 
here's the good news:  this happens, as co-operation and consensus work.  Ask 
yourself:  how many simultaneous (on the planet) "methods" must I imagine these 
things in the real world today (highways, railways, bike routes, PT routes, 
boundaries...) in OSM?  Two?  Four?  Six?  Eight?  It's more than one, for 
sure, and that's OK.  That's OSM.  We have newer data and methods and older 
data and methods simultaneously, it does get better.  There are seldom magic 
bullets, it often takes work for these things to evolve.  Yet, they do.  Work 
it out, we can.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

2020-10-03 Thread stevea
On Oct 3, 2020, at 4:10 PM, Paul Allen  wrote:
> Or maybe something like this?
> I added the farm nearly a year ago.  Held off on adding what they call the
> "farm shop" because it had recently moved from Llwynhelyg Farm across
> the road, was still settling down (I wasn't sure if they were going to keep
> it going for long) and (most importantly) I couldn't figure out where exactly 
> it
> was.

That facebook page isn't exactly the best venue from which to make a 
determination of what this place is, but I get the gist of it, and yes, I'd 
call it a shop=farm, too.  Clifford, we, too (Coastal central/northern 
California, heck, all of California as I grew up in southern) call these "farm 
stands" in local vernacular.

Around here, the (quintessential, cutest, loved by locals...) place like this 
is  I think they've 
moved since the "grandfather of the family" died last year 
 but only down the road a bit.  I believe the family owns a fair bit of 
farmland in the area and their produce and farm products (even farm-produced 
strawberry soap!) are loved by many around here, Yelp is solid five-out-of-five 
stars in ratings.

I thought I had tagged this near here but I'm not seeing the node in OSM, I'm 
going to have to go and see what they've done in the last year and update the 
local tags.  There really are quite a few of these, especially around 
Watsonville and Castroville.  There are more (Cascade Ranch "U-Pick") up near 
Davenport, Swanton, Año Nuevo State Park.  If you are not in a hurry (and you 
are not if you are driving the Coast Road) and want to soak up some local 
color, try these, they are hard to beat!  Both locals and tourists "passing 
through" seem to love these places.  I've bought pies for holiday feasts and 
they are always a hit.  Kids love to pick out pumpkins in mid-to-late October.  
Even Wikidata says that shop=farm is sometimes called a "farm stand" by locals.

It's good to eat local, it's good to map local!

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

2020-10-03 Thread stevea
I'm glad someone mentioned these, they are common and have been here for 
decades up and down California.  Like food trucks, they come and go with 
frequent irregularity.  Sometimes they are more-permanent, sometimes they are 

> On Oct 3, 2020, at 2:35 PM, Graeme Fitzpatrick  wrote:
> On Sun, 4 Oct 2020 at 00:39, Paul Allen  wrote:
> More important is if there is a sign,
> Hand-painted signs saying "Horse manure", "Avo's", "Firewood", "Eggs" & so on 
> good enough? 
> We see lot's of them whenever we go for a drive in the country, & even the 
> occasional one in town!

especially on higher-speed primary or trunk highways in rural farming country 
as you'll get one, two or three signs:  "1/2 mile ahead, fresh apples, stone 
fruits and pies!" with cheerful graphics of cherries and baked goods.  
shop=farm_stand, is what I'd like to tag, but I haven't done an OT query or 
taginfo.  Sometimes it's a pickup truck with fruit boxes or someone out of the 
trunk (boot) of their car or a "go through the door, can I get you another cup 
of coffee with that (honey)?" sort of place.

If it's the latter (might be a full-blown "diner" restaurant, sometimes called 
a "road house") or it might be a simple "get hot water for your tea from the 
pump thermos, and yes we do serve pie, but only to go" kind of place. Those are 
different than the sort of transient (maybe there, maybe not) out-of-a-truck or 
farm wagon kind of thing.  There is also whether the farm is right next to the 
stand, which is sometimes true but more often not (and it's all-run-together, 
more permanent).  I agree with Paul that shop=farm fits these, that's how I 
tagthe ones that are local (iIrc, I haven't been comprehensive in my search).

We have those kinds of places around here with berries in the summer (cute 
signs say "U-Pick"), squashes in the autumn.  Along rural, farming highways 
between towns and cities.  They exist.

I would never say direct_marketing about these.  I might say shop=farm_stand if 
I were being "local vernacular," what we call them here, yet I think the 
more-permanent-ones-associated-with-the-farm-right-here are shop=farm.  And 
maybe what kind of fruit, being seasonal if they are and I can.  Drive along 
the coast between Half Moon Bay and Castroville, you see a dozen or more of 
these.  I think they (or something very much like) are somewhat frequent in 
much of rural, populated Earth.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

2020-10-02 Thread stevea
Wieland, I don't have good answers to offer to you for your other questions.  
However, I would say (as others have) that "direct_marketing" absolutely IS 
"confusing," I go so far as to say "incorrect" in these circumstances.  The 
term "direct_marketing" is used in various dialects of English around the world 
as meaning something wholly different than your proposed usage here.  So, I 
(and others) ask you to please deprecate any consideration of using the tag 
"direct_marketing" in your proposal.

Good luck crafting the correct set of tags you strive to achieve to describe 
the set of semantics you have.  This is often not easy work, as you have 
discovered.  However, with some effort (collaboration with others helps, this 
discussion list is a good start) it can be done.  You might need a combination 
of existing tags, perhaps a combination of new tags or new values on existing 
tags, but such "syntax crafting" (tag development with thoughtful key:value 
pairs and how to use them) is often long and somewhat difficult work, 
especially to gain first understanding and then consensus among our community.  
Take into account "what already is" in OSM, and if you seem to need to "tag 
your way around this" you might be on the wrong track.  But if you find a 
certain harmony with existing tags, keep working in that direction as it is 
often a more correct track, especially for people to understand.  And often, 
with understanding comes acceptance and then wider use.


Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-30 Thread stevea
On Sep 30, 2020, at 5:27 AM, Paul Allen  wrote:
> BTW, ordinary polygons won't do for this.  You'll need a multipolygon
> to exclude the Mount Wilson observatory and some campgrounds that
> were saved from the fires burning all around them. :)

Perhaps I have not been clear or remain misunderstood:  the polygon is not an 
exact delineation of "this (and exactly this) has all burned."  It is the 
perimeter of the fire, inside of which the fire was "fought" or allowed to 
burn, outside of which, "not."  If there are areas (like Mt. Wilson Observatory 
and campgrounds) inside of a perimeter that were "saved," the polygon should 
not explicitly exclude these areas with role "inner" as part of a multipolygon 
relation — that isn't the semantic of the perimeter.  Many areas inside the 
perimeter DID burn and will need their existing land cover (natural=wood, 
natural=scrub...) tags removed, some areas (trees, houses which were saved...) 
did NOT burn.  It would not be correct to re-map the fire=perimeter as a 
multipolygon with not-burned areas with role "inner."  As newer imagery becomes 
available, it is correct to leave not-burned areas alone, adjusting them up to 
the edge of where they DID burn, and in areas which did burn, removing / 
adjusting-to-smaller-areas land cover tags as they exist now.  This area was 
almost exclusively heavily wooded in the real world and OSM well maps fairly 
precisely where these "woods" were.  Only now, much of them burned.  Where, 
exactly?  "Somewhere inside of" the polygon denoted fire=perimeter.  OSM 
contributors await newer imagery, we will better (re-) map landcover and other 
data that are inside of the polygon when they become available.

At the completion of this process, the usefulness of the polygon diminishes to 
zero (perhaps there remain closed roads and dangerous areas, these can be 
mapped "differently," although "no-go" area tagging remains unclear) and the 
polygon can be removed, having exhausted its usefulness.

Some might complain that such an "improve existing map data HERE" polygon 
overlaps with small projects like a localized import or a Mapping Party to 
improve a particular city or county, saying a Tasking Manager or similar tool 
can and should be used to manage this.  But while "a particular city or county" 
have well-defined, largely in-the-map boundaries, an area devastated by major 
fire has no such boundary.  Unless and until a polygon tagged fire=perimeter is 
entered, to describe an "area of interest for improvement of existing map data" 
(rather than "this is all burned").  A Tasking Manager could be used for this, 
but it needs such a polygon to identify the area of interest.

Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-30 Thread stevea
On Sep 30, 2020, at 2:31 AM, Sarah Hoffmann  wrote:
> This is a classic case where you should set up a separate
> database to save the polygons and overlay them with OSM data.

Thank you for your thoughtful reply, Sarah.  However… (and it’s not polygons 
plural, I only entered into the map this singular case, though with this 
discussion and other firefighters chiming in that these can be useful data in 
OSM, they could be talked about as a particular class of object)…

> For one thing, the description sounds like it is not really
> suitable for OSM. It describes a past even ("the perimeter
> firefighters used weeks ago")

That’s not quite what I said, I said “the extent of where firefighters kept the 
fire limited by building a perimeter around it.”

> which is likely not ground
> surveyable because I doubt that the firefighters have put
> red tape all along the perimeters.

I’m not positive that this is true for the entire perimeter, but 
bulldozer-cleared areas, hand-dug trenches many meters wide (to prevent a fire 
“jumping” from one side of the perimeter to the other) and usage of cutlines 
(for power cables / towers) and roadways to establish part of a perimeter are 
all strategies I believe firefighters use to “build” such a fire perimeter.  
This is much more clearly delineated in the real world than might be a bit of 
red tape on a tree.

> The description is really
> fuzzy. It just defines that the area is "of interest for
> something".

It is of interest for two specific purposes (perhaps better outlined here than 
in the recently-added note=* tag, though I only get 255 characters there):  to 
say “better mapping of existing land cover tags is very likely necessary HERE” 
and to say “if you intend to hike in this area, know that due to (recent) fire, 
closed roads and dangerous conditions, very much diminished in their ability to 
provide a suitable recreational landscape, are likely found HERE."

> We have traditionally rejected this kind of
> mapping, see e.g. recent discussions on no-go zones in
> cities. The problem with them is that you don't find two
> mappers really agreeing what they mean to represent. That
> is bad in two ways: a) data consumers shy away from using them
> because they cannot rely on that they mean what they think they
> mean and b) the features tend to rot in the database because
> most mapper don't dare to touch data they don't understand.

I recall that “no-go” discussion and I agree that it was / is hard to define, 
which does yield “two mappers won’t likely agree on what this means."  Yet 
here, I see the focus sharpening on what is meant by this polygon, as well as 
others who say “yes, as a HOT mapper, a firefighter, someone for whom structure 
re-building going on in an area in a construction-intensive way, delineating 
this in the map is useful.”  In a sense, this discussion is a (more dilute?) 
form of a wiki proposal for fire=perimeter.  Except it is not, as we only 
discuss a single polygon, yet others say “I can see how THESE (not simply 
“this”) can be useful data.  As we agree on what fire=perimeter means, the 
ambiguity reason (a) vanishes.  And (b), as already discussed, such data don’t 
(or shouldn’t) “rot,” since as mentioned before, they fall away from the map 
when their usefulness vanishes.

> The other thing is that this kind of data is really easy to
> merge with OSM data. You don't need to merge attributes into
> specific OSM objects. You just want to state "anything inside
> my polygon needs attention". Perfect for overlays. So there
> really is no need at all to burden the OSM database with it.

I think “burden” for a lightly-tagged polygon is hyperbole (exaggeration), but 
I do see the point that a sophisticated user who is curating data in, around or 
associated with such a polygon might find an overlay strategy to be ideal.  But 
doing so leaves out all other OSM users (many, besides the single user noted 
above) and all other “useful” reasons for the data being shared in the database 
(which might become many, but are now discussed as “at least two:  to better 
re-map and to warn users “there was a fire here, use care”). Perhaps we have 
identified an edge between where “data are better curated outside of OSM” and 
“data that seriously benefit by being shared and hence Inside of OSM.”  Who 
decides?  How?

> Just to emphasize again: I'm not saying that the data is useless.
> I just think it is better put elsewhere.

I respect and welcome intelligent discussion on which data belong “in or out” 
of OSM, and why (or why not).  Perhaps this topic is (or is becoming) partly or 
mostly exactly that.

Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-30 Thread stevea
On Sep 30, 2020, at 12:01 AM, Andrew Harvey  wrote:
> So it seems then that what you're mapping here isn't so much the active fire 
> front, it's the burnt area given you want it to stick around after the flames 
> are out.

Neither of these two, really.  Certainly not the active fire front:  the fire 
is out (for about a week now, but it burned for about six weeks).  Nor “the 
burnt area” exactly, but rather a polygon which represents the EXTENT of where 
firefighters kept the fire limited by building a perimeter around it.  Some 
(I’d guess much or even most) of it IS burned, no doubt, but exactly where is 
not fully yet known — but burned areas certainly ARE inside of this polygon.  
This is useful because it shows not only where OSM mappers (like me) will need 
to update landcover (and in some limited cases, landUSE, too) as we update map 
data, but where map data consumers such as hikers in the area (like me) will 
want to know “there may be closed roads, dangerous areas and severely limited 
viewscapes, wildlife (both flora and fauna) et cetera to enjoy were I to 
recreate here.”  These are but two valuable reasons for this fire=perimeter 
remaining in the map, until the polygon's usefulness essentially becomes 
exhausted (there are no longer reasons for these data to remain).

> During Australia's fires last season, I did contemplate mapping active fire 
> fronts, given I could see with my own eyes where the flames were up to and I 
> could have done a more accurate job for a small area than what the government 
> authority was publishing at the time. However due to the fast changing nature 
> of it and temporary nature of the active front, I don't think it's worth 
> mapping.

I agree with you those data are of a “more ephemeral” nature and so are much 
less useful to include in the map.

> For burnt areas and recovery progress, sure this is not temporary (could be a 
> few months to years for evidence on the ground) and it's not fast changing, 
> once an area is burnt it stays burnt. So yeah you could map it, but from my 
> experience in Australia this again wouldn't be worth it (not saying that you 
> shouldn't map it, the way isn't really harmful and I'm not local, so not 
> telling you what to do). The main reason here is that the burn isn't uniform, 
> patches are noticeably burnt to a higher degree than others and some patches 
> might be unaffected, and it can be hard to survey this. It's also hard to 
> know when to remove it from OSM, because after all  OSM doesn't contain 
> historical features which aren't found on the ground anymore, so at some 
> point OpenHistoricalMap becomes more appropriate.

I saw someone say “six to seven years” (as what might pass for “recovery” to a 
large degree) to have “taken root” and after living most of my life here, that 
sounds about right.  This length of time is similar for human structures 
(houses, barns…) as well as (the beginning of) the natural world to have begun 
to bounce back.  (Here, insurance, permits, construction, re-population can and 
do take years).  However, do know that this area's redwood trees can be a 
thousand years old (rare, but we have those).  Summer 2008 I hiked a couple 
hours drive south of here (Big Sur, Ventana Wilderness…) after a major fire and 
even when trails re-opened only nine or ten weeks after the burn and most of it 
looked like a moonscape, I saw the literal “green shoots” beginning to sprout, 
starting the growth cycle anew.  (I have pictures!). After six, eight, ten 
years, it begins to look “more like it once did,” but no sooner.

> Satellites do a pretty good job of finding out which areas burned and to what 
> degree, so I'm happy mostly to just rely on rasters from satellite instead of 
> hand traced and vectors in OSM.

The latter define the bounds of the former, as the former become available.  
And not just for tracing / better mapping with newer imagery (as above), but 
for “map data consumers” (hikers…) alike (as above).

Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-30 Thread stevea
It appears somewhat-established (in this thread) that data consumers both DO 
and WILL find a datum of a polygon tagged fire=perimeter to be useful.  This 
might be for "remap HERE when newer imagery becomes available" purposes (to a 
mapper in the area like me), to "might want to avoid hiking in this area as 
some roads / trails may remain or be closed, and it can be quite dangerous with 
"stump-slump" causing trail failures / slippages..." purposes (to a hiker in 
the area like me).  Not to mention other reasons / purposes cited here.

I'll say it once again:  such a fire=perimeter IS a real-world "thing," 
represented in OSM by a lightweight datum that I find to be "worth it" to be in 
the map.  It serves both better-near-future-mapping purposes as well as 
end-user / map consumer purposes.  I find that "balance" (storage cost in the 
database, whether such a datum should or shouldn't be "in the map at all," its 
usefulness to diverse OSM audiences for various, useful purposes...) to have 
value, even significance (though I'm local, so I'll grant I'm biased).  It 
seems others find similar value, too and agree that "sharing" such data, as OSM 
does, is both valid and valuable (to some) data to map.

After all, we don't want to "hold back people from using (such data) in 
creative, productive, or unexpected ways," do we?

Thanks for great feedback here,
Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-27 Thread stevea
On Sep 27, 2020, at 12:43 PM, Peter Elderson  wrote:
> Clifford Snow :
> I'm not sure there would be a consensus agreement to revise the wiki to 
> indicate landuse=forest should be used for timber production.  Thoughts?
> I am sure there would not. landuse=forest just means the area has trees. I 
> think there is some consensus about that. 
> natural=forest: same.
> The idea that natural=wood is for natural woods and landuse=forest is for 
> managed forests has too little practical support.

Peter offers this with no evidence, so I question its validity.  Furthermore, I 
offer that something like Approach 3 or Approach 1 (from our has been used by me in North America since 
2009 (and I am not the only one; I collaborate with other OSM Contributors on 
"good use of OSM tagging in wooded areas" in areas I map so we avoid conflict 
and harmonize on our use of tags).  So, "too little practical support" simply 
isn't true:  I and my mapping activities (along with others) simply contradict 
this assertion.  We have been contradicting this assertion for many, many years.

> Since there is no consensus about other aspects than "there are trees", data 
> users and renderers will stick to this.

Here, Peter predicts the future after reaching the false conclusion that "there 
is no consensus about other aspects."  There is slow, emerging consensus that 
landuse=forest, natural=wood, landcover=trees, key managed=* with values yes or 
no... most certainly need much work, but "what exactly OSM should or will do" 
is a long way from having consensus established.  We have absolutely no 
predictability about what data users and renderers will "stick to," let's not 
kid ourselves.

I repeat myself, but what can be said is that trees, woods, forests and how we 
tag them need a lot of work if OSM is going to comprehensively capture the very 
wide semantics about these in the real, global world with a finite set of tags 
to capture these semantics.  We'd do well to improve these, but I'll agree with 
anybody who says "this is difficult work."

Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-27 Thread stevea
On Sep 27, 2020, at 12:51 AM, Mateusz Konieczny via Tagging 
> I am a bit dubious about value of updating fire=perimeter

It isn't anticipated to be "updated."  It is a static boundary where "inside of 
this polygon, there might be burned / destroyed landcover (and perhaps some 
buildings, if they are / were there), outside of this polygon, there is / was 
no fire."

> It is something that changes extremely quickly, we should
> not encourage people to survey perimeter of ACTIVE fire,
> OSM is doomed to be strictly worse source of fire perimeter
> than alternative sources

I'm not surveying this (though I would like to, many areas are inaccessible or 
dangerous).  I'm saying the polygon tagged fire=permiter is a useful data 
structure in the map to delineate where the bounds (perimeter) of a fire was 
(now it is "was," for a while it was "is").  So, use ground truth, 
personally-gathered sources, satellite data... to better characterize that what 
was once there (landcover in the form of trees and scrub, largely) is quite 
likely no longer there.  So, "map this area better."

> Obviously, we should (try to) update map where situation changed.

Maybe it wasn't obvious from my posts about this, yes.  This is the whole 
reason for entering these data.

> Delete building that will not be rebuild (mark them as destroyed:building=*
> until aerial imagery will update)
> [deleting buildings and remapping them as they get reconstructed may
> be viable in cases of heavy mapper presence]
> Delete other permanently destroyed objects and so on.

It is still too early to make final determinations of buildings:  some people 
who lost homes to fire will rebuild, some will not.

> > Do we have landcover tags which could replace landuse=forest
> or natural=wood with something like natural=fire_scarred?
> AFAIK nothing established, see
> for related discussion about wind damage.

Thank you, that is interesting and relevant!  So, preliminary results are that 
such tagging is rare, but it does happen.

Tagging mailing list

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

2020-09-27 Thread stevea
On Sep 27, 2020, at 12:45 AM, Mateusz Konieczny via Tagging 
> landuse=forest is used to tag tree covered area, not for how land is used
> It is also basically universally interpreted this way by various data 
> consumers.

Mateusz, I do not disagree with you to simply disagree:  landuse=forest is not 
"basically universally interpreted this way."  Rather, I ask you to look at which says there are at least a half-dozen 
(six, 6) different approaches taken by OSM mappers using the landuse=forestry 
and natural=wood tags.

"Around here" (in California, USA, where I map and tag forests and wooded 
areas), we use something much like Approach 3, except it isn't strictly true we 
view "most woodland as managed or maintained."  Rather, we view "woodland as 
managed or maintained" when we know it is both "zoned" for Timber Production 
and there is an active "logging permit" that has been legally approved, or 
"forestry action" taking place:  trees being felled, logs being taken away via 
sluice, truck or other method, replanting, etc.

"Around here" (and by contrast to landuse=forestry), we do use the natural=wood 
tag for "predominantly wooded areas where there is no active logging" or 
logging is known to not be permitted.

Tagging mailing list

Re: [Tagging] Large fire perimeter tagging?

2020-09-24 Thread stevea
I very much appreciate your reply, Rob; thanks.

Tagging mailing list

Re: [Tagging] Large fire perimeter tagging?

2020-09-24 Thread stevea
On Sep 24, 2020, at 3:05 PM, Clifford Snow  wrote:
> Just a reminder, landuse is to tag what the land is used for. landuse=forest 
> is for areas that have harvestable wood products, ie trees. Just because 
> there was a fire doesn't mean the landuse changes. Landcover is a better tag 
> for burnt areas as well as areas just clearcut.

Thank you, Clifford.  It wasn't my intention to change any landuse tags, though 
I was in listening mode in case that might be suggested — for example, in the 
case of entire rural neighborhoods which might have zero or few houses 
remaining because they all or largely burned down and so are no longer 
residential.  However I do anticipate there being land COVER tag changes, and 
substantially.  Here (there are at least a half-dozen recommended ways to tag 
these in our wiki), we tag landuse=forest on areas which are both dedicated to 
"forestry" or "timber production" and have valid logging permits and we tag 
natural=wood on areas which are substantially or exclusively tree-covered, but 
about which "timber production" it is either unknown or known to not be 
allowed.  (It's a relatively rough distinction, but works fairly well here).

I anticipate that landuse=forest will either change not at all or in very minor 
cases where forestry production ends up being "forfeited" as that particular 
productive use of the land.  (That would take zoning changes, timber permit 
revocations or surrender, lots of public meetings, etc. and therefore many 
years, at least around here).  I anticipate that natural=wood, natural=scrub 
and similar tags will substantially change, and as Joseph just suggested, is 
well-established by "fresh" imagery where the extent of this should likely be 
apparent.  The boundary=tagged fire=perimeter remains useful in the meantime 
(years) to delineate the extent of any necessary land cover mapping OSM would 
likely require.

Thanks for answers so far!  I'll go back to the January Australian fire threads 
people are pointing me to and take a look at any other specifics I might glean. 
 I do respect that there are some who say "don't map these at all," but I do 
find the perimeter useful to describe the extent of what is a substantial 
change to land cover (and in some cases, such as fully abandoned homes and 
residential areas where re-population / re-building will NOT take place, 
landuse as well).

It's wonderful to be able to ask and receive answers here (thank you),
Tagging mailing list

Re: [Tagging] Large fire perimeter tagging?

2020-09-24 Thread stevea
On Sep 24, 2020, at 2:53 PM, Joseph Eisenberg  
> Most large wildfires do not burn the canopy (the tallest trees) in forests 
> with trees over 10 meters in height.

Noted, thank you.

> The perimeter of the wildfire, shown commonly on public maps, does not 
> determine which areas have been burned. Often there are large areas of 
> vegetation along canyon bottoms and streambeds which are unburned, within the 
> perimeter.

Something I already DID know, also noted, thank you.

> You will need new aerial imagery or detailed on-the-ground survey to 
> determine the surviving areas of vegetation.

Something I have anticipated (apparently correctly), yet which isn't available 
now (though I assume will be, in the regular course of imagery being updated), 
so also noted, thank you.

> I would not recommend attempting to map the current official perimeter of the 
> fire, since this changes on a daily or hourly basis: it is a temporary event 
> which is not really verifiable from the standpoint of an OpenStreetMap 
> volunteer mapper.

It isn't anticipated, it was completed about a month ago, containing only two 
versions, creation with start_date and one a couple days ago to add the 
end_date tag.  It is a lightweight data structure:  one polygon with three 
tags.  I don't intend to delete it, as it marks a distinct boundary in the real 
world regarding real world components (like landuse and land cover) that OSM 
already maps — indeed which OSM already 100% maps in the area noted —yet these 
(existing landuse and land cover) polygons may have their nature / character 
quite substantially altered from the fire.

The event WAS temporary (and determinable from start_date and end_date keys), 
the aftermath will indisputably last years, perhaps decades.  OSM will be 
mapping in the area during the meantime.

> Database users who need these perimeters should download the latest version 
> from the official sources. 

Yes, AND OSM users who map in areas affected by the fire want (likely need) 
fire perimeter data to delineate where substantial "re-mapping" almost 
certainly must take place.

Thank you for your quick reply!


Tagging mailing list

Re: [Tagging] Large fire perimeter tagging?

2020-09-24 Thread stevea
I didn't get a single reply on this (see below), which I find surprising, 
especially as there are currently even larger fires that are more widespread 
all across the Western United States.

I now ask if there are additional, appropriate polygons with tags I'm not 
familiar with regarding landcover that might be added to the map (as 
"landuse=forest" might be strictly true now only in a 'zoning' sense, as many 
of the actual trees that MAKE these forests have sadly burned down, or 
substantially so).

Considering that there are literally millions and millions of acres of (newly) 
burned areas (forest, scrub, grassland, residential, commercial, industrial, 
public, private...), I'm surprised that OSM doesn't have some well-pondered and 
actual tags that reflect this situation.  My initial tagging of this (simply 
tagged, but enormous) polygon as "fire=perimeter" was coined on my part, but as 
I search wiki, taginfo and Overpass Turbo queries for similar data in the map, 
I come up empty.

First, do others think it is important that we map these?  I say yes, as this 
fire has absolutely enormous impact to what we do and might map here, both 
present and future.  The aftermath of this fire (>85,000 acres this fire alone) 
will last for decades, and for OSM to not reflect this in the map (somehow, 
better bolstered than a simple, though huge, polygon tagged with 
fire=perimeter, start_date and end_date) seems OSM "cartographically misses 
something."  I know that HOT mappers map the "present- and aftermath-" of 
humanitarian disasters, I've HOT-participated myself.  So, considering the 
thousands of structures that burned (most of them homes), tens of thousands of 
acres which are burn-scarred and distinctly different than their landcover, 
millions of trees (yes, really) and even landuse is now currently tagged, I 
look for guidance — beyond the simple tag of fire=perimeter on a large polygon.

Second, if we do choose to "better" map these incidents and results (they are 
life- and planet-altering on a grand scale) how might we choose to do that?  Do 
we have landcover tags which could replace landuse=forest or natural=wood with 
something like natural=fire_scarred?  (I'm making that up, but it or something 
like it could work).  How and when might we replace these with something less 
severe?  On the other hand, if it isn't appropriate that we map any of this, 
please say so.

Thank you, especially any guidance offered from HOT contributors who have 
worked on post-fire humanitarian disasters,

California (who has returned home after evacuation, relatively safe now that 
this fire is 100% contained)

On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> Not sure if crossposting to talk-us is correct, but it is a "home list" for 
> me.
> I've created a large fire perimeter in OSM from public sources, 
> .  This is a huge fire (sadly, there are 
> larger ones right now, too), over 130 square miles, and caused the evacuation 
> of every third person in my county (yes).  There are hundreds, perhaps 
> thousands of structures, mostly residential homes, which have burned down and 
> the event has "completely changed" giant redwoods in and the character of 
> California's oldest state park (Big Basin).
> This perimeter significantly affects landuse, landcover and human patterns of 
> movement and activity in this part of the world for a significant time to 
> come.  It is a "major disaster."  I'm curious how HOT teams might delineate 
> such a thing (and I've participated in a HOT fire team, mapping barns, water 
> sources for helicopter dips and other human structures during a large fire 
> near me), I've simply made a polygon tagged fire=perimeter, a name=* tag and 
> a start_date.  I don't expect rendering, it's meant to be an "up to right 
> about here" (inside the polygon is/was a burning fire, outside was no fire).  
> I wouldn't say it is more accurate than 20 to 50 meters on any edge, an 
> "across a wide street" distance to be "off" is OK with me, considering this 
> fire's size, but if a slight skew jiggles the whole thing into place better, 
> feel free to nudge.  It's the tagging I'm interested in getting right, and 
> perhaps wondering if or even that people enter gigantic fires that will 
> significantly change landscape for some time into OSM, as I have done.  This 
> will affect my local mapping, as a great much has burned.  Even after 
> starting almost two weeks ago, as of 20 minutes ago this fire is 33% 
> contained, with good, steady progress.  These men and women are heroes.
> To me, this is a significant polygon in my local mapping:  it is a "huge 
> thing" that is a major feature on a map, especially right now.  I firmly 
> b