Use types of way points

[afischerdev]

Using incoming waypoints is a bit confusing. We now have:

//  "lonlats"         = lon,lat|... (unlimited list of lon,lat waypoints separated by |)
//                      variantes: lon,lat,d|... (from this point to the next  do a direct line)
//                                 lon,lat,name|... (route point has a name and should not be ignored)

A list of points that can have plain entries, entries with marker 'd' (direct) or with name. Therefore, I would like to propose a typification of points:

type	short	description
meeting	m	A meeting point is a point the router have to visit. Like e.g. shop, restaurant, service point. Start and end point are always fixed points. Only when the start point is the start of straight routing it is not matched to a way.
shaping	s	A design point that gives a route an extra info where to go. This point must not be visited by the router - see discussion around misplaced via points #519.
direct	d	The point where direct routing starts to the next available point.

So we have on end a new definition like this:

//  "lonlats"         = lon,lat|... (unlimited list of lon,lat waypoints separated by |)
//                      variantes: lon,lat,type|... (this point is marked with a type [m,s,d]=[meeting,shaping,direct])
//                                 lon,lat,type,name|... (route point has a name and a type and should be named in output)

What do you think? More types? Other names, description?

[devemux86]

The straight line becomes a 3rd type? Shouldn't it able to work together with any point type (via | shaping)?

Other routers allow to set a straight line on any point: via or shaping or start / end. Meaning they set separately the point type and the point weight, e.g. straight line.

[afischerdev]

@devemux86 I see the direct type as a variant of the meeting point. When it is not the first point it has a previous segment and it starts with the end point of this segment. Sample: We have 1.0,1.0 ; 1.1,1.1,d ; 1.2,1.2 BRouter calculates segment by segment, means it starts with 1.0,1.0 ; 1.1,1.1. The result for a 'normal' segment is matched to a way. Then 1.1,1.1,d to1.2,1.2 is routed direct.

That is the way it goes at the moment. Real sample here

[afischerdev]

A new idea of a typed waypoint:

type	short	description
changing profile	c:car-fast	A point to change the rules of routing with a new profile.

This could allow routing combinations like

• car-fast (to get out of the city) and car-eco (to enjoy the countryside)
• train/hike to spend a nice day out in the mountains
• ...

The result is a routing file with two routes included:

 <trk>
  <src>brouter_car-fast_0</src>
  <type>car</type>
...
 </trk>
 <trk>
  <src>brouter_car-eco_0</src>
  <type>car</type>
...
 </trk>

What do you think?

[devemux86]

@afischerdev do you mean trk or trkpt? (you mention waypoint but the example has trk)

[afischerdev]

@devemux86 I mean two trk in one file as a result of this logic. One trk is routed with the first profile, the next is routed with another. The waypoint is 'only' the point of change for the profiles.

[devemux86]

A gpx can contain multiple trk for multiple routes. As the src and type can be used for the router info and the travel mode, it would be useful.

@0709wiwiwi any comments?

[poutnikl]

LocusMap has the feature for this in the route planner, where you can change the profile before any addition of next route segment.

[0709wiwiwi]

When I think of multitracks, I spontaneously think of a triathlon route. Three consecutive tracks for a total different activity. I hope by waypoints effectively meant are routepoints.

And since Locus is mentioned apart notice a very important difference. See the attachment txt. Cruiser navigatietrack.txt

[poutnikl]

Obviously, the needs differ dramatically, if the planning is done on the web or the target application. I do almost exclusively the latter.

[0709wiwiwi]

See the attachment txt.

One more thing. What should be obtained through the trkpt scr profile tag is: Through a trk type profile change you can so recalculate the (navtrk) navigation track. Track sections ending on a section target Via or shaping trkpt inclusive src tag are not recalculated. Like a beeline section which should definitely to be excluded from any track recalculation.

[afischerdev]

@poutnikl

LocusMap has the feature for this in the route planner

Good to know that. I think this is done by two (or more) calls an BRouter api

@0709wiwiwi Triathlon is a nice sample on that.

I hope by waypoints you mean route points.

I mean the incoming points for the BRouter calculation. Route point is a result point of the calculation - for me. But sorry we don't have a gpx input at the moment.

[devemux86]

I mean the incoming points for the BRouter calculation.

@afischerdev do you mean that we will be able to mix the BRouter profiles in 1 route request?

Request a route with N segments: 1: car-fast, 2: trekking, 3: hiking, ... So the waypoints in the request will have extra field(s)?

[poutnikl]

@poutnikl

LocusMap has the feature for this in the route planner

Good to know that. I think this is done by two (or more) calls an BRouter api

AFAIK, LocusMap perfoms the series of sequential BRouter API calls for each route segment separately, including the profile to be used ( passed by API too). Then it joins the provided data into the single calculated route, that is eventually used or saved.

[afischerdev]

@devemux86

do you mean that we will be able to mix the BRouter profiles in 1 route request?

That was the basic idea on the new type of waypoint. It could look like this

...&profile=car-fast&lonlats=1.2345,50.12345;1.345,50.345,c:car-eco;1.456,50456...

I haven't tried it yet, just an idea for now.