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 ... 17 18 [19] 20 21 22
271
Implemented / Re: Waypoint text style
« on: December 16, 2011, 17:07:52 »
Very pretty... I LIKE IT!

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

272
Troubles & Questions / Re: CPU usage while track recording
« on: December 16, 2011, 16:32:06 »
sorry, still the same cpu usage with latest test version. about 70% on 1400mhz when track recording is on. screen off, phone sits quietly on window, gps fix acquired. system settings / location / use sensor aiding is disabled btw for these tests, otherwise android would simply turn the gps off after a while.

exact same test but with track recording OFF: only 5% at 1400 and 90% at 200MHZ!!

Maybe it has to do with the track recording message in notification area? Is it accidently updated too often? Or something on locus screen? Although the screen is off... I have no clue :)

273
Troubles & Questions / Re: Preferred map format
« on: December 16, 2011, 15:13:02 »
try ttqv4. it's the best tool for rmap export right now. works with demo afaik:
http://www.ttqv2.de/files9/qv4setup_e.exe
http://www.ttqv2.de/files9/qv4upd_133.exe

274
Troubles & Questions / Re: Preferred map format
« on: December 16, 2011, 11:03:22 »
No idea then. I mostly convert kompass maps and it creates tif and cal and map files nicely. Can be loaded into ttqv and globalmapper without problem.

Never really tried ozf3 though.

275
Troubles & Questions / Re: Preferred map format
« on: December 16, 2011, 08:39:32 »
ozfx3 is a private beast of OziExplorer, encrypted and specifically meant not to be used outside Ozi applications. The swiss army knife tool "OziMapTrans" will decrypt and convert this to a simple TIFF, which in turn can be imported by CompeLand or TTQV and exported into an RMAP for Locus.

OziMapTrans has been discontinued by its author but still works surprisingly well. Google is your friend.

276
Troubles & Questions / Re: CPU usage while track recording
« on: December 16, 2011, 08:29:36 »
I made a direct comparison of Locus vs Oruxmaps, track recording on, screen off, comparable settings, phone sitting quietly on window for ten minutes. Locus spent about 70% of time at 1400MHZ, Oruxmaps only 20%. Something still seems fishy :-).

Measuring was done with cpuspy. Of course there can be a million reasons for this, not neccessarily being Locus fault. Some code paths might work better with some schedulers than others. Android is a complex beast.

277
[DE] - deutschsprachiger Forumsbereich / Re: gps touren
« on: December 15, 2011, 21:00:02 »
gpsies hat zum beispiel eine eigene app, mit der man touren in der nähe finden und als gpx abspeichern kann. das file kann man dann mit einem klick in locus importieren. ist zwar nicht so schön wie direkt auf der locus-karte, aber immerhin gehts mobil und ohne umweg über den pc.

in wie weit die ganzen portale überhaupt noch nützlich sind, nachdem mittlerweile neun von zehn "touren" in etwa das niveau von "fahrt zum bäcker, brötchen holen" haben, lass ich mal dahingestellt :-).

278
Troubles & Questions / Re: CPU usage while track recording
« on: December 15, 2011, 20:44:43 »
could of course be my methods of measuring... no idea. i used cpuspy and have locus sit quietly on the window for ten minutes with track recording on. 7:30 mins were spent at 1400MHZ and 2:20 mins at 200MHZ.

279
Troubles & Questions / CPU usage while track recording
« on: December 15, 2011, 20:15:29 »
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.

280
Under review / Vicinity field
« on: December 14, 2011, 18:35:07 »
Coming from the waypoint style thread, I'd like to suggest something a little bit related: a new "vicinity field". It could sit on bottom of screen and show the closest items (waypoints, tracks, routes, whatever) in locus databases. Sorted by distance from left to right, as many as will fit:

Code: [Select]
Arlbergpass    | Zugspitze      | Hallerangerhaus |   |
(1300m, 5.2km) | (2998m, 8.9km) | (2300m, 12.3km) | x |

Alternative design as a simple list, left-bottom aligned:

Code: [Select]
Arlbergpass (1300m, 5.2km)
Zugspitze (2998m, 8.9km)
Hallerangerhaus (2300m, 12.3km)
Track Nr 123 (1000m, 15km)

This list should be independent from what is actually displayed on the map. Just a global distance search over all items in all databases. On tap, it would scroll the map to the item (and enable it for display if not done so yet).

Possible prefs settings for Vicinity:

Show/hide vicinity field automatically when closest item is nearer/farer than
xxx km.

281
Implemented / Re: Waypoint text style
« on: December 14, 2011, 14:22:06 »
There's just so many different uses for waypoints... it's quite hard to make everybody happy :-).

282
Implemented / Re: RMAP map format
« on: December 14, 2011, 14:14:18 »
geotifs are better suited for maps than simple jpgs. they can have tiles as well as overviews, both quite necessary for speedy handling on mobile devices. jpgs/pngs/etc on the other hand would have to be loaded more or less completely into memory. that will not work well for larger maps. geotifs can also use jpg compression internally, so file sizes must not differ much.

there might be occasions where using a simple jpeg/png image plus worldfile/mapfile/calfile is useful, eg for compatibility reasons on the road. but since ttqv/compeland at home can turn these files into a speedy RMAP with a single mouse click, i wouldnt think it's that important.

In an ideal world, we wouldnt need the windows machine at home for our mapping needs. We could simply buy the map DVDs from Kompass/IGN/whoever and copy over the files to our Android device. Unfortunately, the mapping world is one of the biggest messes in existance. Everybody and his dog uses a different custom format, has very restrictive license policies, tries to encrypt his data, forbids usage outside his own apps, etcpp.

One solution to this "OziMapTrans", a pretty nifty tool that converts most proprietary map formats to a simple geotif. Unfortunately, probably due to complaints from mapping companies, the program has been discontinued. Of course the www never forgets, so you can still find it if you look closely.

283
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 :)

284
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.


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

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