Hello Bill. Please source the data you use to enter USBR 66 in California. I'm quite familiar with tagging this and I don't think you can tag a route as you have here: it is only an early sketch of a route, proposed, and not signed on the ground. Please explain your intentions. Thanks, SteveA.

Bill, I do here and now ask what are your sources for putting in USBR 95 into California. This route isn't even proposed, and/or you may be conflating the ACA's route of a similar name to be a USBR 95 which is not even a Caltrans ballot before AASHTO.

Awaiting your reply, and these data (specifically inclusion of these segments in the route relation) implies you have seen some signage on the ground to mark the route. I don't mind that, but it would be what Caltrans calls PCBR and you could put tag name=PCB in the route relation. But inclusion of these segments in a route relation for USBR 95 as you have with ref=95, nope, nah-ahh, until you source these route data. Thanks, SteveA.

OSM does not name "private property" the way you have. Please remove these tags.

Hi dwl-sdca: Might I ask you to read up on our wiki page for access=* before you use a tag like access=restricted on roads like these? The value "restricted" on the access tag isn't documented. Please consider changing this to access=no emergency=fire. Or, if it is truly private, access=private emergency=fire. Also, the name=* tag shouldn't contain " (private/emergency)" as name=* only should contain a name, not other data. Thank you.

Whoops, no. Thank you for catching this! Of course, I'm perfectly OK with any correction that you might make to this. As well, I'll look out for any other, similar mistakes I have made and correct them.

It's a bit complicated. If you haven't already, please see our wikis for both United_States_admin_level (especially cite_note=49) and WikiProject_United_States/Boundaries (especially the USMOI note in Notable exceptions).

As far as admin_level needing to be "something," as noted in the US/Boundaries wiki, it suffices that each island is U.S. territory surrounded by territorial waters, delineated admin_level=2. So, for example, something like http://layers.openstreetmap.fr shows "USA territorial waters" surrounding each island (if you have the admin_level=2 box checked).

You are probably correct, as those wikis state that these ARE statistical boundaries. As each member of the relation DOES have an admin_level=2 tag, it all works out, but cite_note 49 does request that we keep the relation. Yes, we should, but if you strongly believe that it shouldn't have a boundary=administrative tag and want to change that to (user-defined, yes) boundary=statistical then I don't have a problem with that. Thanks for bringing this up.

Thanks for everybody's good communication here. They do put erasers on the ends of pencils, as we all make little errors now and then! (Don't sweat the small stuff; it's all small stuff). Happy mapping to you as well, stevea

Oops, used an old changeset comment. It should be "Meadows SW of Gilroy."

Ian, please check your "missives Inbox."

hey, oormilavinod. I appreciate your welcome, though I've been an OSMer for most of the project (>8 years), I was named Mapper of the Month earlier this year, and presented talks at SOTM-US conferences in 2014 and 2016.

What road, exactly did I "pull?" I am usually quite careful when I edit, but it is possible I made a mistake with a pulled road. If you identify it (with a link, not a name), I will fix it, as I am local to this area.

Thanks for calling this to my attention (though I'm still not sure what road is wrong), Steve

Nice work, Minh and everybody involved!

I think you should change (fix!) your tripplanner then. Not make changes to the map data which make a accurate tags no longer true. Please revert this change and fix your software, not tag the data with lies so you don't have to.

Thanks for the detailed explanation, Minh, though I believe you walk a very fine line here.

So, am I understanding you to say is that tagging what the signs say is "wrong" (or less right than"on the ground verifiable") and that what the name tag SHOULD say for corporate consumers of OSM data (like Mapbox and Foursquare...) is what corporate consumers of OSM data like Mapbox and Foursquare WANT it to say? Even when "lowly" users like me not in the know how OSM data "might" be used by its corporate consumers?

Gee, that seems odd.

Really, Minh? OK, if you think this is more correct. Are you sure you're not checking on many of or all my edits since 2009? I do live here and see the signs (I was just driving this stretch of highway TODAY), but if you want to "localize" this and call the whole stretch Cabrillo Highway The Cabrillo Highway, OK, you got it. And "official_name"? Is that something you coined?

OK, I loaded your link into JOSM as a WMS layer (thanks). I appreciate your clarification, as you have "realigned" my assumption that this is an import, rather it looks like you are simply using a WMS layer.

By the way, do you have any plans to trace more (or all) buildings in Santa Cruz or any particular subset? I ask because there was some recent talk-us chatter to use recent Bing data (over much of the West Coast) to do the same, but it is a HUGE import project.

I've been mapping in OSM locally (and elsewhere) since 2009, be welcome to look me up! Cheers, Steve

Your source tag is a bad link; please correct it. Also, this appears to be an import. Where are your Import Guidelines steps documented?

What a colossal flustercluck. I am reverting.

What a colossal flustercluck. I am reverting.

What a colossal flustercluck. I am reverting.