Topics

Hi Menion. Since latest Pro Update, I can no longer record proper tracks. Even with "Location Interpolation" or whatever this new thingy is called set to "minimum", my position keeps wandering off aimlessly and strays away more than  20 meters from the correct place from time to time... randomly but quite often.

What makes this quite horrible: If I actually set this interpolation thing to OFF, it wanders around even worse... sometimes as much as 100m. When I get back to the same spot after a while, the position might be fine.... or it might not. Really random.

Maybe there is a little bug in your code that actually interprets OFF as "do as much as nonsense as possible"? :-)

I'd appreciate a quick fix if you find it. Not being able to record proper tracks at all is a real bummer. The Galaxy Note 8 was always spot on and accurate by the meter before this new Locus "feature".

Running latest pro on latest Android Pie on Galaxy S8+. There was also a Samsung Firmware update in-between when this position mess started, but I still suspect Locus. The position problems really look like a filter going crazy or some such.

Thanks...

I want to import a huge amount of data into Locus automatically... around 50 track folders and 50 waypoint folders. I thought locus-actions could do this job and I already got as far as downloading. But then
<after>importData</after>
only opens up the user interface import dialog and waits for input. Not really that useful for automation with hundreds of items.

Is there any way to do something like
<after>importDataQuietly,foldername,create/empty</after>
// do not call the user interface but instead simply import into a given folder automatically, creating/emptying if requested

I assumed this to somehow work already, because otherwise locus-actions are a bit pointless for automated data import. Cannot find anything in the docs though.

Thanks,
joe.

There are dozens of usefule gps trip & tour portals (gpsies, wikiloc, and plenty more). Some "work best" in one country while others are used in other countries. It would be great if Locus could "interface" their web sites by offering them in the sharing menu via customzied URLs:

I would configure something like
name: wikiloc
url: es.wikiloc.com/wikiloc/map.do#lt=%LAT%&ln=%LON%&z=%ZOOM%&k=2&tab=0&a=2

Locus could then offer "wikiloc" as sharing option for the current screen position and I could with a single finger tap find out what routes are available.

Of course Locus needs to offer multiple options here.

For a start, how about config file entries instead of a complexish settings GUI, at least until we figured out what makes sense and if this feature is actually usable:
urlshare1-name, urlshare1-url,
urlshare2-name, urlshare2-url,
urlshare3-name, urlshare3-url,
...
Obviously, Locus must ship with reasonable defaults for the most well known trip portals. I am sure, people will find other uses for other websites as well. DOesnt necessarily have to be trip portals. Only important thing is that the URL is completely customizable.

[attachment=0:zk31e1v7]SC20120330-093723.jpg[/attachment:zk31e1v7]

Hello User... this is your friend Locus speaking. I know you wanted a QUICK map switch. And I gave you a nice list of maps that are very easy to hit with your finger. And I know that the map you just clicked on is perfectly covering the current gps position. After all, that is probably why you clicked it isnt it?

But hey... you know... I am having a funny day today. "Centering" a map is such a majorly important operation, all maps have a golden treasure hidden right in their center. So I will simply throw another requester in your face before I really switch maps. Maybe 0.1% of you want to really center the map instead of simply displaying it at the current position. So lets just annoy the other 99.9% as well... why not. Its just another click isnt it?

GPS on/off, what good is that for? Maybe somebody could explain this to me, I simply dont understand.

I see it like this: Locus offers track recording and it offers a moving map according to current position. These are the two features that need GPS. I, as a user, can turn those two features on and off. Very well, very good.

But why must I, as a user, also take care about the state of the GPS? That is just an additional step which seems totally useless. Why does Locus bother me with that? Why does it not simply turn on the GPS automatically when track recording or moving map is enabled and turn it off just as automatically when both are off?

Maybe I miss the point here, but bothering the user with this GPS on/off business seems simply wrong. For exmaple, I start Locus and tell it to record a track. What happens is: Locus seriously asks me in an additional requester: "Do you want to enable the GPS?". Wtf?! I just told Locus to record a track... why would I ever say NO to this requester? Who would ever click on NO here? Whats the point of enabling track recording and then not enabling the GPS? Thats not a very logical state, why allow it at all?

IMHO, GPS on/off should be completely transparent and automatic. Do not ever bother the user with that decision. The user may decide about Track Recording ON/OFF and Moving Map ON/OFF, not about the state of the hardware.

What am I missing? What good is this additional GPS on/off step? Maybe I forget something really important, but I just do not see it. Please enlighten me...

The track user interface mess and a possible solution

Firstly, sorry for not using getsatisfaction. It has been a 404 since day one on vodafone spain, simply doesnt work. Now for the real topic:

The user interface for tracks has become quite a big mess over time. We have at least five different places now where you can "do" things with tracks: a popup menu on the map, a popup menu over a track in the track list, some onscreen buttons in the tracklist, then we have the track information window with additional buttons, depening on which tab is selected. wtf...

this is seriously BAD
 
Now let me introduce my idea. A track list and tracks are very much the same stuff as email, user interface wise. The track list equals your list of emails, a single track detail view equals a single email view.

This kind of stuff is very common on android and google offers wonderful APIs for that. Just look at GoogleMail and how beautifully it adapts between horizontal and vertical displays, how it uses side-by-side view on tablets, how you can use swiping gestures, etcpp.

Shouldnt Locus use the exact same API for its tracks? You would get all those features for free and everything would fall into place just beautifully. Users know what to expect, users know how to handle things, no learning required at all, everything works as expected. This is would be much preferable to any kind of "custom ui", even if you now think you can do things "better". In the end, it is always nicer and easier to follow standards.

Now for the track detail view (similar to an email view): Do not use tabs(for altitude chart or whatever), use one long scrolling view instead! Scrolling comes absolutely natural on a phone/tablet and everybody uses it all the time. Why mess this up and try to fit stuff into a "custom made window"? Tracks can have so many different attributes, this can never work properly. Think about <desc> and <cmt> fields for instance. They can be any length, they can be html, they can be whatever. Plus they are quite important to display nicely, many track portals put a route description in there.

I would suggest to format the track detail view internally as HTML and use some HTML class for display. No custom stuff made up from custom UI elements. Using html has the benefit of being able to display html cmt and desc tags easily. Also, users would be able to cut & paste relevant information. It always irritates me to see text on a screen that i can not mark and copy.

Also: Now we have a separate window for editing track details. More unneccessary mess. Why can I not simply edit the data I see in a tracks view right away? There is no need for yet another window with yet another formatting of some parts of a tracks data. This could probably also be easily implemented via FORMs if a tracks detail view was in HTML.

An most importantly: EVERYTHING you can possibly do to a track should be available from this new track detail view. And only there! No other popup menus, not five different places with different actions everywhere. Whenever I click on a track in Locus, regardless if its in the track list or on a track on the map or on a track name box (!) on the map, Locus must take me to the track detail view immediately and let me continue on from there. There must be no difference between clicking on a track in the map or on a track in the list. Its all the same, logically.

I know this is kind of a big change... but in the end, everything will become simple and easy and beautiful. New user will immediately know whats going on.

Obviously, the same paradigm (list & detail view) would then be used for waypoints as well. And your "categories" are exactly the same as mail folders in gmail and could also be displayed and handled alike.

Think about it. Easy, simple, beautiful, powerful, and a lot less messy than the current state of things.

Greetings from the middle of the atlantic ocean... on a ferry from tenerife to cadiz.
Joe.

locus removes too many chars from track names on export! all my tracks are named like
2011-01-19-Tindaya
2011-01-20-PicoNieves
2011-01-21-Bananarama
...

Locus kills the "-" char when building the export file name and does "20110119Tindaya.gpx" Why? I want it, I need it, and Android has no problem with "-" in its file system, none at all :-).

Does google earth on android support ground overlays? If it does, the following could be very useful: offer a function: show in googleearth.

What it does: snapshot the currently visible portion of the map to a png file. Create a kml ground overlay parameters for this. Add all currently visible tracks and points too. Call googleearth with that kml.

Result: perfect 3d overview of the current situation in the best 3d-world that android will evr have.

Just tried night mode on some rmaps and they scroll very slow and sluggish. Night mode seems to eat a lot of processor juice. Not good for battery i suppose

The place dialog (see below) is a bit unfortunate. Some of the icons cause immediate action, some open a sub menu, its not really clear to me which image does what.

With a bit of rearranging, it would be possible to kill the sub menus completely and offer each option directly on a single click. Sub menus are necessary sometimes, but here its just bad usability. There is plenty of space and each extra click is bad when you sit on a bike.


[attachment=0:1stir2kn]SC20120102-093431.jpg[/attachment:1stir2kn]

Maps for arabic countries (like egypt) are rendered with arabic fonts. That might be cool for some usage cases, but I suppose 99% of your users would prefer latin spelling. Is that maybe an option that you can change in mapsforge rendering in Locus? Or is it done at map creation time already?

It'd be nice to click on a rmap/map/tar/etc file in any file manager and have locus launch with that map.

Visualizing disabled buttons with a lighter shade of grey background is a bit un-androidish and confusing imho. How about leaving background unchanged and using foreground (ie icon & text) with an alpha value of 0x40 or some such?

It happens quite often that I read some text description on a web page or in an email like "hey joe, check out N14.8834 E12.666, a pretty cool trail starts there". How to get that into Locus easily?

Maybe your "location" dialog could feature an additional entry "from clipboard"? You'd need to parse the clipboard a bit intelligently though and translate as many different spellings as possible, like
N12.345 E5.678
12 10 20, 14 50 20
13°10'20"N 20°10.22W
etc

[attachment=0:1v0no5qg]SC20111223-175826.png[/attachment:1v0no5qg]

I noticed something strange with a huge RMAP (1.8GB) of the alps that I just created. When the map is on screen (even just partly), everything scrolls nice and smooth. However, when I scroll completely outside the maps area (so that the screen is all white), Locus becomes slow and unresponsive.

It seems as if Locus takes a break every second and does some really complex calculations. Everything (scrolling etc) stops for about 0.2s and then continues normally. This effect seems to increase with the size of the RMAP.

The problem only appears when the RMAP is completely off screen. When at least a few pixels are visible, Locus behaves normally and is very fast and responsive.

Maybe you iterate through all the tiles too much when everything is offscreen?

Your calculations for total climbing are hopelessly wrong. Quite understandable, considering that gps altitude data jumps around more or less randomly by at least 30m. The 15 flat kilometers to my dentist resulted in a 2000m locus climb... I wish we had that kind of mountains here :-).

You need to apply some sort of dampening algorithm on the altitude data before summing up the differences, at least if the origin is gps altitudes.

It works better with google heights, but that's not really useful in the mountains in a foreign country without data connection.

On a related note: how about supporting the pressure sensor of newer phones? That gives much cleaner altitude data when calibrated once.

Locus can join tracks already. How about allowing to split track as well? The menu that appears when I click a trackpoint on the map should offer "Split track here" and then turn "thistrack" into "thistrack_1-429" and "thistrack_430-1099".

When I record a new track and press Stop, Locus asks me for the name. The category defaults to "None". Shouldnt it rather default to "Recorded"?

The track recording message in notification area is a bit boring. Doesnt even give Locus as program name. Could it maybe look like

Locus - track log with 10s/25m since %hh:%mm
myfancytrack - 02:10h - 23.6km - 523 points

first line has gps parameters and start time.
second line has track name & data.

updated not too often to save battery.

Something seems a bit bogus with Locus cpu usage while track recording.

My Galaxy Note stays mostly at 1400MhZ (dual core). Surely thats not really needed for simply storing away points from the GPS? Screen was OFF during measurements, but that didnt really change a thing.

GPS ON, Track Recording ON, Moving -> 1400MHZ

GPS ON, Track Recording OFF, Resting -> 200MHZ

GPS ON, Track Recording ON, Resting -> 1400MHZ

The last measurement is especially strange since Locus didnt have to store away any points then.

I can do more tests if required, but maybe you have some idea what's going on already? In the end, it would be nice if simple "track logger usage" (screen off and track recording on) would keep the processor at its slowest setting.