by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Julian Klock
    @juliank
    POST https://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett returnerer 201 Created med Response Header sin Location satt til http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]. Videre er Response Body som følger:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ressurser xmlns="http://nvdb.vegvesen.no/apiskriv/domain/changeset/v3">
        <ressurs rel="self" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]"/>
        <ressurs rel="start" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]/start"/>
        <ressurs rel="kanseller" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]/kanseller"/>
        <ressurs rel="status" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]/status"/>
        <ressurs rel="fremdrift" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]/fremdrift"/>
        <ressurs rel="fremdriftOgÅrsak" src="http://[custom].azurewebsites.net/nvdb/apiskriv/rest/v3/endringssett/[guid]/fremdriftOg%C3%85rsak"/>
    </ressurser>
    Julian Klock
    @juliank

    Man kan også observere denne feilen allerede første gang man aksesserer siden. Går jeg mot https://[custom].azurewebsites.net/ for deretter å klikke meg videre til lenken for NVDB API Skriv (https://[custom].azurewebsites.net/nvdb/apiskriv/) så svarer denne med en 302 Found med Location /openam/login?target=http%3A%2F%2F[custom].azurewebsites.net%2Fnvdb%2Fapiskriv%2F som igjen redirigerer meg til https://[custom].azurewebsites.net/openam/login?target=http%3A%2F%2F[custom].azurewebsites.net%2Fnvdb%2Fapiskriv%2F. Så allerede her ser man at http har sneket seg inn i target-parameteret. Og hvis jeg der fortsetter med innloggingen ender jeg til slutt opp på http://[custom].azurewebsites.net/nvdb/apiskriv/ (hvor jeg forsåvidt manuelt kan endre til https og forsatt være innlogget).

    Jeg kan for øvrig sende den fullstendige URL-en på PM, om dere har interesse av å teste det selv.

    Tore Eide Andersen
    @torand
    Det er ingen hardkoding av schema/protokoll i URLene. Verdiene som returneres i Location og <ressurser> dannes programmatisk ved å ta utgangspunkt i hva aktuelle Java-rammeverk oppfatter som inngående URL. Docker-imaget ble laget for å ha kjørende på localhost og meg bekjent er det ingen andre som (til nå) har prøvd å rulle det ut i skyen. Det er mulig det kan gjøres tilpasninger av imaget for å støtte skykontekst, men dette vil nødvendigvis ta noe tid og det blir et spørsmål om kostnadsfordeling osv. Om dere opplever begrensningene i Docker-imaget som smertefulle råder jeg deg til å melde et endringsønske til Statens vegvesen, så får vi ta dialogen derfra.
    Jose Antonio Hernandez
    @josea.hernandez_gitlab
    Hi. Doing some tests in the Skriv Docker image but without success. I am doing something like this: curl -v http://172.16.0.32:8010/nvdb/apiskriv/rest/v3/endringssett/validator -d '{"datakatalogversjon":"2.20","registrer":[{"typeId":95,"tempId":"BU-2147482399","gyldighetsperiode":{"startdato":"2020-05-16"},"egenskaper":[{"typeId":"4794","geometri":{"srid":4326,"wkt":"POINT Z(10.633060883974899 59.91353864102825 27.150788245603753)"}}]}]}' -H 'Content-Type: application/json' -H 'Cookie:iPlanetDirectoryProOAM=cGVwZQ==' I'm not sure if 8010 port is the correct one for requesting to the validator service or if it is up and running correctly. Any curl command that I can execute to check validator service is ok?
    Julian Klock
    @juliank
    Takk for oppfølging @torand . Jeg vil nok tro vi klarer oss med Docker-imaget slik det er nå. Direkte API-forespørsler vil antageligvis fungere fint, så det er nok bare den "live utprøvingen" som ikke fungerer helt optimalt. Når det er sagt så ser det også ut til å fungere i Azure hvis vi tillater http-trafikk og ignorerer varsler pga. manglende TLS-skiring.
    Tore Eide Andersen
    @torand
    @josea.hernandez_gitlab Port 8010 is correct, but there is a X-Client header missing in the request
    adriankreutz
    @adriankreutz
    Hei,
    Jeg får en litt rar feilmelding på et endringsett, https://www.test.vegvesen.no/nvdb/apiskriv/kontrollpanel/#/jobs/view/d1cd56ac-ecc6-44e5-83a8-e15ea07d1dd5
    Hva er det som forårsaker den feilen?
    Tore Eide Andersen
    @torand
    @josea.hernandez_gitlab also try to replace 172.16.0.32 with localhost
    Tore Eide Andersen
    @torand
    @adriankreutz du forsøker å registrere et vegobjekt med stedfesting på en del av vegnettet som ikke har sammenfallende gyldighetsperiode med vegobjektet. Vegobjektet har gyldighet fra 2020-06-24 og til evig tid, mens intervallet [0.06400687247514725, 0.31874698400497437) på veglenkesekvensen 805705, som det er stedfestet på, ikke er gyldig i hele denne perioden.
    oddoyg
    @oddoyg

    Hei.

    Sliter fortsatt med å få registrert "kjørefelt" som en del av stedfestingen. Har lagt inn kjørefelt i tabell, men får fortsatt feil.

    Endringssett:
    {"datakatalogversjon":"2.21","registrer":{"vegobjekter":[{"gyldighetsperiode":{"startdato":"2020-06-30"},"stedfesting":{"punkt":[{"posisjon":0.08158708,"veglenkesekvensNvdbId":47421,"sideposisjon":"V","kjørefelt":["2"]}]},"typeId":95,"tempId":"1","egenskaper":[{"typeId":1876,"verdi":["Gittermast"]},{"typeId":4794,"geometri":[{"srid":4326,"wkt":"POINT (63.375522668208994 10.366523265838625)","kvalitet":{"målemetode":"82","nøyaktighet":"100","synbarhet":"0"}}]}]}]}}

    Feil:
    Invalid UTF-8 start byte 0xf8 at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 1, column: 198] (through reference chain: no.vegvesen.vt.nvdb.apiskriv.representation.model.domain.changeset.v3.Endringssett["registrer"]->no.vegvesen.vt.nvdb.apiskriv.representation.model.domain.changeset.v3.Registrering["vegobjekter"]->java.util.ArrayList[0]->no.vegvesen.vt.nvdb.apiskriv.representation.model.domain.changeset.v3.NyttVegobjekt["stedfesting"]->no.vegvesen.vt.nvdb.apiskriv.representation.model.domain.changeset.v3.Stedfesting["punkt"]->java.util.ArrayList[0])

    Sendt til test.vegvesen.

    Tore Eide Andersen
    @torand
    jeg finner ingen feil i endringssettet. Når du åpner https://www.test.vegvesen.no/nvdb/apiskriv/generator, klikker JSON, deretter KLADD og limer inn endringsettet, vil du se at det går gjennom uten feil når du klikker Send. Problemet ligger antageligvis i encodingen du bruker ved generering av endringssettet i klientkoden din.
    oddoyg
    @oddoyg
    Det har du muligens rett i. søker videre.... Beklager bryderiet!!
    Jose Antonio Hernandez
    @josea.hernandez_gitlab
    Hi. When sending to NVDB Write service a new object, how is it known the attribute ID for the geometry if there are several attributes with geometry datatypes? For example when sending {"datakatalogversjon":"2.20","registrer":[{"typeId":95,"tempId":"BU-2147482399","gyldighetsperiode":{"startdato":"2020-05-16"},"egenskaper":[{"typeId":"4794","geometri":{"srid":4326,"wkt":"POINT Z(10.633060883974899 59.91353864102825 27.150788245603753)"}}]}]} I can see in the catalog that there is only one point datatype (4794) for this type of objects so I can use 4794, but what can I do when there are several geometry attributes? Is there in the descriptor of the object that identifies the main geometry?
    Tore Eide Andersen
    @torand
    the main (i.e. most important or significant) geometry is the spatial attribute having the lowest number for "Viktighet". E.g. see https://datakatalogen.vegdata.no/199-Tr%C3%A6r, expand the "Geometri, xxx" entries and observe that typeId 5896 has the lowest number of the three spatial attributes.
    bjosor
    @bjosor

    Hei.
    Jeg har litt problemer med å teste endringssett i docker. Sånn jeg har forstått det så bør post requests mot http://localhost:8010/nvdb/apiskriv/rest/v3/endringssett
    enten gi en 302 respons ved manglende autentisering eller 201 og svare med muligheter for videre handlinger mot endringssettet. Problemet mitt er at hver gang jeg sender noe til dette endepunktet så får jeg 200 tilbake sammen med html koden fra login siden.

    Data og headers i requesten ser slik ut:

    url: 'http://localhost:8010/nvdb/apiskriv/rest/v3/endringssett',
    method: 'post',
    data: { headers: { Cookies: 'iPlanetDirectoryProOAM=YXA=' } },
    headers: {
       common: { Accept: 'application/json, text/plain, */*' },
       delete: {},
       get: {},
       head: {},
       post: { 'Content-Type': 'application/x-www-form-urlencoded' },
       put: { 'Content-Type': 'application/x-www-form-urlencoded' },
       patch: { 'Content-Type': 'application/x-www-form-urlencoded' }
    }

    Hva er det jeg går glipp av her?

    bjosor
    @bjosor
    Jeg ser jeg hadde fått headers i data delen her, men jeg har testet flere versjoner bare for å se om jeg kan få et annet svar, det er samme svaret når jeg har headers riktig og faktisk sender med et endringssett
    Tore Eide Andersen
    @torand
    bytt ut "Cookies" med "Cookie"
    Tore Eide Andersen
    @torand
    du mangler også headeren X-Client
    alt dette er forklart her: https://apiskriv.vegdata.no/autentisering
    bjosor
    @bjosor
    Ser ut som det var det jeg manglet ja. Takk for hjelpen!
    Jose Antonio Hernandez
    @josea.hernandez_gitlab
    In the new reference system V3 each object has a stedfestinger array and a vegsystemreferanser array inside the lokasjon provided in the responses. Am I right if I assume that the length of each array should be the same and that both are different ways to provide a reference to the same location?
    Marvin Bredal Lillehaug
    @computerlove
    @josea.hernandez_gitlab stedfestinger is how objects are located on the roadnet. vegsystemreferanser is a human friendly representation of the location on the roadnet.
    The length of those lists does not need be of the same length
    Jose Antonio Hernandez
    @josea.hernandez_gitlab
    Thanks @computerlove I am bit confused here. Does that mean that the underlying roadnet is different for each type of references? For example, if the object extends through several veglenke (subsections) in the road is it possible to have five vegsystemreferanser but three stedfestinger, each one representing a segment in different topological road networks? Or is the difference in length due to other causes?
    Marvin Bredal Lillehaug
    @computerlove

    A object may be placed/stedfesteton [0-1@123, 0.23-0.75@321, 0.5-1.0@666], but this could be the vegsystemreferanse [EV6S12D23M0-999]. But it may be that this consists of [EV6S12D23M0-123, EV6S12D23M123-666, EV6S12D23M666-999].

    Note that API Skriv only cares about placements/stedfestingerlike 0.23-0.75@321.

    Jose Antonio Hernandez
    @josea.hernandez_gitlab
    @computerlove I see. So both share the same topological network, it is just a matter that vegsystemreferanse is even shorter form to reference several stedfestings, and when sending changes or new objects only stedfestinger must be sent. That clarifies me a lot of things. Thanks again
    Marvin Bredal Lillehaug
    @computerlove
    @josea.hernandez_gitlab The complete reference for the roadnet can be found at https://www.vegvesen.no/_attachment/61505
    xorfindude
    @xorfindude
    Hei, kjapt spørsmål angånde docker: Er det noen forskjell i innholdet til det lokale datasettet som følger med dockeren og data man kan lese ut ifra https://nvdbapiles-v3.atlas.vegvesen.no ? Prøver å teste å registrering på forksjellige lokasjoner men får UKJENT_VEGLENKESEKVENS når jeg prøver å registrere med veglenkesekvensIDer hentet fra https://nvdbapiles-v3.atlas.vegvesen.no med GET https://nvdbapiles-v3.atlas.vegvesen.no/posisjon?lat='eksempel_lat'&lon='eksempel_lon'
    Marvin Bredal Lillehaug
    @computerlove
    @xorfindude jeg tror ikke det er noen data i den Docker-instansen. Den inneholder kun datakatalogen og de andre tingene som er nødvendig for å utføre de valideringene som kjøres ved behandling av endringssettet
    xorfindude
    @xorfindude
    @computerlove ok, det forklarer en hel del. Takk for svar!
    xorfindude
    @xorfindude
    Hei igjen, har litt problemer med autentisering og håper noen kan bidra med litt innsikt.
    Prøver å autentisere mot https://www.utv.vegvesen.no/ws/no/vegvesen/ikt/sikkerhet/aaa/autentiser men får istede feilmelding 'ECONNRESET at TLSWrap.onStreamRead (internal/stream_base_commons.js:205:27)' som, hvis jeg forstår det riktig, tyder på at forbindelsen blir brutt/reset. Bruker nøyaktig samme format på request ved testing av autentisering mot docker og det fungerer det fint. Tyder dette på at tilkobling blir avbrutt av endepunktet? Trenger jeg å formatere requestet på en annen måte ved autentisering? På forhånd takk.
    Tore Eide Andersen
    @torand
    Anroper du https://www.utv.vegvesen.no/ws/no/vegvesen/ikt/sikkerhet/aaa/autentiser fra Statens vegvesen sitt lokalnett eller utenfra? www.utv.vegvesen.no er normalt kun tilgjengelig fra lokalnett.
    xorfindude
    @xorfindude
    Problemet viste seg å være IP tilgang, er løst nå. Takk for svar!
    adriankreutz
    @adriankreutz

    @adriankreutz du forsøker å registrere et vegobjekt med stedfesting på en del av vegnettet som ikke har sammenfallende gyldighetsperiode med vegobjektet. Vegobjektet har gyldighet fra 2020-06-24 og til evig tid, mens intervallet [0.06400687247514725, 0.31874698400497437) på veglenkesekvensen 805705, som det er stedfestet på, ikke er gyldig i hele denne perioden.

    Hei, hvordan skal dette da løses, skal de veglenkene med annen gyldighet hoppes over? i dette tilfellet så ser det ut som det er en bit som blitt gjort historisk, gyldigheten er fra 1950-2011, https://www.vegvesen.no/nvdb/api/v3/vegnett/veglenkesekvenser/805705, er det riktig at en del av en veglenkesekvens kan bli gjort historisk/ugyldig?

    Tore Eide Andersen
    @torand
    ja, i dette tilfellet er en del av veglenkesekvensen lukket, det vil si ugyldig fra en dato i 2011. Det ugyldige posisjonsintervallet må derfor vekk fra stedfestingen. Dersom det ugyldige intervallet ble erstattet med en ny veglenkesekvens (dvs ny fysisk veg) og vegobjektet naturlig hører til denne, må den tas med også.
    POJUDK
    @POJUDK

    Hej, håber I kan hjælpe mig. Jeg kalder https://www.vegvesen.no/nvdb/apiskriv/rest/v3/endringssett/017c86a0-c1de-4124-85af-6d5f0e9ec35c/fremdrift og får returncode OK - men responsecontent er nedenstående html. Kan I se hvad der går galt?

    <!DOCTYPE html>

    <html>
    <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>OpenAM</title>
    </head>
    <!--[if IE 9]> <body style="display:none" class="ie9"> <![endif]-->
    <!--[if (gt IE 9)|!(IE)]><!-->
    <body style="display:none">
    <!--<![endif]-->
    <div id="messages" class="clearfix"></div>
    <div id="wrapper">Loading...</div>
    <div id="popup">
    <div id="popup-content" class="radious"></div>
    </div>
    <footer id="footer" class="footer text-muted"></footer>
    <script type="text/javascript">
    var require = {
    urlArgs : "v=13.5.2",
    deps : ['main']
    };
    </script>
    <script src="libs/requirejs-2.1.14-min.js"></script>
    </body>
    </html>

    Tore Eide Andersen
    @torand
    Din request ser ut til å ha manglet godkjent autentiseringstoken. Anropert ble derfor redirigert til websiden for pålogging i OpenAM. Se detaljer på https://apiskriv.vegdata.no/autentisering
    POJUDK
    @POJUDK
    @torand Burde den ikke kommer retur med en 403 i stedet i det tilfælde hvor logintoken ikke er validt.
    Tore Eide Andersen
    @torand
    Den returner 302 med header "Location" som inneholder redirect-url (websiden til OpenAM). Ditt klientrammeverk, som antagelig er satt opp med auto-redirect, fanger opp dette og går til angitte redirect-url og får tilbake den HTML du viste over med statuskode 200 OK.
    302-responsen er by design internt hos Statens vegvesen. Validering av autentiseringstoken skjer utenfor API Skriv-applikasjonen.
    Julian Klock
    @juliank
    Hei. Jeg prøver å teste skriving mot Docker-kontaineren for APISKRIV. Jeg har generert et så enkelt endringssett som mulig (et skiltpunkt med en stedfesting), og det går gjennom den initielle "strukturelle" valideringen. Men det blir likevel avvist med feilkoden "UKJENT_VEGLENKESEKVENS" og meldingen "Vegobjektet er stedfestet på veglenkesekvens 41946, som ikke finnes". Har også prøvd å stedfeste på litt ulike veier, bare i tilfelle jeg var uheldig med utvalget mitt, men får samme feilen. Hva skyldes dette? Er det manglende data i Docker-kontaineren?
    Tore Eide Andersen
    @torand
    Docker-container inneholder ikke en reell NVDB-database. API Skriv inne i containeren er integrert med en liten minnedatabase med noen få data, inkludert noen få veglenkesekvenser. Hvilke veglenkesekvenser kan du avlede av testcasene i Generator-applikasjonen (../nvdb/apiskriv/generator). Testcase 1 registrerer f.eks. en ny tunnel. Sjekk stedfestingen der. Minnedatabasen er kun satt opp med data som understøtter testcasene. Ved registrering blir ikke nye data lagt inn minnebasen, den er kun lesbar for API Skriv. NVDB bor vanligvis på en Oracle Spatial RDBMS. Å inkludere den i docker-imaget, er ikke en opsjon pga. lisenskostnader og mye lengre oppstartstid.
    Julian Klock
    @juliank
    Takk, da vet jeg hvor jeg finner gyldige veglenkesekvenser.
    Olav Dahl Solstad
    @olav89
    Hei. Er det noen endepunkt for innlogging som returnerer en Set-Cookie for videre requester? Eventuelt, er det mulig å sende token med en Authorization-header eller lignende? Skal kalle APIet fra en frontend der det ikke er rett frem og legge til cookies på requester.
    Tore Eide Andersen
    @torand
    Nei, ikke som jeg kjenner til. Dette må du i så fall lage selv på egen backend. Autentisering er beskrevet her: https://apiskriv.vegdata.no/autentisering
    Olav Dahl Solstad
    @olav89
    Så det er ikke ment å kunne lage klienter som kun er frontend som går mot API-Skriv?
    Tore Eide Andersen
    @torand
    Jeg tror det blir rimelig komplisert , om ikke umulig. Jeg kjenner ikke til noen som har fått det til. Klienter må implementere en form for porteføljeovervåking siden API Skriv er et asynkront API. Du trenger derfor å lagre unna endringssett-ider for innhenting av status og oppfølging. Dette kan selvsagt lagres i local storage i nettleseren, men du er da låst til nettleseren på den aktuelle maskinen. Les mer her: https://apiskriv.vegdata.no/endringssett/introduksjon#asynkron-behandling og https://apiskriv.vegdata.no/endringssett/introduksjon#samhandling-mellom-klient-og-api
    Julian Klock
    @juliank
    Bare for å utdype litt rundt spørsmålet til @olav89: Vi jobber med en løsning bestående av en SPA-klient og vår egen backend for alt som skal (mellom)lagres. Men enkelte kall hadde det vært greit om klienten kunne gjøre direkte mot APISKRIV (f.eks. å hente ut utfyllende detaljer om innsendt endringssett), rett og slett fordi backend ikke har behov for denne dataen. Og da blir det litt unødvendig å ha backend til å opptre som en ren proxy mot APISKRIV (både mtp. implementasjonen, men også den ekstra latencyen). Så hadde det vært mulig å gjøre autentisering vha. Authorization-header istedenfor å sette det som en cookie hadde det gitt oss litt flere muligheter. Så det kan jo være et innspill til ev. fremtidige endringer/forbedringer av autorisasjon i APISKRIV :-) (Og når vi likevel er inne på temaet: ordentlig OAuth-støtte hadde jo vært gull ;-))
    2 replies
    Nils Nortier
    @nNortierJ
    hei, vi i TRULS prøvde å skrive et endringssett i går ettermiddag men har stått stille med fremdrift: VENTER. Endringsett: https://pm1.utv.vegvesen.no/nvdb/apiskrivbeta/rest/v3/endringssett/d8b496d1-6d4f-41a5-99ff-ba1bd4aece9f. Har dere noen tanker om er årsaken til dette?
    5 replies