Messages

Of course its not the same. But does it matter? A local tile server could easily do intelligent caching if it thinks the source format is too cpu intensive to read. This could even go as far as converting whole regions of a map into something else for quicker reads. But whatever it does for speed reasons, it should not ever bother the user with it. I just copy over my geotiff and am done.

I really think the time is ripe to kill custom formats alltogether. Those silly conversion things have messed up the geo world long enough and i hate them with a passion. A bit radical, but true :-).

Of course writing that is quite an undertaking. It doesnt necessarily have to be included in locus or be written by menion. An external tile server app still seems like a good idea to me. If only i was more into java coding and less into mountainbike travelling... i would give it a try. And then shut up forever when i find out its not doable...

Basically, i hate the idea of any conversion. All those custom mobile formats might have been necessary ten years ago, when we had no horsepower to speak of. Nowadays, with at least 2x1ghz in our pockets... whats the point?

If locus doesnt want to support geotiff/geopdf directly, a local wms server on android easily could. No reason not to use the same map files on desktop and on mobile... to hell with all conversions

You can use kompass maps in locus already. It involves a shady tool called "OziMapTrans" to convert kompass to tiff and then the demo version of ttqv to convert the tiff to rmap. Locus can read rmap.

If all that sounds complex and crappy to you, it is. The mapping companies do not want you to use their data outside their own applications, even if you bought it and own the dvds.

Is there any way to tell if locus is actually using the pressure sensor?

Just thinking... for testing and maybe also for geeky details, locus could add a waypoint whenever it does some calibration thingies to the sensor. Add a special "automated" poi category so users can enable at will. This could also be used as a general "geologging" thing. You could create "automated" waypoints for many different events (like track export, minimize/maximize, anything of interest).

Its not supposed to be a mapping app. Just a quick 3d visual of the current locus screen. A function like this is quite useful even on the desktop (ttvq offers that eg).

However, as it seems, earth mobile cant even load kml files?! Google completely sucks for this.

Does google earth on android support ground overlays? If it does, the following could be very useful: offer a function: show in googleearth.

What it does: snapshot the currently visible portion of the map to a png file. Create a kml ground overlay parameters for this. Add all currently visible tracks and points too. Call googleearth with that kml.

Result: perfect 3d overview of the current situation in the best 3d-world that android will evr have.

Opengl plus DEM handling will rule the locus world

Just tried night mode on some rmaps and they scroll very slow and sluggish. Night mode seems to eat a lot of processor juice. Not good for battery i suppose

I think older garmins had the altitude jump problem after recalibration. So they changed it to the gradial thing in newer devices/firmware

Is the barometric locus online somewhere for testing already? I could do a sea journey recording in 30 mins and see if it stays at deck altitude properly

Just thinking... it might be worth to consider storing raw data in your data base, ie both gps value and pressure sensor value. You could do the calculations later on export/display. And maybe do funny things too, like a weather forecast .

In general, i think automatic re-calibration during track recording should be done very careful, if at all. Its much more likely to receive a bunch of bullshit gps fixes (think canyons, deep wet forest, rock climbing) than it is to receive wrong barometric data.

Ive read that garmin sort of recalibrates gradually with time to counterbalance weather influence. No immediate changes though, its more like a gradual thing moving the two data streams closer together.

What seems to be important:

A) only very good 3d gps fixes with excellent accuracy are taken into consideration for calibration at all.

B) when the difference of gps & barometric data is too big (garmin uses 300m i guess), measuring is considered an error and not used for re-calibration.

Obviously we need to be able to turn off all pressure sensor handling and use raw gps data like now. Otherwise you cannot track heights while flying in pressurized cabins.

Its quite a complex topic really, just reading a bit.

 http://www.gpswiki.de/dwiki/begriffe/barometer has some valuable info on how garmin treats it. U.fortunately in german....

Background is nice most of the time i guess. However, in case of a serious weather change, calibration must be repeated. Manually?

Also, there might be circumstances when the gps altitude value is simply bullshit. Like in a canyon or or when climbing a huge vertical rock face or whatever.

I think, in the end, a manual calibration screen is sometimes required. It should allow entering the altitude but also allow using the current gps value.  Users can call this manual calibration when they thonk they need it (weather change or difficult gps signal conditions).

Or locus shows it when it fails at automatic calibration, eg because the gps measurements are too far apart.

All garmin devices deal with it in some way. They also have different modes later, ie some are better for flying and some for hiking. I dont really know what they do exactly, it might be worth some research.

I think you need to calibrate it. That could either be manually by the user entering current altitude or automatically. You could eg take the first 5 gps heights when a new track is started and calibrate the sensor with that and then only use pressure data for heights.