Mange af jer ved det måske ikke, men Sitatas tidlige fundamenter blev bygget med henblik på tidlig sygdomsopsporing. Faktisk har vores grundlægger en TedX talk fra 2016, der handler om hvorfor vi er nødt til at advare rejsende for at forhindre spredning af sygdomme. Det bør derfor ikke komme som nogen overraskelse, at vi tog COVID-19 op, da det blev rapporteret som en usædvanlig klynge af tilfælde af lungebetændelse i begyndelsen af december 2019. Den 2. januar 2020 besluttede vores sundhedsteam, at vi skulle udstede vores første advarsel til vores rejsende og forretningspartnere. Det var dage før Verdenssundhedsorganisationen!

Under de uundgåelige nedfald fik vi en åbenbaring. Sygdommen spredte sig så hurtigt, at det stod klart for os, at den globale reaktion i bedste fald ville blive kaotisk. Hvert land ville vedtage sit eget sæt regler og bestemmelser for, hvordan man skulle kontrollere spredningen. Dette ville uundgåeligt skabe ravage i den globale rejseaktivitet og være en stor kilde til forvirring for dem, der stadig ønsker at rejse. Vi havde ret, og vi satte os for at gøre noget ved det. Sitata var en af de første virksomheder i verden til at skabe et dedikeret API og en overvågningstjeneste for ændringerne i rejserestriktioner og indrejsekrav som følge af COVID-19. Med et avanceret softwaresystem til hændelsesdetektion og et dedikeret team af analytikere havde vi allerede alle de rigtige værktøjer og processer på plads.

Siden lanceringen af denne nye tjeneste har vi haft en række organisationer, der har benyttet sig af dataene til gavn for deres egne kunder, herunder Eddy Travels, Flight Centre og Etihad Airways, og der er flere, der snart vil blive annonceret! For at hjælpe flere rejsefokuserede organisationer med at drage fordel af dette tilbud har vi nedenfor skrevet en række eksempler i detaljer for at forklare, hvordan API'et kan bruges til en række forskellige brugssituationer. Jeg håber, at disse forklaringer hjælper dig med at få dine egne initiativer i gang.

Adgangskrav

De første spørgsmål, som rejsende stiller, er uden tvivl "kan jeg rejse dertil?" og "vil jeg blive sat i karantæne", så dette er et godt sted at starte. Vi har oprettet datasættet om indrejsekrav for at besvare de svære "ja/nej"-spørgsmål vedrørende indrejse i et land eller en region.

I skrivende stund omfattede dette datasæt følgende 10 forskellige kategorier:

• Kan en bosiddende person rejse ind i landet?
• Kan en udlænding rejse ind i landet?
• Er transit gennem landet tilladt?
• Er det nødvendigt med en test ved ankomsten (sygdomsudbrud)?
• Er et testcertifikat tilladt (sygdomsudbrud)?
• Er der krav om karantæne ved ankomsten (sygdomsudbrud)? Er der krav om vaccination?
• Er forsikring påkrævet?
• Er testcertifikat påkrævet?
• Er der behov for en formular (sundhed eller andet)?

Hver kategori kan have en af følgende værdier:

• Ja
• Ja, med visse undtagelser
• Nej
• Nej, med visse undtagelser

Selv om langt de fleste værdier er "ja" og "nej", er situationen på stedet ikke altid ligetil. Nogle gange er der virkelig mærkelige og skøre regler, som forskellige regeringer har indført, og som gør det nødvendigt at anvende værdityperne "med undtagelser".

Et indrejsekrav er i bund og grund en registrering, der dokumenterer et sæt regler, som en aktør har indført over for et eller flere andre lande eller regioner. Aktøren kan være et land, en stat eller endog en kommune i vores dataarkitektur. I det store og hele dækker Sitata i øjeblikket data på landsplan. Vi har dog nogle stat/provinsregistreringer for udvalgte regioner såsom USA og andre.

Enhver post, der har en post under feltet origin_country_division_id eller origin_country_region_id er enten på statsligt eller kommunalt niveau. Hvis du ønsker mere detaljerede data, bedes du Kontakt os og vi kan tale om din brugssituation.

Brug lidt tid på at gøre dig bekendt med datastrukturen for adgangskrav ved at ved at kigge på vores API-dokumentation her.

En lidt forvirrende del af datastrukturen er vores brug af udtrykket "oprindelse." Dette er forvirrende, fordi udviklere ofte tænker på oprindelse som værende oprindelsesstedet eller afgangsstedet. Men det, vi mener med oprindelse, er faktisk oprindelsen af den regel, der pålægges andre, dvs. det land eller den region, der har skabt begrænsningen.

Et andet vigtigt punkt at bemærke er, hvordan vores liste over berørte lande fungerer. Hvis affected_countries er tomt, skal det fortolkes som en global regel, dvs. at alle lande er berørt.

Et par eksempler

Som du måske har set i dokumentationen, er der flere måder at hente data fra API'et på. Nedenfor gennemgår vi et par af de mest almindelige anvendelsestilfælde.

Hvordan kan jeg hente kravene mellem to lande?

Der er et par forskellige måder at gøre denne type anmodning på. Den enkleste version er at bruge destination og afgang parametre. Disse parametre accepterer ISO 3166-1 alpha-2 koder som input.

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

Svaret vil omfatte alle de krav (på lande- og statsniveau), der er nødvendige for at forstå for den rejsende, der rejser fra afrejselandet og til bestemmelseslandet.

Hvad hvis jeg vil have data på statsniveau?

Sitata har data på statsniveau for visse regioner. Du ved, at en bestemt post er for en stat, hvis origin_country_division feltet har en værdi. Du kan også filtrere for kun at hente data på statsniveau ved hjælp af destination_country_division parameter. Den forventer en ISO_3166-2 værdi. F.eks. US-TX for Texas, USA.

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

Bemærk, at det kan være enklere at søge efter land og derefter filtrere efter statsdata for at se, om sådanne data findes, og bruge dem, hvis de findes.

Hvordan henter jeg kravene mellem to lufthavne?

Ligesom med lande kan Sitata API'et returnere resultater mellem to lufthavne. Parametrene departure_airport og destination_airport bruge enten ICAO eller IATA koder til at filtrere resultaterne. Svaret vil indeholde alle de restriktioner (på lands- og statsniveau), der er nødvendige for at forstå for den rejsende, der rejser fra det tilsvarende afgangsland og til destinationslandet.

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

Svaret vil omfatte alle de restriktioner (på lands- og statsniveau), der er nødvendige at forstå for den rejsende, der rejser fra afrejselandet og til bestemmelseslandet.

Hvad hvis jeg kun har oplysninger om en by?

Sitata har valgt ikke at imødekomme forespørgsler efter et bestemt bynavn, da det kan give anledning til konflikter og forvirring. I stedet valgte vi at tillade forespørgsler på vores API ved hjælp af koordinater for bredde- og længdegrader, hvilket ikke giver nogen tvetydighed i vores resultatmængde. Parametrene er afgang_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 opløser dine byer til lokationer og forespørger baseret på koordinater, vil vores API svare med alle de begrænsninger (på lande- og statsniveau), der er nødvendige for at forstå, at den rejsende rejser fra afgangslandet og til destinationslandet.

Ekstra data

For nogle typer af adgangskrav kan der være ekstra tilknyttede data i et felt af metadatatypen kaldet ekstraudstyr. Dette felt er en nøgle/værdimapping af forskellige ekstra oplysninger for et bestemt krav.

Hvor mange dage er karantænen?

Denne dataindtastning falder ind under indtastningskravet type 5. I denne post er ekstraudstyr vil indeholde et felt kaldet karantæne_dage som indeholder et heltal for antallet af karantænedage, der er pålagt.

Hvor mange timer skal der gå før indrejse for at få en negativ covid-test?

Denne dataindtastning falder ind under indtastningskravet type 8. I denne post er ekstraudstyr vil indeholde et felt kaldet entry_hours som vil indeholde et heltal for det antal timer, som en negativ covid-test må have været tilladt før indførsel.

Lad os vide det

Vi mener, at vi har et meget robust program, der sandsynligvis vil opfylde alle dine behov for at hjælpe dine rejsende med at forstå, hvad de sandsynligvis vil møde undervejs. Hvis du har et særligt brugsscenarie, som vi ikke tager højde for, så lad os vide det!

Vent... der er mere!

Dette indlæg er en del af en todelt serie, der forklarer, hvordan du interagerer med Sitata API'et for oplysninger om indrejsekrav og rejserestriktioner. Indtil videre har vi talt om indrejsekrav, som beskriver de hårde ja/nej-krav, der er nødvendige for at komme ind i et land eller en region, men vi har heller ikke talt om, hvad der sker inde i landet. Det er én ting at vide om at rejse ind i et land, det er en anden ting at forstå, om det er muligt at bevæge sig rundt i landet eller besøge strandene, eller om der er et obligatorisk udgangsforbud.

Hold øje med det andet indlæg, hvor vi vil dykke ned i vores datasæt om rejsebegrænsninger. Hint - det er næsten identisk, så du kan altid tage et kig på vores API-dokumentation i mellemtiden.

Følg og synes godt om os: