Chiang Mai and up is flooded

Removed

You can try this with the JOSM validator, but the region around Chiang Mai has a lot of OSM data, so this procedure will take some time. Better you could use filter options before.
F.e. for Chiang Mai itself JOSM has found the 3 unclosed waterways:
200889783
98567086
92838271

Removed

No, I did not repair because I thought you want to research and find out before the real reason for flooding. Should I fix it?

Now I tried a better way for can check the full north of thailand. I had to install the “mirrored-download” plugin in JOSM first: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/mirrored_download

With this plugin you can download objects of a type or condition you defined.
F.e. I did select the full north of thailand and searched for objecttype:“way” with xapi:“[natural=water]”, later in a second and third downloads for “[landuse=basin]” and “[landuse=reservoir]”. (I guess it is also possible in one run.)
Then I started the JOSM validator. My results for unclosed ways:
91222234, 200306319, 196514746, 93181185, 200889783, 92838271, 98567086, 143409915

Removed

Ok, it’s done.

Removed

Removed

Sorry, I do not know osmosis. I use now the upside described JOSM-plugin “mirrored download”. So you can also make a filtered download direct into JOSM.

You filtered in a very big region. I had made my repairs only in Thailand. Could you find still any unclosed ways here?

Did you mean unclosed ways with waterway=* or natural=water? I think for waterway=*, only waterway=riverbank must be closed.

Please note also: I found some similar unclosed ways which are correct outer segments of multipolygon relations. But you and I did not download relations and so JOSM will show these ways as fault.

Removed

Maybe it was a bit missunderstanding. When JOSM opens a data download containing only ways+nodes, then the Validator can not differentiate between
a) real unclosed ways and
b) way segments - each unclosed - combined by a multipolygone relation (f.e. the combine of the ways 92838271+98567086 was not necessary because the relation 2702714 already joined both).

No, it is not obligatory. Eighter the multipolygone relation contains all important tags of the area and all outer members have no tags of this kind. (This is currently the more recommended version.)
Or the tags are directly at the outer ways and the multipolygone relation combines it. Both versions are possible and allowed.
But if these relations contain inner ways (f.e. a forest with a sea inside) then there are small differences in the interpretation between both tagging versions: A tag at the outer way is valid for its full area (f.e. for the forest and for the sea). Tags in the relation are valid only for the resulting area (f.e. for the forest only).

Bye,
sundew

Can you please send a link which shows that “flooded area”? I open the map around Chiang Mai quite often and did not notice any problems the last weeks. I’m quite sure I would have noticed a problem with the water features as I had been working on a SVG map recently…

http://thaimap.osm-tools.org/?zoom=10&lat=18.82&lon=98.96&layers=B00T

Stephan

Removed

That may be a bug of mkgmap. If you do not use --generate-sea, but add a style for natural=coastline, the flooding may disappear.

Removed

Was the input data reference complete? Some of the multipolygons are quite large. Be sure the cutting of the area does not throw away important data.

Removed

you specified “–tf reject-relations”. I’m quite certain with that option you won’t have multi-polygon relations in your data. These are needed to correctly know which way is an outer or inner way of a water feature.