BRouter GPX - rouer versus track

195 views
Skip to first unread message

Poutnik

unread,
Apr 23, 2016, 2:48:35 AM4/23/16
to OSM Android bikerouting

Why exactly is a BRouter GPX file generated as a track ( passed ),
when if is semantically a route ( planned ?

Is it a needed trick to bypass
eventual limitations of GPX route implementation,

or compatibility with target systems,
more willing to accept GPX tracks ?

--
Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

Zossebart

unread,
Apr 25, 2016, 7:09:56 AM4/25/16
to OSM Android bikerouting
Hey,


On Saturday, April 23, 2016 at 8:48:35 AM UTC+2, Poutnik wrote:

Why exactly is a BRouter GPX file generated as a track ( passed ),
when if is semantically a route ( planned ?

Is it a needed trick to bypass
eventual limitations of GPX route implementation,

or compatibility with target systems,
more willing to accept GPX tracks ? 

I think it's because a route is defined as a list of routepoints (think of a startpoint, intermediate goals and an endpoint). A route is not meant to describe the exact way to follow (with all the bends in detail) but rather as a list of points to pass.
So a route typically has fewer points than a track.
I think I read that for example on some garmin devices, when given a route, the device computes the exact way between the routepoints itself.
Also, some apps announce a notification on every routepoint, which would be pretty annoying when used with a route which is as detailed as most tracks (lots of points).

regards,
Zossebart

 

Poutnik

unread,
Apr 25, 2016, 7:30:06 AM4/25/16
to OSM Android bikerouting
Hi,

I am aware of the description below.

A BRouter route is not a typical route, having route points so dense they de facto describe an exact way.
Depending on target app configuration, it may be taken as a route, with point list to pass ( strict route following ).
Locus configuration was challenging until I got  it.

I do not have problem with current state, just thinking...

Dne pondělí 25. dubna 2016 13:09:56 UTC+2 Zossebart napsal(a):
Message has been deleted
Message has been deleted
Message has been deleted

Poutnik

unread,
Apr 30, 2016, 4:56:35 AM4/30/16
to OSM Android bikerouting
Dne 30/04/2016 v 10:24 0709 napsal(a):
> Routes=design. But where and when a design is finalised ?
> At software original design output ? Or in the field in your mobile gps
> unit ?

Or both, if generated in the field device.

> If app with routable map in use, routepoints are must pass (via)points,
> but mobile gps can offer a different design between the routepoints.

> Or resulting path depends on the used (actual) map and mobile gps rules
> set. (car,bike,walk). Using a rerouting feature can even allow more path
> changes !

OSMAnd has here big disadvantage , compared to LocusMap,
as the former is quite stupid wrt GPX,
while the latter has quite an advanced management
of GPX following and route recalculations
to address off-route/track state.

>
> Strict Navigation.
>
> Strict Navigation along a track.
> All trackpoints are "must pass" points. Trackpoints are dense by nature
> so a track is exactly followed as meant by the designer.

This does not make much sense
for dense generated tracks like BRouter ones,
where avg point distance is typically about 50 m.

Strict navigation along the track/route is applicable
IMHO in special scenarios only, like for waypoints,
yacht or orientation races,
offroad point2point guidance and similar.
Message has been deleted

Poutnik

unread,
Apr 30, 2016, 7:19:30 AM4/30/16
to osm-android...@googlegroups.com
Dne 30/04/2016 v 13:04 0709 napsal(a):
> I think we agree. Those *special* usage cases:
> Strict track Navigation = Important when track is combined with
> personalised navigation orders. All such nav hints must be delivered at
> correct place and in strict timed order.

But it must not be a dense track,
with dozens of thousands of points,
as there is no reason for you to pass each of them.
Message has been deleted

Poutnik

unread,
Apr 30, 2016, 1:21:22 PM4/30/16
to OSM Android bikerouting
Dne 30/04/2016 v 19:14 0709 napsal(a):
> With dense you probably say a trackpoint +/- each second, as in some
> recorded tracks ?

No, I mean the trackpoints generated by Brouter,
with nav hints or without,
either web or application,
that are placed every cca 50 m in average.

> No, no only the minimal trkpt's necessary to correctly describe a path.
> Of coarse.
Message has been deleted

Poutnik

unread,
May 2, 2016, 2:22:32 AM5/2/16
to OSM Android bikerouting
Dne 01/05/2016 v 20:00 0709 napsal(a):
> Hi Poutnik,
>
> To my own surprise even on a relative simple track I found a problem if
> not using strict.
> Example files in link: See zip
> https://dl.orangedox.com/JeN4FATK56MD7fqMAD/Poutnik.zip
>
Sure, there are scenarios like this
where strict navigation along the GPX is desired,
and other ones, where it is not.

By other words, strict following
may be a good servant, but a bad master.

If route is calculated via application interface,
it is also important if point or route priority is used.

IF point priority with viapoints is used,
route should be in case of deviation recalculated
toward next viapoint ( or destination if none ),
what could be the POI at the end of the junction.
Message has been deleted

poutnik

unread,
May 2, 2016, 5:30:33 AM5/2/16
to OSM Android bikerouting
Hm, not much can be said in advance, what route would a smart custom routing take.. :-)

But I do agree the ready to use predefined local routes can be very useful ( without personal experience) , as well as are the coach planned personal ones.

They all complement each other.

Custom BRouter profiles are great in guessing where you may have wanted to put you routepoints, having clue about your preferences, and do it for you.


2. května 2016 9:00:12 CEST, 0709 <wiv...@gmail.com> napsal:
>
>
>If using a smart routing system the suggestion from knooppunt 73 to
>"POI
>Fons" would take the shortest connection, or the road 'Ridderstraat" to
>the
>"POI Fons", unless otherwise instructed by a "must pass via"
>


Poutnik

unread,
May 2, 2016, 5:53:35 AM5/2/16
to OSM Android bikerouting
We have in Czech Republic 2 marking systems.

1/ Numbered cycleroutes, marked so in the cyclemaps and in terrain by small yellow plates and numbers pointers,
2/ Hikinglike signposts with distances and direction to POIs an places,
     ( while signpost background for hiking signpost pointer, yellow for bikes, orange for cross-country skiing )


Dne pondělí 2. května 2016 9:00:12 UTC+2 0709 napsal(a):
Of coarse my friend. But I want you to follow the official bike route from knooppunt 73 to 72 and only have that small deviation to visit the POI Fons.  See 'cycle' map.

If using a smart routing system the suggestion from knooppunt 73 to "POI Fons" would take the shortest connection, or the road 'Ridderstraat" to the "POI Fons", unless otherwise instructed by a "must pass via"

By the way. Download tracks by website www.fietsnet.be is very popular because fietsnet is always "up to date" using  latest actualised "knooppunten".  (Cycle nodes).
This "knooppunten" system is very nice, but sometimes there are (a lot) changes, and these are not always updated in OSM ! So...
Message has been deleted

Poutnik

unread,
May 2, 2016, 11:37:47 AM5/2/16
to OSM Android bikerouting
I used OSMAnd/OSMAnd+ for almost 2 years, but I prefer these deay LocusMap pro more for bike/foot trips.
Yes, OSMAnd does use routable vector OBF maps, using optionally its internal routing offline servic for car/bike/foot.
But it is not as sofisticated as BRouter.

I will try that GPX in OSMAnd later..

Dne pondělí 2. května 2016 17:29:01 UTC+2 0709 napsal(a):

 Another question. Are you also experienced OsmAnd user ? 
As (I suppose) OsmAnd uses routable maps ? No ?  
Is a  gpx course file output from the JaVaWaRtw tool compatible with OsmAnd ? 
Reply all
Reply to author
Forward
0 new messages