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

height data #271

Closed
emiltin opened this Issue May 22, 2012 · 19 comments

Comments

Projects
None yet
5 participants
@emiltin
Contributor

emiltin commented May 22, 2012

avoiding hill can be important to bicycles.

we have a height model of copenhagen, based on a 2x2 meter grid. the current format is ArcInfo Binary Grid. what format would be needed if osrm was to use it?

i suppose the data would have to somehow be combined with the NASA data that covers outside copenhagen.

@DennisOSRM

This comment has been minimized.

Show comment
Hide comment
@DennisOSRM

DennisOSRM May 29, 2012

Contributor

As a reminder: The format is specified here: http://home.gdal.org/projects/aigrid/aigrid_format.html

Should be possible to write a parser for the data

Contributor

DennisOSRM commented May 29, 2012

As a reminder: The format is specified here: http://home.gdal.org/projects/aigrid/aigrid_format.html

Should be possible to write a parser for the data

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Jul 23, 2012

I would suggest to split out the elevation model stuff into a seperate service. The scriptable importer (#1) should then sample the osm input polylines and allow to calculate cost based on elevation. Elevation should also be stored in the geometry and available on output to be able to print elevation profiles. Ideally the output would be 4D (lat, long, z, distance from start).

What do you think?

karme commented Jul 23, 2012

I would suggest to split out the elevation model stuff into a seperate service. The scriptable importer (#1) should then sample the osm input polylines and allow to calculate cost based on elevation. Elevation should also be stored in the geometry and available on output to be able to print elevation profiles. Ideally the output would be 4D (lat, long, z, distance from start).

What do you think?

@emiltin

This comment has been minimized.

Show comment
Hide comment
@emiltin

emiltin Jul 23, 2012

Contributor

sounds reasonable :-) the parser should have access to various external data, such as height model, traffic counts, noise data, roadwork, etc, which can be sampled geographically.

Contributor

emiltin commented Jul 23, 2012

sounds reasonable :-) the parser should have access to various external data, such as height model, traffic counts, noise data, roadwork, etc, which can be sampled geographically.

@DennisOSRM

This comment has been minimized.

Show comment
Hide comment
@DennisOSRM

DennisOSRM Jul 23, 2012

Contributor

@karme yes, that's the idea captured by the number of different issues on the subject.

@emiltin the lua module will be able to connect to different data sources to collect more information

Contributor

DennisOSRM commented Jul 23, 2012

@karme yes, that's the idea captured by the number of different issues on the subject.

@emiltin the lua module will be able to connect to different data sources to collect more information

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 13, 2012

example lua speed function depending on elevation:

karme@c374bd3

karme commented Nov 13, 2012

example lua speed function depending on elevation:

karme@c374bd3

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 13, 2012

ideally the lua importer would have a callback for each edge (not way) passing in the edge geometry

karme commented Nov 13, 2012

ideally the lua importer would have a callback for each edge (not way) passing in the edge geometry

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 13, 2012

another thing to keep in mind: start/end-point might split a edge in such a way that the assumption of having constant speed / evenly distributed weight on the edge might be horribly wrong (in mountainous areas)

karme commented Nov 13, 2012

another thing to keep in mind: start/end-point might split a edge in such a way that the assumption of having constant speed / evenly distributed weight on the edge might be horribly wrong (in mountainous areas)

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 13, 2012

last point: ideally the heights (any maybe also the distances 4d/instead of 2d points) are stored and readily available in routing result output (for interactive elevation profiles)

karme commented Nov 13, 2012

last point: ideally the heights (any maybe also the distances 4d/instead of 2d points) are stored and readily available in routing result output (for interactive elevation profiles)

karme pushed a commit to karme/Project-OSRM that referenced this issue Nov 14, 2012

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 15, 2012

estimate of required speedup: * 1000

karme commented Nov 15, 2012

estimate of required speedup: * 1000

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 15, 2012

before going down that road any further, i would like to have some feedback. What dou you think about adding lua segment callback?

karme commented Nov 15, 2012

before going down that road any further, i would like to have some feedback. What dou you think about adding lua segment callback?

@DennisOSRM

This comment has been minimized.

Show comment
Hide comment
@DennisOSRM

DennisOSRM Nov 19, 2012

Contributor

I had a brief look. Your approach looks feasible. But most time is spent in overhead to the http calls.

Am 15.11.2012 um 11:06 schrieb karme notifications@github.com:

before going down that road any further, i would like to have some feedback. What dou you think about adding lua segment callback?


Reply to this email directly or view it on GitHub.

Contributor

DennisOSRM commented Nov 19, 2012

I had a brief look. Your approach looks feasible. But most time is spent in overhead to the http calls.

Am 15.11.2012 um 11:06 schrieb karme notifications@github.com:

before going down that road any further, i would like to have some feedback. What dou you think about adding lua segment callback?


Reply to this email directly or view it on GitHub.

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Nov 22, 2012

Project OSRM notifications@github.com writes:

I had a brief look. Your approach looks feasible. But most time is
spent in overhead to the http calls.

yes performance is obviously a problem.

But I am more worried about the ugliness that is waiting there:

  • each line segment is duplicated (forward/backward direction)!
  • segment callback will likely need information that is only available
    in the node/way callbacks
  • the classification logic will be split into 2 parts (each having a
    different set of information)

some thoughts on this:

Maybe it really would be better to drop the graph edge = line segment
approach and instead preprocess the osm data to a graph where nodes are
"real" nodes and ways are splitted into edges (of poylines or maybe some
curve in the future?) if necessary (crossing ways, T-junctions)?

Ideally in that step also relation information would be de-normalized
onto the edges. Then a edge callback would be enough and would have all
information needed. (and could be run in parallel easily)

Another point is about debugging the classification process. Ideally the
pre-processing result could be processed using "standard osm tools".
=> osm output with an additional key for the edge weight.

Extra bonus: pre-processing would support incremental updates (as long
as the classifaction function(s) don't change)

Any experiences with imposm? does it provide something like that?

Other comments / suggestions / ideas?

Greetings,
karme

karme commented Nov 22, 2012

Project OSRM notifications@github.com writes:

I had a brief look. Your approach looks feasible. But most time is
spent in overhead to the http calls.

yes performance is obviously a problem.

But I am more worried about the ugliness that is waiting there:

  • each line segment is duplicated (forward/backward direction)!
  • segment callback will likely need information that is only available
    in the node/way callbacks
  • the classification logic will be split into 2 parts (each having a
    different set of information)

some thoughts on this:

Maybe it really would be better to drop the graph edge = line segment
approach and instead preprocess the osm data to a graph where nodes are
"real" nodes and ways are splitted into edges (of poylines or maybe some
curve in the future?) if necessary (crossing ways, T-junctions)?

Ideally in that step also relation information would be de-normalized
onto the edges. Then a edge callback would be enough and would have all
information needed. (and could be run in parallel easily)

Another point is about debugging the classification process. Ideally the
pre-processing result could be processed using "standard osm tools".
=> osm output with an additional key for the edge weight.

Extra bonus: pre-processing would support incremental updates (as long
as the classifaction function(s) don't change)

Any experiences with imposm? does it provide something like that?

Other comments / suggestions / ideas?

Greetings,
karme

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Dec 7, 2012

no comments?

did some optimizations:

  • improved speed of the elevation profile code
  • after that http overhead was really a problem (~66%) => replaced with simple text based tcp protocol

in the end i got a speedup of around 10

karme commented Dec 7, 2012

no comments?

did some optimizations:

  • improved speed of the elevation profile code
  • after that http overhead was really a problem (~66%) => replaced with simple text based tcp protocol

in the end i got a speedup of around 10

@karme

This comment has been minimized.

Show comment
Hide comment
@karme

karme Dec 20, 2012

test
Not the best example but ok.

blue line: connecting start and end point
yellow line: bike without heights
red line: bike with heights.

karme commented Dec 20, 2012

test
Not the best example but ok.

blue line: connecting start and end point
yellow line: bike without heights
red line: bike with heights.

karme pushed a commit to karme/Project-OSRM that referenced this issue Dec 20, 2012

@emiltin

This comment has been minimized.

Show comment
Hide comment
@emiltin

emiltin Dec 20, 2012

Contributor

right, taking elevation into account makes a lot of sense if you're biking in mountains :-)

Contributor

emiltin commented Dec 20, 2012

right, taking elevation into account makes a lot of sense if you're biking in mountains :-)

karme pushed a commit to karme/Project-OSRM that referenced this issue Jan 21, 2013

karme pushed a commit to karme/Project-OSRM that referenced this issue Mar 5, 2013

karme pushed a commit to karme/Project-OSRM that referenced this issue Mar 5, 2013

@perliedman

This comment has been minimized.

Show comment
Hide comment
@perliedman

perliedman Apr 14, 2015

For anyone else finding this issue, like I did, I wrote up how I added elevation for bike routing in OSRM: http://www.liedman.net/2015/04/13/add-elevation-data-to-osrm/

Parts heavily inspired from what I read in this issue and others.

Note: there are probably lots of other/better ways to do this, but this works fairly well for me so far.

perliedman commented Apr 14, 2015

For anyone else finding this issue, like I did, I wrote up how I added elevation for bike routing in OSRM: http://www.liedman.net/2015/04/13/add-elevation-data-to-osrm/

Parts heavily inspired from what I read in this issue and others.

Note: there are probably lots of other/better ways to do this, but this works fairly well for me so far.

@emiltin

This comment has been minimized.

Show comment
Hide comment
@emiltin

emiltin Apr 14, 2015

Contributor

nice work per!
you write you only considers ways with highway=*. are you also handling other tag combinations that indicate that you can cycle? from bicycle.lua:

  -- initial routability check, filters out buildings, boundaries, etc
  local highway = way:get_value_by_key("highway")
  local route = way:get_value_by_key("route")
  local man_made = way:get_value_by_key("man_made")
  local railway = way:get_value_by_key("railway")
  local amenity = way:get_value_by_key("amenity")
  local public_transport = way:get_value_by_key("public_transport")
  if (not highway or highway == '') and
  (not route or route == '') and
  (not railway or railway=='') and
  (not amenity or amenity=='') and
  (not man_made or man_made=='') and
  (not public_transport or public_transport=='')
  then
    return
  end
Contributor

emiltin commented Apr 14, 2015

nice work per!
you write you only considers ways with highway=*. are you also handling other tag combinations that indicate that you can cycle? from bicycle.lua:

  -- initial routability check, filters out buildings, boundaries, etc
  local highway = way:get_value_by_key("highway")
  local route = way:get_value_by_key("route")
  local man_made = way:get_value_by_key("man_made")
  local railway = way:get_value_by_key("railway")
  local amenity = way:get_value_by_key("amenity")
  local public_transport = way:get_value_by_key("public_transport")
  if (not highway or highway == '') and
  (not route or route == '') and
  (not railway or railway=='') and
  (not amenity or amenity=='') and
  (not man_made or man_made=='') and
  (not public_transport or public_transport=='')
  then
    return
  end
@perliedman

This comment has been minimized.

Show comment
Hide comment
@perliedman

perliedman Apr 14, 2015

@emiltin that's an interesting question. Currently, I only do calculations for highway.

My guess is that railway and public_transport should not be affected by elevation, but perhaps the other ones?

perliedman commented Apr 14, 2015

@emiltin that's an interesting question. Currently, I only do calculations for highway.

My guess is that railway and public_transport should not be affected by elevation, but perhaps the other ones?

@TheMarex

This comment has been minimized.

Show comment
Hide comment
@TheMarex

TheMarex Sep 13, 2015

Member

Support for raster data has landed in develop.

Member

TheMarex commented Sep 13, 2015

Support for raster data has landed in develop.

@TheMarex TheMarex closed this Sep 13, 2015

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