Hi everyone
I’m Prae from TomTom, and I’d like to share our new initiative: Thailand – Nodes Without Primary Tags.
The goal of this project is to enhance the data quality of OpenStreetMap in Thailand by identifying nodes that are currently missing essential primary tags (such as amenity=, shop=, or highway=). By cleaning up these nodes, we can make our map more consistent and useful for everyone.
I’d love to hear any feedback or suggestions from the OSM Thailand community. Your participation and insights are always welcome.
Thank you for your continuous support, and happy mapping!
ซินเจียยู่อี่ ซินนี้ฮวดไช้ ขอให้ปีนี้เป็นปีที่เฮงและมีความสุขสำหรับทุกคนค่ะ
新年快乐 Wishing you all a prosperous and Happy Chinese New Year.
I appreciate your Initiative to improve OSM data in Thailand.
As nodes with missing tags do not cause much problems, I am interested in your strategy to fix them. Will a human check details of each case to detect the potential cause of the missing “primary” tag? I had seen cases of typing mistakes before, which a human can easily recognize and correct.
In the same situation, a human would then double check, that this won’t create duplicate entries.
Example: instead of amenity=supermarket it might be written as aemnity. Correcting might result in a duplicate to the existing supermarket node a different mapper created at a slightly different location due to not seeing the typo and adding new.
The mistyped one could still contain details missing on the existing one. So a merge could be needed.
Is this all part of the instructions to the challenge? The last time I used it, such complex actions had not been foreseen. If not, then this kind of problem is not suitable for map roulette.
Hi @stephankn Thank you for your feedback - glad to hear from you.
As nodes with missing tags do not cause much problems, I am interested in your strategy to fix them. Will a human check details of each case to detect the potential cause of the missing “primary” tag?
I agree that missing tags generally do not cause major issues. From what I understand, the main impact is incorrect routing destinations. I’ve asked the team for more insights on this, especially around inaccurate destination searches, and I will get back to you once I receive their clarification.
I had seen cases of typing mistakes before, which a human can easily recognize and correct. In the same situation, a human would then double check, that this won’t create duplicate entries
Yes, we have included these details in the instructions shown to users after they click the Start button. We also recommend that users merge tags into the correct objects to ensure updates do not create duplicate POIs. The guidelines below appear when starting a task.
Additionally, the instructions provided after clicking Start include guidance on handling outdated POIs and enriching POIs with more informative tags when users can verify information through a trusted source or based on their own knowledge.
Thank you again for your feedback. After trying some tasks myself, I agree that this project requires strong local knowledge or access to up‑to‑date sources to properly update POIs. If a task is too difficult due to lack of reliable sources, please feel free to add a fixme tag to the POI and mark the task as “Can’t Complete.”
can you please share the raw data you used to create the challenge somewhere? I clicked once on the challenge to review, but I was on the go and don’t recall which node was presented to me.
I suspect it might contain nodes which are part of some special boundary relations. Could be that this explains why they lack tags, as it is defined by relation role. Removing them might break things. And relation support in iD is quite limited compared to Josm.
Was this checked in the challenge? Maybe removing all items part of a relation from the challenge is the safest way?
This quality check in osmose (missing object type on named tags) is quite similar to your challenge, but has way more findings:
Regarding the question about relations, we consulted the person who created this check. It turns out that nodes intersecting with or belonging to roads (highway=*), boundaries (boundary=*), railways (railway=*), or waterways (waterway=*) have already been excluded.
He also reviewed all cases from the challenge again and did not find any nodes that are part of relations. If an exceptional or risky case does appear, we would be grateful if you could share it with us so that we can analyze it further.
Additionally, I would like to highlight that we detected more than 1,400 leads in Thailand last month and have already included the first batch of these issues in the challenge. We will be adding more tasks soon.
I found time to review the details you shared. Unfortunately, this is not exactly the data I hoped to receive. The csv is sort of a snapshot of the challenge. I was interested in the OSM data flagged as suspicious. I was hoping for a CSV listing the OSM node ID and the tags of the nodes.
As you already double-checked the relation issue, this sorted out my main concern.
Probably large overlap to the osmose check mentioned above. So if someone wants to review the list, there is a download link of the osmose findings.
