I'm opening discussion on topic - altitude in Locus
I'll ... from conversation that I had with Christian over email (and also with other people here on forum)
"I noticed that the alitude difference of gpx tracks i downloaded (and checked) miscalculated in Locus (track details and diagram also). As attachement a track i want to use it for the alp cross. It has 76,38km and 802m ascendency shown in different software programs (approximately). Locus shows 387m ascendency :-( "
Altitude from GPS is generally a problem, there's no doubt about it. Question is, what's the best way, how to handle it
current solution
Current solution is quite simple, it's based only on a small small filter (set in settings), that optimize altitude a little bit before storing to database!
Altitude results (uphill, downhill, ...) are computed as a sum of altitude change on distance. So change from -2% to +2% are considered as a "flat", others are uphill, downhill
place for improvements
no filter may help to get better values to altitude. It may reduce some huge noises, but ... so question is what we should do with this, to get as good as possible results.
- possibility is to keep current system, but create better filtering method. Some more logical system, that will filter and compute better values
- locus fully support SRTM files, so it's quite easy to compute altitude values during a track record and substitude GPS altitude values, by this computed. Here is question - precision of this method. I did not test it ...
- other possibility or combination?
- you may be also fully satisfied with current system. This is also option
A combination of GPS and calibrated pressure sensor perhaps?
(With the Galaxy Note the display should be always on :cry: )
Hi Menion,
just a few thoughts from my experiences with altitude measurement:
1) With GPS based altitude I had to use strong filter to get useful results. With weaker filter settings I got much higher result for altitude
2) With pressure based altitude measurement I have to use the strong filter again for the same reason as in 1)
2a) I'd like to see automatic pressor sensor calibration before start of track recording based on SRTM for current location
2b) Can I use the altitude based on pressure sensor values also on the fly (i.e. without a track?)
3) I think the -2..+2% aren't necessary if the filter is "strong enough"
4) For track *planning* (add route and measure) I'd like to see an option to calculate the altitude profile based on e.g. SRTM values along the track. Altitude only for the points on the route isn't sufficient as you would need to define points on all the local minima/maxima (valleys, hills) on the tour which are not always easily visible.
5) Don't know how the current filter really works. Is it a FIR, an IIR filter? Or something proprietary? This not to ridicule you but out of interest as you write "create better filtering method"
As I wrote in the beginning, just a few thoughts, nothing really serious.
@jusc:
I'm sure we all now know, that pressure sensor is is on modern Samsung devices useless. Unfortunately. Also calibration have to be improved. I have already here a topic from one user viewtopic.php?f=10&t=728&p=19237#p19237 (http://forum.locusmap.eu/viewtopic.php?f=10&t=728&p=19237#p19237) so I'm more then sure, improvements are needed. Anyway this will not solve problems, because I think that pressure sensors is not solution on this problem that all may use (limited number of device has pressure sensor btw.)
@tommi:
after quick learn lesson about filters, I discovered that I use very simple IIR filter. Something like
Y(i) (final) = Y(i) (measured) * X1 + Y(i-1) * (1 - X1)
Anyway I agree that SRTM data should be probably best way to achieve some usable results. Better filter is probably not a solution right? I'm not much skilled with all these data processing, so some expert advices are of course welcome ;)
Now I am using pressure sensor and compare height with SRTM data (pressure sensor calibrate using METAR). Sometimes difference is about 2 meters, sometimes more than 10 meters. So SRTM data not very precise. But GPS height, especially in the town or forest, is very inaccurate, all the time jumps up/down. Btw using SRTM data is good idea (when you can't use preassure sensor, of course). Better GPS filter not a solution, right - you'll get slowly change height and wrong height (GPS height sometimes is very inaccurate).
Better filter could only give better result if we have a noisy altitude signal over time and you use a low pass filter to filter away the noise. Problem with GPS altitude data is that you cannot rely on it having only some noise. Sometimes it has really jumps in it and filtering these away would mean to filter away other meaningful changes in the signal.
So I agree that we cannot easily get a perfectly filtered result.
Results with pressure sensor are a bit better but as you say only few devices have such a sensor and additionally I even there saw jumps in the data which I have no explanation for.
Unfortunately there are also errors in SRTM data...
Quote from: "menion"@jusc:
I'm sure we all now know, that pressure sensor is is on modern Samsung devices useless. Unfortunately. Also calibration have to be improved. I have already here a topic from one user viewtopic.php?f=10&t=728&p=19237#p19237 (http://forum.locusmap.eu/viewtopic.php?f=10&t=728&p=19237#p19237) so I'm more then sure, improvements are needed. Anyway this will not solve problems, because I think that pressure sensors is not solution on this problem that all may use (limited number of device has pressure sensor btw.)
yes I know. But I support still the idea to use the pressure sensor too, because other special GPS devices like Garmins 62 or Compes Sportiva use it too to improve the altitude data. For me personally it´s annoying that the Note 2 doesn´t use the sensor while the display is off. But on the other side Tommi has shown, that it works correctly with a S3. So not all Samsung devices are failing. And which releated the problem "limited number of devices use a pressure sensor", so I would answer: Locus offers ANT support, but how much devices support ANT?
And Maksym is right, SRTM or GPS data are failing p. e. with trees (forests). I often wondered about altitude data in my tracks of plan areas, there I suddenly should have climbed 30 meters.
So in my eyes a combination of GPS and/ or SRTM and pressure sensor could be a way to improve the altitude data. For those the correct altitude is important, they would buy a phone with pressure sensor, I think.
I think menion think what to do with users who can't use pressure sensor. That users who can use it still will use pressure sensor. Nobody will disable pressure sensor altitude :-). I hope even add some methods to automatic calibration. But that users who can't use pressure sensor want to have precise altitude too. This topic is also about how to do it.
Hi guys,
i'm the one who started the discussion via email with Menion. Thanx to Menion for the support (even during weekend) and the thread here. Sorry for the delay. I was biking the last days in the spring.
I'm not the specialist in programming or GPS related stuff. I'm just a user who want to use the nice app for mountainbiking (planning tours in / over) alps.
So i understand that :
: GPS ist not precise in recording heights,
: Filters can work, mostly not
: pressure sensor as well,
: different devices from different manufacturer computing ascendency in different ways.
For me a "fix point" in this universe could be solution. Means calibrated values from satellites in SRTM Files.
If i record a track in traditional way - like possible in Locus just now - i will get values with "noises", means wrong data due to influences from the environment during recording. This is what we have now. In some cases the accumulated values of ascendency differ up to 30% from other recordings. (Not unimportant when you are in the alps! Thats why i started the discussion)
May be there is a solution if i had the possibility to compare the recorded values with values of SRTM files. Better Locus should compare this for me.
possibility 1:
point A: recorded height in traditional way: 5m
point B: recorded height in traditional way: 25m
point C: recorded height in traditional way: 7m
point A: height value from SRTM file: 5m
point B: height value from SRTM file: 8m
point C: height value from SRTM file: 6m
Locus can straighten the values.
possibility 2:
give users a choice to use values from SRTM files for their recordings (before or after record) or use the values from their device.
English is not my native language. So if there are any blurs don't hesitate to ask :-)
Christian
Hi,
I would prefer a combination of GPS and SRTM heights.
After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).
Quote from: "Maksym"After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).
I also would prefer a combination (to be discussed average of raw values from each available source, average of filtered values from each available source, ...) [source = GPS, SRTM, pressure]
I think it would help a lot to find the best method if we could produce tracks containing data with all three sources. It should be possible then to do an offline investigation (e.g. with a spreadsheet) what the best method would be.
Quote from: "Maksym"After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).
Ahhh, thanx for the information. I tried this some times before but the values are not changing until the window with track details is closed and re-opened...
So i checked my favourite track with the values from SRTM files and the ascendency are quite right. That means ...Locus is computing the uphill and downhill and flat area in the right way but with wrong data. I'm right?
@tommi: "average" is always ...un-exactly.
edith says: using my old but reliable HD2 sensor data are not available. So i would prefer a final solution without pressure sensor data.
No, i'm wrong. All tracks updated with SRTM files has distances in flat area = 0 m.
So i guess its easy to calibrate the algorithm within Locus with support of SRTM values...
Quote from: "Christian"@tommi: "average" is always ...un-exactly.
Average is one possible attempt to make better data out of bad data. Of course it won't lead to exact data out of bad data.
But the available sources are all bad:
GPS: inaccurate, jitters
pressure: more accurate, less jitters but needs calibration, has shift over time due to weather, not available on all phones
SRTM: It is misbelief to think it is correct. Only one km from my home, I know an area where it is definitely wrong: An area with a change from free field to forest and additionally the forest is on a not steep slope. SRTM more or less ignores that and tells the area of field and forest is flat.
Pressure sensor is not very bad: phone has Internet connection and it's not a problem to calibrate time to time pressure sensor using METAR data of nearest airport. Of course if you are not in the middle of Africa where no airports with METAR data. But you can calibrate sensor when get SRTM and GPS height almost the same.
very nice discussion guys, nice surprise. I'm currently finishing some improvements in main menu, point editing and wms layers, anyway since next week, I'll try to focus on better handling of SRTM data (mainly downloading of HGT) and as a first step, create some automatic using of SRTM altitudes, at least for checking of GPS altitudes. So sorry for letting you wait ... I'll start next week on this
Recently, I was on a skiing trip and recorded the tracks. The "information" tab was useless for most tracks since the recorded altitude had big jumps. You certainly remember the discussion about "maximum possible speed". In one case the altitude jumped from one track point to the next from 2500 m to 25000 m (yes, factor ten!) and back.
In my opinion the post-processing of the raw GPS-data can be improved considerably. Additional sources like pressure / SRTM data can be used to improve the altitude for example under known problematic situations (forest, city), when the GPS signal is bad.
The post-processing should first check for obvious outliers (jump of position/speed/acceleratoin between neighbooring points) and secondly use a (FIR-)filter of higher order (meaning that not only the last two points are considered but rather for example the last eight).
If needed I could provide the track showing the above mentioned misbehaviour. I deleted the messy points from the track, though I should have the recorded NMEA data.
Slightly off-topic: Which "altitude correction"-setting is recommanded? Could the option "Use NMEA data" be the source of problems people are sometimes experiencing?
Peter
I am using "Use NMEA data" and get actual height (of course with jumps). The source of problem is inaccurate height limited by GPS technology. The solution is to use pressure sensor. All other methods will work more or less in the flat open field but useless in difficult situations, I think.
We should wait for Galileo system ;)
Quote from: "Christian"We should wait for Galileo system ;)
and by new phones :). The big players will be happy
fine, all major problems seems to be solved in latest test version, so I'm almost ready for next release version. Because Peter is planning on today some testing on random users, I have some time that I would like to spend on this topic, so ..
Firstly, I will keep support for Pressure sensor, don't worry. There are no plans to leave it be. Problems on Note2 are really stupid, but as jusc wrote, on SGS3 it works correctly and with any alternative ROM on Note2 it will also works fine I think, so don't worry. Pressure will remain.
Biggest problem for me is usually finding best place for some additional features. In user interface I mean. Currently there are three places that work with altitude
- GPS > Altitude filter
- GPS > Altitude correction
- Sensors > Pressure sensor
All three are quite advanced options that may confuse basic users. Ah this is not important now. What I wanted to say, that these three places are really close one to another. So what I have in mind is separate screen called for example "Altitude manager", where will be three tabs, for every item one tab. Except fact that all will be at one place, I'll be also able to add this "manager" as a button to right panel (so you'll have really fast access to required functions like "calibration"). And it will also allow also unlimited extending, because it will be much easier for me. What you think?
Fine, it was about GUI. About what will Locus do on background. Currently I have in mind, compare GPS altitude and SRTM values (or Pressure sensor) and computing deviations, some moving averages etc. For my own surprise, I'll like to have working GUI and then start work on background. Hmm as I think about it, some csv file (text separated by commas) with raw and computed values should be welcome for some check and control right?
so basic system done. Two days of work to create GUI and system and also quite a lot of testing. It's anyway not yet completely ready for publishing and even public testing, but I'll try during next few days, create some testing version. This is mainly information for you, to let you know that I work on this and that, except fixing bugs, this is main priority
Great news!
I appreciate it.
Thank you. I'll wait for release.
Great! But don't hurry...
I'm not ... it's already here viewtopic.php?f=25&t=2983#p19941 (http://forum.locusmap.eu/viewtopic.php?f=25&t=2983#p19941) anyway version contain some issues that tommi and others already reported. I'm working on it but seems, fixed version will be tomorrow. It took longer then I expect to fix it ...
Hi Menion,
additional feedback from today recorded tracks:
The slope curve is much to sensible. There are altitude changes <<1m (recorded with baro, no optimization from elevation data (I think this optimization doesn't make sense with the SGS3's pressure sensor)) which create gradients of e.g. 10%. This maybe is mathematically correct but these altitude changes are in many cases only created by noise in the pressure values.
How is the gradient calculated from altitude?
Currently there is light filter configured for altitude. I can test again with heavy filter. What do you think?
Hi Menion,
new results from today morning:
I recorded a tour with a train today, so we can be sure that the terrain was smooth.
With the heavy altitude filter I got a smoot track with altitude on the y-axis. This wasn't the case for a car tour yesterday with light altitude filter.
-> Heavy altitude filter does the trick regarding smoothness of the altitude curve for the use of pressure sensor on SGS3 (I assume that other properly working pressure sensor phones will give similar results,)
The gradient curve shows only integer % values, it should show the curve at least with a granularity of 0.1%, even a higher resolution would make sense to get a smooth gradient curve.
In my case of the train tour the gradient curve was just a constant line with 0%, though there was a altitude differences of about 70m on 30km.
As an alternative to gradient it should be possible to have a chart for the vertical speed.
A bit off topic: The speed curve is really noisy. Could you add a filter for this one, too? But maybe it is better to filter the recorded distance values which would also result in less noise for the speed curve.
If the reported problems are fixed, I think we have a pretty new feature which is another milestone in the development of Locus tracking!
And one more result, actually related to dashboard but as you're anyway working in this area:
Time variable doesn't count up anymore if GPS was lost e.g. in a tunnel. After the tunnel time counts again normally.
Hello all,
I am a long time user of Locus and I certainly appreciate it. I have (Mainly) two classes of needs with it. Hiking and gliding. Could you add a preference in the track profiles to use or disable SRTM ? When I use Locus to record a glider session, I certainly do not want to be "mapped" to the ground. I would suggest GPS + sensor only in this mode, and low filtering since the sky visibility is good in a plastic box).
Thanks,
Denis
Hi Menion,
I understand Altitude manager better now.
Just one point regarding *calibration* of pressure sensor: can I use SRTM data for this purpose?
As you didn't mention it: are the other issues I reported here fixed?
Thanks,
Tommi
Hi Tommi,
fine, I'm glad it's better - "one screen (tab) to rule them all" :)
- hmm SRTM for pressure sensor - no it's not possible. I'll add it to last column where you define exact altitude for current pressure, this will work right?
- and fixed mentioned problems ... I was working on charts. Gradient now display correct values, not rounded. You may also compare charts not (for example with Locus Pro from store). All charts now do not display exact values, but all values are little bit filtered. Just a little, but it's much better to watch them now ...
- I was also think about filters ... maybe I'll make them all little bit stronger, because from your testing seems that "light and medium" are completely useless
- not refreshing time in dashboard - I forget on this, so tomorrow
Quote from: "menion"- hmm SRTM for pressure sensor - no it's not possible. I'll add it to last column where you define exact altitude for current pressure, this will work right?
Yes, something like "automatic cslibration according to SRTM".
Quote from: "menion"- I was also think about filters ... maybe I'll make them all little bit stronger, because from your testing seems that "light and medium" are completely useless
This was my impression, not sure about others'.
Thanks again,
Tommi
Hi Menion,
sorry for being besetting but I fear it could be forgotten since some time passed and a new test version is available.
Quote from: "tommi"Quote from: "menion"- hmm SRTM for pressure sensor - no it's not possible. I'll add it to last column where you define exact altitude for current pressure, this will work right?
Yes, something like "automatic calibration according to SRTM".
And few more reports in this topic from my side regarding value display in dashboards...
hello Tommi,
I have two things to discuss :)
1. auto-calibration by SRTM. I was thinking about it now and I'm not sure this feature is needed. When you want to use pressure sensor, there is expected you'll have enabled GPS as well. SRTM data are good, but both knows that they're also not precise, mainly in hilly areas. So I'm not sure if this feature will bring any benefit. And also, Altitude manager is unfortunately too complicated, so I think rather about "what to remove" then "what add"
2. time when you lost GPS - I reorded a little values in list of possible values for dashboard. "Time" at begin is time of last fix, not current time. I don't expect, that current time will be needed as it's always in top system bar
Quote from: "menion"hello Tommi,
I have two things to discuss :)
o.k, let's discuss :). I'm happy that such things aren't simply disregarded.
Quote from: "menion"1. auto-calibration by SRTM. I was thinking about it now and I'm not sure this feature is needed. When you want to use pressure sensor, there is expected you'll have enabled GPS as well. SRTM data are good, but both knows that they're also not precise, mainly in hilly areas. So I'm not sure if this feature will bring any benefit. And also, Altitude manager is unfortunately too complicated, so I think rather about "what to remove" then "what add"
I agree with you in hilly areas and as well it might also be wrong for our avionic freaks (I'm fascinated they can use such amateur instruments (this is not against Locus which makes the best out of a smartphones sensors) but is this really typical? When do you typically switch on GPS? I guess many more than 50% of all tours (bicycle, hiking) will start at a location like at train stations, parking areas, meeting points, from at home where you can expect quite accuate SRTM data. Automatic GPS correction typically gives me much worse values (e.g. 5..10m instead 0..2m for SRTM).
I try to sum up my understanding of the Altitude manager and also to raise questions:
Tab SETTINGS:
- ALTITUDE OFFSET: this allows different kind of "offsets" offset for the GPS measured altitude to be set on the OFFSET tab
- PRESSURE SENSOR: this enables/disables the PRESSURE tab and has the comment allow to improve measured altitude by pressure sensor.
-> What kind of improvement?
-> Isn't just the pressure value used for calculation of altitude?
- ELEVATION DATA: tick Optimize GPS altitude with comment that optimization is done with offline elevation data.
-> What kind of optimization?
Tab OFFSET:
- Manual correction: Ok, this configures a static offset by calculating the difference between the manual value and the measured altitude for the location of GPS sync
- Automatic correction: Ok, uses the GEOID model, For typical usage (tracks of 1..ca. 100km) it is also more or less a static offset, isn't it (not sure if I understood this correctly)?
- Altitude NMEA correction: ??? No clue what this really does
Tab PRESSURE:
- Automatic: Automatic calibration according to GPS altitude
--> My recommendation: Rename it to Automatic calibration according GPS
- Automatic calibration according SRTM
--> My recommendation: Add this choice
- Pressure at sea level. Ok, this is the classic approach, I won't use it, too much effort to get this data
-Altitude. Manual calibration. This is what I did up to now if I wanted to get accurate altitude data. Typically I used just SRTM information for this which is the reason why I recommend the choice for automatic calibration according SRTM which makes it much more comfortable.
My personal summary (it could possibly be different depending on answers to my above questions):
I think in tab SETTINGS it would make sense to allow either ALTITUDE OFFSET _or_ PRESSURE SENSOR. Phones where the pressure sensor works properly will probably like to use it as it gives the most accurate data for both ground and aviation usage (maybe there will be divers in future ;-)). For all other phones the offset method is appropriate.
Quote from: "menion"2. time when you lost GPS - I reorded a little values in list of possible values for dashboard. "Time" at begin is time of last fix, not current time. I don't expect, that current time will be needed as it's always in top system bar
Hm, one reason why I use dashboard is that the values offered by Locus in the top panel as well as in the top system bar are hardly to read when e.g. riding a bike as these values are printed pretty small and don't have too good contrast (top system bar). Therefore I like to use current time in the dashboard. For me the GPS fix time is a value I don't really need in a dashboard which should mainly show live data.
Have fun with reading and keep up the good work going!
Quote from: "menion"hello Tommi,
I have two things to discuss :)
SRTM data are good, but both knows that they're also not precise, mainly in hilly areas.
Few years ago i remember i tried Mountainbiking in the hilly forest using Altitude not from GPS or barometer but only from SRTM ( one of the option in TwoNav)but after few minutes i stoped this, it was no sense. Altitude from Gps was much better.
But maybe it will be good to have in Locus possibility to correct Altitude after finishing course.
I mean we finish a course, then save or export track and then correct Altitude using SRTM.
(It is possible for ex. in software like ''MyTourbook'' )
,,Momentary'' SRTM Altitude I don't know if it is a good Idea.
Quote from: "locuscycling"Quote from: "menion"hello Tommi,
I have two things to discuss :)
SRTM data are good, but both knows that they're also not precise, mainly in hilly areas.
Few years ago i remember i tried Mountainbiking in the hilly forest using Altitude not from GPS or barometer but only from SRTM ( one of the option in TwoNav)but after few minutes i stoped this, it was no sense. Altitude from Gps was much better.
But maybe it will be good to have in Locus possibility to correct Altitude after finishing course.
I mean we finish a course, then save or export track and then correct Altitude using SRTM.
(It is possible for ex. in software like ''MyTourbook'' )
,,Momentary'' SRTM Altitude I don't know if it is a good Idea.
Maybe I was got wrongly. In case of reasonably working pressure sensor I only want to use SRTM for initial calibration of the pressure sensor.
In other case (no usage of pressure) I'm interested in getting answers to the question which kind of optimizations/improvements are made.
Quote from: "tommi"I only want to use SRTM for initial calibration .
I agree (if i good understand).
You will start a course and want to have a possiility to set start altitude using SRTM ,,automatically'' ( not manualy -looking at maps ,touch a point to see altitude- and then adjust) ?
Quote from: "locuscycling"Quote from: "tommi"I only want to use SRTM for initial calibration .
I agree (if i good understand).
You will start a course and want to have a possiility to set start altitude using SRTM ,,automatically'' ( not manualy -looking at maps ,touch a point to see altitude- and then adjust) ?
Right, either use offline SRTM data or if not available but internet connection use online SRTM data.
Hi,
so discussion :)
firstly, I created this manual http://docs.locusmap.eu/doku.php/manual ... de_manager (http://docs.locusmap.eu/doku.php/manual:altitude_manager) , so hope most question will be answered there.
secondly, thanks tommi for valuable feedback. I improved a little texts below some items, to make more sense.
and finally, things to discuss. I understand usage of SRTM for calibration, but I need to think more about it. For me, it's an unwanted settings. I'm rather thinking about merging this directly into "Automatic" system. So Locus should use SRTM if available or GPS altitude if not available. I'll think about it ...
And time value to dashboard - added "Current time" item
Quote from: "menion"Hi,
so discussion :)
firstly, I created this manual http://docs.locusmap.eu/doku.php/manual ... de_manager (http://docs.locusmap.eu/doku.php/manual:altitude_manager) , so hope most question will be answered there.
Seems my silly questions have helped at least a bit to explain the stuff.
secondly, thanks tommi for valuable feedback. I improved a little texts below some items, to make more sense.
Seems my silly questions have helped at least a bit to explain the stuff.
Quote from: "menion"and finally, things to discuss. I understand usage of SRTM for calibration, but I need to think more about it. For me, it's an unwanted settings. I'm rather thinking about merging this directly into "Automatic" system. So Locus should use SRTM if available or GPS altitude if not available. I'll think about it ...
Automatism is also ok with me but needs again explanation in man page to avoid obtrusive users like me asking a lot of questins about it
Quote from: "menion"And time value to dashboard - added "Current time" item
Thank you!
Hi, my two cents:
I agree with tommi, I also would like to have a possibility to automatically calibrate altitude sensor using SRTM. It is one from reasons I still use ipBike for biking instead of Locus.
I think it would be more reasonable to leave the possibility for choosing the source of automatic calibration.
It would be also nice to have a possibility to autocalibrate using METAR data from nearest airport.When the airport is not too far away, this method is most accurate.
Aah, forgot few questions which might help to make the man page even better:
" Locus allow to define this offset by three methods
Manual correction - basic method, in case you know exact value of this offset and want to define it manually"
My understanding is that the exact altitude (e.g. 500m above N.N.) and not an altitude offset (-50m) shall be entered here.
"Automatic correction - method that may cover 99% of your needs. Locus can automatically compute this offset for whole world from model of Geoid. This method is precise enough for mobile device and allow not to worry about this offset in case, you travel between different locations. (offset change with your location)."
Not sure if I understand right. This sounds like if I record a track from A to B that the correction might change during the record of the track due to different Geoid altitude of A and B. On the other hand how does this work in case of pressure sensor!?
"Altitude NMEA correction"
Maybe better write: Method is deprecated because there are devices which report wrong values.
"Automatic - if you enable GPS, Locus will use current altitude and current pressure and use them as base values. All next measurements will be related to these values. During usage, Locus will periodically check measured values and in case of need, automatically recalibrate pressure sensor."
What does "during usage" mean? During track recording?
Specify periodically.
I made few little changes in the manual where I think things could be misunderstood. Hope you are ok with these.
tommi, thanks for help. Thanks for silly questions and also for changes in manual. Whole wiki is free to use and free to edit, so feel free :) to change everything you find useful. There is always way to revert changes back in case, something will be "bad".
I changed automatic calibration, so it now use SRTM data if they're available, otherwise use normal measured GPS altitude. I'm sure this will need some testing, to make sure it works correctly, so take next release versions as "Altitude testing version". There is always possibility to fill recorded track with offline altitude data (in case measured altitude will be completely wrong), so I'm not worry too much.
To some of your comments:
"This sounds like if I record a track from A to B that the correction might change during the record of the track due to different Geoid altitude of A and B." - that's correct in case you travel longer distance. Anyway changes aren't too big on bike ... check this map http://www.esri.com/news/arcuser/0703/g ... id3_lg.jpg (http://www.esri.com/news/arcuser/0703/graphics/geoid3_lg.jpg) where are visible changes all around the world. Values are from -100 to around +50 metres.
"What does "during usage" mean? During track recording?"
yes also during a long track recording. And don't worry, there should not be any huge change after calibration, but Locus should spread new calibration into next few minutes so there will be fluent movement of altitude from previous calibration value to new ... we'll see how this will work
@sherman: do you know any site that offer METAR data for the whole world? I'm not able to find any. Only some local
Quote from: "menion""What does "during usage" mean? During track recording?"
yes also during a long track recording. And don't worry, there should not be any huge change after calibration, but Locus should spread new calibration into next few minutes so there will be fluent movement of altitude from previous calibration value to new ... we'll see how this will work
Just for my understanding: Is this also done during track recording in case of SRTM available and pressure sensor?
Quote from: "menion"@sherman: do you know any site that offer METAR data for the whole world? I'm not able to find any. Only some local
I am using this site: http://www.aviador.es/Airports/Nearby/ (http://www.aviador.es/Airports/Nearby/)
But I believe there are some web services with API which should be easier to use with an android app, as on Google Play are several of them. I will do some research and will let you know.
thanks Sherman!
and tommi yes ... did you tried to record track with pressure sensor with just one calibration at start? If so then you have to noticed that altitude in the end is wrong for quite a huge value (in tens of metres). So there is need for some calibration even during a day
edit: to your info, Locus check calibration (and re-calibrate if needed) every 2 hours
Quote from: "menion"and tommi yes ... did you tried to record track with pressure sensor with just one calibration at start? If so then you have to noticed that altitude in the end is wrong for quite a huge value (in tens of metres). So there is need for some calibration even during a day
Due to weather related pressure change, I guess.
Quote from: "menion"edit: to your info, Locus check calibration (and re-calibrate if needed) every 2 hours
Ah, thank you. I added this info to the docu page.
Don't forget to link the page from http://docs.locusmap.eu/doku.php/manual ... gs:sensors (http://docs.locusmap.eu/doku.php/manual:settings:sensors) when you release the new Locus version! (But I think you intentionally didn't do it up to now because it' s not matching the current official Locus version.
hmm I again forget on link on manual, thanks. I'll add this into release version into top action bar in Altitude manager.
Hi,
here is a webservice for METAR data: http://www.aviationweather.gov/adds/dat ... amples.php (http://www.aviationweather.gov/adds/dataserver/metars/MetarExamples.php)
In the request you can specify for example most recent data from all airports within a given radius from a given coordinates:
http://www.aviationweather.gov/adds/dat ... ation=true (http://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=metars&requestType=retrieve&format=xml&radialDistance=100;14.455796,50.049169&hoursBeforeNow=3&mostRecentForEachStation=true)
I 'm surpriced of the new altitude manager. great work!
So i checked most of my tracks to re-calculate the altitudes. But i'm not sure... after re-calculation all the values are 0 (NULL).
:-(
Is this a bug or a feature?
All settings in altitude manager are on default.
Christian
it's a feature. I decided that best what I can do for you, is set all altitudes to 0. Only this will make Locus really useful :))
ehm, just kidding, please update to 2.11.1 version and sorry for a confusing
you are funny, man :-)
But... the reason why we - especially you - started the thread still exists: values of 0 for the flat. Means only values for uphill and downhill and these are wrong :-(
Any suggestions?
Anybody out there?
hi, sure. sorry ...
So back to topic.
First part is done I think. Maybe there is place for improvements, but core "Altitude manager" is published and I think, it brings benefit to all that wants "Improved altitude". So way to improve values itself, is done ... (agree?)
here comes second part. Some computations with values and statistics all wants to see :).
here is a nice example https://getsatisfaction.com/locus/topic ... _from_srtm (https://getsatisfaction.com/locus/topics/wrong_uphill_and_downhill_in_information_screen_after_filling_altitude_data_from_srtm)
so question si simple. How to compute it. I expect that there are no "exact variables" that's are used on all devices. So how to calibrate computations? On Garmin device?
Hi Menion,
Thanx for your answer. Sorry, this was my fault. I thought the computation problem ist already solved together with the Altitude Manager (nice piece!!!)
I'm not a mathematician but if i have values from the SRTM files and the track- what's the problem with the computation of uphill, downhill and flat ? Am i wrong?
Quote from: "Christian"I'm not a mathematician but if i have values from the SRTM files and the track- what's the problem with the computation of uphill, downhill and flat ? Am i wrong?
I'm not as well but I think the higher values for up and down come from much more noise in the graph, every little peak counts...
yes as tommi wrote ... "every little peak counts" .. that's a general problem.
I was thinking about it and I think that best should be to find some optimal value thanks to other programs. You for sure (christian mainly) have some GPX files and programs that show uphill/downhill values with which you're satisfied right? I have idea that if you give me let's say 5 different GPX files with tracks together with screenshots from various programs where will be visible values you want to see also in Locus, I'll try to find a optimal parameters to achieve it, what you say? ;)
As far as I can see, other devices have the same problem. In the German Naviboard you can read this :
http://www.naviboard.de/vb/showthread.php?t=51647 (http://www.naviboard.de/vb/showthread.php?t=51647) about the Garmin 62s. The result: They are not very happy with it in addition of the altitude.
that's what I think, that there is no general method with specified parameters. But as I wrote ... give me at least five various tracks with some results you want to see and I'll gladly spend time on this and improve Locus to match some middle ...
Hi guys,
sorry for any delay. I was offline and mountainbiking for 2 weeks :-)
I would like to separate the problem:
1: get correct(ed) elevation data during recording
2: computation of uphill / downhill / flat section of a recorded / downloaded track and got elevation values from STRM files
for 1 i have no idea.
for 2 i think its the best to use a simple methode like this:
ele point A + ele point B - ele point C(if C is smaller than B)
I guess with SRTM files we have all we need....
@menion: is it too simple?
I would like to avoid using philosophy of other devices in Locus.
Christian
hmm wait,
I thought that step 1. is already done. For this exist Altitude manager where you have various methods how to "improve" measured altitude. If you enable "Optimize GPS altitude" in Altitude manager, then Locus will use SRTM files to correct a little measured altitude. So I think point 1 is done, isn't it?
Point 2 is what I want to discuss now. You wrote "avoid using philosophy of other devices in Locus", but I don't want to use system of any other device. Whole this discussion started by "Hey menion, this recorded track has in locus elevation 900m, but in garmin it has only 600m" right? And what I want, is to have 5 - 10 GPX tracks where for every track I'll have values you would like to see in Locus.
So for example
- these 3 tracks from BaseCamp display these values ....
- these 3 tracks from GPSies display ...
- these 3 tracks ...
so in the end, I should optimize Locus to compute elevation that will fit to these values (values you expect) as much as possible. I should do it by myself, but all my recorded tracks has elevation +- 100, because it's really flat around Prague and also I'm still sitting on but at home :)
So if you may send me few high-hill tracks also with values you see in your favorite program (except Locus ;) ), I'll gladly do improvements. And if you do it today, I can include this into next, probably tomorrow release (I planned to release it already in Thursday, but rather late without bugs, then ...)
Ahhh, i'm not in time and not up to date :-(
Sorry for that.
I tried new Altitude Manager only the settings. No recordings has been done so far...
And you are right, i started comparison with Garmin stuff .-)
Its difficult to have different track recordings from one unique route / way. I will try to find some.
so tracks not needed ... we spend half a day together with Peter on some testing and now seems that results are quite usable ... you'll see in next version. Expect anyway that track statistics are stored in database and need to be refreshed. So all new track will have these improved values. Old tracks need some reason to refresh also in database, like "Fill altitude", update/delete of any point etc ...
so gentlemans ... viewtopic.php?f=25&t=3112&p=20936#p20936 (http://forum.locusmap.eu/viewtopic.php?f=25&t=3112&p=20936#p20936)
i'm looking forward to the next version.
fine, version is out. I just suggest to "fill altitude" for already stored tracks, to refresh statistics values
Thanx for the new version. I tried this but the distances in flat area are still too less (like before)
:-(
Christian
Christian we took with Peter four tracks and tested them in five different applications. Values that locus compute are now somewhere in the middle of them. Anyway as I wrote, it's need to refresh tracks to display new values. So for example remove last point or fill altitude of track etc. This will refresh also a store statistics. And if you'll still not be satisfied, I really need one track to test and also values you expect! So I can do some more research ...
Menion,
in past I used heavy altitude filtering, other settings just interpreted simple noise of pressure sensor as change of altitude.
Which setting do you recommend now after optimization for use with pressure sensor?
hmm hard to say :) it needs some field testing ...
anyway heavy filtering should not be needed too much as before. Suggest to try "Optimize GPS altitude" by hgt files. this should improve altitude noise a lot. Pressure sensor itself should work now much better so it's a question if "Altitude filter" is needed at all
Quote from: "menion"hmm hard to say :) it needs some field testing ...
anyway heavy filtering should not be needed too much as before. Suggest to try "Optimize GPS altitude" by hgt files. this should improve altitude noise a lot. Pressure sensor itself should work now much better so it's a question if "Altitude filter" is needed at all
Thanks, I tried without "Optimize GPS altitude" and "Light filter" (I didn't find time to check all settings before starting the track recording). I think in general the generated altitude curve is quite smooth.
But: When GPS is switched on and gets a lock it doesn't use pressure sensor value resp. info from .hgt file from beginning. For several seconds it uses the quite bad value from GPS (in my case (or for everyone?) about 50m too high) and after a while it decides to use the value calculated from pressure sensor/.hgt file.
This creates ugly glitches in the track:
- at the beginning
- when recording was suspended/resumed (by pause button) and GPS was switched off (automatically because no function needed it and screen was off).
See the track witch a glitch at start:
https://www.dropbox.com/sc/ba0gn964psqkhtd/gJ5S3zD3KX (https://www.dropbox.com/sc/ba0gn964psqkhtd/gJ5S3zD3KX)
See a video which shows the described behaviour of altitude measurement/calculation in the GPS screen:
https://www.dropbox.com/s/pae5507dkglya ... -19-15.mp4 (https://www.dropbox.com/s/pae5507dkglyahm/sc_2013-07-09_01-19-15.mp4)
Some month ago (I think it was in March) this bad behaviour didn't occur, the value from pressure sensor/.hgt was taken immediately.
Please fix.
ah it's problem that jusc (if I remember correctly) reported few days ago ...
I'm going to fix it ...
EDIT: ah yes here viewtopic.php?f=10&t=3207 (http://forum.locusmap.eu/viewtopic.php?f=10&t=3207) ... hmm I was recording tracks twice last week and both looks fine even from start, but point is as you mention. To have enabled track recording even before GPS gets fix, so all points are stored, even a first one
Quote from: "menion"ah it's problem that jusc (if I remember correctly) reported few days ago ...
I'm going to fix it ...
EDIT: ah yes here viewtopic.php?f=10&t=3207 (http://forum.locusmap.eu/viewtopic.php?f=10&t=3207) ... hmm I was recording tracks twice last week and both looks fine even from start, but point is as you mention. To have enabled track recording even before GPS gets fix, so all points are stored, even a first one
Hm, maybe there was already a (partial?) fix in the latest testverson on dropbox but I used Locus Pro.
nono I completely forget on this topic, so in current or previous test versions are same problems also
Hi Menion,
this problem doesn't seems to be fixed:
viewtopic.php?f=26&t=2916&hilit=pressure&start=60#p22008 (http://forum.locusmap.eu/viewtopic.php?f=26&t=2916&hilit=pressure&start=60#p22008)
I had the same problem today with 2.14.0.
yes I know, I wasn't able to find simple solution yet, even I spend already few hours on it. To avoid this, best is to enable GPS in locus before you start track record. This few seconds save these problems.
Only solution I have in mind is in this case, wait a few (+- 5) seconds till recording really start. But it's not best, because you expect to record just from time, you tap the button ...
Quote from: "menion"yes I know, I wasn't able to find simple solution yet, even I spend already few hours on it. To avoid this, best is to enable GPS in locus before you start track record. This few seconds save these problems.
Only solution I have in mind is in this case, wait a few (+- 5) seconds till recording really start. But it's not best, because you expect to record just from time, you tap the button ...
Yep, of course I'd like to see it records correctly from button press on. I could live with the problem at the start but the problem also occurs if you paused recording and GPS is disabled during the pause.
Interesting is that this problem did not occur until spring this year.
you know, improved more specific algorithm brings this mess ... anyway I probably found a problem and a small solution.
Seems that problem occur only if you have enabled "Automatic calibration" right? If so, then it should be fixed in next version. Also be sure you have HGT files for area where you record your tracks, because these files also here helps a lot with calibration (they're used instead of GPS altitude if available)
Quote from: "menion"you know, improved more specific algorithm brings this mess ... anyway I probably found a problem and a small solution.
Seems that problem occur only if you have enabled "Automatic calibration" right? If so, then it should be fixed in next version. Also be sure you have HGT files for area where you record your tracks, because these files also here helps a lot with calibration (they're used instead of GPS altitude if available)
Yes, I use automatic calibration of pressure sensor as I'm one of the lucky guys who has a working pressure sensor in the phone. Automatic calibration is a great feature because all the nasty handling with calibration needs not to be done by the user but is done by Locus. And of course, I have hgt files available for the area.
Thanks, and I will test with next version (already in the next version I'll likely get for the problem with dashboard?)
I was already working on dashboard, but it's story to another topic. I don't want to send you a new version with just one fixed problem, so I'll fix them more then publish a version ;)
Ok, I see the behaviour of automatic calibration and first recorded point(s?) has changed. Instead of +50m wrong altitude it's now about -25m wrong.
But the glitch after pausing the recording seems to be fixed.
Are these the expected results (maybe my settings are a bit different after having setup my phone newly? (the fixed problem after pause is definitely an improvement).
Thanks,
Tommi
good to hear. I'm not sure I'll have time to go out to test it till release so thanks a lot for your help
Is there a way to show the dynamic elevation or altitude calculated in real time?
I don't want to only be recorded, but I also want it to see it in real time when I need it.
Ideally, it doesn't have to be the downloaded extraction (http://docs.locusmap.eu/doku.php?id=manual:user_guide:maps_settings), but the real calculated one from GPS data and barometer.
It would be nice to have it added in conjunction with the GPS data on the top of the screen, not in the screen centre.
Have a look into =dashboard]dashboards (http://docs.locusmap.eu/doku.php?id=manual:user_guide:tools:dashboards&s[). It may be what you are wanting.
Thanks Andrew! It's adaptable to what I need.