You’re referring to the Scrub From Hell.

I (user SJFriedl) have been mapping extensively in Orange County and 
(especially) in the Santa Ana Mountains and this thing is *everywhere*. Not 
patches here and there, but everything everywhere is part of one enormous scrub 
relation and it’s positively maddening.

Even if you’re not trying to fix the big problem you’re describing, just 
cleaning up a boundary somewhere by adding a few nodes runs over the limit for 
a way (6k-ish?) and *boom* now you have to deal with the big picture. Ugh.

At the time I was most interested/frustrated in this, I didn’t have nearly 
enough chops with relations to give it a go, but after I fully relationalized 
all the city boundaries in Orange County, I’m game. JOSM is great.

You’re right that splitting this up is the right approach, because I don’t 
believe having all this as one huge relation was every the right thing to do as 
I cannot see how the related-ness of all the scrub patches in a very wide area 
is useful information (the scrubs that are part of the relation are not any 
more “related” than standalone patches of scrub in the same area).

There for sure are legitimate agricultural lands in OC, but they’re mainly in 
the foothills of the mountains; I’d not expect to see much grazing in (say) 
Ladera Ranch.

I’m glad I’m not the only one who’s noticed this :-)

Steve – who lives in Tustin

--- 
Stephen J Friedl  | Security Consultant | UNIX Wizard | 714 345-4571
[email protected] | Southern California | Windows Guy | unixwiz.net





From: David Kewley [mailto:[email protected]] 
Sent: Sunday, August 13, 2017 1:12 PM
To: OpenStreetMap talk-us list <[email protected]>
Subject: [Talk-us] natural=* and landuse=* multipolygons at the urban interface

Development in Orange County, California pushes into areas currently covered by 
polygons (often large multipolygons) tagged as natural=scrub, landuse=meadow, 
or landuse=[farm|farmland]. These were part of the FMMP import 
http://wiki.openstreetmap.org/wiki/California_Farms.

Mostly I try to leave those large multipologons alone, because I don't feel 
confident I can handle them properly, and because I'm using iD (due to using a 
Chromebook), where relation handling is rudimentary.

But I'd like to update the urban-wildland boundary, where new suburban 
developments are pushing into former wildland, farmland, or (historical?) 
"grazing land". See for example the new development (with 2017 imagery recently 
added to Bing) at 
http://www.openstreetmap.org/edit?editor=id#map=16/33.5352/-117.6034.

Editing these huge multipolygons, and reviewing others' edits to them, becomes 
very cumbersome, at least to me. It seems to me probably sensible and 
reasonable at the urban edge to split off small parts of these multipolygons, 
e.g. at roads, to make the smaller bits easier to edit and review in the 
context of the expanding urban edge.


As one test / demonstration edit 
(http://www.openstreetmap.org/changeset/51090963), I carved off a bit of 
natural=scrub from a large outer role of a multipolygon, into its own polygon. 
I manually added new boundary way segments, stitched them together into the 
existing ways, copied tags, and made the split-off piece its own polygon, 
independent of its original parent multipolygon. I did the split at an existing 
highway=residential object (Golden Ridge Lane).

I know, I should find a way to use JOSM, which I expect makes this much easier. 
:)

Meanwhile, does this seem a reasonable approach to making the urban interface a 
bit more manageable in the future? I.e. splitting off parts of large 
multipolygons (so long as they don't have names or other unique identifiers 
that matter, just generic tags things like natural=scrub), to make future 
editing easier?

I know for the above example of a new residential area, I could make a 
landuse=residential island, and make it an inner role in the surrounding 
landuse=meadow multipolygon. But at some point as the urban sprawl expands, it 
seems to me it makes more sense to stop pretending the area is dominated by the 
natural features, and make it clear it's dominated by e.g. landuse=residential, 
with possibly interspersed natural features like scrub.


What would the group suggest?

Is my test edit reasonable, or should it be reverted?

Thanks,
David


P.S. As an aside (not my main point today), the FMMP-based distinction in this 
area between scrub and meadow seems awfully arbitrary. I could be mistaken, but 
I don't believe the "meadow" is actually used today for grazing nor feed 
harvesting, and in the aerial photography, it appears indistinguishable from 
the adjacent "scrub". It appears (and I'm nearly certain from driving by) that 
there's both substantial grass and substantial woody plant cover, in similar 
ratios in both "meadow" and "scrub".

I don't believe there's any current agricultural use of that land, at least not 
near where I'm giving examples today. There might be some large-acreage, 
semi-wildland grazing or feed harvesting activity remaining in Orange County, 
but I've not noticed any.

As documented in the FMMP wiki page 
http://wiki.openstreetmap.org/wiki/California_Farms, the FMMP designation 
"Grazing Land" was mapped to landuse=meadow.

But the FMMP designation of "Grazing Land" explicitly does not mean that there 
*is* grazing activity there, just that it is "...land on which the existing 
vegetation, whether grown naturally or through management, is suitable for 
grazing or browsing of livestock." (See for example 
http://www.conservation.ca.gov/dlrp/fmmp/Documents/soil_criteria.pdf.) So 
wildlands that will never again see livestock, or harvesting for livestock 
feed, can still be designated Grazing Land by FMMP. Those areas map better to 
natural=grassland or natural=scrub, I think.

So landuse=meadow seems less useful than natural=scrub or natural=grassland for 
many of these areas. Even though this is a secondary point today, I'd welcome 
comments on this as well.


_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us

Reply via email to