[Dutch] morgen: help mee het NGR te verbeteren!

[Paul van Genuchten]

hi GJ (en Simeon), helaas ben ik er morgen niet bij, maar namens GeoCat
schuift Jan Skornsek aan. Ik heb mijn wensen lijstje aan hem meegegeven
:-) Hier een hernieuwede interpretatie daarvan:

- Belangrijkste is natuurlijk: die interface die 5 jaar geleden (de
ijstijd) hip was, die kan echt niet meer, het schaalt niet, te
technisch, te complex enz. Goed nieuws, geonetwork 3 verschijnt eind dit
jaar, interface is van scratch herbouwd in Angular/Bootstrap/Less enz.
Dus hip-by-default, maar belangrijker: veel eenvoudiger naar wens aan te
passen.

- Wel een belangrijke discussie is, waar positioneer je het register en
wat zijn de belangrijkste use-cases rond het register:

- Zou je willen dat alle datasets (services, software, documenten,
sensornetwerken) met een ruimtelijke component in het register
beschikbaar komen, wat tot een overdaad aan (dubbele) informatie leidt
(en daarmee een slechte kloon van google) of wil je bijvoorbeeld alleen
landelijke datasets van overheidsinstellingen in het register
beschikbaar stellen. De commerciëlen, ngo's, Gemeentes, waterschappen,
provincies kunnen bijvoorbeeld een eigen portaal inrichten.

- Hoe positioneer je je ten opzichte van de open data portalen. Veel
initiatieven in de geo-catalogussen-sector richten zich op het nabouwen
van een eenvoudige CKAN achtige interface (of gebruiken ckan als
interface op geonetwork). Iemand anders stelde echter juist dat we ons
(als geo) juist moeten onderscheiden door de kaart centraler te zetten.
Als mensen een eenvoudige interface willen, dan gaan ze maar naar
data.overheid.nl. Een kaart georiënteerde catalogus begint met een kaart
en via een zoekinterface kun je kaart-data aan die kaart toevoegen. Maar
de kaart kan ook datasets suggereren op basis van aangeklikte thema's en
de locatie (en periode) waar je op ingezoomed bent.
http://map.geo.admin.ch/ is hier een heel mooi voorbeeld van. De
waarheid ligt waarschijnlijk in het midden, ik zie meer in het aanbieden
van 2 zoekingangen, de textuele manier en de kaart manier. De
ontwikkelingen in de aankomende 3 versie van geonetwork gaan gelukkig
die kant op.
Een punt in dit kader is hier helder: de mapping van iso19139 naar DCAT
moet beter! Hopenlijk gaat het 'IPM dataset', waar binnenlandse zaken
mee bezig is dit proces faciliteren. Ook moeten geo-dataproviders zich
beter realiseren dat hun data ook via andere portalen ontsloten zal
worden en dat zij mogelijk hiervoor hun data beschrijving (en data
formaat) hierop moeten afstemmen.

Een belangrijke use-case rond het register is voldoen aan INSPIRE
wetgeving, dit wordt misschien te weinig bij de eindgebruiker onder de
aandacht gebracht, waardoor de gebruiker terug schrikt van de gebruikte
terminologie. INSPIRE heeft mijns inziens ook een beetje ongelukkig de
term view en download service bedacht, een niet-geo gebruiker kan
hierdoor op het verkeerde been gebracht worden door te denken dat met
zo'n service eenvoudig data te downloaden is, het omgekeerde is waar.
Door gewoon de technische term WFS te hanteren voorkom je dit. Overigens
is het goed mogelijk om met datapipes veel van de technische formaten
toch eenvoudig beschikbaar te maken als json/csv (met uitzondering van
sommige complexe GML en basisregistratie schema's, hiervoor ben ik een
concept "flat views op complexe data" aan het uitwerken).

Ook veel gehoord is de discussie: is ngr voor de geo professional en
pdok-kaart voor de semi-pro? Het zou een keus kunnen zijn het zo te
positioneren, echter het ngr omvat wel veel meer data dan dat via pdok
beschikbaar is (waterschappen, rdw, rce, tno, rivm, knmi, defensie,
provincies enz publiceren niet via pdok). Maar je zou bijvoorbeeld in
pdok-kaart een eenvoudige catalog-search in kunnen bouwen.

Een andere verbetering in het NGR zie ik in mogelijkheden voor linked
data. Het huidige dcat-rdf endpoint van ngr bevat nog teveel bugs (mede
door een slechte iso19139 naar dcat mapping). Dataproviders zouden
daarnaast een eenvoudige interface moeten krijgen om semantiek aan de
attributen van hun csv/shapefile toe te kennen (of natuurlijk direct een
rdf dataset of endpoint registreren), je kunt de dataset daarmee
relatief eenvoudig omzetten naar json-ld (een rdf encoding). Vervolgens
zou een sparql endpoint ingericht kunnen worden op het ngr wat zowel de
metadata als data doorzoekt. Daarmee kan dan in 1 keer de
meest-simpel-te-vragen-maar-meest-uitdagend-te-beantwoorden geo vraag
gesteld worden: "wat legt de overheid allemaal vast rond mijn huis?" Ook
google profiteert, want die kan de data semantischer indexeren.

Een ander punt is het spelen met data, wat de open data portalen erg
goed oppikken (socrata), maar in het geo domein ook cartodb. Het
aanpassen van legenda's, het clusteren, filteren, animeren van data (wms
is achterhaald, wmts alleen voor achtergrond data, wfs en data bestanden
heb je nodig). En waarom altijd een kaart? een grafiek is in sommige
gevallen veel sprekender. Zo'n visualisatie beschrijf je, sla je op in
de catalogus en deel je met je collega's, die dan ook commentaar moeten
kunnen geven.

Nog een persoonlijk puntje, ik zie graag betere support voor sensor en
IoT standaarden (sensor locaties op een kaartje, sensor aanklikken,
grafiekje met meetwaardes). En hoe gaan we 3D visualiseren in NGR?
OpenLayers 3 is geen beperking...

En de homepage mag een tikkeltje aansprekender... Het moet in 1 blik
duidelijk zijn dat je op het coolste geo portaal van Nederland aangeland
bent, what's new, twitter feed, aantal datasets per categorie enz

Een "for developers" sectie was een goed initiatief, maar dient verder
uitgewerkt te worden. En beste developers, beste Simeon, NGR=GeoNetwork,
dus als je een bug vind in NGR, registreer (en fix) m dan in de
GeoNetwork-Github, dan rolt ie op termijn automatisch door naar NGR.
"stable-develop" is de brach die uit gaat monden in de Geonetwork 3 release.

Ik wens jullie een toffe dag toe morgen

groet Paul