Velen van jullie weten dit misschien niet, maar de vroege fundamenten van Sitata werden gebouwd voor vroege ziektedetectie. In feite heeft onze oprichter een TedX-talk uit 2016 helemaal over waarom we reizigers moeten waarschuwen om de verspreiding van ziekten te helpen voorkomen. Het mag dan ook geen verrassing zijn 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 een onze eerste waarschuwing aan onze reizigers en zakenpartners. Dit was zelfs dagen voor de Wereldgezondheidsorganisatie!

Tijdens de onvermijdelijke fall-out hadden we een openbaring. De ziekte verspreidde zich zo snel dat het ons duidelijk was dat de wereldwijde reactie in het beste geval chaotisch zou zijn. Elk land zou zijn eigen regels opstellen om de verspreiding te beheersen. Dit zou onvermijdelijk een ravage betekenen voor het wereldwijde reisverkeer en een enorme bron van verwarring zijn voor degenen die nog willen reizen. We hadden gelijk en we begonnen er iets aan te doen. Sitata was een van de eerste bedrijven ter wereld die een speciale API en monitoringdienst creëerde voor de veranderingen in reisbeperkingen en toegangsvereisten als gevolg van COVID-19. Met een geavanceerd softwaresysteem voor eventdetectie en een toegewijd team van analisten hadden we al de juiste tools en processen om dit te doen.

Sinds de lancering van deze nieuwe dienst hebben diverse organisaties gebruik gemaakt van de gegevens ten behoeve van hun eigen klanten, waaronder Eddy Travels, Flight Centre en Etihad Airways; en er zullen er binnenkort nog meer worden aangekondigd! Om meer reisgerichte organisaties te helpen profiteren van dit aanbod, hebben we hieronder in detail een aantal voorbeelden geschreven om uit te leggen hoe de API te gebruiken voor een verscheidenheid aan use cases. Ik hoop dat deze uitleg u helpt uw eigen initiatieven van de grond te krijgen.

Toelatingseisen

Zonder twijfel zijn de eerste vragen die een reiziger stelt "mag ik erheen?" en "kom ik in quarantaine", dus dit is een goede plek om te beginnen. Wij hebben de gegevensreeks Entry Requirements gecreëerd om de moeilijke "ja/nee" vragen over het binnenkomen van een land of regio te beantwoorden.

Op het moment van schrijven omvatte deze dataset de volgende 10 verschillende categorieën:

• Kan een ingezetene het land binnenkomen?
• Kan een buitenlander het land binnenkomen?
• Is doorvoer door het land toegestaan?
• Is een test bij aankomst vereist (ziekte-uitbraak)?
• Is een testcertificaat toegestaan (ziekte-uitbraak)?
• Is quarantaine vereist bij aankomst (ziekte-uitbraak)? Is een vaccinatie vereist?
• Verzekering nodig?
• Testcertificaat nodig?
• Inschrijvingsformulier vereist? (gezondheid of andere)

Elke categorie kan een van de volgende waarden hebben:

• Ja
• Ja, met uitzonderingen
• Geen
• Nee, met uitzonderingen

Hoewel de overgrote meerderheid van de waarden "ja" en "nee" zijn, is de situatie in de praktijk niet altijd zo eenvoudig. Soms zijn er echt vreemde en gekke regels die verschillende regeringen hebben ingevoerd, waardoor de waarden "met uitzonderingen" moeten zijn.

Een Entry Requirement is in wezen een record met een reeks regels die door een actor aan een of meer andere landen of regio's worden opgelegd. De actor kan een land, staat of zelfs gemeente zijn in onze gegevensarchitectuur. Over het algemeen bestrijkt Sitata momenteel gegevens op landniveau. We hebben echter enkele 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 herkomst_land_regio_id is er een op respectievelijk staats- of gemeenteniveau. Als u meer gedetailleerde gegevens beschikbaar wilt hebben, kunt u contact met ons opnemen en we kunnen praten over uw gebruik.

Neem even de tijd om u vertrouwd te maken met de gegevensstructuur van de Entry Requirement door en bekijk onze API-documenten hier.

Een enigszins verwarrend onderdeel van de gegevensstructuur is ons gebruik van de term "oorsprong." Dit is verwarrend omdat ontwikkelaars bij oorsprong vaak denken aan de plaats van oorsprong of de plaats van vertrek. Wat wij 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 dit worden geïnterpreteerd als een globale regel, d.w.z. dat alle landen worden beïnvloed.

Enkele voorbeelden

Zoals u wellicht in de documentatie hebt gezien, zijn er een aantal manieren om gegevens uit de API te halen. Hieronder overlopen we enkele van de meest voorkomende gebruiksmogelijkheden.

Hoe haal ik de vereisten tussen twee landen op?

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=IN

Het antwoord zal alle vereisten (op land- en staatsniveau) omvatten die nodig zijn om de reiziger die uit het land van vertrek vertrekt en naar het land van bestemming reist, te begrijpen.

Wat als ik gegevens op staatsniveau wil?

Sitata heeft gegevens op staatsniveau voor bepaalde regio's. U weet dat een bepaalde vermelding betrekking heeft op een staat als de herkomst_land_afdeling veld een waarde heeft. U kunt ook filteren om alleen gegevens op staatsniveau op te halen met behulp van 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-AP

Merk op dat het eenvoudiger kan zijn om te zoeken op land en dan te filteren op staatsgegevens om te zien of zulke gegevens bestaan, en ze te gebruiken als ze bestaan.

Hoe haal ik de vereisten tussen twee luchthavens op?

Net als bij landen kan de Sitata API resultaten opleveren tussen twee luchthavens. De parameters vertrekluchthaven en bestemming_luchthaven 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 naar het land van bestemming reist.

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

Het antwoord zal alle beperkingen (op land- en staatsniveau) bevatten die nodig zijn om de reiziger die uit het land van vertrek vertrekt en naar het land van bestemming reist, te begrijpen.

Wat als ik alleen stadsinformatie heb?

Sitata heeft ervoor gekozen geen zoekopdrachten op basis van een bepaalde plaatsnaam toe te staan, omdat dit tot conflicten en verwarring kan leiden. In plaats daarvan hebben wij ervoor gekozen onze API te bevragen op basis van lengte- en breedtecoördinaten, wat geen dubbelzinnigheid in onze resultaten oplevert. De parameters zijn vertrek_lat, vertrek_lng, bestemming_laten 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.8777

Als u uw steden omzet in locaties en een query uitvoert op basis van coördinaten, zal onze API antwoorden met alle beperkingen (land en staat) die nodig zijn om de reiziger die vertrekt uit het land van vertrek en reist naar het land van bestemming te begrijpen.

Extra gegevens

Voor sommige types Entry Requirements kunnen er extra geassocieerde gegevens zijn in een veld van het type metadata genaamd extra's. Dit veld is een sleutel/waarde-mapping van diverse extra stukjes informatie voor een bepaalde eis.

Wat is het aantal dagen quarantaine?

Deze gegevensinvoer valt onder de invoereis type 5. In deze vermelding worden de extra's mapping zal een veld bevatten met de naam quarantaine_dagen dat een geheel getal zal bevatten voor het aantal opgelegde quarantainedagen.

Wat is het aantal uren voor een negatieve covid test?

Deze gegevensinvoer valt onder de invoereis type 8. In deze vermelding worden de extra's mapping zal een veld bevatten met de naam ingangsuren dat een geheel getal zal bevatten voor het aantal uren dat een negatieve covid-test is toegestaan vóór binnenkomst.

Laat het ons weten.

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 bepaalde toepassing heeft die we niet behandelen, laat het ons weten!

Wacht... er is meer!

Dit artikel maakt deel uit van een tweedelige serie die uitlegt hoe u 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 eisen schetsen die nodig zijn om een land of regio binnen te komen, maar we hebben het ook niet gehad over wat er in het land gebeurt. Het is één ding om te weten of je een land binnen mag, het is iets anders om te weten of het mogelijk is je in het land te verplaatsen of de stranden te bezoeken of dat er een avondklok geldt.

Blijf kijken voor het tweede bericht waarin we dieper ingaan op onze Travel Restriction data set. Hint - het is bijna identiek, dus u kunt altijd een kijkje nemen op onze API-documentatie in de tussentijd.

Volg en like ons: