Main Menu
Menu

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.

Show posts Menu

Messages - alang

#1
Troubles & Questions / Re: hours for angles
June 29, 2026, 13:32:23
The two conversion references given refer to "Hour Angle". This is a value used in astronomical positioning/navigation which is definitely not suitable for e.g hiking, cycling etc:
See:  https://en.wikipedia.org/wiki/Hour_angle

Menion used instead the "Clock Position/Bearing" which is completely different and is simple, widely known (but not in France apparently ?), and very suitable for hiking etc.  It uses a 12 hour clock. I've been familiar with it since I was a child as I guess most will be in at least English speaking countries, though younger generations might not be as familiar with it perhaps.
See: https://en.wikipedia.org/wiki/Clock_position

It was (maybe still is) famously used by pilots in WW2, as in "Bandits at 6 O'Clock" for enemy fighters at the rear, also in the Oscar winning film "Twelve O'Clock High"
In a vehice the direction is relative to the heading - i.e. the long axis of the vehicle body - in an aircraft or boat this is probably not the direction of motion because of cross-winds or currents.

Not sure of the context it was being used in, in the example, but for e.g. hiking the only thing to be careful about is to be clear what it is relative to.  For example:

The two things I most often want to know when hiking, without having to refer to my map/phone are: 
"What direction should I be heading to follow the planned route"
"How far am I from the route"

I use a custom announcement system which speaks, on-demand, something like:
"Current direction: West North West. Distance to track: 5 m. Follow track on bearing, East North East, at 4 o clock. After 372 meters, Bear left. Next waypoint, after 4.9 kilometers, is xxxxxx"

Or if off course by greater than a limit:
Warning. Distance to track: 113 meters. Current direction: West. Follow track on bearing, West North West, at 1 o clock.

The clock directions here, however, are relative to direction of motion as that is better defined than the direction the phone happens to be pointing in - if it's in my pocket that would be random.
#2
Maps / Re: Online LoMaps V2
June 25, 2026, 16:26:33
Vector map : The road number captions are not properly displayed in the vector map - there is a blue information box icon obscuring the road number.
There is an error message in the console which looks like it is related to that.  For example:
'Image "shields\motorway_4x1" could not be loaded. Please make sure you have added the image with map.addImage() or a "sprite" property in your style. You can provide missing images by listening for the "styleimagemissing" map event.'
They are OK in the raster map.

(Minor issue) In both raster and vector maps at zoom levels 7 and 8 many of the captions overlay themselves making them garbled.
For example
at https://web.locusmap.app/en/plan?lat=52.1823412&lng=16.0521070&z=7&map=hikeBikeVector  "North European Plain" snakes across the map and repeats itself but these repeats interfere with each other.
at https://web.locusmap.app/en/plan?lat=52.7401762&lng=-1.0284136&z=8&map=hikeBikeVector  "British Isles" is garbled.  At zoom 7 it just says "Isles".
I don't know if the V1 map did the same.
#3
(Übersetzt aus dem Englischen)
Hallo,
ich habe einige Tests durchgeführt: Bei Verwendung eines festen Längengrades:
Für LM Classic 3.66.2 stimmen <wpt> und <trkpt> überein, wenn sich die Breitengrade um weniger als etwa 0,000009 unterscheiden, was ungefähr 1 Meter entspricht.

Für LM Classic 3.70.17 und LM 4.34.1 stimmen <wpt> und <trkpt> überein, wenn sich die Breitengrade um weniger als etwa 0,0000009 unterscheiden, was ungefähr 0,1 Meter entspricht.

Bei Zoomstufe 19 entspricht 1 Pixel etwa 0,3 Metern.

https://support.garmin.com/en-GB/?faq=hRMBoCTy5a7HqVkxukhHd8
https://wiki.openstreetmap.org/wiki/Zoom_levels

Bei einem festen Breitengrad sind die zulässigen Längengradabweichungen geringer.

Ich kann die genaue Logik nicht nachvollziehen – es wird nicht einfach nur auf die Dezimalstellen gerundet. Das Ergebnis sind jedoch ungefähr 10 cm für 3.70.17 und 4.34.1 und 1 Meter für 3.66.2.

10 cm erscheinen mir viel zu wenig – es könnte sich um einen Fehler handeln oder es gab einen triftigen Grund für die Reduzierung.

Es ist unmöglich, die Wegpunkte auf der Bikerouter-Karte mit der von LM 3.70 und 4.34.1 geforderten Genauigkeit zuverlässig zu positionieren, da ein Pixel selbst bei Zoomstufe 19 eine größere Distanz als den zulässigen Grenzwert abdeckt.

------

Haben Sie überprüft, ob Sie für 3.70.x die Routendaten geladen haben? Das könnte ein Grund dafür sein, dass die Neuberechnung nicht funktioniert hat.
#4
Maps / Re: Online LoMaps V2
June 22, 2026, 16:27:50
Feedback when using on PC (Chrome):

Map Content  - It's a bit difficult to see what has changed as the old one isn't there any more. Anyway, from memory....
Pros:
1/ Major peaks now captioned at zoom 13.
2/ Some tracks are now shown at zoom 14 where they were not previously.
3/ Hiking/cycling tracks - have they got a bit less prominent ? - thinner and maybe not as bold ? or am I imagining it? The planned route seems to be more visible when overlaying these tracks, also helped by the recent change that makes it dashed. In some locations they were a multi-colored spiders-web which made the planned route hard to see, especially for those of us with imperfect color vision. Seems better now. 

Cons:
1/ As per Graf Geo post.... really want to be able to control layers - hill shading, and those pesky hiking/cycling routes which I always disable in the android app.
2/ Some tracks can be a bit faint so hard to see where there is strong hillshading, and that can't be disabled or adjusted. Having said that, the hill shading does look very nice - visualising the terrain is good. Ideally it would be possible to adjust the strength/opacity of it (and maybe other parameters) or if that isn't possible then to hide it, or else have two versions of the map one with hill shading, one without, so we can switch betweeen them when needed.
3/ Still can't control the style of the planned route (width/color/opacity/dasharray).  Not strictly map related but thought I'd bang the drum again. The planned route is what it's all about !

Rendering:
1/ Panning:  Vector: When panning quickly the map is rendered seamlessly;  raster: the tiles can be seen being drawn (blank until they are drawn). Minor thing really.
2/ Captions:  are sometimes inconsistent in the Vector Map. e.g. Look at Ben Nevis at  56.796853, -5.003524.  Caption is present at zooms 13 and 19,  but in between it briefly appears then disappears.    It is OK in the raster map.  Similarly, Yr Wyddfa  (Snowdon) at  53.068453, -4.076301 the caption disappears at zooms 15 and 16 on the Vector map.  There was a similar but worse problem on the old map, different cause perhaps,  which was fixed.

No performance issues with vector.

Other:
Are you intending in future to provide other maps, like OAM, OS Maps, etc. ?

I never liked the "flying" map - i.e. if you drag and let go -  still don't. I don't see the point of it - seems like a gimmick. Sometimes if you lift your finger slightly too soon it "flies" when you don't want it to then you have to move it back. If you are in planner mode, then if you stop it by clicking on the map then you get an unwanted route point.

Since WebPlanner V2 the planned route and selected track are now part of the canvas graphics along with the map, previously they were SVG paths. Was this really necessary ? It makes them "invisible" programmatically.

General comment: great to see all these infrastructure changes - but now really looking forward to the rewards, addressing some of the many usability ideas/suggestions pending.  e.g. Number 1 priority for myself: VIA point management - currently it has to be a two stage process - create the route in Web Planner then edit and refine it in the android app.  I'd like to be able to do everything in one go, on my PC with big screen and mouse/keyboard.
#5
(Übersetzt aus dem Englischen)

Vorschläge für Erklärungen:

Beim Import eines Tracks mit <wpt>-Einträgen muss Locus Map berechnen, ob es sich bei jedem <wpt> um einen NAV  oder VIA-Punkt der Route oder um einen unabhängigen POI handelt. Meiner Beobachtung nach (ohne Insiderwissen !) funktioniert dies ungefähr wie folgt:

a) Es wird geprüft, ob die Breiten- und Längenkoordinaten des <wpt> nahe genug an einem <trkpt> liegen. Falls nicht, handelt es sich um einen POI.
In der aktuellen Version V3.70 (und LM 4.34) bedeutet "nah genug" anscheinend einen Abstand von ca. 10 cm, berechnet aus den Breiten- und Längenkoordinaten.
In V3.66.2 liegt der Abstand bei ca. 1 Meter.
Diese Werte habe ich durch Experimentieren mit den Positionen der <wpt> ermittelt. Die Entwickler von Locus Map können die genaue Logik erläutern.

b) Falls nahe genug, werden <sym> und/oder <locus:rtePointAction> geprüft. Handelt es sich um eine Richtungsangabe (links, rechts usw.), ist es ein Navigationspunkt (NAV). Andernfalls ist es ein VIA. Die Längen- und Breitengrade des importierten Wegpunkts werden vom zugehörigen Trackpunkt (<trkpt>) übernommen, sodass der VIA oder NAV Teil der Route ist.

c) Die Wegpunkt-Einträge (<wpt>) müssen in der gleichen Reihenfolge wie die Trackpunkte (<trkpt>) vorliegen. Andernfalls kann es zu unvorhersehbaren Ergebnissen kommen, z. B. werden VIAs  (deren Längen- und Breitengrade mit einem Trackpunkt übereinstimmen) als POIs geladen.

d) Trackpunkte (<trkpt>) können selbst als NAV oder VIA gekennzeichnet werden. Das GPX-Format von brouter-essbee ermöglicht dies. <sym>pass_place kennzeichnet einen VIA.

Mit dem Track gespeicherte POIs werden in LM auf der Karte angezeigt, sind aber nicht Teil der Route – beim Bearbeiten der Route verschwinden sie. VIA werden als kleine blaue Kästchen dargestellt, liegen immer auf der Route und dienen auch  als Shaping punkte. POIs werden von der LM-Navigation nicht angezeigt/angekündigt. VIA-Punkte hingegen schon.

Die Berechnung zur Zuordnung von <wpt> und <trkpt> hat sich nach Version 3.66.x anscheinend geändert. In Version 3.66 gab es eine größere Toleranz. In späteren Versionen muss ein <wpt> deutlich näher an einem <trkpt> liegen, um als VIA-Punkt zu gelten. Ich vermute, dass dies der Grund dafür ist, dass früher viele (aber wahrscheinlich nicht alle) <wpt> als VIA-Punkte geladen wurden, in Version 3.70 jedoch nicht mehr.

In den GPX-Dateien von bikerouter und brouter repräsentieren die <wpt> vermutlich die Punkte, an denen Sie auf der Karte geklickt haben. Dabei handelt es sich eigentlich um Shaping Points (in der LM-Terminologie) – nicht unbedingt um VIA-Punkte –, obwohl brouter sie als VIA-Punkte bezeichnet. Verschiedene Apps verwenden manchmal dieselbe Terminologie mit leicht unterschiedlichen Bedeutungen.
Ich glaube nicht, dass der Typ "via/shaping/from/to" für LM relevant ist – er wird ignoriert.

In den GPX-Dateien von bikerouter und brouter stellen die <wpt>s die Punkte dar, die Sie auf der Karte angeklickt haben. Hierbei handelt es sich eigentlich um Shaping Points (in der LM-Terminologie) – nicht unbedingt um VIA-Punkte –, obwohl Brouter sie als VIA-Punkte bezeichnet. Verschiedene Apps verwenden manchmal dieselbe Terminologie mit leicht unterschiedlicher Bedeutung.

In der Brouter-Essbee-GPX-Datei sind die "VIAs" in der richtigen Reihenfolge, da keine NAV-<wpt>s vorhanden sind. Sie liegen jedoch nicht nahe genug an <trkpt>s und werden daher als POIs geladen.  Die als NAV oder VIA markierten <trkpt>s werden entsprechend geladen. Wenn Sie in LM hineinzoomen und diese VIA-Punkte genauer betrachten, sehen Sie zwei kleine Punkte. Einer (auf der Route) stammt vom <trkpt>, der andere (etwas abseits der Route) vom <wpt>, dem Punkt, auf den Sie in Brouter-Essbee auf der Karte geklickt haben. Wenn Sie diese Punkte abseits der Route nicht sehen möchten, löschen Sie die <wpt>s vor dem Import.

Einige andere Routenplaner erstellen GPX-Dateien, bei denen die NAV and VIA <wpts> immer die gleichen Längen- und Breitengrade wie der zugehörige <trkpt>  haben und daher korrekt geladen werden. Beispiel-App: plotaroute. bikerouter hingegen nicht, daher die Verwirrung. Falls für LM der Brouter-<wpt> innerhalb von 10 cm von einem <trkpt> liegen muss, ist dies unwahrscheinlich, da dies nur eine sehr geringe Anzahl von Pixeln auf dem Bildschirm ausmacht.
-----------------------------

U-turn bei Abweichung vom Kurs: Bei der Neuberechnung der Route durch LM wird die aktuelle Richtung meines Wissens nicht berücksichtigt. Es wird lediglich eine neue Route generiert und der nächste NAV- oder VIA punkt angezeigt oder angekündigt. Sie werden also nicht aufgefordert, umzukehren.

Routenneuberechnung: Sind Sie sicher, dass Sie in Version 3.70 die Routendaten für den Standort heruntergeladen haben? Ich habe festgestellt, dass die Neuberechnung wirkungslos ist, wenn die Daten fehlen.
#6
Troubles & Questions / google drive backups
October 06, 2025, 19:37:56
As per https://help.locusmap.eu/topic/38931-google-verification-status-and-google-drive-backups.

Can anyone explain technically why backups to google drive are being axed, when far as I can see there is no need for full google drive access just to do backups (and restores)?
With the "own files" (drive.file) access an app can create, list, modify, delete app created files which should be all that is needed isn't it ?  Verifying the app with google for that access should be straightforward. Other apps have done that.
There are no doubt other functions in LM which need full access, so these would have to be stopped, but including backups in that seems like "throwing the baby out with the bathwater".

There are workarounds of course so not the end of the world, but I'm just curious about it. 
For example with tasker , which does not have full gdrive access and can only access files/folders it has created itself on gdrive, I can sync all LMs backups to gdrive and then list them,  download them or delete them using tasker. So why can't LM do that itself, without needing full gdrive access?
#7
Tasker / Re: Plugin variables not working - anyone?
January 20, 2025, 00:02:22
Hi,
I just found the same 30 mins ago.
All the variables I use from Request Sensors and Stats are empty or 'null'.
Get Locus Info is still OK.

My tasker project is also now broken.

It was working for sure on December 27 , the plugin was updated on my phone on Jan 10th.  Locus itself was not changed in the meantime.

I guess the API probably has had quite a few updates since the previous plugin version was created.
#8
Troubles & Questions / Re: Locus News in Status Bar
January 13, 2025, 14:45:34
On my Samsung Android 14 there is: "Settings/Notifications/Advanced Settings/Manage notification categories for each app".
Ensure that is enabled.
#9
Tasker / Re: nearest point
January 02, 2025, 19:32:46
I raised this as an "idea" 3 years ago but it still hasn't gathered any votes unfortunately.
See   https://help.locusmap.eu/topic/26875-broadcast-intent-navigation-to-nearest-point.

Currently I think Tasker Autoinput is the only way to do it but that's unreliable IMO.

I don't understand why Navigation "stop" and "recalculate" are available but not "nearest-point".
Maybe it could be reconsidered ? 
Please. :)
#10
Apologies for jumping in on this conversation, but it is of some interest to me.  I was very confused as I did not have the "Tap and Hold to Display Address" setting enabled, but I got it now and can see the reasoning. Hope this helps (and is correct !)

The issue, I think, is whether or not you have got the offline Lomaps for your region downloaded, even if using a different map.  When creating a point in a route this is where it gets the address data from. I don't believe OAM maps include the address data. If that Lomaps address data has not been downloaded then you get just "Shaping point" or "Via Point" in the point's name.

However (provided setting "Controlling/Map Screen/Tap and Hold to Display Address" is enabled !!) when long pressing on the map it DOES show the address - so it must be getting this online - I proved it by setting Airplane Mode - and it can't then get the address.
But when adding the point it still uses the offline Lomap as the source, so this does seem strange/inconsistent. If the offline data isn't available then why not use the online as it has already got it ?  Maybe there is a technical difficulty with that.

For myself, I do have the offline Lomap downloaded for my region so everything works fine. As long as you don't mind the extra storage space needed, that is one solution to the missing address in the point.

On the question of Shaping versus Viapoints.... position cursor at the location, long press on the "+" button at bottom left, then choose "screen centre" will create a viapoint with name filled in with the address. Alternatively there is an option in the route planner settings "Via points as default".  You might want to try that out.  But I suggest download the offline Lomap first.

I can't see a way to directly edit either a Shaping or Viapoints name/icon data. Seems you can only do that when changing from Shaping to Via Point.
So to change a Shaping Points name (or icon) change it to viapoint, edit, then back again, To change viapoints name, change it to shaping point, then back to viapoint then edit.
Could be improved I think, unless there is some other way of doing it already but I can't see it.
#11
Tasker / Re: Tasker task trigger in menubar
September 05, 2024, 12:34:02
Haven't seen anything about app factory problems in Android 14 but I dont use myself so don't know. Have you tried the obvious things like rebooting and/or recreating the app ? 
However, if stuck then you could try these alternatives.

1/ Install Locus/Tasker plugin.
Run plugin app; Settings;   Ensure "Run Task From Functions" enabled. Set Regex to match just your tasker task. (format "Projectname/Taskname"  - Default Project is named "Base")
Locus: configure menu; Add Function - add "Run task" from "Add-ons" section.
One tap needed to run, provided Regex matches just one task else it shows a selection list.

2/ Quick BookMark
URL    tasker://assistantactions?task=YourTaskName&par1=YourValue1&par2=YourValue2
Two taps needed to run.

3/ Tasker secondary app.
Tasker: Preferences/ActionTab - ensure "Secondary App Enabled" set. Create profile using "Secondary App Opened" event and map to your task.
Locus: configure menu; Add app - Tasker Secondary.   
One tap needed to run.

There might well be other ways. (e.g if Locus can trigger app shortcuts or send user defined Intents then Tasker can react to those and map to Tasker task)
#12
Tasker / Re: Tasker Plugin returns Altitude 0.0
August 19, 2024, 11:56:01
Hi
I only just noticed this item. 
I have to plead guilty to using the plug-in "map_center_altitude"  but only in one tasker task and only when testing it - which clearly I haven't needed to do for some time (since originally writing it) as I had not noticed it now returns zero.
I suppose ideally it could be enabled only when needed - e.g only if GPS disabled, or perhaps an expert setting, however if that is too much effort then fine.

(BTW I do use map_center_lat and map_center_lon in several tasks and much more often)
#13
If you don't mind not seeing real-time display of point on map, then you could probably do this using tasker and save the points data to a file, then import to Locus at home, or periodically when convenient when on road.

(ie. detect key strokes in tasker (various ways of doing this) with different key/letter (or combination) for each point type,  get lat/lon via locus/tasker plug in or from tasker itself(slower), then write/append gpx format waypoint line to file, alert (e.g. beep) on success/fail).

On the other hand...   "finalize support for so-called Actions Tasks"  .....  Yes Please!!   
e.g. QNP, export currently navigated route, import/export track or points, 'navigate to' with auto start nav, Nearest Point when navigating,  etc       :) 
Currently have to use tasker Autoinput (screenscraper) which is far from ideal.