Altitute filter spezification

Menion ●

Ah these filters. This option is applied as a final step in "Altitude optimization". It simply uses easy filter defined as

current alt. value * filter + prev alt. value * (1 - filter)

So it really only little bit optimize altitude values, nothing more.

Ah these filters. This option is applied as a final step in "Altitude optimization". It simply uses easy filter defined as

current alt. value * filter + prev alt. value * (1 - filter)

So it really only little bit optimize altitude values, nothing more.

1

Menion ●

Good day Falco,

it is a really complex question and best how to answer, should be to publish few hundreds (maybe thousands) of source code lines so everybody will analyze them by yourself.

Most simple and clear: all parameters set in Altitude manager (offset, filter, etc) are applied immediately when Locus Map receive GPS location. Do this later is not possible. So all services in app already use a location object, that has modified elevation value. For example, recorded track data are have modified elevation values.

About logic, thresholds and other parameters: anything special you are interested in?

Menion

URL

1

Falco ●

Thank you, I did expect this early applyment.

2 of 4 parts are clear now. 2 are missing:

Does the filter profile care about the altitute source, or do you need to select low for good sources and high for bad sources? For example a filter for GPS could be smart based on accuracy values.
Filter logic and threadholds: I would like to know how many old points are used as reference for the adjust of the next point because for pressure you need less points to lookup because you don't have errors you have just noise and for gps you need to lookup many point to detect messurement errors. Well, actually I don't want to know this. I want to know which profile is the best for maybe 0.3m pressure noise and which one for 0.5m pressure noise. And even more importand I would like to know the resolution across multible points. If the logic is not optimized for pressure values, I would maybe disable it an play arround with external altitute leveling. But at the end it would be great to know which conzept is used for altitute leveling. For example your approuch is very limited because you can't lookup the value of the next points because you have only access to the previous points. I would guess that somebody did thought about how pressure values can be leveled to remove the noise without destroying the resolution. Because there are so many different ways to handle it, it would be nice to know if the conzept does follow a specific research study or if anything else was the base for it.

URL

2

Menion ●

Good day Falco,

- the filter does now use accuracy values to optimize filter strength. All received altitude values have the same weight.

- a pressure sensor system in the app computes an average value from last 10 measurements (max. age 15 seconds). This value is then used for computing of current device altitude value. App use elevation data from HGT files and every hour makes a correction based on these offline elevation files (if available).

Precision? Well, to be true, if you are looking for most accurate elevation values, do not use Locus Map for this purpose. I believe in Google Play have to be apps that use a lot more precise algorithms to compute altitude values thanks to the pressure sensor.

Jiří M. aka Menion

URL

1

Falco ●

Thank you,

Is the metric 10 measurements (max. age 15 seconds) equal for all selectable filter options? Because track recording screen looks alot more responsive then 10s average. I can easily find a 0.6m lift of my phone in the recording monitor without waiting to long in the end postion. Or maybe it just feels a lot more snappy then it acually is because of the smooth transition.

I tought about a pressure data filter for MTB:

I need maybe 5-10s, horizontal resolution and 2 meter vertical resolution, Horizontal resolution would exacly match to a 10s average. Maybe 5s average to get near 3s resolution for smallest hills with only 5 meter altitude difference. But need 2 meter filtering to remove bumps, sensor noise and vertical rider movement.

Vertical resolution could be a little bit difficould because it's needed to prevent edgecases where the value does swap arround 2 numbers. It should be already covered by the average of the last 10 measurements but I don't have anoght data to tell if bumps have an impact on each individual average calulculation results.

Other apps? I am not sure. My first thought was don't use locus for altitute monitoring because it will need GPS for track recording.

I did only found 6 apps which can work without gps and pressure sensore and non of them could be record more often then 30s

Sure there are many for realtime display of current, value but non of them do record as fast as the display changes.

URL

1

Menion ●

There is usually around 3 - 4 pressure measurements per second so I'm sure, that changes in altitude based on pressure will be quick enough.

Anyway filtering based on activity, to correctly filter some disturbances caused for example by bike-ride is an interesting idea. Anyway, such algorithm needs more clever mind than mine :).

If you wanna play with raw pressure data, you may try my small utility feature:

open main menu and long-click on "settings" icon at the bottom
after you see "experimental mode enabled", open settings > miscellaneous > experimental (at the bottom) > record sensor data

Since that moment, Locus will log GPS and pressure data into Locus/data/sensors directory. Lines with "loc" at the start is a GPS location and line with "si_pr" is a pressure sensor data. Not sure if you will find any use for it, but maybe you want these information for some own post-processing? So you may play with them. Otherwise forget I wrote it.

URL

1

Falco ●

No way, that is great! That does solve so many things.

Now I can play arround with realtime recording filter without loosing reference data. I could even apply local weather pressuremaps in post. I did nearly start to develop my own sensor recording app.

Does it store sensor data even if GPS fix is missing?

Why did you mention 3-4 times per second? Did the filter analyse 3-4 points per second (which means only last 3 seconds) or does it analyse only points which got eligible for gpx track storage based on record distance/time setting (last 10s to 15s based on how many GPS points got into the record)?

URL

1

Menion ●

Hello Falco,

I used it quite a long time ago for own test of filters, so hopefully it will still work.

It records raw received data immediately, app gets it. So data in text files are unfiltered, unaffected by any Locus filter etc. And yes, pressure values should be recorded even if GPS is not active. If you will have a while, test it and let me know. In case of any problem, rather write me here and I'll look on it, just don't waste time on it :).

And "3-4 times per second" is usual frequency, how often Locus Map receive pressure data on devices. You will probably see this in the text file. So I just wanted to mention that changes in altitude even with this averaging, should be quite fast.

Jiří M. aka Menion

URL

1

Falco ●

That means altitute filter got applied before track recording filter and if you have pressure sensor it takes even more values then available GPS fixes. That does explain why we got such a high time resolution.

What does the selectable filter options change?

- only vertical resolution

- only time resolution

- vertical resolution and time resolution

URL

1

Menion ●

Yes sure, application filter all received data, so usually every second new location and 4x per second new pressure data. As I wrote before, these filtered values are then forwarded to various services like track recording, live tracking etc. So if track recording record data once per 10 seconds, it does not mean, that all these filters are applied only once per 10 sec.

And by "filter options" you mean parameters defined in track recording profile?

URL

1

Falco ●

I mean altitude filter options form low to high.

URL

1

Menion ●

Ah these filters. This option is applied as a final step in "Altitude optimization". It simply uses easy filter defined as

current alt. value * filter + prev alt. value * (1 - filter)

So it really only little bit optimize altitude values, nothing more.

Ah these filters. This option is applied as a final step in "Altitude optimization". It simply uses easy filter defined as

current alt. value * filter + prev alt. value * (1 - filter)

So it really only little bit optimize altitude values, nothing more.

URL

1

Rogemar ●

Hi Menion,

I just read one of your response here:

"App use elevation data from HGT files and every hour makes a correction based on these offline elevation files (if available).

Precision? Well, to be true, if you are looking for most accurate elevation values, do not use Locus Map for this purpose"

Is the automatic correction already applied in the offline map when the elevation data has been downloaded? The automatic correction is based on Geoid model which is safe to say more accurate compared to the ellipsoid model.

URL

1

Menion ●

Hi,

what exactly you mean by this "Is the automatic correction already applied in the offline map when the elevation data has been downloaded"?

Altitude manager > Offset > Automatic correction is applied on received GPS data. GPS altitude is based on Ellipsoid model, so results are not values you usually see in paper maps or in the woods on labels. This automatic correction should be good enough for a common hike & bike usage.

URL

1

Rogemar ●

Hi Menion,

Thank you for your immediate response.

What I meant is if the elevation shown in the offline topographic map already corrected based on Geoid model? Please see attached screenshots.

When is the automatic correction of elevation/altitude being applied?

Also, I've already uploaded the track in GPSIES and performed an altitude recalculation which results to the same altitude. I presume it is already Geoid model altitude.

Files:

URL

1

Menion ●

Yes they are. Values used for map shading or Dynamic elevation (as on your screenshot) are already in correct "Geoid height". So really only received GPS location are corrected by this offset. Expect that dynamic elevation on peaks may not be exactly correct (usually little lower then real values).

URL

1

Rogemar ●

Thanks Menion for the confirmation, Geoid values is better since ellipsoid seems overstated.

URL

1

Guest ●

Hello Locus-team,

this an interesting thread, cause even if I'm an interested user of the altitude-possibilties Locus offers (recording a track, importing GPX-track files, ...) I'm not fully aware with each detail how Locus works regarding these points. And this knowledge would be important - not only for myself but also to help other Locus users with their questions regarding themes like "elevation gain", elevation sources, Altitude filtering...

So I want to ask you some questions:

If using "Replace GPS values" within altitude mananger: Does the values within field "Altitude filter" (no filtration,... Ultra heavy filter) influence the final statistic values "Elevation gain", "Elevation loss" in a tracks statistics? In other words, will I get different results dependend on what strength of filter I'm applying?
Or is this this kind of filter just aplied on GPS-based elevation sources?

You write above: "all parameters set in Altitude manager (offset, filter, etc) are applied immediately when Locus Map receive GPS location. Do this later is not possible. So all services in app already use a location object, that has modified elevation value. For example, recorded track data are have modified elevation values."

So if I understand correct, the single elevation trackpoints of an exported GPX-file already are filtered regarding the setting within field "Altitude filter". So in theory if I analyze this GPX-track with a external software just summing up each elevation value, I should get the same result like Locus calculated for Track statistic "Elevation gain". But this isn't true. It seems to be that Locus uses a second filter on these already filtered GPS-values to calculate its track-statistics, cause they are lower than determined with the external software.

If I'm importing GPX-tracks of 3rd party sources whos trackpoints already include elevation data: Is locus executing some kind of filter to calculate "elevation gain"? Or will Locus just sum up each elevation value.

Same example as before, but now I'm applying SRTM-elevations by help of locus: More > "Update elevation". Is this SRTM-filled track filtered somehow afterwards to calculate "elavation gain" or just summing up each values?
In my observation Locus DON'T just sum up each value but uses an internal non-adjustable filter to just use elevation values which are different by about 2m to the former local minimum/maximum of a track.

Lately I helped a guy https://help.locusmap.eu/topic/altitude to analyse his tracks and to give suggestion on how to record tracks. The Statistics-tab of this track (elevation values by SRTM-files) says: "Max.altitude"=2220 m but if i move cursor over this trackpoint on the map the dynamic elevations (based on the same SRTM-files) says "2232m" => 12m difference - why?

Hello Locus-team,

this an interesting thread, cause even if I'm an interested user of the altitude-possibilties Locus offers (recording a track, importing GPX-track files, ...) I'm not fully aware with each detail how Locus works regarding these points. And this knowledge would be important - not only for myself but also to help other Locus users with their questions regarding themes like "elevation gain", elevation sources, Altitude filtering...

So I want to ask you some questions:

If using "Replace GPS values" within altitude mananger: Does the values within field "Altitude filter" (no filtration,... Ultra heavy filter) influence the final statistic values "Elevation gain", "Elevation loss" in a tracks statistics? In other words, will I get different results dependend on what strength of filter I'm applying?
Or is this this kind of filter just aplied on GPS-based elevation sources?

You write above: "all parameters set in Altitude manager (offset, filter, etc) are applied immediately when Locus Map receive GPS location. Do this later is not possible. So all services in app already use a location object, that has modified elevation value. For example, recorded track data are have modified elevation values."

So if I understand correct, the single elevation trackpoints of an exported GPX-file already are filtered regarding the setting within field "Altitude filter". So in theory if I analyze this GPX-track with a external software just summing up each elevation value, I should get the same result like Locus calculated for Track statistic "Elevation gain". But this isn't true. It seems to be that Locus uses a second filter on these already filtered GPS-values to calculate its track-statistics, cause they are lower than determined with the external software.

If I'm importing GPX-tracks of 3rd party sources whos trackpoints already include elevation data: Is locus executing some kind of filter to calculate "elevation gain"? Or will Locus just sum up each elevation value.

Same example as before, but now I'm applying SRTM-elevations by help of locus: More > "Update elevation". Is this SRTM-filled track filtered somehow afterwards to calculate "elavation gain" or just summing up each values?
In my observation Locus DON'T just sum up each value but uses an internal non-adjustable filter to just use elevation values which are different by about 2m to the former local minimum/maximum of a track.

Lately I helped a guy https://help.locusmap.eu/topic/altitude to analyse his tracks and to give suggestion on how to record tracks. The Statistics-tab of this track (elevation values by SRTM-files) says: "Max.altitude"=2220 m but if i move cursor over this trackpoint on the map the dynamic elevations (based on the same SRTM-files) says "2232m" => 12m difference - why?

URL

Altitute filter spezification

Replies (7)