Opened 7 years ago

Last modified 13 months ago

#854 reopened defect/bug

OSM - Badly rendered coast line (tile artifacts)

Reported by: pini Owned by: cp15
Priority: major Milestone: version 0.5.1
Component: mapdrivers/OSM Version: git master
Severity: complex Keywords: rendering, layout, map, binfile
Cc: http://wiki.navit-project.org/index.php/user:pini

Description (last modified by usul)

Hi,

Depending on the zoom level the coastline is very badly rendered with big squares when using OSM maps. See the attached screenshot which was obtained using a recent planet.bin. It shows the french town Brest.

Attachments (11)

Capture-Navit.png (72.3 KB) - added by pini 7 years ago.
coast.diff (406 bytes) - added by jandegr 4 years ago.
level-2.png (23.3 KB) - added by kazer 4 years ago.
level-3.png (8.1 KB) - added by kazer 4 years ago.
level-4.png (7.2 KB) - added by kazer 4 years ago.
level-5.png (5.0 KB) - added by kazer 4 years ago.
level-6.png (2.9 KB) - added by kazer 4 years ago.
Bordeaux1.JPG (30.2 KB) - added by jandegr 4 years ago.
Bordeaux1.png (117.4 KB) - added by jandegr 4 years ago.
GB-DE_order6coastline.png (41.3 KB) - added by tryagain 4 years ago.
View of region with coastline moved to order=6
GB-DE_defaulcoastline.png (28.2 KB) - added by tryagain 4 years ago.
View of region with default coastline tiling

Download all attachments as: .zip

Change History (24)

Changed 7 years ago by pini

comment:1 Changed 7 years ago by pini

  • Cc http://wiki.navit-project.org/index.php/user:pini added

comment:2 Changed 5 years ago by usul

That shows 2 issues:

  • empty vectortiles are filled with the default earth colour but should become filled with water instead
  • at some areas, the inner coastline is broken (multipolygone issue) and so it's a rectangle earth surface towards the sea

comment:3 Changed 5 years ago by usul

  • Keywords rendering layout map binfile added
  • Milestone set to version 0.5.1

Is essential, as users might think that the map is somewhat corrupted. -> scheduled for hotfix

comment:4 Changed 5 years ago by usul

  • Description modified (diff)
  • Severity set to complex

comment:5 Changed 5 years ago by usul

  • Summary changed from OSM - Badly rendered coast line to OSM - Badly rendered coast line (tile artifacts)

comment:6 Changed 4 years ago by jandegr

If you zoom in, things gradually improve and the coastline becomes perfect when zoomed in more. This points to a tiledepth issue and setting a maximal tiledepth for poly_water_tiled confirms it. I had good results with the attached patch. Anyone pls. comment on this or test the patch since this issue really needs to be fixed.

Changed 4 years ago by jandegr

Changed 4 years ago by kazer

Changed 4 years ago by kazer

Changed 4 years ago by kazer

Changed 4 years ago by kazer

Changed 4 years ago by kazer

comment:7 Changed 4 years ago by kazer

  • Resolution set to fixed
  • Status changed from new to closed

I did some tests, and I can confirm that Jan's patch address this. One line, beautiful!

This is the same coast, viewed from different zoom levels:

Here's the script to generate the images :

prefix="pre854"
for i in `seq 1 10`; do
        dbus-send  --print-reply --session --dest=org.navit_project.navit /org/navit_project/navit/default_navit org.navit_project.navit.navit.zoom int32:-2
        sleep 1;
        import -window root $prefix-zoom-${i}.png
done

(run once with prefix pre854, then change the map and change the prefix )

Here is the script to build the images:

for i in `seq 1 9`; do

        convert pre854-zoom-${i}.png -crop 40%x+0+0 pre-cropped-${i}.png
        convert post854-zoom-${i}.png -crop 40%x+0+0 post-cropped-${i}.png
        montage pre-cropped-${i}.png post-cropped-${i}.png -tile 2x1 -geometry +0+0 level-${i}.png;
done

Applied in r6017. Good job Jan!

comment:8 Changed 4 years ago by tryagain

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi!

Do you have whole planet data converted with current maptool version?

I'm afraid there are hard performance consequences after applying the patch. You have pulled coastline data to tiles of order=6, which have 40000/26 = 625 km side length.

This will affect all map operations, because you'll have always process coastline data from square 625x625km once your standing point is within 625km from coastline or closer. This might be not a very big impact on powerful devices with lots of RAM, which unzip the tile data only once and then keep it in memory cache. Users with low end devices with cache size reduced, lower cpu and disk io performance, may have dramatic consequences.

I would like to have tilesdir.tmp file from processed planet with this patch applied to do some analysis, and planet.bin file itself.

For now, reopening this ticket and marking the new feature as experimental in r6018.

I guess we would have to do some simplification at maptool time to have smooth coastline without affecting enduser performance. But let us check.

tryagain.

comment:9 Changed 4 years ago by kazer

That's a valid point Tryagain.

I did process only a small subset of the planet for this test. Processing time was about the same and I did not see an impact on my test machine, but it is a regular computer, not a low power device.

Changed 4 years ago by jandegr

Changed 4 years ago by jandegr

comment:10 follow-up: Changed 4 years ago by jandegr

Time for a little experiment :

download (approx.) this area from the mapserver

https://dl.dropboxusercontent.com/u/93775123/Navit/Bordeaux2.JPG

You see right away that the size of the map is very big for such a small area. On other occasions I tried to download the map of a very tiny island, surrounded by lots of water and did not get the map below 75MB (from the mapserver).

Once installed in Navit, zoom in and out a little untill you notice that as a treat the mapserver gave you (chunks of) country borders from all over the globe. Maybe after tweaking navit.xml more global-wide content could appear.

https://dl.dropboxusercontent.com/u/93775123/Navit/Bordeaux1.JPG

Now anyone can try to convince me that some usefull coastlines are worse for ancient hardware than this kind of *%µ# thousands of kilometers of country borders !

It is in fact exactly the same problem as with the coastlines : randomness all over. There is a way to limit tiledepth but to solve both coastlines and the global-wide crap we need to impose an upper tilelevel for objects. Some signatures of functions in maptool suggest it is possible since they have a max and min parameter, but the code itself seems to ignore the min parameter.

If you zoom in a little you will notice the same happens with landuse polygons, roads, ... Needless to say that the level=6 I used at first is open for discussion, but to avoid those artefacts and randomness I had to use 6 awaiting a solution to impose an upper limit.

And something not related to the issue but to the bordeaux area : can someone help me figure out why the bordeaux and bassin d'Arcachon area are flooded (maps from the mapserver and selfbuilt maps just the same) ? thx.

Last edited 4 years ago by jandegr (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 4 years ago by tryagain

Replying to http://wiki.navit-project.org/index.php/user:jandegr:

lots of water and did not get the map below 75MB (from the mapserver).

I think most of this data is zip file directory. It's stored uncompressed. We have really lots of tiles, each tile being a file inside binfile. I hope navit does not reread this data on each map access, but it have to read it at least once. There's lots of data (tile names) which is actually never used by navit itself. If a tile is outside of your area of interest, it's still included in the zip file, but is marked as having zero size.

Binfile structure is described in wiki

Once installed in Navit, zoom in and out a little untill you notice that as a treat the mapserver gave you (chunks of) country borders from all over the globe. Maybe after tweaking navit.xml more global-wide content could appear.

Yes, it may appear. Actually, any item which crosses tile boundary, will be shifted uplevel, until it does not cross the tile boundary. Items which cross equator, for example, are put into the top level tile. We could workaround it by splitting such items by tile boundary. It's already done for coastlines.

Now anyone can try to convince me that some usefull coastlines are worse for ancient hardware than this kind of *%µ# thousands of kilometers of country borders !

Then contribute code to split and push these country borders deeper ;)

It is in fact exactly the same problem as with the coastlines : randomness all over.

I see your point, but there's no randomness in maptool at all (it does not access /dev/random ;)

There is a way to limit tiledepth but to solve both coastlines and the global-wide crap we need to impose an upper tilelevel for objects. Some signatures of functions in maptool suggest it is possible since they have a max and min parameter, but the code itself seems to ignore the min parameter.

Yes. But we shouldn't just move stuff to upper level. Big objects should be simplified beforehand. And we should take measures to draw only one version of each object at a given time.

Another way would be add support for prerendered tiles, which could be used to display world map, having vector and prerendered maps swithced at some zoom level.

If you zoom in a little you will notice the same happens with landuse polygons, roads, ... Needless to say that the level=6 I used at first is open for discussion, but to avoid those artefacts and randomness I had to use 6 awaiting a solution to impose an upper limit.

If you make all coastlines accessible at all zoom levels, prepare to process 360+Mb of unzipped coastline data on each map redraw. That's around 45mln points which should be scaled to fit the screen, and 45mln lines drawn.

And something not related to the issue but to the bordeaux area : can someone help me figure out why the bordeaux and bassin d'Arcachon area are flooded (maps from the mapserver and selfbuilt maps just the same) ?

See #745 and wiki

tryagain.

comment:12 Changed 4 years ago by tryagain

Experimental maptool has produced much smoother coastline, but we now have 92 order=6 tiles above 1Mb, biggest over 8Mb.

Beforehand we had only 9 order=6 tiles, biggest ones of 2Mb size.

So applied r6026 to move coastline to order=9.

Changed 4 years ago by tryagain

View of region with coastline moved to order=6

Changed 4 years ago by tryagain

View of region with default coastline tiling

comment:13 Changed 13 months ago by wiki.navit-project.org/index.php/user:naggety

I did some tests with the experimental feature, even seting order = 1 (max = 1).

The RAM memory usage was up to around 60 - 70MB.

Note: See TracTickets for help on using tickets.