Velen van jullie weten dit misschien niet, maar de vroege fundamenten van Sitata zijn gebouwd voor vroege ziektedetectie. Onze oprichter heeft zelfs een TedX-talk uit 2016 over waarom we reizigers moeten waarschuwen om de verspreiding van ziekten te helpen voorkomen. Het is dan ook geen verrassing dat we COVID-19 hebben opgepikt toen het begin december 2019 werd gemeld als een ongewoon cluster van gevallen van longontsteking. Op 2 januari 2020 besloot ons gezondheidsteam dat we het volgende moesten uitgeven onze eerste waarschuwing aan onze reizigers en zakenpartners. Dit was zelfs dagen voor de Wereldgezondheidsorganisatie!
Tijdens de onvermijdelijke fall-out kregen we een openbaring. De ziekte verspreidde zich zo snel dat het voor ons duidelijk was dat de wereldwijde reactie in het beste geval chaotisch zou zijn. Elk land zou zijn eigen regels en voorschriften uitvaardigen om de verspreiding onder controle te houden. Dit zou onvermijdelijk wereldwijd reizen in de war sturen en een enorme bron van verwarring zijn voor degenen die nog steeds willen reizen. We hadden gelijk en we wilden er iets aan doen. Sitata was een van de eerste bedrijven ter wereld die een speciale API en monitoringdienst creëerde voor de wijzigingen in reisbeperkingen en toegangsvereisten als gevolg van COVID-19. Met een geavanceerd softwaresysteem voor eventdetectie en een toegewijd team van analisten beschikten we al over alle juiste tools en processen om dit te doen.
Sinds de lancering van deze nieuwe service hebben verschillende organisaties gebruik gemaakt van de gegevens ten behoeve van hun eigen klanten, waaronder Eddy Travels, Flight Centre en Etihad Airways; en er worden er binnenkort nog meer aangekondigd! Om meer organisaties die gericht zijn op reizen te helpen profiteren van dit aanbod, hebben we hieronder een aantal voorbeelden in detail beschreven om uit te leggen hoe je de API kunt gebruiken voor verschillende gebruikssituaties. Ik hoop dat deze uitleg je helpt om je eigen initiatieven van de grond te krijgen.
Zonder twijfel zijn de eerste vragen die een reiziger stelt "mag ik erheen?" en "kom ik in quarantaine" en dus is dit een goede plek om te beginnen. We hebben de Entry Requirements-dataset gemaakt om de moeilijke ja/nee-vragen over het binnenkomen van een land of regio te beantwoorden.
Op het moment van schrijven bevatte deze dataset de volgende 10 verschillende categorieën:
Elke categorie kan een van de volgende waarden hebben:
Hoewel de overgrote meerderheid van de waarden "ja" en "nee" zijn, is de situatie op de grond niet altijd zo eenvoudig. Soms zijn er echt rare en gekke regels die verschillende overheden hebben ingevoerd, waardoor de waarden "met uitzonderingen" moeten zijn.
Een Entry Requirement is in wezen een record dat een reeks regels documenteert die een actor oplegt aan een of meerdere andere landen of regio's. De actor kan een land, staat of zelfs gemeente zijn in onze gegevensarchitectuur. De actor kan een land, staat of zelfs gemeente zijn in onze gegevensarchitectuur. Over het algemeen bevat Sitata momenteel gegevens op landniveau. We hebben echter een aantal staat/provinciale records voor bepaalde regio's zoals de Verenigde Staten en andere.
Elk record met een vermelding onder het veld oorsprong_land_afdeling_id of oorsprong_land_regio_id is er een op respectievelijk staatsniveau of gemeenteniveau. Als u meer gedetailleerde gegevens beschikbaar wilt hebben, kunt u contact met ons opnemen en kunnen we praten over jouw use case.
Neem even de tijd om vertrouwd te raken met de gegevensstructuur van Entry Requirement door Bekijk onze API-documenten hier.
Een enigszins verwarrend onderdeel van de gegevensstructuur is ons gebruik van de term "herkomst." Dit is verwarrend omdat ontwikkelaars bij oorsprong vaak denken aan de plaats van herkomst of de plaats van vertrek. Wat we echter bedoelen met oorsprong is eigenlijk de oorsprong van de regel die aan anderen wordt opgelegd, d.w.z. het land of de regio die de beperking heeft gecreëerd.
Een ander belangrijk punt om op te merken is hoe onze lijst met betrokken landen werkt. Als affected_countries leeg is, moet het worden geïnterpreteerd als een globale regel. Dat wil zeggen dat alle landen worden beïnvloed.
Zoals je misschien al in de documentatie hebt gezien, zijn er een aantal manieren om gegevens van de API op te halen. Hieronder zullen we een paar van de meest voorkomende gebruikssituaties bespreken.
Er zijn een paar manieren om dit soort verzoeken te doen. De eenvoudigste versie is om de bestemming en vertrek parameters. Deze parameters accepteren ISO 3166-1 alfa-2 codes als invoer.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=INHet antwoord zal alle vereisten (op land- en staatsniveau) bevatten die nodig zijn om de reiziger die vertrekt uit het land van vertrek en naar het land van bestemming reist, te begrijpen.
Sitata heeft gegevens op staatsniveau voor bepaalde regio's. U weet dat een bepaalde invoer voor een staat is als de oorsprong_land_afdeling veld een waarde heeft. Je kunt ook filteren om alleen gegevens op staatsniveau op te halen met de optie bestemming_land_afdeling parameter. Het verwacht een ISO_3166-2 waarde. Bijvoorbeeld US-TX voor Texas, Verenigde Staten.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-APMerk op dat het misschien eenvoudiger is om een query uit te voeren op land en dan te filteren op staatgegevens om te zien of zulke gegevens bestaan, en ze te gebruiken als ze bestaan.
Net als met landen kan de Sitata API resultaten teruggeven tussen twee luchthavens. De parameters vertrekluchthaven en luchthaven van bestemming gebruik ofwel ICAO of IATA codes om de resultaten te filteren. Het antwoord zal alle beperkingen (land en staat) bevatten die nodig zijn om de reiziger te begrijpen die vertrekt uit het overeenkomstige land van vertrek en reist naar het land van bestemming.
GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOMHet antwoord zal alle beperkingen (op land- en staatsniveau) bevatten die nodig zijn om de reiziger die vertrekt uit het land van vertrek en naar het land van bestemming reist, te begrijpen.
Sitata heeft ervoor gekozen om query's op basis van een bepaalde plaatsnaam niet mogelijk te maken, omdat dit kan leiden tot conflicten en verwarring. In plaats daarvan hebben we ervoor gekozen om onze API te bevragen op lengte- en breedtecoördinaten, wat geen dubbelzinnigheid oplevert in onze resultaten. De parameters zijn vertrek_lat, vertrek_lng, bestemmingen bestemming_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.8777Als je je steden omzet in locaties en zoekopdrachten uitvoert op basis van coördinaten, zal onze API reageren met alle beperkingen (land- en staatsniveau) die nodig zijn om de reiziger te begrijpen die vertrekt uit het land van vertrek en reist naar het land van bestemming.
Voor sommige typen Entry Requirements kunnen er extra geassocieerde gegevens zijn in een veld van het metadatatype genaamd extra's. Dit veld is een sleutel/waarde-toewijzing van verschillende extra stukjes informatie voor een bepaalde vereiste.
Deze gegevensinvoer valt onder de invoereis type 5. In dit item is de extra's mapping bevat een veld met de naam quarantaine_dagen die een geheel getal bevat voor het aantal dagen quarantaine.
Deze gegevensinvoer valt onder de invoereis type 8. In dit item is de extra's mapping bevat een veld met de naam binnenkomst_uren die een geheel getal bevat voor het aantal uren dat een negatieve covid-test is toegestaan voor binnenkomst.
We denken dat we een zeer robuuste oplossing hebben die waarschijnlijk aan al uw behoeften zal voldoen om uw reizigers te helpen begrijpen wat ze onderweg waarschijnlijk zullen tegenkomen. Als u een specifieke toepassing hebt die we niet behandelen, laat het ons weten!
Dit artikel maakt deel uit van een tweedelige serie waarin wordt uitgelegd hoe je kunt communiceren met de Sitata API voor informatie over toegangsvereisten en reisbeperkingen. Tot nu toe hebben we het gehad over Entry Requirements die de harde ja/nee soorten vereisten schetsen die nodig zijn om een land of regio binnen te komen, maar we hebben het ook nog niet gehad over wat er in het land gebeurt. Het is één ding om te weten hoe je een land binnenkomt, het is iets anders om te weten of het mogelijk is om je in het land te verplaatsen, de stranden te bezoeken of dat er een avondklok geldt.
Blijf kijken voor het tweede bericht waarin we dieper ingaan op onze Travel Restriction-dataset. Hint - hij is bijna identiek, dus je kunt altijd een kijkje nemen in onze API-documentatie in de tussentijd.
English 
Español 
Français 
Italiano 
Deutsch 
Magyar 
Română 
العربية 
Polski 
Português 
Nederlands 
Svenska 
Suomi 
Norsk bokmål 
Dansk