4 ms·

Adding flight data to it should be no problem as well. Then map it over period of time to see highs and lows :)

by solidr53 10y ago

knz 10y ago
"No problem"! You underestimate the volume of data (tens of thousands of points per flight) and time needed for temporal spatial analysis. I routinely run spatial analysis queries on a 400NM buffer around a large US airport and have spent many hours improving the efficiency of the queries due to the long run times on the largest RDS instances available. Running it for the entire national air space would be a significant project. Edit: I pulled one random day of data - using the data source with the least frequent reporting period (ATC Center - one point every 12s) there were ~ 600,000 data points for one day of operations that arrived or departed from our facility (overflights or GA to smaller airports are easily another 15%. This is also clipped at a 400NM radius). Annualized that would ~220 million data points. If you are looking at ground noise then you would probably want to merge in the approach radar data which is approximately one point every 3 seconds for a ~60NM radius. We often run multiple years at a time. It might not be "big data" by the standards of some on HN but it's significant for many GIS shops!
- deleted 10y ago
  [deleted]
- revelation 10y ago
  Most flight trajectories can be described with perfectly fine accuracy by a low number of consecutive line segments. But yeah, storing raw radar points in some RDS is going to slow you right down. I wouldn't put signal sample data into Postgres either.
  - knz 10y ago
    We simplify the tracks as much as possible (and convert to a geometry rather than store as raw data) but once you are in the terminal area there is a lot of value in retaining the full data set - especially when you start analyzing things like RNAV/PBN procedures or mapping noise contours.

4 ms·

Adding flight data to it should be no problem as well. Then map it over period of time to see highs and lows :)

by solidr53 10y ago

Adding flight data to it should be no problem as well. Then map it over period of time to see highs and lows :)

knz 10y ago
"No problem"! You underestimate the volume of data (tens of thousands of points per flight) and time needed for temporal spatial analysis. I routinely run spatial analysis queries on a 400NM buffer around a large US airport and have spent many hours improving the efficiency of the queries due to the long run times on the largest RDS instances available. Running it for the entire national air space would be a significant project. Edit: I pulled one random day of data - using the data source with the least frequent reporting period (ATC Center - one point every 12s) there were ~ 600,000 data points for one day of operations that arrived or departed from our facility (overflights or GA to smaller airports are easily another 15%. This is also clipped at a 400NM radius). Annualized that would ~220 million data points. If you are looking at ground noise then you would probably want to merge in the approach radar data which is approximately one point every 3 seconds for a ~60NM radius. We often run multiple years at a time. It might not be "big data" by the standards of some on HN but it's significant for many GIS shops!
- deleted 10y ago
  [deleted]
- revelation 10y ago
  Most flight trajectories can be described with perfectly fine accuracy by a low number of consecutive line segments. But yeah, storing raw radar points in some RDS is going to slow you right down. I wouldn't put signal sample data into Postgres either.
  - knz 10y ago
    We simplify the tracks as much as possible (and convert to a geometry rather than store as raw data) but once you are in the terminal area there is a lot of value in retaining the full data set - especially when you start analyzing things like RNAV/PBN procedures or mapping noise contours.