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.


Messages - joeloc

Pages: 1 ... 18 19 [20] 21 22
286
Implemented / Re: Waypoint text style
« on: December 13, 2011, 20:11:11 »
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 :)

287
Implemented / Re: Waypoint text style
« on: December 13, 2011, 12:22:53 »
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.


288
Troubles & Questions / Re: Data path
« on: December 13, 2011, 11:18:12 »
I agree. Maps folders are perfect. Thanks!

289
Troubles & Questions / Custom screen switching & energy issues
« on: December 09, 2011, 10:38:42 »
I want to make a very basic custom screen that serves as a replacement for a simple speedometer on a bike:

++++++++++++
+    26 km/h
+    550m      
+
+
+
+
+
+
+
++++++++++++

Since it's supposed to be always on, the main issue here is amoled energy consumption. All black with just a few white letters, no complex map updating, no track drawing, no nothing. So far so good, that should be doable with Locus style sheets.

Questions:

a) I can use the back button to return to main screen. Good. Can I somehow make my custom screen also return to main by a simple single tap just anywhere on screen?

b) I would need Locus to automatically turn the screen off if the speed is 0 km/h for a minute and turn it back on when I start moving again. That could be handled either by gps or motion sensors I guess. Any ideas on this?

c) If I do not have a map displayed on my custom screen, will Locus still do internal calculations, rotations calcs, etcpp? Or is it all intelligently suspended until the map is actually visible?

290
Implemented / Re: Display track/route name on map
« on: December 08, 2011, 20:51:03 »
Btw, Locus really becomes very slow and sluggish when a few tracks are enabled, even when they are not visible. That cant be right. Test case: Import single tracks of Gran Canaria from http://http://forum.asamm.cz/download/file.php?id=478 , enable them all, then scroll around Prague. Very slow... and nothing to do with acually displaying any pixels.

Solution: a track should calculate and store its bounding box (max left/top/right/bottom coordinate) when imported into your database. Then you can quickly check if it's visible at all with just a few comparisons between screen and bounding box. This way, invisible but enabled tracks will not slow down Locus much.

Other solution: Store all your geospatial data in R-Trees. That will even work for tenthousand enabled tracks :-).

291
Implemented / Re: Display track/route name on map
« on: December 08, 2011, 20:15:32 »
there is other stuff that worries me more, a little bit of 3d here and there cannot hurt :). are you moving your whole display engine to opengl btw? and we'll get realtime 3d-maps, smooth like in googleearth? the dem data is freely available...

btw, locus is really quite impressive for a one-man job. or is there a whole team behind you?

292
Implemented / Re: Display track/route name on map
« on: December 08, 2011, 19:54:00 »
the problem is: it's very easy to activate this 3d mode accidently when zooming with two fingers. and then your screen gets all messy on you in the blink of an eye.

i thought enabling "simple multitouch" in settings should forbid the 3d-mode completely, but apparently it doesnt.

293
Implemented / Re: Single click "immediate" route create mode
« on: December 08, 2011, 18:08:41 »
hm... on a second thought... my "quick add" points are about 0.5cm below where i actually tap. and that happens with finger & stylus. thats a bit weird, because the touch test app shows the touch screen to be very accurate.

294
Implemented / Re: Display track/route name on map
« on: December 08, 2011, 18:02:49 »
I know I'm a pain in the a*... sorry :)

Anyway... permanent display of track name is good! However, I see now that the additional Data (Distance & Climb) is a bit too much really even for the Galaxy Note (1280x800). It might work for one or two tracks on screen, but not for a trail network. So I'd remove that info from the label and only leave a one-line track name for now.

I'd also kill the "START" icon completely because it's obviously at the same place as the label.

The font in the label box should use the same color as the track itself.

Later, you can make it an option to please everyone out there:

Display Tracks...
o  ... without any labels or icons.
o  ... with start & end icons.
o  ... with title.
o  ... with title & additional data.

Btw... labels can apparently overlap now. How complex would it be to store position and dimension of all boxes on screen and try to shift overlapping boxes a bit to prevent overlapping? That should work for track names as well as POIs.

Btw2... this is about item selection with finger tapping. It's quite nice that you present a list of things "close" to the tap to choose from. However, if the tap coordinates can directly be connected to a specific label box on screen, I meant to select exactly this track and not any other one.


295
Implemented / Re: Single click "immediate" route create mode
« on: December 08, 2011, 17:32:31 »
Works nicely in new version! Cool :)

296
Implemented / Re: Waypoint text style
« on: December 07, 2011, 19:34:30 »
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.

297
Implemented / Re: RMAP map format
« on: December 07, 2011, 14:45:17 »
TTQV (works also with demo version) or CompeLand (iirc works also with demo version). Both can for example import any ECW or GEOTIFF or *.map/*.cal thingy and then export RMAP format. It's called "Export Aventura/Sportiva" in TTQV4.

298
Implemented / Re: Display track/route name on map
« on: December 07, 2011, 09:33:43 »
Hm... yes! A track's starting point could just be handled as a POI, settingswise. Then we get the name on the map immediately. Good idea.

As for the hovering... it's a very good method to display more information on mouse-controlled devices. But I'm not sure if it really works well on touchscreens. Tapping might be more intuitive. Oh well, maybe it's just me. Might need some getting used to.

Btw, instead of Start & Finish icons, you could also try to add some tiny arrows along the track, indicating the direction. A bit like what you use in your "guide mode". That would also work nicely with roundtrips, where start & finish is the same. Might be a bit more difficult to implement though.

299
Implemented / Re: Waypoint text style
« on: December 07, 2011, 08:46:52 »
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.

300
Implemented / Waypoint text style
« on: December 06, 2011, 23:07:20 »
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.

Pages: 1 ... 18 19 [20] 21 22