databaser? Ikke særlig interessant.
så kan en gennemsnitlig person, der arbejder med GIS eller datavisualiseringer, tænke. Jeg må indrømme, at databaser ikke er den kønneste ting i verden (undskyld DBA ‘ s), men hvis du hævder (eller sigter) at lave analyser eller visualisering med (rumlige) data på en mere seriøs måde, bør du absolut ikke ignorere dem. Jeg håber, at dette blogindlæg kan give dig en ide om, hvilke fordele den effektive brug af rumlige databaser kan tilbyde dig.
Hype vilkår kommer og går i det, og der var en stor hype omkring big data stadig bare et par år siden, men det er nu langsomt fading væk. Nå, data er stadig store, og faktisk er de større end nogensinde. Filstørrelser vokser og i “data science” og geovidenskab skal folk beskæftige sig med data, der nemt kan være inden for Gigabyte. Jo større data, mere opmærksomhed skal vi betale for den måde, vi gemmer og analyserer dem på.
det er her en database kommer ind på billedet.
i programmel udvikling arbejde med databaser er et must. Men for folk i andre underdomæner inden for datalogi (som GIS) er fordelene ved en database måske ikke altid så indlysende. Selvfølgelig har folk en tendens til at bruge de værktøjer, der er mest kendte for dem, selvom det ikke ville være den mest effektive måde at nå mål på. Men nogle gange at træde ud af dit komfortområde kan virkelig give dig store fordele. Jeg har selv langsomt indset det potentiale, der ligger i rumlig KVL.
dette blogindlæg er primært til folk, der arbejder med geospatiale data, men har ikke rørt PostGIS eller måske ikke engang hørt om det. Jeg vil ikke gå igennem, hvordan du installerer Postgraduate/PostGIS, men snarere forsøge at give dig et overblik over, hvad det er, og hvad er det godt for.
min arbejdsgang og eksempler fokuserer hovedsageligt på kombinationen af GIS + PostGIS, men du skal være opmærksom på, at du også kun kan arbejde med PostGIS, din egen kode eller med nogle andre GIS-klienter.
Post… hvad?
allerede under mine GIS-studier havde jeg hørt udtrykket ‘PostGIS er en rumlig udvidelse af Postgres’ flere gange. Det betød ikke, at jeg havde nogen anelse om, hvad det betyder. Jeg havde ingen anelse om, hvad der er Postgres, endsige en rumlig udvidelse.
lad os prøve at bremse det så enkelt som muligt.
nogle mennesker hader mig måske for denne sammenligning, men jeg tager risikoen: hvis du aldrig har arbejdet med databaser, kan du tænke på databasetabeller som massive ark. Men et massivt intelligent udmærke ark, hvorfra du i et millisekund kan finde ud af, hvilken værdi der er på den tredje kolonne på række nummer 433 285. Og i stedet for at skrive funktioner inde i arket til en enkelt celle, skriver du dem til dit kommandovindue. Så et sted at gemme data og hvorfra du kan få det ud effektivt.
PostGIS er en open source, frit tilgængelig rumlig databaseforlænger til postgraduate Database Management System (alias DBMS). Så Postgres er databasen, og PostGIS er som en tilføjelse til den database. Den seneste version af PostGIS kommer nu pakket med Postgraduate.
i en nøddeskal PostGIS tilføjer rumlige funktioner såsom afstand, område, union, kryds og speciale geometri datatyper til postgraduate.Rumlige databaser gemmer og manipulerer rumlige objekter som ethvert andet objekt i databasen.
så i en normal database gemmer du data af forskellige typer (numerisk, tekst, tidsstempler, billeder…), og når det er nødvendigt, kan du forespørge (hente) det for at besvare spørgsmål med dine data. Spørgsmålene kan være om ‘hvor mange mennesker logget på din hjemmeside’ eller ‘hvor mange transaktioner er foretaget i en online butik’. Rumlige funktioner kan i stedet besvare spørgsmål som’ hvor tæt er den nærmeste butik’,’ er dette punkt inde i dette område ‘eller’hvad er størrelsen på dette land’.
så dataene gemmes i rækker og kolonner. Da PostGIS er en rumlig database, har dataene også en geometri-kolonne med data i et specifikt koordinatsystem defineret af spatial reference identifier (SRID). Men husk, at selvom du primært bruger PostGIS til geodata, er det også muligt at gemme ikke-geodata derinde, da det stadig har alle funktionaliteterne i en normal postgraduate database!
den fremragende grænseløse PostGIS-introduktion introducerer tre kernekoncepter, der forbinder geodata med en database. Kombineret disse giver en fleksibel struktur for optimeret ydeevne og analyse.
- Geodatatyper som punkt, linje og polygon. Kendt for de fleste arbejder med geodata;
- multidimensionel rumlig indeksering bruges til effektiv behandling af rumlige operationer;
- rumlige funktioner, stillet i KVM, er til forespørgsel af rumlige egenskaber og relationer.
“struktureret forespørgselssprog” er et middel til at stille spørgsmål til og opdatere data i relationsdatabaser. En udvælgelsesforespørgsel (som du bruger til at stille spørgsmålene) er generelt en kommando af følgende formular
SELECT some_columns FROM some_data_source WHERE some_condition;
PostGIS-specifikke funktioner er normalt i form af ST_functionName.
du skriver disse kommandoer på kommandolinjen, når du er logget ind i din database eller i dit database GUI-værktøj (f.eks. Så ja, det kræver, at du virkelig skriver noget. Højreklik kan være undervurderet generelt, men for en person, der ikke skriver nogen kode, er det et godt første skridt til at skrive dine egne kommandoer og måske senere kode.
der er også andre rumlige databaser udover PostGIS. ESRI ArcSDE, Oracle Spatial og GeoMesa er et par andre muligheder for styring og analyse af geodata. Men PostGIS siges at have flere funktionaliteter og generelt bedre ydeevne. Også de andre nævnte (undtagen GeoMesa) er ikke open source.
hvis du er ny til dette, nu Kan du blive forvirret: så det er et sted at gemme data, og du er nødt til at få information ud på en kompleks måde ved at skrive nogle underlige ting på kommandolinjen? Vent på det. Der er også nogle reelle fordele, som PostGIS kan tilbyde dig, hvis du virkelig forpligter dig til det.
jeg spurgte nogle ideer til blogindlægget fra kvidre og fik en masse god feedback. Derfra fik jeg ideen om at opdele dette i to dele. I den første del vil jeg se på de fordele, som PostGIS kan bringe til dit daglige arbejde. I den anden del vil jeg fokusere mere på rumlig KVL.
PostGIS kan give dig mulighed for at vedtage en ny måde at arbejde på. Denne nye måde kan lettere reproduceres, du kan lettere begynde at bruge versionskontrol, og den kan aktivere arbejdsgange med flere brugere.
filer kræver ofte specielle programmer til at læse og skrive. Det er en abstraktion for tilfældig dataadgang og analyse. Uden denne abstraktion har du enten brug for et specifikt program til at udføre operationerne eller har brug for at skrive al adgangs-og analysekoden selv.
gør din analyse i stedet for bare at gøre tilfældige operationer for filer med nogle tilfældige værktøjer med tilfældige parametre, giver dig mulighed for at dele og reproducere dine resultater lettere. Du har måske den ene” master Shapefile ” i øjeblikket et sted, hvor du har lavet flere rumlige sammenføjninger og klipoperationer til en Shapefile for at få det til at være som det skal være. Hvad hvis det forsvinder?
Johnnie skrev et godt eksempel på kvidre om, hvordan han ved et uheld slettede alle sine data, men var i stand til at gengive dem med minimal indsats med De skripter, han gemte til GIT.
personer, der arbejder med programmeludvikling, er sandsynligvis (eller forhåbentlig) bekendt med versionskontrol. Jeg vil ikke gå dybere ind i det i dette blogindlæg, men du kan (og du bør) have dine skripter i et versionsstyringssystem, som GIT. Tænk på det som en kogebog, som du opbevarer i din bogreol og konstant opdaterer for altid at finde de bedste opskrifter til velsmagende dataanalyse. Kun at du kan købe en ny kopi af denne nøjagtige kogebog fra
en database kan også hjælpe dig med at holde dine geodata i bedre orden. Ingen af os er virkelig perfekt, og sandsynligvis vil du stadig oprette tabeller som temp_1, final_final, men stadig giver en database bedre mulighed for dig at standardisere din datastruktur end bare filer (f.eks.
og hvad med de store datasæt? Med en rumlig database bliver det muligt at arbejde med store datasæt. Ikke kun lettere, men nogle gange er det næsten umuligt at arbejde på større datasæt uden en database. Har du nogensinde prøvet at åbne 2 gb csv-fil? Eller forsøgte at gøre nogle geoprocessing for en 800 mb GeoJSON? Vidste du endda, at Shapefiles har en størrelsesgrænse? Selvfølgelig kan du tackle nogle af disse problemer ved hjælp af Geopackage eller nogle andre filformater, men generelt er PostGIS det optimale værktøj til håndtering af store (geospatiale) data.
en meget flot funktion med databaser er, at du lettere kan automatisere processer, som du normalt gør manuelt. Hvis du f.eks. bruger notifikationsfunktionen, kan du automatisk opdatere dine kort. FME) for at automatisere dit arbejde, er det meget lettere at læse/skrive fra/til PostGIS-tabeller end med filer.
hvis du ikke er som mig (jeg gør i øjeblikket disse ting alene og for sjov), har du måske en ting kaldet et hold. Også kendt som medarbejdere. De kan have behov for at få adgang til de samme data som dig. Brug af en database i din arbejdsgang muliggør parallel arbejde helt på et andet niveau end blot at have filer på et delt drev.
en hovedårsag til dette er, at samtidige brugere kan forårsage korruption. Selvom det er muligt at skrive ekstra kode for at sikre, at flere skrivninger til den samme fil ikke ødelægger dataene, ville du have skrevet den bedre del af et databasesystem, når du har løst problemet og også løst det tilknyttede ydelsesproblem.
selvfølgelig er der både fordele og ulemper ved at vedtage en ny arbejdsgang. Ligesom at holde dine filer i orden, i slutningen af dagen, også opretholde en database kan være en masse arbejde. For eksempel kan opdatering af dine PostGIS til en ny version være en reel smerte, som det blev påpeget på kvidre. Med stor magt følger et stort ansvar.
men lad os tale mere om den magtdel.
Del 2: den magiske verden af rumlig KVL
rumlig KVL kan virkelig fremskynde din behandling (når den bruges klogt). Nedenfor er en sammenligning mellem at gøre den samme proces med en shapefile og KGI ‘ er behandling og derefter i PostGIS med ST_GeneratePoints.
til denne sammenligning havde jeg postnummerdata fra Finland og befolkningen i hvert postnummerområde. Jeg havde dette både som en Shapefile og en tabel i min lokale database. Jeg oprettede tilfældige punkter inde i hver polygon for at repræsentere befolkningen. Jeg brugte Kgl-behandlingen (tilfældige punkter inde i polygon fra Vektorbehandling) til Shapefilen, og i PostGIS var KKL virkelig så simpelt som dette:
SELECT ST_GeneratePoints(geom, he_vakiy) from paavo.paavo
som du kan se fra grafen tidligere, tog det PostGIS mindre end 10% af tiden at lave den samme analyse sammenlignet med KGI ‘ er og en Shapefile. Hvis du er GIS-analytiker og udfører processer som denne hver dag, kan det spare dig for en hel del tid på et år.
udover hurtigere behandling kan du nyde det store udvalg af rumlige funktioner, PostGIS har at tilbyde. Hvilke funktioner der er mest nyttige for dig, afhænger helt af brugssagen. Ud over Voronoi-analysen og mere traditionel GIS-analyse (buffer, overlay, intersect, clip osv..) du kan gøre mere avancerede ting:
- Routing. Med pgrouting og vejdata kan du finde optimale ruter og gøre forskellige netværk analytics;
- Polygon skeletonisering. Denne funktion gør det muligt at bygge den mediale akse af en polygon på flue;
- geometri underinddeling. Opdeling af dine geometrier til videre behandling kan betydeligt fremskynde dine processer;
- klyngedannelse. Find klynger og mønstre fra dine data. Med AI-hype på toppen, k-midlerne kan være endnu mere interessante for nogle end før…
Hvad har du brug for ting som polygonskeletonisering til? Kan være et gyldigt spørgsmål for de fleste, men den ene gang, når din rumlige analyse har brug for det, vil du være meget glad for, at nogen har gjort det hårde arbejde (=matematik) for dig. Ved at kombinere forskellige rumlige funktioner sammen og bruge de indbyggede Postgres-funktioner med dem kan du foretage avanceret rumlig analyse i din database.
komplicerede og interessante spørgsmål (rumlige sammenføjninger, aggregeringer osv.), der kan udtrykkes i en linje i databasen, kræver en masse beregningskraft, og det er noget, PostGIS tilbyder dig. Besvare de samme spørgsmål med din egen kode, kan tage hundredvis af linjer af specialiserede kode til at besvare, når programmering MOD filer.
PostGIS for dataviser
i mange af de visualiseringer, jeg har i min portefølje, har PostGIS spillet en slags rolle i visualiseringsprocessen. I min arbejdsgang behandler jeg oftest dataene og udfører derefter den faktiske visualisering i KGI ‘ er.
lad os se et eksempel på en af disse processer.
Animation om tog og voronois ovenfor giver et legende eksempel på PostGIS magt. Jeg havde et par millioner tog GPS-punkter i min lokale database, og jeg havde allerede oprettet animationer med de punkter, der bare bevægede sig. Men jeg ville teste, hvordan en animation med Voronoi-linjer ville se ud.
først fordi jeg havde flere GPS-punkter for hvert tog pr. Jeg havde først oprettet en tabel manuelt for de resulterende punkter. Jeg skrev følgende forespørgsel
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 forespørgslen i stykker, kan vi se følgende stykker af puslespillet:
- du kan se nogle af de normale elementer i en forespørgsel (indsæt i, Vælg som, fra, hvor og gruppe efter)
- geom, trainno og time er kolonnenavne i min ugetabel i skemaet kaldet tog
- underforespørgslen a returnerer alle GPS-punkter, der er sporet inden for den ønskede tidsramme.
- fordi jeg vælger alle GPS-punkter sporet inden for et minut, kan jeg få flere point for hvert tog. Jeg ville kun have en, så voronoi-linjerne ville se mere fornuftige ud. Derfor bruger jeg ST_Collect til at gruppere punkterne sammen og skabe en multipunktsgeometri fra dem. ST_Centroid erstatter multipunktsgeometrien med et enkelt punkt placeret ved centroid (underforespørgsel b), og dataene grupperes efter tognumre.
for at gøre det samme flere gange havde jeg et simpelt Python-script til at løbe over den samme forespørgsel i et par hundrede gange, hvor jeg havde start-og sluttiderne som parametre. Efter at have fundet et repræsentativt punkt for hvert minut, kørte jeg bare følgende kommando (i 11,5 sekunder):
SELECT t, ST_VoronoiLines(geom) from trains.voronoipoints
så tilføjede jeg resultatet til KGI ‘ er og visualiserede det med Time Manager. Dette kan være en smule hacky måde at opnå resultatet på, og en mere erfaren bruger kan have gjort det helt med en enkelt kommando, men jeg er stadig ret tilfreds med resultatet. Selvom det måske er meningsløst.
til sidst ret simpelt, men resultatet ligner højere niveau matematik (og det er det!), da alt det hårde arbejde udføres af PostGIS. Også fordi jeg var i stand til at lave Voronoi-analysen for kun et point pr.
ofte vokser behandlingstiden for dine forespørgsler eksponentielt, efterhånden som datamængderne vokser. Derfor skal du være smart med dine spørgsmål.
som en tommelfingerregel, jo flere data en forespørgsel skal hente og flere operationer databasen skal udføre (bestilling, gruppering osv.), bliver den langsommere og dermed mindre effektiv. En effektiv forespørgsel henter kun de rækker og kolonner, den virkelig har brug for. Det kan fungere som et logisk puslespil, hvor du virkelig skal tænke grundigt over, hvad du vil opnå.
jeg må også bemærke, at finjustering af udførelsen af dine forespørgsler er en glat skråning, og du kan gå tabt i en verden af endeløs optimering. At finde balancen mellem en” optimal forespørgsel ” og en optimal forespørgsel er virkelig vigtig. Især hvis du ikke bygger en applikation til en million brugere, vil et par millisekunder her eller der sandsynligvis ikke rocke din båd.
Hvordan kommer man i gang?
jeg tør sige, at det er endnu mere fordelagtigt for en gennemsnitlig GIS-bruger at lære JavaScript, Python eller R.
jeg har fundet ud af, at indlæringskurven ikke er rigtig stejl for at gøre det grundlæggende, men det kan tage dig lidt tid at virkelig se de fordele, det kan medføre for din rumlige analyse. Men jeg opfordrer til at være tålmodig og prøve mere komplicerede analyser og sigte mod hurtigere behandling. Til sidst vil du se forskellen.
først når du lærer grundlæggende grundlæggende oplysninger, lærer du, hvordan du forespørger data fra en enkelt tabel ved hjælp af grundlæggende datavalgsteknikker, såsom valg af kolonner, sortering af resultatsæt og filtrering af rækker. Derefter lærer du om de avancerede forespørgsler, såsom sammenføjning af flere tabeller, brug af sætoperationer og konstruktion af en underforespørgsel. Endelig lærer du, hvordan du administrerer databasetabeller, såsom oprettelse af ny en tabel eller ændring af en eksisterende tabels struktur.
men der også også værktøjer til at hjælpe dig ud!
KGIS har et fantastisk værktøj kaldet DB Manager. Det tilbyder en lignende GUI til din database, men på en meget mere komprimeret måde og inde i KGI ‘ er. Du kan ændre og tilføje tabeller, tilføje indekser og gøre en masse af de grundlæggende operationer på en højreklik-klikbar måde.
du bør også tjekke pgAdmin, som er den mest populære administrations-og udviklingsplatform for Postgraduate. Der er flere måder at få dine data ind på PostGIS (f.eks. Generelt opfordrer jeg til at prøve forskellige værktøjer og metoder til at arbejde med dataene.
jeg har lavet et par små eksperimenter med at kombinere Python og PostGIS. Arbejde med Python (eller R) og PostGIS sammen kan virkelig tage din databehandling og automatisering til det næste niveau. Bare at kombinere grundlæggende scriptingfunktioner i Python og oprette forbindelse til PostGIS ved hjælp af psycopg2 er gode måder at komme i gang på.
har du lyst til at komme i gang med PostGIS?
- bare hente installatørerne og installere PostGIS på din lokale maskine. Følg instruktionerne i vejledningerne;
- Indlæs nogle data derinde. Denne tutorial om, hvordan man får Naturlige jorddata til PostGIS;
- Start med at spille rundt med kvm. Start med det grundlæggende (valg, filtrering og ændring af dataene), og langsomt vil du se, hvilken slags fordele det kan medføre i din arbejdsgang.
konklusioner
hvis din måde at arbejde på i øjeblikket er ineffektiv, vil bare ændring af dine værktøjer ikke gøre dit resultat bedre eller processen mindre smertefuld. Du skal ændre den måde, du tænker på datastyring. Der er mange måder at bruge databaser ineffektivt på. Tro mig, jeg har set dem og endda prøvet et par stykker.
også at ændre ting bare for forandringens skyld, giver ikke mening. Hvis dit daglige arbejde bare planlægger et par prikker på et kort nu og da, kan du meget gøre det med Shapefiles og csv-filer også i fremtiden. Måske endda være mere effektiv på den måde.
men.
hvis du ønsker at gøre nogle seriøse rumlige analyser, automatisere dine processer eller på nogen måde flytte din måde at arbejde med spatal data til det næste niveau, kan jeg stærkt anbefale at blive fortrolig med PostGIS og især rumlig kvm. Det kan også være sjovt at lære GL. Alvorligt.
sidst men bestemt ikke mindst. Som Tom påpegede: brug af PostGIS giver dig geohipster cred!
en ting, som jeg kun nævnte kort, var, at PostGIS er open source og frit tilgængeligt. Det betyder, at folk, der arbejder med små eller intet budget (som mig), ikke har nogen adgangsbarriere. Kommercielle rumlige databaser kan være enormt dyre. Stor tak går til alle de aktive udviklere, der arbejder på projektet!
tak for læsning! Tjek min hjemmeside for mere information om mig eller smide mig en kommentar på kvidre.
vil du vide mere? Kilder til dette blogindlæg og yderligere PostGIS læsning
RTFD. PostGIS-dokumentationen er virkelig god.
PostGIS guru Paul Ramsey har flere præsentationer om emnet fra forskellige synspunkter på hans hjemmeside
store materialer fra grænseløs på introduktion til PostGIS.
Anita Graser har skrevet en fantastisk serie blogindlæg om håndtering af bevægelsesdata i PostGIS.
Tjek PostGIS-bøgerne fra Regina Obe
jeg brugte denne Boston GIS-tutorial, da jeg først installerede PostGIS lokalt
ekstra til folk, der laver dataviser: et interessant eksperiment om lagring af farver som 3D-punkter i PostGIS