Koordinatkrangel i NVDB api V1

Vi har nettopp satt i produksjon en ny versjon 1 av NVDB api.

  • Hvis du bruker lengde- og breddegrad så er rekkefølgen nå er byttet om – eller mer presist: Vi har byttet tilbake slik det var før juni 2016.
  • Vi serverer nå kun 2D koordinater. Ikke en blanding av 2D og 3D.

Mange eksisterende klienter fikk problemer på grunn av dette. Derfor ruller vi V1 tilbake slik det var før juni 2016. Beklager at dette tok tid!

Merk at V1 nå avviker fra V2 på de to punktene over.

Koordinatkrangel.

Dette med rekkefølgen på koordinater for lengde- og breddegrad har gitt mye hodebry.

  • Matematikere og programmerere har ofte foretrukket rekkefølgen X, Y, det vil si rekkefølgen (øst, nord) – eller (lon, lat) (lengdegrad, breddegrad).
  • Geografer har likt best rekkefølgen (grader N, grader E), eller (lat, lon).

Heldigvis har vi internasjonal standardisering. V2 vil følge denne standarden, og det samme gjør skriveAPI’et. Der er det (lat, lon) som gjelder, evt (lat, lon, z) for 3D koordinater.

For V1 gjør vi det motsatt: Her tilbyr vi lengde- og breddegrad som (lon, lat). Altså motsatt av standarden. Og uten høydeinformasjon.

<geometriWgs84>POINT (10.63317257269053 63.42266891319099)</geometriWgs84>

Dette gjelder altså bare lengde- og breddegrad: For UTM-koordinatene er det heldigvis ingen som krangler på rekkefølgen.

Og så er det bare å beklage – både at vi gjorde denne endringen i utgangspunktet, og at det tok såpass lang tid før vi fikk skrudd det tilbake.