nvdb-vegdata/api-les-v3

Tilbakemeldinger på NVDB API Les V3 https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/ https://github.com/nvdb-vegdata/endringslogg/blob/master/APILESV3.md Miljøer: https://nvdbapiles-v3.atlas.vegvesen.no https://nvdbapiles-v3.test.atlas.vegvesen.no https://nvdbapiles-v3.utv.atlas.vegvesen.no https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no Referanseklient: https://github.com/nvdb-vegdata/nvdb-api-client Rapportering av datafeil: https://fiksvegdata.opentns.org

Torbjørn Gjendem

@torgje

18. okt kl. 8:30: ATM-database (test-miljø) oppgradering

Database oppgraderes, og det meste i testmiljøet vil være nede fra 8:30.
Samtidig vil vi klone produksjonsbasen over i ATM for å få ferskere data i testmiljø. Nye data må da indekseres og vi venter at testmiljøet er oppe i normal drift først tirsdag 19. oktober.

escuelle

@escuelle

Attributtet sist_modifisert inneholder informasjon om når et objekt sist ble endret. Er det også mulig å hente informasjon om hvem som er ansvarlig for den endringen?

1 reply

Simen Aardal Ulsaker

@sulsaker

Hei, jeg er interessert i å få ut historiske data på vegobjekter (f.eks. parkeringsplasser). Får ut tidligere versjoner av gyldige objekter gjennom /versjoner-spørring, men er det mulig å få ut også data på vegobjekter som ikke lenger er gyldige (eks. parkeringsplasser som ikke finnes lenger)? Mvh

4 replies

IvarL

@IvarL

Hei, jeg driver å tester en del mot https://nvdbapiles-v3.atlas.vegvesen.no ved bruk av Postman og i følge dokumentasjonen så kan man benytte vegsystemreferanse som parameter til endepunktet /vegobjekter, men jeg får error 4013 Ukjent parameter: vegsystemreferanse når jeg forsøker dette. Jeg får derimot til å benytte vegsystemreferanse som parameter til endepunktet /vegobjekter/{vegobjekttypeid}, men det betyr at jeg må iterere over objekttyper får å kunne hente alle objekter på en strekning/delstrekning. Vil parameter vegsystemreferanse bli implementert på endepunktet /vegobjekter ?

2 replies

kolsmyr

@kolsmyr

Hej, jag gör parallella anrop mot vegobjekter med unika idn men får följande fel för random vegobjekt/id
"Ugyldige tegn i 'veglenkesekvens' field: '0.73474087-0.99409165@384020'. Gyldig eksempel: 0.6-0.9@42364"

Jag fann också tidigare ställd fråga:
"@svein-hallsteinsen
@computerlove - til informasjon så fant jeg ut hvordan man reproduserer bugen jeg rapporterte i går (Ugyldige tegn i 'veglenkesekvens' field..., se lenger opp). Hvis man kaller flere samtidige kall på et vegobjekt oppstår problemet ganske ofte. Vi henter ut flere attributter for en og samme tunnel samtidig i flere tråder, gjør vi dette i serie fungerer det alltid
For vår del går det nok fint å gjøre det i serie i stedet, men er kanskje en race condition eller noe sånt en plass"

Men där står det att felen ofta uppstår om man gör flera parallella anrop mot samma Vegobjekt, som jag förstår det.
Jag försöker anropa flera vegobjekt samtidigt.
Något ni har stött på tidigare?

Tacksam för svar.

Tobias Andersen

@turbolego

Noen her som har erfaring med CORS error fra https://nvdbapiles-v3.atlas.vegvesen.no/ ?

prøver å kjøre en GET

Access to XMLHttpRequest at 'https://nvdbapiles-v3.atlas.vegvesen.no/posisjon?maks_avstand=100&nord=6646031.11272874&ost=248289.47397246864' from origin 'http://localhost:4200' has been blocked by CORS policy: Request header field user-id is not allowed by Access-Control-Allow-Headers in preflight response.

Taras

@Taraskin_gitlab

Hi @All,
https://nvdbapiles-v3.utv.atlas.vegvesen.no/vegobjekter/60/272390601/2

...
<strekning>
<id>-1</id>
<versjon>-1</versjon>
<strekning>16</strekning>
<delstrekning>20</delstrekning>
<arm>true</arm>
<adskilte_løp>Med</adskilte_løp>
<adskilte_løp_nummer>4-1</adskilte_løp_nummer>
<trafikantgruppe>K</trafikantgruppe>
<meter>2872.026</meter>
<retning>MED</retning>
</strekning>

are -1 values correct for strekning's ID and VERSJON:
<id>-1</id>
<versjon>-1</versjon>
?

2 replies

Magnus Kvendseth Øye

@magnusoy

INFO: NVDB blir oppdatert 9/11 2021 kl. 18:00. Alle data og tilgang til NVDB blir utilgjengelig under oppdatering som er bergenet å være i 6 timer. Ut over natten venter vi noe ustabilitet, men forventer å være tilbake i normalstatus innen 8:00 10/11.

2 replies

CalHeg

@CalHeg

Hei! Vi opplever at spørringer mot objekttyper 521, 524 & 525 plutselig ikke lenger fungere feks fra: https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/525 får vi "<message>Vegobjekttype er ikke indeksert!</message>

<message_detailed>Vegobjekttypen 525 er ikke indeksert og finnes ikke i gjeldende datakatalog.</message_detailed>"

2 replies

escuelle

@escuelle

Hei! Vi opplever at døtre fortsetter å referere til sine mødre i les-API selv etter at de har blitt fjernet fra sine mødre og lurer på om det er det saken NVDB-6365 i deres utviklingsplan vil fikse?

1 reply

Magnus Kvendseth Øye

@magnusoy

INFO: Problemer i NVDB IND har ført til at ingen tranaskjoner har blitt inkrementelt indeksert. Dette betyr at endringer gjort etter 00:00 16.11.2021 ikke er synlig i NVDB Les API. Som følger av feilen ble vi nødt til å kjøre full reindeksering. Dette vil ta 24 timer, og endringer gjort gjennom NVDB API Skriv fra nå og utover vil bli satt i kø og blir deretter håndtert fortløpende etter at full reindeksering er fullført. NVDB API Les vil fortsette å fungere, men ytelse vil være preget av indekseringen.

Magnus Kvendseth Øye

@magnusoy

INFO: Generelle nettverksproblemer i Statens vegvesen sin infrastruktur. Systemer i produksjon vil være til tider utilgjengelig. Kommer med oppdatering når det har stabilisert seg.

1 reply

Olav Dahl Solstad

@olav89

Prøver å laste ned binærfiler fra nvdbapiles-v3-stm.utv.atlas.vegvesen.no, men får 500 på alle jeg prøver. Eks: https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no/vegobjekter/446/717405137/1/egenskaper/7900/37025/binaer

1 reply

Marius Thorvik

@mThorvik

Hei! Jeg forsøker å hente ut vegreferanser fra v3 med /posisjon, og vil filtrere kun på Fase og Trafikantgruppe. Finnes det funksjonalitet for å ignorere filtrering på Vegkategori, a la "vegreferanse=?V" i v2?

1 reply

Thomas Brekk Unnvik

@brekk75

Hei! Når man bruker funksjonen "/posisjon" for å finne en bestemt vegreferanse får man tilbake en vegreferanse med bruk av mellomrom og store bokstaver som vist på skjermbildet under. Hvis man så skal søke videre på vegobjekter med denne vegreferansen må man derimot bruke en versjon med små bokstaver (bortsett fra for vegtype) og uten mellomrom. Er det noen enkel måte å gjøre dette på uten å måtte selv skrive en funksjon som konverterer mellom formatene? Kunne det ellers vært en ide å harmonisere formatene slik at man enkelt kan bruke det ene til det andre? (er ny på å bruke APIet, så hvis det er noe her jeg har oversett av funskjonalitet tar jeg gjerne imot tips)

2 replies

mario.cocozza

@mario.cocozza:matrix.org

[m]

Hei
I datakatalogen for Elektrisk anlegg finnes det en egenskap Målepunkt ID. Vil vi kunne via LES apiet kunne hente ut MålepunktsID basert på et vegobjekttype/vegobjekt?

1 reply

Vegard Stene

@vstene

Hei. Er det mulig å få endringslogg på versjon som ble lansert 20. januar? Ser at endringsloggen på github henger litt etter

1 reply

Magnus Kvendseth Øye

@magnusoy

INFO: NVDB API LES kan blir utilgjengelig i helgen. Viser til vegdata for mer informasjon: https://www.vegdata.no/2022/01/27/varsel-mogleg-nedetid-i-nvdb-les-i-helga/

Anders Thorsen

@andersthorsen

Hei! Veldig spennende api. Men er det mulighet for å fikse valideringsfeilene i openapi-definisjonen?

4 replies

Feilene over er hentet fra valideringen på https://editor.swagger.io/

escuelle

@escuelle

De aksepterte chiffersuitene er forskjellige mellom nvdbapiles-v3.test.atlas.vegvesen.no og nvdbapiles-v3.atlas.vegvesen.no. Det ser ut til at noen få chiffersuiter har blitt fjernet i ATM-miljøet nylig. Vet ni mer om denne endringen? Vil den samme endringen bli innført på produksjonsmiljøet snart?

5 replies

adriankreutz

@adriankreutz

hei, det virker som det er noen problemer på paginering ved uthenting av segmentert vegnett når man har kontraktsområde som filter og kontraktsområdet har '&' i navnet. eks: https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert?kontraktsomrade=1544+Tunnelvask+M%26R+2020-2023&detaljniva=VT,%20VTKB&antall=100
href til neste side blir: https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert?antall=100&R+2020-2023=&start=A5421GTyTMu2rgs7ycPybh246zxhTwTa9tFoVnkZkciADRu2yjoyBkbQj238r6LXxh5wQfRAo9PPZbmQDhskfDuTznoQ1G2cxdxadqsL1oBrokLBN15AHShc1VDSsvSWfdg6nfbjm3tmndbSXUgcpKsRYhgngrdnDisv&kontraktsomrade=1544+Tunnelvask+M&detaljniva=VT%2C%20VTKB
Kontraktsområdet har blitt endret, deler av kontraktsområde ligger retter etter antall=100 og resten ligger ved kontraktsområde=
kontraktsområdet i dette tilfellet er "1544 Tunnelvask M&R 2020-2023"

6 replies

Hans Engstad

@HansEngstad_gitlab

Hei,

Jeg prøver å generere en C# klient fra deres OpenAPI definisjon. Det ser ut som at yaml-filen fra https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/openapi.yaml ikke er gyldig for meg. Jeg bruker NSwagStudio, og får følgende feilmelding [1].

Det er en streng som går over 2 linjer på linje 242 i yaml-filen:

description: "Angir hvilket geografisk referansesystem geometrien skal returneres
i. \n Mer informasjon: EPSG:5973 [EPSG:4326]

Hvis jeg endrer denne til å gå over én linje i stedet, får jeg en annen feilmelding [2].

Er det noen som har noen tips til hvordan jeg kan generere en C# klient for NVDB APIet?

Legger ved feilmeldingene [1] og [2] som kommentarer for at ikke meldingen skal bli for lang.

Hans Engstad
NTNU

4 replies

skjalgsk

@skjalgsk

Hei, før jul hentet jeg bl.a alle versjoner av Trafikkmengde i Oslo kommune, og fikk med geometri (egenskap "geometri") på alle objekter. Men nå er det kun siste versjon av vegobjekter som har geometri hvis man henter dem via /vegobjekter/{vegobjekttypeid} og spesifiserer "alle_versioner=true". Men hvis man henter historiske versjoner av objekter direkte fra /vegobjekter/{vegobjekttypeid}/{vegobjektid}, så får man fortsatt geometri på de historiske versjonene. Er dette en feil? Eller det en endring? Det vil gjøre at henting av data vil gå fra å ta et par minutter til timer og dager hvis jeg skal hente individuelle objekter og overholde rate-limit, fordi jeg henter også mange andre objekttyper og ønsker å få med historiske versjoner.

4 replies

Magnus Kvendseth Øye

@magnusoy

INFO: NVDB API LES sitt ATM miljø (test-miljø) blir utilgjengelig fra 25.02.2022 Kl: 10:00 til 28.02.2022 i forbindelse av at vi skal flytte over data fra PROD databasen. Dette medfører også at endringer fra NVDB API Skriv ATM ikke blir synlige i denne tidsperioden.

Magnus Kvendseth Øye

@magnusoy

INFO: Vi er nødt til å ta ned API-Les i ATM/test-miljø for å teste en endring vi planlegger i PROD til helgen. ATM Les vil da være nede til i formiddag en gang.

Torbjørn Gjendem

@torgje

INFO: planlagt aktivitet i NVDB, med forbehold - https://www.vegdata.no/2022/03/09/planlagt-oppdatering-av-nvdb-i-helga-11-13-mars-2022-med-forbehald/

oveien

@oveien

Hei. Jeg lagde en enkel kartløsning for å se utvikling i trafikkmengde fra år til år, og hentet ut alle versjoner for mitt fylke en gang i året-ish. Når jeg prøver å oppdatere data nå, så får jeg ikke med historiske data. Er det gjort endringer rundt "alle_versioner=true" i det siste? Jeg bruker endepunktet: https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/540?inkluder=metadata&fylke=50&vegsystemreferanse=F&alle_versjoner=true

5 replies

Magnus Kvendseth Øye

@magnusoy

INFO: Infrastruktur problemer fører til at flere av systemene er nede. Drift er på saken og mer informasjon vil komme senere.

Tobias Andersen

@turbolego

Jeg trenger hjelp med å teste ut NVDB i localhost.
Får CORS error når jeg prøver å hente data fra STM:

Access to XMLHttpRequest at 'https://nvdbapiles-v3.atlas.vegvesen.no/posisjon?maks_avstand=100&nord=6646031.11272874&ost=248289.47397246864' from origin 'http://localhost:4200' has been blocked by CORS policy: Request header field user-id is not allowed by Access-Control-Allow-Headers in preflight response.

1 reply

adastachowiak

@adastachowiak

Hello. I have a problem. In out app we had this request, nothing changed in our side but somehow it stoped working. We're getting empty response on that request. I was digging a little bit in documentation but I'm not sure if we're doing sth wrong or generally - where's the problem. Can anyone help me with that?

https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/643?inkluder=egenskaper%2Cgeometri&segmentering=false&srid=4326&kartutsnitt=10.71819339123445%2C59.8955445126403%2C10.797672608764003%2C59.9274298311918&antall=400

2 replies

bojanmilojkovic77

@bojanmilojkovic77

Hei, kan den plugin for QGIS 2.0 virke for QGIS3.0 også? Kommer data fra API-les v3 i den plugin?

1 reply

Torgeir Thoresen

@torgeir

Hei! Lenken til håndboken fra dokumentasjonssiden for les v3 er død https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/

Hvordan vegnettet er bygd opp er beskrevet i Håndbok V830

1 reply

Tobias Andersen

@turbolego

@torgeir denne lenken kan kanskje brukes i mellomtiden: https://www.vegvesen.no/globalassets/fag/handboker/hb-v830-nasjonalt-vegreferansesystem.pdf

1 reply

Geir Sagberg

@geirsagberg

Hei! Vi jobber med å lese inn hele vegnettet i Saga, og har noen antagelser vi skulle ha fått bekreftet/avkreftet rundt veglenker (vi bruker endepunktet for segmenterte veglenker, inkludert historiske veglenker):

Vi ser at det kommer et felt "referanse" som består av <veglenkesekvensid>-<veglenkenummer>-<segmentnummer>; stemmer det at dette feltet er unikt? dvs, det finnes ikke to veglenker med samme "referanse"?
Kan det skje at f.eks. startDato endres (fordi man skrev feil), og isåfall, vil det da bli noen endring i ovennevnt referanse?

Geir Sagberg

@geirsagberg

Hei! Vi ser at noen veglenker i det segmenterte endepunktet har invalid geometri, f.eks.: https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/73205?srid=4326, der veglenkenummer 2 (segment 16) har : <wkt>LINESTRING Z(63.410433 10.484676 149.541, 63.410433 10.484676 149.541)</wkt>. Altså to identiske punkt. Samme veglenke i det ikke-segmenterte APIet har denne: <wkt>LINESTRING Z(63.410389 10.484348 149.841, 63.410433 10.484676 149.541)</wkt>. Hva kan dette skyldes?

Geir Sagberg

@geirsagberg

Finnes også startnoder / sluttnoder som har format veglenksevensid-<tall>-<tall>, hva er disse?

1 reply

Geir Sagberg

@geirsagberg

Kan vi be om mer presisjon i WKT når vi bruker SRID 4326?

1 reply

skjalgsk

@skjalgsk

Hei, jeg meldte ifra i februar om kombinasjonen alle_versjoner=true og segmentering=true ikke gir geometri. Før jul så fikk jeg geometri på kombinasjonen av alle_versjoner=true og segmentering=true. Er det noe ETA på når dette blir fikset? Vi i Bymiljøetaten ønsker å komme videre med å hente data fra NVDB Les.

Eksempel, denne gir geometri (segmentering=false):
https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/540.json?alle_versjoner=true&inkluder=alle&kommune=0301&segmentering=false&antall=1

Men denne gir ikke geometri (med segmentering=true):
https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/540.json?alle_versjoner=true&inkluder=alle&kommune=0301&segmentering=true&antall=1

1 reply

Øystein Heggernes Alvestad

@heggernesalvestad

Hei,
Vi henter inn NVDB objekter til ett 3partsystem hvor vi også oppretter og vedlikeholder andre objekter. For å kunne gi disse andre objektene ID-er i en nummerserie som passer i int-format så lurer vi på om det er nummerserier mellom 0 og 2 147 483 647 dere ikke kommer til å bruke i NVDB?

1 reply

Øyvind Stette Haarberg

@oyvindsh

Hei, vi har et case der vi trenger å hente ut fylker / kommuner for noen gamle kontraktsområder (de er ikke aktive, så det holder ikke å bruke omrade/kontraktsomraader-endepunktet). For å hente ut dette så bruker vi /vegobjekter/{vegobjekttypeid}/{vegobjektid} for å hente ut informasjon -- men da må ha inkluder=lokasjon for å få med kommuner / fylker. Dette fungerer, men vi får med veldig mye annen informasjon om stedfesting / linjer / andre områder / geometrier, så jeg lurte på om det er en bedre måte å hente ut disse feltene uten å inkludere ALL lokasjonsinformasjon?

1 reply

Øystein Grande Jaren

@oysteinjaren

Hei. Jeg har snublet over litt irriterende oppførsel på dokumentasjonssiden for nvdbapiles-v3. Når man tester ut API-et, blir det sendt med mange query-parametre som ikke er fylt ut i skjemaet. F.eks. her: https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/#/Vegnett/get_vegnett_veglenkesekvenser

Hvis man trykker "Try it out", og prøver å sende en request ("Execute") uten å gjøre noen tilpasninger, får man feilen:

[
  {
    "code": 4005,
    "message": "Finner ikke noe kontraktsområde ved navn '2003 NORDKAPP 2011-2016'.",
    "help_url": "https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/#/Vegnett"
  }
]

Jeg ser at requesten som sendes inneholder parametrene fylke, kommune, kontraktsområde, riksvegrute og gate:

https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser?fylke=50&kommune=5001&kontraktsomrade="2003 NORDKAPP 2011-2016"&riksvegrute="RUTE8B"&gate="Holkestadveien"&vegsystemreferanse=EV6&kartutsnitt=265273,7019372,346553,7061071&polygon=20000.0 6520000.0,20500.0 6520000.0,21000.0 6500000.0,20000.0 6520000.0

For å unngå å sende med disse ekstra parametrene, må man for hver parameter trykke på knappen "Add integer/string item", og deretter trykke på "-"-knappen for å ta den bort igjen. Dette gjør det nokså tungvint å eksperimentere med API-et. Er det mulig å få gjort noe med dette?

1 reply

Hans Olaf Gundersen

@hansog

19. Mai kl. 12:00 skal det utførast testkøyring av ei endring på serveren til NVDB.

Dersom alt går som planlagt vil ingen merke noko på Api Les V3, men dersom noko feilar kan det oppstå ustabilitet i nokre minutt før alt rullast tilbake som det var.

Dag M

@monsendag

Hei. Jeg jobber som utvikler på Trygg tunnel. Vi benytter API Les V3 til å hente ut tunnel-vegobjekter og diverse attributter. Noen av disse kallene feiler hos oss i PROD med følgende feilmelding:

HTTP error 422 for request 990ff1fa-9716-c531-1a20-2baec44491d7: Error 4005: Ugyldige tegn i 'veglenkesekvens' field: '3.17E-6@2070659'. Gyldig eksempel: 0.6-0.9@42364

Jeg mener at dette er fordi java.Double blir serialisert på feil måte. Ref: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Double.html#toString(double)

Siden Double blir konkatenert med String flere steder i nvdb-read-api-v3-client så vil det kunne føre til vitenskapelig notasjon (3.17E-6) i stedet for desimaler dersom verdien er lav (eller høy) nok. Jeg har rettet opp i dette i vår egen kodebase, men det gjenstår noen plasser i nvdb-read-api-v3-client.

Er det aktuelt å ta inn en PR på GitHub hvis jeg lager en til dere? Eventuelt har dere tid/mulighet til å fikse det?

GitHub issue: nvdb-vegdata/nvdb-api-client#112

Where communities thrive

People

Repo info

Activity

18. okt kl. 8:30: ATM-database (test-miljø) oppgradering