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

[Nathan Mixter]

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
examplehttp://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.


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Aug 13, 2017 at 9:29 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> 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] Available Building Footprints

[Nathan Mixter]

Steve, I'm not sure how or why you are jumping to the conclusion that
because a wiki page was created that somehow means the import has already
occurred. Your impulsive reaction and rants are unwarranted and
unappreciated. No one has said anything about importing other than raising
the possibility.

The page was created by another user who was listing the data sets
available. I simply added another section on the page to break apart the
California areas into cities so they can be reviewed further. The page
clearly states that the import procedures need to be followed and I don't
have any plans to import the data now and I don't think anyone else does
either.

Denis was right on with his response, and those are the type or responses
that we need if ... and I do say if ... this project is to move forward.
There are several hurdles in using this data, one being the size and scope.
That is why the wiki page was created was to hash out the best way to
proceed from people who have successfully done large scale imports. The
data can't be reviewed effectively as one big file. The project is still
young, and before we can even post on the imports list we need to have a
procedure in place.

Let's continue to pool resources and add ideas and suggestions to the wiki
page as we look into the possibility of importing this data. Looking
forward to hearing what others have to say and the ideas we can come up
with together.

Nathan

On Tue, Mar 28, 2017 at 9:23 AM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> I couldn't agree more, Denis.  The only thing that this (poorly
> named/indexed in OSM's wiki) "Available Building Footprints" page mentions
> about importing is "Any import of these building footprints must strictly
> follow the import guidelines."  Well, then, please do so!  I'm not saying
> that this built-in-the-last-week wiki isn't informative, for what it is, it
> is.  However, it is not an import project (yet), and while Nathan implies
> these data (data are plural) SHOULD be imported, he has not taken the time
> nor effort to correctly turn these into a real import project (posting to
> the imports list, following our "five steps...").
>
> Nathan just emailed me to say that he couldn't open the Bay Area shapefile
> either, saying he split it apart with QGIS.  He continues "Even though I
> split the file into different areas that file still seems to be the same
> size as the original. It's almost like the other data is still there even
> though it shows only the Bay Area shapes. Maybe some one else has a better
> way to split up the file. The Bay Area data all runs together so it is hard
> to see where natural splits occur. Maybe you (stevea) or some one else will
> have better luck trying to split it."  This does not bode well for someone
> who wants to lead or contribute to an import.  (Nathan, Nathan, Nathan...).
>
> Nathan and I have become friends, we met eight years ago in OSM, go on
> many hikes and camping trips together, he comes to my house parties and we
> further collaborate via email.  I have worked with Nathan on numerous
> import tasks, noted in our Santa Cruz County wiki page, including the major
> (now in version 3) import of Santa Cruz County landuse areas and the
> Monterey County California Farmland import.  The first one was nearly a
> disaster:  it took me four years to manually untangle Nathan's mess/data
> upload crashes and finally supersede with v3.  The Monterey County import
> was a constant struggle of "throttling down" Nathan's constant instinct to
> "spill buckets of import paint quickly and with little regard for data
> quality" until I hardcore task-managed the project between the two of us
> over months of careful project husbandry so it eventually became a sane and
> high-quality import of which we can both be proud.  Nathan is also
> notorious for, let's be candid, "making a mess of California's Central
> Valley" which, even to this day, I am not sure he has fully cleaned up.
>
> Nathan, I do not say these things lightly in a public forum like talk-us,
> but it appears that you are yet again taking a cavalier and hair-trigger
> approach to doing a major (MAJOR!) import in California.  If you wish to do
> so, please learn from your past that this is a tremendous effort, bigger by
> an order of magnitude or more than anything you have attempted to import
> before, listen to friends of yours like me and Denis (below) and bite off
> only as much as you can chew, with the technical, social and OSM community
> skills needed that it takes to complete such an endeavor.  We are asking
> you to please do it right this time, if indeed you feel that you can and
> will.  There are many, many tasks ahead if you wish to see these data in
> OSM and not even the first tasks of what would encourage me to say I see a
> high quality data import ahead have happened yet, save for posting the
> data.  THAT is often the first step of a hasty, poor (and ultimately
> redacted) data 

Re: [Talk-us] Available Building Footprints

[Nathan Mixter]

California has more than triple the amount of data available than any other
state. Importing it will be no small task but doing it in chunks by several
people will make it manageable. The buildings in the Bay Area alone in the
file stretch from Clear Lake way down to Hollister and run along the coast
in Santa Cruz all the way up the East Bay. Several other large cities and
areas are included in the data. There have been several imports of
buildings here in California and many people have put in a lot of work
tracing individual buildings. This data will tie in those imports and will
be a valuable addition. I broke the data apart further by region along with
the status of buildings in the areas on the main wiki page at
https://wiki.openstreetmap.org/wiki/Available_Building_Footprints, and
there is a place for users to express interest. I would love to hear
further thoughts on this data set particularly on the data in California.
All the best,
Nathan


Message: 4
> Date: Wed, 22 Mar 2017 19:34:21 +
> From: Eric Ladner 
> To: Clifford Snow , Brad Neuhauser
> 
> Cc: Rihards , talk-us 
> Subject: Re: [Talk-us] Available Building Footprints
> Message-ID:
> 

Re: [Talk-us] Open Building datasets for San Jose, Fremont and Berkeley

[Nathan Mixter]

Hi, I reviewed the data awhile back for San Jose and found that it was high
quality and definitely worth being imported. Yes, by all means please feel
free to jump in on this import! It will a great addition to connect other
imports done in the Bay Area. There are a few buildings that I and others
have traced manually from imagery. I started working my way north tracing
images in southern San Jose with Bing imagery before I realized the city
had the data available. I am fine with having any of the buildings I've
traced deleted in favor of the better quality shapes. I would be happy to
assist in the import however I can, and there are several other mappers in
the area who have helped with imports who would also be able to take over
part of the work load.
All the best, Nathan Mixter

On Feb 22, 2017 4:09 AM, <talk-us-requ...@openstreetmap.org> wrote:

Send Talk-us mailing list submissions to
talk-us@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-us
or, via email, send a message with subject or body 'help' to
talk-us-requ...@openstreetmap.org

You can reach the person managing the list at
talk-us-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-us digest..."


Today's Topics:

   1. Open Building datasets for San Jose, Fremont and Berkeley
  (maning sambale)


--

Message: 1
Date: Tue, 21 Feb 2017 20:36:00 +0530
From: maning sambale <emmanuel.samb...@gmail.com>
To: talk-us <talk-us@openstreetmap.org>
Subject: [Talk-us] Open Building datasets for San Jose, Fremont and
Berkeley
Message-ID:
<capzumufhwxjem96ggace-_4xvblslnyelf7epwvqvuva7qn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

Recently we came across three open buildings datasets for San Jose[1],
Berkeley[2] and Fremont[3]. We have evaluated the quality of each of
the datasets and found them to have good coverage and building
extrusions match recent satellite imagery. We have updated the wiki[4]
with the above sources for California.


- San Jose: https://cloud.githubusercontent.com/assets/
1933377/22969874/09901660-f396-11e6-93a9-225dfab1ccc9.png
- Berkeley: https://cloud.githubusercontent.com/assets/
1933377/22469786/28cb43b4-e7f3-11e6-979c-0fcc27cea67d.png
- Fremont: https://cloud.githubusercontent.com/assets/
1933377/22917071/97fb3536-f2a8-11e6-885c-26a5f0a6ce14.png

The datasets for San Jose and Berkeley also contain building heights
and that of San Jose contains building parts as well.

- Building part details in San Jose:
https://cloud.githubusercontent.com/assets/1933377/22919803/e374ba8c-
f2b7-11e6-9d03-3693401851fe.png

Our team would be happy to collaborate if you are open to importing
these datasets to OpenStreetMap.

[1] - http://www.sanjoseca.gov/index.aspx?NID=3308

[2] - https://data.cityofberkeley.info/City-Government/
Roofprints-2006/gnp8-t9x8

[3] - http://egis-cofgis.opendata.arcgis.com/datasets/
5b4a263844634084af2001f82a5174a5_0

[4] - https://wiki.openstreetmap.org/wiki/Potential_Datasources#California



--
cheers,
Maning
Data, Mapbox



--

Subject: Digest Footer

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


--

End of Talk-us Digest, Vol 111, Issue 16

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

Re: [Talk-us] Long way in Lake County, CA no tags - broken boundary or other relation?

[Nathan Mixter]

It was indeed part of an import. It has been deleted now.

Message: 1
Date: Thu, 17 Sep 2015 14:20:37 +0200
From: Blake Girardot 
To: talk-us 
Subject: [Talk-us] Long way in Lake County, CA no tags - broken
boundary or other relation?
Message-ID: <55fab015.7020...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi all,

Could someone with some knowledge or expertise please investigate this way:

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

I think it part of broken boundary relation or something, but it has no
tags and does not seem to belong to any relations.

I only have the vaguest idea how boundaries and relations are used so I
do not mess with them and when needed, find a more experienced mapper to
help me with them.

I already left a note on the last changeset to modify this way as well:

https://www.openstreetmap.org/changeset/32790926

But I can't do anything to fix it and it happens to be in the middle of
a current wildfire area (Valley Fire in CA) so will be seen and/or used
by lots of people in the near and long term future.

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

Re: [Talk-us] Tagging National Forests

[Nathan Mixter]

I would like to see areas in OSM categorized as either land use, land cover
(which we call natural for the most part in OSM) or administrative to clear
the confusion. I am also in favor of eliminating the landuse=forest tag at
least in its current incarnation and switching any official forested areas
to boundary tags.

I think most of us would agree that having trees across an area with few or
no trees looks weird. Yes, I know - don't tag for the render, blah blah.
But it seems like it would make sense if we kept wood and forest areas
separate. Since natural=wood and landuse=forest virtually render the same
now, they should be treated differently than they are currently.

Before, portions of southern California, Arizona and Utah were lit up with
their landuse=forest tags everywhere looking like massive Christmas tree
farms the way they rendered. Now that wood and forest look similar, there
is a smoother flow between the two but still much cleanup to do.

I'd like to see most administrative boundaries be tagged with just a
thicker or dashed border. Even most non city parks should not be green but
should just have the same boundary=protected_area type border. An admin
boundary should always be the base. The color in the map should come from
the land cover in rural areas and the landuse in urban areas. This means
that a national forest shouldn't have the landuse tag. We need to make it
harder for people to accidentally edit an official border rather than
easier.

If an admin area has a landuse tag attached to it, then people who try to
expand and modify it to include a surrounding forest or treed area will get
confused and accidentally move the admin area by mistake. The two areas
need to be separate otherwise people have to try to connect land cover
areas to admin areas in order to map land areas.

In any discussions about land use and land cover, we should look at what
organizations have done and how they have mapped ares. For instance, in
USGS imagery in JOSM you can see how they render borders with just a dashed
line and let the land cover have various shades of color on top of it.

The U.S. Forest Service has a distinct classification for mapping
vegetation within the forest. And the USDA differentiates between use of
forest land and forest cover (
http://www.ers.usda.gov/data-products/major-land-uses/glossary.aspx).

Here is how the USGS defines land use and land cover (
http://www.mrlc.gov/nlcd92_leg.php and in more depth at
http://landcover.usgs.gov/pdf/anderson.pdf). Not sure how other countries
map land use and land cover, but this is a sample from what the U.S. does.

From
http://www.ers.usda.gov/about-ers/strengthening-statistics-through-the-interagency-council-on-agricultural-rural-statistics/land-use-and-land-cover-estimates-for-the-united-states.aspx#h
Land use and land cover are often related, but they have different
meanings. Land use involves an element of human activity and reflects human
decisions about how land will be used. Land cover refers to the vegetative
characteristics or manmade constructions on the land’s surface.

The site also has a good break down of how different organizations view
land use and land cover. It is interesting to note how organizations view a
forest. Most of the agencies listed view it as an area with trees. Forest
land is broken up into deciduous and evergreen, something we might be able
to incorporate into the OSM rendering eventually.

I would love to see OSM reach a consensus on this long standing issue and
be able to move forward and even expand the land cover definitions further
to incorporate more features and make them easier to map.

Thanks for reading, Nathan
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] Using unit tags

[Nathan Mixter]

Hi,
 Is there any way we can start using the addr:unit tag for buildings? This
was approved several years ago but it still doesn't render yet. If both the
addr:housenumber and addr:unit tags are used, the housenumber tag is still
dominant. This looks really weird having several of the same housenumbers
on one building. If the unit tags is there it should override the
housenumber tag. Some people try to get around this restriction by placing
the main housenumber inside the building shape and then using an additional
housenumber tag as a node for each of the individual units in the building.
Does anybody know if this issue has been addressed on the carto page.
Thanks,
Nathan
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Cleaning up California FMMP residential

[Nathan Mixter]

As the original importer of this data, I support Paul's proposal to
selectively delete the larger residential areas, which mostly are too broad
to be in OSM. I know the farm data has its problems, especially in the
earlier counties where I didn't fully realize how to use techniques to
fully optimize the data and split it up more first. But there is a lot of
good useful data mixed in with the bad data. The strength of the data is
the farms and these data are generally high quality. People have expressed
to me that the data is hard to edit in the areas that it is too vast, and I
do apologize for the extra work this has caused. Originally I left in a lot
of what FMMP defined as urban land. These often included a wide variety
of features that were split apart a lot better in later imports done.

For better or for worse, California is no longer a barren wilderness but
has blossomed into a flower full of color and life. I always am open to
comments and critisms and working with others to make the data better.

Nathan


 --

 Message: 1
 Date: Fri, 14 Jun 2013 15:28:50 -0700
 From: Paul Norman penor...@mac.com
 To: OpenStreetMap US Talk talk-us@openstreetmap.org
 Subject: [Talk-us] Cleaning up California FMMP residential
 Message-ID: 005901ce694e$8c1b2d80$a4518880$@mac.com
 Content-Type: text/plain; charset=us-ascii

 I've been doing some California landuse and have come across a lot of
 landuse=residential imported from FMMP which is clearly wrong. The
 landuse=residential covers entire cities, including commercial, industrial,
 retail, parks, schools, golf courses, airports, and pretty much anything
 within city limits.

 It's hard to be certain because whatever was done doesn't match the
 documentation at http://wiki.openstreetmap.org/wiki/California_Farms but
 it
 appears that data corresponding to any urban area was imported as
 landuse=residential.

 Given that this is a systemic problem with this imported data and the
 problem originates with the import conversion, I think the best approach to
 fix it is a mechanical edit. Given that the data is 1.5 years old without
 being cleaned up, I believe it is the best option.

 To this end, I propose removing v1 imported ways/multipolygons from FMMP
 with FMMP_modified=no, FMMP_reviewed=no, landuse=residential, and either
 description=other land or description=urban land, starting with ways 
 about
 500 000 square Mercator meters (exact value subject to change).

 This would be about 750 areas.

 There are about 3000 smaller areas that would need dealing with later, but
 it'd be nice to get the large hard to edit ones cleaned up first.



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

Re: [Talk-us] Anyone ever talked about adding more Land Ownership data to OSM?

[Nathan Mixter]

It would be awesome to include the land ownership data from BLM especially
if we could do it for the whole US. Unfortunately that is probably not
something that people would want to add because of the conflicts with other
data. I wonder if we could include it on a limited basis or only include
certain features.

As a hiker, I also think the data have value because it is important to
know where you will get shot at if you cross over. On my Garmin Oregon, one
of the layers I have draws in landuse boundaries so I know what is what. It
is too bad we can't include something like this. Maybe it could be somehow
included as a separate layer or transparent somehow so it does not affect
other data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Can Google use our buildings

[Nathan Mixter]

I'm not sure if this link has been posted before, but for those wondering
how Google got their new buildings, there is a link at PC Magazine
http://www.pcmag.com/article2/0,2817,2411232,00.asp. Apparently they
recently uploaded 25M buildings done through an automated image recognition
software.

I've manually added most of the buildings in the city of Gilroy (
http://tools.geofabrik.de/mc/?lon=-121.56369lat=37.00553zoom=17) so I was
curious to find out where they got their data from. I thought maybe the
city or county had a secret source that I hadn't found. And I checked
everywhere I could to find buildings that could have been imported.

I was wondering if OSM could do the same thing. Could we buy as a group a
program like Feature Analyst, eCognition or Imagine Objective and add
buildings that way? We could combine the buildings with any existing
address points available. I checked into it earlier this year and one
program was about $2,000. But the money could be quickly raised. I know I
would be willing to donate.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] parcel data in OSM

[Nathan Mixter]

Parcel data in and of itself are not inherently bad to have in OSM as long
as they are filtered and modified before adding. For instance an open space
parcel probably isn't that useful because it is not represented in OSM. It
could be broken up into meadow, wood, scrub, forest, etc. Other parcel data
that don't translate well include things like flood planes or highway
zones. Even some forest parcels may not always translate into
landuse=forest. Within cities, you have parcels that are subdivided into
areas like medium family residential, multi family residential, non retail
commercial, mixed use, etc. Parcel data tends to be too vague or tends to
overlap other features. A better way to add it is to filter out each
individual feature first, verify them and then upload them individually.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NHD imports

[Nathan Mixter]

In June, user Bsupnik converted the entire NHD dataset into OSM
format. The files are available at
http://bsupnik.dev.openstreetmap.org/NHD. He mentioned that he was
working on creating better quality files. The files that he created
look good. They are missing the names though. It looks like they just
need a couple minor tweaks because the files generally looked good.
Just wondering if any progress has been made. These would be ideal
once the bugs are worked out so people could review and upload the
data in their area.

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

[Talk-us] Kern County progress

[Nathan Mixter]

  I have begun cleaning up the area around Kern County, California. It is 
starting to not only look better but be less cluttered.

I originally imported landuse data from both Kern County and the City
 of Bakersfield. Some areas from these two agencies overlapped around 
Bakersfield, and I have been going through and trying to remove these. 
The city data were quite good and included landuse areas, buildings, 
parks and even individual trees within the city. The county data tended 
to be generic in several places. It also was slightly misaligned in 
spots particularly in the rural areas, possibly due to the projection it
 was created with by the county.

I have been going through and systematically deleting the redundant 
areas and breaking down the over used landuse=farm and 
landuse=residential tags into more specific areas. And in the process, I
 have been covering some of the ugly white space that has remained 
empty.

A lot of the areas are now natural=heath. There is not really any 
good way to differentiate between meadow and heath areas. Still seems 
like they can be used interchangeably sometimes. I've been trying to use
 meadow for an area that can be used for grazing. I just started using 
the heath tag for open areas generally on areas east of Highway 5. It's 
not a perfect option but at least it kind of matches the work others 
have done around Las Vegas and in the desert.

I've been trying to integrate the existing Kern County data with the 
FMMP farm data, which I have imported for other counties around the 
state as well. 
As part of the cleanup, I am adding some new buildings in Bakersfield from city 
data. I am only adding new building that have been added since the original 
import and verifying that they don't exist to avoid dups. Probably less than 
1,000 total new buildings. Originally, I included bak:fac_type1, bak:fac_type2 
and bak:fac_type3 tags on some buildings to correspond to tags in the data. 
These are not needed and can be removed en mass by a script in the future. I am 
leaving those tags out and incorporating them into the building= tag (ie 
building=residential, building=commercial) for new buildings.I also created a 
long overdue Kern County page on the wiki to keep track of the changes 
(http://wiki.openstreetmap.org/wiki/Kern_County,_California).
Thanks to everyone who has contacted me to help out with the cleanup and 
offered advise. If anyone is interested in helping or has any suggestions, feel 
free to jump in or let me know.Nathan,


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

Re: [Talk-us] Kern County Import Cleanup

[Nathan Mixter]

Kern County does have its set of unique challenges. As mentioned, the rural 
areas of Kern County I imported from the official county files tend to be too 
generalized - either landuse=farm for agricultural land or landuse=residential 
for any type of residential area even if it is rural residential or estate land 
with little actual residential use. Much of the rural areas can probably be 
tagged as either meadow or scrub. There is also the area to the east as it gets 
near the Mojave Desert. This could be tagged as heath or as desert, as some in 
that area have started doing. In addition some of the areas in the county are 
used for oil drilling. Should these get something like landuse=industrial?

The shapes in rural areas tend to be off as mentioned. These were part of the 
original data by the county. It could be the projection that was used to create 
the data. I've been able to correct some of these areas by selecting several at 
once and then moving them.  

I agree with the suggestion removing the extra tags. I don't see any way reason 
to keep them. Maybe these could all be removed by a script or bot.

To fix the areas, they can either be deleted or modified to include the 
appropriate tag for each section of the area.

If any one wants to take a stab at fixing them, feel free. I will continue 
doing so also.

Subject: [Imports] Kern County Import Cleanup

Message-ID: 026101cd6d5c$126eea10$374cbe30$@mac.com

Content-Type: text/plain; CHARSET=US-ASCII



I happened to be looking at Kern County and noticed two problems with the

imports that seem to be systemic over the area.



The first is classification of empty areas as landuse=residential (e.g.

http://www.openstreetmap.org/browse/relation/540695

http://www.openstreetmap.org/browse/way/53993995)



I'd suggest deleting these as no landuse appears to appropriate here



The second is a similar issue, mountainside areas in landuse=farm (e.g.

http://www.openstreetmap.org/?lat=35.26lon=-118.47zoom=14)



While doing this cleanup I would suggest removing attribution, description,

kern:Comb_Zn, kern:Zn_Cd1 and setting source=Kern_County_GIS



The appropriate solution for most of the ways/multipolygons seems to be to

delete them, but I'll leave this to you since you're familiar with the

extents of the upload.

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

Re: [Talk-us] Fresno castradal imports

[Nathan Mixter]

Thanks for everyone's comments. I do take pride in making sure my imports are 
good. That said I realize there are issues with the Fresno import, one of my 
first imports. But I am not sure if we need to throw out the baby with the bath 
water just yet. If it comes to that, fine. I think the problems with the import 
can be fixed. I am surprised it took two years to mention and then from a 
person from Canada who I guess is doing a review for the license.

So to address some of the issues for Fresno County:

The consensus is against dumping castradal data into OSM.
Consensus by who? There have been many cases where it has been used 
effectively. Sometimes it is the only way to go because some areas can't be 
mapped by hand or are so vast they are impossible. Sure, it shouldn't be just 
dumped in, but if it is selectively added it can be beneficial. Landuse is 
beneficial because it tells you where you can or cannot go and makes the map 
more usable. With parcel data, address data can later be added making the map 
routable.

I don't buy the argument that having too much data is a bad thing. If that is 
the case, we might as well all stop editing the map altogether. Eventually as 
more and more people join, people will add items to the map anyway. You can't 
have all white areas forever. The data shouldn't be too over digitalized, But 
being under digitalized can be just as bad. There has to be a mix. I like the 
idea of having a filter for people who need to download larger areas.

No documentation or community consultation.
When I did the import, there weren't really any active mappers in the county. I 
try to consult local users when doing imports because they often have good 
suggestions about ways to handle certain areas or know what has been done 
locally. Unlike with Europe, there are many counties in the U.S. that don't 
have any active mappers, making it tough to establish a consensus. That is 
something we need to figure out a way to solve. One trick I've used is to move 
my location marker each time and then see all the users around and what they 
are doing. Maybe in the future there could be some type of host site where 
people can comment on imports in an organized way and search for things near by 
them and comment on them or offer to help importing.

Extra tags.
I'm not sure what the problem with having extra tag information in the 
database. A couple extra bytes? We are allowed to create custom tags and use 
them however we want to describe the data when tags don't already exist. What 
is wrong with incorporating a few of the original tags from the producers of 
the data into OSM? Was this overkill? Maybe. Definitely with the description 
and location tags. But we can send the woodpecker bot in or run some other 
script in and take out all the tags that aren't needed. No big deal. There are 
areas that do have overlapping tags like natural=water and landuse=residential 
due to an error in my scripting conversion, but these can be deleted manually 
or by script.

Empty areas
These can easily be filled in or deleted on a case by case basis. Sometimes 
this is federal land that can be tagged with a landuse tag upon further review. 
I tried to account for all areas when running the script on the initial data 
but missed some of the variables.

Split lots
Split lots are a pain, but these can be joined manually as I have done on 
several locations.

Duplicates
Some duplicates were added since there were several different layers used in 
the Fresno imports, i.e. parks, schools and the county and city zones. That was 
my fault for not checking, but they can be merged or deleted in JOSM. The 
county lot includes all the crop types, which makes it possible to break down 
farms into vineyards or orchards. The city parcel set includes all the extra 
parcel information for each address.

I'm not sure what user:BiIbo did to update the data afterward. But I have done 
numerous updates myself to delete dups, merge data and align the layers. The 
Tiger data in the county was real bad, which adds to the problem of things not 
lining up. While I acknowledge there are several errors in the data, I think it 
is still possible to clean them up manually or merge parcels into one area for 
each block, and I am willing to continue working on cleaning up the data if 
that is the route chosen.

When I originally converted the shapefile, it created more than 100 OSM files, 
which I loaded one by one. It was tedious. That was back in the day when files 
took forever to load. I wish I knew what I know now about importing. I do agree 
it is a lot easier to do a little pre-import work first and save a lot of time 
later on.

So bottom line, I am OK if the data has to be reverted. I still think it 
belongs in OSM but in a more condensed and error-free form. I am willing to 
help however I can to either clean up the data or to reimport it in a more 
streamlined fashion. Thanks for hearing me out. Hopefully I didn't put too 

[Talk-us] California GIS data is public domain

[Nathan Mixter]

Try checking with the county planning department. Looks like there are three
people in their GIS services department -  Greg Bazhaw, Steve Borgstrom and
Matthew Thompson. Start with Greg at 408-299-5776 or
greg.baz...@pln.sccgov.org. Then try Michael Lopez, the planning manager or
Jody Hall, the director. They all have the same email format of
first.l...@pln.sccgov.org. It might be best to send them a letter requesting
the information and explaining a little about OSM and what it is about. 

--

Message: 3
Date: Fri, 24 Jul 2009 21:26:55 -0700
From: David Carmean d...@halibut.com
Subject: [Talk-us] California GIS data is public domain?
To: OSM US Talk talk-us@openstreetmap.org
Message-ID: 20090724212655.g16...@halibut.com
Content-Type: text/plain; charset=us-ascii


[ OK, I see that this was posted to the list back in February, but I don't
find 
any further discussion about it... is there a way to search just the
legal-talk archive? ]

Just found this article about an appeals-court decision on the Santa Clara
County 
GIS brouhaha:

http://gis.lacounty.gov/eGIS/?p=696

In particular, the analysis of item III of the decision seems to indicate
that 
the court believes that government-produced data cannot be copyrighted:

III. A. There is no statutory basis either for copyrighting the GIS
basemap or for
conditioning its release on a licensing agreement.

The decision can be found here:

http://www.courtinfo.ca.gov/opinions/documents/H031658.PDF

The question is: has the Foundation considered this?  Can we begin to import
California 
GIS data? :)


-- 
Dave C, 2nd St.



--

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


End of Talk-us Digest, Vol 20, Issue 23
***


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

Re: [OSM-talk] Do we care if its forest or wood? Natural world mapping ...

[Nathan Mixter]

What about reorganizing the structure of the wiki to be something like this?
Basically any item would fall into three main categories - boundary,
landcover or land_use. The boundary or the land_use should be the first
layer then the landcover. For instance, within a park you could have trees,
rocks, sands etc. The natural category can be combined into one category for
the landcover. The items for amenity, historic, leisure, man_made, military,
shop and tourism would fall under the land_use category even though they
wouldn't be tagged land_use=amenity, etc. They could still be tagged the
same way as currently they are. 

I like the idea of having one tag for any type of trees. There could be a
subtype such as type=forest or type=eucalyptus_grove, type=deciduouis, etc.
The trees could even be rendered differently depending on how much space
they took up. 

Nature_reserve should only be for a natural boundary that is an official
nature reserve. Nature_reserve should also be either transparent or in the
background. There are cases where it will run over both land and water. It
may even run over a coast line like it does in Point Lobos, Ca.

Especially in the Bay Area in California, there are a lot of tags that
overlap each other and as a result look ugly. Using something like
landcover=trees may help. The trees could be rendered with little tree icons
instead of just being a solid shade of green like the parks are.



One tag Natural=Trees, maybe it could be rendered differently based on the
size.

Boundary =
the official boundary set by a government or municipality

= administrative 
= civil 
= nature_reserve
= national_park
= national_forest
= park
= political

landcover =
is the physical material at the surface of the earth.

= basin 
= bay 
= beach
= cave_entrance
= cave 
= rock face 
= coastline 
= fell 
= glacier 
= grass
= heath
= land
= marsh
= meadow 
= mud 
= peak 
= rocks
= scree 
= scrub 
= snow 
= spring 
= tree (s) 
= volcano 
= water 
= wetland 

Land_use
is the human modification of natural environment or wilderness into built
environment such as fields, pastures, and settlements

= allotments 
= cemetery
= farm 
= farmyard 
= landfill 
= logging
= open_space
= pasture
= quarry
= railway
= recreation_ground 
= reservoir
= salt_pond
= village_green 
= vineyard 

= brownfield
= commercial 
= construction
= greenfield
= industrial 
= residential
= retail 

amenity
historic
leisure
man_made
military
shop
tourism


\==


///
//Tom: 
I'd really like to nominate someone like Nick Whitelegg as Countryside Tsar
for a day, so he could work out the different basic features we need to
know about in the countryside and an appropriate tagging schema. Then, as
always, a combination of wiki documentation, Mapnik  ti...@home rules,
Xybot mischief and peer education could disseminate this sensible approach.

I'm going to go back to this because it makes so much sense to do. I too get
discouraged by the lack of comprehensible tags. I actually think that
natural key is a bad key. Is an artificial lake a natural=water or
something else? If it's a reservoir (and what lake isn't technically a
reservoir) is it sufficient to tag it just landuse=reservoir, and should we
tag it as man_made=water to explain that it's not actually natural? 

No, clearly we shouldn't. So we could just accept that natural and landuse
are equivalent and adjust natural tagging as such (since changing everything
to landuse seems out of the question). So if we do that, then natural=wood
wood=managed or landuse=forestry or whatever becomes a reasonable way to
separate the landform from the land use

Greg: 
So, I think we need some tags that denote landcover, and some tags that
denote legal status.

so an area would have at most 1, preferably exactly one of:

landcover=trees
landcover=swamp



Exactly what I was thinking (though I think just using natural as equivalent
to landcover might be the way to go at this point), and using the USGS style
landuse values [1] would be a good start covering the majority of cases (I
think just rolling them all into natural (including man made surfaces makes
sense at this point, but I accept I may be--and probably am--wrong) 

and at most 1 of

land_use=...

eh... I'm less fond of this, just because I'm not sold on there being 1 and
only 1 land use for an area but I have no supporting evidence to back up my
iffy feeling
 
yes, land_use=forestry perhaps implies land_cover=trees, but in the case
of

land_use=conservation

I would expect a variety of landcover tags within the administrative
boundary of the conservation area/park.

As would I, when I said solid fill earlier I mean more like hatching or even
a transparent overlay/underlay? for rendering, I'm pretty convinced about it
being a boundary=whatever issue at this point for things like parks/national
forests,DNR land, BLM land... but not convinced that something can't be both
say land_use=recreation and land_use=conservation (you can bike, 

[OSM-talk] script and python bindings

[Nathan Mixter]

I'm trying to run the polyshp2osm.py script on a shapefile I converted to
4326 format using ogr2ogr. I copied the script and all three files created
by ogr2ogr to the c directory.

I try to run from the command prompt
python c:\polyshp2osm.py -s 10 -o 4 -l c:/open C:/Zoning.shp.

 

But I keep getting ogr python bindings not installed

 

I tried several different options from
http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries

 

I added the path location\data in the GDAL_DATA system variable and the
location\bin to the path.

 

I added the gdal locaton inside the script.

 

I got the same results when I installed fw tools, when I ran the individual
installation and when I ran it from USBGIS.

 

I tried uninstalling and reinstalling the application several times in
different orders, but still nothing.

 

What am I missing? Anything I can try? Thanks

 






___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] yahoo and josm

[Nathan Mixter]

I copied the web-kit folder to the same directory that the josm build files are 
in. I am still getting the red exception occurred when trying to run the wms 
layer. Any ideas why its still doing it? Do I need firefox 2 rather than 
firefox 3? I tried to install both at the same time but haven't tried running 
just firefox 2 yet.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] (no subject)

[Nathan Mixter]

That is the rare exception. Not the norm

On Wed, Dec 17, 2008 at 5:49 AM, Nathan Mixter srmix...@hotmail.com wrote:

 Just wondering. Shouldn't buildings be rendered behind roads.



Not if the building is over the road



http://picasaweb.google.com/hemrajpathare/CopenhagenPhotos#5225837680766253506



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Buildings and roads

[Nathan Mixter]

Wow, Naga City is full of buildings. How did they get so many? Are those all 
building=yeses? Crazy. And I thought adding all the industrial and commercial 
buildings was bad. Anyway I still think that if the building layers were set at 
a lower layer level by default and the roads to a higher, it might look better.


On Wed, December 17, 2008 06:49, Nathan Mixter wrote:

 Just wondering. Shouldn't buildings be rendered
behind roads. 

 Currently buildings are drawn above a road when the
road is wide like 

 a highway or major road. Obviously buildings don't
cut into roads. If 

 the road layer is on top this won't happen.

 

A major road doesn't have to be wide by
default. I hereby invite you to visit Guadarrama, where a trunk road (the
N-VI) has only two lanes, and buildings are just one meter away
from the asphalt.

 

Yes, I agree that the rendering is messed up at low zoom
levels (see Naga City in the Phillipines), but at higher zoom levels, I see no
other easy solution.

 

(In a perfect world, a road would be not a line, but a
polygon, so the width and area could be perfectly known).

 

 

Cheers,

--

Iván Sánchez Ortega i...@sanchezortega.es

 

Un ordenador no es un televisor ni un microondas, es una
herramienta compleja.

 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] buildings and roads

[Nathan Mixter]

Just wondering. Shouldn't buildings be rendered behind roads. Currently 
buildings are drawn above a road when the road is wide like a highway or major 
road. Obviously buildings don't cut into roads. If the road layer is on top 
this won't happen.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] open space land

[Nathan Mixter]

Thanks for the response. The area in question is land that usually is near a 
county or state park in the U.S. Usually the area will be about the size of a 
regular park or a little larger. Sometimes the borders of the land could be 
touching the park borders. This land is general purpose land, i.e. hiking, 
biking, horse riding etc. The area doesn't include dense trees, so there is no 
logging or anything. It's pretty much set aside for its natural beauty. The 
specific land I was looking at was in California listed under 
openspaceauthority.org. Thanks.

--


Subject: Re: [OSM-talk] open space land



May I ask which country that's in? For example in the US (where I am) there are 
several different types of open space land. National Forests, National Parks, 
State Parks, State Forests to name a few. All of those have different 
regulations when it comes to land use (whether you can cut wood, etc.) for 
example. leisure = park may not automatically apply to all of them.



Now this is in the US. I know that Germany has, for example, state and national 
forests which are typically much more groomed than US national forests. Back 
when I lived in one of them (I'm not even kidding) at the end of the 90s, they 
appeared to be more like really large parks than forests, at least to my North 
American eye. I would personally see it fit to tag those as leisure = park, but 
don't take this for advice as I don't map stuff in Germany and german mappers 
would obviously know better.



So before giving more precise opinions, I would say we would have to know which 
jurisdiction you are in, what those open space land actually look like and how 
they're actually used.



My two cents.



Charles



 Original message 



   The government sets aside land for open space land.

   These usually have specific and boundaries. Are they

   worth adding? Should they be treated as leisure=park

   in OSM?



___

---___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] layers and rendering

[Nathan Mixter]

I know there has been a lot of talk recently about layers and what should be 
displayed on the maps. I think the public buildings such as libraries, town 
halls are good to have on the main map. 

Here is an idea I wanted to throw out to the OSM community. I am not a 
developer, so I'm not sure what is being done or has been done along these 
lines or even if it is feasible. 

Is it possible to somehow turn off and on certain features on the map? I'm 
imaging something that works similar to mapstudio or another map making 
program. If someone wanted to see just the buildings, just the roads etc, it 
would be great if they could check a box and those features would show up or 
not show up. This would eliminate the worry of the main map becoming too 
cluttered and it would also help if people wanted to export the map to 
highlight particular features. Once the feature is approved, it could then be 
immediately rendered on the map rather than whenever someone decides to render 
it.

Here are a couple of ways this could be accomplished. The first is by having 
the different data on different layers then turning those layers off and on. 
The second is by being able to select which tag categories can be viewed. 

Just food for thought. Thanks.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] open space land

[Nathan Mixter]

The government sets aside land for open space land. These usually have specific 
and boundaries. Are they worth adding? Should they be treated as leisure=park 
in OSM? 
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapnik rendering of paths + place=locality in general

[Nathan Mixter]

Maybe the answer is to modify the map features table and add columns for 
mapnik, osmarender,
cyclemap, etc. Maybe getting rid of the generic rendering column and making it 
rendering for each of the viewers. What do you think? 

I think there is a wysiwyg media wiki plugin that might make editing the table 
easier. If we have something like this, it may make managing the table less 
time consuming so we can keep it up to date with all the newest official tags 
and how they look with each of the renders. 





 

 
I
wish we could have a wiki page that describes tags which are supported
by at least one of the major renderers (main mapnik, osmarender,
cyclemap), routing software or widely used. Now a number of tags on map
features are very rarely used or even usable (bus_guideway) or
generally not rendered (path).
 
As it is now, I think map features is confusing and often of little help when 
trying to find the best way to tag a feature.___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] changes not showing up

[Nathan Mixter]

It shows up in Osmarender, so maybe its just taking longer to load like you 
said.


I assume you mean Mapnik, mapnik is not done loading the data. If you
see your data when opening potlatch (it is the editor tab) or JOSM, it
is the DB. 
Also
it is probably already rendered on the Osmarender layer and definitely
on the data layer (real time), click the blue plus icon in the right top
 
On Wed, Nov 5, 2008 at 9:31 PM, Nathan Mixter [EMAIL PROTECTED] wrote:
 
Is there any reason the weekly changes weren't reflected on the
Potlatch map? Usually they are made Tuesday night. Did the day change?
Could there be a problem with the data I uploaded? It was quite
extensive, buildings, tracks, landuse, etc. Thanks.___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] gpsbasecamp.com

[Nathan Mixter]

Can data from GPS base camp (gpsbasecamp.com) be used in OSM? The site has 
state and national park data formatted in GPX XML. Does that mean that it can 
be opened in GPSBabel or directly in JOSM. So far I haven't been able to get 
them to work in either.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[Talk-us] GIS state data

[Nathan Mixter]

Has anyone had any experience with importing state GIS data?
Looks like

there is some good information the California state gis site at

http://gis.ca.gov/BrowseCatalog.epl
and also at the Santa Cruz County gis

site at http://gis.co.santa-cruz.ca.us/.
It looks like the state data

formats are in dbf, prj, shp, xml and shx. The county data is in mdb,

shp, and esri format. Which formats are the best to try converting and

where do I start?

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

[OSM-talk] nodes and land use

[Nathan Mixter]

 

 
When do you use nodes and when do you landuse? Can you have a node
overlapping landuse such as a golf course node overlapping the area of
the golf course? If so, do you include the name and ref of the course
in the node or the landuse or both?  I've been over lapping the two for
things like golf course and churches. Is this correct?___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] GIS data

[Nathan Mixter]

Has anyone had any experience with importing state GIS data? Looks like

there is some good information the California state gis site at

http://gis.ca.gov/BrowseCatalog.epl and also at the Santa Cruz County gis

site at http://gis.co.santa-cruz.ca.us/. It looks like the state data

formats are in dbf, prj, shp, xml and shx. The county data is in mdb,

shp, and esri format. Which formats are the best to try converting and

where do I start?___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk