search

opentripplanner / OpenTripPlanner

An open source multi-modal trip planner
http://www.opentripplanner.org
Other
2.21k stars 1.03k forks source link

Storage of elevation/biking data #1533

Closed abyrd closed 10 years ago

abyrd commented 10 years ago

Even when a graph is built with no elevation data, every street edge has a field reserved to point to an external ElevationProfile object.

  1. Bizarrely, PlainStreetEdge is a subclass of EdgeWithElevation and is its only subclass. Reversing this relationship would allow graphs to be much more compact when they don't contain elevation information.
  2. The elevation profiles could be stored in the same way as the geometries: directly in a value field in the edge rather than with a compound reference type, optionally using delta coding and variable width packing. @laurentg I suppose this item might interest you.

3a. The ElevationProfile objects contain no less than 5 double-precision floating point fields and two boolean fields to describe bicycling characteristics. First, I'm sure all of these can be made into narrow floats with no harm. The booleans could be moved to bits in the street edge bitfield.

3b. The "effective length" fields should probably be replaced with something else entirely. Apparently, the current system focuses on calculating danger/bikeability at graph build time and distorting the length of the edge. It seems completely reasonable to just store flags indicating presence of bike lane, protected bike lane, bad surface, etc on the street edge itself and calculating the weight on the fly during the search. It would just be a couple of conditionals and multiply operations, and it would allow you to modulate the relative preference for bike lanes and such much more effectively.

abyrd commented 10 years ago

Laurent has implemented much of this. The main thing that remains is to move the elevation data field into a subclass to get rid of the extra wasted pointer in graphs without elevation.