Mange af jer ved det måske ikke, men Sitatas tidlige fundament blev bygget til tidlig sygdomsopsporing. Faktisk har vores grundlægger en TedX-talk fra 2016, der handler om Hvorfor vi skal 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 flere dage før Verdenssundhedsorganisationen!
Under det 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 af regler og bestemmelser for, hvordan man skulle kontrollere spredningen. Det ville uundgåeligt skabe ravage i den globale rejseaktivitet og være en stor kilde til forvirring for dem, der stadig ønskede 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, der skabte en dedikeret API og overvågningstjeneste til ændringerne i rejserestriktioner og adgangskrav som følge af COVID-19. Med et avanceret softwaresystem til registrering af hændelser og et dedikeret team af analytikere havde vi allerede alle de rigtige værktøjer og processer på plads til at gøre det.
Siden lanceringen af denne nye tjeneste har en række organisationer udnyttet dataene til fordel 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, der forklarer, hvordan man bruger API'en til en række forskellige formål. Jeg håber, at disse forklaringer hjælper dig med at få dine egne initiativer i gang.
De første spørgsmål, en rejsende stiller, er uden tvivl "kan jeg rejse dertil?" og "vil jeg blive sat i karantæne", så det er et godt sted at starte. Vi skabte datasættet Entry Requirements for at besvare de svære "ja/nej"-spørgsmål om indrejse i et land eller en region.
I skrivende stund omfattede dette datasæt følgende 10 forskellige kategorier:
Hver kategori kan have en af følgende værdier:
Mens langt de fleste værdier er "ja" og "nej", er situationen i praksis ikke altid så ligetil. Nogle gange er der virkelig mærkelige og skøre regler, som forskellige regeringer har indført, og som nødvendiggør værdityperne "med undtagelser".
Et adgangskrav er i bund og grund en post, der dokumenterer et sæt regler, som en aktør har pålagt et eller flere andre lande eller regioner. Aktøren kan være et land, en stat eller endda en kommune i vores dataarkitektur. I det store og hele dækker Sitata data på landeniveau i øjeblikket. Vi har dog nogle statslige/provinsielle optegnelser for udvalgte regioner som USA og andre.
Enhver post, der har en post under feltet origin_country_division_id eller oprindelse_land_region_id er en, der enten er på statsligt eller kommunalt niveau. Hvis du gerne vil have mere detaljerede data, bedes du kontakt os og vi kan tale om din use case.
Brug lidt tid på at gøre dig bekendt med Entry Requirement-datastrukturen ved at ved at kigge på vores API-dokumenter her.
En lidt forvirrende del af datastrukturen er vores brug af begrebet "Oprindelse." Det er forvirrende, fordi udviklere ofte tænker på oprindelse som oprindelsessted eller afgangssted. 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 tom, skal den fortolkes som en global regel, dvs. at alle lande er berørt.
Som du måske har set i dokumentationen, er der en række måder at hente data fra API'en på. Nedenfor gennemgår vi nogle af de mest almindelige anvendelsesmuligheder.
Der er et par 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=INSvaret vil omfatte alle krav (på lande- og statsniveau), der er nødvendige at forstå for den rejsende, der afgår fra afgangslandet og rejser til destinationslandet.
Sitata har data på statsniveau for visse regioner. Du vil vide, at en bestemt post er for en stat, hvis oprindelse_land_inddeling 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. For eksempel US-TX for Texas, USA.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-APBemærk, at det kan være enklere at forespørge efter land og derefter filtrere efter statsdata for at se, om sådanne data findes, og bruge dem, hvis de findes.
Ligesom med lande kan Sitata API'en returnere resultater mellem to lufthavne. Parametrene afgang_lufthavn og destination_airport Brug enten ICAO eller IATA koder til at filtrere resultaterne. Svaret vil omfatte alle restriktioner (på lande- og statsniveau), der er nødvendige for at forstå den rejsende, der afgår fra det tilsvarende afgangsland og rejser til destinationslandet.
GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOMSvaret vil omfatte alle restriktioner (på lande- og statsniveau), der er nødvendige at forstå for den rejsende, der rejser fra afgangslandet og til destinationslandet.
Sitata valgte ikke at imødekomme forespørgsler efter et bestemt bynavn, fordi det kunne resultere i konflikter og forvirring. I stedet valgte vi at gøre det muligt at forespørge vores API efter bredde- og længdegradskoordinater, hvilket ikke giver nogen tvetydighed i vores resultatsæt. Parametrene er afgang_lat, afgang_lng, destination_latog 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.8777Hvis du omdanner dine byer til steder 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å den rejsende, der rejser fra afgangslandet og til destinationslandet.
For nogle typer adgangskrav kan der være ekstra tilknyttede data i et felt af metadatatypen kaldet Ekstramateriale. Dette felt er en nøgle/værdi-kortlægning af forskellige ekstra informationer til et bestemt krav.
Denne dataindtastning falder ind under adgangskravet type 5. I dette indlæg er Ekstramateriale mappingen vil indeholde et felt kaldet karantænedage som vil indeholde et heltal for antallet af karantænedage.
Denne dataindtastning falder ind under adgangskravet type 8. I dette indlæg er Ekstramateriale mappingen vil indeholde et felt kaldet indgangstimer som vil indeholde et heltal for det antal timer, som en negativ covid-test er tilladt før indrejse.
Vi mener, at vi har en meget robust løsning, 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 en særlig brugssag, som vi ikke dækker, Giv os venligst besked!
Dette indlæg er en del af en serie i to dele, der forklarer, hvordan man interagerer med Sitata API for at få oplysninger om indrejsekrav og rejsebegrænsninger. Indtil videre har vi talt om adgangskrav, 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. En ting er at vide, hvordan man rejser ind i et land, noget andet er 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 dykker ned i vores datasæt om rejsebegrænsninger. Hint - det er næsten identisk, så du kan altid kigge på vores API-dokumentation i mellemtiden.
English 
Español 
Français 
Italiano 
Deutsch 
Magyar 
Română 
العربية 
Polski 
Português 
Nederlands 
Svenska 
Suomi 
Norsk bokmål 
Dansk