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.

osm.org/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: osm.wiki/Key:area:highway

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

osm.org/changeset/141742251

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

osm.org/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. osm.wiki/Key: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.

osm.org/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.

Hi, most of your changeset comments are only a single letter long, which isn’t very descriptive. osm.wiki/Good_changeset_comments On the other hand, if you’re experiencing a bug in iD that’s truncating your changeset comments, please let the developers know at https://github.com/openstreetmap/iD/ . Thank you.

The terminology is a bit confusing; I think “pencil tip” actually refers to the style you applied. TomTom and Mapbox have historically been the main proponents of this style, though Mapbox is no longer active in mapping intersections.

As mentioned in that forum thread, routers have long accounted for the sharp turns you’re concerned about. The OSRM and Valhalla routers (used by Mapbox) average out the turn angle by looking at points further away from the intersection. Ironically, the pencil tip style sometimes foils this heuristic, as well as the heuristic for consolidating a complex intersection so you can hear “make a U-turn” instead of “turn left then turn left”.

On another level, the disagreement is over whether we should model how self-driving cars would travel through the intersection, or hew more closely to the physical separation principle. One reason mappers in California have complained about the pencil tip style is that it makes it difficult to distinguish the small traffic islands that are commonplace at an intersection. This is not so interesting to self-driving cars perhaps, but mappers are trying to think of a broader range of possible uses for the map.

I appreciate your openness to feedback. I would suggest continuing this discussion in the forum thread, because a changeset comment thread is unlikely to result in any broader changes anyways.

Please be careful remodeling intersections to include dual carriageways. This changeset appears to have broken a number of route relations. Additionally, the “tuning fork” or “pencil tip” modeling that led to this breakage is controversial globally and not preferred among mappers local to California. https://community.openstreetmap.org/t/pencil-tip-intersections/1512

Moved to OpenHistoricalMap in https://www.openhistoricalmap.org/changeset/86325 and deleted from OSM in osm.org/changeset/140958637

Chào bạn, các giá trị như VN:CT và VN:QL thật có lý, nhưng các thay đổi này làm cho các bản đồ như OSM Americana không còn nhận ra các tuyến đường QL/CT để hiển thị số đường đúng màu. Dĩ nhiên có thể cập nhật OSM Americana nếu cộng đồng muốn sử dụng các giá trị này. Để tránh vấn đề mai mốt, tôi đã đề nghị thống nhất các giá trị này trong nhóm Facebook; xin bạn tham gia cho ý kiến. https://www.facebook.com/groups/openstreetmapvietnam/posts/1653123425098640/

Did you mean to tag this entire building as a McDonald’s flag?

To get started with OpenHistoricalMap, go to:

https://www.openhistoricalmap.org/

You can find out more about the project at:

osm.wiki/OpenHistoricalMap

Hi, thank you for taking the time to contribute this historical data. Unfortunately, historical data is ineligible for inclusion in OpenStreetMap. The good news is that our companion project OpenHistoricalMap welcomes historical rail data and is better suited for it. Would you mind contributing this information there instead? Let me know if you need help undoing the changes you’ve made here in OSM. Thanks for understanding!

Hi Pete, thanks for all the wonderful contributions you’ve made in this area. Have you considered contributing some of this historical information to OpenHistoricalMap as well? osm.wiki/OpenHistoricalMap There’s so much left to map over there that would complement the details here.

Hi, looks like this changeset included a few buildings that are identical to each other, in the exact same spot. I’m not sure how that happened, or why RapiD didn’t warn you about it when you added them in from the Microsoft Buildings dataset. Anyhow, changeset 139895241 deletes the two redundant buildings. If you see this kind of thing happen again in the future, I’m sure the RapiD team would welcome a bug report.

Fixed in changeset 139067157.

Removing ref=RM 1431 was incorrect. It hasn’t been FM 1431 since 1956.

If you want a relation representation for this road, there is an experimental “street” relation type, though you’d have to manually replace type=route with type=street in iD.