Thank you for your opinions.

Think of ACRES as a kind of checksum of the data, as that is how it gets used (for comparison purposes between versions of data).

Going forward (and backward, as it has been included for exactly this reason), in time, UNIT_ID is a highly-useful tag to "index" between various versions of CPAD data (so far we are up to a third, though we no longer call them v1 / 2016a or v2 / 2018a, as no v3 was coined with 2019b, we now simply say "CPAD 2019b" and will do that going forward). So, please do continue to expect to see UNIT_ID in these data, it isn't unreasonable to include this for these reasons, so we do. (When I say "we," I include many local California-based OSM volunteers who use and coordinate CPAD data into OSM, such as doug_sfba, with whom, among others, I/we coordinate these activities).

ACRES is often included because the most common thing to change from version to version is the area-size of the unit, and the value of this key changing is a clear indication this happened (and so older data should be updated with the newer data). If a unit's shape changes in a subtle way, that can be hard to see visually, but this always will change the ACRES value, even by a tiny amount, so the many-digits of precision are helpful, perhaps even crucial to detect this. Several bytes of data are not "an unrealistic number of decimal digits," as this technique of using area to detect subtle changes in version-to-version data is both clever, effective and relatively low-cost (in terms of data stored).

The keys included may be undocumented, true, but there is no secret where they come from, why they are included (to wit, this and other changeset comments like it). Obviously you have noticed that as we begin our third (only partial, only carefully) bringing-into-OSM of these data (it's not an import, more like a one-at-a-time curation), there is some evolution of process, and that has included leaving in tags which do not (always) map well to documented OSM tags. Also, OSM tags (like park, national_park, natural_reserve and protected_area) have evolved, too, over the years, so it's very much like "changes chasing changes."

Again, I have said here and in wiki, "where objectionable, the tags may be removed" as well as "a few stray tags here and there as we evolve a process to better improve protected-areas in California are not a major problem." I've documented, I answer politely in changeset comments, I do not keep secrets nor am I trying to "get away with anything" as we do these things. Don't like the tags? Remove them, please. I (and others) don't seem to find them a problem.

They are from CPAD 2019b data, as documented on our Contributors and Santa_Cruz_County,_California wiki pages.

While I endeavor during these additions to remove all tags (except sometimes ACRES and usually UNIT_ID, so that we may compare between older CPAD, OSM versions and newer CPAD versions of the data), other tags (like the ones you mention) can and should be removed.

As the latter wiki mentions, "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."

I have been and do "better tag" on these. However, I don't see some stray tags finding their way into our map as a major problem. You are welcome to delete these, too. I appreciate you calling them to my attention.

CPAD data are under construction with the collaboration of other OSM volunteers in Santa Cruz, Santa Clara and San Mateo counties. We're now on on our third version of these (2019b) and the UNIT_ID allows us to compare particular units. You have mentioned to me that ACRES can be computationally computed; our Santa Cruz County wiki states "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." I don't consider ACRES "a mistake," but you might.

Yup, that's how it's done. You're welcome and keep up the great work! (GL w/finals)

It's like bricks in a wall, you think you'll never count to a million or a billion, then you realize you have a million brothers and sisters. Voilà, an ever-better map!

All, right! Go, man, GO!

The rail elements in the route=light_rail are changed from railway=rail to railway=light_rail.

Despite the service being DMU instead of electric, everything about this says "light" rail instead of "heavy," (which would lead to a route=train for the passenger service, but it isn't, it is route=light_rail). The concomitant train=yes tags (on stations, transit centers, platforms) are now light_rail=yes

Now, finally, the question confronts us: do we change the elements of the Escondido Subdivision from railway=rail to railway=light_rail where applicable? Following the example of the San Diego Trolley's three infrastructure lines (Blue, Orange, Green, though there is also a Silver passenger route on these), I would say "yes, we should" make these changes.

It would be good to definitively know if/when there actually is any freight service on the Escondido Subdivision, the "Freight Bypass Tracks" and minor amount of freight-appearing rail just past the Escondido Transit Center notwithstanding.

I have changed relation/1371791 back to route=light_rail (from route=train). Everything I know and can find about this calls it a "light rail" and calling it a train (as in heavy rail) seems incorrect to me.

Wiki changes made yesterday were backed out (to re-reflect it is light_rail, not train). The "service=commuter" tag on the relation was deleted, as this key:value pair isn't wiki-documented and doesn't make sense in the better-established context of the "passenger=urban" tag (which does make sense and is wiki documented).

While the route is still PTv1, some platform elements (as in the richly-tagged Escondido Transit Center) do begin an ability for upgrading to a fully PTv2 route, but other intermediate platforms will need to be added to the map and this relation.

relation/6161003 (Escondido Subdivision) seems fine — it is even additionally stitched into local transit as a bus_route.

relation/1371791 (SPRINTER) was updated with the text of the change in the wiki. In short, this route=light_rail is now a route=train and is documented in the wiki as so. Keeping eyes open here, as this is a curious edge of California/Rail: the distinction between a light_rail and a train route.

I agree with your analysis and changes here. This has always been mildly confusing in my mind as to how DMU lines are best mapped, especially when the tracks are used for both a light_rail service (whether DMU or electric) AND there is also some freight on the line (as on San Diego Trolley's Orange line out to Santee and El Cajon, where there are "industrial rail customers" that use the same line the passenger trollies are on, but between 2:00 AM and 3:30 AM for their freight runs).

So, as I don't know if the SPRINTER tracks even ARE used for freight, (I don't think so, my nephew rides this line as a CSUSM student) that was my motivation: "light_rail only" made me change it. But you continue to do excellent work on rail, and if you have noticed that what I did is "incomplete" and that your newer tagging is how similar routes are mapped, then I defer to your more consistent tagging.

While realizing that the following questions mildly stray in the direction of tagging for the renderer, doesn't it seem that your style of tagging railway=rail instead of railway=light_rail would make an ORM rendering "disappear" that the tracks (as black, not green) are not readily apparent as passenger (light_rail) service? That's another motivation for me having changed it, not so much tagging for the renderer, but merely as an accurate way of seeing (say, California-wide) rail as a network and identifying where the light_rail passenger service is?

I'm still not sure which is "more correct," as I see both of our perspectives here, though I will defer to you setting it to railway=rail as we discuss this. Let's say there is no freight service here (maybe true, maybe not). Wouldn't the ORM tagging convention of "the highest or heaviest service on the line" (i.e. passenger service being "more important" than freight) suggest that light_rail "win out" over rail? We really could go either way here.

Thanks for noticing and your very polite note here! I encourage further discussion, or you might simply leave your changes as is without further discussion, though I would appreciate an answer as to the above questions.

Please cite some California law (Code, chapter, section, paragraph) which describes this "barring," please.

My apologies if it seems I shower you with endless compliments, especially recently. However, those woodland areas are simply stunningly pretty and beautifully rendered. Thank you.

You are welcome.

Look sharp, map smart, be nice, learn much.

Map well! (Ask, read wiki, be nice, stand tall...)

I haven't had a chance to look at everything comprehensively here, but thank you very much for what appears to be substantial and awesome work!

I fixed it.

Look, if you are going to edit OSM around UCSC, that's fine, as long as you don't destroy existing valid data. Please be careful, read wiki or ask (me, others, our forum, the talk pages...) if you don't understand something.

So, you've broken the wood polygon for the Pogonip. How are you going to fix that?

Thanks. This has been rather complicated for at least a decade, and it may change. Not everybody reads the county wiki, so it's easy to miss.

The root of this is how people tag differently for "landuse" (as the university is) vs. "landcover" (like wood, grass, scrub...). It is complex and has become exacerbated by what people can see in increasingly technically-better aerial / satellite imagery.

The renderers have tried to keep up with multiple -use -cover "conflicts," and again, "it is complex."

I think this / these issues are slowly beginning to resolve themselves, but the local convention at UCSC does make for a "prettier" campus (for now). In the future, there may be some wider consensus hammered out which most agree is both pretty and accurate (to that future day's tagging standards). Meantime, we sort of smear the truth a little bit. Thanks for your understanding and you are perfectly welcome to contribute additional strategies to the map or the wiki.