Santa Cruz County, California

From OpenStreetMap Wiki
(Redirected from Santa Cruz County)
Jump to navigation Jump to search
VTE
Santa Cruz, California
Wikidata

latitude: 37, longitude: -122
Browse map of Santa Cruz 37°00′00.00″ N, 122°00′00.00″ W
Edit map
External links:
Use this template for your locality

Santa Cruz is a county in California at latitude 37°00′00.00″ North, longitude 122°00′00.00″ West.

A section of California's "Central Coast," and rather "average-sized" compared to other counties in the USA, Santa Cruz County is geographically the second-smallest county in the state: only San_Francisco,_California is smaller in the size of its geography among California counties.

Events

Upcoming events

Please suggest locations and goals for future events. A UCSC Mapping Party is a "next" good choice, as OSM needs added and improved additional footpaths as well as amenities like bicycle parking and drinking fountains. Suggested good meeting places are Café Iveta at Quarry Plaza, and the Atrium at McHenry Library as both are centrally-located to the campus.

Who's up for organizing another mapping party?

Past events

Santa_Cruz_Mapping_Party Wilder Ranch State Park (May 2019)

University of California Santa Cruz (UCSC) Professor of Environmental Studies Millard-Ball used OSM at UCSC Winter 2016 in his ENVS 196 class to audit the pedestrian network on campus and use it as a model for improvements, including longer-term planning with the Campus Architect.

UCSC Professor of Computer Engineering user:manduchi proposed McHenry Library for a Mapping Party. However, the professor and venue seem to be unavailable for this function in the near future. Professor Manduchi and his Computer Engineering 80A students did not contribute to OSM around Santa Cruz during Fall quarter of 2015, but did in earlier academic quarters. This class may once again make contributions in future academic quarters.

Fading into the past, there is a not-actually-active "Cake Map" for UCSC where you might feel free to be inspired. No longer is it a realistic option to take ownership of a slice if you can and will improve it: simply improve the map at UCSC!

Santa_Cruz_Mapping_Party_June_2012 Wilder Ranch State Park

Santa_Cruz_Mapping_Party_July_2011 Wilder Ranch State Park

Santa_Cruz_Mapping_Party_May2009 Downtown

Imports

Landuse

In late 2009, user:srmixter (nmixter) imported official landuse=* zones from the Santa Cruz County GIS (SCCGIS) site. (But not without significant problems!) See Santa_Cruz_County,_California/Archive.

These (multi)polygons were intended to be a "first draft" of landuse and greatly benefit by continuing improvement and additional micro-mapping with finer detail than data which were originally entered in 2009. They are updated as necessary with newer data from here or real world experiences. Importantly, in no way are these data intended to interfere with newer, better, more detailed data being added to the map. Wholesale removal of the SCCGIS data without such improvement is regressive to OSM's overall data content, so contributors are encouraged to UPDATE, ADD and IMPROVE data here, where as superior data supersede SCCGIS data, the older data should be removed. As superior data are added or existing data derived from SCCGIS (multi)polygons become so heavily modified that they are unrecognizable from their original source, tags identifying their source should be removed. This allows editors to know which data came from SCCGIS (those with, say, Zoning tags) and those which don't (no such tags). Over time, these SCCGIS "first draft" landuse (multi)polygons are supplemented with or replaced by superior data, thanks to additional contributions by OSM contributors. Please feel free to edit such data with NEWER, ADDITIONAL or IMPROVED data; remove SCCGIS tags from (multi)polygons as they become so modified that they no longer resemble the original data.

upload_version=* OSM Volunteer Date of data Date uploaded Status and Notes
1 (not actually tagged) user:srmixter 2009 November 2009 Upload script repeatedly crashed, many errors. Raw data, unimproved (e.g. landuse=public_facility and landuse=special_use remained as imported, not rendering). Data contain the Atribution=* key.
2 (not actually tagged) user:srmixter 2009 December 2009 2nd attempt with same data caused many duplicate nodes, broken multipolygons, other problems. Data contain the attribution=* and Zoning=* keys. user:stevea improved these, e.g. natural=wood on largely-wooded landuse=special_use (multi)polygons.
3 (not actually tagged) user:stevea November 2013 December 2013 - May 18, 2014 Where data were wrong from v1 and v2 and needed updating, these data replaced them. Data contain the Attribution=Santa Cruz County GIS key. user:stevea substantially improved these (individually compared each against v2/v1).
4 user:stevea 11/2/2018 December 2018 - January 2019 Spatial Dataset 3,095 Rows. ("Row" = OSM closed way/polygon datum or a single multipolygon). Where v3 data needed updating. Data contain the upload_version=4 key and/or this is noted in the changeset comments (e.g. "SCCGIS v4").
5 user:stevea 2/9/2019 February 2019 - August 2019 Spatial Dataset 3,095 Rows. Where data needed updating. Data contain the upload_version=5 key and/or this is noted in the changeset comments (e.g. "SCCGIS v5" or "SCCGIS Zoning v5").
6 user:stevea 9/20/2019 October 2019 - December 2019 Spatial Dataset 3,098 Rows. The very few places where data need updating. Data contain the upload_version=6 key and/or this is noted in the changeset comments (e.g. "SCCGIS v6" or "SCCGIS Zoning v6"). Minor "touch ups" from November to December, 2019.
7 user:stevea 11/23/2019 December 2019 - June 2020 Spatial Dataset 3,098 Rows. These data seem to indicate very few or no changes are needed to upload / update, so very few were.
8 user:stevea 7/7/2020 July 2020 — January 2021 Spatial Dataset 3,160 Rows. Initial contact with these data happened on July 13, 2020. Very few changes based on this set, but some were noticed to not be included upon release of subsequent dataset (upload_version=9).
9 user:stevea 11/21/2020 January 2021 — July 2021 Spatial Dataset 3,161 Rows. Initial contact with these data happened on January 14, 2021.
10 user:stevea 5/26/2021 July 2021 Spatial Dataset 3,161 Rows. Initial contact with these data happened on July 27, 2021. The data in OSM and the reference Zoning dataset are drifting. For example, Harmon Gulch area's "forest" (Timber Production zone) needs reworking as v10 TP polygon data are smaller.
11 user:stevea 6/29/2021 February 2022 — June 2022 Spatial Dataset 3,160 Rows. Initial contact with these data happened on February 18, 2022.
12 user:stevea 3/29/2022 June 2022 — October, 2022 Spatial Dataset 3,160 Rows. Initial contact with these data happened on June 22, 2022.
13 user:stevea 6/30/2022 October 2022 — April 2023 Spatial Dataset 3,166 Rows. Initial contact with these data happened on October 14, 2022.
14 user:stevea 2/2/2023 April 2023 — July 2023 Spatial Dataset 3,168 Rows. Initial contact with these data happened on April 5, 2023.
15 user:stevea 6/29/2023 July 2023 — October 2023 Spatial Dataset 3,168 Rows. Initial contact with these data happened on July 2, 2023.
16 user:stevea 11/1/2023 November 2023 — ongoing (where necessary) Spatial Dataset 3,168 Rows. Initial contact with these data happened on December 30, 2023. This is the current "reference" Zoning dataset. Data in OSM and this reference Zoning dataset slightly drift from about v9 or v10 (late 2020, early 2021 data). As of 2023-Q4, estimated effort to fully harmonize from existing data (somewhere between v9 and v10, sometimes later) to this reference dataset (v16) is low to perhaps moderate.

Landuse data inside of city limits (cities of Santa Cruz, Capitola, Scotts Valley, Watsonville) derive from sources other than SCCGIS (which is county only) or have been directly experienced. See specific "City of..." sections below. There is an encouraging trend, for example in the Prospect Heights neighborhood of Santa Cruz (a "neighborhood, fully zoned residential" as a polygon): smaller, much more accurate polygons tagged landuse=residential have begun to be added, excluding streets, sidewalks, and other not-strictly-residential areas inside of the enclosing polygon. When the enclosing polygon is fully populated with these, its landuse=residential tag becomes superfluous. However, the enclosing polygon still remains useful to "name" the neighborhood, so it should remain in OSM. At "fully populated" (with the smaller, more accurate polygons) change the landuse=residential tag to place=neighbourhood. This is consistent with the original intent of "capturing zoning with landuse is a good first step...then replacing these with more precise data correctly supplement them."

OSM strives to include both the latest official data and OSM-contributed data which are superior. Sources of official data include a SCCGIS "Zoning" file (a .shp, .kml or .json; the data are equivalent) v16 down to v1 (as "versioned" above), CPAD 2022b (possibly), CPAD 2020b, CPAD 2019b, CPAD 2018a (aka CPAD v2) and CPAD 2016a (aka CPAD v1). Later versions of these data somewhat agree. Some OSM edits include "editor smear" of centimeters to a meter or so, often caused by copying a (multi)polygon in one layer of JOSM and pasting into another, though there has been much work to correct these minor misalignments as they are observed. A fact: official data do improve with multiple iterations, especially as OSM, SCCGIS and CPAD "watch each other's data" over the longer-term (many years). There is drift in the county between OSM and the latest dataset, while it is minor, "it is complicated." These data do (slowly) improve in OSM.

Santa Cruz has won a Gold Star Award from BestOfOSM.org, one of only a few places in North America to have achieved this accolade. The site notes that OSM displays "nearly perfect landuse!" And, Joseph Eisenberg, one of the authors of Carto (OSM's default renderer) says Santa Cruz County "looks like the best-mapped county in California, and one of the best in the USA, now." He has also downloaded it "to use for testing new features." Keep up the great work, Santa Cruz mappers!

Additional landuse tags

From both SCCGIS imported data (noted above) and individually-curated CPAD polygons, OSM contains some extraneous "foreign keys" left over from these sources. These are in ALL CAPITAL LETTERS, obviously not OSM-originated keys. Our wiki California/Using CPAD data describes why two of these data might sensibly remain in OSM. (Briefly: with CPAD data, UNITID is useful as an identifying tag and ACRES is useful as a sort of "checksum" to see if this UNITID polygon has changed since a previous version of these data). The SCCGIS data have similar extraneous keys, although because versions of the data over the years have modified their included keys and values, "what to do" is a bit more complicated than for CPAD data.

Similar to CPAD's UNITID (going forward, cpad:unitid=*), SCCGIS' OBJECTID (going forward, sccgis:objectid=*) remains a useful tag to keep for the same reason: it uniquely identifies this (multi)polygon between versions. So, similarly are the SHAPE* tags (SHAPESTAre, SHAPESTLen, SHAPE_STAr, SHAPE_STLe), as only the most recent version of two of these should remain in OSM data: either *Are with *Len or *Ar with *Le. The reasoning is the same as for CPAD data: the SHAPE* tags allow detection of even very slight changes in a polygon by differing values (as a sort of checksum).

The Zone key contains a capital-letter value which definitively characterizes this landuse (multi)polygon. Most, but not all of these values logically map directly or "fairly closely" to an actual landuse=* value in OSM:

SCCGIS Zoning key or value Action New OSM key=value
A (value) Keep Change to landuse=farmland. A stands for "Agricultural" (a direct logical mapping).
BASEDTL (key) Delete
BASENM (key) Keep Change to description=* with the same value.
BASEZN (key) Delete
COMBZN (key) Delete
CA (value) Keep Change to landuse=farmland. CA stands for "Commercial Agricultural" (a direct logical mapping).
C-1, C-2, C-4, CT (values) Keep, Special Change to landuse=commercial (if specifically known to be "offices") or landuse=retail (if specifically known to be retail). C stands for "Commercial" (a direct logical mapping). For CT ("Tourist Commercial:" gas stations, restaurants, visitor accommodations...), you may wish to add tourism=yes; see also the VA value, below.
FULLZN (key) Delete
GENERIC (key) Delete
M-1, M-2, M-3 (values) Keep Change to landuse=industrial. M-anything means "Manufacturing" (a direct logical mapping). Locally, these include mining (sand, gravel, limestone quarries...), rocket engine testing, factories, frozen food processing and "light industrial."
OBJECTID (key) Keep Change to sccgis:objectid=* with the same value.
PA (value) Keep Change to landuse=commercial. PA stands for "Professional / Administrative" (a "fairly closely" or "close enough" logical mapping). These are frequently offices (insurance, medical professionals, real estate, surveying / engineering professionals, etc.).
PF (value) Keep, Special Change to "something," exactly what requires some further research. PF stands for "Public Facility" so this could be amenity=fire_station, amenity=townhall, office=government, amenity=public_building, or even a state highway corridor. Omitting landuse=* or another OSM tag is controversial, but it is still done.
PR (value) Keep Change to leisure=park or leisure=nature_reserve (local knowledge or a sign can help determine which). PR means "Park," (as meant in US English) but as leisure=park has a very OSM-specific meaning, please see leisure=park. Tags boundary=protected_area + protect_class=* may be appropriate.
R-anything, besides RA (values) Keep Change to landuse=residential, perhaps something more specific. R-anything means "Residential" (a direct logical mapping). Some values indicate specificity of what sort of residential, such as a mobile home park, or medium- or high-density, so specific tags on buildings like building=apartments might be correct. Use discretion.
RA (value) Keep Change to landuse=residential or landuse=farmland (local knowledge or imagery can help determine which). RA means "Residential-Agricultural" (a live-on / family farm), a category of landuse for which OSM has no single tag, so a choice is made. Usually, landuse=farmland. Can be subtantially covered with trees. If it is known (e.g. from aerial / satellite imagery) where the "farmhouse" (residential dwelling) is located, this (and possibly other appurtanant structures like barns, etc.) can be surrounded with a smaller polygon tagged landuse=farmyard, which includes / surrounds the building=house.
SHAPESTAre with SHAPESTLen (keys) Keep Change to sccgis:shapestare=* and sccgis:shapestlen=*, respectively, with the same values.
SHAPE_STAr with SHAPE_STLe (keys) Keep Change to sccgis:shapestar=* and sccgis:shapestle=*, respectively, with the same values.
SU (value) Keep, Special Change to an appropriate value, but without local knowledge it can be challenging to know what this should be. SU stands for "Special Use" and is a SCCGIS "catch all" value. Often (not always), these are heavily wooded, so many (circa v2) were also tagged natural=wood: these "stacked tags" are slowly being broken apart into two polygons, the original landuse=* tag, plus a new one with a landcover / natural=* tag. See below.
TP (value) Keep Change to landuse=forest. TP stands for "Timber Production" (a direct logical mapping).
VA (value) Keep, Special Change to tourism=hotel or something similar. VA stands for "Visitor Accommodations" so these might be tourism=hotel, tourism=motel, inns, conference centers, organized camps, vehicle and tent camping parks (tourism=camp_site), etc.
Zone (key) Special Logically map to the corresponding value as found in this table, add the new OSM key=value pair, then delete this Zone key. For example: M-anything=landuse=industrial, TP=landuse=forest, etc.
Zoning (key) Keep If no upload_version=* tag is extant or added, keep this tag as an identifier of these data as originally derived from SCCGIS Zoning data.

OK, this looks "v1 complete" as a rough suggested algorithm to start whacking away these "extraneous foreign keys," so let's get busy doing that! (I correct these as I see them, especially since creating this table offers a decent set of rules). Stevea (talk) 02:00, 8 January 2020 (UTC)

Update: Data were OT-filtered to delete BASEDTL, BASEZN, COMBZN, FULLZN and GENERIC keys. There should be no more of these keys in OSM. Going forward with newer data, please delete these five keys (as indicated in the table). Stevea (talk) 03:55, 8 January 2020 (UTC)

Sometimes tags in ALL CAPITAL LETTERS (some refer to these as "foreign keys") are left in the data when they do not logically map well to OSM tags. Where objectionable, these tags can be deleted from OSM. However, for the reasons indicated above, please leave intact (older) values of Shape* and OBJECTID, changing keys as described.

Parks

In 2009, user:Apo42 uploaded some of the open space conservation and/or recreational areas and all California State Park entities (from UC Davis-sourced CaSIL data) including those in Santa Cruz County. The vast remainder of the parks in the county (county, city and private) came from the SCCGIS Landuse import (see Landuse above). A small number of minor, usually city parks (e.g. La Barranca, Mimi De Marta, Branciforte Dog Park) were added manually from non-SCCGIS sources.

In March, 2017, some data were conflated (with existing SCCGIS v3 landuse data) from California Protected Areas Database (CPAD). (CPAD generally "winning" over minor boundary differences, although the county's western edge at Big Basin State Park diverges substantially between existing CPAD data and SCCGIS data; areas from Whitehouse Canyon to Waddell Creek continue to challenge). These data are tagged source=California Protected Areas Database (CPAD) – www.calands.org (December 2016), the v1 of these data. This manual conflation of units and super-units was difficult: minor discrepancies between SCCGIS landuse and CPAD data, especially alignment in west and south county, were noticed and called to the attention of the next data update (as Carto rendering completed with the v1 upload). What we call "CPAD version 2" data began with CPAD "2018a" data. Sometimes tags from the shapefile in ALL CAPITAL LETTERS were left in the data when they do not logically map well to OSM tags. Where objectionable, these can be deleted; see Using_CPAD_data.

In early 2019, these newer (2018a) v2 CPAD data were discovered and compared with SCCGIS Zoning.zip v5 data (noted in Landuse above). In March 2019, email correspondence among CPAD's publisher (GreenInfo Network) and SCCGIS attempted to determine which data defining components of Big Basin State Park are "more correct" (notably, West Waddell Creek Wilderness / WWCW segments along the western edge of the Santa Cruz County boundary), as there are v5 discrepancies of as much as 30 meters westerly and 90 meters northerly. According to GreenInfo Network, "we consider State Parks' data authoritative when mapping state parks specifically. Our standard generally is to refer to agency data but use parcels as a geometry base. But with State Parks specifically we tend to defer to their boundaries over parcels." A reply from SCCGIS says "the answer depends on your mapping needs" and "there are a number of other factors potentially at play here as well. For instance, we've known for a long time that in certain areas of the county parcels can be off by up to 300'. This is acknowledged in the disclaimer we put on our internet mapping applications." The result is that park data near Little Basin west to about Last Chance Road seem more accurate as SCCGIS publish them, which are "winning" in OSM there, while west of there, along the San Mateo County boundary in and near WWCW, CPAD data seem to "better align" with multiple other data sources (and so remain in OSM, even as they differ from SCCGIS data). See also "County Boundary" (below), where some easterly drift (15 - 20 meters) is seen in SCCGIS County Boundary data near Big Basin Way compared to USGS topos and other sources. See also recent (2019-Q2) Talk page Discussion on park:type=* tagging (being deprecated, but widely extant here). CPAD 2019b (November, 2019 data) began to be added to OSM, starting in Santa Cruz, Santa Clara and San Mateo counties in the early 2020s, continuing into Monterey County and beyond as of the mid-2020s (2024-Q1).

Streams

user:DanHomerick imported the Stream.shp layer of the Hydrography dataset from the Santa Cruz GIS site in October 2009. He used the Java program shp-to-osm-0.6.1 to convert the data from Shapefile format to OSM format and bulk_upload.py to upload it. Since, at the time of the import, shp-to-osm does not connect line segments he used the Validator plugin in JOSM to merge overlapping nodes. This connected many stream segments correctly, but left some unconnected at import time. Existing rivers were not programatically deleted, instead preferring to rely on manual verification before their deletion. Many imported streams were initially pointing the wrong direction (a way with a stream/river tag should point downstream). Work is underway to correct issues with the import: corrections to wrong-direction waterways are mostly complete as of Feb. 2010. However, as of May 2014, JOSM's Validator plugin reports many unconnected stream endpoints where they conjoin other streams. A note about the tags used: many of the streams were listed as type "swale" (a low lying area) in the original dataset. These were translated as waterway=stream + intermittent=yes + note=swale for the upload, but in many cases, especially near the mouth of a stream, a swale may not actually have intermittent flow. As intermittent=yes now appears to affect the Mapnik rendering (with a dashed light blue line), the tag should be deleted on ways where it is inaccurate.

County Boundary

In early 2010 user:Apo42 uploaded CaSIL-based county-boundary data for all of California, including Santa Cruz County. The Santa Cruz County boundary was harmonized by user:stevea. In particular, the southern boundary displayed centuries of flooding and re-coursing of the Pajaro River, the eastern boundary is close to, but not quite exact with the SCCGIS landuse=* upload, especially around Mt. Madonna Park, the northern boundary was checked against stream data uploaded by user:DanHomerick (noted above) and user:mk408's stream data upload from Santa Clara Valley Water District along the "spine" of differing flow directions at ridgetops of the Santa Cruz Mountains, and the northwest and western boundaries were checked against both CaSIL state park and SCCGIS landuse=* uploads, still not quite with perfect alignment. An error in the northwestern county line near Gazos Creek Road was found in the data from the CPAD import in March, 2017, this was harmonized with data from the USGS topographic data of the area.

In early 2018, user:stevea remapped the county boundary based on SCCGIS' October 27, 2017 "County Boundary.zip" shapefile data. This was harmonized with the shared boundaries of Santa Clara, San Mateo, Monterey and San Benito Counties. In 2019, this was done again with SCCGIS' 2/9/2019 updated data, however, there is some noticeable drift with USGS topos, Santa Clara County data and CPAD. These were "best guessed" and almost certainly contain minor errors (as much as 15 - 20 meters in places).

Cycle Routes

Santa Cruz County has an excellent network of established and developing bicycle infrastructure. The Santa Cruz County Regional Transportation Commission (SCCRTC) publishes a (paper and online) County Bike Map (CBM) displaying these bicycle lanes, paths and alternate routes, the latest online version in 2020. Also, SCCGIS publishes (click "Data" then "Transportation") a transportation layer that includes the County's electronically published bicycle infrastructure. JOSM can be persuaded (with the opendata plugin) to open the shapefile data's .shp entry point resulting from (optionally) unzipping this file. While every single way in the CBM denoted with colors has had tags applied in OSM (green bicycle path = highway=cycleway or cycleway=track, red bicycle lane = cycleway=lane, purple bicycle alternate = bicycle=yes) — OSM bicycle infrastructure tagging — and these have been collected into route=bicycle relations tagged with network=lcn — OSM bicycle route tagging — there are also ways in the County which (according to signage or roadway paint in the real world) also have these tags, but are not (usually) collected into route=bicycle relations, as they are not so denoted in the CBM. Somewhat unusually, several of these ways are included in OSM as CycleNet "Z" routes, see below.

In 2010, a proposal was made to SCCRTC to superimpose upon the CBM's local-government-published infrastructure a local cycleway network (network=lcn) numbering protocol, colloquially known as CycleNet (or "CycleNetSZ" in a statewide Caltrans context). The routes and their numbering largely have a one-to-one correspondence with the physical bicycle infrastructure published in the CBM, ideally, the bicycle infrastructure resulting from downloading SCCGIS' latest bicycle shapefile data noted above. CycleNet is simply a set of logical routes proposed as a local network numbering protocol superimposed on the CBM-published physical infrastructure. In introductory stages as it is brought before jurisdictions for discussion and approval, two initial routes (Walnut-Soquel, which might become lcn or rcn 8, and Freedom Blvd., which might become lcn or rcn 80) were introduced into OSM as proposed network=rcn bicycle route relations. Additionally, other network=lcn route relations (with state=proposed) have also been introduced, with network=lcn and route=mtb (the latter only for mountain bike routes suffixed with "M" in their ref=* tag). Thus, OSM is a venue for geographic communication/visualization of lcn/rcn/mtb bicycle route discussions and public introductions into a numbered local network. A set of tags to render mountain bike routes as both orange lines (in Cycle Map / OpenCycleMap layer) shown from route=mtb, as well as giving them dark blue numbers in the (shared with network=lcn) local address space have been determined, thanks to research via renderers OpenCycleMap (OCM) and Waymarked Trails' (WMT) Cycling and MTB layers. As local jurisdictions approve these now-proposed routes, state=proposed shall be removed to denote any newly local/legally-sanctioned numbering. Signage on these routes may follow their state going from proposed to approved, so cyclists should not expect route (number) signs on these until jurisdictions approve them. However, believed to be part of Santa Cruz' "Wayfinding" initiative, bicycle-oriented MUTCD D1-3a / D1-3c signage (named destinations, distances in miles, turn direction arrows), without CycleNet or any other numbering protocol route numbers, began to appear in 2019 around Santa Cruz (City and County).

An exception to "no bike route signage" is Pacific Coast Bike Route (PCBR), originally signed by California's DOT, Caltrans. The northern half of Oregon-to-Mexico PCBR — Oregon to Daly City — is now network=ncn and ref=95, as AASHTO approved this in 2021 as USBR 95. The southern-half remainder (Pacifica to Mexico) is believed to be in planning in 2021 to be submitted during a subsequent round. This (public) PCBR should not be confused with the (private) route of the same name by Adventure Cycling Association (ACA); entered into OSM is the public PCBR (Northern California's USBR 95), ACA's private PCBR remains deliberately unentered in OSM, as doing so would violate our ODbL. OCM and Waymarkedtrail's Cycling layer display California's PCBR as "PCB" where known, including Santa Cruz County. Here, PCBR is concurrent with CycleNet 95 as a network=rcn route, as 95 is "regional" in the sense that proposed rcn 8 and 80 are regional — together, 8, 13, a short connecting segment of 15, 40, 80 and 95 act as regional "spines" of County bicycle connectivity. (As of 2019 with MBSST opening its first segment in the City of Santa Cruz, which refers to this as the "Coastal Rail Trail" as part of the MBSST Network, "C40" is also network=rcn here; see below). However, after erecting PCBR signs, Caltrans ceded route definition to local authorities (counties and cities). It was confirmed that de facto "on the ground" Caltrans PCBR signs contradict the de jure PCBR asserted by the City of Santa Cruz. The explanation offered (by the City, in city limits) was "Caltrans gave us the authority to change PCBR and we did, though we haven't changed the signs yet." The PCBR that the City asserted appears to be identical to the ACA's PCBR, which OSM does not have permission to enter, as the City said "here is our PCBR." Yet, the City's declaration put this PCBR segment into the public domain, so it was entered into OSM (in the City). In 2019 with the opening of MBSST's first segment, between Hiawatha and West Cliff Drive, the City appears to have rerouted PCBR along the "Beach alignment," (new MBSST / C40) diverging from the ACA route (again, deliberately not shown in OSM). OSM now displays PCBR through Santa Cruz as the City has defined it to SCCGIS in the "online version" noted above. Hopefully this explains complexities of PCB route/PCBR signage discrepancy history in the City of Santa Cruz.

Additions to CycleNet's "one-to-one correspondence" noted above (not displayed by CBM) are Z-suffixed routes: CycleNet has several such "connectors." In the real world, Z-routes are signed with "Share The Road" or "Bicycles May Use Full Lane," painted with sharrows (all three are cycleway=shared_lane) or are otherwise legal bicycle infrastructure (bicycle=yes). Though bike-legal, CBM does not display these (as purple bicycle=yes), so CycleNet denotes them as Z routes: bike-legal infrastructure as sensible "connectors." Major CycleNet Z routes are 5Z (Hwy 9), 25Z (Empire Grade), 26Z (Hwy 236) and the 826 route group (826 Gazos Creek Road, 826M through Big Basin and 826Z China Grade), all challenging for cyclists (steep, narrow, sinuous, M-routes are unpaved and non-M routes are shared with automobile traffic). CycleNet 826 from/to Hwy 1 (via 26Z and 5Z at Saratoga Gap connecting to Santa Clara County's lcn=13, a route from San Jose to Saratoga Gap) could become a part-mountain-bike regional route (network=rcn) linking multiple counties over the Santa Cruz Mountains, from San José to the Pacific Ocean. However, as of 2022, CycleNet 26 (Highway 236 "north" of Big Basin) and CycleNet 826Z (China Grade) are closed / under construction due to the CZU August Lightning Complex Fire (of later 2020).

The Monterey Bay Sanctuary Scenic Trail (MBSST) multi-use "Rail Trail" is in earlier phases of construction; two initial segments are complete (as of 2021-Q4). CycleNet assigns MBSST as CycleNet 40, with various segments as constructed denoted 40A, 40B...up to 40Y. In 2019-Q2, MBSST Construction Segment #1 (was CycleNet 40I, Boardwalk) was completed in the real world as Coastal Rail Trail and entered into OSM tagged ref=C40, as Coastal Rail Trail / MBSST is a de facto route in the cycle_network=US:CA:SZ namespace, though not yet de jure in the cycle_network=US:CA:SZ:CycleNet namespace, so ref=C40 solves labeling both route designations with a single tag. (If CycleNet becomes de jure, MBSST becomes ref=40). The new bike-and-ped-only bridge across the mouth of the San Lorenzo River is also believed to be part of the (poorly geographically specified) California Coastal Trail (also bike-and-ped), proposed as CycleNet 30. As the bridge is bicycle=dismount (walk bikes), this segment is also tagged (via a relation separate from MBSST) ref=30P, the "P" suffix in CycleNet meaning "pedestrian only" (on a bicycle, dismount and walk your bike). A newer segment of MBSST through the Westside of Santa Cruz (Bay Street to Natural Bridges Drive) was completed in 2020, and while it is (slightly) discontiguous from the Beach Cycleway (Boardwark area) segment, this is also denoted network=rcn and ref=C40; CycleNet 15 (Bay Street) does connect these discontiguous ref=C40 segments. Here, ref=C40 (MBSST along the rail right-of-way) and ref=PCB (West Cliff Multipurpose Cycleway as Pacific Coast Bicycle Route/PCB/PCBR/CycleNet 95/potentially USBR 95) are two parallel, regional bicycle routes, separated by about 1 kilometer.

Local Conventions

In 2009, we began a convention with parks, starting with user:Apo42's tagging of State Park data that included park:type=state_park. In Santa Cruz County (and elsewhere afterwards), this was extended to include park:type=county_park and park:type=city_park for parks with management/jurisdiction at those admin_levels (there were explorations to combine these tags with admin_level=* at some point) and park:type=private_park to private parks (for example, a small decathlon-event park with access=private), private campgrounds and for-fee short-term trailer parks. The point was not to make these render (yet) but such tags are useful in a search query, for example. A proto-proposal (park_level=*, see park:type=*) to combine these tags with boundary=* so these render with different color dashing was developed but never more widely submitted to the OSM community; the plan was for rendering to be extended to display parks tagged with state_park, county_park, city_park and private_park using different colors of dashing. (In later versions of mapnik, boundary=national_park renders with green dashes, and it was a partially accepted OSM convention that this tag was appropriate on state parks, though this now appears to be discouraged). See this Discussion, which offers a proposal to deprecate park:type=* in preference of more modern, widely accepted and better documented park tagging standards. Included is the newer tagging scheme of boundary=protected_area, utilizing protection_title=* and protect_class=* keys (themselves not well-developed regarding rendering) which may be applicable to some remaining park-like areas now denoted leisure=park (especially "undeveloped parks" owned by a city or county park agency). Progress on this transition has already begun here, for example this used to be tagged leisure=park, but is now more accurately tagged boundary=protected_area. A distinct trend has emerged to actively deprecate park:type=*: especially with the park:type=city_park value, simply change this to ownership=municipal.

As noted in the Santa_Cruz_County,_California/Archive, because the county is 2/3 wooded, many landuse=special_use polygons from early SCCGIS imports were tagged natural=wood. This tag is used unusually at UCSC, where, in some places, the campus renders with its preferred light-yellow amenity=university tag. Being simultaneously a university yet also heavily wooded with redwood trees, some mappers assume UCSC is "already" wooded, "except where it is not." For contrast, the Campus Natural Reserve polygons ARE explicitly set to natural=wood and Lower Moore Creek and Cave Gulch/Wilder even have some landuse=meadow on top of these, plus there are woods at the Arboretum. The west edge of Mima Meadow (part of UCSC) blends into Wilder Ranch State Park with a meadow/wooded edge, while Upper Campus also has explicit natural=wood polygons, but only as far north as the small water tower. And as the edge of UCSC's boundary is not well-rendered, it tends to blur into surrounding landcover as this tagging continues. So, in places, UCSC's amenity=university polygon is "assumed to be wooded, unless tagged otherwise" — such as natural=grassland (grassy areas not grazed by cattle), landuse=meadow (grassy areas which are grazed by cattle), amenity=parking, building=university, building=dormitory, highway=*, etc. As of late 2023, this continues to be tweaked slightly with explicit wooded polygons and even individual trees (nodes tagged natural=tree) being added around the UCSC campus.

Landuse and landcover are frequently confused issues in OSM. The "all wooded" areas around the intersection of UCSC (amenity=university), Pogonip Open Space Preserve (leisure=nature_reserve) and Henry Cowell Redwoods State Park (boundary=national_park) illustrate this: the boundaries are apparent and readily identifiable with their landuse, even as the real-world landcover on all three is identical (densely wooded). A newer trend is to not double-tag (with both leisure and natural) but to more explicitly define natural=wood as a separate (multi)polygon, hence the natural=wood tag was deleted from both Pogonip and HCRSP relations and added to other relations tagged natural=wood to specifically indicate they are wooded, independent of another polygon. (This also allows members to have greater specificity regarding differing leaf_type=* values). This "tag splitting" is also done on state parks in the county, where, for example, Nisene Marks State Park and Big Basin Redwoods State Park have both (correctly) had their leisure=park tag removed and "largely wooded, similarly state-park-shaped multipolygons" were added as new polygons OSM to specifically (and "independently") represent landcover in those areas. So, now included in the map are landuse=*, boundary=* and leisure=nature_reserve polygons (e.g. farms, state parks, open space preserves, respectively) which may also have landcovers (often natural=wood "superimposed upon them," perhaps with some "punch out" polygons as inner members tagged natural=grassland, natural=scrub or geological=outcrop). This transition of breaking apart "assumed to be wooded" polygons (splitting polygons with a "stacked" natural=wood tag) is a work in progress, user:doug_sfba is active with landcover north of the Santa Cruz / Santa Clara County line (the "spine" of the Santa Cruz Mountains) and user:stevea is active south of there, to near the San Benito County line. Now (2019-Q4) complete is the deprecation of leisure=park on state parks in the county, though this tag does remain (believed correctly) on county parks and especially city / urban parks.

Work to be done in the County

Many TIGER-sourced roads in rural, unincorporated Santa Cruz County were entered with or continue to have errors of up to tens of meters. Some are better expressed as highway=unclassified or are actually highway=track (or highway=service + service=driveway) instead of TIGER's default of highway=residential. Additional tags like barrier=gate and access=private are also missing in many locations. Most of these roads are public, some are access=private (it is not always clear which), so it would be very helpful for those with local knowledge of (and access to) these rural roads to gather GPS wanderings and better classify, align and tag them (highway=*, access=*, name=*...). Due to heavy tree cover, this is more true in heavily-wooded, hilly/mountainous areas of central and northern County, and less true in flat, largely treeless, primarily agricultural areas of southern County. This displayed how complete we are at reviewing data from the TIGER import: as of 2019, substantially reviewed, but minor TIGER Review is still required, especially in more difficult-to-access areas. While that ITOworld renderer is no longer functional, and no similar visualizer seems extant, the latest strategies for TIGER-cleanup are found at TIGER_Edited_Map. Some good news is that package-delivery services to quite remote, rural residences often add / update service=driveway highways to these locations, also better-aligning the residential, tertiary or unclassified roads these "root" upon. So, slowly, both better driveways are added (these might benefit from access=destination) AND their host roads are becoming better aligned, even though these don't always correctly benefit from subsequent removal of their tiger:reviewed=no tag. TIGER cleanup can be performed in the county with the help of this Overpass Turbo query. Note that the relatively urbanized areas of Live Oak, Aptos (especially close to the coast) and Watsonville would benefit from some relatively easy TIGER review (because of existing imagery and relative lack of tree-cover). The San Lorenzo Valley still needs TIGER review, though is more heavily tree-covered.

Certain "holes" in county (zoning or) landuse=* uploads remain from polygons tagged "special_use" or "public_facility:" these are equivocations from SCCGIS, allowing a lack of specificity defining what landuse=* these were, so "special_use" conveys "less defined." As previously described, such "special_use" (multi)polygons which are mostly- or all-wooded also may be tagged natural=wood, perhaps with grassland, scrub and buildings superimposed. This worked well for a decade or longer, though newer distinctions among "park," "wood," "forest," "scrub," "grassland," and (especially among already) "landuse" are being better mapped, most importantly by "tag splitting" landcover tags (usually natural=*) onto a separate polygon. Also, some otherwise "blank" public_facility polygons (no rendered OSM landuse=* value) need a site visit to determine what they actually are (e.g., a water_tower facility that should properly be tagged landuse=industrial). Two notable "public_facility" polygons are significant portions of state highway corridors (State Routes 1 and 17).

As it attached from SCCGIS' declaration of "Park" in its 2009 "Zoning.pdf" file, revealing its use as both vague and flexible, what was long-ago tagged leisure=park captured many private, sometimes spiritual/religious conference grounds and broadly speaking, natural-state, largely unimproved contemplative and meditative spaces. When private (often as religious communities), these are similar to parks in a broad sense, as sometimes they are permissively open to respectful public (quasi-public, actually, permissive) uses such as hiking. One emergence of 2009's SCCGIS Zoning (landuse=*) import was to better categorize these "Park" entities: sometimes both leisure=park and amenity=place_of_worship accurately captured landuse semantics at these areas. (For example, Quaker Center west of Ben Lomond, Land of Medicine Buddha near Aptos, Jikoji at the northern tip of the county and Vajrapani Institute at the north end of Kings Creek Road). As sometimes-difficult exploration of more remote areas continues, the number of parks with unknown names continues to decrease. A believed-more-correct OSM tagging trend began in Fall 2014:   tag name=Unknown Park applied from the SCCGIS Zoning (landuse=*) upload has been replaced with name:absent=yes. As of February, 2016, there remain dozens of parks tagged name:absent=yes which still need accurate naming, either from a site visit (if signs exist) or further querying of County or State records. Some of these appear to be "proto-parks:" public properties which are planned to be improved into parks in the future, but remain closed/no access until then. The March, 2017 CPAD conflation improved a fair number of these parks and "protected areas" with better name=* tags.  Here is an Overpass Turbo query to display these. In 2018 and 2019, some of the religious-oriented areas were more-consistently tagged with amenity=place_of_worship and perhaps landuse=recreation_ground if they are open to public recreation uses (such as Mount Hermon's Redwood Canopy Tours and Sequoia Aerial Adventure), further removing the contentious tag of leisure=park.

A California Public Records Act request of UCSC building footprint data was partially completed, thanks to release of the data by UCSC's Privacy and Information Practices Director and Campus Architect. Work to migrate these from .dwg to .osm took place: while there was partial progress and partial failure, UCSC is also willing to produce a .shp shapefile as an intermediate, another migration path to get these data into OSM. Two of us (software-heavy engineering professionals) have tried .dwf via Teigha to shapefile (various methods and tweaks, the GRASS 6.3 "v.in.dxf, v.out.ogr" method documented in our wiki, others...) to no avail. If you have knowledge how to achieve this data workflow (.dwg -> .shp or .dwg -> .osm, whether via .dxf or not), please OSM-missive stevea.

Around upper Happy Valley, north and west of Laurel Glen and Mountain View, an edge between landuse and landcover ("treed farmland") blurred due to some confused editing. This was largely "healed" with the SCCGIS v4 landuse update. In late spring 2018 the v3 data were reverted with a note=*, asking users to check OSM's definition of landuse=farmland. Some of these areas also have landuse=vineyard, landuse=orchard and landuse=greenhouse_horticulture overlays, and while they both are and appear (from aerial imagery) to be somewhat "treed," it is correct to call these areas farmland, as whether they do allow tree harvesting or not (consistent with their landuse), they continue to generate vineyards/wineries, orchards and greenhouses, all prevalent in this county (even while 2/3 of the county remains covered by trees). The county zoning here is "RA" meaning "Residential/Agricultural," or a "live-on (family) farm," something for which OSM doesn't have accurate tags, so a choice is made between landuse=farmland and landuse=residential, not ideal, but better than nothing. It IS correct to tag the immediate area surrounding the residence (building=house) with landuse=farmyard. From personal experience, these Happy Valley "farms" are extremely diverse agricultural areas: in addition to wine grapes, tree fruit and hothouse crops, they generate wild-crafted herbs for aromatherapy, rare mushrooms by foraging at the tree bases, apiaries / beekeeping and other beneficial insect hatching (such as ladybugs to control aphid infestation), etc. All of these are "agricultural landuse" on areas which appear to be "somewhat treed" (though no or few timber permits prevent Zoning=TP for Timber Production from being tagged, where then landuse=forest is applied) AND with residences where the owners live and raise these "crops." (Important to remember: "farmland" doesn't ONLY mean row crops). Continuing discussion between "landuse" and "landcover" in OSM reveals "this is a complex topic." This wiki's Discussion page is a good place to discuss these issues. A similar "healing" with v5 data occurred in 2019-Q1 with residential and wooded areas in Brookdale and Boulder Creek: a correct trend is to "break apart" both of these (landuse=residential and natural=wood) into two separate (multi)polygons, rather than "stacking" these tags into one (multi)polygon.

The two major components of bus and rail which display in the Transport Layer merit specific mention, due to their partially incomplete state in OSM (though modernization and completion do now continue):

• Santa Cruz Metropolitan Transit District (SCMTD) provides substantial bus service to many parts of the county. Moderate but incomplete highway=bus_stop data were entered into OSM, initially around the University of California campus, extending citywide in 2013 and early 2014. Also entered was inter-county bus route "Highway 17 Express," linking to San José's Diridon Station for CalTrain and Amtrak rail connections (plus BART and High Speed Rail in the future). This route is nearing "going green" to PublicTransit v2 standards according to geofabrik's OSM Inspector tool. A semi-automated system (SCMTD's quarterly-released GTFS protocol data) to transform routes and stops into route relation data in OSM was under development, but bogged down with technical difficulties (the Java development stalled). So, now, the tedious work of entering these routes and updating them quarterly must be (and is being, slowly but surely) completed manually. Manual entry began with most University-Downtown routes in February 2014. All stops and additional "alternate segments" of these routes may not yet be complete. As of late 2014, the SCMTD bus route network being entered into OSM was "in progress," perhaps 55% - 60% complete. SCMTD routes remaining to be entered into OSM could use re-assesement; additional volunteers assistance is appreciated! However, as of late 2019, there has been substantial growth towards fully realized public_transport version 2 elements and relations — hooray! As with many OSM tasks, it is far easier to update a "network" or "system" (of bus routes, for example) than it is to continue to be adding to it, so what is not known is if SCMTD's routes in OSM are actually complete. Please update (post 2021-Q2) this wiki or its Discussion page if anybody discovers that the SCMTD network can be declared to be public_transport version 2 complete. After that, simple updates to any real-world changes will suffice.

• Since 2012, Santa Cruz Branch rail is in public ownership (administered by SCCRTC). While light industrial/freight usage (lumber, frozen foods, biodiesel matter...) continues on about five miles of track around Watsonville, longer-term planning is underway to potentially offer future passenger rail service on much of this line. Sites, stations, halts and platforms which displayed in OSM as proposed rail stops came from studies as early as 1998, these are obsolete. As new and potentially different rail infrastructure and services emerged, proposed and actual rail features were updated in OSM. In early 2014, SCCRTC was awarded a Caltrans Transit Planning grant to undertake an analysis of commuter and intercity passenger rail service, studying recommendations for phased, efficient service on the branch: objectives included comparisons of cost-effective options to provide additional transportation options. In 2014-Q4, results were published and in early 2015 updating of railway=stations, railway=tram_stops and railway=halts was completed in OSM. As of 2016-Q1, County rail infrastructure in OSM has stabilized, as additional improvements (sidings, signal infrastructure, speed limit and control point data...) continue to be updated (though, these "minor infrastructure" elements remain incomplete). OpenRailwayMap displays rail infrastructure and OpenPublicTransportMap displays passenger rail. Finally, there is much railway=abandoned in the county (e.g. in the San Lorenzo Valley) not yet entered into OSM; ODbL-compliant data sources for these historical rail routes and/or their actual entry into OSM continue to be appreciated! A future, likely-local OSM project might emerge to systematically migrate all abandoned and disused rail in the county to OpenHistoricalMap, though with the (slow, underfunded) emergence of public passenger rail and sharing of dispatch responsibilities among Santa Cruz Branch operators, this remains fluid and early.

City of Santa Cruz

The COSCZoning.kmz file from http://gis.cityofsantacruz.com/kml was used to "officialize" commercial districts, industrial zones and residential neighborhoods (among other areas, like parks and schools) of the City of Santa Cruz. While exactly correct for parks, schools, commercial and industrial zones, this file contains an overabundance of data for residential areas, such as distinctions between low- and medium-density zoning. Hence, these residential polygons were coalesced where necessary to build the named (and numbered, put into ref=*) neighborhood areas shown at the City web site. These display at closer zoom levels, out to z=14. The place=suburb nodes (Downtown, Westside, Eastside, Seabright and University, displaying at medium zoom levels, out to z=12) and place=locality nodes (Midtown, Terrace Hill, Terrace Point, East Morrissey and Science Hill) emerged with local consensus, they appear to have stabilized.

Work continues (2024 onwards) in the City of Santa Cruz to add and complete the following:

• more complete amenity=parking areas (with access=destination if true) and highway=service, service=parking_aisle roads in commercial and industrial zones, where appropriate,

• better lanes=* tagging and turn restriction relations,

• tags for disabled access routing: many more areas which are well-served for wheelchairs or low-vision persons (disabled parking spaces, highway=elevator, automatic_door=yes, ramp:wheelchair=yes, kerb=lowered, tactile_paving=yes, traffic_signals:sound=yes...) are not marked as such nor are mapped with these access nodes or routes in mind where they certainly exist,

• more highway=bus_stop nodes and route=bus relations of the excellent local transit system, (may become semi-automated with a GTFS protocol data feed from SCMTD),

• better and more consistent address numbering at landmark buildings and block level starting Downtown (a major tourism attraction, popular with locals too!),

• "completion" of UCSC campus (see The Cake). It seems there is a constant need for additional "micro-mapping" such as amenity=drinking_water (drinking fountains), shop=laundry and amenity=vending_machine nodes,

amenity=place_of_worship (largely done, some details remain, such as sport courts visible in aerial views, adjunct buildings and amenity=parking),

highway=footway and footway=sidewalk (and highway=crossings (crosswalks), tactile_paving=yes, kerb=lowered, highway=elevators...) in areas beyond Downtown, especially to link business districts for pedestrian and disabled access,

• individual buildings in residential neighborhoods (houses, apartments, detached garages...) added around the city,

• remaining amenity=post_boxes, amenity=fountains, amenity=charging_stations, amenity=clocks, amenity=telephones, amenity=benches, tourism=viewpoints, amenity=waste_baskets, barrier=fences, barrier=gates, natural=cliffs, amenity=drinking_water (drinking fountains), leisure=pitches (sport fields and courts), leisure=playgrounds, power=poles, power=lines, power=substations, cycleway=shared_lanes (roads with sharrows and signs proclaiming "Bikes May Use Full Lane" and "Share The Road") and traffic_calming=bumps around the City.

City of Capitola

Zoning/landuse areas are good to very good, but minor improvements can still be made. A zoning map was available, but this link is broken as of 2019. A "Capitola Village" landuse=retail polygon and some commercial zone wheelchair access have been added, as have city parks (all of them?) and refinements to New Brighton State Beach. The Capitola City Limit is believed to be largely correct, but may also need minor correction in places.

City of Scotts Valley

user:DanHomerick was a frequent contributor in the early 2010s. An official zoning map is available, but it does not always agree with "on the ground" reality. OSM prefers reality over zoning. As noted above, while zoning is a good first step, reality is best.

City of Watsonville

Many contributions have been made, but OSM needs volunteers to improve Watsonville! An important next set of additions are bus stops to complement SCMTD Watsonville route expansion: OSM needs highway=bus_stop nodes added east of Seacliff and south of Aptos, along Airport and Freedom Boulevards.

See Also

Contributors in the county

  • user:stevea has done a thorough job of mapping Santa Cruz, and continues to refine/edit throughout the county, notably 2010 CaSIL park and county boundaries, 2009, 2013 and 2019-2022 SCCGIS landuse polygons, 2017, 2019 and 2022 CPAD conflation, ongoing TIGER cleanup, CycleNet bicycle routes, rail improvements and temporal updates.
  • user:srmixter has done numerous landuse zones both manually and with the shp2osm script.
  • user:Apo42 has added official state parks and open spaces to the county, in addition to CaSIL-based county boundaries.
  • user:DanHomerick has added and refined areas in the central and northern portion of the county.
  • user:fudsnottica contributes lane data, business updates and more.
  • user:joeybab3 adds UCSC details and mapping around Santa Cruz.
  • user:adelman has edited in the central and southern portion of the county, especially improving mountain bike trails.
  • user:njaard contributes to especially the northern portion of the county, including new business node and commercial district entries.
  • user:Michael_SFBA makes many park and nature path trail contributions.
  • user:manduchi and his students of Computer Engineering 80A at UCSC make many important mobility, handicapped access and public transport contributions (crossing types and locations, tactile_paving, bus_stops)....
  • user:peterm95018 makes maps.ucsc.edu work using OSM data.
  • user:hrutten contributed mightily to the effort to display ADA-compliant wheelchair routes at the UCSC campus.
  • user:Bike Mapper makes many contributions regarding mountain bike paths in the South Bay (SF Bay Area) and Santa Cruz Mountains areas.
  • user:Adamant1 adds buildings to Boulder Creek and refines the area.
  • user:idkwhatname2use adds rail data along abandoned rights-of-way.
  • user:StellanL is less active locally now, but has made many local contributions in the past, and is active in the Greater SF Bay Area.
  • user:balrog-kun, user:yellowbkpk, and especially user:DaveHansen have all made important contributions in the "early days."