# Geospatial ## Hva det er Geospatial beskriver data, analyser og programvare der en posisjon på jorden er en del av betydningen. En temperaturmåling er bare et tall til den knyttes til stedet der den ble tatt. En avlesning fra en smartmåler blir nyttig for planlegging først når den kan plasseres på en kurs, inne i et bydistrikt eller i nærheten av en værstasjon. Ordet er et adjektiv og følger det det beskriver: geospatiale data, en geospatial join, geospatial modellering. Romlig er det videre ordet. Layouten på en databrikke, en plantegning av et lager målt i lokale meter og en maskintegning er alle romlige, og koordinatene deres betyr ingenting utenfor tegningen. Geospatiale data er festet til kloden gjennom et koordinatreferansesystem, så to datasett som aldri ble laget for hverandre, likevel kan legges over hverandre og sammenlignes. Plassering kommer inn i et datasett i flere former, og de er ikke like nyttige. - **Koordinater**, som regel bredde- og lengdegrad fra en GPS-mottaker eller en geokoder, gir et punkt som programvare kan regne med direkte. - **Geometrier** beskriver linjer og flater i tillegg til punkter: en kabeltrasé, utbredelsen av en flom, et forsyningsområde. Simple Features-modellen fra Open Geospatial Consortium (OGC), også utgitt som ISO 19125, definerer formene de fleste databaser og filformater deler. - **Adresser og stedsnavn** bærer plassering for mennesker, men de må geokodes, altså gjøres om til koordinater, før noe kan måles, og hver geokoder løser dem opp med sin egen presisjon. - **Områdekoder**, som postnumre, kommunenumre eller identifikatorer for ruter i et rutenett, sier hvilket område noe ligger i, uten å si hvor inne i det. Under det hele ligger et sett åpne standarder som lar geospatiale data flytte mellom systemer uten å miste betydningen sin. OGC gir ut spesifikasjonene for geometri, for filer som GeoPackage og for webtjenester som OGC API – Features. EPSG-registeret gir hvert koordinatreferansesystem en tallkode, så 4326 betyr bredde- og lengdegrad på WGS 84 uansett hvor koden dukker opp. PROJ, et bibliotek med åpen kildekode, transformerer koordinater fra ett av disse systemene til et annet og støtter mer enn hundre kartprojeksjoner. ## Hvorfor det er viktig Plassering er en koblingsnøkkel som nesten alle datasett allerede har. Måleravlesninger, værobservasjoner, kunderegistre og nettanlegg deler sjelden en identifikator, men hver av dem skjedde et sted. En geospatial join parer rader etter hvordan posisjonene deres forholder seg til hverandre, den ene inne i den andre, innenfor en gitt avstand eller på kryss av hverandre, i stedet for etter like verdier. Den kobler sammen data som ingen fremmednøkkel noen gang har bundet sammen, og det er ofte den første grunnen til at en virksomhet begynner å behandle dataene sine som geospatiale: spørsmålet den vil ha svar på, spenner over datasett som bare møtes på kartet. Den andre grunnen er at plassering endrer hva et gjennomsnitt betyr. Et nasjonalt tall for forbruk eller for strømbrudd kan skjule ett distrikt som er ved grensen sin, mens resten har god margin, og beslutningen som teller, hvor nettet skal forsterkes, hvor pengene skal inn, hvor et mannskap skal sendes, handler om nettopp det distriktet. Å gruppere etter område eller etter avstand viser spredningen som én enkelt sum skjuler. Plassering veier også tungt utenfor analysen. Et kort spor av GPS-punkter fra én telefon viser som regel hvor eieren sover og arbeider, så posisjonsdata om mennesker fortjener samme omtanke som andre personopplysninger. I praksis betyr det å samle dem inn med den presisjonen formålet trenger, gjøre dem grovere før de deles, og ikke beholde dem lenger enn formålet varer. ## Slik ser det ut i praksis Smartmålere spredt over flere regioner sto for dataene bak [mer enn 500 analyserapporter skrevet i ren SQL](/nb/portfolio/released-500-electricity-and-gis-data-analysis-reports-11/) på PostgreSQL og BigQuery. Avlesningene kom med geolokasjonskoordinater for hver måler, og det lot skriptene bruke geospatiale joins sammen med CTE-er og vindusfunksjoner for å finne regionale trender og avvik. Hver rapport hadde med seg kommentert SQL, slik at kolleger kunne reprodusere den, og de vanlige datakvalitetsproblemene, manglende GPS-koordinater blant dem, ble skrevet ned med en anbefalt måte å håndtere hvert av dem på. Rapportene ble siden brukt i regional lastbalansering og bidro til en forbedring på 10–15 % i effektiviteten i den operative planleggingen. Elleve nettselskaper hadde driftsdataene, men lite geospatial analyse å bygge beslutningene om forsterkning og investering på. [Driftsdataene deres ble koblet sammen med geospatial modellering](/nb/portfolio/optimized-forecasting-and-investment-strategies-for-11-electricity-27/), slik at hvert nett kunne betraktes på kartet og stilles spørsmålet om hvilke strekninger som var på vei mot grensene sine, og hvilke områder som fortjente investeringer først. Analysen ble tilpasset hvordan hvert nettselskap faktisk drev nettet sitt, i stedet for å bli delt ut som én mal. Geospatiale data må også holde seg raske etter hvert som de vokser. I en PostgreSQL-applikasjon der spørringer mot plassering hadde blitt trege sammen med tidsseriene for strøm, [ble GiST-indekser lagt til for de geospatiale dataene](/nb/portfolio/accelerated-postgresql-performance-by-10x-via-strategic-indexing-15/), og de geografiske dataene ble hash-partisjonert for å fordele lasten jevnt mellom nodene. Etterpå gikk geospatiale oppslag på millisekunder. ## Hvor det går galt **Kartet får en tett klynge på null bredde og null lengde.** Et kart over kunder eller enheter viser en tett samling i Guineabukta, der ekvator krysser nullmeridianen, og de regionale summene tar med poster fra et sted ingen kunde kan befinne seg. En enhet uten GPS-posisjon, eller en import som traff en tom celle, skrev nuller i stedet for å la posisjonen stå tom. Lagre en ukjent posisjon som NULL, legg til en begrensning som avviser nøyaktig paret 0, 0, et punkt ute på åpent hav, og tell de manglende posisjonene i hver bolk, slik at hver rapport oppgir hvor mange poster den lot stå uplassert. **Joins på koordinater gir bare en håndfull treff.** To datasett beskriver de samme transformatorstasjonene, men en join på lik bredde- og lengdegrad treffer bare noen få rader. Hver kilde målte eller rundet av koordinatene sine på sin måte, og koordinater er flyttall, så to posisjoner som ligger noen centimeter fra hverandre, er rett og slett ulike verdier. Koble heller på avstand, med en toleranse valgt ut fra hvor nøyaktige kildene er, gjennom et predikat som den romlige indeksen kan betjene. I PostGIS, med geography-kolonner målt i meter: ```sql SELECT a.substation_id, b.asset_ref FROM survey AS a JOIN register AS b ON ST_DWithin(a.location, b.location, 15); ``` Gå deretter gjennom rader som traff mer enn én gang, for en toleranse som er vid nok til å svelge målefeil, kan også bygge bro mellom to naboanlegg. **Punkter midt i postnummerområder går for å være nøyaktige posisjoner.** En avstandsanalyse melder at dusinvis av kunder bor på nøyaktig samme sted, eller et varmekart viser skarpe topper midt i postnummerområdene. Adressene ble bare geokodet ned til postnummeret, og hver av dem kom tilbake som midtpunktet i området sitt uten at analysen merket det. Registrer nivået hvert punkt ble løst opp til, for eksempel adresse, gate eller postnummer, i en kolonne ved siden av det, og filtrer eller vekt etter det nivået før du måler en avstand som er kortere enn selve området. **Fjorårets regionale summer endrer seg etter en grenseendring.** En rapport som kjøres på nytt på uendrede historiske data, gir andre tall per region enn de som først ble publisert. Punktene ble koblet mot det gjeldende laget med grenser, og siden den gang har kommuner slått seg sammen, postnumre blitt delt eller et forsyningsområde blitt tegnet om. Behold de rå koordinatene og ikke bare regionen de havnet i, lagre grenselagene med datoene de var gyldige, koble hver post mot den grensen som gjaldt på tidspunktet i posten, og noter i hver rapport hvilken grenseversjon den bygger på. ## Les mer - [OGC Standards](https://www.ogc.org/standards/) — katalogen over åpne geospatiale standarder fra Open Geospatial Consortium, hver med sine spesifikasjonsdokumenter. - [Simple Feature Access – Part 1](https://www.ogc.org/standards/sfa/) — den felles geometrimodellen med punkter, linjer og polygoner som databaser og formater deler. - [EPSG Geodetic Parameter Dataset](https://epsg.org/) — registeret bak koder som 4326 og 3857, med den fullstendige definisjonen av hvert referansesystem. - [PROJ](https://proj.org/) — biblioteket med åpen kildekode som transformerer koordinater mellom referansesystemer, med kommandolinjeverktøy og API. - [OGC API – Features](https://ogcapi.ogc.org/features/) — OGC-standarden for å publisere og spørre etter geospatiale objekter over HTTP.