elevation: cliffs at director park

[abyrd]

For this bike trip through downtown Portland, the obvious thing to do is ride down the edge of the park blocks, both for safety and speed.

http://maps5.trimet.org/opentripplanner-webapp/index.html?submit&fromPlace=45.513934866581,-122.68516861908&toPlace=45.52542122653,-122.67922534945&mode=BICYCLE&min=TRIANGLE&triangleTimeFactor=0.5016501650165017&triangleSlopeFactor=0&triangleSafetyFactor=0.4983498349834983&maxWalkDistance=840&time=4:44%20pm&date=11/10/2011&arr=Depart&itinID=1

If you put "flattest" into the mix, you get a crazy path. Looking at the elevation profile of the fastest path, you can see that this is caused by a 50-foot deep hole right where director park is. Looking at NED data on http://seamless.usgs.gov/website/seamless/viewer.htm I see that the hole is actually in the original data.

This park is recent, and has a parking garage under it. I wonder if this is the hole they dug when constructing the parking garage.

[abyrd]

It would be nice to have a tool to visualize elevation data in the graph (2.5D / 3D) and adjust or smooth out artifacts by hand. You would have to somehow save the changes (to the original elevation data or to the graph edges?) so they would not be lost the next time you build a graph.

I suppose we could do some image processing on the NED data to pick out edges steeper than streets can be, and maybe geometric shapes, and flag them for smoothing.

[pdxmele]

Yes, they certainly did dig a great big hole before putting in the park. It would be great to be able to spot these kinds of things visually and fix them... I'm sure there are things like this hiding out all over the NED.

[mattwigway]

You could use an edge detection kernel or a slope analysis function in a GIS to find them.

[abyrd]

That's what I was thinking, but other than the occasional enormous temporary hole in the ground, we may not want to doctor the source elevation data, since many drop-offs are intentional parts of road infrastructure.

For example, here is a similar issue caused by the 405 trench:

http://maps5.trimet.org/opentripplanner-webapp/index.html?submit&fromPlace=45.523567566736,-122.68844475533&toPlace=45.523680517498,-122.68277076057&mode=BICYCLE&min=TRIANGLE&triangleTimeFactor=0.32673267326732675&triangleSlopeFactor=0.3307376354130507&triangleSafetyFactor=0.3425296913196225&maxWalkDistance=840&time=4:44%20pm&date=11/10/2011&arr=Depart&itinID=1

In these two example cases, the problem is a road bridging over a hole. If we assume that the endpoints of edges (which are intersections) are at ground level (according to NED), I suppose we could low-pass-filter elevation change relative to a straight line between the endpoints.

In northeast Portland I can see a distinct rectangular grid of depressions where the streets are. Are the raised plateaus between the streets the treetops? I checked and fortunately the OSM data is well-aligned with the NED, so our streets do not cut across the tree-edges.

[mattwigway]

Perhaps reading OSM level=... tags is the solution to the 405 trench problem?

[abyrd]

OSM superimposed on NED for reference:

https://github.com/openplans/OpenTripPlanner/wiki/Elevation

[abyrd]

Yes, making use of level= will certainly help. But at the 405 trench there is some ambiguity as to what is the "natural or permanently changed surface level" as with NW Couch Street here http://g.co/maps/ekh8g which is (not really incorrectly) at level 0, with the underpass at -1, though the NED data there seems to indicate the tunnel level. Some kind of filtering would have to be applied around ways with level=1 as well.

[mattwigway]

Perhaps a combination of layer= and bridge= would help this issue.

See also this question.

[evansiroky]

@demory am I recalling correctly that you manually edited the NED data to fix this?

[abyrd]

Closing this as it's about a particular issue in Portland. We will want to keep an eye out for any strange elevation data in OTP2 though.