When a county has little or no administration, as in Rhode Island (absolutely) and Connecticut (as in "only the judiciary"), then these counties being tagged without a boundary=administrative tag is correct.

EIGHT years ago, I myself suggested that a COG-like thing in California (where I live) might be (I posited it as "might" not "is," as you did) an admin_level=5. It was determined not to be and I and OSM accepted that. You seem bent on not accepting that, yet it is documented to be true.

Escalate away.

When a county has little or no administration, as in Rhode Island (absolutely) and Connecticut (as in "only the judiciary"), then these counties being tagged without a boundary=administrative tag is correct.
EIGHT years ago, I myself suggested that a COG-like thing in California (where I live) might be (I posited it as "might" not "is," as you did) an admin_level=5. It was determined not to be and I and OSM accepted that. You seem bent on not accepting that, yet it is documented to be true.

Escalate away.

When a county has little or no administration, as in Rhode Island (absolutely) and Connecticut (as in "only the judiciary"), then these counties being tagged without a boundary=administrative tag is correct.

EIGHT years ago, I myself suggested that a COG-like thing in California (where I live) might be (I posited it as "might" not "is," as you did) an admin_level=5. It was determined not to be and I and OSM accepted that. You seem bent on not accepting that, yet it is documented to be true.

Be my guest at "escalating this," although you should know that SomeoneElse (Andy Townsend, member of the Data Working Group and with a blue star next to his name) is already involved, contributing to these very Changeset Discussions: you can't get any more "escalated" than that.

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.