Sorry, I missed your question because it was in an edit instead of a new post.
Kurviger routing is powered by GraphHopper routing library.
You can check GraphHopper code for information about instruction signs.
Tnks Emux. Perfect. Fits nicely with
Optimal is that a Navigation sign: -98 is generated by the Kurviger router.
Compare u-turn list by Locus sym vs the Kurviger signs.
The U turns Icons by Kurviger app.
Good to know.
I got a comment about a corrupt Kurviger file that I posted here.
To avoid confusion I have removed it. Yet it was not corrupt.
This was a file generated by the combination Kurviger App_Brouter.
In the kurviger file format, this is marked by the App as being a B_router generated file.
If you import this .kurviger file back into the app, it automatically selects than BRouter.
However, if you import this kurviger file into the website, it will give you an error message.
That is because the website does not support the app_BRouter generated kurviger files.
It would help in this case if the website gives a more precise error message here.
Where?
The route service is selected in settings by the user.
Kurviger files are just route containers, they should be compatible.
By PM.
Test: By the APP (online): Set Router: Kurviger online.
Import the attached file.DeadEnd-Test_brouter_Kurviger-fastroads.kurviger (1.2 KB)
Import than find short pop up: “BRouter traject” I think = very smart and logical.
= Ready for start Navigation. (no street names)
Than if you do trigger a recalculation (by placing a single Shaping Point) so the online Kurviger Router is activated such than does recalculate the traject by the selected Kurviger router profile.
The Website refuses this input. (Has no BRouter)
I think the rejection so is very logical but the error msg could be improved.
Anyway Robin should complete this answer.
Importing a Kurviger file does not calculate a new route, so it should not be affected by the route source.
It can be fixed from the app side and will be available in the next version.
Fine tnks, and a chance for the sign: -98 activation in the app ?
What do you mean?
The turn instructions come from the routing.
In the file that comes from the Kurviger router the sign-98 is very correctly generated and attached but the app does not make use of it.
The actual app probably seems to be missing the corresponding U-turn instruction and the Navigation Icon ?
This has been discussed before.
Shaping points do not have voice guidance.
Instead you can set a via point there.
There are no extra instructions on via points, except their name announcement.
I could allow turn instructions too, like mentioned above.
In the next Kurviger file generated by the online Kurviger router it is (internal) in instruction 3 inclusive street.
DeadEnd-Test_Kurviger_router.kurviger (1.1 KB)
All signs must always be included in routing responses, for responses to be valid and complete.
Then whether a sign is used or not, it’s the client’s responsibility to decide.
Via and shaping points work differently, we already have discussed all that.
Please explain what you mean.
App is the client right ? Website display is also a client right ?
App does not display nor use. Website does, see instruction list.
App is one of the clients and follows specific rules for via and shaping points.
Shaping points don’t have voice guidance or else they will be identical to via points.
Via points (now) announce only their name and not their turn instructions.
Website is another client.
@boldtrn can answer for that.
Than why not using than that generated sign:-98 ?
This is not a Shaping Point nor a Via Point it is a Navigation Point.
It’s a turn instruction produced from / on a shaping point, which are not announced.
If you want turn instructions on waypoints you should use via points.
And wait when app can offer turn instructions on via points in the future.
Please check the waypoint types topic where all these have been discussed with the community:
A Navigation point generated (by the router) with a very close nearby Shaping point (by the user) that it is. The Navigation point should be announced the Shaping Point sure not as agreed before.
public static final int UNKNOWN = -99;
public static final int U_TURN_UNKNOWN = -98;
public static final int U_TURN_LEFT = -8;
public static final int KEEP_LEFT = -7;
public static final int LEAVE_ROUNDABOUT = -6; // for future use
public static final int TURN_SHARP_LEFT = -3;
public static final int TURN_LEFT = -2;
public static final int TURN_SLIGHT_LEFT = -1;
public static final int CONTINUE_ON_STREET = 0;
public static final int TURN_SLIGHT_RIGHT = 1;
public static final int TURN_RIGHT = 2;
public static final int TURN_SHARP_RIGHT = 3;
public static final int FINISH = 4;
public static final int REACHED_VIA = 5;
public static final int USE_ROUNDABOUT = 6;
public static final int IGNORE = Integer.MIN_VALUE;
public static final int KEEP_RIGHT = 7;
public static final int U_TURN_RIGHT = 8;
public static final int PT_START_TRIP = 101;
public static final int PT_TRANSFER = 102;
public static final int PT_END_TRIP = 103;
The turn instructions on via / shaping points are generated because of the via / shaping points.
Anyway the discussion keeps doing circles, perhaps the community can explain better all that.
We’re not going to fight for it, but you can just say you don’t want it. But a better example of what the website shows with the return symbol in the instruction list I don’t have to offer. You may indeed place hundreds of Shaping Points without notice, but only in this very specific case does the navigation point with its instruction exactly coincide with the Shaping Point. I think you are mistaking that.
You know, we are not going to put the website and the application against each other.
We compare politely.
But in this case, the website implementation is right.
Perhaps there is a misunderstanding:
As far as I can see, the routing returns 2 instructions for each via point / shaping point: The first has sign=5 which is the value for “REACHED_VIA”. It also has distance=0.0 and time=0.0, which means that the following instruction is on the same place.
The following instruction is the 2nd one - in many cases it has sign=0 ( =“CONTINUE_ON_STREET” ), but in the case that the point is in a dead end, it has sign=-98 (=“U_TURN_UNKNOWN”).
Showing the turn instructions on the Website, both turn instructions of the via points / shaping points are shown (please see screenshot of @0709 above).
As far as I understand, the app suppresses the 2nd turn instruction of the via points / shaping points: Even if I change the shaping point from route above to via point and enable option “Waypoints in instructions”, I can not see a hint that I have to make an U-turn @ the via point (Version 1.14.11).
I am not sure, if the discussion “announce via points / shaping points or not” and the option “Waypoints in instructions” concern just the announcement “here is a via point / shaping point” or if it includes “hide the 2nd instruction or not”:
My current, personal opinion:
- hide the 2nd instruction or not" should be a separate descision
- In most cases it is good to suppress the 2nd turn instruction, because it is just a “continue on street” hint, which would not be there if the via point / shaping point would not be there,.
- But if there is a real turn hint (any left, right, U-Turn hint) it would be useful to show it even in combination with shaping point, because it would be also there if the same route leg would be routed without that viapoint / shaping point.
The “Dead end U-Turn” case shown by @zaphod_42 is an extreme example - as Wolfgang mentiond you miss the turn point, if you do not observe the map. - On the other hand, this “severe case” is caused by a user failure (@Wolfgang: sorry
), so the first advice would be “avaoid failures” - as in many cases, a more complex handling of the decision “show 2nd turn instruction?” would increase the effort, due to limited developer resources a priorization has to be done! I would like to have such an improvement, but would give a low priority ( = “nice to have” )