Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 10 15:26

    hansog on V3

    Rute tjeneste flyttet til /beta… (compare)

  • Sep 10 15:04

    hansog on NVDB-4376

    (compare)

  • Sep 10 15:04

    hansog on V3

    Made some Result-classes static NVDB-4376 RoadNetRouteClient Merge pull request #59 from nvd… (compare)

  • Sep 05 14:54

    computerlove on NVDB-4376

    Made some Result-classes static NVDB-4376 RoadNetRouteClient (compare)

  • Sep 03 13:56

    computerlove on master

    2019.10.0 (compare)

  • Sep 03 13:32

    computerlove on master

    2019.11.0 (compare)

  • Sep 03 13:25

    computerlove on master

    Reverserte rekkefølge på versjo… (compare)

  • Sep 03 12:43

    krimjo on V3

    Updated readme (compare)

  • Sep 03 12:38

    krimjo on V3

    Updated readme (compare)

  • Sep 03 11:45

    vegdata on nvdb-read-api-v3-client-1.0.1

    (compare)

  • Sep 03 11:41

    krimjo on V3

    Updated bintray name to nvdb-re… (compare)

  • Sep 03 11:38

    vegdata on nvdb-read-api-v3-client-1.0.0

    (compare)

  • Sep 03 11:35

    krimjo on nvdb-read-api-v3-client-1.0.0-alpha

    (compare)

  • Sep 03 11:34

    krimjo on V3

    Updated tag prefix to nvdb-read… (compare)

  • Sep 03 11:32

    krimjo on V3

    Updated artifactId to nvdb-read… (compare)

  • Sep 03 08:51

    computerlove on NVDB-4152

    (compare)

  • Sep 03 08:51

    computerlove on V3

    NVDB-4152: Updated client to re… NVDB-4152: Fixed veglenkesekven… NVDB-4152: startposisjon/sluttp… and 11 more (compare)

  • Sep 03 08:47

    krimjo on NVDB-4152

    NVDB-4152: Implementing stedfes… (compare)

  • Sep 03 08:31

    krimjo on NVDB-4152

    NVDB-4152: ResponseRevision 1, … (compare)

  • Sep 03 08:14

    krimjo on NVDB-4152

    NVDB-4152: ResponseRevision 1, … (compare)

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
Marvin Bredal Lillehaug
@computerlove
Vet ikke. Vi finner ut av det
Marvin Bredal Lillehaug
@computerlove
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.
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?
men den ser ikke ut til å nå APIet, så da gir den ikke så mye verdi
Marvin Bredal Lillehaug
@computerlove
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.
  1. 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

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.