Website: Export routing profiles

[0709]

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.

Find in attachment demo gpx.
All_in_one_segment_profiles.gpx (5.4 KB)

[boldtrn]

@0709

Anyway is it possible to transfer the router segment profiles by using basic gpx only ?

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?

[0709]

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.

[boldtrn]

Sorry, my reply was a bit rash.

@0709

Did I suggest different symbols ?

No, but that is one of the major benefits of exporting shaping points in GPX. Reimporting it correctly into kurviger is the other.

If we are just talking about re importing there is probably some way we can make this work.

Maybe even changing the type to “shaping:curvy”.

[devemux86]

@boldtrn

I am wondering, why?

Indeed, why?

@boldtrn

If no other app can use this information?

Kurviger profiles only work within Kurviger.

And multiple routing profiles have not yet been implemented.

[0709]

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.

[WalterG]

@0709

I do not speak “Kurvigs”

Please, don’t missunderstand, but that for me seems perhaps to be a problem.

From this point there seems to be a missunderstanding:

@0709

The lower priority Shaping Points only adjust a path that is not optimally calculated.

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.

[0709]

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.

[devemux86]

We first need a valid reason for customizing GPX with Kurviger proprietary features.

What is the real use, since Kurviger features can only be used in Kurviger universe?

There is already the Kurviger format to cover offline and more efficiently that need.

[0709]

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”

[0709]

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

[devemux86]

@0709

Similar to actual Beta, the now succesfull reimportation of exported Shaping Points.

We added (unofficially) shaping points in GPX mainly for 3rd party devices / apps.

@0709

If exported or shared as gpx file at a reimport allows reconstruction into Kurviger.

No need to use 3rd party formats with Kurviger, use the Kurviger format, it’s offline!

[rumbrummer]

@devemux86

We first need a valid reason for customizing GPX with Kurviger proprietary features.

What is the real use, since Kurviger features can only be used in Kurviger universe?

There is already the Kurviger format to cover offline and more efficiently that need.

@devemux86

No need to use 3rd party formats with Kurviger, use the Kurviger format, it’s offline!

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).

[devemux86]

@rumbrummer

there is no need to save an additional .Kurviger file for later use in Kurviger

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.

[0709]

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.

[devemux86]

@0709

if you don’t want it then so it be. Again you are the boss.

@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.

[boldtrn]

@devemux86

@boldtrn can decide for the website.

Adding this to the GPX type should not hurt. The reimport aspect makes sense. So it could be something like:

<type>[WAYPOINT-TYPE]:[ROUTING-PROFILE]</type>.

3rd partys don’t support this anyway, but many people still prefer to use GPX, so this can help in this situations.

[devemux86]

@boldtrn

Adding this to the GPX type should not hurt.

Perhaps for the website, you can try it.

@boldtrn

The reimport aspect makes sense.

App will not support custom imports, only its own offline kurviger format and the official GPX schema.

To manage better our resources, it’s better to allow app export only for offline Kurviger + GPX formats.

App: Export 3rd party (online) formats deprecation

Focus on app’s main purpose: Kurviger routing + navigation. Export of kurviger and gpx should be done offline in the app. Support of 3rd party devices can be handled by the website. (it is a conflict of interest within the application)