- Belangrijkste punt 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 het schaalt op mobiele devices, hip-by-default, maar belangrijker: veel eenvoudiger naar wens aan te passen. [noot van de redactie: NGR is gebaseerd op versie 2.9.x van GeoNetwork, een upgrade naar 3.0 zal een inspanning kosten (overzetten maatwerk-aanpassingen)]
- Daarentegen 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?
- 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 http://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 tekstuele manier en de kaart manier. De ontwikkelingen in de aankomende 3 versie van geonetwork gaan gelukkig die kant op. 1 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).
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 (bv 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 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, 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
Ik wens jullie een toffe dag toe morgen
