Re: [Talk-us] While we're fixing things in iterations

[Ian Dees]

Hi everyone on this thread. It seems conversation has gotten way off topic
and heated, so I put a moderation hold on the list and won't let this
thread through for 24 hours or so.

Thanks,
Ian
talk-us moderator
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[stevea]

James Umbanhowar  wrote:
> Something else to consider is that even though there is a perimeter for
> a fire, there can be highly variable impacts on the landcover within
> the perimeter.
> Some areas may have not burned, other areas only burned
> the understory, some with limited burning of trees and other with full
> tree killing canopy burns.  The effects of these will also depend on
> the specific species that burn.  So to convert and entire area inside a
> fire perimeter to one land cover without extensive surveying would
> likely be in error.  

(Please take further discussion of this thread to the tagging list
https://lists.osm.org/pipermail/tagging/2020-September/055496.html ).

James, this is all well known and part of the intended solution (to better map) 
here, thank you for pointing this out.

There is no intention to "convert an entire area" inside of the fire perimeter, 
rather careful RE-mapping of SELECTED areas which have ACTUALLY burned (e.g. a 
natural=wood area is shrunk to where trees remain and "no data" or "blank map" 
is what remains of the burned area).  This will likely best emerge when newer 
imagery data become available.

> It seems as though the perimeter tag is the most verifiable at this point.

Yes, to be clear:  this fire=perimeter polygon intends to delineate the area 
where, as they become available, newer imagery data which display fire damage 
should be used to update the map.  In short, the polygon conveys "here is the 
EXTENT of the area that burned:  while it isn't yet clear whether existing 
landcover natural=* tags need to be altered, that is likely, as there was a 
major fire inside of these bounds."  That's all, really.  This is a 140 square 
mile rural area, formerly heavily/primarily wooded, not a few blocks of 
residential or commercial landuse, as are many typical urban fires.  "Huge" is 
about right.

At least one person (a HOT technical manager, also a firefighter) said (on the 
tagging thread and in off-list emails to me) that such polygons can serve a 
historical purpose by remaining in OSM, though I see little purpose in doing so 
for extended periods of time, believing that after the map is updated with 
newer imagery, the polygon's (initial) purpose is exhausted and can be removed 
from OSM.  His arguments for why it should remain have to do with better 
building polygons enclosed by the perimeter during HOT re-mapping and into the 
re-population and re-building phases in landuse=residential areas that happen 
after a major fire.  As a firefighter (and HOT mapper), he finds such data 
helpful, as in that case, a fire=perimeter polygon remaining is valuable 
history.  That could last years, perhaps decades, I'm certain the effects of 
this fire will be long-lasting:  many of the millions of trees that were 
destroyed were several hundred years old.

Either way (the polygon is long-lasting or ephemeral to the extent it aids 
better landcover mapping), it is a lightweight data structure, tagged with only 
three tags (fire=perimeter, start_date and end_date), it remains invisible to 
all renderers (that I know of) and is intended to aid mappers determining 
"should re-mapping of landcover happen HERE, in or out?"  I find that balance 
of data vs. usefulness "worth it."

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Fri, Sep 25, 2020 at 11:49 AM Volker Schmidt  wrote:

> (this comment is only regardinbg the "lanes" part of the thread)
>
> Date: Thu, 24 Sep 2020 09:30:15 -0500
>> From: Paul Johnson 
>> To: OpenStreetMap talk-us list 
>> Subject: Re: [Talk-us] While we're fixing things in iterations
>>
>
>
>> > > Can we finally fix two other longstanding problems, then?
>> > >
>> > > 1. The wiki being incorrect about not counting bicycle lanes.
>
> The wiki is correctly reflecting the practice in many places, for example
> in Italy. Almost all users here count the car lanes and not bicycle, foot,
> combined foot-cycle lanes.
> If there are different  approaches prevalent in other places, then at
> worst the wiki is incomplete by not listing diverging approaches.
>
>> > >That's
>> > > not reflective of how validators deal with lanes, how data consumers
>> > > like Osmand or Magic Earth deal with lanes,
>
> Can you point more precisely where Osmand and Magic Earth differ from the
> wiki.
>

They actually treat all lanes as lanes when all lanes are mapped.  They're
automatically providing incorrect lane guidance when tagged to the wiki, as
the wiki specifically asks people to omit lanes.


> or how ground truth works.
>>
> Ground truth depends on how you define lanes.
> If you count bike lanes this
>  is a 4-lane
> road, if not it's a two-lane road.
>

It's a 4 lane road.  That's how lanes works in the real world.


> > > The whole "but you can't fit a motor vehicle down it" argument is
>> > > facile, that's what access:lanes=* and width:lanes=* is for.
>>
> In this argument you forget that hundreds of thousends of roads have been
> inserted in the OSM database using the wiki definition.
>

Just because it's time consuming to fix doesn't mean we shouldn't bother
fixing it.  Or we'd have just thrown in the towel after the OBDL
relicensing.


> > I agree that width is a poor argument for the status quo, especially
>> > given the common practice (in California, anyways) of bike lanes that
>> > double as right turn lanes for cars.
>>
> As far as I know (rom riding a lot ib California, we are not talking about
> bike lanes, but, at best, about shared lanes.
> Example: bike lane
>  disappers, and 
> becomes
> (unsigned) shared lane
> .
>

It didn't disappear so much as it became motor_vehicle=yes.  Probably a
good situation where mode:turn:lanes (ie, bicycle:turn:lanes,
motor_vehicle:turn:lanes) may need to come into existence.

> Apparently some mappers
>> > only count through lanes but exclude turn lanes.
>>
> That seems fine to me especially if the turn lanes are short (ike  in the
> above example in LA.
>

Except this breaks data consumers from being able to provide accurate lane
guidance.


> The editor won't solve the problem of existing mapping.
>

Maproulette can help organize fixing this.


> Hopefully when id gets
>> lane tools, it does the same thing JOSM does in this regard.
>>
>
>
>> > I'm pretty sure existing routers would have no problem with including
>> > bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
>> > are both present. So I think a reasonable migration path would be to use
>> > the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
>> > non-auto-centric approach you're advocating.
>>
>
> There is no migration path. I would, from my European perspective at
> least, stick with the present usage and not count any bike/pedestrian
> lane/horse lanes.
>
> The number of lanes is a rough indication for the capacity for motor
> vehicles of a road.
>

"Fuck accuracy, fuck ground truth" --you.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Volker Schmidt]

(this comment is only regardinbg the "lanes" part of the thread)

Date: Thu, 24 Sep 2020 09:30:15 -0500
> From: Paul Johnson 
> To: OpenStreetMap talk-us list 
> Subject: Re: [Talk-us] While we're fixing things in iterations
>


> > > Can we finally fix two other longstanding problems, then?
> > >
> > > 1. The wiki being incorrect about not counting bicycle lanes.

The wiki is correctly reflecting the practice in many places, for example
in Italy. Almost all users here count the car lanes and not bicycle, foot,
combined foot-cycle lanes.
If there are different  approaches prevalent in other places, then at worst
the wiki is incomplete by not listing diverging approaches.

> > >That's
> > > not reflective of how validators deal with lanes, how data consumers
> > > like Osmand or Magic Earth deal with lanes,

Can you point more precisely where Osmand and Magic Earth differ from the
wiki.

or how ground truth works.
>
Ground truth depends on how you define lanes.
If you count bike lanes this
 is a 4-lane road,
if not it's a two-lane road.

> > The whole "but you can't fit a motor vehicle down it" argument is
> > > facile, that's what access:lanes=* and width:lanes=* is for.
>
In this argument you forget that hundreds of thousends of roads have been
inserted in the OSM database using the wiki definition.

> I agree that width is a poor argument for the status quo, especially
> > given the common practice (in California, anyways) of bike lanes that
> > double as right turn lanes for cars.
>
As far as I know (rom riding a lot ib California, we are not talking about
bike lanes, but, at best, about shared lanes.
Example: bike lane 
disappers, and becomes (unsigned) shared lane
.

> For what it's worth, the lanes=* documentation has long included a
> > passage recommending that data consumers treat lanes=* as a minimum
> > value rather than a reliable exact lane count.

Yes but that statement " Many ways have not yet been tagged with the total
number of lanes at all points, but only with the number of through lanes of
a longer section. Therefore, data consumers can mostly treat the lanes tag
as a minimum rather than an exact number." refers specifically to turn
lanes and similar situations.

> Apparently some mappers
> > only count through lanes but exclude turn lanes.
>
That seems fine to me especially if the turn lanes are short (ike  in the
above example in LA.

>
> Fortunately, editors will automatically fix this and make lanes=* be the
> total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*,

I think JOSM only complains in case of a n odd numberof lanes. and missing
forward/backaward counts


> so this
> is something that isn't hard to solve long term.


The editor won't solve the problem of existing mapping.

Hopefully when id gets
> lane tools, it does the same thing JOSM does in this regard.
>


> > I'm pretty sure existing routers would have no problem with including
> > bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
> > are both present. So I think a reasonable migration path would be to use
> > the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
> > non-auto-centric approach you're advocating.
>

There is no migration path. I would, from my European perspective at least,
stick with the present usage and not count any bike/pedestrian lane/horse
lanes.

The number of lanes is a rough indication for the capacity for motor
vehicles of a road.
If you want to be more precise you can use the second version of the lanes
key as described in this separate wiki page
.

Volker
Italy, Europe




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[James Umbanhowar]

Something else to consider is that even though there is a perimeter for
a fire, there can be highly variable impacts on the landcover within
the perimeter.  Some areas may have not burned, other areas only burned
the understory, some with limited burning of trees and other with full
tree killing canopy burns.  The effects of these will also depend on
the specific species that burn.  So to convert and entire area inside a
fire perimeter to one land cover without extensive surveying would
likely be in error.  

It seems as though the perimeter tag is the most verifiable at this
point.

James

On Thu, 2020-09-24 at 15:05 -0700, Clifford Snow wrote:
> Steve,
> 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. 
> 
> 
> 
> On Thu, Sep 24, 2020 at 2:31 PM stevea 
> wrote:
> > 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,
> > 
> > SteveA
> > 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, 
> > http://www.osm.org/way/842280873 .  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 

Re: [Talk-us] Talk-us Digest, Vol 154, Issue 30

[Michael Patrick]

> Brian says that a common (THE common) definition of "suburb" in the US is
(roughly) "a smaller city next to or near a much larger one as part of a
conurbation."  I agree that is a very frequent understanding of how the
word "suburb" is both used and understood in the USA, even most or almost
all of the time.

 (In the USA, we tend to CALL someplace like Bellevue a "suburb,"
> though we correctly TAG it a place=city in OSM.  Such differences between
> "call" and "tag" are the source of much of the confusion about "suburb" and
> "neighborhood" or place=neighbourhood).
>

'Suburbs' originated in the USA, created by the intersection of the
post-war baby boom, GI Bill, affordable automobiles, freeway construction,
and urban decline. And specifically, they are not part of a larger city. It
may be part of a larger metropolitan / micropolitan area and/or and
government / service, but the genesis of the 'burbs' was the white flight
by people specifically fed up with corrupt major cities and the collapse of
services, and so a separate city administrative structure, including
taxation. These days, many of those 'sub'-urbanizations are actually larger
or the same size as the original city, like Bellevue / Seattle. These are
now known as 'Edge Cities'  https://en.wikipedia.org/wiki/Edge_city
Beyond the Edge Cities are the 'Exurbs', sometimes unincorporated areas.
There are still some cities that fit the past suburb definition, 'Bedroom
Communities' like Mountlake Terrace where the residents primarily commute
outside their city limits, but many of those trips aren't even into the
major city ( Seattle) but to other suburbs and urban centers ( hence the
Census defining metropolitan statistical areas, and such ).
Suburb should probably be deprecated as a tag, it sort of an anachronism.
Magnolia has never been a 'suburb', I've walked from downtown to Magnolia,
if it is a suburb, then the University District and Ballard are too, they
popped up during the streetcar / Interurban build out. (
https://historylink.org/File/2667 )




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us