Monterey County Checklist

Note as of mid-February 2013: the MoCoFMMP import is complete. What you see below was a brain dump and checklist. It can be ignored, but is included for historical purposes.

Checklist for California Farms import for Monterey County.

• Remove or fix overlapping zones. This is easier typed than done. In fact, just to say how is a bit of effort, but it needs doing.

-- Largely done as part of the upload process. By "upload process," we mean that we first split the MoCoFMMP data into separate sub-files, each with a different landuse. This resulted in about twenty different files. Then, for each sub-file, we loaded it into JOSM, turned on a Bing layer, selected each object in the sub-file, and downloaded the surrounding area to see what was already in OSM (e.g. an existing similar polygon), visually comparing all three layers: sub-file/FMMP data, Bing, and OSM. When "all looked good," we went onto the next object/polygon in the sub-file data. When this resulted in a pleasing proto-upload for that sub-file (specific landuse out of the twenty), we uploaded. We discussed whether or not we should "peer-review" by sharing the post-edited files amongst ourselves, but decided that our editing skills had matured to the point that this was not necessary. Beginner or intermediate editors might still consider the peer-review step in similar efforts.

• Fix the area around the military base in south county. To fix right, a better data set might define the boundary more satisfactorily than what we have now. Sloppy or uneven park-military boundaries seem like we are being too hasty to upload.

-- Largely done/underway. The USGS layer being available in JOSM helped.

• Should landuse go over the base? I'd say so initially, until we better look at how red-hatching works mixing these in various renderers. A military base might be considered as a political division, too. Large landuse boundaries by differing units and levels of government more-or-less live here. Yet we also "concede" that these may truly have features such as orchards, meadows and farms. In short, just as a park can be mostly wooded, but "lightly meadowed," mixing a landuse with a landuse (military + meadow) seems OK, especially as renderers do something visually pleasing. However, this remains undone in this next frontier of landuse mixing and renderer testing. It's not a terrible way to do it, but it does lean towards coding for the renderer.

-- We still have questions here. For example, for a barracks, is it sufficient to have a large landuse=military define the boundary of the base, and then have building=residential for the individual buildings? What about adding an interior polygon with landuse=residential inside of landuse=military? Use a multipolygon with "inner?" (But then we exclude that this really is military housing). Et cetera.

• Remove natural=scrub around cities. Better: sharpen how this is less vague; seek original intent from data producer. We might be able to use these polygons, but with more crisply-defined-in-OSM tags. Or not if that really isn't possible (a poor mapping from original data semantics to OSM semantics). As tags are flexible, some effort may be quite worthwhile. Consider how OSM is seen and used now and how OSM will be seen and used in a future we can only imagine.

-- The landuse=scrub data is vague, but it is better than nothing. This should be sharpened up with tedious visual comparison with Bing, but it is not always clear where scrub begins and ends (and where it is forest/wood).

1) The area surrounding the Soledad State Prison is blended with part of US Hwy 101. This doesn't seem altogether wrong, as both are "state property," but to be strictly correct, might we want to break these apart and call one "amenity=prison" and the other something like "landuse=public_utility" (which is what the SCCGIS upload does for portions of state highways, and while this doesn't render, it is "correct" in a sense, as a highway is a state-owned public utility). Thing is, what boundary?

Also, our buffer holds a multipolygon relation with an outer scrub and an inner "hole" which are in turn inside of the prison multipolygon. As "scrub" really isn't right for the "other land" tag from the original data, this will need to be fixed, additional research is required here.

Oddly, the NE portion of this prison area skates off into farmland with seemingly random curved areas. I don't know if this is a legal boundary, an intermittent creek which doesn't appear that somehow affects the farm data, or what, but it is odd, and I'm not sure whether it is legal, natural, or correct for OSM as is.

2) The "wood" multipolygon in Del Monte Forest (Pacific Grove area) may be strictly true from a "natural=" perspective, but it directly overlaps with both residential and military areas. Yes, it appears we have a "woody housing tract" and a "wooded portion of a military base," yet what might we expect a renderer to do? Does OSM actually WANT double-overlap areas, even if they are strictly true? (Your SCCGIS upload / my edits do this to some small degree with some SCCGIS data, I admit, but I personally eyeballed, hand-checked and edited each and every one of them for "pleasing combination" results and fixed what was or looked wrong). What combos do we expect to render? This smears into coding for the renderers, but it can also be a subtle art. Striking for "true (factually, as tagged) and certainly beautiful" (say, like Mapnik expresses it) is not a bad place to land, but truth and fidelity to reality and accurate tags must lead the way.

3) The "residential" area around Wunpost is most distinctly not: it is best described by industrial (or perhaps quarry?), as this is an active oil drilling field with access roads. Or is it? Most (or all?) of this large parcel is an oil field, but some of it might be worker housing (e.g. near the Salinas River on the west side of the railroad?). Just hard to accurately say without more data or local knowledge. -- This is now known to be an active oil-drilling area and is marked landuse=industrial.

4) The Prunedale residential area overlaps with clearly (already-mapped) commercial areas. So we shouldn't tag this residential, but it vaguely defines a soft urban boundary often at farm interfaces. An experiment might be a boundary tag that draws some dashes at the right level (4?) of government (the Farm Bureau). Subtle, true, and perhaps a good place holder to sharpen up to better (less vaguely defined) data.

5) The Spreckels residential area overlaps with park and school areas. Knocking those out shouldn't be hard. -- Done.

6) The gigantic (307 member) meadow relation overlaps with vast other areas, including Hunter-Liggett military reservation. Again, this may be strictly correct from a "natural" perspective, but is it right to upload this as is? Just this relation alone is a vast amount of work, but it appears to be quite deserving of careful and detailed attention. -- Done.

7) The meadow relation (9 members) around Los Padres Reservoir looks to be part scrub and/or wooded, and may actually be defined by fire damage. Whether fire damage accurately ought to be tagged as meadow (perhaps yes) is debatable, this parcel is clearly not all meadow as viewed by Bing Sat imagery. -- Done.

8) Many other meadows seem spotty or random. -- Done.

9) The farm multipolygon relation with the largest number of members (42) has a "tear" (missing members) in its outer members: they don't form a "loop" in the relation editor, and they should. Delete in our shared buffer (awaiting a re-import of that one)? -- In progress. This is the bulk of the upload and was split into five geographical pieces, two of which (around Salinas and King City) are already done.

10) The farm multipolygon relation with 13 members around Greenfield looks awesome! This one is a keeper! Maybe this is a first baby upload. Then we can delete it from our buffer. -- Being harmonized with JOSM now before the actual upload.

11) (Skipping a whole bunch of farms). The first eight relations of the 80 are empty of tags besides "type=multipolygon." These are just plain wrong and should not be uploaded as they are without more effort to discover what they are trying to convey from the original dataset. -- Perhaps the most difficult part of the upload. We are saving this for last. Possibly circa March/April 2013 upload.