Hvordan bruke Sitatas API-er for å fastslå reiserestriksjoner for reisende

Mange av dere vet kanskje ikke dette, men Sitatas tidlige fundament ble bygget for tidlig sykdomsdeteksjon. Vår gründer har faktisk et TedX-foredrag fra 2016 som handler om hvorfor vi må advare reisende for å bidra til å forhindre spredning av sykdom. Det bør derfor ikke komme som noen overraskelse at vi oppdaget COVID-19 da det ble rapportert som en uvanlig gruppe av lungebetennelsestilfeller tidlig i desember 2019. Innen 2. januar 2020 hadde vårt helseteam vurdert at vi burde sende ut vår første advarsel til våre reisende og forretningspartnere. Dette var dager før selv Verdens helseorganisasjon!

Under den uunngåelige etterspillet fikk vi en åpenbaring. Sykdommen spredde seg så raskt at det var klart for oss at den globale responsen i beste fall ville bli kaotisk. Hvert land ville innføre sine egne sett med forskrifter og regler for hvordan man skulle kontrollere spredningen. Dette ville uunngåelig skape kaos for den globale reisevirksomheten og være en stor kilde til forvirring for de som fortsatt ønsket å reise. Vi hadde rett, og vi bestemte oss for å gjøre noe med det. Sitata var et av de første selskapene i verden som laget et dedikert API og overvåkningstjeneste for endringer 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 det.

Siden vi lanserte 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 bli kunngjort snart! For å hjelpe flere reiserettede organisasjoner med å dra nytte av dette tilbudet, har vi nedenfor skrevet i detalj om en rekke eksempler for å forklare hvordan man bruker API-et til ulike bruksområder. Jeg håper disse forklaringene hjelper deg med å få dine egne initiativer i gang.

Innreisekrav

Utvilsomt er de første spørsmålene en reisende stiller “kan jeg dra dit?” og “må jeg i karantene?”, så dette er et godt sted å starte. Vi opprettet datasettet for Innreisekrav for å svare på de klare “ja/nei”-spørsmålene om å reise inn i et land eller en region.

På tidspunktet for skriving inkluderte dette datasettet følgende 10 distinkte kategorier:

• Kan en innbygger reise inn i landet?
• Kan en utlending reise inn i landet?
• Er gjennomreise gjennom landet tillatt?
• Kreves test ved ankomst (sykdomsutbrudd)?
• Godtas testattest (sykdomsutbrudd)?
• Kreves karantene ved ankomst (sykdomsutbrudd)? Kreves vaksinasjon?
• Kreves forsikring?
• Kreves testattest?
• Kreves innreiseskjema? (helse eller annet)

Hver kategori kan ha en av følgende verdier:

• Ja
• Ja, med unntak
• Nei
• Nei, med unntak

Mens størstedelen av verdiene er “ja” og “nei”, er situasjonen på bakken ikke alltid så enkel. Noen ganger er det virkelig merkelige og sprø regler som ulike myndigheter har innført, noe som nødvendiggjør verditypene “med unntak”.

Et Innreisekrav er i bunn og grunn en post som dokumenterer et sett med regler pålagt av en aktør mot 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. I stor grad dekker Sitata for tiden data på landsnivå. Vi har imidlertid noen poster på delstats-/provinsnivå for utvalgte regioner som USA og andre.

Enhver post som har en oppføring i feltet **origin_country_division_id** eller **origin_country_region_id** er enten på delstats- eller kommunenivå, henholdsvis. Hvis du ønsker mer detaljerte data tilgjengelig, kan du kontakte oss så kan vi diskutere ditt bruksområde.

Ta deg tid til å bli kjent med datastrukturen for Innreisekrav ved å se på vår API-dokumentasjon her.

Et litt forvirrende aspekt ved datastrukturen er vår bruk av begrepet “origin”. Dette er forvirrende fordi utviklere ofte tenker på “origin” som opprinnelsesstedet eller avreisestedet. Det vi faktisk mener med “origin” er imidlertid opprinnelsen til regelen som pålegges andre, dvs. landet eller regionen som har innført restriksjonen.

Et annet viktig poeng å merke seg er hvordan listen vår over berørte land fungerer. Hvis affected_countries er tom, skal det tolkes som en global regel, dvs. alle land er berørt.

Noen få eksempler

Som du kanskje har sett fra dokumentasjonen, er det flere måter å hente data fra API-et på. Nedenfor går vi gjennom noen av de mer vanlige bruksområdene.

Hvordan henter jeg kravene mellom to land?

Det er et par måter å gjøre denne typen forespørsel på. Den enkleste versjonen er å bruke parameterne **destination** og **departure**. Disse parameterne aksepterer ISO 3166-1 alpha-2-koder som input.

GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=IN

Responsen vil inkludere alle krav (på lands- og delstatsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Hva hvis jeg vil ha data på delstatsnivå?

Sitata har data på delstatsnivå for visse regioner. Du vil vite at en bestemt oppføring gjelder for en delstat hvis feltet origin_country_division har en verdi. Du kan også filtrere for kun å hente data på delstatsnivå ved å bruke parameteren **destination_country_division**. 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 å spørre etter land og deretter filtrere etter delstatsdata for å se om slike data finnes, og bruke dem hvis de finnes.

Hvordan henter jeg kravene mellom to flyplasser?

Akkurat som med land, kan Sitatas API returnere resultater mellom to flyplasser. Parameterne departure_airport og destination_airport bruker enten ICAO- eller IATA-koder for å filtrere resultatene. Responsen vil inkludere alle restriksjoner (på lands- og delstatsnivå) som er nødvendige å forstå for reisenden som reiser fra det tilsvarende avreiselandet til destinasjonslandet.

GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOM

Responsen vil inkludere alle restriksjoner (på lands- og delstatsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Hva hvis jeg bare har informasjon om by?

Sitata valgte å ikke tilrettelegge for spørringer ved et spesifikt bynavn fordi det kunne føre til konflikter og forvirring. I stedet valgte vi å tilrettelegge for å spørre API-et vårt ved hjelp av bredde- og lengdegradskoordinater, som ikke gir noen tvetydighet i resultatsettet vårt. Parameterne er departure_lat, departure_lng, destination_lat og destination_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 finner lokasjonene til byene dine og spørrer basert på koordinater, vil API-et vårt svare med alle restriksjoner (på lands- og delstatsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Ekstra data

For noen typer Innreisekrav kan det være ekstra tilknyttede data i et metadatafelt av typen extras. Dette feltet er en nøkkel/verdi-kartlegging av ulike ekstra informasjonsbiter for et spesifikt krav.

Hva er antall dager med karantene?

Denne dataoppføringen faller under innreisekrav type 5. I denne oppføringen vil **extras**-kartleggingen inneholde et felt kalt quarantine_days som vil inneholde et heltall for antall pålagte karantenedøgn.

Hvor mange timer før innreise må en negativ covid-test være tatt?

Denne dataoppføringen faller under innreisekrav type 8. I denne oppføringen vil **extras**-kartleggingen inneholde et felt kalt entry_hours som vil inneholde et heltall for antall timer en negativ covid-test er gyldig før innreise.

Gi oss beskjed

Vi tror vi har en svært robust løsning som sannsynligvis vil dekke alle dine behov for å hjelpe dine reisende med å forstå hva de sannsynligvis vil møte på veien. Hvis du har et spesifikt bruksområde som vi ikke dekker, gi oss beskjed!

Vent… det er mer!

Denne oppføringen er del av en to-delt serie som forklarer hvordan man samhandler med Sitatas API for Innreisekrav og informasjon om reiserestriksjoner. Så langt har vi snakket om Innreisekrav som skisserer de klare ja/nei-kravene som er nødvendige for å reise inn i et land eller en region, men vi har ikke snakket om hva som skjer innenfor landet heller. Det er én ting å vite om å reise inn i et land, det er en annen å forstå om det er mulig å bevege seg rundt i landet eller besøke strendene, eller om det er portforbud.

Følg med på det andre innlegget som vil dykke dypt inn i vårt datasett for Reiserestriksjoner. Hint – det er nesten identisk, så du kan alltid ta en titt på vår API-dokumentasjon i mellomtiden.