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
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
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
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
@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.
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.
- 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.
@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.
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
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
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
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
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
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
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
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.
Det er fortsatt revisjon 1 som er gjeldende dersom revisjon ikke oppgis, og revisjon 2 vil få flere endringer i fremtiden.
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
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!
Jeg ønsker Johan og resten av teamet lykke til!
1 reply
Er det noen her som har erfaring med å hente inn informasjon til PowerApps?
For fagobjekt #538 Gate: Noen kommuner har ingen Sideveg, andre har bare Sideveg=Nei (ingen Sideveg=Ja). Hva er greia her?
5 replies
Hi there!
Recently got an exception by using
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]
P.S. STM environment, consuming: https://nvdbapiles-v3.utv.atlas.vegvesen.no , but ATM/PROD might be impacted as well
Exception request trace:
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);
}
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
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
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
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
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
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
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]
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
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?
/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
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
Hei, vi opplever sporadiske feil ved tilsynelatende gyldige spørringer mot
/vegobjekter/<objekttype>?veglenkesekvens=XEksempel:
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
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.
