2010/1/20 Felix Hartmann <extremecarver@googlemail.com>

Just downloaded new data for Germany, problem persists:

Is this maybe not solvable with current code? I'll retry with different max-nodes to see if it then maybe works.

I also noticed this with the Geofabrik extract of Germany: The tile around Bremen always gets flooded. My tiles are different from yours, so I assume we have different max-nodes parameters. I did also compile Geofabrik's complete Europe extract: here the problem did not occur. There were a couple of other landlocked tiles in France and Poland which were flooded though (caused by, I assume, some bad data in the tiles). This may mean, therefore, that the problem stems from the way Geofabrik extracts Germany. You could try making your own extract (using a bounding box) for Germany out of the Europe extract. Perhaps this would work better. Cheers.

On 20.01.2010 11:12, Clinton Gladstone wrote:

...

2010/1/20 Felix Hartmann <extremecarver@googlemail.com <mailto:extremecarver@googlemail.com>>

Just downloaded new data for Germany, problem persists:

Is this maybe not solvable with current code? I'll retry with different max-nodes to see if it then maybe works.

I also noticed this with the Geofabrik extract of Germany: The tile around Bremen always gets flooded. My tiles are different from yours, so I assume we have different max-nodes parameters.

I did also compile Geofabrik's complete Europe extract: here the problem did not occur. There were a couple of other landlocked tiles in France and Poland which were flooded though (caused by, I assume, some bad data in the tiles).

This may mean, therefore, that the problem stems from the way Geofabrik extracts Germany. You could try making your own extract (using a bounding box) for Germany out of the Europe extract. Perhaps this would work better.

Cheers. -- I reduced maxnodes to 800.000 and then the flooding became a lot smaller (and not the whole tile anymore). The problem seems to be that there is sea in the North, then a section with land until the boarder, and then further south again sea. See below (or to the right) a screenshot of Garmin (Mapsource) Topo Deutschland v2. One can nicely see the problem of the country boundary going seperated through the sea. It is really strange that there is a sea section without exit on dutch territory. But well.

I don't know whether this can be fixable in code, or whether we should simply take it out from the main ocean and make a separate sea section in OSM data to make it easier to work with country extracts.

From my experience the Geofabrik extracts are the problem. Our code will not be able to fix that 100%. From my point of view our code can work only if the coastline ways are complete. The boundaries used by Geofabrik are sometimes too short. I analysed that for belgium. A good example is the land nose at Zeebrugge (http://www.openstreetmap.org/?lat=51.3465&lon=3.2097&zoom=13&layers=B000FTF). It is completely cut away in the Geofabrik dump. So what has to be done to solve the problem? 1. Inform the geofabrik people that they may increase their boundaries. maybe they could include the three or twelf-mile-zone around a country? 2. The format of an OSM dump should be extended by the possibility to define the exact borders of the OSM dump. The osmosis tool could then add the boundary used to extract the OSM dump to the dump. This solves 99% of the problems originated by inexact dumps and unknown boundaries. WanMil

Hi Felix, if you created the map with the extend-sea-sectors option this may help you. Previously I ignored that a distance in longitude drection depends on the latitude. One degree on equator is same for longitude and latitude, while one degree at a pole is zero. The attached patch does this correction. So if using the data you posted in your first mail, the additional point is drawn on western border of tile instead of going to north and cutting the real coastline. Nevertheless this behaviour may occur again if the size of the tile changes. Like WanMil wrote the only possibility to get rid of this is to have the exact borders of the extract stored in the osm data and move them to the generated maps. Am 20.01.2010 11:55, schrieb Felix Hartmann:

On 20.01.2010 11:12, Clinton Gladstone wrote:

...

2010/1/20 Felix Hartmann <extremecarver@googlemail.com <mailto:extremecarver@googlemail.com>>

Just downloaded new data for Germany, problem persists:

Is this maybe not solvable with current code? I'll retry with different max-nodes to see if it then maybe works.

I also noticed this with the Geofabrik extract of Germany: The tile around Bremen always gets flooded. My tiles are different from yours, so I assume we have different max-nodes parameters.

I did also compile Geofabrik's complete Europe extract: here the problem did not occur. There were a couple of other landlocked tiles in France and Poland which were flooded though (caused by, I assume, some bad data in the tiles).

This may mean, therefore, that the problem stems from the way Geofabrik extracts Germany. You could try making your own extract (using a bounding box) for Germany out of the Europe extract. Perhaps this would work better.

Cheers. -- I reduced maxnodes to 800.000 and then the flooding became a lot smaller (and not the whole tile anymore). The problem seems to be that there is sea in the North, then a section with land until the boarder, and then further south again sea. See below (or to the right) a screenshot of Garmin (Mapsource) Topo Deutschland v2. One can nicely see the problem of the country boundary going seperated through the sea. It is really strange that there is a sea section without exit on dutch territory. But well.

I don't know whether this can be fixable in code, or whether we should simply take it out from the main ocean and make a separate sea section in OSM data to make it easier to work with country extracts.

On 20.01.2010 07:53, WanMil wrote:

...

Depending on the sea complexity some countries really take a lot more time for rendering now. (Norway went from 5 minutes to 45 minutes). I don't really mind as my upload speed is still a lot slower than my PC compiling on my weekly updates.

This is caused by the new mp code. The methods contains(JoinedWay, JoinedWay) and createContainsMatrix(..) are not optimal for large and lots of polygons (both apply to Norway).

Attached patch is a first try to speedup these methods. I haven't tested this patch very much (not enough time yet). At least I didn't measure if it really speeds up the calculation. I expect a minimum speedup of factor two. So if you don't want to be a kind of test candidate please throw it away. Otherwise feel free to compile Norway with it. I am curious about the results.

WanMil Time went from start compilation 16:18:58 norway end compilation 17:11:37 norway

to start compilation 9:45:32 norway end compilation 9:48:27 norway So that speedup is really significant. Couldn't find any differences in the map itself.

On Wed, Jan 20, 2010 at 10:42:53AM +0100, Chris-Hein Lunkhusen wrote:

WanMil schrieb:

...

This is caused by the new mp code. The methods contains(JoinedWay, JoinedWay) and createContainsMatrix(..) are not optimal for large and lots of polygons (both apply to Norway).

And what about the realy large boundary MPs used in Germany and Netherlands (other areas use type=boundary for boundaries).

Maybe we should internaly convert them to type=boundary so that they don't stress the MP code ?

Chris

[1] <http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries> [2] <http://www.openstreetmap.org/browse/relation/62781> (land_area MP) [3] <http://www.openstreetmap.org/browse/relation/51477> (maritime)

Actually, type=boundary relations can define multipolygons too if they contain enclaves or exclaves. An example would be the city of Espoo, which surrounds the city of Kauniainen: http://www.openstreetmap.org/browse/relation/36097 I am not sure if that would matter, though. Someone might want to define polygons for boundaries (e.g., for highlighting the area), but usually border lines should be enough. Marko