Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Dossier

Context

In een uitbreiding van het SDG-verhaal voorziet Europa een oplossing voor informatieuitwisseling betreffende kortetermijnverhuur van accommodaties (Short Term Accommodation Rental services). Deze STR’s zijn plaatsen (units) die worden verhuurd en aangeboden aan het brede publiek om te verblijven, en dit gedurende korte tijd. Hotels, campings, … vallen buiten de scope. De STR’s worden typisch aangeboden op gespecialiseerde platformen (zoals bvb airbnb). Europa wil dat lidstaten voor de informatieuitwisseling gebruik maken van een zgn Single Digital Entry Point (SDEP). Men voorziet één SDEP per land. Dit SDEP is verantwoordelijk voor het vormen van een abstractielaag tussen STR-platformen enerzijds en verantwoordelijke overheden (CA’s, Competent Authorities) anderzijds. In België bestaan er al registers voor het Vlaams gewest, Waals gewest, Brussel, en de Duitstalige gemeenschap. In Vlaanderen neemt Toerisme Vlaanderen een duorol op: zij zijn tegenlijk de bevoegde autoriteit èn zij beheren tevens het register dat registratienummers toekent voor STR’s op het Vlaamse grondgebied.

*** Update 30/4/24: De STR-verordening (Verordening (EU) 2024/1028 van het Europees Parlement en de Raad van 11 april 2024 betreffende het verzamelen en delen van gegevens met betrekking tot diensten voor kortetermijnverhuur van accommodatie en tot wijziging van Verordening (EU) 2018/1724) is intussen gepubliceerd. De tekst is hier terug te vinden in alle EU-talen. De verordening treedt in werking op 19 mei 2024 (20 dagen na publicatie). Vanaf dan is er 2 jaar de tijd voor implementatie, dus:

Note

De deadline voor implementatie van dit project is 19 mei 2026.

HL integratie architectuur

Application Cooperation View.pngImage Removedstrs.pngImage Added

Onder begeleiding van PwC zal een proof of concept ontwikkeld worden voor het SDEP (Zie https://github.com/SEMICeu/STR-AP/tree/main/prototype ). Deze code kan desgewenst hergebruikt worden door de verschillende lidstaten. De werking en de features van het SDEP en mede het integrale systeem worden momenteel nog besproken, maar voorlopig zijn dit de vaststellingen:

  • De host (eigenaar/verhuurder van een STR) registreert zijn STR bij het officiële register van een lidstaat (of regio van een lidstaat). Voor Vlaanderen is dit bvb in handen van Toerisme Vlaanderen. Na registratie ontvangt de host een uniek registratienummer voor dat specifieke STR.

Note

CA’s moeten in staat zijn minstens de attributen beschreven op https://github.com/SEMICeu/STR-AP/blob/main/prototype/3. Testing/Endpoints.md onder User Story 1.2 te bevragen en op te slaan.

  • De host kan zijn STR op verschillende platformen (bvb airbnb) te huur aanbieden (we spreken dan van een “listing” van de STR). Tijdens die procedure biedt het STR-platform tevens de kans om een registratienummer in te vullen voor het STR, indien de host hierover beschikt. Dat laatste is niet altijd het geval: voor accomodaties die zich bevinden buiten een gebied waarbinnen de STR-wetgeving van toepassing is zijn vrijgesteld van de verplichting om een registratienummer te hebben, net als hotels (ook al bevinden zich deze binnen een toepassend gebied). Het is de rol van de CA’s om op frequente basis deze gebieden up to date te houden.

Note

CA’s moeten overweg kunnen met Shapefiles, en de geografisch afgebakende gebieden die onder hun STR-bevoegdheid vallen te definiëren in dergelijke Shapefiles. Ze moeten deze immers opladen en updaten in het SDEP, zodat platformen deze kunnen opvragen en downloaden. Zie ook User Story 3.2 op https://github.com/SEMICeu/STR-AP/blob/main/prototype/3.%20Testing/Endpoints.md.

  • Tijdens het maken van een listing op een platform zal het platform controleren of de STR zich in een gebied bevindt dat onderhevig is aan de STR-wetgeving. Het platform kan al deze gebieden voor een land opvragen bij het SDEP van dat land.Wanneer tijdens de listing géén registratienummer wordt meegegeven zal het STR-platform een

Note

De Endpoints-documentatie strookt hier (nog) niet met de Swagger. Het vermoeden is dat dit opvragen van deze lijst van gebieden zal gebeuren via de /str/area call. In het antwoord staan dan wellicht per AreaID de overeenstemmende ID van de CA samen met de UID van de shapefile. Deze laatste kan dan gedownload worden via /str/area/{areafile-id}. Daarin is de documentatie dus niet helder. Dit moet nog uitgeklaard worden met PwC.

  • Bij de creatie van een listing kan een STR-platform zelf bepalen of er direct een check gebeurt op het eventueel doorgegeven registratienummer. Het platform zal in dat geval de listing doorgeven aan het SDEP, dat op zijn beurt verantwoordelijk is voor het doorsturen van deze data naar de verantwoordelijke CA. De CA kan dan de nodige controles uitvoeren. Opmerking: het is nog onduidelijk of de listing ook zal doorgegeven worden als de STR wél een registratienummer heeftDe host blijft verantwoordelijk voor het doorgeven van het registratienummer bij de creatie van de listing als zijn/haar unit er één toegekend heeft gekregen.

  • Eens om de zoveel tijd (bvb maandelijks) geeft het platform alle activiteitsdata door binnen een bepaald gebied aan het SDEP. Dat laatste geeft deze activiteitsdata verder door aan een collector in de regio. Voor Vlaanderen is Toerisme Vlaanderen niet alleen verantwoordelijk voor het beheer van het register, maar ook voor het invullen van deze collector rol.

  • STR-platformen maken deze alle bovenstaande calls via een API van het SDEP. De beveiliging hiervan gebeurt via OAUTH2 (en dus moeten de STR-platformen die het recht hebben om dit soort calls te maken gekend zijn bij het SDEP.

De afspraken op Europees niveau behandelen het contract en de interfacing van het SDEP richting de platformen, daar dit voor alle Europese lidstaten hetzelfde concept is. Hoe het SDEP achter de schermen communiceert met de verschillende CA’s in een lidstaat moet elke lidstaat voor zichzelf bekijken.

De epics en user stories voor het SDEP zijn te vinden op https://github.com/SEMICeu/STR-AP/blob/main/prototype/3.%20Testing/Endpoints.md.

Transmissie van data naar Eurostat

Initieel leek de collectie van data bij Eurostat (of andere Europese statistieken) ook deel uit te maken van het plaatje. De laatste informatie vertelt dat dit een zaak is van de CA’s per EU-lidstaat, en dat dit geen deel zou uitmaken van het SDEP-verhaal. Dit is nog niet uitgeklaard.

Informatiemodel

Het algemene informatiemodel rond dit project is terug te vinden op https://semiceu.github.io/STR-AP/.

API contract

Op dit moment is de consensus van de API interface van het SDEP een REST API (JSON-formaat) zal zijn, met autorisatie via OAuth 2.De link naar de Swagger zal nog voorzien worden. De technische documentatie is te vinden op 0.

technical_prototype/EU_STR_connection.md.

Er zijn momenteel 4 SDEP-endpoints gedefinieerd, bedoeld voor gebruik door de STR-platformen:

GET

/ping

Healthcheck voor het SDEP

POST

/str/activity-data

Doorgeven van activiteitsdata

POST

/str/listings

Doorgeven van een nieuwe listing

GET

/str/area

Ophalen van een lijst van area-bestanden

GET

/str/area/<areafile-id>

Downloaden van een specifiek area-bestand

Het SDEP voorziet ook een endpoint voor healthchecks: GET /ping

De PoC-code van het SDEP door PwC bevat nog andere endpoints, maar die zijn te gebruiken door de CA’s, en maken daarom niet strikt deel uit van het Europese contract.

Panel
panelIconId27a1
panelIcon:arrow_right:
panelIconText➡️
bgColor#DEEBFF

Er kan alvast bekeken worden met de CA’s of zij de voorlopig gekende data-attributen uit de berichten ondersteunen.

Onboarding STR-platformen

Er zal een proces moeten ingericht worden om platformen te onboarden op het SDEP. Pas na deze onboarding zal het platform calls kunnen maken en data kunnen doorgeven. Te bekijken hoe dit proces er zal uitzien.

Versie

Datum

Auteur(s)

23 Jun

Paul Kiekens

Doelpubliek

Iedereen

Inhoudsopgave

Table of Contents