Kiharu1410's Comments
| Changeset | When | Comment |
|---|---|---|
| 172306156 | Can't blame them though, they're probably just trying to free up money for things like education, roads, and all that. |
|
| 172306156 | That sounds valid. But by that same reasoning, shouldn't a well-known ward in Saigon also be tagged as place=city? If we do that, you'll have a big text label for the ward right next to the main 'Ho Chi Minh City' label, which doesn't look good. If we tag it as place=district, the label disappears entirely. And if we stick with place=suburb for now, the address lookup issue remains. So, if we're going to keep using place=suburb, we'd have to remove the old city nodes to fix the address problem, but this seems undoable since we keep these for navigation. That's what I think, at least, if we find another way to fix the address lookup issue, that would be great. After all, the main purpose of this changeset is to correct only the address, and not for aesthetic reasons. I'll leave this changeset for now. |
|
| 172306156 | Using place=district works as a quick fix for the address issue, since it's more or less at the same admin level (admin_level=6) as the old divisions. The problem is, that tag is normally for places without clear-defined borders, and it won't make a label show up on the map. On top of that, if we use the same tag for both wards and communes, there's no way to tell them apart without reading the name. Honestly, it would be way more helpful to use different tags. That would make it much easier for people using the Overpass API to pull data for just wards or just communes. |
|
| 172306156 | Thanks for the reply. If place=suburb doesn't have to mean "suburb" in the dictionary sense, then city and town don't have to either. If we tag wards as suburbs, it can really screw up how address lookups work in systems like Nominatim (for example, in Saigon ward, now contains Thu Duc city node for every address) unless we removed the previous second-level divisions. Plus, it frees up the place=village tag for the actual villages (thôn and ấp) that sit under the communes, which just feels right. As I said, it was just to standardize the wards and communes, it's up to you if you want to fix the address. Regards. |
|
| 172306156 | Since OSM does not support tags like place=ward or place=commune, the most reasonable way to standardize this data for Vietnam is to tag wards as place=city and communes as place=town. This approach is consistent with OSM's documentation. As we have agreed on using admin_level=6 for the second-level administrative divisions of Vietnam, the OSM Wiki, place=*, indicates that place=city is a suitable tag for this level. Although place=subdistrict and place=municipality are also appropriate for admin_level=6, place=city is a more logical fit for wards. A ward cannot be tagged as place=suburb, which means "the edge of a large town or city" and translates to "Ngoại ô" in Vietnamese. For instance, a central area like a ward in Saigon is clearly NOT a "suburb." Similarly, communes cannot be tagged as place=village because many communes have large populations. Given that a commune is the same administrative level but below a ward, place=town is the next logical tag to use. To sum it up, this method provides the best way to standardize how all wards and communes are represented across Vietnam. |
|
| 171212260 | Fixed in changeset/172099577 |
|
| 171212260 | Allright, I found the reason, you can view the history of way/1425977644, way/1425977644. Seem like some changesets modified it |
|
| 171212260 | Yeah, seems like a technical error. It's weird that I already validated before submitting. I will fix it soon. If any same errors come up, message me, or you can fix it by yourself. The referenced source is from: https://sapnhap.bando.com.vn/ |
|
| 171212260 | Yes, this took a lot of time :) |
|
| 170256948 | The drawn boundary referenced can be found on the official government website here: https://sapnhap.bando.com.vn/. |