GithubHelp home page GithubHelp logo

nvdb-vegdata / nvdb-api-client Goto Github PK

View Code? Open in Web Editor NEW
13.0 16.0 8.0 1.4 MB

BSD-licensed open source Java library for consuming NVDB REST API

License: BSD 2-Clause "Simplified" License

Java 99.94% Shell 0.06%

nvdb-api-client's Introduction

nvdb-api-client

Open source Java client library for use with the NVDB REST API v3.

Support or feedback: Issue on this repo or on Gitter

API URL

Base URL for the API is https://nvdbapiles-v3.atlas.vegvesen.no

Artifact

This artifact will be published to Maven Central upon releases.

Gradle

def nvdbVersion = "1.17.2"
def slfVersion = "1.7.30"

dependencies {
    compile "no.vegvesen.nvdb:nvdb-read-api-v3-client:$nvdbVersion"
    compile "javax.activation:activation:1.1"
    compile "org.slf4j:slf4j-api:$slfVersion"
    compile "org.slf4j:slf4j-simple:$slfVersion"
}

Maven

<properties>
    <nvdb.version>1.17.2</nvdb.version>
    <slf.version>1.7.30</slf.version>
</properties>

<dependencies>
    <dependency>
        <groupId>no.vegvesen.nvdb</groupId>
        <artifactId>nvdb-read-api-v3-client</artifactId>
        <version>${nvdb.version}</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>${slf.version}</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>${slf.version}</version>
    </dependency>
</dependencies>

Getting started

Using the client is very simple. All it takes is a couple of lines of code.

Authentication

This is a completely open API, but some featuretypes are restricted and need authentication and authorization. We strongly encourage using the X-Client-Name header because it helps us gather statistics which we use to improve the API.

Example

To start using the library simply instantiate the factory. It takes three arguments:

  1. Base URL for the API
  2. Value for request header X-Client-Name
// First, create factory
ClientFactory factory = new ClientFactory("https://nvdbapiles-v3.atlas.vegvesen.no", "nvdb-read-api-v3-client");
// Then, create your client. Typically, there's one per root endpoint   
RoadObjectClient client = factory.getRoadObjectClient();

// Example single object download
RoadObject ro = client.getRoadObject(534, 1);

// Remember to close your factory when you're done using it
factory.close();

Please note that when the factory is closed all clients created by it will also be closed. So the following code will not work

RoadObjectClient client;
try (ClientFactory factory = new ClientFactory("https://nvdbapiles-v3.atlas.vegvesen.no", "nvdb-read-api-v3-client")) {
    client = factory.createRoadObjectClient();
}

// Won't work because client is closed after the try-with-resources block.
RoadObject ro = client.getRoadObject(534, 1);

Setting timeouts for Jersey client.

To set a connect and read timeout for the nvdb-api-client. An instance of ClientConfiguration can be added when creating the ClientFactory

// Add a read timeout of 5000 millis and connect timeout of 1000 millis
ClientConfiguration clientConfig = 
   ClientConfigurationBuilder.builder()
      .withReadTimeout(5000)
      .withConnectTimeout(1000)
      .build();

// Create a factory with timeout settings.
ClientFactory factory = new ClientFactory("https://nvdbapiles-v3.atlas.vegvesen.no", "nvdb-read-api-v3-client", clientConfig);

Simple setup

To use the client in your project, you should:

  1. Add the gradle or maven code to your project build file (pom.xml for maven projects);
  2. Fill in your preferred version at $version (maven versions are available here: https://search.maven.org/artifact/no.vegvesen.nvdb/nvdb-read-api-v3-client);
  3. Add some of the example code and run it.

How to build

The repo contains the Gradle wrapper. The client is built running:

// Simple compilation 
./gradlew build

// Publish to your Maven local
./gradlew publishToMavenLocal

nvdb-api-client's People

Contributors

andpaas avatar computerlove avatar daniesso avatar hansog avatar jleknes avatar johannsl avatar krimjo avatar magnusulstein avatar mariuskaa avatar matsandreassen avatar matsandreassen-triona avatar monsendag avatar pal-thomassen avatar runeschuermann avatar sanderpett avatar sindrevik avatar tollefj avatar torkie avatar torstorruste avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nvdb-api-client's Issues

AsyncResult støtter ikke resubscribe

Når man kaller roadObjectClient.getRoadObjectsAsync(featureTypeId, roadObjectRequest).get() får man tilbake en Flux som er knyttet til en ExecutorService som avsluttes når Flux-en termineres. Det fører til problemer dersom man forsøker å konsumere flux-en på nytt, fordi ExecutorService-en ikke lengre tar i mot nye jobber, og man får en litt kryptisk RejectedExecutionException. Jeg mener at det er et ganske vanlig brukstilfelle å konsumere en Flux på nytt. I vårt tilfelle hadde vi en jobb som brukte flux.retry(3) for å prøve på nytt ved feil fra API-et, men et forsøk på retry vil da gi overnevnte feil (og i vårt tilfelle faktisk svelge hele stacktrace-en 😞).

For meg ser det ut som en mulig løsning å flytte instansieringen av ExecutorService-en inn i AsyncResult.get, sånn her:

  public Flux<T> get() {
    return Flux.create(sink -> {
      ExecutorService executorService = Executors.newSingleThreadExecutor();

      executorService.execute(() -> {
        try {
          PagingIndicator pagingIndicator = doPage(sink, page);
          while (pagingIndicator.hasNext) {
            pagingIndicator = doPage(sink, pagingIndicator.currentPage);
          }
        } catch (Exception e) {
          sink.error(e);
        } finally {
          sink.complete();
          executorService.shutdown();
        }
      });
    });
  }

Da vil man i så fall instansiere en ny ExecutorService hvis man subscriber på flux-en på nytt. Hva tenker dere om det? Jeg lager gjerne en PR.

unøyaktighet for oppslag på posisjon

Ser ut som det er unøyaktighet i oppslag på posisjon, både i API les v2 og v3. Hadde ventet å få kryssystem med søk på posisjonen til EV18 S2D1 m8909 KD3 m10:

$ curl "https://apilesv3-stm.utv.atlas.vegvesen.no/veg?vegsystemreferanse=EV18S2D1m8909KD3m10" --silent | jq .geometri.wkt
"POINT Z(303991.385 6605302.555 191.121)"
$ curl "https://apilesv3-stm.utv.atlas.vegvesen.no/posisjon?ost=303991.385&nord=6605302.555" --silent | jq .[0].vegsystemreferanse.kortform
"EV18 S2D1 m9207" <---- Hadde forventet å få "EV18 S2D1 m8909 KD3 m10"

Oppslaget gir kun ett treff:

$ curl "https://apilesv3-stm.utv.atlas.vegvesen.no/posisjon?ost=303991.385&nord=6605302.555" --silent | jq '. | length'
1

Litt lenger bort på kryssystemet, meterverdi 20, fungerer fint.

En kan detektere feilen ved å se at posisjon returnert er flyttet 2.5 meter unna posisjonen som det ble søkt på:

$ curl "https://apilesv3-stm.utv.atlas.vegvesen.no/posisjon?ost=303991.385&nord=6605302.555" --silent | jq .[0].geometri.wkt
"POINT Z(303991.603 6605305.065 191.446)"

Manglende lukking av Jersey Response-objekt

Jeg har problemer med at RoadObjectClient.getRoadObjects forårsaker kall som henger uendelig. Det skjer i et ganske spesifikt tilfelle, så sliter med å produsere et minimalt reproduserbart eksempel, men tror det er forårsaket av at GenericResultSet.next ikke lukker Response-objektene sine. Jeg mistenker at dette fører til en ressurs-lekkasje der det til slutt ikke er igjen flere ledige connections. Observerer at feilen løses dersom jeg lukker response-objektene (se PR).

Hvordan henter jeg vegobjekttype kategori?

Hei,
I Java applikasjon "Datakatalog" alle veggobjekter er delt i kategorier. Hvordan henter jeg kategoriene i APIen? Hvordan kan jeg hente objekter som er knyttet kun til en bestemt kategori?
Takk! :)

Publish to maven central repo?

Hi, and thanks for the api-client.
Since v2 is live, are you planning on publishing the api to the maven central repo soon ?

Svært korte segmenter

Det segmenterte vegnettet i api-les v3 inneholder en del svært korte segmenter, ofte bare noen centimeter eller rundt en meter lange. Mye tyder på at de er klippet feil, som om klippingen såvidt bommet på neste segment. En del av disse segmentene har en unormal vinkel til nabosegmentene. De finnes i alle kommuner ser det ut til, f.eks. 9 stk i Grimstad, 72 stk Trondheim osv.

Disse segmentene skaper noen problemer ved fletting av vegobjekter inn i vegnettet fordi start/sluttnode blir liggende for nær hverandre.

Eksempler:
2264914-6-13 (4 cm)
2442974-1-10 (21 cm)
22312-3-17 (47 cm)
1707381-5-6 (89 cm)

Ugyldige tegn i 'veglenkesekvens': mangler eksplisitt formatering av double

Hei, vi får denne når vi henter enkelte attributter på vegobjekter. Bruker siste versjon (1.18.2) av Java-klienten.

Ugyldige tegn i 'veglenkesekvens' field: '3.17E-6@2070659'. Gyldig eksempel: 0.6-0.9@42364

Dette er sannsynligvis grunnet feil formatering når man bruker Double#toString(), f.eks ved konkatenering av double med string. Specen for double viser at formatet ved ren toString() avhenger av verdien, og ved veldig lave eller høye verdier risikerer man å få vitenskapelig notasjon, som vi ser i feilmeldinga. (3.17E-6).

Dette løses ved å bruke String.format() og spesifisere formatet. Jeg har gjort det alle steder jeg kunne finne formatering av posisjon i vår kodebase, men ser at det ikke er gjort alle steder i klientbiblioteket. F.eks RefLinkExtendAttribute#getValueAsString.

Har dere tid/mulighet til å lage en fiks, eventuelt tar dere inn en PR hvis jeg lager en?

Mangler "medium" i segmentert vegnett

Dokumentasjonen i https://nvdbapilesv3.docs.apiary.io/#reference/0/segmentert-vegnett/segmenter-for-veglenkesekvens angir at det segmenterte vegnettet skal eksponere Medium. Medium er imidlertid ikke inkludert i les-api v3 per i dag.

Medium var med i det segmenterte vegnettet i les-api v2. Utfordringer med stedfesting av broer og underganger gjør at Medium ikke kan hentes inn via vegobjekter. Medium er med i det usegmenterte vegnettet (veglenkesekvenser) og kan flettes inn derfra, men det er en kostbar løsning som medfører dobbelt lasting av alle veglenker.

Fint om Medium kunne tas med i det segmenterte vegnettet.

Attributes for Driftskontrakt (580)

Provide attributes for Driftskontraktsområde (Datakatalog code = 580).

AreaClient.getContractAreas() method returns only limited set of properties - id, type, name, number, counties, municipalities.

RoadObjectClient.getRoadObjects() for featureTypeId = 580 returns only IDs, without a properties.
At the same time web endpoint - https://nvdbapiles-v3.utv.atlas.vegvesen.no/vegobjekter/580/114142161:
responds with:

<egenskaper>
    ...
    <egenskap>
        <id>8832</id>
        <navn>Type</navn>
        <egenskapstype>Tekstenum</egenskapstype>
        <datatype>FlerverdiAttributt, Tekst</datatype>
        <verdi>Driftskontrakt</verdi>
        <enum_id>11750</enum_id>
    </egenskap>
    <egenskap>
        <id>8833</id>
        <navn>Dato fra</navn>
        <egenskapstype>Dato</egenskapstype>
        <datatype>Dato</datatype>
        <verdi>2007-09-01</verdi>
    </egenskap>
    <egenskap>
        <id>8834</id>
        <navn>Dato til</navn>
        <egenskapstype>Dato</egenskapstype>
        <datatype>Dato</datatype>
        <verdi>2020-01-01</verdi>
    </egenskap>
    <egenskap>
        <id>5174</id>
        <navn>Navn</navn>
        <egenskapstype>Tekst</egenskapstype>
        <datatype>Tekst</datatype>
        <verdi>MIDTHORDALAND</verdi>
    </egenskap>
    <egenskap>
        <id>5175</id>
        <navn>Nr</navn>
        <egenskapstype>Heltall</egenskapstype>
        <datatype>Tall</datatype>
        <verdi>5</verdi>
    </egenskap>
</egenskaper>

Interested mostly in next properties:
Navn - 5174
Nr - 5175
Type - 8832
Dato fra - 8833
Dato til - 8834

It would be also nice to have possibility receive attributes for multiple driftskontrakt at once, based on IDs in request, for example - it will reduce amount of requests to the service.

Manglende støtte for EE9

Hei!

Jeg ville oppgradere prosjektet mitt videre fra EE7 og møtte på en snag da denne klienten bygger mot javax-pakken som nå er "kastet ut av Oracle". Jeg gjorde en fork for å komme videre men jeg tenkte å nevne dette for dere. Slik jeg ser det kan dere

a) lage en build-variant slik at man kan velge eller
b) skrive om kommunikasjonslaget til noe annet som f.eks. OkHttp

Eller gjør ingenting. Jeg kommer som sagt videre med min fork.

Noen segmenter har sluttposisjon før startposisjon

Det finnes noen få segmenter i det segmenterte vegnettet i api-les v3 som har sluttposisjon før startposisjon. De medfører problemer ved fletting av vegobjekter.

Det er f.eks. tre stk i Trondheim: 3141465-1-5, 3141466-1-5 og 3113846-1-4.

filter `relasjon` in `vegobjekter?egenskap` is failing

Expected egenskap-filter to work on all objects in datakatalogen:

https://apilesv3-stm.utv.atlas.vegvesen.no/vegobjekter/445?antall=10&inkluder=relasjoner&egenskap=relasjon(446,egenskap(2361)=4254)

Gives code 5000, Det har dessverre oppstått en feil!

Note: The example in the documentation is missing an ending parenthesis, which gives Expected RPAREN got null in expression: relasjon(67,egenskap(1317)>2000.

NPE i RoadObjectRequest::toMutable

RoadObjectRequest::toMutable kaster en NPE hvis allVersions ikke har blitt satt (f.eks ved å kalle withAllVersions på builderen).

Problemet bryter ned til bruk av Boolean wrapper-typen i feltene, mens parameteret til withAllVersions bruker boolean-primitiven. Så hvis et RoadObjectRequest-objekt har blitt bygget uten at allVersions har blitt satt, ender man opp med allVersions lik null. toMutable prøver så å kalle RoadObjectRequest.Builder::withAllVersions med RoadObjectRequest-objektets allVersions-verdi som umiddelbart konverteres til boolean, som ender opp med å kaste en NPE fordi null ikke er en gyldig boolean-verdi.

https://github.com/nvdb-vegdata/nvdb-api-client/blob/master/src/main/java/no/vegvesen/nvdbapi/client/clients/RoadObjectRequest.java#L532

Manglende identifisering av broer i vegobjekt 60

Vegobjekt 60 Bru leverer vegsegmenter både under og over broen i api-les v3, men det leveres ikke noe informasjon som gjør det mulig å finne ut hvilket segment som er selve broen (i motsetning til veier under den).

Dette gjør at vegobjektet ikke kan brukes til å gi avgjøre hvor det er broer i det segmenterte vegnettet. Dette skaper også problemer når man f.eks. ønsker å flette inn navnet på broen eller annen bro-informasjon til vegnettet. En løsning kunne være å bruke Medium eller Sideposisjon til å identifisere broene (eller undergangene, som også returneres av vegobjekt 60).

I tillegg er det ikke mulig å skille to broløp som ligger ved siden av hverandre der f.eks. høyre og venstre kjørebane er skilt på en motorvei. To slike broløp har gjerne litt forskjellig utstrekning og navn. For tunneler er dette løst ved at Kjørefelt er tatt med for hvert tunnelløp. Det kunne vært en løsning for broløpene også.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.