BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//talks.staging.osgeo.org//foss4g-2022//talk//YJPU9S
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-foss4g-2022-YJPU9S@talks.staging.osgeo.org
DTSTART;TZID=CET:20220825T123000
DTEND;TZID=CET:20220825T130000
DESCRIPTION:I am working as the Technical Lead at Blue Sky Analytics\, a cl
 imate-tech startup empowering the world’s decision-makers with accurate\
 , real-time\, and standardized climate data. \n\nAll datasets that we are 
 building here at Blue Sky Analytics\, technically have one similarity - th
 ey all have a space and time component. We tried to build solutions like f
 illing empty values in inconsistent temporal data\, and dividing the data 
 in specified time period chunks for faster queries\, while these worked as
  POC\, they were not easy to scale up. Working with structured data was mu
 ch easier to understand\, working on postgres with the addition of timesca
 le and PostGIS gave us exactly what was needed. Building the solution at t
 he database level with the existing open-source technologies has been an e
 xhilarating experience. \n\nImagine a dataset with hourly frequency going 
 back years on a global level\, with frequent inconsistencies\, that not on
 ly you have to efficiently store but that should also be highly accessible
  in combination with other such datasets. If not for the open-source\, we 
 would not have been able to answer questions like:\n - How much have the l
 akes shrunk between the years 2010-2020 on a yearly basis?\n- Finding GHG 
 emissions from biomass burning of "*all US states\, for the last 10 years 
 on a monthly\, weekly\, daily basis***".**\nLeveraging other open source s
 olutions like h3-pg indexing also helped us to reduce the query time by an
  exponential factor for global level queries! \n\nWhile the database sound
 s pretty amazing\, another challenge was putting it all together and deplo
 ying it on the cloud\, which was a whole another challenge. The most intui
 tive solution was to deploy a bunch of Postgres instances. While it was no
 t so hard to implement the basics\, it became almost impossible to scale u
 p or down\, install rolling updates\, account for failures. \n\nKeeping up
  with the tech\, Kubernetes seemed like a great solution for building a hi
 gh availability cluster service\, and finding the postgres-operator (PGO) 
 by crunchydata was exactly what we needed. It combined all the right tools
  like pgBouncer\, pgBackRest\, and monitoring solution using grafana and P
 rometheus all in one packaged easily to deploy service. While the learning
  curve with Kubernetes was a little steep\, it lead to building a highly s
 calable and resilient database cluster.\n\nThe PostgreSQL + PostGIS + Time
 scale + H3 stack helped us simulate the temporal and spatial nature of the
  world at the database level and gave a universal approach to store and qu
 ery all our datasets. It can handle textual data like fires with time (rec
 orded time) and spatial information (lat -long) or shapes of counties\, wa
 ter bodies\, etc.\, and combine them with each other using few joins givin
 g us a very powerful geospatial-temporal query engine. \n\nWithout FOSS it
  would have been impossible to even imagine any of this but as of now\, we
  are quantifying climate change!
DTSTAMP:20260404T150127Z
LOCATION:Room Limonaia
SUMMARY:Spatio-temporal Database - Creating a high availability easily scal
 able Spatio-temporal database cluster with Postgres\, PostGIS\, and timesc
 aleDB! - Jashanpreet Singh
URL:https://talks.staging.osgeo.org/foss4g-2022/talk/YJPU9S/
END:VEVENT
END:VCALENDAR