Feature Request: Surfaces & Waytypes

Issue #362 new
Jowan Dijkhuis created an issue

Not only in the trailrunning community but also in other sports the tracks surface and waytype is important. Trailrunners prefer sand, mud or dirt paths while a mountainbiker prefers unpaved, gravel and dirt roads. These surface types and waytypes are explained in Open Street Map's Key:surface and Key:highway. When building a track in QMapShack it would be very helpful to have this information. Komoot already uses this information and displays this in a side panel when you view or build a track. See photoScreen Shot 2018-07-12 at 12.54.51.png

Comments (12)

  1. kiozen

    Do not expect that anyone will pickup that topic any soon. Your best chance will be to implement it yourself.

    Anyway, a bit of information for anyone willing to spend time on this: This information is in the OSM database for sure. But right now none of the data formats read by QMapShack contains this information. These formats are:

    • Garmin IMG map
    • Routino routing database
    • BRouter routing database

    I might be wrong but to my knowledge none of these contains any information about the surface. Therefor this information has to be either read from the plain database, or from a map format not implemented yet. Alternatively you can try to talk the developers of BRouter or Routino into adding that information to their data formats and provide it along with the derived routes.

    If you can't come up with a feasible and practical solution for this problem, this request will make it into the long-term-never-solved collection of this tracker for sure.

  2. Jowan Dijkhuis reporter

    Thanks for the comment. I was aware of the fact that this is an OSM specific feature. Therefore maybe not the best place to do a feature request on this website. ;-)

  3. kiozen

    Funny enough I read a similar request in a German outdoor navigation forum just a few days ago. Did a service get out of business lately?

    Regarding the feature. It's not impossible but it takes a lot of motivation and time. My best bet would be to pimp up BRouter. This has been done in the past for the no-go areas in route calculation. However it was only realized because the developer wanting that feature changed BRouter source code and QMapShack source code and successfully placed pull request on both projects. It was a lot of effort for a feature hardly anyone will use. So you really have to be in need of such a feature to start implementing it.

  4. Jowan Dijkhuis reporter

    BRouter is indeed the way to go I guess. It supports routing profiles. From what I have seen so far is that you can customize your profile. This could be customized in such a way to have a trailrunning profile or an MTB profile to start with. The next step would be accessing the routing database for that route and do a query for the surface and waytypes. I will go to the BRouter forum and see what I can do. Thanks again Kiozen!

  5. kiozen

    And once this information is in the output of the derived route we can discuss a statistics in QMapShack. Maybe even BRouter can do the statistics and write it to the output.

    Edit: Ah, better write the pure stuff into along with the route. Better for routes drawn in QMapSack's edit mode segment by segment.

  6. Norbert Truchsess

    I wonder if it would make sense to implmement a QMS map-module to read BRouter-routing-data to be used as visible map in QMS. That would render installation of separate garmin-maps and DEM optional for offline use if you are satisfied with the information included - e.g. BRouter-routing-data currently does not include street-names or areas that are not streets. Including the available data along the way from the routing-database in the router-response also would make sense.

  7. Jowan Dijkhuis reporter

    Routing is about following roads and paths. Most of my gpx files are tracks. With lots of points not on a road or path. I don't think BRouter can extract this kind of information from OSM.

  8. kiozen

    For tracks you will need a track to route conversion. This is another one of the infamous long-term-never-solved issues ;)

    Regarding own vector map format that combines them all: The Garmin format does it already. It's a good approach for devices. But a bad one for an application like QMapShack. To have separate data for DEM, map and routing has several advantages:

    • All layers can be mixed with other ones. You can use routing and high quality DEM with every kind of map, not just the one it is linked to.
    • To keep the size of a combined file to a usable minimum you always have to make a compromise in quality. For some areas you can get 5x5m DEM data. This is too big to add to a combined file. The Garmin file format has only 24bit numbers to keep size low, etc.
    • In a combined file you are hardly able to update just one layer. You have to update the whole bunch. But DEM data is not subject to change. Having single layers is much easier.

    And you will need more than just roads. Topographic information will be the first thing to be requested. Guaranteed. The only reason to do it would be developing your own GPS application /device. I do not think that the Android market needs another navigation app. And there is no usable hardware available to start your own Garmin-Killer device.

  9. Norbert Truchsess

    Regarding usage of BRouter-data as map: Obviously it has drawbacks as it's just the roads with elevation and metadata. The advantage is that you don't need a separate DEM and garmin-map if you are satisfied with what it provides. And you can install it from the existing brouter-setup that you would use anyway when you intend to use local BRouter. @kiozen not that I request you to implement this - it's something I consider to implement myself ;-)

  10. Norbert Truchsess

    @Jowan Dijkhuis BRouter-data will not help in any way to add surface-information to recordet tracks. It only may provide that data to tracks that are a result of routing with that data.

  11. kiozen

    "@kiozen not that I request you to implement this - it's something I consider to implement myself ;-)"

    :D I never doubted that you see it that way

    But it will be a bit tricky to integrate it into the current layer structure. I did some thoughts on that when the first Gamrin OSM images with DEM data popped up. One would need to register the img with the maps as well as with DEM. Not very nice. Or you render elevation data on the map layer but in that case you can't take elevations from the map as this is a DEM layer thing. At the end I noticed that the DEM data will never have the quality of what's already available. That was the moment I abandoned this idea.

    Anyway, back to the topic. There seems to be some requirement to add information about the surface and type of a path. Imho that would kind of fit into the routing database. And with that information you can do a statistics at least with routes and tracks derived from BRouter. To add this information to a recorded track is still another beast to fight (Track -> Route conversion).

  12. Log in to comment