Databaser? Ikke veldig interessant.
så kan en gjennomsnittlig person som jobber med GIS eller datavisualiseringer tenke. Jeg må innrømme at databaser ikke er den sexigste tingen i verden( beklager DBA), men hvis du hevder (eller sikter) å gjøre analyser eller visualisering med (romlige) data på en mer seriøs måte, bør du definitivt ikke ignorere dem. Jeg håper dette blogginnlegget kan gi deg en ide om hva slags fordeler effektiv bruk av romlige databaser kan tilby deg.
Hype vilkår kommer og går I DET, og det var en stor hype rundt store data for bare noen få år siden, men det er nå sakte fading bort. Vel, data er fortsatt store og faktisk er det større enn noensinne. Filstørrelser vokser og i» datavitenskap » og geovitenskap må folk håndtere data som lett kan ligge innenfor gigabyte. Jo større data, mer oppmerksomhet vi må betale til måten vi lagrer og analysere den.
det er der en database kommer inn i bildet.
i programvareutvikling arbeider med databaser er et must. Men for folk i andre underdomener innen datavitenskap (SOM GIS) er fordelene med en database kanskje ikke alltid så åpenbare. Selvfølgelig folk har en tendens til å bruke verktøyene mest kjent for dem selv om det ikke ville være den mest effektive måten å oppnå mål. Men noen ganger stepping ut av komfortsonen kan virkelig gi deg store fordeler. Jeg har vært meg selv sakte å realisere potensialet som ligger i romlig SQL.
dette blogginnlegget er hovedsakelig for personer som jobber med geospatiale data, men har ikke rørt PostGIS, eller kanskje ikke engang hørt om Det. Jeg skal ikke gå gjennom hvordan du installerer PostgreSQL / PostGIS, men prøv å gi deg en oversikt over hva det er og hva det er bra for.
min arbeidsflyt og eksempler fokuserer hovedsakelig PÅ qgis + PostGIS-kombinasjon, men du bør være oppmerksom på at du også kan jobbe med Bare PostGIS, din egen kode eller med noen ANDRE GIS-klienter.
Innlegg … hva?
allerede under GIS-studiene hadde jeg hørt uttrykket ‘PostGIS er en romlig forlengelse Av Postgres’ flere ganger. Det betydde ikke at jeg hadde noen anelse om hva det betyr. Jeg hadde ingen anelse om Hva Som Er Postgres, enn si en romlig utvidelse.
La oss prøve å bremse det ned så enkelt som mulig.
Noen mennesker kan hate meg for denne sammenligningen, men jeg tar risikoen: hvis du aldri har jobbet med databaser, kan du tenke på databasetabeller som massive Excel-ark. Men et massivt intelligent Excel-ark hvorfra du i et millisekund kan finne ut hvilken verdi som er i den tredje kolonnen på rad nummer 433 285. Og i stedet for å skrive funksjoner inne i arket til en enkelt celle, skriver du dem til SQL-kommandovinduet. Så et sted å lagre data og hvor du kan få det ut effektivt.
PostGIS Er en åpen kildekode, fritt tilgjengelig romlig database extender For PostgreSQL Database Management System (aka DBMS). Så PostgreSQL (aka Postgres) er databasen Og PostGIS er som et tillegg til den databasen. Den nyeste versjonen Av PostGIS kommer nå pakket Med PostgreSQL.
I et nøtteskall PostGIS legger romlige funksjoner som avstand, område, union, skjæringspunkt, og spesialitet geometri datatyper Til PostgreSQL.Romlige databaser lagre og manipulere romlige objekter som alle andre objekter i databasen.
så i en vanlig database lagrer du data av forskjellige typer (numerisk, tekst, tidsstempler, bilder…) og når det trengs, kan du spørre (hente) det for å svare på spørsmål med dataene dine. Spørsmålene kan være ‘hvor mange som er logget på nettstedet ditt’ eller ‘hvor mange transaksjoner som er gjort i en nettbutikk’. Romlige funksjoner kan i stedet svare på spørsmål som ‘hvor nær er nærmeste butikk’, ‘er dette punktet inne i dette området ‘eller’ hva er størrelsen på dette landet’.
slik at dataene lagres i rader og kolonner. Fordi PostGIS er en romlig database, har dataene også en geometri kolonne med data i et bestemt koordinatsystem definert av spatial reference identifier (SRID). Men husk at selv Om Du vil bruke PostGIS hovedsakelig for romlige data, er det også mulig å lagre ikke-romlige data der inne, da det fortsatt har alle funksjonene i en vanlig PostgreSQL-database!
Den utmerkede Grenseløse PostGIS intro, introduserer tre kjernekonsepter som forbinder romlige data med en database. Kombinert gir disse en fleksibel struktur for optimalisert ytelse og analyse.
- Romlige datatyper som punkt, linje og polygon. Kjent for de fleste som arbeider med romlige data;
- Flerdimensjonal romlig indeksering brukes til effektiv behandling av romlige operasjoner;
- Romlige funksjoner, utgitt I SQL, er for spørring av romlige egenskaper og relasjoner.
SQL, Eller» Structured Query Language», er et middel til å stille spørsmål om og oppdatere data i relasjonsdatabaser. En utvalgsspørring (som du bruker til å stille spørsmålene) er vanligvis en kommando av følgende skjema
SELECT some_columns FROM some_data_source WHERE some_condition;
PostGIS spesifikke funksjoner er vanligvis I Form Av ST_functionName.
du skriver disse kommandoene på kommandolinjen etter at du har logget inn i databasen eller i databasens GUI-verktøy (f.eks. pgAdmin eller QGIS DB Manager). SÅ JA, SQL krever at du virkelig skriver noe. Høyreklikk kan være undervurdert generelt, MEN FOR noen som ikke skriver noen kode, ER SQL et godt første skritt for å skrive dine egne kommandoer og kanskje senere kode.
Det finnes også andre romlige databaser i Tillegg Til PostGIS. SQL Server Spatial, ESRI ArcSDE, Oracle Spatial Og GeoMesa er noen andre alternativer for å administrere og analysere romlige data. Men PostGIS sies å ha flere funksjoner og generelt bedre ytelse. Også de andre nevnte (unntatt GeoMesa) er ikke åpen kildekode.
hvis du er ny på dette, kan du nå bli forvirret: så det er et sted å lagre data, og du må få informasjon ut på en komplisert måte ved å skrive noen rare ting på kommandolinjen? Vent på det. Det er også noen reelle fordeler Som PostGIS kan tilby deg hvis du virkelig forplikte seg til det.
jeg spurte noen ideer til blogginnlegget Fra Twitter og fikk mye god tilbakemelding. Derfra fikk jeg ideen om å dele dette i to deler. I den første delen vil jeg se på fordelene Som PostGIS kan bringe til ditt daglige arbeid. I den andre delen vil jeg fokusere mer på spatial SQL.
PostGIS kan gjøre Deg i stand til å vedta en ny måte å jobbe på. Denne nye måten kan lettere reproduseres, du kan begynne å bruke versjonskontroll lettere, og det kan aktivere flerbrukerarbeidsflyter.
Filer krever ofte spesiell programvare for å lese og skrive. SQL ER en abstraksjon for tilfeldig datatilgang og analyse. Uten den abstraksjonen trenger du enten en bestemt programvare for å gjøre operasjonene eller trenger å skrive all tilgangs-og analysekoden selv.
Å gjøre analysen din I SQL i stedet for bare å gjøre tilfeldige operasjoner for filer med noen tilfeldige verktøy med tilfeldige parametere, lar deg dele og reprodusere resultatene dine lettere. Du kan ha den ene «master Shapefile» for tiden et sted, hvor du har gjort flere romlige sammenføyninger og klippoperasjoner til En Shapefile for å få det til å være som det skal være. Hva om det forsvinner?
Johnnie skrev et godt eksempel På Twitter på hvordan han ved et uhell slettet alle dataene sine, men klarte å reprodusere dem med minimal innsats med SQL-skriptene han lagret TIL GIT.
Personer som jobber med programvareutvikling er sannsynligvis (eller forhåpentligvis) kjent med versjonskontroll. Jeg kommer ikke til å gå dypere inn i det i dette blogginnlegget, men du kan (og du burde) ha SQL-skriptene dine i et versjonskontrollsystem, som GIT. Tenk på det som en kokebok som du holder i bokhyllen og stadig oppdatere for å alltid finne de beste oppskriftene for velsmakende dataanalyse. Bare at du kan kjøpe en ny kopi av Denne eksakte kokeboken fra Amazon igjen hvis huset ditt brenner ned.
en database kan også hjelpe deg med å holde dine romlige data i bedre rekkefølge. Ingen av oss er virkelig perfekt, og sannsynligvis vil du fortsatt lage tabeller som temp_1, final_final, men fortsatt gir en database bedre mulighet for deg å standardisere datastrukturen enn bare filer (for eksempel ved å standardisere datatypene i tabellene dine).
og hva med de store datasettene? Med en romlig database som arbeider med store datasett blir mulig. Ikke bare enklere, men noen ganger er det nesten umulig å jobbe med større datasett uten en database. Har du noen gang prøvd å åpne 2 gb csv-fil? Eller prøvde å gjøre noen geoprosessering for en 800 mb GeoJSON? Visste du selv at Shapefiles har en størrelsesgrense? Selvfølgelig kan du takle Noen av disse problemene Ved Å bruke Geopackage eller noen andre filformater, Men Generelt Er PostGIS det optimale verktøyet for å håndtere store (geospatiale) data.
en veldig fin funksjon med databaser er at du lettere kan automatisere prosesser som du vanligvis gjør manuelt. For eksempel ved Å bruke PostgreSQL VARSLE funksjonen, kan du oppdatere qgis kart automatisk. FME) for å automatisere arbeidet ditt, er det mye enklere å lese/skrive Fra/Til PostGIS-tabeller enn med filer.
hvis du ikke er som meg (jeg gjør for tiden dette på egen hånd og for moro skyld), kan du ha en ting som kalles et lag. Også kjent som medarbeidere. De kan ha behov for å få tilgang til de samme dataene som deg. Ved hjelp av en database i arbeidsflyten kan parallell arbeider helt på et annet nivå enn bare å ha filer på en delt stasjon.
en hovedårsak til dette er at samtidige brukere kan forårsake korrupsjon. Selv om det er mulig å skrive ekstra kode for å sikre at flere skriver til samme fil ikke ødelegger dataene, når du har løst problemet og også løst det tilknyttede ytelsesproblemet, ville du ha skrevet den bedre delen av et databasesystem.
selvfølgelig er det både fordeler og ulemper ved å vedta en ny arbeidsflyt. Akkurat som å holde filene i orden, på slutten av dagen, også opprettholde en database kan være mye arbeid. For eksempel oppdatere PostGIS til en ny versjon kan være en reell smerte, som det ble påpekt På Twitter. Med stor makt følger stort ansvar.
men la oss snakke mer om den kraftdelen.
Del 2: den magiske verden av spatial SQL
Spatial SQL kan virkelig øke hastigheten på behandlingen din (når den brukes klokt). Nedenfor er en sammenligning mellom å gjøre samme prosess med En Shapefile og QGIS-behandling og deretter I PostGIS Med ST_GeneratePoints.
til denne sammenligningen hadde jeg postnummerdata fra Finland og befolkningen i hvert postnummerområde. Jeg hadde dette både Som En Shapefile og et bord i min lokale database. Jeg opprettet tilfeldige punkter i hver polygon for å representere befolkningen. JEG brukte QGIS-behandlingen (Tilfeldige punkter inne i polygon fra Vektorbehandling) For Shapefilen og I PostGIS VAR SQL virkelig så enkelt som dette:
SELECT ST_GeneratePoints(geom, he_vakiy) from paavo.paavo
Som du kan se fra grafen tidligere, tok Det PostGIS mindre enn 10 % av tiden å gjøre den samme analysen sammenlignet MED QGIS og En Shapefile. Hvis DU er GIS-analytiker og gjør prosesser som dette hver dag, kan det spare deg ganske mye tid på et år.
I tillegg til raskere behandling, kan Du nyte det store utvalget Av romlige funksjoner PostGIS har å tilby. Hvilke funksjoner som er mest nyttige for deg, avhenger helt av brukssaken. I Tillegg Til Voronoi-analysen og mer tradisjonell GIS-analyse(buffer, overlegg, kryss, klipp etc..) du kan gjøre mer avanserte ting:
- Ruting. Med pgRouting og road data kan du finne optimale ruter og gjøre forskjellige nettverksanalyser;
- Polygon skeletonization. Denne funksjonen gjør det mulig å bygge medialaksen til et polygon på fly;
- Geometry subdivision. Å dele geometrier for videre behandling kan øke hastigheten på prosessene dine betydelig;
- Clustering. Finn klynger og mønstre fra dataene dine. MED AI hype på topp, k-midler kan være enda mer interessant for noen enn før…
Hva trenger du ting som polygon skeletonization for? Kan være et gyldig spørsmål for de fleste, men den gangen når din romlige analyse trenger det, vil du være svært glad for at noen har gjort det harde arbeidet (=matte) for deg. Kombinere ulike romlige funksjoner sammen og bruke Postgres innebygde funksjoner med dem vil tillate deg å gjøre avansert romlig analyse i databasen.
Kompliserte og interessante spørsmål (romlige sammenføyninger, aggregeringer, etc) som er uttrykkbare i EN LINJE AV SQL i databasen krever mye beregningskraft, Og Det Er Noe Som PostGIS tilbyr deg. Svare på de samme spørsmålene med din egen kode, kan ta hundrevis av linjer med spesialisert kode for å svare når programmering mot filer.
PostGIS for dataviz
I mange av visualiseringene jeg har i porteføljen min, Har PostGIS spilt En slags rolle i visualiseringsprosessen. I arbeidsflyten min behandler jeg ofte dataene og gjør den faktiske visualiseringen I QGIS.
La oss se et eksempel på en av disse prosessene.
Animasjon om tog og voronois ovenfor gi en leken eksempel på kraften I PostGIS. Jeg hadde et par millioner tog GPS poeng i min lokale database, og jeg hadde allerede laget animasjoner med punktene bare flytte. Men jeg ønsket å teste ut hvordan en animasjon Med Voronoi linjer ville se ut.
Først fordi JEG hadde FLERE GPS-poeng for hvert tog per minutt, ønsket jeg å gruppere dem slik at jeg ville ha ett representativt punkt for hvert minutt per tog. Jeg hadde først opprettet et bord manuelt for de resulterende punktene. Jeg skrev følgende spørring
INSERT INTO trains.voronoipoints
SELECT '2018–01–15 09:00:00' AS t,
geom
FROM (SELECT St_centroid(St_collect(geom)) AS geom,
trainno
FROM (SELECT geom,
trainno
FROM trains.week
WHERE time > '2018–01–15 09:00:00'
AND time < '2018–01–15 09:01:00') AS a
GROUP BY trainno) AS b
hvis vi bremser ned spørringen i stykker, kan vi se følgende stykker av puslespillet:
- du kan se noen av de normale elementene I EN SQL-spørring (SETT INN, VELG, SOM, FRA, HVOR OG GRUPPE ETTER)
- geom, trainno og tid er kolonnenavn i min uketabell i skjemaet kalt trains
- delspørsmålet a returnerer alle GPS-punkter som har blitt sporet innen den forespurte tidsrammen.
- Fordi jeg velger ALLE GPS-poeng sporet i ett minutt, kan jeg få flere poeng for hvert tog. Jeg ville bare ha en, slik at voronoi-linjene ville se mer fornuftig ut. Derfor bruker Jeg ST_Collect til å gruppere punktene sammen og lage en multipoint geometri fra dem. ST_Centroid erstatter multipointgeometrien med et enkelt punkt som ligger ved sentroid (subquery b) og dataene er gruppert av tognumre.
for å gjøre det samme flere ganger, hadde jeg et enkelt Python-skript for å sløyfe over samme spørring for noen hundre ganger hvor jeg hadde start-og sluttider som parametere. Etter å ha funnet et representativt punkt for hvert minutt, kjørte jeg bare følgende kommando (i 11,5 sekunder):
SELECT t, ST_VoronoiLines(geom) from trains.voronoipoints
så la jeg resultatet TIL QGIS og visualiserte Det Med Time Manager. Dette kan være litt hacky måte å oppnå resultatet på, og en mer erfaren SQL-bruker kan ha gjort det helt med en ENKELT SQL-kommando, men jeg er fortsatt ganske fornøyd med resultatet. Selv om det kan være meningsløst.
Til slutt ganske enkelt ,men resultatet ser ut som høyere matte (og det er!), som alt det harde arbeidet er gjort Av PostGIS. Også fordi Jeg var i stand Til Å gjøre Voronoi-analysen for bare ett poeng per tog, var behandlingstiden bare sekunder for hundretusener av poeng.
ofte vokser behandlingstiden for spørringene eksponentielt etter hvert som datamengdene vokser. Det er derfor du må være smart med dine spørsmål.
som en tommelfingerregel, jo flere data en spørring må hente og flere operasjoner databasen må gjøre( bestilling, gruppering etc), blir det langsommere og dermed mindre effektivt. En effektiv SQL-spørring henter bare rader og kolonner det virkelig trenger. SQL kan fungere som et logisk puslespill, hvor du virkelig må tenke grundig hva du vil oppnå.
jeg må også merke seg at tweaking ytelsen til dine spørsmål er en glatt skråning, og du kan gå seg vill i verden av endeløs optimalisering. Å finne balansen mellom en» optimal spørring » og en optimal spørring er veldig viktig. Spesielt hvis du ikke bygger et program for en million brukere, vil noen millisekunder her eller der sannsynligvis ikke rocke båten din.
hvordan komme i gang?
jeg tør å si at læring SQL er enda mer gunstig for en gjennomsnittlig GIS-bruker enn å lære JavaScript, Python eller R. SQL syntaks har bare hatt små endringer gjennom årene, OG SQL-ferdigheter er svært overførbare.
jeg har funnet ut at læringskurven I SQL ikke er veldig bratt for å gjøre det grunnleggende, men det kan ta deg litt tid å virkelig se fordelene som det kan bringe til din romlige analyse. Men jeg oppfordrer til å være tålmodig og prøve mer komplisert analyse og sikte på raskere behandling. Til slutt vil du se forskjellen.
Først når DU lærer SQL-grunnleggende, lærer du hvordan du spør etter data fra en enkelt tabell ved hjelp av grunnleggende datautvalgsteknikker som å velge kolonner, sortere resultatsett og filtrere rader. Deretter vil du lære om de avanserte spørringene som å bli med i flere tabeller, bruke settoperasjoner og bygge en delquery. Til slutt lærer du hvordan du administrerer databasetabeller, for eksempel å opprette en ny tabell eller endre en eksisterende tabellstruktur.
Men det er også også verktøy for å hjelpe deg!
QGIS har et flott verktøy kalt DB Manager. Det tilbyr en lignende GUI for databasen, men i en mye mer komprimert måte og inne QGIS. Du kan endre og legge til tabeller, legge til indekser og gjøre mange av de grunnleggende operasjonene på en høyreklikkbar måte.
du bør også sjekke pgAdmin, som Er Den mest populære administrasjons-og utviklingsplattformen For PostgreSQL. Det er flere måter å få dataene dine inn I PostGIS (f.eks. ogr2ogr, shp2pgsql). Generelt oppfordrer jeg til å prøve ut ulike verktøy og metoder for å jobbe med dataene.
jeg har gjort noen små eksperimenter i å kombinere Python og PostGIS. Arbeide Med Python (eller R) og PostGIS sammen kan virkelig ta databehandling og automatisering til neste nivå. Bare å kombinere grunnleggende skriptfunksjoner I Python og koble Til PostGIS ved hjelp av psycopg2 er gode måter å komme i gang.
føler Du at Du vil komme I Gang Med PostGIS?
- bare last ned installatørene og installer PostGIS på din lokale maskin. Følg instruksjonene i veiledningene;
- Last inn noen data der inne. Start med en Enkelt Shapefile ved HJELP AV QGIS DB Manager eller chech for eksempel denne opplæringen om hvordan Du får Naturlige Jorddata Til PostGIS;
- Begynn å spille rundt MED SQL. Start med det grunnleggende (velge, filtrere og endre data) og sakte vil du se hva slags fordeler det kan bringe i arbeidsflyten.
Konklusjoner
hvis arbeidsmåten din for tiden er ineffektiv, vil bare å endre verktøyene ikke gjøre utfallet ditt bedre eller prosessen mindre smertefull. Du må endre måten du tenker på datahåndtering. Det er mange måter å bruke databaser ineffektivt. Stol på meg, jeg har sett dem og selv prøvd noen.
også å endre ting bare for forandringens skyld, gir ikke mening. Hvis ditt daglige arbeid bare plotter noen punkter på et kart nå og da, kan du veldig gjøre Det med Shapefiles og csv-filer også i fremtiden. Det kan til og med være mer effektivt på den måten.
MEN.
hvis du vil gjøre noen seriøse romlige analyser, automatisere prosessene dine eller på noen måte flytte din måte å jobbe med spatal data til neste nivå, kan jeg sterkt anbefale Å bli kjent Med PostGIS og spesielt spatial SQL. Læring SQL kan også være morsomt. Alvorlig.
Sist Men definitivt ikke minst. Som Tom påpekte: bruke PostGIS gir deg geohipster cred!
En ting som jeg bare nevnte kort var At PostGIS er åpen kildekode og fritt tilgjengelig. Dette betyr at folk som jobber med lite eller ingen budsjett (som meg) ikke har noen inngangsbarriere. Kommersielle romlige databaser kan være enormt dyre. Stor takk går til alle de aktive utviklerne som jobber med prosjektet!
Takk for at du leste! Sjekk min hjemmeside for mer informasjon om meg eller kaste Meg en kommentar På Twitter.
Vil du lære mer? Kilder for dette blogginnlegget og videre PostGIS lesing
RTFD. PostGIS-dokumentasjonen er veldig bra.
Postgis guru Paul Ramsey har flere presentasjoner om emnet fra ulike synspunkt på sin side
Flotte materialer Fra Boundless på introduksjon Til PostGIS.
Anita Graser har skrevet en fantastisk serie blogginnlegg om håndtering av bevegelsesdata I PostGIS.
Sjekk Ut PostGIS-bøkene fra Regina Obe
jeg brukte Denne Boston GIS-opplæringen da Jeg først installerte PostGIS lokalt
Ekstra for folk som gjør dataviz:et interessant eksperiment om lagring av farger SOM 3d-poeng I PostGIS