I originally didn’t intend to map bike route 11 in this changeset, but as I went looking for the “Welcome to San Jose” archway along Monterey Rd. (which sadly seems to have been taken down), I encountered the BEGIN and END signs for bike route 11 at the San José/Morgan Hill city limit.

The bike route 11 signs are visible all along the road in Mapillary imagery (going southbound) and OpenStreetCam imagery (going northbound). I used the Mapillary sign layer to more easily locate the signs, and the Mapbox layer was just on as a matter of course. (I used that layer for pinpointing city limit signs that I came across, also in this changeset.)

Bike route 11 is San José’s first signposted crosstown bike route. http://www.sanjoseca.gov/DocumentCenter/View/5417#page=2 To my knowledge, other routes that have been entered so far are only found on maps published by VTA and aren’t officially numbered. So I’m considering removing the refs from those routes.

Toy cars or tricycles, rather.

I think it’s intended for toy tricycles or something along those lines. It’s part of a playground.

Please do not move the location of a motorway_junction as in this changeset at the 101/87 interchange. The freeway had already been mapped with turn lanes, but this changeset incorrectly moved the beginning of the ramp to before the beginning of the turn lane, effectively deleting the turn lane data from the map as far as routers are concerned.

The motorway_junction node should be placed no sooner than the point at which the ramp begins to split from the main highway. Use the turn:lanes tag to indicate a turn lane that hasn’t split from the highway yet.

Yes, that’s what I meant to do. Thanks!

The admin_level=4 tag was intended to clarify that this boundary=national_park does not, in fact, represent a national park but rather a state park. With the removal of the admin_level tag, it may be necessary to indicate its lesser importance in some other way, such as a different boundary tag.

Unfortunately, Mapillary sign detections can be unreliable, too. In my experience, in an urban area, you end up always having to check out the actual Mapillary imagery, using the sign overlay only as a guide.

I was going through speed limit sign detections in this neighborhood last night (which is how I stumbled upon this change), and there were spurious speed limit detections that were actually phone numbers on business signs or even the little signs above beg buttons at crosswalks.

The locations can also be way off. Code for San José contributed side- and rear-facing imagery as well as front-facing imagery, so Mapillary gets confused by a side street’s speed limit sign in peripheral view.

Did the note say this road has a 15 mph speed limit? That would’ve been mistaken; the road actually has a 30 mph speed limit. I wonder if the author of the note had gotten confused with the light rail speed limits near here.

Are you sure the location of the label should be over city hall in each of these cities? In some cities, the commonly accepted center of the city is a public square or beginning of the street grid.

What in Sam Hill is going on here? I’m seeing comments between you two flying by in the changeset comment tracker and it really stands out among the constructive comments that otherwise turn up. Clearly, there are hurt feelings and a total breakdown in trust.

I’m not even sure I want to know who originally started this whole flamewar and where, but the ad hominem attacks, name-calling, backhanded compliments, etc. need to stop. Both of you have been contributing to this project long enough to know that the tone of this discussion is inappropriate. With the decentralized nature of communications in this project, there’s not much point in anyone blocking one or both of you; you’d just migrate elsewhere. But it would be a shame if you get burnt out and stop contributing and even worse if your dispute discourages others from contributing too.

I’d encourage you both to take a break – from communicating with each other, from discussing the tags that you’ve been disagreeing over, even a temporary break from OSM – whatever it takes to get past this episode. Take the long view: in a month, will you be proud that you won the argument or frustrated that you spent so much time and energy doing so? In five years, will you feel as strongly about your differences over these tags? Tags could look totally different by then!

(A consensus one way or another, that is.)

That tagging style was also discussed elsewhere at the time, for instance on talk-us: https://lists.openstreetmap.org/pipermail/josm-dev/2013-November/006781.html .

I understand the downside you’re describing, but as it happens that page has been pretty influential, as seen in https://taginfo.openstreetmap.org/relations/route#roles . Though this tagging style isn’t universal among U.S. mappers, it’s clearly more widespread than an individual change by Kristen, so we should discuss it more widely as a community. Maybe we’ll finally come to a consensus about it.

Due to an edit conflict with changeset/69492678, this changeset broke the TAH 7 route relation in many places. changeset/69497394 fixes the route relation.

Cardinal directions as relation roles are one widespread tagging practice in the U.S., as documented at osm.wiki/Highway_Directions_In_The_United_States . OSRM is one example of a routing engine that makes use of those roles in guidance instructions. That said, it can sometimes be problematic to use cardinal directions as roles on surface streets, which may not always be divided and may only travel in one direction along a two-way street. The alternative of relations and superrelations (with direction tags on the relations) addresses that ambiguity.

Paul, if you feel strongly that directions should not be used as relation roles, perhaps it’s worth starting a discussion on the talk-us and/or tagging mailing list about it, laying out the pros and cons of each approach.

In general, the AA Highway should be highway=trunk, considering its importance and partial access control.

Thanks for adding more detail about this church. After drawing the building, instead of choosing “Building” from the list of presets and naming it “Church”, search for the preset named “Church”. In this case, there was already an existing POI for the church, so you can merge the POI into the building by selecting both, right-clicking, and choosing Merge.

I noticed in the Bing Streetside imagery from 2012 and Mapillary imagery from last year that the signs say “San Jose Vietnamese Seventh-Day Adventist Church”, not “Greater Church of Jesus Christ”, so I changed the name in changeset/69138615. Is that correct, or do people still refer to it as “Greater Church of Jesus Christ”?

Deleted in changeset/68885799.

Hi, thanks for all your edits in the area lately! Regarding this particular change, OSM’s guidelines for classifying places is intended to apply evenly across jurisdictions, even internationally. So even though Belpre counts as a city according to Ohio law, it technically only qualifies as a place=village in OSM based on its population. A place=city would have to be the focal point of a metropolitan area, such as nearby Parkersburg. You can read more about the guidelines at osm.wiki/Ohio/Map_features#Places .

Despite the guidelines, I retagged Belpre as a place=town in changeset/68710661, because of its significance as a major river crossing. Meanwhile, the Belpre POI is a member of a Belpre boundary relation that is tagged border_type=city; that tag correctly indicates the place’s legal status.

Hi, thanks for your contributions in San José. Please use the “Golf Cartpath” preset instead of “Unclassified Road” to represent golf cart paths through a golf course. This distinction keeps routers and navigation applications from telling car drivers to drive along golf cart paths. Thank you!