Waypoint text style

[joeloc]

The altidude of waypoints is displayed a bit strangely in a second text bubble. That results in a very messy screen when you have multiple points (see picture).

Suggestion: ONE item (ie a waypoint) can only have ONE bubble. Could either be

Col Raiser (2500m)

or

Col Raiser
 (2500m)


If you want to be fancy, make it an option:

Display waypoint elevation...
o ... not at all.
o ... besides name.
o ... below name.

If you want to be even fancier, waypoint display styles should be adjustable per category. Elevation might be interesting to see for mountain huts or passes but not interesting at all for peoples home addresses.

[joeloc]

Btw, I just noticed that Locus doesnt display german umlauts. They come from a gpx file with xml version="1.0" encoding="ISO-8859-1" standalone="yes" and are just used verbatim (äöü ÄÖÜ ß) throughout the file. See attachment. This should work in theory? Or is my file wrong somehow? Imports nicely into other software though.

[Menion]

joe, is this file works for you? Weird, because I get WrongUTFFormat exception on background during import.

anyway, seems like some problem with parser in android. Accept only utf-8 encoding. Anyway small hack helped so now fixed and working

and btw. I think that displaying all item names for whole time is not much useful. I like current system that display altitude above so if there will not be some global revolt, I'll keep it as is

[joeloc]

I'm not giving up so easily :-).

Separate bubbles for one item is a bad idea and only works if you have VERY FEW waypoints on screen. As soon as your data grows and you're using POIs as sort of a "map enhancement overlay", things get bad. For example, I always want to see all "mountainbikable" cols on my maps of the alps. With Locus, it is just a huge mess. It is completely unclear which altitude belongs to which waypoint:

That display doesnt make any sense at all. To get what I want with Locus, I'd have to remove the elevation tag from all my POI files and add it as text to the name tag manually. Possible, but a bit lame.

If you really prefer this look, add it to the settings and make it default. Everybody happy

Display waypoint elevation...
o ... not at all.
o ... separatly <- make this the default
o ... besides name.
o ... below name.

[Menion]

oki ...

[attachment=2:15yz7bph]device-2011-12-10-084432.png[/attachment:15yz7bph][attachment=1:15yz7bph]device-2011-12-10-084504.png[/attachment:15yz7bph][attachment=0:15yz7bph]device-2011-12-10-084524.png[/attachment:15yz7bph]

edit: ah I also changed "never" for "disable"

[joeloc]

Better than before. Still eating too much screen estate though. I dont really want 5% of my screen eaten by the word "Altitude". It's pretty clear what "1234m" means anyway, no need to repeat that a dozen times. Best style for plenty waypoints is imho still a simple oneliner:

"Dremelscharte (2500m)"

I also noticed an item called "Distance" now, which I dont need. Any option to turn that off?

Generally speaking: I agree that different users might have different tastes for what they want to be displayed. Catering to all of them with options might lead into a bit of a mess. How about you invent a few simple string replacement tokens instead? Then the options could be reduced to one simple string field, like:

Waypoint Information: "<name> (<elevation>)"
or
Waypoint Information: "<name>nAltitude: <elevation>nDistance: <distance>"
or simply
Waypoint Information: "<name>"

The same configuration language could be used for track labels, like:
Track Information:  "<name> (<length>)"
or
Track Information: "<name>nLength: <length>nClimbing: <climb>"
or
Track Information: "<name> (<length>km, <climb>m)

Furthermore, it could be used to configure dashboard elements on main screen, like
Main screen title field: "<mapname>n(<zoom>, <minzoom>-<maxzoom>)"

I agree that configuring "string tokens" is not ideally suited for beginners. However, beginners usually dont want to change those aspects of the user interface anyway. And you could still offer popup lists with the string gadgets that contain examples for various useful possibilities.

Different settings for different waypoint categories would also be easy to accomplish. Users might want "<name> (<elevation>)" for mountain passes and "<name>n<address>n<phonennr>" for some sort of contacts database or "<name> (<distance>)" for geocaches.

To accomplish this, each waypoint category could offer its custom "format string field". When empty, the default format from main settings dialog is used.

[Menion]

I don't understand why you still have such problems with this labeling system. You're walking in terrain with map zoomed, as I see, to cca 100km over display? If not, then for just quick overview of map, this is good. Altitude in bottom line is there because I still don't have working mechanism to break text lines and also that this system looks nice by me. Distance is there because you have enabled GPS so Locus know you location and display distance to POI. If you find 10 people that will for sure need some improvements like you want, I'll start think about it. Till then, I see no reason to complicate Locus by any other settings like you want.

[joeloc]

Wasted space is wasted space... and space is always a premium on mobile devices. What's there not to understand?

The current 3-line-display (screenshot above) eats up almost three times as many map pixels than a simple "Ehrwalder Alm (1486m, 24km)" one-liner would use. Or in other words: a one-liner would allow three times as many waypoints to be displayed nicely.

Why would anybody want to fill his display with endlessly repeating words like "Meereshöhe" and "Distanz" and huge greyed out areas? A map is not a place for labels, they are just lost pixels without content. But ok... lets wait for more supporters against pixel waste... I hope this thread has enough readers... please reply

[stebu]

As a geocacher I need some info about closest caches, but in urban areas even a one-liner is too much!
So this is again a possibility to ask for a short list, maybe 5, closest POIs to be shown at the bottom of the display  :roll:

[joeloc]

There's just so many different uses for waypoints... it's quite hard to make everybody happy :-).

[stebu]

Hi! I was experimenting with the label size. In Pro 1.14.6 I changed the size to HUGE, Locus asked me to restart, so I did. Then it force closed every time I restarted it! Finally I was quick enough to change the size back to Big. The Show setting was "On hover".
In all crash reports there is <entry key="STACK_TRACE_KEY">java.lang.OutOfMemoryError: bitmap size exceeds VM budget! I didn't know that HUGE was this humangous

I tried the same with the recent (map) testing version, HUGE didn't crash, but the labels were small! Then I chnged the label size to Big and the app crashed. Another restart and it seems to work, but the label size is still small on display, the setting is Big, on hover.
There are a crash and an error report, I can't say what's the problem.

The reports are atteched. The first ones (about 15:00) are from the pro and the last two (18:00) are from the test version

[stebu]

The latest market version also force closes when HUGE size is selected

[Menion]

stebu, thanks for email. Unfortunately part of code where was error is quite different now so crash log is useless for me now. ANyway they're always welcome

joe, labeling system changed a little ... again, so try it and let me know. Hope you'll be silent for a while (just kidding, really ... ) ...

[joeloc]

Very pretty... I LIKE IT!

There's still about two or three wasted pixels, vertically, below the label, though :-).

[stebu]

Hi Menion!
Something for your ToDo-list.
I was driving around geocaching and switched the POI alert on. (As you remember I've been asking for a list of 5 closest POIs)
I thought about an alternative solution:
-each time the POI alert draws the thin blue line to a close by POI,
    it should also highlight the POI and show the waypoint name and distance.
-each time the blue line is erased,
    the POI's text should disappear.

This would be useful. And hopefully easier to implement than the list.