Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elevation profile for route information view #79

Closed
dittaeva opened this issue Aug 8, 2012 · 5 comments
Closed

Elevation profile for route information view #79

dittaeva opened this issue Aug 8, 2012 · 5 comments
Assignees

Comments

@dittaeva
Copy link
Collaborator

dittaeva commented Aug 8, 2012

I first listed this on WNRI#26, but now that I'm discussing it with a potential developer I realised that I should consult with you to find the best way to go about this (or if you even would want it included in WT).

Elevation profiles can be very useful for the user, but there are a couple of problems with making elevation profiles for route relations:

  1. Current relation mapping practices do not provide for a way to specify start and goal of the route (this could be solved on OSM by starting to give segments or points the role of "start" and goal"), and thus it is not always clear where the route begins and ends (if it is meaningful to have a beginning and end).
  2. Routes do not necessarily cover one continuous stretch, but could have arms and segregated segments (using the "link" role could be a solution on OSM).
  3. The length of routes varies a lot. Does it make sense to make route profiles for international and national routes, routes over 500 km or under 500 m, or for a whole super-relation?
  4. Routes can go through tunnels and on structures elevated or under the "ground" as seen by a Digital Elevation Model (DEM).

For number 1 I suppose one could either use the edge segment that is listed first, or the edge segment that has the lowest elevation (assuming that most routes start low and go high). One could also give the user a choice to turn the profile around if he thinks the direction is wrong.

Number 2: Incontinuous stretches could be marked in the profile itself with a standard gap or vertical line (voids in the DEM would also need to be marked), and for both arms and gaps an interactive display where the pointer on the profile would follow a marker on the route on the map could be useful. See example on lommekjent.no (elevation profile in lower right corner).

For number 3, I think it probably does make sense to make elevation profiles for really long routes. If you are going to spend half a year hiking or cycling it would be nice to see that you'll have some really long and flat stretches (the Netherlands and Denmark) and some really hilly ones (alps). If it makes sense to make elevation profiles for shorter routes mostly depends on the resolution and accuracy of the digital elevation model used to make it. With a resolution of SRTM the resolution is 90 meters (outside the US) and it could be misleading to generate profiles for routes below 300 meters, and in any case it probably doesn't make much sense to generate route profiles for routes that short(?).

Existing solutions that make elevation profiles for OSM data:

  1. Relation Analyzer (source): Makes really nice profiles from relations and SRTM data, outputting to a canvas image.
  2. CycleStreets (dev. info): Makes elevation profiles from route defined by user. Not yet open source. Takes into account tunnel=*
  3. Pistes Nordiques (source): Makes elevation profiles from route defined by user using SRTM data.

There are three GDEM's that could be used:

  1. ASTER: Covers almost the whole world with high 30 metres resolution, but there are still some issues with anomalies and voids. Used successfully by turkompisen.no. Limits on distribution of original data, no limits on use and distribution on derived data that cannot be converted back to original data.
  2. SRTM: High quality 90 metres resolution, but limited to between 60 deg. north and 58 deg. south. Original dataset from NASA public domain, but void-filled version from CGIAR-CSI has restrictions on commercial use. Yves has used SRTM for his solution (now on Github).
  3. GMTED2010: Only one with worldwide coverage, good accuracy and quality, but best resolution is 7.5 arc-seconds (~232 m). Should be public domain. Suitable for routes of several km, but not good for sub-1 km routes.
@jschleic
Copy link
Contributor

jschleic commented Aug 8, 2012

Do you know the OSM Relation Analyzer? They show a height map, if the route is connected (example). For unconnected routes it seems as if only the first segment is shown in the height map. Probably they are using SRTM data (see RA at github)...

By the way: What about adding a link to RA iside the route view of WT (e.g. near zoom and GPX button)? Connectivity would be especially intersting for OSM Mappers...

@dittaeva
Copy link
Collaborator Author

dittaeva commented Aug 9, 2012

While browsing your github profile I did look at RA, but since I looked at a route here north of SRTM data I didn't see any elevation profile (grundid/relation-analyzer#2). It does look pretty cool though, using the HTML5 canvas tag and all.

I've addressed your suggestion to add RA in issue #80.

@dittaeva
Copy link
Collaborator Author

I have hired @esisa to start on this based on ASTER data. Here's a screenshot from him. He's made a branch on WNRI/route.is.

@dittaeva
Copy link
Collaborator Author

dittaeva commented Sep 3, 2012

@esisa has now generated DEM data for the whole of Norway that you can get on request and test with the profile branch on WNRI/route.is (I have also added a section to the install wiki about what needs to be installed). We probably wont do more with raster data, but will rather move on to a vector version. At the moment only straight routes are rendered, so routes with branches or unconnected segments do not render.

@dittaeva
Copy link
Collaborator Author

Pull request for this in #96.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants