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

2017-08-14 Thread 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

2017-03-28 Thread 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

2017-03-28 Thread 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

2017-02-22 Thread 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?

2015-09-18 Thread 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

2015-08-19 Thread 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


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

2013-06-17 Thread 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?

2013-01-07 Thread 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: [Talk-us] parcel data in OSM

2012-12-28 Thread 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

2012-10-28 Thread 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

2012-08-20 Thread 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

2012-07-29 Thread 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

2012-04-27 Thread 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

2009-07-25 Thread 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


[Talk-us] GIS state data

2008-11-02 Thread 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