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

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.

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.

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.

[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 :-).

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.

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.

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.

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

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.

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

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>)"
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>)"
Track Information: "<name>nLength: <length>nClimbing: <climb>"
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.

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

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.


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?

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:// , 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 :-).

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