I really like your app and prefer it much to the official Jolla Maps.

The biggest issue I have with it is that I cannot save a POI for future use and search for it, like in e.g. the Jolla and Ovi maps.

Let’s say I’m really liked a restaurant or hotel or whatever that I found through Poor Maps and I want to remember it for the next time I’m in that town – I’d like to save that POI and to search/find it when I want to again.

font.pixelSize: Theme.fontSize...

or

font.pointSize: ...

Sometimes, for one reason or another, its better to alter the route proposed by the mapping application and drive differently. In these situations (since we are driving already), Poor Maps should realize that the proposed route was not accepted by the driver and it should get a new one. Few restrictions:

1. The new route and its use should be done hands free - don't want to interact with the device while navigating. So, we cannot ask whether new route is needed, for conformation of the proposed route, and starting navigation again.
2. Request should be done in background, without altering map display.

When long routes are used, it should significantly simplify routing calculations if significant number of points along the previously calculated route are used in query. It may create other problems though - router could consider them as a points of stops. So, maybe this aspect could be looked into later...

I had a chance to test the navigation feature of Poor Maps today. The version that I used, contains 24dd599 (Account for navigation block and auto-rotate when centering) already.

The use was as follows: OSM Scout as a router, select Navigate to (address specified) from current position. The interaction on setup was done in portrait mode, started navigation, phone turned to landscape, and started driving. Starting from some moment, the current position indicator was getting either very close to the upper message or, after some time, disappeared. Now, I am not 100% sure whether I touched the screen or something touched it while driving. After disappearance, I couldn't get the location indicator back (well, I didn't try very hard while driving).

Maybe I did something wrong or should have setup it somehow differently. Please let me know.

If you don't mind suggestion - would be great to get the current location fixed at the middle of the screen horizontally and on 1/4'th of the screen vertically (maybe should play with the position a bit or allow user to set it). That way the map would move with the movement keeping the current location in the same spot.

Also, I don't know if you have any algorithm to calculate the shown zoom level on the map, or is that fixed by user when starting navigation?

Please let me know if opening an issue is a correct way of sending such feedback or whether you would prefer TMO.

Thank you for a great application!

While testing Valhalla, I stumbled on an issue with the HTTP requests done by Poor Maps. While I don't know what is an expected request by standard, In particular, its quite different from what browsers, wget and curl do. As a result, Valhalla's web-engine was not able to parse URL and return routes.

When requesting http://localhost:8002/route?json... by browser (wget, curl, and simple python program with requests library), valhalla reports

GET /route?json=...

When the same URL is called by Poor Maps, we get

GET http://127.0.0.1:8002/route?json=...

I presume that many web-services are able to process it (as well as OSM Scout Server), but "pure" valhalla fails. I think that this behavior is due to https://github.com/otsaloma/poor-maps/blob/master/poor/http.py#L161 . At this point, you already have connection with the host and still forward full URL. If I parse, remove components 0 and 1 (https://docs.python.org/3/library/urllib.parse.html urllib.parse.urlparse), unparse it back to URL, I get a local URL that works fine with the services that I tested with.

Since I don't know whether the standards allow such GET requests, I am not sure its a bug. But, maybe Poor Maps requests should still be adjusted to be similar to the others.

When calculating a route, its sometimes advantageous to take into account current motion direction. In particular, its important for re-routing while driving. Mapzen/Valhalla have heading option for it, maybe other as well.

My use case: I wanted search next filling stations around my current position. (My car was low on gas)

In German the appropriate word would be "Tankstelle". This translates to the English words "filling station" or "gas station". (PoorMaps lists "Gas Station" as example POI search term)

But POI searches with both translations failed in PoorMap (+ OSM Scout Server), since the "official" tag name for this kind of infrastructure is "amenity : fuel". (http://wiki.openstreetmap.org/wiki/Map_Features)

Another example: Search for "drugstore" gives no results, since the "official" tag name is "pharmacy".

Solution 1:
In my opinion this problem could be solved by providing a list of "official" OSM tags in PoorMap's POI search dialog. (Advanced enhancement: This list of tags might have translatable descriptions and might have icons ;)
I am not sure, whether all those tags are needed. I can't imagine a use case, someone is searching for "barrier : fence".

Solution 2:
Another way to solve this problem would be to add some automatic mapping for the "most used" use cases. Search for "gas station" maps to search for "fuel". But I guess it would be quite difficult to identify those "most used" uses cases.

I personally don't like algorithms doing "magic stuff", so I would prefer solution 1.

file:///tmp/poor-maps/qml/poor-maps.qml:21 module "org.nemomobile.keepalive" is not installed
file:///tmp/poor-maps/qml/poor-maps.qml:20 module "Sailfish.Silica" is not installed
file:///tmp/poor-maps/qml/poor-maps.qml:21 module "org.nemomobile.keepalive" is not installed
file:///tmp/poor-maps/qml/poor-maps.qml:20 module "Sailfish.Silica" is not installed

Is it necessary to install it ?

Could you support localization(e.g. using transifex) please?

I've enabled both options but don't work

Hi!

I am working on getting routing provided by OSM Scout Server. While calculations of routing within Estonia are fast (few seconds), calculations for larger distances (Aarhus-Stockholm, for example) could take 25-40 seconds. During this time, Poor Maps timeouts the connection, unfortunately.

Would it be reasonable to remove timeouts for localhost connections? Or set them rather large, like 10 minutes? I expect that timeout handling is different from the inability to establish connection (no local server running), right? If timeouts are handled differently then it should be no problem to make such change in the handling since local internet connection is available always.

Best wishes,

rinigus

I am developing a simple server that can be used as a drop-in replacement for online map services: https://github.com/rinigus/osmscout-server . The integration with poor-maps was very simple (see poor-maps under thirdparty subfolder). However, it would be great to be able to specify how many downloads can be performed simultaneously. It seems, that poor-maps is downloading using only single connection. While the speed is reasonable in the interaction with the local server, I think it would be faster if I could generate 4 tiles in a time (as many as CPU cores on the phone).

I'd suggest to add "threads" or some similar option to tilesourses/ .json files, for example. It could 1 as a default and changed if needed.

At least from a GPX file.

Hallo,

when I'm using poor-maps in landscape mode with Jolla C the menu button is situated in the map center and the actual position will be covered by the menu button.
Maybe its better to put the menu button to the right and the NorthArrow on top of the menu button.
An in my opinion the information band for navigation is to big - reduce the hight of the whole band would be better. Here some suggestions:

1. direction picture is okay
2. put the narration distance directly under the direction picture, use little bit smaller font hight, so that the picture width and the distance width are the same
3. arrange navigation information and total distance on the same top position as the direction picture

with best regards

Denis

p.s. It's a very great app, I love it

It seems that there are not many providers of good-quality retina map tiles and the only good option, Mapbox, seems to have dropped midlevels from their pricing plans, meaning that once use exceeds the free plan it would be a whopping $500/month. Also, the retina tiles that providers have are only @2x, while some devices, such as Fairphone 2, would really need @3x or @4x.

For future reference, once the user count gets past free plans, based on a quick review, the most promising option for a tileserver seems to be TileServer GL.

• http://blog.klokantech.com/2016/08/tileserver-gl-maps-with-gl-json-styles.html
• https://github.com/klokantech/tileserver-gl
• http://demo.tileserver.org/
• https://maps.klokantech.com/
• https://www.youtube.com/watch?v=rOg4VnSAnI4
• https://github.com/tobinbradley/mapbox-gl-style-editor

Poor Maps stays in English regardless of the system language.

I only get installation failed without any detailed error message.
I downloaded the rpm from github.

When I try to navigate to Friedberg, it automatically chooses the first (wrong) result from the results Nominatim provides (compare http://www.openstreetmap.org/search?query=friedberg#map=18/48.35461/10.98271&layers=T)

It should either:

1. Show a list of possible results first (like openstreetmap.org does)
   or
2. Navigate to the result
3. Provide an easy way to select another result when the first one is the wrong one

When Qt/QtLocation updated in Sailfish OS and QtLocation allowed in the Jolla store.

• Adapt to QtLocation API changes.

• Switch to the OSM plugin, see QTBUG-32937.

• Remove Photon geocoder and maybe OSRM router as those are using demo servers, which are unstable and where significant traffic is likely not OK.

• Review keep-alive's Harbour-compatibility, see TJC#93323.

When navigating, the info block covers the top part of the map, meaning auto-center should center to the remaining part of the screen.

Furthermore, with auto-rotate on, the user is always heading up on the screen and might want to see more ahead than behind.

When I search (with Nominatim) in poor-maps, I get “no results” quite often (even for trivial searches).

e.g. friedberg ludwigstraße 26
There are at least 10 results Nominatim knows, compare: http://www.openstreetmap.org/search?query=friedberg%20ludwigstra%C3%9Fe%2026#map=18/48.35461/10.98271&layers=T

Are you sure you are querying Nominatim right?

Either

espeak --stdout "Some text" | gst-launch-1.0 -q fdsrc ! wavparse ! audioconvert ! pulsesink

or

flite -t "Some text" -o /tmp/out.wav && gst-launch-1.0 -q filesrc location=/tmp/out.wav ! wavparse ! pulsesink

http://talk.maemo.org/showthread.php?p=1520041#post1520041

https://digitransit.fi/en/developers/services-and-apis/1-routing-api/bicycling/

http://photon.komoot.de/

In NarrativePage, we have Begin and Pause controls. I think that they make sense only when using navigation from current location. Otherwise, we are just reviewing possible route and don't have anything to start.

In PR #43 I introduced app.navigationReroutable, but I guess it would be better to use an additional property like app.navigationFromCurrent and, depending on the state of this property, enable or disable Begin and Pause controls

See #62

Hi

using poor maps on two devices and the only issue i see up to now is the size of fonts.

on a big screen you can see in the attached pictures the difference. attached for comparasion the sailfish image too...
poormaps big screen device

sailfish big screen device

also from a phone screen nexus 5.
sailfish

poormaps

Add pixel_ratio argument to poor.main and use that to set conf.DEFAULTS.basemap and maybe basemap_filter before the config file is read. Supply the value from QML based on either Silica's Theme.pixelRatio or QML Screen's devicePixelRatio.

When you do a search from (or to) current location and the GPS is not yet ready, it returns “No results”.

I recommend to check for this first and display a spinning wheel or similar with the title “Waiting for location services to activate”.

I have started to fiddle with the code with the look on replacing Map with MapboxMap QML type. As far as I could see, there is a significant amount of code that is made around limitations of used Map component.

At present, I am planning to start replacing the components and propagate the functionality of MapboxMap throughout the code. I would like to use voice branch as a base with the hope that it would make the life easier in future, even if there are significant changes expected in that branch.

For me, its the best to start changing and tag the problems that I encounter. Already now I have seen lots of magic in poor-maps.qml with the respect of page pushing and pop'ing. But if I don't understand what's going on, I'll report it here and would keep changes minimal. Right now, I am not going to touch the page movement code.

In addition, by doing such code reading and changing the main map widget in Poor Maps, I can further develop QML API as well. For example, I am planning to add a call that would allow us to find zoom and the center of the map that ensures that all requested points are visible. Such call exists in QMapboxGL, but I haven't exposed it yet. So, when we see some issues with the QML type, maybe its better to fix it in the plugin code when possible.

Thanks for implementing support for HSL's APIs! We have released new APIs and some of them are now in beta. The old APIs will be discontinued soon - perhaps as soon as in 4 months. The new APIs support new features such as realtime data and citybikes.

Digitransit APIs: http://digitransit.fi/en/developers
Other data and APIs from HSL: http://dev.hsl.fi/

Gui is weird when running on FP2.

Ask if I can help to fix this.

According to the search dialog presented by "Nearby Venues", POIs are searched by type. However, from inspecting Foursquare and Nominatim URLs, it seems to me that they would find venues by name as well if I would type the name as a type. OSM Scout Server, however, makes "type" as it is - as a type of the venue and looks into OSM type tag.

I have just finished the version of "Nearby" search which is backed by geocoder-nlp. This search accepts poitype and name options. When only one is specified, it would take that one to search for POI. When the both are specified, its using them both with logical AND. That way you can specify cafe and its name, for example. I think its a correct handling of the situation, but it differs from the current approach.

I wonder, is it possible to add "Name" into Nearby Venues dialog? Its probably possible to do so as a specific OSM Scout Server option, but that would probably feel odd.

There is also an option to use logical OR and, using the current dialog, search for type or name.

Would be great to get your thoughts on it.

https://geocoder.opencagedata.com/

SVG? PNG?

Must be due to the Qt 5.6 upgrade.

When calculating a route and using current location as "From", Poor Maps displays total distance and time on the overview of the route on map. This data is missing when shown for routes that are calculated between two addresses. For trip planning, it would be great to get the same overview for routes between addresses.

It would be great with a function that would allow me to download all tiles of a location quickly without having to zoom in on each tile. E.g. if I'm going on a trip I want to prefetch tiles of my destination city , but if it's a big city then I want to fetch them without having to first zoom in and then scroll through half the city.
One way of doing this could be using location name (download Berlin, Germany etc.). Another could be to do it for visible area of map or similar.

When using the "search nearby" feature from the map, I am often facing the problem that I don't know the correct OSM POI type to enter there. E.g. today I was looking for DIY stores but didn't know that they are actually mostly listed under "hardware" rather than "doityourself".

I there would like to propose to have (in the search nearby feature and when selecting OSM as search provider) a list of POI groups and names. To me e.g. the listing provided in http://openpoimap.org/ is very useful.

is this possible?

As in title. I tested it on Jolla 1 and Jolla C with the same result. When I enter the map and start navigation and then turn off screen by pressing the power button. After turning on screen by power button and then swipe from lock screen to home screen app crashes. Not always but often.

https://graphhopper.com/

In some cases, where i have e.g. Issues with the spelling of an address or when I'm operating completely offline (via osm scout) a tree- or listing-based address would be helpful. I remember that osmAND has/had something similar, see e.g. http://osmand.net/images/features/search_10.jpg

Lapuanjoki It is already to everyone, so poor-maps and same to poor-maps-GL spanish not work. Modrana does, as example.
Thanks

Have you thought to add other languages? I would like to translate your app in Spanish language.

That would be 768x768 pixels as per the old standards and as per what tileserver-gl returns.

For example:

1. Enter a destination roughly South of your current position. Start following the route.
2. Turn on auto-rotate. North should now be at the bottom of the map.
3. Tap the routing panel at the top of the screen, then swipe left to view the list of maneuvers.
4. Touch an upcoming maneuvre. The map zooms in and centres on the maneuver. However, it doesn't rotate the map, so North is now at the top. It is easy for the user to mistakenly think that they will be approaching the junction from the bottom of the screen, but they will in fact be coming from the top of the screen.

Ideally, I think we should rotate the map to align to the route trace so that the 'incoming' side of the route enters the screen from the bottom in an upward direction. That way, the map is oriented the same way as it will be when the user actually gets to it.

Adding direction arrows to the route trace could also help to avoid confusion in this and possibly other situations, but I don't know if that's feasible.

Splitting the HSL geocoder, router and tiles to a separate package (e.g. harbour-poor-maps-hsl-plugin) would make the lists of providers cleaner for those not in Helsinki and would act as a self-documenting stand-alone piece on how to write provider plugins for specific regions.

Might not be worth the effort. Before doing anything about this, we should probably wait for Poor to be allowed into Harbour and then check if separate packages for plugins are allowed into Harbour. Making plugins undiscoverable or undistributable is not the goal.

I'm currently trying to implement some train routing providers which unfortunately do not provide journey planning from position data but instead only from fixed stop points.
Therefore, I added a gecoder with returns (besides title, description, x and y) an id which is a ID of the stop point.
Because the journey planning requires knowledge of the startId and destinationId, the route implementation would require (instead of x and y) the id. Would it be possible to pass this information also (or instead of) the x and y data to route?

Currently we auto-rotate according to the direction calculated from positioning data, which means that we have a trade-off between being too sensitive (e.g. rotating due to lane changes etc.) and being too late to respond to turns (which will look confusing if making a turn very soon after the previous one).

We could probably fix this by calculating if the current position is near the route polyline and what is the angle of the nearest route polyline segment (excluding very short segments?) and using that angle for rotation. If the position is far from the route polyline then we'd fall back to the current system.