nominatim import -> No marked ways (Skipping stage 2) & FATAL: No data imported by osm2pgsql.

[wyf2215087636]

Title: OSM file fails to import in Nominatim with “No marked ways” and “No data imported by osm2pgsql” errors

Description:
When importing the following OSM XML file into Nominatim, the process fails with two main errors:

No marked ways (Skipping stage 2)

FATAL: No data imported by osm2pgsql

The file renders correctly in various GIS tools and OSM renderers, but Nominatim refuses to import it.
After testing, I found that if I remove the two nodes with IDs 109478 and 112351, the import succeeds.
This suggests that there may be an issue or conflict related to these specific nodes.

Minimal failing OSM data:

<way id="639" version="1">
    <nd ref="112352"/>
    <nd ref="109478"/>
    <nd ref="109479"/>
    <nd ref="112350"/>
    <nd ref="112351"/>
    <nd ref="112352"/>
</way>

<relation id="10" version="1">
    <member type="way" ref="639" role="outer"/>
    <tag k="type" v="boundary"/>
    <tag k="boundary" v="administrative"/>
    <tag k="admin_level" v="4"/>
    <tag k="name" v="Mandalay"/>
    <tag k="name:en" v="Mandalay"/>
    <tag k="name:my" v="မန္တလေးတိုင်းဒေသကြီး"/>
</relation>

Steps to reproduce:

Save the above XML as a .osm file.

Run Nominatim import (e.g., nominatim import --file <file.osm>).

Observe the import failure with the errors mentioned.

Expected behavior:
The file should import successfully, given that it is valid OSM and renders correctly elsewhere.

Actual behavior:
Import fails with “No marked ways” and “No data imported by osm2pgsql”.

Workaround:
Removing nodes 109478 and 112351 allows the import to proceed without errors.

Possible causes considered:

Coordinate range or geometry validity issues?

Conflict with existing data in the database?

A bug in osm2pgsql or Nominatim’s preprocessing when certain nodes are present?

Any insight into why these two nodes cause the import to fail would be greatly appreciated. Thank you!

[wyf2215087636]

<node id="109478" lat="23.61923725300005" lon="96.14216058500006" version="1"/>
<node id="109479" lat="23.62487731000016" lon="96.13720834000003" version="1"/>
<node id="112350" lat="20.90685845300015" lon="96.47332569200006" version="1"/>
<node id="112351" lat="20.90652308500011" lon="96.47282799600009" version="1"/>
<node id="112352" lat="20.90565297800015" lon="96.47153673399998" version="1"/>

<way id="639" version="1">
    <nd ref="112352"/>
    <nd ref="109478"/>
    <nd ref="109479"/>
    <nd ref="112350"/>
    <nd ref="112351"/>
    <nd ref="112352"/>
</way>

<relation id="10" version="1">
    <member type="way" ref="639" role="outer"/>
    <tag k="type" v="boundary"/>
    <tag k="boundary" v="administrative"/>
    <tag k="admin_level" v="4"/>
    <tag k="name" v="Mandalay"/>
    <tag k="name:en" v="Mandalay"/>
    <tag k="name:my" v="မန္တလေးတိုင်းဒေသကြီး"/>
</relation>

[lonvia]

This is not a valid polygon, it intersects in the middle. Note that this is very hard to "see" when just rendering the data because of the odd shape with 400km of length and 400m of width.

The correct order of the nodes in the way would be:

<way id="639" version="1">
    <nd ref="112352"/>
    <nd ref="109479"/>
    <nd ref="109478"/>
    <nd ref="112350"/>
    <nd ref="112351"/>
    <nd ref="112352"/>
</way>

[wyf2215087636]

Thank you very much for taking the time to respond so patiently. I will check all the OSM data according to this specification.