Wat is het gewenste waardebereik voor dct:spatial in dataset?

[importalis]

Deze kan een string literal zijn, zoals Gemeente Haarlem, maar ook een geografisch object.

[CelineJansen]

• Een string meegeven is denk ik in elk geval haalbaar / laagdrempelig voor iedere bronhouder.
• Een geografisch gebied koppelen zou dan optioneel kunnen:
  • Misschien kan dit automatisch worden afgeleid wanneer de betreffende data locatie componenten bevat.
  • Een andere optie kan zijn dat er binnen data.overheid automatisch geometrieën gerelateerd worden aan bepaalde strings. (Binnen ons portaal bijvoorbeeld wordt bijvoorbeeld de contour van Eindhoven gekoppeld aan de string "Eindhoven".)
  • Alternatief kan de bronhouder de locatie aanleveren, maar daar kan niet elke bronhouder makkelijk aan voldoen denk ik, wat de kwaliteit / volledigheid niet ten goede zal komen.
    

[keestrautwein]

dct:Location komt vaker voor binnen DCAT. Er zijn diverse problemen met dit kenmerk:

1. GEO standaard Welke GEO standard is er gevolgd voor het invullen van zo'n veld? Er zijn meerdere mogelijkheden.
2. In de verwerking. Een groot nadeel aan het toestaan van zowel string als GEO-data is dat een ontvangend systeem moet kijken of de meegeleverde waarde een string is of niet. Dat lijkt moeilijk.
3. in de verwerking De meeste systemen kunnen geen GEO data verwerken dus dan heeft GEO geen toegevoegde waarde: Mensen noch systemen kunnen die data dan gebruiken. Een string heeft waarde voor menselijke gebruikers.

Een oplossing om strings om te zetten in GEO-objecten, zoals Celine hierboven beschrijft voor de gemeente Eindhoven, is geen standaard. Zo'n oplossing moet telkens opnieuw worden ontwikkeld en kan slechts een beperkte verzameling strings omzetten in GEO objecten.

Ons voorstel is om het geografisch object te laen vervallen, maar altijd een string te gebruiken, eventueel met een best-practise om enige structuur aan te brengen in de waardes, zoals:

• Voeg waar mogelijk "gemeente", "provincie", de naam van het waterlichaam, etc

[CasperKoop]

Commentaar Huub

Location komt in een aantal vormen: voor nl BAG ID, naam, bekend als, punt, coördinaten, vlak, shape HvO: maak een klasse. KT: alleen string. Zie ook SemicEU: How should dct:spatial and dct:Location be used? | Joinup (europa.eu).

En achtergrond: https://semiceu.github.io/GeoDCAT-AP/drafts/latest/

In w3c dcat 2 is een set voor geo toegevoegd: dcta:bbox, dcat:centroid en locn:geometry. En locn:GeograohicName Dct:spatial zou dan meer de klasse zijn die deze kenmerken bevat.

[keestrautwein]

We stellen een oplossing voor die meerdere use-cases ondersteund waarbij dct:spatial meerdere keren kan worden gebruikt.
Uitgangspunt is dat dct:spatial leesbaar moet zijn voor partijen zonder software of expertise om specifieke GEO informatie te ondersteunen. Het is de wens van deze werkgroep een profiel op te stellen dat breed toegepast kan worden. Niettemin is er enige ondersteuning voor Geo-standaarden zoals EPSG-28992 of bounding boxes.

Als onderstaande waardes niet voldoen, kunnen GEO toepassingen gespecialiseerde waardes toegevoegd worden, die niet binnen het DONL profiel worden ondersteund. Nog beter zou zijn voor GEO uitbreidingen van DCAT aan te sluiten bij GeoDCAT-AP, waarvoor helaas nog geen Nederlands profiel bestaat. Het opstellen van zo'n Nederlands profiel voor GeoDCAT-AP ligt buiten deze werkgroep.

Om GEO data toegankelijk te maken en backwards compatible te blijven met het DONLv1 profiel wordt dct:spatial meerdere keren toegevoegd:

1. Een locatie kan worden aangegeven met een waarde van geonames.org (aanbevolen door DCAT-AP). In deze geographische database die door de community wordt bijgehouden wordt aan plaatsen een URI toegevoegd die eenvoudig als waarde kan worden opgeslagen en via geonames geraadpleegd kan worden . Geonames geeft de naam van de locatie weer, met coördinaten en andere informatie en daarnaast is er een weergave op een kaart beschikbaar. Hoewel Geonames zeker niet compleet is, zijn veel locaties waarover binnen Nederland wordt gecommuniceerd opgenomen;
2. OWMS kent verschillende manieren om een locatie te beschrijven afhankelijk van de organisatorische eenheid:
3. overheid:Gemeente2. [overheid:Koninkrijksdeel] (https://standaarden.overheid.nl/owms/4.0/doc/waardelijsten/overheid.koninkrijksdeel) overheid:Nederlandse_Antillen overheid:Provincie overheid:Waterschap
4. Compatibel met DONLv1 is het gebruik van bounding boxes voor gegevens uit het Nationaal Geo Register. De OWMS standaard EPSG-28992 kan gebruikt worden als een coordinaten referentiesysteem om een locatie te beschrijven d.m.v. coordinaten van een vlak op een kaart;
5. Om een locatie aan te duiden met behulp van Postcode en Huisnummer maken we gebruik overheid:PostcodeHuisnummer

[CasperKoop]

Ter informatie, PDOK heeft een handleiding voor het creëren van coördinaten.