Messages

@PeterPablo: ... Nominatim (used by MapQuest) has optional parameter to specify prefered area for search. So added

Great! This will certainly improve the quality of search results. Acutally this behaviour annoyed me from the begining and only recently I noticed that the Google Search returns more meaningful results. I only brought this up because of the HTML markup "annoyance". So -- thank you very much!

@PeterPablo: ... I'm unable to do this, because Google API do not allow such request.

It is the other way round. Google already behaves good, meaning that it does respect the currently displayed area.
The standard search by Locus (probably based on nominatim) though does NOT respect the currently displayed area and offers results from almost "everywhere". Are you able to improve that search?

This should probably be discussed in a separate topic since it is no regression from the current version.

When I added a POI by searching with Google Places the name field was filled with HTML markup (i.e., &amp; <b> ... </b>, etc.).

On a related subject:
The Google Places search respects the current area I am viewing and offers me results in its vicinity (try searching for "Hilton" while viewing San Francisco). When I use the standard search ("address and place") with the same term "Hilton" the results I am being offered are spread all over the USA. Could you please make the OSM search behave more like the google search concerning local proximity? The same holds true for the Geonames search.

Thank you!
(tested with current release)

silber1, you need to manually download the hgt-files for the region you would like to have shading for, so that Locus has the elevation data needed for the calculation. You can download them from within locus by creating a temporary POI and then filling the altitude from the second TAB (advanced).

I hope this helps.

Peter

Proper labeling is in active research. I recently read a blog entry on the website of University Heidelberg: http://k1z.blog.uni-heidelberg.de/2013/ ... based-map/

May be it is possible to join forces?

I have the same behaviour on my Galaxy S2. It is probably due to the installed keyboard (SwiftKey).
Peter

Recently, I was on a skiing trip and recorded the tracks. The "information" tab was useless for most tracks since the recorded altitude had big jumps. You certainly remember the discussion about "maximum possible speed". In one case the altitude jumped from one track point to the next from 2500 m to 25000 m (yes, factor ten!) and back.
In my opinion the post-processing of the raw GPS-data can be improved considerably. Additional sources like pressure / SRTM data can be used to improve the altitude for example under known problematic situations (forest, city), when the GPS signal is bad.
The post-processing should first check for obvious outliers (jump of position/speed/acceleratoin between neighbooring points) and secondly use a (FIR-)filter of higher order (meaning that not only the last two points are considered but rather for example the last eight).

If needed I could provide the track showing the above mentioned misbehaviour. I deleted the messy points from the track, though I should have the recorded NMEA data.

Slightly off-topic: Which "altitude correction"-setting is recommanded? Could the option "Use NMEA data" be the source of problems people are sometimes experiencing?

Peter

I am aware of that. I just wanted to discuss it here publicly since you like to get customers feedback.

I know...
The reason I asked was to further simply the handling of the program for this specific scenario.

Hi menion,

I am aware of that procedure. It is not well suited for my usecase though, since usually I first do a search with Locus Pro and then click on the found POI and use the "navigate to" command. As a result the screen is of course not centered on my current (approximate) location.

Peter

Hi menion,

no, unfortunately this menu is disabled so I can not enable the pressure sensor. By disabled I mean, that has a gray color (like "speed value" in the screenshot of the wiki-link you provided).

Peter

Hi menion,

when calculating a route to a specific point and for the field "start" I have "GPS" selected, then the route will only be calculated as soon as locus has a GPS fix. Often I want to calculate a route while still being in my appartment or an hotel where I have a (free) data connection.

I wish that Locus would use the approximate position or may be even the last known GPS position as a starting point. Up to know I have to select the starting point from the map, which is tedious and not necessary.

Peter

I observed that in the first buggy 2.9.x version the number of highway-crossings and exits was displayed which made me very happy (vector map of germany, openandromaps, one of the internal styles). With the very last released version those numbers unfortunately vanished. Is this intentional?

Hi menion,

the Nexus 7 has a builtin Barometer. I checked that it is working using the app "SyPressure". In Locus Pro the option "air pressure" in the menu "Sensors" is greyed out and the checkbox "activate pressure sensor" is unchecked. Is this a bug or intention?

Thank you!
Peter

Handy darf nicht im Lautlos-Modus sein...