Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - joze

Quote from: berkley on September 04, 2014, 12:10:35
There's an app for that:

Put it into your right side panel and have fun.
Although in don't understand, why this is needed?

thanks -- this works.
if I want to switch the screen orientation manually I've to go awkwardly through the settings menu. Is there some quick button  (which I could attach to the right panel for example) to quickly switch between portrait and landscape no matter what the android setting is?
Troubles & Questions / augmented reality poor accuracy
September 03, 2014, 23:32:01

I played with AR (latest testing version, offlines pois) and observed some oddities (assuming they're not related to the sensor failure as reported in my previous post).

Generally I find the AR accuracy quite poor. This is probably not a Locus issue but an issue of inaccurate sensors.

But what I found very strange is that the position of the AR poi's in the image depends on the screen orientation.

Look at the three attached images. I labelled some peaks with numbers 1 .. 4.

  • In the landscape.jpg image, the poi "Puig Campana" is a little right from peak 1 and Monte Ponoig is about above peak 3
  • In the skewed.jpg image, the poi "Puig Campana" moved to peak 2 and Monte Ponoig is between the peaks 3 and 4
  • In the portrait.jpg image, the poi "Puig Campana" is between peaks 2 and 3 (2 is not visible in this image) and Monte Ponoig is far left of peak 4

any ideas? is this a sensor issue or is there some AR calculation error?

Btw.: the angle which is drawn into the radar seems to be the same for portrait and landscape mode. I'd have expected to get a narrower angle in portrait mode because then the field of view is smaller.

here's an annoying thing I observed with the augmented reality plugin (and it's also present when showing the view direction).
I used a recent Locus testing version on a Samsung Galaxy Note II (cynogenmod 11) because I wanted to use the offline poi database.

Sometimes the poi's don't show up at all in AR, even though plenty of poi's should be around. In fact they do show up as white dots in the radar but they're just not visible on the display if I move the display around. In fact the radar then shows the white dots, but the radar directs to 0° and doesn't move as I move around the phone. It seems that in this case some of the sensors (motion, compass?) just don't work or are somehow not recognized by Locus AR.

If this happens, showing the "view direction" doesn't work either, so both seem to be related.

This behavious appers randomly -- as a gut feeling less than in 1/3 of the cases I switch to AR or use the view direction.

I used CPU-Z to have a look at the sensors. Attached are two screenshots, one in which case Locus view direction didn't work (and apparently CPU-Z shows some missing sensor values) and on screenshot for a case where Locus view direction and AR worked -- and there CPU-Z shows that all sensors are present.

It seems that the missing sensors can be activated somehow by just switching on and the android automatic screen rotation feature. It seems that the actual setting is not important. So sensors might be missing both for fixed portrait mode or automatic mode, but if I then switch the setting, the sensors are present for a while and can be used in Locus.

did anybody observe similar problems?

any idea how to solve this? (is it maybe a setting or does Locus miss in switching on the sensors?)
yes thanks -- that solved my problem.

Quote from: KaHeMu on August 28, 2014, 00:52:54
Answer from menion in another thread:

Currently recorded track is, before save into database, store in Locus/cache/trackRec directory.

Perhaps you should delete temporary track in this directory.


I'm running Locus (Pro) with it's base directory on an external sd card.
After having removed the external sd card from my phone by mistake (while it was running), Locus always shows a message that a track recording has not been completed short after startup. I'm attaching a screenshot (in german, sorry).

I already tried...

  • to "save" or abort the not-completed-track but Locus doesn't allow me to save or abort it, since there's no real recording
  • to uninstall and reinstall Locus
  • to overwrite the settings (and settings only) with a backup

but it didn't help.
I still get the message of a not-completed track after startup. Everything else works as expected. I can record new tracks, maps work as expected and so on.

The startup message is not a big problem as I can just hit the stop button but it's a little annoying.

Any idea how to get rid of this faulty behaviour?
Quote from: jusc on January 12, 2014, 16:57:43
try settings / miscellaneous / map directory and top right menu "add maps"
thanks -- right -- you can select different map source directories there.

But what I meant is adding directories for gpx tracks for example. You can just drop gpx files into the Locus/mapItems directory and then use these gpx tracks w/o importing them.

I just wanted to know if there's a way to use different directories as well as you can with maps.

is it possible to change the mapItems diretory (eg. also to ta directory outside the Locus tree)?

thanks -- I'll generate my maps with a supported format.

apparently mbt and (rmaps) sqlitedb are both sqlitedb databases.

Are there performance or or other issues which would make the one or the other preferable?

I do get an error message when I use the orux sqlite as overlay (in fact it's something like "this map is not supported for overlay")

But I do NOT get an error message, whe I use the orux sqlite as base map (and vector as overlay) -- but this still doesn't work.
Troubles & Questions / Can't get overlay working
August 03, 2013, 21:08:56

I can't get overlay working with maps stored on the phone.

I tried:

1. Use a raster map (in orux sqlite format) as base map and try to overlay a vector map (openandromaps). I tried this with different transparencies (e.g. 50%) and different overlay types. I get no error messages but I still see only the base map.

2. Use the openandromaps vector map as base map and try to overlay different raster maps (all raster maps in orux sqlite format). Here I get the message that the raster maps don't support overlay if I try to select the maps.

Any ideas?

What is the requirement of a raster map to be used as overlay map? -- I create the raster maps with mobac. Do I need some special setting for the raster maps to be useable for overlay?

Any help much appreciated.

Troubles & Questions / Re: Dynamic Dashboard?
June 13, 2013, 21:50:42

there's more dashboard dynamics which I'd find useful and I'd like post here for the wishlist.

See attached comparison.

The number on rows and buttons displayed on the bottom of the screen can vary (e.g. between zero and two like in the example).

In this example I let locus to autohide the bottom buttons so there might be no buttons / rows at the bottom at all like in the left image.

The right image shows the situation where the default bottom row is not hidden and furthermore there's another button row which allows to do something with the displayed track / poi's.

As you can see, the two button rows are obstructed by the dashboard, which is not useful.
I see two solutions for this situation:

1. either move the dashboard dynamically up as rows appear on the bottom (preferred)

2. have the dashboard in the background such that if any button rows appear they should be over the dashboard (less preferred)
Hi // is it possible to displayed the stored srtm height and current magnification (e.g. "15") as dashboard items?
Troubles & Questions / Dynamic Dashboard?
June 12, 2013, 00:00:19

is it possible to have a dynamic dashboard?

Example // let's suppose I've defined track recording items as part of a dashboard. I'd like them not to show up if no track is recorded where all non-track-recording dependend items should still be displayed.

Is this possible?
Quote from: "gynta"compare?
oh yes! let's  compare  :mrgreen:

means, Locus is not soo bad...


thanks for this exhaustive comparison -- but still I think that all example show that locus' built-in hill shading does it sub-optimal.