View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#955
Originally Posted by jafd View Post
Yep, empty PNGs are just 103 bytes in size. But you can take advantage of preloading one at the very start, and rendering it wherever an empty tile is needed, thus conserving some time (and battery) otherwise spent on decoding. In terms of database disk size, getting rid of them would yield next to nothing.
This could be implemented as an optional extension, as you would also need to know the empty-space color for the given map layer for this to work without artifacts. It would activate only provided that you know the empty space color and the database has this additional info.

It would indeed probably speed things up both in the current GTK interface - you would just draw a rectangle and fill it with solid color instead of loading an image to an image surface and then painting it. It would also make sure only real tiles are cached (the amount of cached tiles is currently limited by their count).

In the QML interface it would help too - just drawing a colored Rectangle instead of an Image element. But the performance is already very good, so it might not be that needed in this case.

To detect that a (downloaded) tile is empty, simple == comparison might be enough & pretty fast, as a different size is automatically False and comparing 103 Byte sized files should be very fast. Or just get the header, check size and don't download it in the first place, just mark as empty.

Originally Posted by jafd View Post
As for sharing the pre-renders, I suspect it would take a few months to do them on commodity hardware (three days for Poland, zoom levels all the way to 15 and 16-18 for select cities); also, to achieve acceptable results, the database for the whole planet is needed (for some reason I've got proper administrative borders only around one of two countries).
Well, thats quite brutal. But I'd say doing just some selected european countries and/or big cities might be doable.

Proper on-device realtime rendering would be ideal though - I have to finally look how the Kothic renderer actually works. I met some people on the SotM in Viena suggesting that Mapnik is horrendously inefficient so it might indeed be possible.

Originally Posted by jafd View Post
Also the stylesheet I ended up with, default one from OSM-bright (which played well with imposm data) is bad, too low contrast to be viewed on a phone. Font size is also next to pathetic.
What about the stylesheet used for the detail layer ?

At least this tools does custom rendering from OSM snapshots and uses them default stylesheet, so it should be possible:
http://osm.kyblsoft.cz/historie/
(the text in the header says that you need to select on the plus in the upper left corner to select the snapshot)
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)