Bokstavelig talt altså, gjerne også oversatt. Altså: “Hva er opp?”. Dumt spørsmål sier du kanskje, men jeg har i det siste begynnt å lure litt på dette, det vil si i faglige sammenhenger. Og for meg er faglige sammenhenger Geomatikk-verdenen, eller mer spesiftkt GIS-verdenen.

Jeg jobber med, og har en utdannelse som dreier seg om, digitale kartløsninger. Jeg trenger vel kanskje ikke en gang nevne at det finnes en rekke biblioteker, programmer og standarder som brukes i denne sammenhengen. OpenLayers, Google Maps, GeoTools, Geoserver, PostGIS, GDAL/OGR, SOSI, WKT, GeoJSON og GML er noen eksempler.

Det er mange ting å passe på her, og mye har med koordinatsystemer å gjøre. Et av “problemene” er at det er mange av dem, men der kommer transformasjonene inn. Et annet problem, som får meg til å lure på hva som er opp og og til er hvordan koordinatsystemet er satt opp. Det tenkte jeg å se litt nærmere på her.

I mattetimene ser koordinatsystemene gjerne ut som på figuren under:

Her legger vi merke til at aksen som går oppover er Y, og aksen bortover er X. Det er her problemene oppstår i GIS-verdenen. Det første jeg lærte i det første Geomatikk-faget var at X var oppover (og at sirkelen deles i 400 gon, ikke 360 grader). Her har vi en kilde til frustrasjon. I tillegg kommer de “ekle” skapningene Lengde- og Breddegrad inn. Da heter ikke aksene X og Y mer heller, men Ø og N (for Øst og Nord), eller V og S hvis vi er på de negative sidene av aksene. Her har vi enda en kilde til frustrasjon, siden dette blir hhv. Longitude og Latitude , som da blir E og N (eller W og S). I tillegg kan man brude de greske symbolene lille lambda (λ) for lengdegrad, og lille phi (φ) for breddegrad, men disse er vanskelig å få til i kode. Dermed har vi også formene lon (for longitude) og lat (for latitude).

Og når det gjelder X som opp? Vel, det gir mange blanke i…

Da blir altså systemet vår som i figuren under:

Og her starter problemene, for hvordan representerer man dette i kode?

For å starte lett. Google Maps har en klasse for geografiske punkter de kaller GLatLng. Den har følgende constructor:

GLatLng(lat:Number, lng:Number, unbounded?:Boolean)

Dvs, først Bredde-, så Lengdegrad. Metodene for å hente ut disse heter lat() og lng(). OpenLayers har klassen LonLat, med følgende constructor:

OpenLayers.LonLat(lon,lat)

Og bestanddelene kan du hente ut som propertiene lon og lat.

Dermed har vi allerede to forskjeller, Lon og Lng som begge er Lengdegrad, og rekkefølgen de skal inn i. Og værre skal det bli. PostGIS bruker x og y, og som de sier i en note i dokumentasjonen:

Note x is longitude and y is latitude

Der har vi altså det første eksempelet på at det jeg lærte om at x er opp ikke brukes.

PostGIS bruker også formatet WKT, der et punkt representeres med:
POINT(X Y)
Dette er i det minste konsistent med resten av PostGIS.

GeoJSON gjør noe av det samme, der sier de:

The order of elements must follow x, y, z order (easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system).

Altså: X er bort, og Y er opp. X kommer før Y. Legg også merke til notisen om projected og unprojected coordinate system, noe jeg ikke har nevnt. Kort fortalt: X og Y er ikke helt det samme som lon og lat.

Så langt har bare Google vært uenige med resten. Men here comes SOSI, et norsk format. Her er syntaksen for et punkt:
.PUNKT
..NORD tall
..ØST tall
(la oss for et øyeblikk ignorere bruken av Ø i kode). Her ser vi at Nord kommer før Øst (jeg er dog usikker på om det må ha denne rekkefølgen).

GeoTools har en artig take på det hele. Her har man en DirectPosition2D, som kan konstrueres med:

DirectPosition2D(CoordinateReferenceSystem crs,
double x,
double y)

Men dette er jo ganske standard, helt til du leser følgende:

Constructs a 2D position from the specified ordinates in the specified CRS. Despite their name, the (x,y) coordinates don’t need to be oriented toward (East, North). Those parameter names simply match the x and y fields. The actual axis orientations are determined by the specified CRS. See the class javadoc for details.

Her er det altså CRS, eller koordinatsystemet som betsemmer dette.

Ogå så har vi GML, her klarer jeg faktisk ikke å finne ut hva som skal i hvilken rekkefølge. Any clues?

Og med det tror jeg vi avslutter, før jeg begynner å snakke om Bounding Boxer (det får bli neste post i serien).

Og ja, jeg er ikke 100% sikker på at alt jeg har skrevet her er 100% riktig, så ikke ta alt du leser for god fisk, og finner du feil så si gjerne ifra!