My pleasure to help. Good communication between contributors, especially as we share deeper experience (like that a service=driveway is for a single residence) makes for a better map!

It is osm.wiki/Talk:United_States_admin_level where a section ends with

"The bottom line: it has emerged as consensus that COGs, MPOs, similar "special purpose districts" and statistical areas defined by the US Census Bureau are tagged with neither boundary=administrative nor admin_level=* of any value."

There is a reference in that section to talk-us discussion to bolster this conclusion: http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010066.html .

BTW, there is no @ before my moniker here.

Unless and until there is recent consensus on what it is best to change these boundaries TO, leaving them at a "status quo as agreed to in 2017" seems best. They are not "mass" changes, as while the number of ways seems large, this is only some modest tagging distinctions (according to our wiki and consensus) across two small states, none of the actual boundaries were changed. (If many of the boundaries were changed, that might be "mass changes," but it wasn't, so this isn't).

Unless and until there is recent consensus on what it is best to change these boundaries TO, leaving them at a "status quo as agreed to in 2017" seems best. They are not "mass" changes, they are changes to eight relations, and only some modest tagging distinctions (according to our wiki and consensus), none of the actual boundaries were changed. (If many of the boundaries were changed, that might be "mass changes," but it wasn't, so this isn't).

Unless and until there is recent consensus on what it is best to change these boundaries TO, leaving them at a "status quo as agreed to in 2017" seems best. They are not "mass" changes, they are changes to nine relations, and only some modest tagging distinctions (according to our wiki and consensus), none of the actual boundaries were changed. (If many of the boundaries were changed, that might be "mass changes," but it wasn't, so this isn't).

Unless and until there is recent consensus on what it is best to change these boundaries TO, leaving them at a "status quo as agreed to in 2017" seems best. They are not "mass" changes, they are changes to nine relations, and only some modest tagging distinctions (according to our wiki and consensus), none of the actual boundaries were changed. (If many of the boundaries were changed, that might be "mass changes," but it wasn't, so this isn't).

Unless and until there is recent consensus on what it is best to change these boundaries TO, leaving them at a "status quo as agreed to in 2017" seems best. They are not "mass" changes, they are changes to nine relations, and only some modest tagging distinctions (according to our wiki and consensus), none of the actual boundaries were changed. (If many of the boundaries were changed, that might be "mass changes," but it wasn't, so this isn't).

It would be helpful if you say what, specifically, you believe is wrong. There is a rather messy Discussion going on at osm.wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted which indicate "it was started" by Mashin.

I have used name_absent=yes to replace Name=Unknown Name from an import, so I think I understand something about the edge.

OSM is a database. It isn't about how Standard rendering looks, but I'd say it looks pretty good and the recent improvements are appreciated!

I don't know about this one. If you know the name, please enter the name in the database using the name= key.

Well, that's "OK" and maybe not perfect (you didn't see a street sign, for example), but because it serves four (rather than one), I'd hold off on the service=driveway tag. At least you've got the highway=service road, so "OK/fair."

In future, as you add these highway=service ways, it does make sense to add service=driveway if it is one of those (serving exactly one single residence). If you notice a street-sign, changing to highway=residential and adding name=name_on_sign is correct.

OSM can be like this: get something 80% correct upon entry (though, do strive for 90%, 95%, or even 100%), then it gets incrementally improved in subsequent updates.

Thanks for your good mapping.

I appreciate the addition of this highway=service, especially that you added a barrier=gate tag on a node that looks geographically accurate.

However, if this is really a driveway (if ANY of these highway=service roads you and Amazon Logistics adds is really a driveway), may I please ask you to ALSO add the tag "service=driveway?" That would really make it much more complete and correct. Thank you.

It really is complicated. I find a lot of people tag "leisure=nature_reserve" as it "sort of" renders (name, lacking color) "better than nothing" (or common, which is deprecated, or park, which is so contentious I burned my fingers trying to sort it out by being banned from wiki-writing for 15 days a year ago). Much of that stems from "park" being different in British English and US English, but the result is that it is still contentious, misunderstood and no truly good consensus has emerged about what to do with all of this.

I've tried to help with United States/Public Lands wiki, but that is very much "wet clay" and horribly complex, too.

Harrison and I have exchanged missives, and what these really are isn't well-wiki-documented either: they are HOA "strips," land that homeowners associations have been "mandated" by local ordinance to both be owned by the association, yet still be opened to the public "like a park." Bizarre, yet what Morgan Hill does (and I say that from the perspective of a decades-long property owner in a neighboring jurisdiction one county away).

It is a long way from an ideal situation, but I think with discussion / dialog (here, in missives, in talk pages...) we can get closer. It may be "Zeno's Paradox closer," (meaning we never actually REACH the goal, but we do get ever-closer), but that's better than the alternative.

Thanks for good dialog, phidauex.

Careful, Harrison: what you are doing is called "tagging for the renderer," which is heartily discouraged in OSM.

If this is really a leisure=common, it should be tagged as such (and was, but I'm not sure what it really "is"). If it really is a park (please read osm.wiki/Park as it isn't what we American's call 'park') as OSM defines it, this tagging you have done is OK. (I'm personally just not sure).

The point is, be sure you are tagging accurately (with tags that mean what OSM's wiki says they mean) rather than tagging because you want to see them render a certain way (which we shouldn't do).

Keep mapping, have fun!

Hm, was it something I said?

I (also) welcome further Discussion at osm.wiki/Talk:California/Using_CPAD_data#.22Foreign.22_tags

Two small classes of plastic keys, which slightly buzz and glow with slightly different nomenclature over the years of many versions, used efficiently to identify and checksum data relatively human and computationally efficiently, well, it works.

OK, so we're good with OBJECTID and sccgis:objectid, yes? Let's also allow (because it is true) that over a decade-plus of integrating our public data into OSM (updates happen every few weeks to few months) thousands of polygons from that source being compared to their data in OSM can be tedious to compare. The Shape*, SHAPE* and cpad:acres tags make this a numeric comparison rather than a very tedious visual one. (Visually comparing a slightly modified polygon with its original by algorithmically matching theirs geometries is MUCH more computationally difficult than simply comparing a numerical value used as a checksum.

True, these keys have changed over the years, OSM learns to cope with these, especially by wiki-documenting.

I have heard and agree with similar (local, regional, national in the USA...) import discussions which express concerns about "foreign keys" making their way into OSM. This really has been minimized in the cases of SCCGIS and CPAD data curation in OSM. However, given the "good data science" arguments of "id" (which we seem to overtly agree with) and "checksum" (which I ask you to consider as many other have, and have come to agreement with), I hope we can agree here as well.

No software is able to handle them all. Humans use them to determine versions of data which are updated over time. Polygons such as these have been imported and/or curated into OSM for over a decade over many, many versions. The *ID and Shape* tags allow humans to much-more-easily determine whether data in the OSM database have changed relative to a newly-published version of data by the government GIS agency who publishes them.

Makes sense?

It is Kleene-star (regular expression syntax) mention as the last two sentences: "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) tags of Shape* and OBJECTID."

I hope that helps.

The other place where something similar is done is documented at osm.wiki/California/Using_CPAD_data .

The tags are mentioned at the very end of this section of the wiki page, just before the beginning of the next section (Parks).

Tagging leisure=nature_reserve is an older, still valid tag for a "less specified" area (as are these) compared to the newer tagging of boundary=protected_area (and protect_class). I am very, very familiar with this and am involved in discussions on tagging mail list as well as wiki writing / collaboration as in osm.wiki/United_States/Public_lands .

This is all horrifically complex and I'm not going to worry about the very subtle distinctions between a leisure=nature_reserve vs. a boundary=protected_area where I have to spend a lot of time determining which numeric value of protect_class is correct, as leisure=nature_reserve is "close enough."

At least in the USA, the subtle distinctions between a leisure=park (it is, in fact, a "park district" which administers these lands) and leisure=nature_reserve AND a boundary=protected_area do often blur. Part of that is American English's dialect use of the word "park" which is distinct from what OSM (and its predominantly British English leanings) means by leisure=park. A year ago, I got hung out to dry by being banned from wiki writing for a short time trying to iron out some of these semantic differences.

If you think you know better tagging on areas in my backyard, then please tag them better than I do and I'll say I appreciate you contacting me first before you do. However, I am aware of many of the semantic, political, tagging, consensus, local and OSM-global issues going on here. Maybe you are, too, in which case, I'm glad to have you as a member of the ongoing conversation.