Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 11 10:53

    magnusoy on master

    Update APISKRIVV3.md (compare)

  • Jun 11 10:53

    magnusoy on master

    Update APISKRIVV3.md (compare)

  • Jun 11 07:47

    gitdummies on master

    Update APISKRIVV3.md v 2021.6.1 (compare)

  • May 25 06:12

    magnusoy on master

    Update vegkart.md (compare)

  • May 06 08:47

    ph10m on master

    Update README.md (compare)

  • May 06 07:46

    ph10m on master

    dependencies in readme (compare)

  • May 05 12:20

    ph10m on 1.16.6

    (compare)

  • May 05 12:20

    ph10m on nvdb-read-api-v3-client-1.16.6

    (compare)

  • May 05 12:20

    ph10m on 1.16.6

    (compare)

  • May 05 12:15

    ph10m on maven-central

    (compare)

  • May 05 12:15

    ph10m on bintray-hosting

    (compare)

  • May 05 12:14

    ph10m on master

    updated gitignore and remove ka… mod build scripts merge publishing variants and 12 more (compare)

  • May 05 08:11

    ph10m on maven-central

    Update README.md (compare)

  • May 05 07:05

    ph10m on prepare-for-maven-central

    (compare)

  • May 05 07:04

    ph10m on move-to-official-sonatype-docs

    (compare)

  • May 04 11:59

    ph10m on maven-central

    latest release scripts with mav… (compare)

  • May 03 15:14

    ph10m on maven-central

    modify release scripts archive jar for signing separate local and repo builds (compare)

  • May 03 11:22

    ph10m on maven-central

    include versioning, add group (compare)

  • May 03 11:19

    ph10m on maven-central

    remove build names (compare)

  • May 03 11:18

    ph10m on maven-central

    older axion version (compare)

koch
@ochmanski
Hei!
I've noticed that endpoint https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/643 is running really slow. By slow I mean typical request takes 10-30 seconds. After some period I'm getting 503's. Could you look into it?
Thank you
5 replies
bojanmilojkovic77
@bojanmilojkovic77
Hei,
Hei, det er ikke mulig å importere enkel api i datafangst : https://nvdbapiles-v2.atlas.vegvesen.no/vegobjekter/80/884628235 (med og uten versjon "1"). Er det feil i datafangst eller det er normalt. Jeg sendte sammen spørsmål på epost (NVDB). Mvh Bojan
Tor M
@tormoseng
@bojanmilojkovic77 Hei! Nei, det er ikke mulig per nå å importere et enkelt objekt direkte i Datafangst. Men dette er en god ide som vi kan ta med oss.
Datafangst er i dag tilpasset til å ta inn url som du får fra Vegkart (søk og deretter kopier inn API-url du finner ved CSV- og SOSI-eksporten). Frem til støtte av enkeltobjekt må du nesten bare zoome så langt ned som mulig s.a. du får færrest mulig "støy" i tillegg til objektet du ønsker å importere.
bojanmilojkovic77
@bojanmilojkovic77
  1. Kan dere lage mulighet for å importere flere API med en gang (URL liste) vi trenger mer avansert filering som er ikke mulig å gjøre med enkel API og vi har del av søk med python og der har vi generert liste av URLs . 2. Tenkte dere å lage "bruker" som del av metadata (p0**). Den "bruker" data gir ingen informasjon om navn! Jeg hørte at dere har mulighet å se bruker som lager oppdatering av objekt og den typen av søk med API kan bli fint. Bojan, Geodataforvalter Viken.
Tor M
@tormoseng
@bojanmilojkovic77 Send endringsønsker for Datafangst til datafangst-support@vegvesen.no slik at produkteier kan prioritere hva som skal gjøres. Hvorvidt bruker skal eksponeres i API kan du etterspørre hos fagavdelingen i NVDB på nvdb@vegvesen.no.
roltorran
@roltorran
Hei, Jeg tror jeg har oppdaget en liten feil. Jeg fikk problemer med parsing av XML som returneres fra denne https://nvdbapiles-v3.atlas.vegvesen.no/veg/batch?veglenkesekvenser=0.00065647%40578625 . <relativPosisjon> inneholder en desimalverdi på "scientific notation", og det liker ikke XML-parseren min. I følge dette http://books.xmlschemata.org/relaxng/ch19-77057.html så er det heller ikke tillatt i XML. Akkurat for min applikasjon så trenger jeg ikke egentlig denne verdien, så jeg kan alltids parse den som streng i stedet for tall. Men det burde kanskje vært rettet?
2 replies
roltorran
@roltorran
En annen liten feil jeg oppdaget under testing er at dokumentasjonen/demoen av APIet her: https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/ lager noen feil i URL når man forsøker "Try Out". Det gjelder typisk at f.eks. Kommune og Vegsystemreferanse noen ganger skrives med stor bokstav i Request URL, mens APIet forlanger små bokstaver. Det er også litt forvirrende at eksemplet her: https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/#/Posisjon/get_veg tilsynelatende skal ha som input en liste av vegsystemreferanser, men det er uklart hvilket format som skal brukes for dette. Eksempelet som kommer fram (List [ "EV6S1D1m341", "R6S1D1m1300KD4m129", "SP12S1D3m123" ]) godtas ikke, ei heller forenklingen til EV6S1D1m341, R6S1D1m1300KD4m129, SP12S1D3m123; da får man beskjed om at "Må inneholde bare en vegreferanse".
3 replies
roltorran
@roltorran
Så et spørsmål: Det ser ikke ut til at /veg/batch gjør bruk av paginering. Hva er årsaken til dette? For min bruk har jeg fra noen titalls til noen tusen (i verste fall) veglenkesekvenser som skal hentes ut (jeg trenger "oversettelse" til vegsystemreferanse). Hva er anbefalt måte å håndtere dette på uten å belaste systemet unødvendig? Jeg kjører dette i batch med opptil 100 veglenkesekvenser per kall til APIet, og cacher lokalt per brukersession.
1 reply
Jan Kristian Jensen
@LtGlahn
Tror jeg fant en bug på vegobjektfilter veglenketype=hoved, alternativt snål vegnettsfeil som unnvek mitt skarpe blikk. Mangler iallfall 904 på strekningen FV3972 K S3D1 m8265-8638 på søket https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/904?kartutsnitt=74683.747,6461672.793,75368.358,6462292.58&veglenketype=hoved,detaljert&segmentering=true&inkluder=metadata,lokasjon,geometri
3 replies
image.png
Jan Kristian Jensen
@LtGlahn
image.png
Olav Dahl Solstad
@olav89
Når jeg kjører spørring https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/79/80863621/6 kommer det ut relasjoner, men det viser seg at disse barnene er avsluttede objekter. Se f.eks. https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/761/80863620/1 der man finner <sluttdato>2008-06-18</sluttdato>. Er dette noe APIet vanligvis filtrerer, eller skal det meldes til fiksvegdata?
1 reply
bojanmilojkovic77
@bojanmilojkovic77
Hei, Hvordan kan jeg få alle prosjektreferanse som finnes på kartutsnitt eller fylke eller kommune eller (hva som helst)?
3 replies
bojanmilojkovic77
@bojanmilojkovic77
image.png
NKA
@NKAmapper
Jeg har behov for å gruppere veier som hører logisk sammen, og bruker vegsystemreferansen. Er det slik at det ikke lenger blir laget veglenkesekvenser for private veier? I hvert fall ser vegnummer ut til å være maskingenerert og ny for hvert segment, slik at private veier deles opp i hvert individuelle segment uten sammenheng med resten av den "logiske" veien.
8 replies
Markus Lund
@MarkusLund

Hei.

Vi på Trafikkdata-prosjektet har problemer med at vi ikke finner vegreferanser på veglenkeposisjoner der vi tidligere har funnet vegreferanser.
F.eks. https://vegkart.atlas.vegvesen.no/#kartlag:geodata/@-38210,6566281,16/vegnett:~'geometri+~()/valgt:3131641:2:7

Denne har måledato 2018-12-01, mens vi har tidligere hentet 532 vegreferanser for samme posisjon. Men vi i dag verken finner 532 objekter eller vegsystemreferanser før 2018-12-01 på posisjonen 0.14454362@3131641.

Vi trenger dette for å sammenligne metreringsretning på et gitt historisk tidspunkt med dagens metrering.

6 replies
Marvin Bredal Lillehaug
@computerlove
I kommende versjon av NVDB API LES vil responsrevisjon 2 bli innført.
Det er fortsatt revisjon 1 som er gjeldende dersom revisjon ikke oppgis, og revisjon 2 vil få flere endringer i fremtiden.
Olav Dahl Solstad
@olav89
Er det innført begrensninger i versjon 2 av lese-APIet for uthenting av objekter? Ser ut som jeg kun får ut 250 om gangen
4 replies
Jens Erik Thyholdt
@jethy57
Hei! Oppdaget noe merkelig i dag. Har hatt problemer med et område i Alver kommune hvor fartsgrenser var oppgitt med sluttdato og dermed "LUKKET". Det var ikke overenstemmelse mellom de data jeg hadde fått fra API og de vi fant gjennom Vegkart. Kjørte et uttrykk https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/105?srid=utm33&segmentering=true&kartutsnitt=-23080.%2C%206757557%2C%20-22556%2C%206758256&inkluder=lokasjon,metadata,egenskaper som i går inneholdt en rekke lukkede objekter, men i dag ikke har noen. Noe som kan forklares eller har jeg blingset noe helt alvorlig ?
1 reply
Truls Dahl
@BingoBoy
Hvordan må jeg formatere forespørselen for å hente ut alle vegskilter?
8 replies
Marvin Bredal Lillehaug
@computerlove
I dag er siste dag Kantega jobber på NVDB Åpne vegdata, så det er siste dag jeg og @krimjo jobber på API Les. Fra mandag er det Capgemini som har ansvaret, så @johannsl tar over den jobben jeg har hatt de siste årene.
Jeg ønsker Johan og resten av teamet lykke til!
1 reply
Truls Dahl
@bingoboy:matrix.org
[m]
Er det noen her som har erfaring med å hente inn informasjon til PowerApps?
NKA
@NKAmapper
For fagobjekt #538 Gate: Noen kommuner har ingen Sideveg, andre har bare Sideveg=Nei (ingen Sideveg=Ja). Hva er greia her?
5 replies
koch
@ochmanski
Hi! Open street map has element way. Does NVDB provide API for getting ways?
7 replies
Taras
@Taraskin_gitlab
Hi there!
Recently got an exception by using nvdb-api-client v.1.15:
Caused by: java.lang.RuntimeException: Error processing
{"id":272297887,"href":"https://nvdbapiles-v3.utv.atlas.vegvesen.no/vegobjekter/60/272297887/1","egenskaper":[{"id":120060,"navn":"Liste av lokasjonsattributt","egenskapstype":"Liste","datatype":"Liste","innhold":[{"id":100060,"navn":"StrekningTilknytning","egenskapstype":"Stedfesting","datatype":"GeomLinje eller Kurve","stedfestingstype":"Linje","veglenkesekvensid":1995026,"startposisjon":0.96450906,"sluttposisjon":0.96817013,"retning":"MED","kjørefelt":[]},{"id":100060,"navn":"StrekningTilknytning","egenskapstype":"Stedfesting","datatype":"GeomLinje eller Kurve","stedfestingstype":"Linje","veglenkesekvensid":625212,"startposisjon":0.63416536,"sluttposisjon":0.63468331,"retning":"MED","kjørefelt":[]},{"id":100060,"navn":"StrekningTilknytning","egenskapstype":"Stedfesting","datatype":"GeomLinje eller Kurve","stedfestingstype":"Linje","veglenkesekvensid":616969,"startposisjon":0.13461538,"sluttposisjon":0.15384615,"retning":"MED","kjørefelt":[]},{"id":100060,"navn":"StrekningTilknytning","egenskapstype":"Stedfesting","datatype":"GeomLinje eller Kurve","stedfestingstype":"Linje","veglenkesekvensid":618537,"startposisjon":0.04545455,"sluttposisjon":0.90909091,"retning":"MED","kjørefelt":[]}]},{"id":1313,"navn":"Lengde","egenskapstype":"Flyttall","datatype":"Tall","verdi":70.0,"enhet":{"id":1,"navn":"Meter","kortnavn":"m"}},{"id":8969,"navn":"Vedlikeholdsansvarlig","egenskapstype":"Tekstenum","datatype":"FlerverdiAttributt, Tekst","verdi":"Statens vegvesen","enum_id":11808},{"id":11180,"navn":"Opprinnelig F-Nr","egenskapstype":"Heltall","datatype":"Tall","verdi":3},{"id":1263,"navn":"Brukategori","egenskapstype":"Tekstenum","datatype":"FlerverdiAttributt, Tekst","verdi":"G/S-bru","enum_id":7306},{"id":1971,"navn":"Lengste spenn","egenskapstype":"Flyttall","datatype":"Tall","verdi":19.5,"enhet":{"id":1,"navn":"Meter","kortnavn":"m"}},{"id":11317,"navn":"Status","egenskapstype":"Tekstenum","datatype":"FlerverdiAttributt, Tekst","verdi":"Trafikkert ","enum_id":19262},{"id":1080,"navn":"Navn","egenskapstype":"Tekst","datatype":"Tekst","verdi":"Røssedal gangbru"},{"id":1404,"navn":"Materialtype","egenskapstype":"Tekstenum","datatype":"FlerverdiAttributt, Tekst","verdi":"Spennbetong","enum_id":12326},{"id":9182,"navn":"Byggverkstype","egenskapstype":"Tekstenum","datatype":"FlerverdiAttributt, Tekst","verdi":"Bjelkebru, NIB (320)","enum_id":12445},{"id":2175,"navn":"Nummer","egenskapstype":"Heltall","datatype":"Tall","verdi":371}],"lokasjon":{"kommuner":[301],"fylker":[3],"kontraktsområder":[{"id":642371105,"navn":"0303 RIKSVEGER OSLO 2016-2021"},{"id":657582591,"nummer":210,"navn":"Drift Elektro veglyskontrakt Oslo og Akershus"},{"id":1006900767,"nummer":9104,"navn":"9104 Oslo-Gardermoen 2021-2026"},{"id":1010957021,"nummer":9151,"navn":"9151 Stor-Oslo veglys 2023-2027"},{"id":1010957807,"nummer":9151,"navn":"9151 Stor-Oslo veglys 2021-2023"}],"riksvegruter":[{"id":137054099,"nummer":"1","navn":"RUTE1","periode":"2006-2009"},{"id":137054101,"nummer":"2","navn":"RUTE2","periode":"2006-2009"}],"gater":[{"gatekode":11540,"navn":true}],"vegsystemreferanser":[{"vegsystem":{"id":1006190638,"versjon":1,"vegkategori":"E","fase":"V","nummer":6},"strekning":{"id":-1,"versjon":-1,"strekning":15,"delstrekning":1,"arm":false,"adskilte_løp":"Nei","trafikantgruppe":"K","fra_meter":6112.008,"til_meter":6117.009,"retning":"MED"},"kortform":"EV6 S15D1 m6112-6117"},{"vegsystem":{"id":1002315795,"versjon":1,"vegkategori":"E","fase":"V","nummer":6},"strekning":{"id":-1,"versjon":-1,"strekning":15,"delstrekning":125,"arm":false,"adskilte_løp":"Nei","trafikantgruppe":"G","fra_meter":1060.225,"til_meter":1064.25,"retning":"MED"},"kortform":"EV6 S15D125 m1060-1064"},{"vegsystem":{"id":1002347261,"versjon":1,"vegkategori":"K","fase":"V","nummer":89790},"strekning":{"id":-1,"versjon":-1,"strekning":1,"delstrekning":1,"arm":false,"adskilte_løp":"Nei","trafikantgruppe":"G","fra_meter":1.01,"til_meter":20.203,"retning":"MED
And the rest of tacktrace:
at no.vegvesen.nvdbapi.client.gson.GsonUtil.lambda$rt$9(GsonUtil.java:231) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na] at java.base/java.util.ArrayList$Itr.forEachRemaining(ArrayList.java:1032) ~[na:na] at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) ~[na:na] at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[na:na] at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[na:na] at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) ~[na:na] at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[na:na] at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) ~[na:na] at no.vegvesen.nvdbapi.client.clients.GenericResultSet.next(GenericResultSet.java:144) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] ... 37 common frames omitted Caused by: java.lang.IllegalArgumentException: navn did not contain a string. at no.vegvesen.nvdbapi.client.gson.GsonUtil.parseStringMember(GsonUtil.java:83) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at no.vegvesen.nvdbapi.client.gson.RoadObjectParser.lambda$parseStreets$3(RoadObjectParser.java:219) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na] at java.base/java.util.ArrayList$Itr.forEachRemaining(ArrayList.java:1032) ~[na:na] at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) ~[na:na] at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[na:na] at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[na:na] at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) ~[na:na] at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[na:na] at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) ~[na:na] at no.vegvesen.nvdbapi.client.gson.RoadObjectParser.parseStreets(RoadObjectParser.java:220) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at no.vegvesen.nvdbapi.client.gson.RoadObjectParser.parseLocation(RoadObjectParser.java:173) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at no.vegvesen.nvdbapi.client.gson.RoadObjectParser.lambda$parse$0(RoadObjectParser.java:115) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at java.base/java.util.Optional.map(Optional.java:265) ~[na:na] at no.vegvesen.nvdbapi.client.gson.RoadObjectParser.parse(RoadObjectParser.java:115) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0] at no.vegvesen.nvdbapi.client.gson.GsonUtil.lambda$rt$9(GsonUtil.java:229) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
More precise point:
Caused by: java.lang.IllegalArgumentException: navn did not contain a string.
at no.vegvesen.nvdbapi.client.gson.GsonUtil.parseStringMember(GsonUtil.java:83) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
Taras
@Taraskin_gitlab
P.S. STM environment, consuming: https://nvdbapiles-v3.utv.atlas.vegvesen.no , but ATM/PROD might be impacted as well
Exception request trace:
no.vegvesen.nvdbapi.client.exceptions.ClientException: HTTP error 200 for request f3bc3a42-525e-a124-6ee1-c3e188dfb193:
22 replies
This piece of GsonUtilraised an exception:
    public static String parseStringMember(JsonObject obj, String path) {
        Optional<JsonPrimitive> e = getNode(obj, path).map(JsonElement::getAsJsonPrimitive);
        if (e.isPresent() && !e.get().isString()) {
            throw new IllegalArgumentException(path + " did not contain a string.");
        }
        return e.map(JsonElement::getAsString).orElse(null);
    }
Ole Kristian Sandum
@okkero

Jeg prøver å hente ut et vegobjekt med full dybde (https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/487/588616932/5?dybde=full&inkluder=relasjoner%2Cmetadata%2Cgeometri), og ett av datterobjektene i hierarkiet kommer tilbake med kun ID og ingen annen data: {id: 588616940}
Det kan da ikke være rett? Tror vi var borti noe lignende før og mener vi kom fram til at objektet var lukket i NVDB, men skal det da komme tilbake med kun ID? Kan ikke se at oppførselen står dokumentert noen plass heller.

Prøver jeg å hente ut data for det vegobjektet får jeg følgende tilbake:

[
  {
    "code": 4016,
    "message": "Feature 588616940 of type 859 is gone!",
    "help_url": "https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/"
  }
]

Det styrker mistanken min om at dette er en bug, og at objektet egentlig ikke skal bli med i relasjonshierarkiet.

Hvordan skal jeg tolke dette?

3 replies
Olav Dahl Solstad
@olav89
Henter ut statistikk av vegobjekt for en gitt kommune, og får ikke samsvar med antallet man får ved uthenting av vegobjekter. F.eks. gir https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/95/statistikk?kommune=1539 antall 2358 - men https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/95?kommune=1539 gir antall 2414. Ser at det gjelder alle kommunene jeg har testet - er det treghet før statistikk blir oppdatert?
2 replies
Olav Dahl Solstad
@olav89
OpenAPI-dokumentasjonen viser til "omrader/kontraktomrader" som gir 404 - skal vel være "kontraktsomrader" der
2 replies
Olav Dahl Solstad
@olav89
Ser ut som at geometri har forsvunnet fra liste med egenskaper for noen objekter? https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/95/785578755/1 gir geometri som en egenskap, mens https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/5/709617755/1 ikke gjør det
2 replies
Johan
@johannsl
Vi prøver å prioritere det å svare på ubesvarte spørsmål i dagene framover
2 replies
Jose Antonio Hernandez
@josea.hernandez_gitlab
In a geometry attribute what is projection for the coordinates? Has NVDB one projection set for them? I am doing tests reading some skiltpunkts with geometry attributes of type GeomPunkt but do not see where the projection for the coordinates is defined. There is sometimes a høydereferanse for elevations, but with a value of 9999, and nothing that seems to indicate the projection of the planar coordinates.
1 reply
Jose Antonio Hernandez
@josea.hernandez_gitlab
Hi. In the målemetode of th kvalitet object API doc says: Se vegobjekttype 793 NVDB Dokumentasjon, egenskap 9543 Målemetode eller Kodeliste i kapitel 1.6.2.8.2. and there is a link to SOSI-standard kapittel 1.6.2.8 but seems to be broken. What is the correct link to the pdf standard with these codes?
1 reply
Olav Dahl Solstad
@olav89
Endepunkt for ruteberegning er jo anbefalt brukt til stedfesting - men det er ingen måte å angi om man skal ha linje eller punkt-stedfesting såvidt jeg kan se (man vil vel alltid ha linje her, da man ellers kan bruke posisjonsendepunktet). Dette er som regel ikke et problem, men jeg ser at ved spørringer der man filtrerer på en vegsystemreferanse som ligger litt vekk fra start/slutt-koordinatene kan man få et enkelt punkt. Eks: "start": "270928.7194, 7038372.6711", "slutt": "270918.5789, 7038348.960", "vegsystemreferanse": "KV3010" gir "1.0@41753" som resultat.
7 replies
Taras
@Taraskin_gitlab

Hi, is https://nvdbapiles-v3.utv.atlas.vegvesen.no down?
Getting 504 errors while using nvdb-read-api-v3-client-1.15.0 library:

    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) ~[spring-beans-5.3.2.jar:5.3.2]
    at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653) ~[spring-beans-5.3.2.jar:5.3.2]
    ... 48 common frames omitted
Caused by: no.vegvesen.nvdbapi.client.exceptions.ClientException: HTTP error 503:
Error 504: Server did not respond correctly <html>

and stack trace:

    at no.vegvesen.nvdbapi.client.clients.JerseyHelper.parseError(JerseyHelper.java:67) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
    at no.vegvesen.nvdbapi.client.clients.JerseyHelper.executeOptional(JerseyHelper.java:137) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
    at no.vegvesen.nvdbapi.client.clients.DatakatalogClient.getVersion(DatakatalogClient.java:62) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
    at no.vegvesen.nvdbapi.client.clients.ClientFactory.getDatakatalogVersion(ClientFactory.java:301) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
    at no.vegvesen.nvdbapi.client.clients.ClientFactory.getRoadObjectClient(ClientFactory.java:325) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
    at no.vegvesen.nvdbapi.client.clients.ClientFactory.getRoadObjectClient(ClientFactory.java:317) ~[nvdb-read-api-v3-client-1.15.0.jar:1.15.0]
3 replies
Taras
@Taraskin_gitlab
Update: seems to be working again :)
FMEtilNVDB
@FMEtilNVDB
Hei! Jeg prøver å få kontakt gjennom datafangst api'et. Målet mitt er å hente ut informasjon om aktuelle kontrakter for å opprette et NVDB objekt fra dette. Jeg er dermed avhengig av geografisk informasjon. Foreløpig har jeg fått til å hente kontraktsnavn og annen relevant informasjon gjennom oppskriften her: https://github.com/nvdb-vegdata/apiskrivdokumentasjon/blob/master/datafangst/datafangst-api.md. Problemet er at det kommer ikke ut "boundaryWkt" i kallet til f.eks. : https://datafangst.vegvesen.no/api/v1/contract/cabeca8f-91c8-4d25-879a-a1ec7909ad43/. Snudd på hodet så finnes all informasjon på REST-apiet. Dette kan jeg se når jeg skriver "https://datafangst.vegvesen.no/rest/contract/cabeca8f-91c8-4d25-879a-a1ec7909ad43/" rett inn i nettleseren. Når jeg gjør samme kall ifra FME, så får jeg bare HTTP respons 401, samme hvilken metode jeg tester for autorisering. Hvordan kan jeg på korrekt måte bygge rett kall med autorisering mot REST-apiet til datafangst?
1 reply
NKA
@NKAmapper
Finnes det informasjon om hvor de nasjonale sykkelrutene går i NVDB? Eller vet noen om dette kan hentes andre steder?
1 reply
Olav Dahl Solstad
@olav89
Har noen spørsmål rundt uthenting vegobjekter med geometri. I dokumentasjonen for
​/vegobjekter​/{vegobjekttypeid}​/{vegobjektid} står det at SRID kan være 6173 eller 4326, mens default-valget på 5973 ikke er nevnt i det hele tatt. Når jeg derimot setter srid=6173 får jeg svaret tilbake med srid 5973. Er det da slik at høyden alltid returneres i NN2000, uansett om man spør etter NN54?
1 reply
Johan
@johannsl
@Taraskin_gitlab Hei, jeg tror jeg klarte å slette meldingen din ved feil. Beklager det. Det jeg mente å gjøre var å svare og si at vi er på saken og prøver å friskmelde UTV
1 reply
bojanmilojkovic77
@bojanmilojkovic77
Hei, Kan jeg få med API-les objekter som finnes i et polygon (IKKE kartutsnitt, IKKE veireferanse)? Hvis dere vet, kan jeg få eksempel med url?
2 replies
Taras
@Taraskin_gitlab

Hi, getting 4005 errors for requests like: https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/60?kartutsnitt=-154.45083%2C-62.011843%2C154.45083%2C62.011843&inkluder=egenskaper,geometri&antall=1000

<errors>
<error>
<code>4005</code>
<message>Bounding box did not intersect system bounds.</message>
<message_detailed>Missing 'srid' parameter?</message_detailed>
<help_url>https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/#/Vegobjekter</help_url>
</error>
</errors>

According to https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/#/Vegobjekter/get_vegobjekter__vegobjekttypeid_
srid - is not requred (query) parameter, should we set it explicitly?

Environment: PROD

2 replies
Bendik Solheim
@bensolh

Hei, vi opplever sporadiske feil ved tilsynelatende gyldige spørringer mot

/vegobjekter/<objekttype>?veglenkesekvens=X

Eksempel:
https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/105?veglenkesekvens=0.38790492@291234
x-request-id: b6daa6b3-3d22-c2ef-eecb-c3fa424da76d

{
    "code" : 4005,
    "message" : "Ugyldige tegn i 'veglenkesekvens' field: '0.38790492@291234'. Gyldig eksempel: 0.6-0.9@42364",
    "help_url" : "https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/#veglenke "
}

Koden vår bruker samme veglenkesekvens til flere oppslag og det er sjelden mer enn ett som feiler (som regel ingen). Klarer ikke å gjenskape feilen. Vegobjekttype virker uvesentlig og det skjer med vilkårlige veglenkesekvenser.
Kjenner dere til feil ved endepunktet, evt. ser noe i loggene som indikerer hvilke tegn som er ugyldige?

3 replies
Tollef Jørgensen
@ph10m

Flytting av api-klienten til maven central

Hei alle brukere av api-klienten :-) Noen har kanskje fått med seg at bintray har lagt ned tjenesten med hosting, så vi har måttet flytte api-klienten til maven central. Det innebærer noen små endringer, men mange av de gjør det lettere mtp. at maven central er et offisielt støttet repository, så man trenger ikke predefinere <repositories> feltene lengre. Oppdatert README er ute, der det også er lagt ved noen dependencies som kreves i tilfelle noen har slitt med dette før.

Det eneste dere trenger å gjøre er å oppdatere dependencies, evt. kun å fjerne referanser til bintray i pom/gradle-filer o.l.

Svein Hallsteinsen
@svein-hallsteinsen
Vi har et problem i PROD nå. Vi bruker nvdb-read-api-v3-client 1.13.4 i java, og spør om alle tunneler (objekter av type 581). Siden i går har vi fått masse duplikater av tunneler. Så samme tunnel har flere entries, med ulik NVDBID
6 replies
NKA
@NKAmapper
Hvordan kan man finne ut om en vei ikke er tillatt for gående og syklende, bortsett fra tunneler (og bortsett fra motorvei/motortrafikkvei)? Har forsøkt å bruke skiltplate/skiltnummer 306.6-8, men det gir ikke alltid entydig kobling til aktuelle veisegmenter.
2 replies