Timeline for Elevation data in a database (tens of billions of information)
Current License: CC BY-SA 3.0
14 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Oct 2, 2016 at 20:14 | history | edited | jobou | CC BY-SA 3.0 |
added 228 characters in body
|
Oct 2, 2016 at 20:12 | vote | accept | jobou | ||
Oct 2, 2016 at 19:19 | vote | accept | jobou | ||
Oct 2, 2016 at 20:12 | |||||
Oct 2, 2016 at 18:18 | answer | added | MickyT | timeline score: 3 | |
Oct 2, 2016 at 12:52 | comment | added | jobou | @MickyT : I look into this and this is a nice solution. It seems that postgis is really optimized for this kind of processing. Moreover with gdal installed, I can directly use raster2postgres command line tool to import the HGT data (elevation values). Each file will be a raster row in the table with one band storing the elevation data. I am going to do some benchmark with both solution before I select the final one. | |
Oct 2, 2016 at 10:23 | comment | added | MickyT | No, you should only have to load up 20,000 raster images, assuming that the files you have can be treated that way. I'll try and write up a better answer tomorrow | |
Oct 2, 2016 at 8:36 | comment | added | jobou | @MickyT : but it won't change the fact that I will have 28 billions records and not 20 thousands ? | |
Oct 1, 2016 at 21:13 | comment | added | MickyT | You may want to have a look at postgres with the postgis extension. It will store each of your raster tiles (20,000) and can be queried resonably simply with indexes. | |
Sep 30, 2016 at 18:40 | vote | accept | jobou | ||
Oct 2, 2016 at 19:19 | |||||
Sep 30, 2016 at 18:10 | history | edited | jobou | CC BY-SA 3.0 |
added 646 characters in body
|
Sep 30, 2016 at 15:04 | answer | added | paparazzo | timeline score: 1 | |
Sep 30, 2016 at 14:25 | history | edited | Paul White♦ | CC BY-SA 3.0 |
Formatting; tags
|
Sep 30, 2016 at 12:36 | review | First posts | |||
Sep 30, 2016 at 14:25 | |||||
Sep 30, 2016 at 12:30 | history | asked | jobou | CC BY-SA 3.0 |