Kurviger.de | Application | Blog | Frequently Asked Questions (FAQ) | Legal Notice | Privacy Policy

Website: Export and waypoint names

I checked the GPX file I imported with a text editor: The waypoints there don’t have names but only coordinates. So my suggestion to the website would be: Use numbers as default names when importing nameless points from GPX.

Everyone it’s important to understand that if GPX waypoints or route points have filled their name tag, then those are considered as waypoint names during import process.

And during export those GPX waypoints and route points must have their name tags empty by the routers, if users have not explicitly named them.

1 Like

No, they only contain “lat” and “lon”, nothing else. So no name.

Can you attach the gpx file?

Bad Urach.gpx (6.0 KB)

That GPX does not contain any “name” tags in waypoints or route points.

When import it with latest version, waypoints are numbered as expected.

That’s what I said. But when you import this GPX into the kurviger website, it sets the coordinates as the name of each point.

If the points from a GPX have no names, I would find it clearer to have numbers instead of the coordinates in the name field. Or leave the name empty.

1 Like

I have experimented a bit with your “Bad Urach” route

  • Import your route into website
  • export it as *.gpx
  • export it as *.kurviger
  • import it into the app

You are right.
Although your original route doesn’t contain any names, the website adds different waypoint names
depending on the export-format.
The worst is *.kurviger, where it adds the coordinates as names into the file.

Edit:
Until this is fixed, you can mitigate this effect in the app by changing all WP into shaping points and afterwords change only your interesting WP into via points and give them proper names.

2 Likes

The website is adding the content of the waypoint input as name.

So if there are coordinates, coordinates are put in the file. If there are names from geocoding results for example, they are put in there.

This behavior makes sense, because the website will show the same content in the input boxes that you had when planning the route.

It’s a bit unfortunate that this seems incompatible with the app now. I can check if the website could not set the name property, if there are only coordinates set in the waypoint list. But this won’t change the existing .kurviger files.

That’s acceptable and happens also in app if create via points from search results.

But users didn’t set coordinates as names, website can still retrieve them from gpx.
Also kurviger & gpx website exports have different incompatible names in waypoints.

In my opinion the best solution would be a design change on the website by using the existing waypoint fields to input a name (with the current number of the waypoint set as default as long as the user didn’t choose a name) and by having a single separate input field to perform an adress or location search. This even would somehow be more intuitive (I always had problems with those waypoint/search fields).

2 Likes

Something like this could be done when adding waypoint names to the website. I am not yet 100% sure how this could look. Please feel free to share your ideas in the corresponding thread.

Here I am really unsure. Most route planners work exactly like Kurviger in this regard, like GMaps, Here, Bing Maps, Adac Maps, Falk, the examples are countless. So I think it is intuitive that the Kurviger website works like that as well.

I think that the website works correct in saving the contents of the input fields and restores them when loading a .kurviger file, that’s a benefit of using .kurviger files. It’s a bit unfortunate that this breaks the app compatibility, since this feature exists for years on the website all previously generated .kurviger files have these incompatibility issues. As mentioned previously I will see how I can work around this issue to restore app compatibility, so once that is done users would have to reimport their generated .kurviger files and export them again.

That would be OK. :+1:

So it seems the website decides and sets custom names in kurviger and gpx files.
I didn’t know that, as waypoint names were not implemented in both platforms yet.
Anyway those names are not set by users, but serve other needs like for UI fields.

Not sure what you are referring to? Nothing has changed on the website regarding the export formats or the content of the name tags in GPX. Not for the .kurviger format and not for .gpx.

That’s all existing behavior.

It’s already explained that while not supporting waypoint names:

  • Kurviger files contain coordinate numbers in waypoint names
  • GPX files contain turn instructions in waypoint & route points

Both are not custom names explicitly set by the users.

That cannot be an excuse if something does not work correctly or else we should drop future updates.

That’s often the case and that’s not limited to the Kurviger website. GPX Names have no guarantee to be set explicitly by the user. Many systems will name waypoints numerically like “Waypoint 1” or use any other name, like geocoding results, coordinates, some internal naming etc.

So far, user defined names are not available on the website, therefore the websites uses best guess names, like the name of the road, if that’s available, which is better than not providing any name. Having the name of the road can help to identify the correct waypoint in waypoint lists for example.

That’s currently the intended behavior and was agreed on with several users years ago when testing the transfer of routes to different navi devices.

When user defined waypoint names will be available, these should be obviously used instead.

1 Like

I updated the website, so for points that only contain coordinates in the input field, no name is exported in the .kurviger file.

4 Likes

Wouldn’t it be a good idea to define them as shaping points as well?

The lack of name does not mean necessarily a shaping point.
Via points can be unnamed too until users select their names.

Waypoint names or types in website are not implemented yet: