Messages

It would be interesting to know what it can do with the screen on all the time, hours wise for navigating. ... Trying to keep all ones devices charged up on a bike tour can be a challenge.

Good point. I don't normally use navigation mode while hiking and only refer to the phone occasionally (so screen is normally off). Having the screen always on will definitely increase battery consumption. I guess an external battery pack might become a mandatory accessory for long bike tours.

They provide cases for a tiny fraction of Android phones and only for a handful of high end models.

That's the status quo for all name-brand, specialty phone cases, not just Lifeproof. Even Otter and Quadlock focus on Apple and Samsung. However, Quadlock does make a "universal" case where the phone is held in place with adhesive. Of course, it isn't waterproof so that feature must be part of the phone's design.

How about this off-brand, universal, waterproof case with bike mount?
https://www.amazon.co.uk/Waterproof-Resistant-Transparent-Touchable-Smartphone/dp/B071SJ8MBB/

It's inexpensive and has received good reviews. You can use it with non-waterproof phones which opens the door to a broader selection of Android phones.



FWIW, I used to use a Garmin Rino 530 HCx but, after extensive field trials, has been retired and replaced with Locus Map and a Moto X Play. It has a 3630 mAH battery and a bright, 5.5" FHD display (~403ppi density). I've run Locus Map for over ten hours, in track-recording mode, and the battery capacity dropped <30%.

Perhaps of less interest to cyclists but the phone has also served me well for winter-hiking. The internal battery temperature has been below freezing (reported by Locus Map) but has continued to function nominally for both navigation and photos: https://flic.kr/p/QMVs1m

Good luck with your search for the ideal Garmin replacement!

[and claims to be waterproof]

... The Otterbox case has a lot of padding, adds a screen protector and claims to be waterproof. ..

I believe the Preserver model was the only waterproof Otterbox case and they stopped making it in 2015 (for iPhone 5/5s). The Defender model is Otterbox's current "extreme protection" case and they do not claim it is waterproof (only dust resistant).

Lifeproof makes waterproof cases (2 meters for 1 hour) for iPhones and many Android phones. I have a Lifeproof FRE for my Moto X Play.

I used the revised theme and now the map shows trails with steps. However, if I enable "Hiking networks", the steps become very difficult to see. You have to magnify the map to high zoom-value to see them.



It's also difficult to see steps using the Elevate theme (when "hiking routes" is enabled) but it's a little bit clearer.


Regarding OpenAndroMaps, ChristianK responded to my request and said the January map version will include all ladders with numeric values. More information here:
https://www.openandromaps.org/oam-forums/topic/please-allow-numeric-values-for-ladder-safety_rope-and-rungs#post-21356

[highway=steps]

One more thing: "highway=steps". Elevate shows hiking trails with stairs but Tiramisu does not.

http://www.openstreetmap.org/way/535587828#map=18/44.12928/-73.86749&layers=C

['sr_yes']

Thanks! I followed your instructions and the Tiramisu theme now shows the safety ropes and one ladder ("ladder=yes").

The last problem to solve is that both Elevate and Tiramisu don't show ladders defined with numeric values ("ladder =4"). When the map is produced, I believe "numeric ladders" are not extracted from OSM.

This page shows the items extracted from OSM to produce OpenAndroMaps.
https://www.openandromaps.org/en/map-basics-2/tag-mapping

Here is how it extracts "safety_rope" and "ladder":
<!-- tags_alpine -->
<osm-tag key='safety_rope' value='sr_yes' equivalent-values='yes' zoom-appear='15' />
<osm-tag key='ladder' value='ld_yes' equivalent-values='yes' zoom-appear='15' />
<osm-tag key='rungs' value='rn_yes' equivalent-values='yes' zoom-appear='15' />

I will contact the OpenAndroMap team and ask if they can change the filter to include numeric values.

[ladders]

@Magellan

I installed Tiramisu LE 3+2 and it now correctly displays all trails. Thank you!

Perhaps you can help me understand how Tiramisu, and Elevate, display ladders.

A month ago, I added several ladders, and two safety_ropes, to OpenStreetMap. To display the items, I used the latest version of OpenAndroMaps for the State of New York (2017-11-25) with Elevate LE V4.2.1 and Tiramisu 3 LE+2 themes.

• The safety_ropes are displayed by Elevate but not Tiramisu.
• Elevate shows only one of the ladders and Tiramisu shows none of them.

Here is the ladder that is displayed by Elevate but not Tiramisu. It is a node with the tag "ladder=yes".
http://www.openstreetmap.org/node/4773080911

These ladders are not displayed by Elevate or Tiramisu. They are nodes with the tag "ladder=X" where X is the length of the ladder. The lengths varied from 2 to 5 meters. Example: "ladder=4"
http://www.openstreetmap.org/node/5191411959
http://www.openstreetmap.org/node/4234427426
http://www.openstreetmap.org/node/4234427476
http://www.openstreetmap.org/node/4203671346
http://www.openstreetmap.org/node/1690836990

According to OSM's Wiki, it is permitted to enter a numeric value, instead of "yes", for ladders (and safety_ropes).
http://wiki.openstreetmap.org/wiki/Key:ladder


In Elevate and Tiramisu, I changed the rule for handling ladders to be more comprehensive. I replaced "ld_yes" with "*".

OLD: <rule e="any" k="ladder" v="ld_yes" zoom-min="15"> <symbol src="file:../ele_res/s_ladder.svg" symbol-width="16dp" /> </rule>
NEW: <rule e="any" k="ladder" v="*" zoom-min="15"> <symbol src="file:../ele_res/s_ladder.svg" symbol-width="16dp" /> </rule>

Unfortunately, the modification failed to display ladders (with numeric values) in both Tiramisu and Elevate. It also failed to make Tiramisu display the one ladder tagged with "ladder=yes".

Either my rule modification is incorrect or the New York OpenAndroMap simply does not contain all the ladders. Is it possible that when OSM data was extracted to create the New York map, it only selected ladders that were identified with "yes" and rejected all ladders with numeric values?

It would explain why "numeric ladders" cannot be displayed because they simply don't exist in the map.  However, it would not explain why Tiramisu fails to display the one ladder ("ladder=yes") that Elevate can show.


Full-size image.

john_percy, Viajero Perdido

Thank you both for your helpful reply. It now seems clear that Tiramisu is based on Elevate because the two themes show precisely the same trails (and don't show precisely the same trails). In addition, as John suspected, Tiramisu works correctly with OpenAndroMaps.

When Magellan wrote "Now able to work in Locus. Some layers have been added." I assumed the modified Tiramisu theme would work (correctly and completely) with LoMaps. In fact, it only works as well as Elevate does with LoMaps; it works best with OpenAndroMaps.

Am I correct to say that the theme's XML file can be modified to display all hiking trails in LoMaps? I guess the question is how much time am I willing to invest to understand how it works!

[Tiramisu 3 LE]

I installed Tiramisu 3 LE theme but it does not display all hiking trails in LoMaps.

I compared several map themes and here are the results.

Shows all hiking trails?
Hike & Bike = Yes
Tiramisu 3 LE = No
Elevate LE = No
HiLo = Yes
Voluntary UK = Yes


Full-size image

I found useful information about routing with Garmin devices here: http://www.poi-factory.com/node/6656

Garmin has a broad range of devices and they don't all behave the same way. According to someone on poi-factory, devices made before 2013 (like the Nuvi series) don't support shaping points correctly (they treat them exactly like via points ... and announce them).

This post includes a summary of the characteristics of shaping points:

--------------------------------------------------------------------------------------------------------
Shaping Points Advantages:
1- You will not be alerted as you're navigating and arriving at a shaping point as you are when using waypoints/vias.
2- If you deviate purposely off your route, the unit will skip the upcoming shaping point and navigate you to your next shaping or waypoint.
The disadvantage of using only waypoints is when you deviate purposely off your route the unit will try to route you back to the waypoint that you didn't go through.
3- When using shaping points with certain units you're able to manually skip an upcoming shaping point.

Note: Shaping points do not contain arrival time or distance between points information.

--------------------------------------------------------------------------------------------------------

I can't find the post now but I recall reading Shaping Points are exported as <rtept>. I guess this is easy to confirm by exporting a route (containing shaping points) from Basecamp and examining the output.

This is fascinating stuff and I look forward to using Route Planner when it arrives in the next (full) release.


PS
I like Josef's "floating slider" suggestion for adjusting the size of NoGo points.

Should the floating slider prove to be difficult to implement (avoid overlapping other onscreen controls) or to use (it's a narrow target and a finger tap might be misinterpreted as touching the map), then an alternate is to use FABs (Floating Action Buttons).

When a NoGo point has focus, two NoGo-sizing buttons could appear above the existing two zoom buttons ("+" and "-") on the right. The icon on the upper button can be a large circle (to indicate increasing the size of the NoGO) and a smaller circle on the lower button (to indicate reduction of the NoGo's size).

[Via points vs shaping points]

@Andrew

Thanks for the link! The 77th post in that thread (whew!) sums up my own experience with using Basecamp (i.e. its use of undocumented terminology).

To put it politely, the term "Shaping point" is used very sparingly in Basecamp. Searching for "shaping points" in Garmin's online Basecamp documentation produces no results (it finds many matches for "points"). The documentation uses the generic term "Route Points". HOWEVER, if you right-click a "route point", ta-dah!, there in the pop-up menu you see "Remove shaping points"! It also appears in (some) Nuvi documentation.

I defer to my wiser colleagues, who are clearly better versed in Basecamp's "secret language" than I, and accept the term "shaping point".

The 77th post also provides an explanation for the difference between "Shaping Points" and "Via Points".

Via points vs shaping points

• Via points are announced as you navigate, can have scheduling data, and you cannot skip them (unless you tell your device to do so).
  
• Shaping points are not announced, do not have scheduling data, and you can skip them as you navigate.

Is this how the Route Planner is handling Vias and Shaping Points?

[Route Planner]

Problem = Locus does not create a route...but a track to be navigated along.
...
Locus do not generate you a  (technical) route (gpx = rte) but generates you a track (trk) so has trackpoints (trkpt). 

I understand the underlying technical aspect but is it relevant? After all, the function is called Route Planner.

Regardless of the function's output format, its purpose is to plan a route (i.e. the path of your planned trip). You create Route Points to indicate where you want the route to go.

[Route]

The current system uses three kinds of points to define a "Route"

1) Shaping/Destination Points
2) Via Points
3) Navigation Points

Why isn't the most basic of these three points simply called a "Route Point"? Or "Routing Point"?

Would it not be clear that you define a Route using Route/Routing Points? (Instead of Shaping or Destination.)