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

Pages: [1] 2
Versions / Re: [APP] - version 3.22.+ ( 7. 3. 2017 )
« on: March 10, 2017, 09:06:32 »
@twil69 - the notification button is not permanent - I'd complain too if that were the case. Easy to dismiss any new items and button will hide. Don't stress too much.

Well, technically you may be right.
But lor74cas described quite nicely what will happen most of the time: this thing will disturb you when you have no time to deal with it and just want it to go away. And when you do have time you will not remember.

So it is more about the perception as something useful or something annoying. And since there are established notification alternatives (that most apps seem to agree upon) I dont see why Locus needs something different.

I always prefer pull mode (deal with things when I have time for them) instead of push mode (being interrupted).
The status of a download is visible in the Android status bar and when I want to read the Locus blog I go to feedly. Everything is already there. I personally dont need more. But let the user community decide.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.22.+ ( 7. 3. 2017 )
« on: March 09, 2017, 10:17:35 »
All settings in apps has it's unique key and value values. These has nothing to with texts that user see on screen. These texts are generated on the fly in moment, they are needed. And they are needed in moment, any screen from settings is visible. So this whole system needs to write somewhere list of all preferences that may appear on screen, get all possible texts for them and then iterate over these texts and test them. I have partially useful solution thanks to new presets system, but there is still a lot work to do, because almost all settings has to be changed to new system (while currently only around 10% was rewrote).
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.22.+ ( 7. 3. 2017 )
« on: March 09, 2017, 08:46:56 »
You eventually added Profiles/Presets!  ;D
Garmin has this in the Oregons since almost a decade and I was always hoping that this would be offered for Locus as well. Given the overwhelming plethora of settings this is only a logical step. How often did I find myself roaming the settings tree to find a particular knob. Worse, the settings tend to move every now and then, so you need to memorize where they currently are. Since I use locus for geocaching, bike riding, running and hiking each time I changed the activity I needed to tweak the settings. Now consider you are e.g. on a geocaching tour by bike.... :-\
Definitely will give (custom) presets a go.

What I dislike is the notification center. I bought Pro to get rid of ads and now it sneaks back in by the app itself. Other apps also manage to notify you without cluttering the main application. I am fine with the Android notification bar, I dont want to waste precious real estate of my screen with a permament button. Please make this an opt-in instead of an opt-out.
The following users thanked this post: michaelbechtold

Hallo, ich versuche es so "kurz"  ;) und verständlich wie möglich zu erklären:

Für jene Gebiete wo es bereits meine LIDAR-DTMs gibt, z.b. für Österreich , lädst du dir jeweils die 1"-DTM runter. Hier findest du übrigens auch einen Link zum Kartenvergleich meiner LIDAR-Daten zu denen der SRTM-Kacheln:

Das 1" ist das genaueste DTM, es gäbe auch noch die 3" die aber ungenauer sind. Mit den 20m und 50m-DTMs kann Locus sowieso nicht umgehen.

Du entpackst alle Dateien und schiebst die .hgt Dateien rüber in den data/srtm-Ordner von Locus. Dort liegen ev. schon Dateien mit dem gleichen Kachelnamen drin, die überschreibst du einfach, denn dabei handelt es sich vermutlich um die "alten" wesentlich ungenaueren SRTM-Höhendaten.

Sodala, da war's schon. Ab nun nimmt Locus zur dynamischen Anzeige der Höhe deiner aktuellen Position ("Dynamic Elevation", zur Berechung von Höhenunterschieden eines Tracks, zum Erzeugung der Kartenschattierungen ("Map shading") dieso genauen Höhenkacheln her.

Diese Höhendaten sind so gut wie immer genauer und zuverlässiger als die Höhenbestimmung per GPS oder auch per Barometer (dieser folgt zwar Höhenänderungen sehr genau, muss aber manchmal nachkalibriert werden, da sich der örtliche Luftdruck ändern kann).
In den Locus-Einstellungen (Menü > Settings > GPS > Altitude manager > "SRTM DATA" kannst du einstellen:
"Optimimize GPS values" (gerade in Zusammenspiel mit einem Barometer sicher eine interessante Sache) oder gleich "Replace GPS values", dann werden ausschließlich diese Höhenkacheln zu Höhenberechnung herangezogen.

Etwas anderes ist die Lage für Länder, wo es solche LIDAR-basierten DTMs noch nicht gibt, sonder nur die SRTM-Kacheln. Diese können zuverlässiger sein als GPS-Höhenempfang, aber auch ungenauer sein, da die SRTM-Kacheln stellenweise Abweichungen von 50m,100m oder mehr haben können, z.B. im alpinen Gelände, in Schluchten etc.
Speziell in gebirgenen Regionen und/oder dicht bewaldeten Flächen würde ich hier zuerst auf barometrische Höhenmessung zurückgreifen falls im Gerät vorhanden.

Zu deinen Zusatzfragen:

- Es kann immer nur eine gleichbenannte Kachel geben und diese erwartet Locus im data/srtm ordner.
Dabei sollte es sich hier immer um die genauest möglichen Kacheln eines Landes handeln (1"-Lidar besser als 3"-Lidar besser als 1"-SRTM besser als 3"-SRTM)
- Wenn du einen Track z.B. für eine Navigation im Vorhinein erzeugst, dann basiert das Höhendiagramm definitiv auf den Höhenkacheln.
Wie dies aber bei der Aufzeichnung eines Tracks ist während du unterwegs bist, weiß ich nicht. Entweder es werden auch hier standardmäßig nur die Höhenkacheln genommen oder aber jene Höhe die Locus live ermittelt anhand der obigen einstelllungen bei (Menü > Settings > GPS > Altitude manager > SRTM).

Müsstest du menion dazu fragen, oder jemand anders der das weiß.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: February 20, 2017, 01:03:47 »
Vector maps have themes which have different style options, selected either by drop down menus or check boxes.
ahh yes, excellent suggestion to add these settings to (advanced) presets
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: February 19, 2017, 11:09:03 »
For presets, can we have styles as well as themes, please.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: February 13, 2017, 21:00:58 »
My personal opinion is anyway still the same ... I think that "Presets" are too powerful tool to stay with current limited number of preferences without option to turn some of then off completely. Petr kill me for this :), anyway I would like to introduce some "advanced mode" that allows to add more preferences (like panels) and also option to remove some preferences from preset at all (maybe simple "toggle button > advanced mode" below name/icons in presets parameters).
100% agree! Advanced mode sounds great and still gives a simple version for not-power-users!

Anyway as first public version, I think current solution is fine. Votes in ideas on help desk may show me, what (advanced) users wants.
Ok, first public version with simple presets is ok, if advanced mode is implemented afterwards! What do you mean by "votes on help desk"? Is there more than one idea regarding presets, that I could vote for?
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: January 31, 2017, 10:07:58 »
ok, forget on presets, seems that concept is wrong, and I need to find out some different method how to do it.
Mainly because there is nothing like "active preset", so there is nothing to deactivate ...  :'(
@menion - probably just "lost in language translation" but I think the concept is excellent. Given the constructive debate it's clear core forum users as passionate about the feature, and implementation. But the way it stands, I think an average user would be somewhat confused on operation, and decide to avoid use, or require lots of documentation to understand, or lots of ongoing support questions. Don't give up on the presets concept.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: January 28, 2017, 10:59:39 »
That change would need a three-position switch (on | off | no change) for each setting which is what the present arrangement achieves.
yes, I suggested this a few days earlier. The present arrangement is a 2-step process - 1) select settings, 2) decide on overriden value. Instead there could be a single list. For boolean settings there could be a 3-way button, but for more complex settings this wouldn't work. A checkbox to override the setting and the actual setting control may be simpler to explain/ more intuitive for users than the current process.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: January 27, 2017, 11:55:24 »
Nice to have map themes now included.
For me, it would be nicer to have map styles as well as themes included.
Because each preset can have own independent set of settings I imagine could cause user confusion. Seems user will generally need to have settings identical in each preset (for example I am testing with 3 presets Cycling/ Driving/ Default). There is not going to be large number of settings to choose from so could the initial choosing of set of settings be removed - each preset just has all possible settings? User simply decides on the value of each setting.
That change would need a three-position switch (on | off | no change) for each setting which is what the present arrangement achieves.
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: January 26, 2017, 14:35:08 »
My feedback regarding the presets-feature:

I'm ok with the way it's implemented now. This way the settings currently in use are consistent with what the main settings menu shows (at this time). You (the user) just have to keep in mind that some settings can be changed from what you set up in the main settings when a preset is "executed".

I must admit, I first was confused about how to set up a preset, even to the point I thought it didn't work on my phone (or maybe it actually wasn't in the first version?). It took me a while to realise that it's a two-step process of first selecting which settings should be available in the preset, and then the actual setting. But I think this is only a matter of headline/description/help texts...

So I'm looking forward to also having themes, dashboard activation, permanent display on and display activation settings available. Also, preset execution when starting track record with a specific recording profile would be nice!
The following users thanked this post: michaelbechtold

Versions / Re: [APP] - version 3.21.x (21. 12. 2016+)
« on: January 24, 2017, 23:51:33 »
For me these "presets" are really setting "overrides". It seems to more accurately describe the new feature. Would you consider renaming presets to overrides?

Currently there doesn't appear to be a way to disable a selected preset. Could there be a checkbox at the top of the main dialog?

It seems for each available boolean setting there are 3 possibilities: don't override, force true, force false. Similar for more complex settings. Maybe if the overridden value is same as default value it is displayed in normal font, and if  overridden value is different to default value it is displayed in stronger font?

At present there are two steps to creating a new preset - 1) select list of settings from list 2) decide on overridden value (which may be same as default value anyway). To make it more obvious to user what "is going on here" could there be just a single dialog/ list. I think Wolfgang commented this was confusing too? For each setting there is an "override" checkbox, and if override=true then value control is enabled, and can be modified, and will be in strong font if different to default value.

If list is ever opened subsequent time for further editing, the overridden values are sorted to/ displayed at top of list to save user scrolling through whole long list.

Maybe in the "top level" selection list of presets below each icon, there can be a list of overridden abbreviated or acronym setting names in small font for quick glance. I imagine for each preset there will only be short list of settings that user would override. A long list would suggest user has misunderstood the purpose of presets.

Just my 2 cents of thoughts after some further usage and reading other forum comments.
The following users thanked this post: michaelbechtold

Die .rd5-Dateien sind kein darstellbares Locus-Kartenmaterial, sie dienen ausschließlich zur Berechnung des Weges bei der Routenplanung und Navigation. Wählst Du bei der Locus-Navigation/Routenplanung BRouter als Routingservice, übernimmt BRouter die Routenberechnung und greift dabei auf die .rd5-Dateien zu.
The following users thanked this post: michaelbechtold

Troubles & Questions / Re: Elevation gain
« on: November 21, 2016, 12:43:28 »
For global info:

I do not have a pressure sensor so when I found that altitude data of the recorded track with just gps are crazy I tried to solve.

First you need a good accuracy of recorded track points:
settings -> track rec -> choose your profile settings --> requested accuracy set a strict value (for me 30mt)

Second you can have better SRTM values using HGT files with 1" arc insted of 3"

and if you want a costant application of srtm data and bypass the "fill data.." after track recorded use this:
in settings -> gps and position -> altitude manager -> settings -> srtm data -> replace gps values

The following users thanked this post: michaelbechtold

Troubles & Questions / Re: Uploaded GC logs have a false date
« on: November 21, 2016, 12:30:52 »
Except really rare cases (except some tasks around downloading of maps), Locus always used device time ...
The following users thanked this post: michaelbechtold

Pages: [1] 2