search

eldang / elevation_lookups

Takes an input file of paths described as series of points, outputs a file of data about the elevation changes along those paths.
Apache License 2.0
3 stars 2 forks source link

Comparing data sources for Seattle #12

Closed dabreegster closed 3 years ago

dabreegster commented 3 years ago

I'm going to do a qualitative comparison of the LIDAR and contour data for Montlake. (I haven't gotten SRTM to run in Docker yet, so I'll add that later.)

Performance: contour took 177s, lidar took 11s. Montlake is a tiny map, so contours being so slow is a notable limit. Of course parallelism will help.

Percent grade quick glance. Contours: Screenshot from 2021-03-23 17-22-46 LIDAR: Screenshot from 2021-03-23 17-22-55 Nothing jumps out as extremely different between these, so that's a good sign.

Looking at the climb from Boyer->Edgar->11th->Roanoke: Screenshot from 2021-03-23 17-25-03 Contour says 6.6%, 16.8%, 13.8% for those 3 roads Lidar says 5.7%, 17.9%, 13.6%. Quite similar, and it doesn't look like one is consistently guessing things are more or less steep than the other.

Both of them seem to mess up on the southbound lane of Montlake Blvd where it crosses over 520: Screenshot from 2021-03-23 17-28-34 The arrows point uphill. The more north bit is 30% grade in contour, only 17% in lidar. In reality this is pretty flat. I'm guessing this being a bridge is the problem.

Overall, I don't spot any major differences between the output of these, so I'm of course inclined to go with lidar for performance. It has a big upfront 2.5GB (compressed) download cost, compared to 230MB contours, but that's fine. And data quality looks great, except for the issue with bridges.

dabreegster commented 3 years ago

I don't have any layers hooked up to show absolute elevation, just percent incline. But glancing at a few examples (like Delmar), the elevation between the two seems to be within about 0.5 meters.

eldang commented 3 years ago

Cool!

The bridge is definitely a bridge issue, in that both data sources are reporting elevation for the ground below it. Or at least, I know that's the case for the contours and it would make sense for it to be the case for the LIDAR.

So far, the best idea I have for bridges is your suggestion about marking them as such and not making intermediate points along them. But you're right that that would miss a lot for the 520 bike lane (and I-90 too). I'm wondering if floating bridges are rare enough that we can get away with treating them as special cases for which you hard-code some stats?

dabreegster commented 3 years ago

Agreed that plan for bridges should work. Since they're tagged in OSM, I can remove all the intermediate points from the query. And for a few of the cases we care about, https://wiki.openstreetmap.org/wiki/Key:incline is an appropriate tag to manually add. I don't see many uses around Seattle, mostly for curb cuts: https://overpass-turbo.eu/s/15lM

dabreegster commented 3 years ago

Performance wise, the huge seattle map has 56,526 queries. I'm doing a run and reducing the resolution in the query from 1m to 5m, and this largest case finished in under 2 minutes -- quite acceptable from a perf standpoint. I'll see how the output looks; 1m was a pretty arbitrary first guess anyway.

dabreegster commented 3 years ago

Closing this issue. I'll probably still add a quick UI tool to compare values at each road and intersection and do some kind of color coding for higher/lower values. If I find anything interesting there, I'll open a new issue. And if the tool is easy enough to run, document it here.