Messages

Sure. But as a computer geek, i just like every file in my file browser to be associated with something useful. Non-clickable items irritate me .

You rock! Greetings from Lanzarote btw... Locus finds all the trails easily

no change with 1.15.4.3 (ie locus still freezes for a split second when rmaps are completely off screen and i try to scroll).
also no change for the 3gb map.

I just thought it would be convenient while I played around with file explorers and rmaps. No clue how file types work on android though, so if it's too complex, forget it. As long as you can open gpx, everything is fine .

uploading 3GB is beyond my capabilities :-( and smaller maps work nicely.

maybe some fseek() or whatever this is called in java beyond the 2GB boundary fails. you have to read data from the end i guess? a bit more debug whenever rmaps fail might be helpful.

it might even be helpful in general as an error message for the normal (nondebug) user.

CompeGPS MAP File
<Header>
Version=2
VerCompeGPS=6.72
Projection=3,Transversal Mercator, 9, 0, 0, 500000,1
Coordinates=1
Datum=WGS 84
</Header>
<Map>
Bitmap=KMP-Alpen-DE-AUT-CH-IT-SLO.rmap
BitsPerPixel=0
BitmapWidth=141049
BitmapHeight=55905
</Map>
<Calibration>
P1= 0, 0,, 5.87168899997482, 47.8668659999137
P2= 70524.5, 0,, 10.5878400006239, 47.8985209060187
P3= 141049, 0,, 15.2873839956531, 47.7369799944763
P4= 0, 27952.5,, 5.94481549987443, 46.6110613118524
P5= 70524.5, 27952.5,, 10.5506702027813, 46.6413627298758
P6= 141049, 27952.5,, 15.1412682455545, 46.4867141048772
P7= 0, 55905,, 6.01320499997158, 45.3548969999388
P8= 70524.5, 55905,, 10.5159115985245, 45.3839056874145
P9= 141049, 55905,, 15.0045629983003, 45.2358419960646
</Calibration>

probably not, but i just wanted to find out more. it's on fat32 microsd. movies up to 4GB apparently work with certain video players.

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?

Speaking about huge maps: I am just trying a 3GB RMAP file again. Locus doesnt even show it in the map manager. I tried to query "adb logcat | grep locus" for some information, but it only contains rubbish as far as i can see :-). Could you maybe make it a bit more verbose with useful debug information? I'd like to know why certain RMAP files are refused.

Maybe it would be better to not ever deny a map file, even if it's broken/mangled/wrong projection or has other errors. They should still show up in map manager. When the user selects it, you can write a specific error text into the rendered tiles, eg "projection xyz not supported" or "file read error at position 4123412421". Then people know what's going on immediately.

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

Das kalibrieren wird mehr oder weniger automatisch gehen... man könnte zb die ersten fünf gps-Trackpunkte mitteln oder sonst irgendwas halbwegs intelligentes.

Und was die Qualität der Druckmessung angeht... die Sensoren sind pfennigware und seit Jahrzehnten in allen möglichen Sachen verbaut. Selbst meine uralte Armbanduhr hat genauere Höhen als aktuelle GPS-Geräte, vor allem schwanken sie nicht mit der Position.

Erste Tests mit dem Galaxy Note im Aufzug haben sehr vernünftige Werte ergeben (Erdgeschoss bis achter Stock, schon 5m konnte man an den Werten ablesen). Das heisst natürlich nicht, dass Samsung es nicht trotzdem versauen könnte (so wie etwa das miserable GPS vom ersten Galaxy). Aber vom Prinzip her müsste es sehr gut funktionieren.

Ein GPS zum kalibirieren des Barometers am Beginn der Tour ist doch vorhanden .

Das Problem von GPS-Höhenmessungen sind ja eigentlich nur die häufigen "Schwankungen" um ein paar Meter je nach Position und Empfangsbedingungen unterwegs. Darum sehen GPS-Höhenprofile ohne algorithmische Filter auch immer sehr "zerfretzelt" aus und die Berechnung von gekletterten Höhenmetern gerät zum Ratespiel.

Wenn man einmal am Morgen das Barometer mit einer gemittelten GPS-Höhe aus ein paar Messungen kalibriert, bekommt man danach mit dem Drucksensor beste Daten und beste Höhenprofile, ohne hinterher irgendwas gerade rechnen zu müssen. Bei einem extremen Wetterumschwung unterwegs müsste man diese Kalibrierung allerdings wiederholen.

Wie auch immer: der Autor unserer allseits geliebten Mapping-App befindet sich bereits im Besitz eines aktuellen Eiskrembrötchen-Androiden mit Drucksensor. Die Unterstützung wird also sicher nicht mehr lange auf sich warten lassen.

Barometer wird von Locus (noch?) nicht unterstützt. Mit OruxMaps neuester Beta sollte es allerdings funktionieren. Habs noch nicht probiert.

I agree. Storing original data is better.

You could also store barometer reading with every point and do something useful with it later . I know it's a bit hard/impossible to work on, if your own device doesnt have a pressure sensor. Might still be worth to at least keep it in mind for later. I believe pressure sensors will become quite common in the future. googles new flagship phone has one too.

maybe a bit like


ie background stays the same, foreground (icon and/or text) is painted with alpha blending.

however, i disagree a bit with the idea of disabled toolbar buttons in general. maybe they should be made clever toggles instead.