OTP should support NED

[novalis]

OTP needs to be able to load National Elevation Dataset and use it to assign elevation data to edges representing streets. This is useful for calculating optimal walking and especially bicycling paths.

[novalis]

Just got a message from David saying he's working on this and will email something to the list in the next few days.

--nicholasbs

[novalis]

--nicholasbs

[novalis]

See r198 and r199

--nicholasbs

[novalis]

--nicholasbs

[novalis]

David, were you planning on adding this NED annotation to the OSM and Shapefile loaders, or should we reassign or deassign the ticket? This is not to rush you -- just to help us figure out what to work on.

--novalis

[novalis]

--novalis

[novalis]

Sure, I'll take a look at that. Can you point me to where the OSM and Shapefile loaders are in the trunk?

--demory

[novalis]

They're under here:

http://opentripplanner.org/browser/trunk/opentripplanner-graph-builder/src/main/java/org/opentripplanner/graph_builder

--novalis

[novalis]

Just wanted to check in on the status here. Think you'll have a chance to look at this sometime in the near future or are you completely swamped with other work?

--nicholasbs

[novalis]

Sorry for taking so long to get back to this. I've had some time lately to get caught up with the project and am now actively working on code for this ticket. But since I've been out of of loop for a little while, let me make sure this approach sounds OK..

I have started writing a GraphBulder implementation that will read NED data and apply it to a graph. This will be a standalone builder that will be run following the construction of the graph by one of the existing builders (OSM, Shapefile, etc).

I will also need to modify the graph structure to include an elevation profile for each applicable link. One question is where/how the elevation data would be stored. My initial thought is in the Street class, alongside the geometry field, probably as a PackedCoordinateSequence of (x,y) elevation samples where x is the distance along the edge and y is the elevation. The sampling frequency will be determined by the resolution of the specific NED data being read; this will be specified as an input parameter to the NEDGraphBuilder. Regarding storing the elev data in the Street class -- does this make sense, or is it possible we might want to support elevation for other link types in the future?

Also, once the GraphBuilder and Graph modifications are finished, the next step will be to modify the TripPlan/Itinerary/Leg structure to include elevation data and incorporate a visual elevation display of some kind into the webapp (i.e. something similar to the elevation display functionality of bike-trip planning on atltransit.com). Does that fall under this ticket or is it considered a separate task?

--demory

[novalis]

Your approach sounds good. There are separate tickets for both the visual display (#41) and the API changes (#67).

--novalis

[novalis]

This sounds good to me as well.

--nicholasbs

[novalis]

--demory

[novalis]

Discussed this on the call. Sounds like it's just about ready to go. David is going to check it into trunk shortly.

--nicholasbs

[novalis]

I am now working on writing a NED downloader, but it is going slowly because the USGS's web service is both misdesigned and cranky.

--novalis

[novalis]

NED downloader done. Should we mark this complete, and just leave #41 and #67 for the rest? Or is there more to do here?

--novalis

[novalis]

At current we have a builder which can automatically download NED and attach it to streets, correct? I think we should close this ticket (as you guys have finished coding what's described in the ticket description), and create a new one for routing on elevation data.

Sound good?

--nicholasbs

[novalis]

Sure, I'll close it, but we're already routing on the elevation data, so no need for a new ticket.

--novalis

[novalis]

oops, I am dumb -- I missed a bit of this and will fill it in now.

--novalis

[novalis]

OK, have finished but have errors.

--novalis