Hello Non Zero Racing,

I noticed you added some bridges here (way/865808267, way/865808266) which are good details to add! When I add bridges I prefer to split existing ways instead of adding new ones. Splitting retains details like the `oneway`, `name`, `surface`, and `lanes` tags. In iD editor the scissors icon allows you to split ways and retain the existing tags. It also helps maintain relations like the bus routes along this road (relation/2662847, relation/2662848). Before I upload, I also like to use the validation tool (osm.wiki/ID#Validation) which helps identify unintentional issues like disconnected ways that are easy to overlook.

Thanks for your contributions to OSM and let me know if you have any questions!

Thanks,
aDSAT

Hello Non Zero Racing,

Thank you for contributing to OSM! I noticed some of your edits near Kuala Lumpur unintentionally left some broken data so I wanted to let you know about a few things I discovered. When this complex junction was remodeled there were multiple crossing ways which were not connected together by shared nodes. There were also six turn restriction relations which were left with missing members. The validation function in ID editor can help highlight these issues before you upload, so I would recommend using it when making complex edits (osm.wiki/ID#Validation). I found some KartaView (https://kartaview.org/details/2724186/1511/track-info) and Mapillary (https://www.mapillary.com/map/im/Rba8vTgKQ4woou9RsTQnft) ground level imagery in this area, which could help show you what exists on the ground vs. whats just visible in Bing.

Here is an OSM Wiki about editing restriction relations (osm.wiki/Relation:restriction) that I find very helpful when I am editing complex junctions that have existing turn restrictions. Thank you for contributing to OSM and let me know if you have any questions!

Thanks,
aDSAT

Hello DFFYou,

I noticed you split a portion of Jalan Kompleks Sukan into a dual carriageway. A number of turn restrictions are now invalid because they are missing members, for example: relation/10054743
If these restrictions no longer apply to the dual carriageway, it would be best practice to remove them as they are now invalid. I also noticed at the crossing of Jalan Kompleks Sukan and Lebuh 5, there is a dashed line separating the lanes of Jalan Kompleks Sukan and no turn restriction signs seen here https://kartaview.org/details/2387670/580/track-info, this would imply drivers on Lebuh 5 road may cross Jalan Kompleks Sukan. This restriction you added prevents that maneuver, relation/11838761, do you have any resources that support it?

Lastly, you updated the modeling at the intersection of Jalan Kompleks Sukan and Lebuh 5 and added these secondary links: way/867218246 way/867218245. You used this particular intersection modeling in this changeset also changeset/96196075. I posted another comment there, but I am curious why you are modeling intersections with unnecessary links like this?

Thanks,
aDSAT

Hello DFFYou,

I noticed you remodeled intersections on Jalan Bercham between way/886981654 and way/886981681. I am concerned about this modeling because Esri World Imagery and this KartaView https://kartaview.org/details/2714150/54/track-info do not show physically separated lanes. Links are often channelised with physically separated lanes, as described here: osm.wiki/Highway_link. Is there a reason you model the intersections this way?

Thanks,
aDSAT

Hello Andy,
Thanks again for discussing this situation. I have replaced the barrier=kerb tags created by opencarpatia that I removed.
Cheers,
aDSAT

Hello Andy,

Thanks again for discussing this situation. I will undo my edits and replace the barrier=kerb tags. Since the barrier=kerb is one of the few barrier tags in which access=yes is implied barrier=kerb I am wondering if I should add that tag as well. I do not believe there would be any legal restriction preventing passage of these locations so tagging them with access=yes seems like a way to acknowledge that there is an impediment but also show that vehicles are legally allowed to pass. Do you think this would be an acceptable solution? I hope to hear back from the original mapper too, and I can contact the OSRM developers and let them know about this issue.

Cheers,
aDSAT

Hello Andy,

Thank you for contacting me and I saw your other comments as well. I did reach out to opencarpatia about these barriers here in Ukrainian: changeset/96220532 and waited over 3 weeks for a response. I agree that opencarpatia has mapped the situation in great detail, but I don’t think that `barrier=kerb` is the most appropriate tag in these locations. On barrier=* it says and “A barrier is a physical structure which blocks or impedes movement” and on barrier=kerb it says something similar while also suggesting barrier=kerb is meant for being along the road, and mentions that having it on the road itself is a possible tagging mistake.

It seems that the quality of the road is the issue here and not purposefully built barriers intended to block all vehicle traffic — in the Mapillary examples it looks like cars can travel over it, albeit slowly. Tagging areas of rough highway as barriers has the unintended consequence of completely blocking vehicle routing, such as node/4348897612, osm.org/directions?engine=fossgis_osrm_car&route=48.98627%2C38.40851%3B48.98580%2C38.40874#map=19/48.98611/38.40952.

I think discouraging routing on rough highways is appropriate and ideally routing engines should account for smoothness and surface tags like the user provided. Like I suggested in my initial outreach to opencarpatia, I believe `traffic_calming` or `hazard` tags could be appropriate here. barrier=kerb also suggests traffic_calming for when the kerb goes across the road.

Another option could be to use ‘4wd_only=yes|recommended’ tagging on the ways. The road surface here has some especially rough locations, but I don’t believe any of them qualify as barriers that are intended to stop all traffic. Do you agree one of those tags would be an appropriate replacement?

I understand the concern over losing history of the features and if it helps I can return to the barriers I removed and add `fixme` tags like muchichka_s suggested in the comment above.

Cheers,
aDSAT

Hi muchichka_s,
Thank you for providing that example! That situation differs from the barrier=kerb nodes I edited in this changeset, because it is a lowered section of kerb along a highway. There are no kerbs along the highway in this changeset, and none of the nodes I edited intersected with other highways, as can be seen in the 2018 Mapillary trace beginning here (https://www.mapillary.com/map/im/U73V-OgayEYkyXZg-sB8Ig) traveling through Lypovets to here (https://www.mapillary.com/map/im/i-iFaC7EGF3a9ZqStABg8g). I agree the highway is uneven, but the various smoothness=* and surface=* tags provide sufficient detail in this location.
Thanks,
aDSAT

Hello muchichka_s,
Thank you for contacting me. I reached out to the user here changeset/96220532 and suggested the traffic_calming and hazard tags. Do you think either of those would be more appropriate? My interpretation is that opencarpatia was mapping locations of uneven pavement, not purposefully constructed kerbs. Do you know any more details about these situations?
Thanks,
aDSAT

Привіт opencarpatia,

Я помітив ряд функцій `barrier = kerb`, які ви додали в Україні. Наприклад, node/7929466013, node/530557023 та node/1424591013.
Мені цікаво, що ви картографуете з цими функціями? Бар'єри в OSM зазвичай використовуються для того, щоб вказати, що прохід заблокований або перешкоджаний фізичною структурою (barrier=*). Мене турбує що `barrier = kerb` не є найбільш підходящим тегом для цієї ситуації. Чи буде тег `traffic_calming = yes` або` hazard = bump` самостійно краще підходити для цих місць? Нині маршрутизація переривається тегами `barrier = kerb` уздовж цих магістралей (osm.org/directions?engine=fossgis_osrm_car&route=48.4025%2C24.9278%3B48.4254%2C24.8131#map=13/ 48.4060 / 24.8632). Це був ваш намір?

Дякую!
aDSAT

Привет elm5789,

Самый простой и надежный способ отменить эти изменения - отредактировать вручную и изменить их классификации на те, которые были раньше. Вы можете ссылаться на свою историю наборов изменений в OSMCha, что поможет вам при внесении изменений. Я видел набор изменений 92284054 10 октября, это самое раннее изменение, которое вы сделали в отношении классификации шоссе в этой области. Вы можете посмотреть свою историю редактирования здесь (https://osmcha.org/?filters=%7B%22users%22%3A%5B%7B%22label%22%3A%22elm5789%22%2C%22value%22%3A%22elm5789%22%7D%5D%2C%22date__gte%22%3A%5B%7B%22label%22%3A%22%22%2C%22value%22%3A%22%22%7D%5D%7D).

Еще раз спасибо за обсуждение дорог в этом районе. Пожалуйста, дайте мне знать, если у вас возникнут другие вопросы!
aDSAT

Здравствуйте elm5789,
Если посмотреть на соседний Тольятти (way/27382126), вы увидите, как первичные, вторичные и третичные дороги ведут к аналогичным многоквартирным домам, в то время как жилые улицы (way/133889852) используются для доступа к частным домам.

Автомагистрали с этой классификацией представляют собой те, по которым проходят большие объемы движения в пределах города. Они часто имеют более двух полос движения и иногда являются двухполосными, как улицы, которые мы обсуждаем в Автозаводском районе. Также важно отметить, что ограничение скорости на жилых дорогах часто бывает низким, около 20 км /ч (way/27831550), в то время как дороги более высокой классификации часто имеют намного выше ограничения скорости, например 60 км /ч (way/380865577).

Из-за более высоких ограничений скорости и способности этих дорог справляться с большими объемами движения их предыдущая классификация была правильной на основе российской политики и местной практики моделирования. Пожалуйста, обращайтесь кo мне если у вас есть другие вопросы о классификации автомагистралей!
Спасибо,
aDSAT

Здравствуйте elm5789,

Я заметил некоторые недавние изменения классификации автомобильных дорог вокруг Автозаводского района. Вы заменили многие основные и вторичные дороги на городские дороги. Согласно политике OSM, классификация центральных и главных дорог городов, районов и микрорайонов должно быть основных, вторичных и третичных дорог (osm.wiki/RU:Key:highway). Есть ли причина, по которой вы внесли эти изменения или считаете их правильными? Основываясь на моем понимании политики OSM, я считаю, что их следует вернуть к прежней классификации.

Спасибо,
aDSAT

Здравствуйте Taxist23061982,
Я заметил, что вы добавили множество тегов «barrier=block» вдоль улицы Гастелло way/30999178.
Недавний набор изменений удалил многие из них (changeset/93390708),но некоторые все еще остались.
Знаете ли вы, можно удалить эти другие узлы «barrier=block»?
Спасибо,
aDSAT

Hello JaLooNz,
I have changed these building:parts back to buildings. Thank you for discussing the modeling here. Which renderers and searches are you referring to? I would suggest that you reach out to the developers or maintainers of the tools you are concerned with so they can update them to recognize the current OSM policy about building:part and building relations.
Thanks,
aDSAT

Привіт, Andrej S,

Я помітив тут що ви дещо додали тег `ref = Т-19-16`; однак це суперечить тегам відповідного відношення на цій магістралі (relation/3097263). На основі переліку важливих магістралей (osm.wiki/Uk:Автомобільні_шляхи_Україні_державного_значення), здається, номер маршруту більше не використовується. Я бачу, що ви раніше переміщували Т-19-16 до тегів ʻold_ref` і ʻold_loc_ref` на ци шляхи (way/245891784, way/40003872) та відношення маршруту, про яке я згадав раніше (relation/3097263). Я хотів би допомогти стандартизувати тег ref та відносини, але мене бентежать ваші останні редагування.
Чи можу я запитати, на який ресурс ви посилаєтесь? Чи відрізняється це від вікі-сторінки?

Дякую,
aDSAT

Hello JaLooNz,
Yes, I was informed of this discussion but that occurred when Nominatim did not support building:part addressing, so my edits were made in accordance with that recent enhancement to Nominatim. Modeling these as building:part=residential is correct per OSM policy but I can change them back to building=residential if that is what you are suggesting.
It is unfortunate that the apps are not able to recognize unique addresses on building:parts since this is an approved tagging in OSM and is a more accurate method of modeling complex buildings. It might be worth reaching out the the app developers so they can consider accounting for OSM policy. Do you have a specific app in mind that does not support addressing on building:part?
Thanks,
aDSAT

Hello JaLooNz,
I searched all of these building parts in Nominatim and it provided results: “Waterloo Centre, Singapore” (https://nominatim.openstreetmap.org/ui/search.html?q=Waterloo+Centre,+Singapore), “262 Waterloo Street, Singapore”(https://nominatim.openstreetmap.org/ui/search.html?q=262+Waterloo+Street,+Singapore), “263 Waterloo Street, Singapore”(https://nominatim.openstreetmap.org/ui/search.html?q=263+Waterloo+Street,+Singapore), “264 Waterloo Street, Singapore”(https://nominatim.openstreetmap.org/ui/search.html?q=264+Waterloo+Street,+Singapore).
Could you clarify the issue here as I am not seeing a problem. If you would like to discuss the modeling of this building I am happy to do so.
Thanks,
aDSAT

Hello Kovoschiz,

This is a very unique situation, and your reasoning is well-taken. Unfortunately, because OSM does not render turn restrictions, and also how it renders the overlapping highways in this area, it might always have the appearance that traffic already on Lung Wo Road (way/762936336) would be able to exit here. Even at zoom level 17 (osm.org/#map=17/22.28076/114.17059) the highways are blurred together, and a lot of the detail is unclear. Since the link in question is coming from a primary, OSM Wiki policy (highway=motorway_link#Link_roads_between_different_highways_types) suggests this would be a primary_link — although I’m sure it was not considering a circumstance such as this.

Thankfully the turn restriction is modeled well, and routing engines should avoid that maneuver (https://maps.openrouteservice.org/directions?n1=22.281467&n2=114.170533&n3=18&a=22.282142,114.172797,22.281259,114.169943&b=1a&c=0&k1=en-US&k2=km).

Thanks,
aDSAT

Correction: ground level imagery source used was Yandex Panoramas