[Dutch] Uitnodiging Verkenning oplossingsrichtingen PDOK light - 1 juli

[Gertjan Idema]

Deze discussie roept bij mij de vraag wat het doel moet zijn van PDOK
light.
Aan de ene kant kan light duiden op de de belasting van de servers. Maar
light kan ook duiden op toegankelijkheid,  gebruiksvriendelijkheid en
flexibiliteit. Of op de benodigde inzet van PDOK middelen en mankracht.

Deze varianten van light zullen vaak tegenstrijdig zijn.

Om de NWB segmenten als voorbeeld te nemen:

Voor de server kan light betekenen dat je alleen een shp-file aanbiedt
om te downloaden. Daarmee is de server belasting minimaal en is het aan
de gebruiker om iets bruikbaars met de data te doen.

Voor de gebruiker word de data een stuk toegankelijker als je
bijvoorbeeld een zoom-level afhankelijke WFS aan zou bieden. De WFS laag
op het hoogste zoom-level biedt de volledige details voor alle
segmenten, maar is beperkt tot kleine gebieden per request. Op hogere
zoom-levels worden de details beperkt door geometrien samen te voegen,
te versimpelen, of helemaal weg te laten. Het zelfde geldt voor de
niet-geometrische attributen.
Op deze manier kan de client (met kleine aanpassingen) bestaande
technieken als open-layers en google-maps api gebruiken, om zelf on-line
kaarten met eigen styling te produceren.
Iets degelijks kan door gebruikers als PDOK light ervaren worden, maar
zal dat voor PDOK als organisatie niet zijn.

Gertjan Idema

On Mon, 2014-06-16 at 09:00 +0200, geejee op dds.nl wrote:

> Goed punt, van het beperken van die WFS-en.
> Ik dacht eerst dat daar een Inspire verplichting achter zat, maar  
> Inspire schrijft voor dat je of hele "predefinned" datasets (via ATOM  
> feeds, of via WFS) of features (via WFS) beschikbaar moet stellen.
> WFS hoeft dus niet persé van Inspire.
> 
> (en in de praktijk zijn de PDOK-WFS-en met hun 15000 features limiet  
> wel beperkt in hun gebruik. Zodra je de Flevopolder verlaat zit je al  
> gauw boven de 15000 adressen of 15000 NWB-segmenten.
> 
> 
> groet,
> 
> Gert-Jan
> 
> 
> 
> 
> 
> Richard Duivenvoorde schreef:
> 
> > On 13-06-14 18:25, Gert-Jan van der Weijden wrote:
> >> Vanuit de PDOK beheerorganisatie kreeg ik de vraag of er OSGeo-ers zijn
> >> die willen meedenken over hoe een PDOK-light er uit zou kunnen zien.
> >
> >> 1. Roep -via deze lijst- eens iets over hoe jij een pdok-light zou
> >> willen zien?
> >
> > Ik gil wat:
> >
> > tl;dr bied alleen relevante goede landelijke services aan en de rest als
> > grote downloads
> >
> >
> > - beperk de WM(t)S services tot enkele goede ondergrondkaarten, bv
> > de luchtfoto's (liefst zelfs hogere resolutie door de luchtfoto's van de
> > verschillende gemeenten aan elkaar te stitchen).
> > de brt-achtergrondkaart
> > de brt in een zachte kleurstelling
> > de bgt (als wmts MET featureinfo)
> > (voor we zijn die 200 zeegras layers interessant, en de alle cbs
> > services zijn eigenlijk eenvoudiger als shapefile neer te zetten)
> >
> > - beperk de WFS'en tot grote landelijke recente data, zoals bgt, bag etc
> > MAAR bied die ook gewoon aan als eenvoudig te laden dataset (zoals ook
> > nlextract doet: eenvoudig een database dump inlezen!)
> >
> > - verbeter de landelijk werkende geocoder, geef 'm evt een extra
> > (google) interface EN maak de software Opensource zodat anderen de
> > geocoder kunnen verbeteren!
> >
> > - zorg voor eenvoudigere downloads van dataset (echt een beetje
> > ontwikkelaar weet echt wel hoe hij/zij een db dump moet inlezen en evt
> > overpompen naar een ander formaat). Maak hierin een duidelijke keuze
> > voor OPEN formaten: het zijn namelijk vooral de gebruikers van de open
> > formaten die ook 'open' verder ontwikkelen
> >
> > - leg het beheer bij een club die de services ook zelf gebruikt, of bv
> > kennis heeft van een beetje cartografie of gebruikerswensen. Veel
> > kaartlagen in PDOK zijn er echt liefdeloos ingehangen wat mij betreft
> > (en het excuus: "zo is het aangeleverd" zo voor mij niet op gaan)
> >
> > - snoei in bureaucratie/regelgeving/procesformalisatie
> >
> > - moedig gebruikers aan om ZELF de services op te zetten (en bied
> > daarvoor dus ook de tools aan: inlees scripts, styling informatie
> > (ook hierbij dus: gebruik OPEN tools, zodat een gebruiker niet vast zit
> > aan FME of ArcGis omdat het kadaster daar nu eenmaal gebruiker van is).
> >
> > ...
> >
> >> 2. En wie willen vanuit deze hoek die ongetwijfeld briljante ideeën op
> >> 1juli 's ochtends in Amersfoort tijdens een sessie bij Geonovum naar
> >> voren brengen? (want goede ideeën hebben is een ding, maar je moet ze
> >> ook nog op de juiste plaats en tijd verkondigen)
> >
> > Indien gewenst kan ik daar aanwezig zijn.
> >
> > Vriendelijke groet,
> >
> > Richard Duivenvoorde
> >
> > Zuidt
> > http://www.zuidt.nl
> 
> 
> 
> 
> _______________________________________________
> Dutch mailing list
> Dutch op lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dutch


------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://lists.osgeo.org/pipermail/dutch/attachments/20140616/7799ce41/attachment.html>