Added to OpenHistoricalMap in https://www.openhistoricalmap.org/changeset/95544

Added more of Heinlenville in https://www.openhistoricalmap.org/changeset/95544 and Pinoytown in https://www.openhistoricalmap.org/changeset/95545

Thought you might be interested to know that one map style was rendering these emoji, though ideally it would render something more faithful to the logos:

https://github.com/ZeLonewolf/openstreetmap-americana/issues/451#issuecomment-1169406462

This also removed “name=Purchase Parkway” from many but not all of the ways, resulting in haphazard rendering in the OSM Americana style.

These refs are unsignposted and were already in unsigned_ref.

changeset/142685666

Hi, the Route Number field (ref key) is only for signposted route numbers. The route numbers you added were already present, but in the unsigned_ref key so that they wouldn’t confuse motorists who are looking at signs on the ground.

Hi, thanks for detailing these historic neighborhoods. It would be better to add this detail to OpenHistoricalMap – not only the place POI but also the streets and buildings. Here’s a starting point: https://www.openhistoricalmap.org/node/2106979221 I’d love to have your help in building up coverage of this historic area of town.

changeset/142595843 promotes the minor through streets to highway=tertiary.

changeset/142589542 adds the apartment buildings’ addresses and also restores the overall development’s landuse area, which had gotten conflated with the plot next to the park where the Center for Creative Arts is being built.

I don’t consider the Wikipedia links to be essential, but for completeness’ sake since they have been added:

• Created <https://en.wikipedia.org/wiki/Heinlenville> and <https://en.wikipedia.org/wiki/San_Jose_Department_of_Parks,_Recreation_%26_Neighborhood_Services> as redirects to less specific articles with the hidden <https://en.wikipedia.org/wiki/Template:R_with_possibilities> tag.
• Added these titles to <https://www.wikidata.org/wiki/Q123023841< and <https://www.wikidata.org/wiki/Q106709038>, respectively, as “intentional sitelinks to redirects”.
• Retagged the park with these titles in changeset/142589542.

Hopefully any validator or bot that tries to reconcile the Wikipedia and Wikidata items will recognize that the redirects are intentional and not a signal of tagging inconsistency.

Thank you for taking an interest in this neighborhood!

I agree that many of the city’s parks lack an address [1], but this park has a different address than either of the apartment buildings in the complex [2], because the block was subdivided into parcels with addresses long before the park was built.

[1] https://www.sanjoseca.gov/your-government/departments-offices/parks-recreation-neighborhood-services/parks-trails/search-parks-playgrounds
[2] https://www.sanjoseca.gov/Home/Components/Calendar/Event/6502/

Fallbacks don’t always work well, because bots go around replacing the more specific Wikidata tags with less specific ones based on the Wikipedia tags (e.g., changeset/140125562).

changeset/142281921 removes the route and merges the stations with still-extant features on the ground. Please do let me know if you’d like any help contributing this information to OpenHistoricalMap.

This changeset discarded a more precise Wikidata item in favor of a less precise one based on a Wikipedia article that covers multiple topics. The topics are covered in a single article because the individual topics are not considered notable enough by Wikipedia standards. To prevent this issue from arising in the future, the relevant Wikidata items have all been edited to be instances of https://www.wikidata.org/wiki/Q21484471 or have intentional sitelinks to redirects on Wikipedia.

changeset/142356249

I see what you mean about those intersections being undivided for a similar length. If they were modeled as single carriageways, it would probably be OK, but you’d have to update a number of lane-level tags accordingly.

The main problem with dividing the Beechmont intersection into a dual carriageway is that, even though mainstream routing engines can collapse the a divided intersection into a single point, that functionality won’t be able to handle a complex intersection this complex. Additionally, you had extended the link ways to the beginning of the turn lanes, causing the lane counts and lane change restrictions to become inaccurate.

Fortunately, most intersections aren’t this complex. A good rule of thumb is to use a dual carriageway whenever there’s a median and avoid a “braided” look due to gaps in the median that exist only due to turn lanes.

The intersections at Jager and Nimitzview are modeled as dual carriageways as an exception to the physical separation principle, as detailed in osm.wiki/Dual_carriageway

I agree that this may not seem very consistent, but this is what data consumers have come to expect at this point. If you’d like to clarify the situation, you can map the traffic islands and even the roadway as an area: area:highway=*

Reverted per osm.wiki/Dual_carriageway ; will reapply any necessary realignment.

changeset/141742251

Reverted per osm.wiki/Dual_carriageway ; will reapply any necessary realignment.

changeset/141742188

Hi, thanks for reviewing this intersection. Note that any separate link way for a turn lane should begin at the “gore”, where a physical barrier begins, not where a solid painted line begins. The change:lanes tag is how we indicate a lane change restriction. change=* This tag doesn’t have a dedicated field in the Web-based iD editor, but you can open the Tags section at the bottom of the left sidebar to see it. Let me know if you have any questions about how that works.

changeset/141657991 adds the appropriate tags and cuts a gap in the road to ensure that routers won’t send drivers into the tree or into the creek.