Import of too long ways (more than 524 287 nodes) will fail about libosmscout

[nnhubbard]

Thanks for finding the issue!

[Framstag]

Hi Karry, can you name the concrete OSM object that caused the problem? I haven't done the import yet myself but would propose that the imports checks for such cases and just drops (with an error log) the corresponding object. The assert should only make sure that things are still cleanly detected and handled if the importer fails to detect the problem,

Note that I recently added a limit for merged ways since drawing contour labels for too long ways created performance issues during rendering.

[Karry]

Problematic is relation that defines UK coastline (outer ring): www.openstreetmap.org/relation/6038068 (one way in this relation: www.openstreetmap.org/way/415818132)

I know that long ways (contour lines) are performance problem. This is the reason why I am using -maxwaynodes 256 for Srtm2Osm tool. State or island borders is another example... As I understand correctly, outer rings have to be written as one way now. Right? Question is if ignoring such objects is good idea :-) I would like to see some nice hack for such huge areas...

[Karry]

What about usage of some special index for really huge areas, similar to water.idx?

[Framstag]

Yes, a variant of the algorithm implemented for the water.idx could (and in my opinion should be used) for all "big" areas based on long, long ways, especially as part of big, big relations. Examples are:

• Boundaries
• Coastlines (done by water index), defining ground and sea areas
• post number regions

The water index covers the whole import region and devides it in cells without content (they could still have different types like land, see, unknown) and cells that contains lines. Cells with line sonly contain that part of the line that is contained by the cell up to its line borders.

The index is generated for multiple levels up to a certain resolution.

Since the index is not cheap the lines should cover the whole region. And the actual geographic coordinates of the lines will be lost (it is just enough resolution for correct drawing).

[Framstag]

In now pushed code to the github repository that defines a MAX_NODES constant for FileWriter. Way merging, area mergin and relation composition check now against this constant and skip processing. For the wales import two relations were now skipped.

[Framstag]

Note also, that coastlines are already evaluated in the water index. Individual coastlines are stored separately and the water index builds the full coastline in memory, thus not having above problem. So dropping relations defining coastlines and island is OK. However there are other relation where it is not.

[nnhubbard]

I read somewhere that in a recent version you updated the database. With this fix and the current version, will my imports not be readable/useable with this new libosmscout update?