Messages

Hi orux,

when planning a route with brouter, the "follow route" works, that means I get a route alarm whem I'm off the route,

but the map is not following the actual gps-position.

+1 for follow route, should include: end follow route

Hello Orux,

I'd like to suggest some small improvements and put them into one topic:

1. away from route alarm:

   now the alarm starts at a certain distance and stops at a certain distance (both configurable).

   when you are very slow (uphill mtb), then you get up to 10 "away from route"-alarms - which is annoying, when you are very fast (downhill) you only get one message,

   so I would prefer to have a configurable number of alarms, similar to the waypoint alarm.

2. display route - dashed line:

    the route displayed in the map (set to: dashed line) overlays the ways on the map, so I cannot see, which waytype is behind the route. I suggest to put more space

    between the dashes, so that I can see the underlying waytype.

3. route calculation and map rotation:

   when calculating a route and turn the device so theh map is rotated, om forgets about the route to calculate and I have to start once again. (I guess this is more a bug)

4. route calculation:

    possibility to add more points when route is already calculated. (similar to brouter web client)

5. map orientation: orientation up:

    having this orientation with mtb it works fine during riding, but when I stop the orientation gets "lost".

    It would be nice if om can keep the last map orientation before stopping.

6. background screen black(dark) instead of grey:

    if found out that new map tiles are painted on a grey background.

    I would prefer it in black or at least dark. The reason is: using om during night the grey backgroung is too bright and is blending

   (sometimes om is a bit slow in painting the new tiles and then you first see the grey background screen).

panda

Hello Orux,



when creating a new waypoint, it gets automatically the type "left" (or at least the text in field type is "left", the symbol is the green sticker), should be "waypoint"  (in market version it works OK).



I don't know how I managed it, but now my waypoint-types are all in english (for new waypoints or edit waypoint), although I have german language setting. (Yesterday it was OK, I switched between german and english language profile)

How do I get back to the german waypoint-types?

Hi,



I think it is working well. Have you changed the locale recently?





orux

What do you mean with "locale"?



Here are the screenshots:

http://up.picr.de/20040360ai.jpg">



http://up.picr.de/20040361bi.jpg">

Hello Orux,



when creating a new waypoint, it gets automatically the type "left" (or at least the text in field type is "left", the symbol is the green sticker), should be "waypoint"  (in market version it works OK).



I don't know how I managed it, but now my waypoint-types are all in english (for new waypoints or edit waypoint), although I have german language setting. (Yesterday it was OK, I switched between german and english language profile)

How do I get back to the german waypoint-types?

On the brightness issue, have you tried any auto brightness tools from Google Play- they usually allow the screen to automatically adjust to lower brightness settings than stock android. Lux is popular and includes temporary changes to brightness. I prefer Velis because it has a brightness preset of AMOLED Dim that suits me perfectly, even though my screen isn't amoled.

Hello goosiebn,

interesting tips, but I read on google play, that Lux does not work on android 4.4. I don't know if Velis works.

At the moment it would be the easiest to have an option within oruxmaps to change the loudness button to brightness setting instead of digital zoom.



@Maki: thanks for that info, I expexted something like this. Yesterday I was once more annoyed from the garmin maps, so finally I decided to stop using them and build my own MTB-Theme and additionly a MTB-Night-Theme.



But there's one more point, that should be improved:

when the screen is off and then screen is turned on (manually or by waypoint alarm) or when you zoom or scroll, om first paints a very bright grey screen

and then paints the map on that grey screen. It would be much better, if om paints the initial map on a black screen.

Hi,  i suggest you to use altitude from dem file and tap on "interpolate dem file".  With this Method i solved my problem of uncorrect altitude.

Hello,

finally at the weekend I made some tests with the setting you recommend and with the latest beta (36).

Now the ele gain is between 5% and 20% higher than my barometer device.

Especially on a ripled surface with many small ups and downs it's approx 20% too high.

I think this range is not perfect, but it's acceptable.



So the setting "use altitude from dem file and tap on "interpolate dem file"" is the best for oruxmaps to calculate the ele gain.

Of course the values depends on the resolution of the DEM files, at the moment I use the free 3" - files.

In another post I read, that the 1" DEM files will soon be freely available, so there's hope for even better ele gain values :-)

Hi Orux,

is there a possibilty to change the night mode settings?

Afaik no - but perhaps I missed something.



At the moment all lines are white and I cannot even see, if the line is a street/path or a river.

Thats a bit strange.



For mountainbiking I use a garmin map, where the tracks/paths have the colours red, green and brown.

It would be really helpful to see these ways in these colours.



In addition I'd like to ask for an easy way to change brightness of the screen.

One idea is: when you change to night mode, then the loudness buttons are used for brightness instead of digital zoom.

Hi Orux,

I just like to ask: is there a reason why hillshading is only added to mapsforge maps?



I also use garmin maps and the contourlines there are very thin and hard to see, so applying hillshade to that would improve

the information about heights and elevation.

Hello Orux,

the relief shading is really great, you did a super job here, thank you!



In my home region it works good until ZL 15 with 3" DEM-files, in the alps it works good until ZL 14 with 1" DEM files.

In flat regions  with normally white background it's a bit too grey for my impression. So agree with maki and eartrumpet, that settings for that could be useful.



@Thomas: I use different profiles for that. But you have to quit om and restart to take effect.



panda

Hi Maki,

this is great stuff!!



Can you give more details how you did it, I#d like to try on my own.

Hi,



if you have a kitkat android device, and you are using the external sd card, then you have to change the tracks folder to the internal memory, because kitkat doesn't allow the apps to write to the external sdcard.



orux[/quote]



Hi,

I#m using android 4.4.4 and om writes data to SD Card: tracks and maps without probs.

panda

Hello,

when I startet with om and made my first track recordings, I wondered why the measurement of Elevation gain/loss via gps is far away from reality.

Sometimes it's double of the real value (measured with bike computer barometer, which gives good results on stable weather conditions, my phone has no barometer).

I also tried to use DEM-data or online-elevation service to correct the data afterwards, but with few success. Sometimes it's even worse than gps data.



Of course I know, the main issue is, that gps based measurement of height is not very accurate and it varys up to some meters all the time.

So therefore it is necesary to make some averaging to get better height values.

I don't know how om does this, perhaps orux can contribute this, but I think it can be improved.



Here are the details of my test:

I made a trip with bike with one steep uphill, then some km flat, and then steep downhill, distance 18 km.

The correct Elevation gain/loss should be about 800m.

Oruxmaps tells me: 1150m, this is more than 40% off.



Then I took all the gps data (750 points) into Excel and added all Elevation gain/loss from point to point: this gives 1570m - even worse than OM.

(the data shows many small ups and downs, which is wrong)

Averaging #1 (5 points):  I made an average of height every 5 points and added the Elevation gain: 946 m

Averaging #2 (10 points): I made an average of height every 10 points and added the Elevation gain: 886 m



So with averaging 10 points it's only 10% off the value which is pretty good for gps based measures.



Of course this is only an example, perhaps tracks with other profile will lead to other results, but I guess that better averaging the elevation data

will lead to better Elevation gain/loss data.

Hi,



1. why is there so much information missing on openstreetmaps?

-> because nobody has entered it until now. If you live near this place or make holiday there, you're invited to add the missing data.



2. why are the names very small, complete unreadable on gps device?

3. why are the roadlines so thin?[/quote]

-> probably this depends on your device and the dpi it has. When you use mapsforge based maps you can choose different styles to adjust to your device,

eg openandromaps and the themes there: http://www.openandromaps.org">www.openandromaps.org

Hello,

is there an advance in this topic?



I would really enjoy this very much !