Natural=peak mapping guidelines for Thailand: proposal + cleanup notice

Hi all,

While reviewing peaks data in Northern Thailand, I came across two areas where recent changesets have introduced large numbers of problematic natural=peak nodes. These include spot height grids on slopes and chains of nodes along ridgelines with no distinct summit. I’m planning a cleanup and wanted to propose some guidelines before proceeding.

Affected areas:
• in Chiang Rai: https://www.openstreetmap.org/changeset/147179207
• in Uttaradit: https://www.openstreetmap.org/changeset/151631891

This is not intended as criticism of the authors of these changesets, but rather an effort to establish clearer guidelines and improve overall data quality.

Mapping every local maximum, shoulder, or minor hill visible in SRTM or similar datasets tends to introduce noise, reduces the usefulness of the data for map users, and makes it harder to identify truly distinct and locally recognized features.


PROPOSED GUIDELINES (Thailand) — updated

Use natural=peak when:

  • The feature is supported by topography: a closed or near-closed contour ring
    and a clearly identifiable high point. A slope or ridgeline without a distinct
    apex does not qualify.
  • There is some degree of topographic prominence (~50m in the North/Northeast,
    ~20m in Central/South as a rule of thumb)
  • Only one node per summit, placed at the highest point
  • The feature is verifiable through at least one independent source:
    Wikidata/Wikipedia, field survey, or well-established local knowledge

A name using a regional prefix: ดอย (Doi, North), ภู (Phu, Northeast),
เขา (Khao, Central/South), ควน (Kuan, South), is a strong positive signal
but is not required. Unnamed peaks are acceptable if topography clearly
supports them.

Use natural=hill for เนิน (Noen), ลูกเนิน (Luk Noen), and smaller ควน
with low local relief.


SOURCES

Avoid creating natural=peak features from DEM data alone. A local maximum in SRTM or similar datasets does not by itself establish a distinct, mappable geographic feature. Such data is useful for supporting information (e.g. ele=*) once a feature is otherwise verified.

RTSD topo maps may help confirm the presence of a feature, but cannot be copied directly; names and elevations should come from independent, compatible sources.

Adding wikidata=* and wikipedia=* where available is encouraged, as these provide useful supporting references. The Wikidata Query Service (query.wikidata.org) can be used to explore documented Thai mountains with coordinates independently of OSM.

Download Wikidata peaks dataset prepared with OSM tags: here.


PLANNED CLEANUP

Unless there are objections, I plan to:
• Remove clearly unsupported nodes (e.g. unnamed points on slopes with no topographic support)
• Reduce ridgeline clusters to a single node at the most representative high point

Changeset comments will link back to this discussion.

Draft guidelines will also be proposed on the wiki:
https://wiki.openstreetmap.org/wiki/Thailand/Other_Features

Thanks,
Julien

I read the global wiki and found it is unclear what should be considered peak.

For me, named or unnamed shouldn’t be the criteria (albeit “named” is likely to be).

Maybe this feature is comparable to the peak in army map.

These 2 might give some hint.

1 Like

There is no global consensus on this, and a quick search shows there have been plenty of conflicts around it. That’s exactly why documenting it locally makes more sense than waiting for a global definition that may never come.

Agreed, a name is a strong signal but not a requirement. Many legitimate peaks on RTSD topo sheets are unnamed, and they still deserve a node if the topography supports it. I’ve updated the draft guidelines to reflect this.

1 Like

As there were no objections, I’ve gone ahead with the following:

Wiki: Mountains and Hills guidelines (natural=peak / natural=hill) have been added to the Thailand/Other_Features page.

Cleanup: Unsupported natural=peak nodes (spot heights on slopes, ridgeline clusters without a distinct apex) have been removed from both affected changesets. Original authors have been notified via changeset discussion with a link back to this thread.

Happy to refine the guidelines further if anyone has additional input.

1 Like