nvdb-vegdata/api-les-v3

Tilbakemeldinger på NVDB API Les V3 https://nvdbapilesv3.docs.apiary.io/ https://github.com/nvdb-vegdata/endringslogg/blob/master/APILESV3.md Miljøer: https://apilesv3.test.atlas.vegvesen.no https://pm1.utv.vegvesen.no/nvdb/api/v3/ https://apilesv3.utv.atlas.vegvesen.no https://nvdbw01.kantega.no/nvdb/api/v3/ Referanseklient: https://github.com/nvdb-vegdata/nvdb-api-client/tree/V3

Arve Seljebu

@arve0

Forresten, hvem er forvalter og systemeier av v3 API-et? Tenkte forhøre oss om retningslinjer (tillatelse, oppetid, osv) for bruk av API-et i Vegloggen.

Marvin Bredal Lillehaug

@computerlove

Terje Brasethvik (@vegvesen-brase) er systemeier. Forvalter er Jan Tore Berget

Arve Seljebu

@arve0

Takk :-)

Arve Seljebu

@arve0

Har det skjedd noe på apilesv3.utv.atlas.vegvesen.no siden i går? Mener oppslag på vegsystemreferanse fungerte, men får 500 i dag.

$ curl -v "https://apilesv3.utv.atlas.vegvesen.no/veg?vegsystemreferanse=EV6%20S55D1%20M1000"
*   Trying 146.2.0.167...
* TCP_NODELAY set
* Connected to apilesv3.utv.atlas.vegvesen.no (146.2.0.167) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=NO; postalCode=0667; ST=Oslo; L=Oslo; street=Brynsengfaret 6A; O=Statens vegvesen; OU=Orgnr 971032081MVA; OU=Provided by Statens Vegvesen Vegdirektoratet; OU=Commfides Premium SSL SGC Wildcard; CN=*.utv.atlas.vegvesen.no
*  start date: Nov 22 00:00:00 2017 GMT
*  expire date: Nov 21 23:59:59 2020 GMT
*  subjectAltName: host "apilesv3.utv.atlas.vegvesen.no" matched cert's "*.utv.atlas.vegvesen.no"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Organization Validation Secure Server CA
*  SSL certificate verify ok.
> GET /veg?vegsystemreferanse=EV6%20S55D1%20M1000 HTTP/1.1
> Host: apilesv3.utv.atlas.vegvesen.no
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 500 
< Access-Control-Allow-Methods: GET, POST, OPTIONS
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: accept, x-client, origin
< Access-Control-Max-Age: 1728000
< Cache-Control: no-cache
< X-Robots-Tag: none
< X-REQUEST-ID: e5b44600-64c0-c87d-65a3-fbda675a7227
< Content-Type: application/json;charset=utf-8
< Content-Length: 124
< Date: Tue, 02 Jul 2019 06:04:51 GMT
< Set-Cookie: 8d212c34ebed62f8e9a139fcb8dd4db2=dc1d03c75118ec493dfe135aa7a1c3aa; path=/; HttpOnly; Secure
< 
[ {
    "code" : 5000,
    "message" : "Det har dessverre oppstått en feil!",
    "help_url" : "https://api.vegdata.no"
} ]

Arve Seljebu

@arve0

Får samme på posisjon: https://apilesv3.utv.atlas.vegvesen.no/posisjon?lat=63.03689426379423&lon=10.296212892301309&srid=4326

Arve Seljebu

@arve0

Endepunktet https://nvdbw01.kantega.no/nvdb/api/v3/ fungerer.

Marvin Bredal Lillehaug

@computerlove

Vet ikke. Vi finner ut av det

Marvin Bredal Lillehaug

@computerlove

Bare litt miljøknot. Bruk https://nvdbw01.kantega.no/nvdb/api/v3/ eller https://pm1.utv.vegvesen.no/nvdb/api/v3/ inntil videre

Arve Seljebu

@arve0

pm1 er også nede:

$ curl -v https://pm1.utv.vegvesen.no/nvdb/api/v3/
*   Trying 146.2.0.253...
* TCP_NODELAY set
* Connected to pm1.utv.vegvesen.no (146.2.0.253) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=NO; postalCode=NO-0033; ST=Oslo; L=Oslo; street=Brynsengfaret 6A; postOfficeBox=Postboks 8142 Dep; O=Statens vegvesen; OU=Orgnr 971032081MVA; OU=Provided by Statens Vegvesen Vegdirektoratet; OU=Commfides Unified Communications; CN=pm1.utv.vegvesen.no
*  start date: Nov 29 00:00:00 2016 GMT
*  expire date: Nov 29 23:59:59 2019 GMT
*  subjectAltName: host "pm1.utv.vegvesen.no" matched cert's "pm1.utv.vegvesen.no"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Organization Validation Secure Server CA
*  SSL certificate verify ok.
> GET /nvdb/api/v3/ HTTP/1.1
> Host: pm1.utv.vegvesen.no
> User-Agent: curl/7.54.0
> Accept: */*
> 
* LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54
* stopped the pause stream!
* Closing connection 0
curl: (56) LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54

Forresten, er det noen les-API-miljø som har ny fylkesstruktur? (eksternt eller internt)

Marvin Bredal Lillehaug

@computerlove

Neida, den er oppe. Du har sikkert bare ikke åpning mot den fra der du sitter.

https://www.utv.../v3 ser ut som er den eneste. https://www.utv.vegvesen.no/nvdb/api/v3/omrader/fylker.json

Arve Seljebu

@arve0

Neida, den er oppe. Du har sikkert bare ikke åpning mot den fra der du sitter.

Ah, har tilgang til pm1 hos SVV.

https://www.utv.../v3 ser ut som er den eneste. https://www.utv.vegvesen.no/nvdb/api/v3/omrader/fylker.json

Takk 🙂

Arve Seljebu

@arve0

www.utv.../v3 ser ut til å ha samme feil som apilesv3.utv.atlas.vegvesen.no, er det samme system kanskje?

Nei...atlas har gamle regioner.

Marvin Bredal Lillehaug

@computerlove

Jo, de er like.

Arve Seljebu

@arve0

Hm, må være jeg som blingset

Håkon Kippe

@hakonki

Hei, jeg er også utvikler på Vegloggen (kollega med Arve). Jeg lurer på om dere har en URL jeg kan nå Vegkart versjon 3?

jeg prøvde denne: https://www.utv.vegvesen.no/nvdb/vegkart/v3/

men den ser ikke ut til å nå APIet, så da gir den ikke så mye verdi

Marvin Bredal Lillehaug

@computerlove

https://vegkart-v3.utv.atlas.vegvesen.no og https://www.utv.vegvesen.no/nvdb/vegkart/v3/ går mot apilesv3.utv.atlas.vegvesen.no
https://pm1.utv.vegvesen.no/nvdb/vegkart/v3 mot pm1.utv.../v3

Håkon Kippe

@hakonki

den siste fungerte

takk! :)

Marvin Bredal Lillehaug

@computerlove

Litt problemer med det første miljøet, forventet i orden ca torsdag

Arve Seljebu

@arve0

Kanskje ikke deres bord, men kanskje dere vet hvem som vet.

Forventes NVDB les API v3 å være klart 1. august med tanke på datainnhold også? Eksempelvis mangler noen fylker nå,

$ curl -s https://apilesv3.utv.atlas.vegvesen.no/omrader/fylker | jq .[].nummer
3
11
18
34
38
42
46
54

og vegobjekter peker til fylker som ikke eksisterer:

curl 'https://apilesv3.utv.atlas.vegvesen.no/vegobjekter/535?inkluder=egenskaper'|jq '.objekter[].egenskaper[]|select(.id == 4582)|.verdi'
1
2
3
4
5
6
7
8
9
10
11
12
14
15
18
19
20
50

Marvin Bredal Lillehaug

@computerlove

Områdene i den databasen det miljøet går mot har vært litt frem og tilbake.

august: vi leverer en versjon til akseptansetest, og det er forventet at NVDB les API v3 vil være i produksjon i starten av november.

Det kommer en ny instans av NVDB i pm1.utv../v3 i starten av neste uke

Arve Seljebu

@arve0

takk 👍

Arve Seljebu

@arve0

Heisann :-) Jeg leter etter en definisjon av ny vegsystemreferanse, jeg har sett på https://nvdbapilesv3.docs.apiary.io/#/data-structures/0/vegsystemreferanse og kjenner til oppbygningen, men skulle gjerne hatt en formell beskrivelse. Eksempelvis, lurer jeg på:

Hvilke deler av referansen er tillatt å utelate (alt utenom vegidentifikator, seksjon, delseksjon og meter?)
Er mellomrom " " eneste godkjente separator? Tillates flere mellomrom?
Kan deler av referansen stokkes om på?

Arve Seljebu

@arve0

Ah, en kan klikke på titlene! Det var ikke et åpenbart bruksmønster. Da holder dokumentasjonen for nå, men tar gjerne en formell offentlig beskrivelse som kan lenkes til hvis det finnes.

Forresten så er eksemplet som gis, EV6 S9D1 M6384-6462 K1D1 M10-29, ikke gyldig:

code 4005, Ikke gyldig vegreferanseparameter 'vegsystemreferanse' med verdi: EV6 S9D1 M6384-6462 K1D1 M10-29

https://nvdbw01.kantega.no/nvdb/api/v3/veg?vegsystemreferanse=EV6%20S9D1%20M6384-6462%20K1D1%20M10-29&srid=4326

Arve Seljebu

@arve0

Angående utelating av felt, indikeres at kun kategori, nummer og fase er obligatorisk her:

https://api.vegdata.no/v3/vegsystemreferanse.html#eksempler-på-vegsystemreferanser

Men det tillates ikke mot API-et.

Arve Seljebu

@arve0

Også usikker på kortversjon for kryssystem, kryssdel, sideanlegg og sideanleggsdel. Stemmer dette?

KS = kryssystem
KD = kryssdel
SA = sideanlegg
SD = sideanleggdel

KS forutsetter KD. SA forutsetter SD.

aleksamd

@aleksamd

Heihei! Lurer også på et par småting:
Når man søker på segmentert vegnett står det oppgitt at man skal kunne hente vegnett slik det var på et gitt tidspunkt. Slik det er nå så får man kun resultater om man søker for tidspunkt etter endringsdatoen for nye vegnummer (2019). Man får ikke resultater for tidligere enn dette, hverken på ny eller gammel vegnummer. Er dette uferdig eller tiltenkt?

Det står i dokumentasjonen at om man har på historisk så skal man få veier med sluttdato. Tenkes dette som veier som får nytt vegnummer og dermed er "avsluttet" eller er det kun veier som blir fjernet?

Marvin Bredal Lillehaug

@computerlove

@arve0

Forresten så er eksemplet som gis, EV6 S9D1 M6384-6462 K1D1 M10-29, ikke gyldig:
Hvor står det eksemplet?
Den spørringen gir ikke mening. Et kryssystem/sideanlegg finnes kun ett sted, så alle referanser med kryss/sideanlegg kan ha kun én meterverdi på strekningen. EV6 S9D1 M6384 K1D1 M10-29 ville vært gyldig.
Den minste referansen man kan ha er slik: E6, altså vegkategori og -nummer. Da tolkes det som EV6. Fase og Trafikantgruppe er de delene som er mulig å droppe. For de andre delene er alt som kommer før påkrevd. Men en referanse kan ikke ha både kryss og sideanlegg.

Angående utelating av felt, indikeres at kun kategori, nummer og fase er obligatorisk her:
https://api.vegdata.no/v3/vegsystemreferanse.html#eksempler-på-vegsystemreferanser
Men det tillates ikke mot API-et.

/veg er litt mer kresen, den krever at det angis strekning og meter. For filtrering av objekter er det lov med mindre

Marvin Bredal Lillehaug

@computerlove

@aleksamd
Det blir generert nye vegsystemreferanseobjekter(915-920, disse ligger til bunn for hele vegsystemreferansen) for vegreferanse(532) fra 1.1.2018. For data før denne datoen vil det kun eksistere data fra Vegsystem(915).
På grunn av problemer med datakvalitet på et knippe objekter finnes ikke historiske data ennå, men det kommer.

Jeg har ikke helt oversikt over hvordan endring av vegnummer gjøres, så kan ikke svare konkret på det du spør om akkurat nå.
Det vi kaller segmentert vegnett er satt sammen av vegnettet(veglenkesekvenser med veglenker) og vegsystemreferanseobjekter(og kontraktsområder og riksvegruter). Objektene er stedfestet på vegnettet.
Så et historisk segment er enten av veglenken har sluttdato eller at noen av objektene stedfestet på objektet har sluttdato.
Så om jeg skal tippe vil du kunne finne et segment for det gamle vegnummeret og ett for det nye. I alle fall når vi får på plass alle historiske data.

Se også «Håndbok V830 Nasjonalt vegreferansesystem» https://www.vegvesen.no/_attachment/61505
Det er håndboka for den gamle vegreferansen(532)

Arve Seljebu

@arve0

Hvor står det eksemplet?

I dokumentasjonen på https://nvdbapilesv3.docs.apiary.io/#/data-structures/0/vegsystemreferanse Direktelenken fungerer ikke, men du kan søke etter EV6 S9D1 M6384-6462 K1D1 M10-29, så finner du det raskt ;-)

Den minste referansen man kan ha er slik: E6, altså vegkategori og -nummer. Da tolkes det som EV6. Fase og Trafikantgruppe er de delene som er mulig å droppe.

👍

Relatert til fase, så feiler fiktiv ef6 s1 d1 m1:

{
  statusCode: 422,
  body: '[ {\n' +
    '    "code" : 4005,\n' +
    `    "message" : "Ikke gyldig vegreferanseparameter 'vegsystemreferanse' med verdi: ef6 s1 d1 m1",\n` +
    '    "message_detailed" : "",\n' +
    '    "help_url" : "https://api.vegdata.no/v3/vegsystemreferanse.html"\n' +
    '} ]'
}

Arve Seljebu

@arve0

/veg er litt mer kresen, den krever at det angis strekning og meter. For filtrering av objekter er det lov med mindre

Gir mening.

Marvin Bredal Lillehaug

@computerlove

Skal undersøke hvorfor EF6 påstås å være ugyldig

Marvin Bredal Lillehaug

@computerlove

Ny versjon lagt ut på www.utv.vegvesen.no/nvdb/api/v3 og https://apilesv3.utv.atlas.vegvesen.no

2019.11.0

Response fra /veg har riktig kommune (var alltid 0)
Stedfesting for Svingerestriksjon er komplett representert
Responsrevisjon 1
Første versjon av referanseklient i java releaset.

Arve Seljebu

@arve0

Hei! Er det med i planen å støtte desimaler av koordinat?

Eksempelvis:

$ curl -s "https://nvdbw01.kantega.no/nvdb/api/v3/veg.json?vegsystemreferanse=FV21S2D1m1" | jq .geometri
{
  "wkt": "POINT Z(316161 6638660 167.96876841)",
  "srid": 6173
}

Her er høyden gitt med 10^-8 meters nøyaktighet, men nord/øst kun i meter. Ser av koordinatsystemet at nøyaktigheten er 1 meter, men regner med koordinatene er lagret med nøyaktighet ned mot cm :-)

Marvin Bredal Lillehaug

@computerlove

@arve0 Får du alltid hele meter? Mener det skal være desimaler.

noen steder har vi atomkjerne-nøyaktighet på deismalene, det skal fikses en gang

Arve Seljebu

@arve0

Får du alltid hele meter?

Ja, har prøvd de 100 første metrene i F21 og E6:

for i in (seq 1 100);
    curl -s "https://nvdbw01.kantega.no/nvdb/api/v3/veg.json?vegsystemreferanse=FV21S1D1m$i" | jq .geometri
end

Men ser ut som nøyaktigheten er bra nok for formålet, har ikke klart å finne eksempler der det nøyaktigheten er et problem for Vegloggen enda.

Marvin Bredal Lillehaug

@computerlove

Hmm.
i koden står det // Only need precision down to one meter in this response

Marvin Bredal Lillehaug

@computerlove

Men nå er det tre desimaler på alt.

Skal undersøke hvorfor EF6 påstås å være ugyldig

Ved parsing hentet vi gyldige verdier fra en egenskap på 532. Når vi henter fra tilsvarende egenskap på 915 gikk det litt bedre.

Where communities thrive

People

Repo info

Activity

2019.11.0