Tagging uniformisation is valuable, that’s why the previous polished proposal.
But now there is already a new (gpx) challenge ahead.
As routing profiles per segment will therefore be offered later on by Kurviger.
New segment with its own routing profile always do start from a Via Point.
All this sure will be nicely processed in the .kurviger file format.
Anyway is it possible to transfer the router segment profiles by using basic gpx only ?
See the current (Beta app) type text tagging.
Point with tag type without a text “Shaping” is always a Via Point.
In type text so you maybe could add the (Kurviger) routing profile.
Type text = Of course by uniformized (EN)! standard Kurviger profile text.
Example: Via: Manual, Via: Curvy, Via: Fastest, Via: Extra Curvy.
It might be possible to do. I am wondering, why? If no other app can use this information? For ShapingPoints we have a different Sym per waypoint type, that makes sense, because the waypoint looks different.
For different profiles, what would be the expected output? Even more different symbols?
Did I suggest different symbols ? No. Unique could be that neither in .kurviger nor simple gpx format valuable information as Shape and Via Points inclusive the router segment design profiles are lost during file export and re import transfers. That’s all.
Well Robin, a surprise, by so promoting passive Shaping Points in the routing profile process? I rather expected something in the sense of Via: Manual, Via: Fastest, Via: Curvy etc.
As similar softwares initiate such profile segment changes only at Via Points.
If you draw a non-linear path from Via: Manual to the next Via, you so place (several) adjusting Shaping Points in between. Sorry, I have to document by (gpx) human readable text instructions. I do not speak “Kurvigs”
Start contains the first Via Point with profile which can be changed further on subsequent Via’s.
The lower priority Shaping Points only adjust a path that is not optimally calculated.
The less adjusted the routing profile used, the more correcting Shaping Points needed.
By Kurviger it is already quite clear that just one profile is not entirely 100% comfortable.
In quite a few designs people want to ride a Curvy route, but for the way out and return prefer Fastest. With only one profile actually available needs a lot of adjusting Shaping Points for that. Not optimal.
Garmin with profile “FasterTime”.
If you don’t want to swab back and forth and keep leaving the original Curvig design, you have to place many corrective Shaping Points.
@ devemux…future idea (pre)planning ? Let’s pause. Is just free text.
Beta app. Shaping point support by gpx export import transfers is simple and 100% reliable.
Please, don’t missunderstand, but that for me seems perhaps to be a problem.
From this point there seems to be a missunderstanding:
That’s your interpretation. Speaking (and understanding) in “Kurviger” Shaping Points for the routing have the same or similar priority, Speaking (and understanding) in “Kurviger” at navigation the “lower priority” of Shaping Points is, that there are no instructions at or to Shaping Points. That may be a difference to similar software, but for some users on their tours this is a big advantage from “Kurviger” to other software.
PS: I’m not native speaking english. Therefore sometimes are missunderstandings in reading and writing english. Yes, for me that’s a problem.
Nice discussion.
I forgot, but when adding routing next section profiles, one should also add the source routing machine these correspond too, right ? I added the source router machine here.
Update change: I add this info into the free “src” element. The Source element is probably the most logical one to use.
If exported or shared as gpx file at a reimport allows reconstruction into Kurviger.
Similar to actual Beta, the now succesfull reimportation of exported Shaping Points.
However if both of you do not find this usefull, no problem. Just is a suggestion.
You are the boss. Anyway Priority: “Low”
Hi Walter. Not speaking Kurvigs I mean the technical file format not the Kurviger “spirit”.
Priority misunderstanding ? I am no Native English speaker too.
So instead of “lower priority” more optimal expression would be “discrete”
Language barrier(s) sometimes is a hurdle to take I am also confronted with.
Pse write German, I do read, no machine translate, no issue.
Priority With regard to the (re) routing, Shaping and Via are both technically completely equivalent in Kurviger. (At Garmin there is a small technical difference). But there is the difference in use. You pass a shaping completely discreetly. A Via demands attention with a visual or audio message. It can be a stop invitation or not
I fully agree if you use the Kurviger app for navigation.
But if you use Kurviger (app or website) for route planning and a navigation device (Garmin, TomTom, …) for navigation, storing all information about the waypoints (start, destination, via points and shaping points) and route calculation options and import them also when reading a GPX would improve the useability: You have to export the GPX anyway to import it in your navigation device, but if full information is saved in GPX there is no need to save an additional .Kurviger file for later use in Kurviger.
Remark: Of course, a new calculation later on might lead to an different result due to changed OSM data - but I do also a recalculation of .Kurviger files if I use them later (e.g. in the next year).
You should always save .kurviger offline files for using within the Kurviger universe (app + website).
If you want to use website with 3rd-party devices, then this discussion has meaning for the website.
App’s purpose is different. You can use the website with your mobile to plan and export route files.
For easier maintenance, it’s better keep in app only its 2 offline formats: Kurviger + (original) GPX.
Emux, simple, if you don’t want it then so it be. Again you are the boss.
I respect the app. I notice a nice virtually bug free app, there are worse ones.
@boldtrn can decide for the website.
I develop / decide for the application.
I respect that some don’t use the app and prefer to use the website with 3rd-party devices.
They can continue using the website on their phones to plan and export 3rd-party formats.
But I cannot complicate app development to support them, maintenance should be simple.
App’s priority / development should be on users who use the app for routing + navigation.
