Messages

Hello Orux,

the problem still persists in Version 10.7.2 GP.

I'm aware that you tried to fix this issue and my feeling is that there were fewer false alarms in some intermediate versions. On my last trip (1200km by bike in Spain, 10.7.2 GP Version) I had a lot of false alarms again, although I switched to a more up to date smartphone (Samsung Galays A55). So the hardware should not be the issue. As already stated: ther's no jitter on the recorded track, so I guess the route alarm uses some raw gps signal and not the "saved positions" when calculating the distance to the route I follow...

Best regards and thanks for your great work.

The Amazon Store Version (9.6.9 AM, last update Jan 2023) doesn't seem to support online Maps like the GP-Version, at least the "Online Maps" tab is missing in the "load new map" feature.

Adding a "onlinemapsources.xml" file under maps/customonlinemaps doesn't seem to have any effect. I use the app via the windows subsystem for android (wsa), which by the way, works like a charm (with offline maps): you can use oruxmaps on a high resolution pc screen, which is a great advantage for planning routes.

Since at least one of the "WMS" Maps are working, I'm sure that WSA has proper internet access.

My dream would be to do my whole route planning within oruxmaps on a pc. At the moment I use the web version of brouter, komoot and google earth in combination. Although oruxmaps already supports route planning via brouter, it's still not possible to move, delete and/or insert intermediate routing points. If that would be possible oruxmaps would be the perfect tool for route planning on a pc.

In my case the overlay is generated automatically by the poi search, so that can't be the problem. I can show/hide the overlay with Kartenwerkzeuge(maptools)->KML-Folie anpassen(adjust KML-overlay). There's also a predefined button you can add to the interface.

I use the "old interface", meaning neither "Einheitliche Benutzeroberfläche(unified interface) nor LTE Interface is checked.

Sorry - no more ideas.

For me it works in 10.1.8.

Are you sure you have an appropriate map which supports pois? After doing the poi search it shows: xx number of poi found. xx should be greater 0? It should work e.g. with any of the mapsforge maps from https://www.openandromaps.org/, at least when one of the pois you search for is within the actual display range of the map.

Furthermore you can hide and unhide an overlay layer which is very helpful to show/hide the poi search result afterwards. In an earlier version you didn't see the search result when the overlay layer was switchen off. But in version 10.1.8 this bug seems to be fixed because afer a poi search the overlay layer with the pois is always switched on.

Could be related to https://oruxmaps.org/forum/index.php?topic=41949.0?

the track...

Hi Orux,

in the height diagram waypoints have correct height but are located at a wrong distance, as you can see in fig. 1. In fig. 1 only 11 waypoints show up, but the track is 1165km long and has 12 waypoint ("Tag 12" is missing at the end). Furthermore all waypoints are located directly on the track, which is obviously not the case in the height diagram (even after height correction within the app with very accurate dem files).

This can further be proofed by taking a terrain-height profile near "Tag 5" (which is nearly 400m off in height in the height diagram) from within the app, as shown in Fig. 2 and Fig. 3. Fig. 3 shows that waypoint 5 and the track around waypoint 5 is roughly around 1160m height (so waypoint 5 has correct height, which is matching with the dem-cursor-height readings within the app). As you can see in fig. 4 waypoint 5 is locatet around 430km distance but should be correctly placed at around 350km distance, at the peak after "Tag 4" in the height diagram (see arrow).

I'll post the track in the next comment, since only 4 attachements are allowed. The track was created in brouter (outside the app).

I used V. 10.04 GP. Latest beta and V. 9.6.3. AP show the same.

I noticed the same behaviour several times on a long 1000km bike trip. Got false alarms even when the road was straight and in plain terrain without trees that could impair gps.

See:  Errors/Bugs: "False alarms in route alarm" « on: October 02, 2022, 06:15:04 PM »

Helllo, We have added flags for the languages.

To attract more people you might integrate a flag in the main menue  ? The point is that not all foreigners know that "Idioma" means "language selection". You could copy from https://www.openandromaps.org/ for example.

Hello Orux,

with 9.0.4 GP I get very often a route alarm although I'm perfectly on the route which I follow. My settings to start the alarm is 160m and 320m to stop the alarm with 2 alarm repeats. I get those false alarms even in a perfectly plain area (no hills, no impairment of gps signal) and even on perfectly straight roads. When I get such a route alarm I switch on the display and compare the recorded track with the route: I can see that there is no deviation, and definitely not in a 160m range. Sometimes I even get a second alarm before after a while the route alarm tells me that I'm back on the route. So at least based on the recording those false alarm should not happen. Is it possible that the route alarm uses a raw gps position which might be different from a recorded (maybe averaged) gps position? I use a galaxy S9 and did the test during a 1000km bike trip. If helpful I can provided the tracks for the planned route and the recorded route. Certainly they will differ in some parts where I intentionally left the route, but it's clear that I don't talk about route alarms in these parts.

Additional "bug": I recorded my tracks using a new segment for every day of my trip. When I export the track as .kml using the option "conntect segments if possible" the segments won't be connected.

Best regards, Tilo

Hi Orux,

In deed I thought that the alarm icon would indicate if "route alarm" is on or off. Thanks for explaining.

I tried to reproduce the road selection, but I couldn't figure out which test condition triggered the reported "problem". In my new attempt everything worked well. I'll report again with a video if I can describe the test case properly.

Best regards, Tilo   

Hello Orux,

found some small improvement options for Beta 4 and the Play Store Edition (both show same behaviour):
-  when you toggle the route alarm the route alarm symbol is not updated
-  there's a great option to load multiple routes into the map or to create multiple routes with the routing tool. Each route has a start and an end waypoint which you can touch to see a menue about the route. When I choose "follow route" in this menue the app doesn't follow the activated route. It always follows the route which was created first. You can test this by creating a short and a long route. In the height diagram you see the length of the route you follow. If you remove the first route and choose "follow route" the app still follows the deleted route! It would be great if we could select which route is the "active route". Maybe you even could make this choice visible somehow (e.g. use a grey color for inaktive routes)? The advantage:  you could plan different route options, load them all together in the map and choose duing your ride where to go.
- if you create a route with the routing tool and save it into the database it would be nice if the app would ask for a name. You could use the same procedures/settings which are active when you save a "normal" track recording.

Best regards, Tilo

Hi,

all my problems are resolved all of a sudden: My S9 received a software update and at the same time I installed new beta 1 (at the meantime beta 3) from 9.4.xx betas. Since then no more black stripes. Sonny's 1'' DTM, as well as the DEM Data from within OruxMaps work like a charm. Same with OruxMaps v.9.0.4 GP from store.

Sorry for the fuss, Tilo

Hi,

I tried out Sonny's 1'' DTM, but things got worse. In some parts of the map hill shading doesn't take place at all. So I can even get a mixture of black boxes, shaded and unshaded regions (see attached screenshot). For the result it doesn't matter if the DTM data is stored on internel or external sd card.

@Ineam:  I guess at first place it's a new rendering problem in the app, which didn't occur in earlier versions. I don't think that .hgt tiles are missing in the black box areas. Maybe my phone is too slow.

@Matt: thanks a lot! Certainly to Sonny, too.