Dankzij initiatief en gastvrijheid (lekkere broodjes!) van GeoNovum zaten zo'n 25 geo-vertegenwoordigers van diverse gemeenten, andere overheden, georganiseerd en ongeorganiseerd bedrijfsleven en ontwikkelaars bijeen over het vraagstuk "hoe nu verder met GeoZet?".
Moeten we streven naar een uniforme geoviewers voor de gehele overheid? Of zelfs breder? Want dat Nederland te klein is om allerlei eigen viewers te laten ontwikkelen is iets waar we het aardig over eens zijn.
Wat moet zo'n viewer dan -op basis van standaarden- kunnen en zijn? Voldoen aan webrichtlijnen / geïntegreerd met een content management systeem / op basis van open source / gereed om open data te ontsluiten / gemakkelijk configureerbaar / ook als SAAS leverbaar / ondersteund door een levende community / voortvarend gepromoot / met een helder licensiemodel. En dan houd ik nog voor me dat ik voor onze Haagse open data op zoek ben naar een integratie van dataportalen als NGR en data.overheid.nl.
Eerst divergeren met de wensen, het convergeren komt later wel. Hoop ik.
Er is al heel veel op dit gebied, zowel producten (Esri's GeoCMS, Geozet, Flamingo, als diverse maatwerkoplossingen zoals de Geo-CMS integratie op basis van ArcGIS en GX in de gemeente Den Haag. Zowel kennis als communities.
Eens kijken of we al die requirements kunnen verzamelen, er een "grootste gemene functionele behoeftestelling" uit kunnen distilleren en dit aan diverse overheden voorleggen met de vraag: "hoe blij wordt u als we in deze behoeftestelling voorzien". En bij positieve reacties de boer op om -al dan niet op basis van een bestaand product- in die behoefte te voorzien.
Beetje GovUnited-achtig. Maar dan hopelijk zonder financieringsprobleem.
Wat losse bemerkingen uit en rond deze meeting:
- GeoZet heeft (okee, met de huidige beperkingen dat het alleen punten toont) het voldoen aan de webrichtlijnen als unique selling point. Flamingo had in het verleden usability als sterk punt, maar is daarbij in de laatste jaren ingehaald;
- Velen hebben het gevoel dat GeoZet en Flamingo bij elkaar brengen zeer zinvol is, maar ik bespeur nog weinig toenadering:
- GeoZet is een term die 2 ladingen dekt: soms wordt de software bedoeld, soms het turn-key systeem van viewer met daarbij het onderliggende systeem van gevulde geocodeerservice en kaartachtergrond;
- Er is tot dusverre geen partij te vinden die deze geo-informatie-infrastructuur kar enthousiast trekt. Iedereen wil wel meewerken, maar de grote Geoleider moet nog opstaan;
- de Nederlandse communities zijn klein, maar de internationale community rond de geo-CMS koppeling op basis van Openlayers en Drupal schreeuwt ook om uitbreiding
- er zat alleen geo aan tafel. Volgende keer graag ook webredacteuren en communicanten: dat zijn immers degenen die de behoefte bepalen!
Posts tonen met het label cms. Alle posts tonen
Posts tonen met het label cms. Alle posts tonen
dinsdag 20 december 2011
zaterdag 1 november 2008
Content Management met GIS (of omgekeerd?)
Dat willen we toch allemaal: Dat het management content is?
Maar dat bedoelde ik niet direct met deze titel. Wel doel ik op Content Management Systemen (CMS) zoals die gebruikt worden om websites handig te beheren. Deze systemen zijn de voorlopig laatste stap in de evolutie van het beheer van webpagina's: van hard-coded HTML (met daarin opmaaktags voor vet, cursief etc.) via cascading stylesheets (css) waarbij de inhoud en vorm waren gescheiden naar nu dus CMS-en, waarmee de inhoud ("content") wordt losgehaald van de webpagina. Een CMS definieert een set ankers ("placeholders") op een webpagina waarin dynamisch de inhoud wordt gegoten. Die inhoud bestaat uit artikelen, blogs, nieuwsberichten, rss-feeds die weer van andere sites afkomstig zijn en zo voort.
Hoe verhoudt zich dit nu tot GIS-systemen?
De scheiding tussen vorm en inhoud is in ArcGIS en voorganger ArcInfo altijd moeizaam geweest. In mijn AML-tijd wisten we dit op te lossen door de inhoud (welke kaartlagen en hoe weergegeven) en de vorm (welke paginagrootte, waar komt de legenda) in aparte AML's te gieten.
Voor wat betreft desktop GIS: De templates in ArcMap voorzien in zo'n beperkte mate in dat diverse partijen zélf de scheiding van vorm en inhoud ter hand hebben genomen. Mapmaker dat ESRI Nederland ism het Zuiveringsschap Hollandse Eilanden en Waarden heeft ontwikkeld, het door ARIS voor het PBL (voorhen MNP) GeoView en het door MX Systems voor Verkeer en Waterstaat beheerde VenW layouter zijn hiervan drie voorbeelden uit Nederland. Sommige van deze tools gaan al zover dat hiermee ook bijvoorbeeld symbolenset en logo's centraal gedefinieerd kunnen worden.
Dat wil ik ook gebruiken voor mijn websites. En dan niet als een in zichzelf gekeerde GIS-tool, maar als een plugin voor de bekende CMS-en als Joomla! en Drupal.
Dus allereerst een tool waarmee kaartlayouts gedefinieerd kunnen worden. En wel graag met één en dezelfde tool zowel voor papieren kaarten als voor webkaarten, zodat ik stijlen voor schaalbalken, titels en mijn logos ongeacht het medium wat ik kies kan hergebruiken.
Vervolgens een tool om de kaarten zelf mee te maken, wederom ongeacht het medium (papier, beeldscherm) waarop het terecht komt. Natuurlijk is beeldscherkartografie heel wat anders dan kartografie voor papier, maar de tool die ik wil houdt daar rekening mee en kan hier flexibel mee omgaan. De output van deze tool kan dynamisch aan een outputservice gekoppeld worden die naar believen een beeldschermPDF, een pre-press PDF of een WMS (of WFS+WCS) uitspuugt
Daarnaast iets om deze WMS en WFS webservices te beheren. Met dezelfde tool kunnen natuurlijk ook de bron geodatasets als service worden beheerd.
Dan iets om de webapplicatie mee te maken. Hé dat hebben we al, want dat is ons Content Management Systeem. En zitten daar ook al niet modules in om te bepalen wie nieuwe layouts mag maken, wie nieuwe content mag toevoegen, welke catagorieën er gedefinieerd zijn voor de artikelen. Mooi, dan gebruiken we die tools ook om in onze hierboven geschetste layouttool, kaartentool en webservicemanager gebruiksrechten toe te kennen en elementen te categoriseren en van services en objecten aan te geven of ze voor breed gebruik "gepublished" zijn of dat ze nog in bewerking zijn
Net zoals ik met het blogging systeem waarmee ik dit bericht schrijf "tags" en categoriën kan toekennen, voorlopige versies van berichten kan beheren en zo meer.
Hetzelfde verhaal geldt natuurlijk ook voor de bouw van geodataportals. Die moeten niet alleen zoeken naar geodata mogelijk maken maar ook via wiki's kennis kunnen bijhouden, gebruikers commentaar kunnen laten geven op dataset en aankondigingen van AGGN-gebruikersdagen, gisconferenties etc. doen.
GIS-software bouwers: beperk u tot de specifieke GIs functionaliteit. Doe dat heel goed en zorg dat het praat met services en componenten van buiten de GIS-wereld zodat "de GIS-wereld" deel uit gaat maken van de rest van het heelal.
Maar dat bedoelde ik niet direct met deze titel. Wel doel ik op Content Management Systemen (CMS) zoals die gebruikt worden om websites handig te beheren. Deze systemen zijn de voorlopig laatste stap in de evolutie van het beheer van webpagina's: van hard-coded HTML (met daarin opmaaktags voor vet, cursief etc.) via cascading stylesheets (css) waarbij de inhoud en vorm waren gescheiden naar nu dus CMS-en, waarmee de inhoud ("content") wordt losgehaald van de webpagina. Een CMS definieert een set ankers ("placeholders") op een webpagina waarin dynamisch de inhoud wordt gegoten. Die inhoud bestaat uit artikelen, blogs, nieuwsberichten, rss-feeds die weer van andere sites afkomstig zijn en zo voort.
Hoe verhoudt zich dit nu tot GIS-systemen?
De scheiding tussen vorm en inhoud is in ArcGIS en voorganger ArcInfo altijd moeizaam geweest. In mijn AML-tijd wisten we dit op te lossen door de inhoud (welke kaartlagen en hoe weergegeven) en de vorm (welke paginagrootte, waar komt de legenda) in aparte AML's te gieten.
Voor wat betreft desktop GIS: De templates in ArcMap voorzien in zo'n beperkte mate in dat diverse partijen zélf de scheiding van vorm en inhoud ter hand hebben genomen. Mapmaker dat ESRI Nederland ism het Zuiveringsschap Hollandse Eilanden en Waarden heeft ontwikkeld, het door ARIS voor het PBL (voorhen MNP) GeoView en het door MX Systems voor Verkeer en Waterstaat beheerde VenW layouter zijn hiervan drie voorbeelden uit Nederland. Sommige van deze tools gaan al zover dat hiermee ook bijvoorbeeld symbolenset en logo's centraal gedefinieerd kunnen worden.
Dat wil ik ook gebruiken voor mijn websites. En dan niet als een in zichzelf gekeerde GIS-tool, maar als een plugin voor de bekende CMS-en als Joomla! en Drupal.
Dus allereerst een tool waarmee kaartlayouts gedefinieerd kunnen worden. En wel graag met één en dezelfde tool zowel voor papieren kaarten als voor webkaarten, zodat ik stijlen voor schaalbalken, titels en mijn logos ongeacht het medium wat ik kies kan hergebruiken.
Vervolgens een tool om de kaarten zelf mee te maken, wederom ongeacht het medium (papier, beeldscherm) waarop het terecht komt. Natuurlijk is beeldscherkartografie heel wat anders dan kartografie voor papier, maar de tool die ik wil houdt daar rekening mee en kan hier flexibel mee omgaan. De output van deze tool kan dynamisch aan een outputservice gekoppeld worden die naar believen een beeldschermPDF, een pre-press PDF of een WMS (of WFS+WCS) uitspuugt
Daarnaast iets om deze WMS en WFS webservices te beheren. Met dezelfde tool kunnen natuurlijk ook de bron geodatasets als service worden beheerd.
Dan iets om de webapplicatie mee te maken. Hé dat hebben we al, want dat is ons Content Management Systeem. En zitten daar ook al niet modules in om te bepalen wie nieuwe layouts mag maken, wie nieuwe content mag toevoegen, welke catagorieën er gedefinieerd zijn voor de artikelen. Mooi, dan gebruiken we die tools ook om in onze hierboven geschetste layouttool, kaartentool en webservicemanager gebruiksrechten toe te kennen en elementen te categoriseren en van services en objecten aan te geven of ze voor breed gebruik "gepublished" zijn of dat ze nog in bewerking zijn
Net zoals ik met het blogging systeem waarmee ik dit bericht schrijf "tags" en categoriën kan toekennen, voorlopige versies van berichten kan beheren en zo meer.
Hetzelfde verhaal geldt natuurlijk ook voor de bouw van geodataportals. Die moeten niet alleen zoeken naar geodata mogelijk maken maar ook via wiki's kennis kunnen bijhouden, gebruikers commentaar kunnen laten geven op dataset en aankondigingen van AGGN-gebruikersdagen, gisconferenties etc. doen.
GIS-software bouwers: beperk u tot de specifieke GIs functionaliteit. Doe dat heel goed en zorg dat het praat met services en componenten van buiten de GIS-wereld zodat "de GIS-wereld" deel uit gaat maken van de rest van het heelal.
Abonneren op:
Posts (Atom)