Thread: [SailfishOS] [Announce] Native offline maps: OSM Scout Server
View Single Post
MartinK is offline MartinK
2016-12-02 , 18:57
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#42
Originally Posted by rinigus View Post
I must say that I use modRana on PC and Poor Maps on the device so far. So, I haven't tested modRana too much on device.

Assuming that you use the latest version of the server (there could be different problems with the versions earlier than 0.3)

* you could be hitting timeouts for connections in modRana. As a result, modRana might ask multiple times for the same tiles. To check if its true, look into the events log shown in the server's main screen. Check whether the same URL is loaded multiple times.
Maybe it could be also related to the old bundled urrlib3 (issue 146) ? I've updated it in the master branch, but it is not (yet!) in any released version. So users packages from OpenRepos & Jolla Store still run with the old urrlib3 and might be getting those errors.

That should hopefully not be an issue soon as I plan to release updated modRana packages today or tomorrow.

Originally Posted by rinigus View Post
* its probable that modRana and Poor Maps use different tile sizes. This is visible in URLs requested to render the tiles. Notice if there is a difference in "shift" and "scale" parameters in URL. Poor Maps uses by default 1024x1024 or 512x512 tiles that are not very well supported by modRana (or not at all yet) with modRana using 256x256 tiles (shift=0 and scale=1 by default). As a result, tile rendering can be done in bigger chunks in Poor Maps which should produce faster overall rendering. Optimization of tile size vs parallel rendering is not a simple problem and it may vary between the devices.
Map tile scaling is unfortunately currently broken in modRana - and even if it worked, it is at present only meant to upscale current 256x256 pixel tiles - mainly to make text and small map features easier to read (at the cost of making them more blurry). The map scaling code (once fixed) should be relatively easy to adapt to supporting larger tile sizes - even though there might be some issues with overlays to overcome when some layers provide bigger tiles and others not.

Originally Posted by rinigus View Post
* maybe modRana's rendering is slower. If its true you could try to follow when the server states "Idle" on its cover and see when the map is rendered in reality. For that, browse the map in Poor Maps or modRana and peak by sliding from the right on the state of the server. In Poor Maps delay is minimal if any, in modRana - I haven't checked.
You can also check the modRana debug logs: Go to Options -> Debug, enable the tile related debug logging & logging to a file and then restart modRana. On next start modRana should create a log file in ~/Documents/modrana_debug_logs/

Originally Posted by rinigus View Post
The main drawback of smaller maps is that you would have to change them in the server's settings.
This is something I have been wondering about - is that really needed ? Couldn't OSM Scout Server check incoming tile requests against the bounding boxes/shapefiles of multiple data packs and return data for the first match ? Or, depending on cost, just run the query on one pack after another until there is a hit ?

Some heuristic can be applied for this to run all further queries after a hit on the same data pack until there is another miss. Users could also enable just some packs in the OSM Scout Server UI to reduce the number of lookups.

Also a related idea - client side pack specification. OSM Scout Server clients could specify data pack name for the lookup. They could get the available pack names either from OSM Scout Server via a special query or by other means (listing all folders the OSM Scout Server data folder or even by downloading data packs themselves and pointing OSM scout to them).

Just a couple of ideas.

Originally Posted by rinigus View Post
Also, you cannot calculate the routes between maps.
Yeah, that's certainly not an easy problem to solve. I wonder how the commercial/proprietary navigation systems handle that ? Or do they just have larger areas (whole Europe, etc.) so they don't have to care about it ?

BTW, a naive idea how inter pack routing might be done:

0. assuming two adjacent packs with a relatively straight border between them & some overlap + simple start-destination routing
1. draw a straight line from start to destination
2. note where it intersects the border
3. search for suitable (way) nodes around the intersection points in both map-packs
4. find a node near the border that is in both packs
5. compute two routes: start - shared border node, shared border node - destination
6. return combined route as the result

This is of course very simplified and would probably returns some pretty inefficient routes. It also does not handle complex border geometries, routes over multiple packs, non overlapping packs or having only packs that have no shared border at all.

Again - just a couple of ideas.
__________________
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)
 

The Following 5 Users Say Thank You to MartinK For This Useful Post: