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
magnusoy on master
Updated API Skriv changelog up … (compare)
magnusoy on master
Updated API Skriv changelog up … (compare)
mariasoleim on leveranse-2021-1.1.0
mariasoleim on master
Update datafangst.md Update datafangst.md Update datafangst.md and 1 more (compare)
mariasoleim on leveranse-2021-1.1.0
Update datafangst.md (compare)
mariasoleim on leveranse-2021-1.1.0
Update datafangst.md (compare)
mariasoleim on leveranse-2021-1.1.0
Update datafangst.md (compare)
computerlove on master
2021.1.0 (compare)
mariasoleim on datafangst-2021.1.0.0
mariasoleim on master
Update datafangst.md Update datafangst.md Merge pull request #23 from nvd… (compare)
mariasoleim on datafangst-2021.1.0.0
Update datafangst.md (compare)
mariasoleim on datafangst-2021.1.0.0
Update datafangst.md (compare)
vegdata on nvdb-read-api-v3-client-1.15.0
computerlove on nvdb-read-api-v3-client-1.15.0-alpha
computerlove on NVDB-6376
computerlove on master
NVDB-6376 pagination of Street Merge pull request #101 from nv… (compare)
computerlove on NVDB-6376
NVDB-6376 pagination of Street (compare)
torand on master
Updated API Skriv changelog up … (compare)
Heisann. Eg brukar NVDB for å hente ut trafikkmengdeobjekt via java-klient. Tidlegare har det vore tilfelle at alle desse har hatt RoadObject -> segments[] -> roadSysRef -> section satt til ein verdi. No køyrde eg denne uthentinga på nytt, og opplever at section er null. Er dette forventa? Eg har med to screenshots som viser "problemet" samt vebobjektId m.m.
Vegobjekt: https://e.pcloud.link/publink/show?code=XZdkdZjCpV8B48TnLlaslOLCVpajME9TTk
Segmentet der section er null: https://e.pcloud.link/publink/show?code=XZlkdZ9UMT9AQ5kN7v8g8o8DA2w0NTY7Q7
Hey,
according to the https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/openapi/
retningstring
example: MED
Om objektet er stedfestet med eller mot lenkeretning
Enum:
[ MED, MOT ]
Got an exception:
Caused by: java.sql.SQLException: ORA-12899: verdien er for stor for kolonnen "BRUTUS"."VEGREFDATA"."RETNING" (faktisk: 4, maksimum: 3)
020-10-01 00:46:37,379 uuid="7fe5a827-ef89-4b2e-91f2-44cf162b0825" user="N/A" evt="FEIL:" message="Oppdatering av VegRefData feilet"
Heisann med sveisen!
I går dreiv eg å henta ut trafikkmengdeobjekt for alle riksvegar via Java-klienten. Eg køyrde programmet mitt ein del gonger og observerte at den totale lengden veg kunne variere ganske drastisk mellom køyringar. Her er antal kilometer med veg for kvar køyring:
Ser ut til at eg ikkje nødvendigvis får alle trafikkmengdeobjekta ved kvar køyring. Kva er årsaken til det?
Hei,
hvis man gjør dette kallet: https://nvdbapiles-v3.test.atlas.vegvesen.no/vegobjekter/99?srid=4326&inkluder=lokasjon&vegsystemreferanse=FV864S2
og ser på objektet med id: 204249035 så har det åtte vegsystemreferanser der objektet er stedfestet.
Hvis man gjør dette kallet: https://nvdbapiles-v3.test.atlas.vegvesen.no/vegobjekter/99/204249035
så ser man at vegsystemreferansene der objektet er stedfestet på er slått sammen og har fra_meter 0 og til_meter 2997.371.
Er det, eller kan det bli, en mulighet for å få slått sammen sammenhengende vegsystemreferanser også for kall tilsvarende det første?
I tillegg i det andre kallet så har objektet med id: 204249035 fått en stedfesting på strekning 1 fra_meter 3168.287 og til_meter 3168.315 som jeg ikke helt forstår hvor kommer fra, men det er en annen sak.
Hei. Vi har en nattlig jobb i Brutus som kopierer vegsystemreferanser fra NVDB med endepunktet: veg/batch
Vi bruker NVDB Java klient versjon, nvdb-read-api-V3-client versjon 1.11.2.
Når vi gjør kall mot:
roadPlacementClient.getRoadPlacementsInBulkFromReflinks(refLinkRequests1, Projection.UTM33);
Så får vi følgende feil i ATM-miljøet:
2020-10-12 00:00:43,149 uuid="94e811c1-d46d-4827-94f8-97e9f22d4c3f" user="N/A" evt="FEIL:" message="Oppdatering av VegRefData feilet"
no.vegvesen.nvdbapi.client.exceptions.ClientException: HTTP error 504:
Error 504: Server did not respond correctly <html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
at no.vegvesen.nvdbapi.client.clients.JerseyHelper.parseError(JerseyHelper.java:67) ~[nvdb-read-api-v3-client-1.11.2.jar:1.11.2]
Ser i dokumentasjonen, og der står det:
"Ratelimiter
API-et implementerer en ratelimiter for å forhindre overbelastning. Denne opererer med tre parametere: Tidsvindu-størrelse, antall kall og timeout.
Tidsvindu: Angir hvor lenge mellom hver gang API-et tilbakestiller tellingen på antall kall.
Antall kall: Tillatt antall kall i hvert tidsvindu fra en enkelt klient. Enkeltklienter skilles på IP-adresse.
Timeout: Hvor lenge en request kan stå i kø og vente på et ledig tidsvindu før den blir kastet ut med en 429 - Too Many Requests.
Standardverdier for disse parametrene er henholdsvis 2000/100/2000, altså 100 kall per tidsvindu på 2000 millisekunder, eller gjennomsnittlig 50 kall/sek, med en timeout tilsvarende ett tidsvindu. Disse verdiene kan endres for å forhindre overbelastning i perioder med generell høy last.
Overbelastning
Dersom det er mye last, som ikke trigger HTTP 429 som over, vil kall som ikke er behandlet innen rimelig tid (~25s) avbrytes med HTTP 503 og melding Behandlingen av forespørselen kunne ikke fullføres innen rimelig tid.."
Hva kan vi gjøre for å hindre at dette skjer?
Hi there. It looks like java-client library now available on https://artrepo.vegvesen.no/artifactory/list/nvdb-vegdata/no/vegvesen/nvdb/nvdb-read-api-v3-client/1.13.1/
But, still, I can't pull it using maven:
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Could not find artifact no.vegvesen.nvdb:nvdb-read-api-v3-client:jar:1.13.1 in central (https://artrepo.vegvesen.no/artifactory/libs-release)
Has anybody configured SVV Artrepo for pulling NVDB API artifacts from there?
P.S. I've used recommended configuration provided for Maven settings.xml
and rest of the artifacts pull well.
NVDB les API:STM
java-client-library v.1.11.2
Exception:
2020-10-15T11:25:55,837+0200 level=ERROR uuid="a39d49d4-b003-4b12-aff3-2c3bcd0d7dcf" user="tarbuh" evt="FEIL:" message="Systemfeil. Kontakt systemadministrator"
java.lang.RuntimeException: Error processing
{"id":1002101480,"navn":"Kongsvinger","nummer":3401,"kartutsnitt":{"wkt":"POLYGON ((325162.84 6652316.2, 325162.84 6698791.51, 363715.31 6698791.51, 363715.31 6652316.2, 325162.84 6652316.2))","srid":5973},"senterpunkt":{"wkt":"POINT Z(346029.41 6675553.86 0)","srid":5973},"vegobjekt":{"id":1002101480,"type":946,"href":"https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no/vegobjekter/946/1002101480"}}
at no.vegvesen.nvdbapi.client.gson.GsonUtil.lambda$rt$9(GsonUtil.java:231)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$Itr.forEachRemaining(ArrayList.java:901)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
at no.vegvesen.nvdbapi.client.clients.AreaClient.getMunicipalities(AreaClient.java:62)
https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no/vegobjekter/946/1002101480 - works fine
One more thing...
https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no/vegobjekter/60/statistikk?segmentering=true&fylke=54
<errors>
<error>
<code>4002</code>
<message>Ukjent fylke: 54</message>
<help_url>https://nvdbapiles-v3-stm.utv.atlas.vegvesen.no/dokumentasjon/openapi/#/Vegobjekter</help_url>
</error>
</errors>
54 - Troms og Finmark
Hei. sendte nettopp et endringssett til NVDB til: https://nvdbapiskriv.utv.atlas.vegvesen.no/rest/v3/endringssett
Og det ble prosessert vellykket/Utført.
Men finner ikke objektet igjen i: https://nvdbapiles-v3.utv.atlas.vegvesen.no/vegobjekter/60/1011511659
<errors>
<error>
<code>4016</code>
<message>Feature 1011511659, version null of type 60 gone!</message>
<help_url>https://nvdbapiles-v3.utv.atlas.vegvesen.no/dokumentasjon/</help_url>
</error>
</errors>
Hello eveyone.
First and foremost big thanks for creating and maintaining this API with so rich data. I started lately to explore vegobjekter . I was wondering about how the historical data is taken care of. According to info here: https://api.vegdata.no/om_nvdb.html one can only query currently valid objects. I have tried to play with alle_versjoner=true
option, but I am still struggling to understand this versioning.
Take Fartsgrense (105) as an example. There is an object with two inputs (versions) in metadata. One version has startdato and sluttdato, end the second version has startdato (same as sluttdato of previous version) and missing sluttdato. If one checks egenskaper for these two versions, both are identical with exactly the same 'Gyldig fra dato' (5127). So my questions are:
Hope I expressed my thoughts clearly. Looking forward for any information. Thank you
alle_versjoner=true
av mange forskjellige vegobjekttyper , slik at vi får inn alle endringer. Vi har litt problemer med Vegreferanse (532), hvor det er veldig mange endringer. Selv om området vårt inneholder ca 160 000 vegreferanser kom det i løpet av forrige måned inn over 200 000 endringer. Er dette på grunn av noe batch-oppdateringer dere har holdt på med i løpet av denne perioden, eller kan vi forvente at det vil være slik fremover for dette temaet?
https://nvdbapiles-v3.utv.atlas.vegvesen.no
down? <body>
<div>
<h1>Application is not available</h1>
<p>The application is currently not serving requests at this endpoint. It may not have been started or is still starting.</p>
<div class="alert alert-info">
<p class="info">
Possible reasons you are seeing this page:
</p>
<ul>
<li>
<strong>The host doesn't exist.</strong>
Make sure the hostname was typed correctly and that a route matching this hostname exists.
</li>
<li>
<strong>The host exists, but doesn't have a matching path.</strong>
Check if the URL path was typed correctly and that the route was created using the desired path.
</li>
<li>
<strong>Route and path matches, but all pods are down.</strong>
Make sure that the resources exposed by this route (pods, services, deployment configs, etc) have at least one pod running.
</li>
</ul>
</div>
</div>
</body>