Re: [Talk-us] natural=* and landuse=* multipolygons at the urban interface

[OSM Volunteer stevea]

David, I would contact Nathan Mixter directly (in OSM, nmixter, import account 
Eureka gold) and ask him what he thinks, as he is (largely speaking) the 
original importer of these (and many other, very large) imports, many of which, 
unfortunately generated consternation or reversion.  You might ask him what his 
plans are to "upkeep" the data he has imported.

Nathan is a friend of mine I met in OSM (on a personal and "let's go 
hiking/camping/backpacking together" level) and I have helped him on both 
improving the Santa Cruz County (my home) and Monterey County (next door to 
both of us) landuse imports that he initiated.  Together, we did the 
single-county FMMP import of Monterey County (only, I didn't help with other 
counties) over many months (instead of the days Nathan thought it might take) 
as I wanted to convey the care, vetting, quality assurance and teamwork that 
such an endeavor truly requires to get it right (or much closer to right, as I 
still think Monterey County's landuse from this import is "pretty good," if I 
say so myself).  I/we documented what we did if you click around the links in 
our wiki, already introduced in this thread.

In short, these landuse polygons are indeed very large, unwieldy or virtually 
"just kill me now" highly difficult to edit using iD (PLEASE use JOSM to edit 
complex polygons like these!).  I declare that they aren't anything "sacred," 
especially as new human urban development simply outdates more and more edges 
of these data as obsolete.  Subtle differences between scrub and meadow, while 
I admire your diligence in determining "what is best" for a given area, are not 
hard-and-firm.  I'd characterize these FMMP imports as "2010-12 data, roughly 
applied to OSM to avoid large blank areas in California" (except Monterey 
County, were I was very careful to apply the lipstick carefully so there was no 
piggy ugliness about it).  So, should these FMMP import (multi)polygons need to 
be changed, edited, modernized and especially trimmed down to more manageable 
size, please, get a read from Nathan if you can, then take the controls of JOSM 
firmly in your hands and go for it!  Especially as those bulldozers build those 
suburbs.

Nathan, you might please chime in either on-list or via email to this distro; 
thank you.  If you wish, I additionally invite anybody to contact me off-list 
to ask about this topic should you care to know further details, though Nathan 
is the primary importer of these data.

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

Re: [Talk-us] natural=* and landuse=* multipolygons at the urban interface

[Steve Friedl]

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
st...@unixwiz.net | Southern California | Windows Guy | unixwiz.net





From: David Kewley [mailto:david.t.kew...@gmail.com] 
Sent: Sunday, August 13, 2017 1:12 PM
To: OpenStreetMap talk-us list 
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 

Re: [Talk-us] natural=* and landuse=* multipolygons at the urban interface

[Rihards]

On 2017.08.13. 23:11, David Kewley wrote:
> 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?

looks very reasonable. you have added the split-off piece as a separate
way, not multipolygon, which makes it easier to handle.

nitpicking - i would disconnect it from the road here :)
http://osm.org/go/TPVmeC512?m=

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

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

[Talk-us] natural=* and landuse=* multipolygons at the urban interface

[David Kewley]

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
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] anyone know what software is generating these Q/A Notes?

[Andy Townsend]

On 12/08/2017 00:45, Rihards wrote:

seems to be streetcomplete, although i thought it edited osm data


I did try and discuss this sort of problem with the author over at 
https://github.com/westnordost/StreetComplete/issues/351 - specifically 
to say that someone running StreetComplete should be allowed to say that 
"everything is OK in OSM as it currently is, no need to edit the data or 
add a note".  Unfortunately communication failed to occur, and the 
author of this app is committed to adding useless notes to OSM.


I don't doubt that the author's heart is in the right place and that 
they, and the app's users, are genuinely attempting to improve the 
quality of OSM data, but unfortunately their actions together will 
dilute the "useful" notes in an area.  Just look at the (lack of) 
quality of 
http://api.openstreetmap.org/api/0.6/notes/search?q=Streetcomplete=0 
for examples.


Best Regards,

Andy



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

[Talk-us] Whole-US Garmin Map update - 2017-08-11

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-11

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-11/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-11

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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