
Mange av dere vet kanskje ikke dette, men Sitatas tidlige grunnlag ble bygget for tidlig sykdomsoppdagelse. Faktisk har grunnleggeren vår et TedX-foredrag fra 2016 som handler om hvorfor vi må advare reisende for å bidra til å hindre spredning av sykdommer. Det burde derfor ikke komme som noen overraskelse at vi fanget opp covid-19 da det ble rapportert om en uvanlig opphopning av tilfeller av lungebetennelse tidlig i desember 2019. Den 2. januar 2020 bestemte helseteamet vårt at vi skulle utstede vår første advarsel til våre reisende og forretningspartnere. Dette var flere dager før Verdens helseorganisasjon!
Under det uunngåelige nedfallet fikk vi en åpenbaring. Sykdommen spredte seg så raskt at det var klart for oss at den globale responsen i beste fall ville bli kaotisk. Hvert land ville vedta sitt eget sett med forskrifter og regler for hvordan de skulle kontrollere spredningen. Dette ville uunngåelig skape kaos i den globale reisevirksomheten og være en stor kilde til forvirring for dem som fortsatt ønsket å reise. Vi hadde rett, og vi satte oss fore å gjøre noe med det. Sitata var et av de første selskapene i verden som opprettet et eget API og en egen overvåkingstjeneste for endringene i reiserestriksjoner og innreisekrav som følge av covid-19. Med et avansert programvaresystem for hendelsesdeteksjon og et dedikert team av analytikere hadde vi allerede alle de riktige verktøyene og prosessene på plass for å gjøre dette.
Siden lanseringen av denne nye tjenesten har en rekke organisasjoner benyttet seg av dataene til fordel for sine egne kunder, inkludert Eddy Travels, Flight Centre og Etihad Airways, og flere vil snart bli annonsert! For å hjelpe flere reiselivsorganisasjoner med å dra nytte av dette tilbudet, har vi skrevet en rekke eksempler nedenfor for å forklare hvordan du kan bruke API-et til en rekke ulike bruksområder. Jeg håper disse forklaringene hjelper deg med å komme i gang med dine egne initiativer.
De første spørsmålene en reisende stiller er uten tvil "kan jeg reise dit?" og "kommer jeg til å bli satt i karantene?", så dette er et godt sted å starte. Vi har laget datasettet Innreisekrav for å besvare de vanskelige "ja/nei"-spørsmålene om innreise til et land eller en region.
I skrivende stund omfatter dette datasettet følgende 10 forskjellige kategorier:
Hver kategori kan ha én av følgende verdier:
Selv om de aller fleste verdiene er "ja" og "nei", er situasjonen i praksis ikke alltid like enkel. Noen ganger er det virkelig rare og sprø regler som ulike myndigheter har innført, og som gjør det nødvendig å bruke verditypene "med unntak".
Et Entry Requirement er i hovedsak en post som dokumenterer et sett med regler som en aktør har pålagt ett eller flere andre land eller regioner. Aktøren kan være et land, en stat eller til og med en kommune i vår dataarkitektur. Sitata dekker for tiden stort sett data på landsnivå. Vi har imidlertid noen delstats-/provinsialregistre for utvalgte regioner, for eksempel USA og andre.
Alle poster som har en oppføring under feltet opprinnelsesland_divisjon_id
eller opprinnelsesland_region_id
er en som er på henholdsvis statlig eller kommunalt nivå. Hvis du ønsker mer detaljerte data, kan du kontakt oss så kan vi snakke om bruksområdet ditt.
Bruk litt tid på å gjøre deg kjent med datastrukturen i Entry Requirement ved å ta en titt på API-dokumentene våre her.
En litt forvirrende del av datastrukturen er vår bruk av begrepet "opprinnelse." Dette er forvirrende, fordi utviklere ofte tenker på opprinnelse som opprinnelsessted eller avgangssted. Det vi mener med opprinnelse, er imidlertid opprinnelsen til regelen som pålegges andre, det vil si landet eller regionen som har opprettet restriksjonen.
Et annet viktig poeng er hvordan listen over berørte land fungerer. Hvis affected_countries er tom, skal den tolkes som en global regel, dvs. at alle land påvirkes.
Som du kanskje har sett i dokumentasjonen, finnes det en rekke måter å hente data fra API-et på. Nedenfor går vi gjennom noen av de vanligste brukstilfellene.
Det finnes flere måter å gjøre denne typen forespørsler på. Den enkleste versjonen er å bruke reisemål
og avreise
parametere. Disse parameterne godtar ISO 3166-1 alpha-2 koder som inndata.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=IN
Svaret skal inneholde alle krav (på land- og delstatsnivå) som er nødvendige for å forstå hva som gjelder for den reisende som reiser fra avreiselandet til destinasjonslandet.
Sitata har data på delstatsnivå for enkelte regioner. Du vil vite at en bestemt oppføring gjelder en stat hvis opprinnelsesland_inndeling
feltet har en verdi. Du kan også filtrere slik at du bare henter data på delstatsnivå ved hjelp av destinasjon_land_inndeling
parameter. Den forventer en ISO_3166-2 verdi. For eksempel US-TX for Texas, USA.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-AP
Merk at det kan være enklere å søke etter land og deretter filtrere etter delstatsdata for å se om slike data finnes, og bruke dem hvis de finnes.
På samme måte som med land, kan Sitata API returnere resultater mellom to flyplasser. Parametrene avgang_lufthavn
og destinasjon_flyplass
bruk enten ICAO eller IATA koder for å filtrere resultatene. Svaret vil inneholde alle restriksjoner (på land- og delstatsnivå) som er nødvendige for å forstå hva som gjelder for reisende som reiser fra det aktuelle avreiselandet til destinasjonslandet.
GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOM
Svaret skal inneholde alle restriksjoner (på land- og delstatsnivå) som er nødvendige å forstå for den reisende som reiser fra avreiselandet til destinasjonslandet.
Sitata valgte å ikke legge til rette for spørringer etter et bestemt bynavn fordi det kunne føre til konflikter og forvirring. I stedet valgte vi å legge til rette for at API-et vårt kan spørres etter bredde- og lengdegradskoordinater, noe som ikke gir noen tvetydighet i resultatsettet vårt. Parameterne er avgang_lat
, avgang_lng
, destinasjon_lat
, og destinasjon_lng
.
GET https://www.sitata.com/api/v2/entry_requirements?departure_lat=48.13743&departure_lng=11.57549&destination_lat=19.0760&destination_lng=72.8777
Hvis du omgjør byene dine til steder og spør basert på koordinater, vil API-et vårt svare med alle restriksjoner (på land- og delstatsnivå) som er nødvendige for å forstå at den reisende reiser fra avreiselandet til destinasjonslandet.
For noen typer oppføringskrav kan det finnes ekstra tilknyttede data i et metadatatypefelt som heter Ekstrautstyr
. Dette feltet er en nøkkel/verdi-kartlegging av ulike ekstra informasjonsbiter for et bestemt krav.
Denne dataregistreringen faller inn under oppføringskravet type 5. I denne oppføringen er Ekstrautstyr
mappingen vil inneholde et felt som heter karantene_dager
som vil inneholde et heltall for antall dager karantene som er pålagt.
Denne dataregistreringen faller inn under oppføringskravet type 8. I denne oppføringen er Ekstrautstyr
mappingen vil inneholde et felt som heter entry_hours
som vil inneholde et heltall for antall timer som en negativ covid-test er tillatt før innreise.
Vi tror vi har et svært robust verktøy som sannsynligvis vil dekke alle dine behov for å hjelpe de reisende med å forstå hva de sannsynligvis vil møte på veien. Hvis du har et spesielt bruksområde som vi ikke dekker, kan du kontakte oss, vennligst gi oss beskjed!
Dette innlegget er en del av en serie i to deler som forklarer hvordan du kan samhandle med Sitata API for informasjon om innreisekrav og reisebegrensninger. Så langt har vi snakket om innreisekrav, som beskriver de harde ja/nei-kravene som er nødvendige for å reise inn i et land eller en region, men vi har heller ikke snakket om hva som skjer inne i landet. Det er én ting å vite at man kan reise inn i et land, men det er en annen ting å vite om det er mulig å bevege seg rundt i landet, besøke strendene eller om det er portforbud.
Følg med på det andre innlegget som vil gå i dybden på datasettet vårt om reisebegrensninger. Tips - det er nesten identisk, så du kan alltid ta en titt på vår API-dokumentasjon i mellomtiden.