Loading…
Tilbage

DAWA release


Miniformat til adresser og adgangsadresser

I DAWA er der nu mulighed for at få returneret et svar fra adresse- og adgangsadresseopslag med færre data. Et normalt adresseopslag returnerer udover selve adressen en lang række oplysninger om adressen: Det drejer sig f.eks. om hvilken zone, sogn, retskreds eller jordstykke adressen er beliggende i. Det er ikke alle applikationer, som har behov for disse ekstra oplysninger. Vi har derfor givet mulighed for kun at modtage de mest centrale oplysninger om en adresse: id, status, vejnavn, vejkode, husnummer, etage, dør, supplerende bynavn, postnummer, postnummernavn, kommunekode, koordinater samt adgangsadresse id.

Formålet med miniformatet er at tilgodese de anvendere af DAWA, som udelukkende er interesseret i selve adressen, og som ønsker at reducere svartider og datamængder. Det kunne f.eks. dreje sig om mobile løsninger, hvor båndbredden typisk er reduceret.

Miniformatet aktiveres ved at anvende struktur query parameteren med værdien mini.

Eksempler:

Adressesøgning i miniformat:
http://dawa.aws.dk/adresser?q=rentemestervej 8, 2400&struktur=mini

Den samme søgning i csv format:
http://dawa.aws.dk/adresser?q=rentemestervej 8, 2400&struktur=mini&format=csv

Samme søgning i adgangsadresser:
http://dawa.aws.dk/adgangsadresser?q=rentemestervej 8, 2400&struktur=mini

 

Forbedring af autocomplete

DAWA tilbyder adresse autocomplete funktionalitet, som gør det let for en udvikler at lave en løsning, som gøre det let for en bruger at indtaste en gyldig adresse i løsningen. Den nuværende autocomplete funktionalitet er lidt over et år gammel. I den periode har vi og anvendere fundet forbedringsmuligheder til autocomplete funktionaliteten. Disse forbedringer har vi nu implementeret, og eksempler på forbedringer kan læses i det følgende

Hov Agre 36, Omø, 4230 Skælskør:

Før release
Efter indtastning af ”hov ” præsenteres brugeren adresser, hvor nr 36 ikke er med. Det betyder, at brugeren skal indtaste en stor del af adressen (”hov agre 36”) før nr. 36 kan vælges. 

Efter release
Efter indtastning af ”hov ” præsenteres brugeren for vejnavnet ”Hov Agre”, som så kan vælges eller indtastningen kan fortsætte. 

Alleshavevej 12, 4593 Eskebjerg:

Før release 
Efter indtastningen af ”alleshavevej 1” bliver brugeren kun præsenteret for ”Alleshavevej 1, 4593 Eskebjerg” og ikke for nr. 10, 11, 12, 13... 

Efter release 
Efter indtastningen af ”alleshavevej 1” bliver brugeren præsenteret for Alleshavevej 1, 10, 11, 12 … 

Grønjordskollegiet 2, 1. 2205, 2300 København S:

Før relase
Efter indtastning af ” Grønjordskollegiet 2” præsenteres brugeren for adresser på 2. sal. Når brugeren indtaster ”Grønjordskollegiet 2, 1” præsenteres brugeren for adresser på ”Grønjordskollegiet 1”. Ved indtastning af ” Grønjordskollegiet 2, 1.” præsenteres brugeren for den korrekte adresse(r). 

Efter release
Efter indtastning af ” Grønjordskollegiet 2” præsenteres brugeren for adresser i stuen startende med dørnummer 2101, 2102 ... Når brugeren indtaster ”Grønjordskollegiet 2, 1” præsenteres brugeren for adresser på ”Grønjordskollegiet 2 1.” startende med dørnummer 2201, 2202 .... Og den korrekte adresse kan vælges. 

Nyborgvej 291, st. mf, 5220 Odense SØ:

Før release
Efter indtastning/valg af ”nyborgvej” listes først adresser i Ørbæk efterfølgende med adresser fra Saltum i blandet adresser fra Ørbæk. Efter ” Nyborgvej 291” listes i en ikke gennemskuelig rækkefølge. Ved indtastning af ”Nyborgvej 291, st” findes alle adresser i stuen i rækkefølgen 1, 2, 3, 4, mf, th, tv. 

Efter release
Efter indtastning/valg af ”nyborgvej” listes adresser i de forskellige postnumre hver især med første husnr på vejen. Efter ” Nyborgvej 291” listes først adresser i st (eventuelt først kældre) derefter 1., 2. 3. … Ved indtastning af ”Nyborgvej 291, st” findes alle adresser i stuen i rækkefølgen tv, mf, th, 1, 2, 3, 4.

Da alle autocomplete forbedringerne er etableret i det server baserede autocomplete API, behøver du ikke at opdatere din løsning for at drage fordel af forbedringer. Det gælder også hvis du anvender autocomplete komponenten.

 

Nærmeste DAGI inddeling

Bortset fra DAGI’s postnummerinddeling er alle DAGI inddelingerne afgrænset af kystlinjen. Da der er adresser, som ligger uden for kystlinjen, og som skal knyttes til DAGI inddelingerne, har vi i DAWA implementeret funktionalitet til at finde den nærmeste DAGI inddeling. Herved knyttes alle adresser med en gyldig placering til de forskellige DAGI inddelinger uanset om de ligger i havet eller ej. Denne funktionalitet udstiller DAWA nu også i forbindelse med DAGI’s reverse geokodnings funktionalitet vha. nærmeste query parameteren.

Eksempler:

Nærmeste kommune ude i Roskilde Fjord:
http://dawa.aws.dk/kommuner?x=12.054613430562348&y=55.709279836294584&nærmeste

Nærmeste sogn samme sted:
http://dawa.aws.dk/sogn?x=12.054613430562348&y=55.709279836294584&nærmeste

 

Udvidelse af replikerings API’et

Replikerings API’et udvides med mulighed for at replikere vejstykkers postnummer tilknytning. 

 

Andre forbedringer

WFS performanceforbedringer.

GeoJSON understøtter NDJSON.

Profilbillede

Rigtig gode tiltag.

Stefan Thordarson

Først vil jeg sige at vores brugere bliver glade for de gode tiltag.

Især casen med alleshavevej 1  --> alleshavevej 1, 10, 11 osv.  Tak for dette.

 

Vi oplever dog desværre at Autocomplete ikke virker f.o.m. 1.december, så vi mistænker at der er opstået en fejl ifm. version 1.9.36.

Problemet har relation til parameteren adgangsadresseid (fandt jeg frem ved udelukkelses-metoden)

Flg. query har virket fint i flere måneder indtil 1. eller 2.december:

https://dawa.aws.dk/autocomplete?q=Ternevej+3%2C+Egense%2C+9280+Storvorde&type=adgangsadresse&adgangsadresseid=0a3f509b-68cf-32b8-e044-0003ba298018&caretpos=34&fuzzy=&kommunekode=851 

men fejler nu med InvalidRequestError: probably due to bad query parameters

Fjerner man parameteren adgangsadresseid, så returnerer forespørglen data OK.

 

Jeg kan selvfølgelig ikke være sikker på at ovenstående er indført i version 1.9.36

 

Håber at nogen kan hjælpe med at opklare ovenstående.  

Mvh, Stefan Thordarson

Hej Stefan,

Vi beklager fejlen, som vil blive rettet på mandag.

Fejlen opstår på grund af kombinationen af parametrene type=adgangsadresse og adgangsadresseid=0a3f509b-68cf-32b8-e044-0003ba298018. Det er meningen, at parameteren adgangsadresseid skal anvendes sammen med type=adresse, hvorved man så modtager adresser på den givne adgangsadresseid.

I forrige relealse blev type=adgangsadresse ignoreret hvis der var en adgangsadresseid parameter, således at der faktisk blev søgt i og returneret adresser, selvom parameteren er angivet til type=adgangsadresse. Dette var egentlig ikke en tiltænkt opførsel, og var egentlig også fejlagtigt, da type=adgangsadresse burde resultere i, at man modtager adgangsadresser, men at der faktisk returneres adresser.

I den nye release er der en fejl, som gør at forespørgslen fejler helt. Den vil blive rettet på mandag, sådan at opførslen bliver som før (dvs. type parameteren ignoreres). Indtil vi har rettet dette kan du løse problemet i din egen løsning ved at angive type=adresse når du anvender adgangsadresseid parameteren.

Hej Anders

Tak, også til Finn Jordal, for den gode forklaring og tippet til løsningen med type=adresse, det har jeg lagt ind i vores løsning og det virker fint.

Super flot og hurtig service, lørdag morgen. Vi har vigtigt møde på mandag om vores web-løsning, hvor adresse-søgningen er vigtig brik, så virkelig godt at I reagerede så hurtigt - thumbs up.

Mvh, Stefan