Using CPAD data
The California Protected Areas Database (CPAD) data published by GreenInfo Network, downloadable from here and noted in our Contributors page are slowly but surely being incorporated into OSM. This includes all protected as permanent open space lands in California: 15,000 parks and preserves owned by over 1,000 agencies/organizations.
The data are a zipped shapefile, unzip them and have the opendata plugin installed into JOSM to open them. From CPAD 2019b, here is a typical single-item datum (part of an Open Space Preserve in Santa Cruz) as the various tags found on the polygon:
ACCESS_TYP=Open Access ACRES=492.2348748251647 AGNCY_ID=1320 AGNCY_LEV=City AGNCY_NAME=Santa Cruz, City of AGNCY_TYP=City Agency AGNCY_WEB=http://www.cityofsantacruz.com/departments/parks-recreation CITY=Santa Cruz COUNTY=Santa Cruz DATE_REVIS=2006-01-31 DES_TP=Local Conservation Area GAP_STS=2 HOLDING_ID=2298 LABEL_NAME=Pogonip OSP LAND_WATER=Land LAYER=City MNG_AGNCY=Santa Cruz, City of MNG_AG_ID=1320 PARK_URL=http://www.cityofsantacruz.com/departments/parks-recreation/parks/open-spaces/pogonip SITE_NAME=Pogonip Open Space Preserve SRC_ALIGN=PARCELS SUID_NMA=12041 UNIT_ID=18677 UNIT_NAME=Pogonip Open Space Preserve YR_EST=0 YR_PROTECT=0
That's a lot of data! Most of these are "internal to CPAD" and don't logically map well to any specific OSM tags. Some, however, do. Others, especially UNIT_ID and ACRES are useful to include in the data: UNIT_ID is useful as it allows a unique identifier from CPAD, and ACRES is useful as a sort of "checksum" of the data. What is meant by "checksum" is that a particular datum might change from version to version of CPAD, but this might be a very small or subtle change and isn't readily apparent or easily visually identifiable. But if there is a change between CPAD versions, the ACRES value will almost certainly change, especially out to one of its many digits of precision.
Generally area sizes from shapefiles should not be incorporated into OSM. Please see the newly-created Talk page for Discussion about this.
Suggested tag-migration protocol
So, which tags to keep, which to delete? Here are suggestions:
|CPAD Tag||Action||New OSM tag=value|
|ACCESS_TYP||Keep||Change to access=*. If "Open Access" set value "yes" if "Restricted Access" set value "private" if "No Public Access" set value "no" if "Unknown" set value "unknown"|
|ACRES||Special||Change to cpad:acres=* with the same value. If multiple "sub-units" are coalesced to form a larger unit, delete these differing ACRES tags.|
|AGNCY_LEV||Keep||Change to ownership=*. If "Federal" set value "national" if "State" set value "state" if "County" set value "county" if "City" set value "city"|
|AGNCY_NAME||Keep||Change to owner=* with the same value|
|AGNCY_TYP||Special||Usually, delete this, but see DES_TP, below|
|AGNCY_WEB||Special||Change to website=* with the same value, unless there is a PARK_URL which differs (if so, delete this tag and see PARK_URL). If empty, delete.|
|DES_TP||Optional||If you wish, and it distinctly adds clarity to "what this is," change to description=* with the same value. If you include AGNCY_TYP here, too, semi-colon separate the values.|
|MNG_AGNCY||Keep||Change to operator=* with the same value|
|PARK_URL||Special||Change to website=* with the same value, unless this value is empty, then set AGNCY_WEB to website=* instead|
|UNIT_ID||Special||Change to cpad:unitid=* with the same value. If multiple "sub-units" are coalesced to form a larger unit, delete these differing UNIT_ID tags.|
|UNIT_NAME||Keep||Change to name=* with the same value|
|YR_PROTECT||Special||If 0 (zero), delete. If non-zero, change to start_date=* with the same value|
Add an additional OSM-specific "physical" tag, like leisure=nature_reserve or boundary=protected_area (plus the proper protect_class=* value). The choice of which tag(s) to add is at the discretion of the author, but do strive to tag consistently with documented uses. See (the emerging wiki) United_States/Public_lands for additional suggestions: these are intended to follow regularized tagging protocols as documented there.
Applying these suggestions, this results in the following tags on the polygon in OSM:
description=Local Conservation Area
name=Pogonip Open Space Preserve
operator=Santa Cruz, City of
owner=Santa Cruz, City of
In this specific example, other sub-unit polygons were coalesced together to form a larger cohesive unit, so there are neither cpad:unitid=18677 nor cpad:acres=492.2348748251647 tags. If this were an isolated (multi)polygon, there would be these tags.
Some might explicitly add source=CPAD 2019b to each datum, but it is a more modern convention to enter this on the entirety of the changeset during upload (JOSM has "Specify the data source for the changes"), where this may simply be set to "CPAD 2019b" (for example).
Extraneous data found in OSM
Sometimes shapefile tags in ALL CAPITAL LETTERS 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) tags of ACRES and UNIT_ID.