Wednesday, January 08, 2025

Running an impressive lightshow from your windows laptop with budget hardware

Hi, it has been a while since i posted here. Something fully different today.

In last weeks i had the opportunity to play with some minimalistic components to set up a lightshow for family parties. I want to share with you the steps involved. Setting things up requires some hours, but the hours are will spent!

Hardware

First get your hardware at one of the online discounters, amazon, aliexpress, bax, Thomann, For example:

- A USB to DMX interface connects your windows laptop to the lightshow, I tried Lixada and works nicely (see later)



- Some DMX cables (one for each light)

- a DMX terminator should be applied at the final light of your lightshow

- and then some PAR and effect lights. This 10E RGB PAR works quite nicely. Verify the light comes with a DMX interface.







Software

The Lixada DMX to USB comes with a Windows 95 driver on a CD... It doesn't work on modern 64bit systems. Fortunately a german guy crafted a driver available via https://www.illutzmination.de/udmxdriver.html for the uDMX interface which works nicely on my win11 laptop

A next tool needed is a software to setup and play the sequences of the lights. I tried opensource Freestyler, and it works nicely. The website and documentation looks a bit rusty, but it works. 



Concepts

A DMX chain connects a chain of lights from the DMX controller to the terminator plug (connect the DMX-out to DMX-in of the next light in the chain).

DMX provides 256 channels, for each channel a level from 0-100 can be send, indicating the brightness of the light. In theory you can control 256 lights with 1 dmx chain. However modern lights require multiple channels per light, 1 channel to control the brightness, others for color, direction, shape, strobe etc. On DMX controlled lights you can typically configure the starting channel for them to listen for. In freestyler you typically indicate for each channel range which light(s) it will control. For example, range 1-8 control light A and channel 9-15 control light B (where lights A and B typically require 8 channels each to be controlled).

A 'fixture' defines what each of the channels of a light manages. Each light requires a specific fixture. For example: Channel 1: Brightness, Channel 2: Red, Channel 3: Green, etc. Freestyler includes many known fixtures for common lights. But you can quite easily create a new fixture for your specific light using freestylers 'fixtureCreator'.

A 'Sequence' plays a set of scenes. Each scene is a single state of all your lights, for example: A and C off, B and D blue, E and F red. Sequences and their scenes are created in the main Freestyler app. During the party, sequences are played using the Sequence player (where you control the speed of playing the sequence and even combine sequences).

Conclusion

With the components above you can set up your lightshow with 8 pars and 4 effects for under 200,- and the show will be quite impressive. Personally I like to use sequences in which I restrict the number of colors in each state to 1 or 2. Combining contradicting colors such as yellow/purple or green/red. 

Let me know if aspects are unclear, and i'll have a look where to extend the story. Continue reading at the Freestyler documentation.

Wednesday, September 03, 2014

Brainstorm verbetering Nationaal Georegister morgen bij geonovum

Helaas kan ik morgen niet bij deze sessie zijn, maar wil toch wel mijn gedachten hierover delen. De sessie is georganiseerd door Geonovum om bij gebruikers (u en ik) na te gaan wat er verbeterd zou kunnen worden aan NGR.

- 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



Monday, September 23, 2013

#Foss4g13 wake-up-call

At #foss4g13 last week... After friday evening's entertainment (the movie blues brothers) I started with this wake-up-call in the auditorium on saturday morning ... (I guess some of it should soon be available in the conference recordings)

Good morning ladies and gentlemen at the Nottingham Campus Auditorium. We're so glad to see so many of you lovely people here at this time, and we would especially like to welcome all the representatives of the local OSGeo Community who deserve you're credits right after this show. We do sincerely hope you'll all enjoy the show, and please remember people, that no matter who you are, and what you code to live, thrive and survive, we chose a license that make us all the same. You, me them, everybody.

* based on works registered at Universal Studios

Wednesday, July 03, 2013

The internet of things and geo services



Today I visited the concluding conference of a linked open data pilot in the Netherlands (http://pilod.nl). In this blog some thoughts on the matter from a (spatial) catalogue perspective. In the last years a lot of energy has been put in publishing open datasets on the web using open geo standards like CSW/WFS (triggered by regulations like Inspire, basis registraties etc). Unfortunately, due to their nature, geo-services can hardly be used in the linked open data web. As geo community I think we should investigate how to support the internet of thinges from our existing services. It's just a shame if they are left out. Or linked data might even bridge the gap that quite some experience between the geo community and regular ICT

CSW/WFS to RDF
Most geo data is tagged with metadata these days. In the metadata references are made to contact point info and keywords from skos thesauri (like gemet). If we'd be able to present this metadata as RDF along with the spatial data itself, the data will link with exisiting resources in the internet of things instantly. Geonetwork does have a basic RDF-endpoint-implementation these days (/srv/eng/rdf.search, funded by EEA), the actual challenge is in creating rdf output from the WFS services (and linked shapefiles) out there and link to that from the rdf-metadata. A potential solution would be to extend products like geoserver and mapserver, which do have support for a range of output formats for WFS (like GML,KML,SHP,CSV,JSON), with an RDF output format. From the RDF metadata one could then link to a WFS-getfeatures request in format application/rdf+xml. Spiders would be able to index the data and use it as linked data to support GeoSparql queries.

Implementing rdf support can be quite easy if it would be a pure xslt transformation (gml to rdf). However RDF is far more usefull if additional items are added to each getfeature-response-document. Items like contact point and keywords (as defined in the service definition) link the record to other resources on the web.

iso19110
An OGC practice described in iso19110 (http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=39965) but unfortunately not commonly implemented is feature catalog metadata (for example http://sdi.eea.europa.eu/catalogue/srv/eng/search?uuid=99b05c69-1532-48b8-bfeb-4cb0df539c88). This could become an essential link in creating RDF from WFS/CSW. ISO19110 describes the attributes used in a dataset. From this metadata references can be made to common (linked data) vocabularies, which then (hopefully) can be used to convert the GML to optimally linked RDF.

Fixed location
The internet of things is based on the fact that each resource on the web has a unique location (url), which will not change over time. In gis servers a record or feature is accessed via a getRecord/getFeature request. One can imagine a scenario that you use this type of requests as unique url for the resource. However, this url is actually not that fixed. For example the order of attributes in the request can change, it can be a post request and the format parameter is explicitely defined in the url (in stead of as an accept header, generally used in open data content negotiation). But more challanging is the version parameter of the standard, after a while a new version of the catalogue standard will become available, and the old standard might get deprecated. The url of the request will change accordingly. This could be managed by adding additional links in the referring document. A link could be added for each supported version, format, language, spatial reference system etc...

Geonetwork as a gateway
Considering above drawbacks it might be an idea to extend the functionality of Geonetwork to act as a gateway between geo and rdf. Geonetwork has all of the required iso19115/iso19110 and links to the actual downloads and services available. It could (daily/hourly) harvest all of that data and convert it to RDF quite optimally. Some additional advantages: a search query in geonetwork will include a search into the actual data and it would solve the uri-strategy for the geo domain instantly: All dutch geodata (PDOK) will for example be available at:
nationaalgeoregister.nl/geonetwork/dataset/{namespace}:{uuid}/record/{id}
For sure some exceptions should be made for frequently changing data like sensor services, and the processing should be delegated to other nodes in the cluster.

For sure above approach will have legal limitations (who is responsible for the data/service). In the long run each organisation will need an RDF endpoint (and register that endpoint in the iso19139 metadata?). But my proposal can offer a temporary solution for organisations which are not ready yet to do the full RDF implementation.

Read more
A search on the web learned there are plenty of initiatives in this area, most important the FP7 Geoknow project (http://geoknow.eu). I'm curious for their results.
Also check "Opportunities and Challenges for using  Linked Data in INSPIRE" by Sven Schade and Michael Lutz http://ceur-ws.org/Vol-691/paper5.pdf


Monday, July 01, 2013

Open data Hackaton Amsterdam

Last saturday I visited the Open Data Hackathon in Amsterdam organised by "HackdeOverheid" (http://www.hackdeoverheid.nl). It was my first visit to such an event. I really liked the vibrant atmosphere, but in the days after some thoughts on it returned to me frequently which I would like to share with you here.

Identifying OpenData
These days it's quite popular at governments to publish data as OpenData. For sure any data published is interesting. However quite some datasets published are aggregated in some way, which makes it less usefull for usecases the publisher hadn't thought about it could also be used for. Sometimes the aggregation is done to facilitate developers, but most of the times it's done for other reasons like to protect the privacy of the persons mentioned in the data.
For example at this hackaton a dataset was presented by SVB (http://www.hackdeoverheid.nl/voornamen-data-beschikbaar-voor-apps), they summerized the given firstname over the whole country, which limits the dataset for a single purpose: firstname-popularity. If they had aggregated to street/postode/area (or not at all) people might have used the dataset to relate name-giving to region or even economical status.
Which leads me to a suggestion to publishers, provide us with the raw data please. Offer aggregations as a separate download.

Open standards
At the event there were frequent requests for open formats like CSV/JSON/TXT, also people requested API's. But there was not much awareness on open standards. At such a point I always realise that as a geo community we're quite far in development and implementation of open standards. The risk of every organisation implementing it's own formats and API's is that a data miner should develop specific format conversions for each organisation he wants to extract data from. Think of the dutch communities, we have some 250 communities, if they would all develop a specific api on their data, it would be very hard to extract similar data from all those api's. Quite some people are aware of this riks, that's why government develloped "basisregistraties": indications on how to store and comunicate data on certain thematic area's, to be implemented by for example all communities. And quite important for the Open Data movement, since most of the data available via the "basisregistraties" will be open data. A first example of this is "Basisregistratie gebouwen", a dataset (+ soap and WFS api) which contains all buildings in the Netherlands.  Ok, this is not a simple json-rest API, but hey, we're developers, we are not afraid of a little XML. My colleague pointed me on http://5stardata.info/ where indeed complying to unified data models in not mentioned as a star, they point at linked data as a way to go. Which indeed might be a better pattern to interact with data from different origin. But afaik is quite experimental at most organisations.

GeoJSON in GitHub
Recently the Github team added GeoJSON support in Github. Uploaded GeoJSON files are displayed as maps on a nice backdrop using LeafletJS. Since then people started uploading masses of GeoJSON files, also in preparation of this Hackathon. For sure there is the risk this will be a single action, and the data will soon be outdated, but if done correctly it could mean a real change in how we're used to publishing data. Imagine:
- An automated proces updates the GeoJSON data in Github every... In the history of git you can then see very nicely the historic development of the dataset.
- You can fork the dataset, reformat it and publish it again, or even open a pull request for data optimisations
- To make the data accessible in traditional GIS you could add a WMS/WFS server which uses the Github GeoJSON as input-storage (using OGR)
- In the end people will love Git as storage and will introduce Git servers in their own organisation as master storage and just clone to Github.
Related to this there is a proposal by Max Ogden & OKFN https://github.com/maxogden/dat and another proposal by OpenGeo https://github.com/opengeo/GeoGit. Today I noticed a blog by Rufus Pollock on the matter, http://blog.okfn.org/2013/07/02/git-and-github-for-data, amazing to see the movement on this theme these days

OGC vs best practices
The last thought is on OGC vs best practices standards. These days we see projects like MapBox, CartoDB, LeafletJS, GeoJSON being very popular, but dissociating from OGC standards.
For sure they use conventions between the products (epsg:900913, TMS, GeoJSON), but those conventions are a result of best practices in the community and not designed in a highly technological and political process at OGC. These best practices standards are  light weight, focus on performance, are much easier to implement, widespread and offer a more fluent user experience than any application using OGC standards. OGC should really focus on these leighter standards. We are at a point that data distributors and proprietary spatial software implementors get much pressure from users to also support the best practices standards, resulting in the fact that the best practices standards are widely implemented in both open source and proprietary systems without having been adopted by OGC.


Friday, June 21, 2013

which OGC standard to use to recieve info from mobile phones being used as sensors

We're cooperating in an european FP7 project called COBWEB (http://cobwebproject.eu) on enabling citizens to contribute nature observations in biospheres. From an interoperability aspect it's quite usefull to use an OGC standard to publish observations from the registered phones. But which one to use, there's a couple of them out there. I did some research, but I'm still not sure. Maybe this research helps others, or comment if you have additional ideas on the matter


Most prominent is the openLS standard, which is actually a set of "core" services around location. One of them being the location service, where a client registers with a server and the server sends out requests for postion at regular intervals, the client then responses with it's location. I'm not sure though, if such a model would work on mobile phones. I think a phone can't have a listener for incoming requests like this (what if it's stand-by or offline at that moment)? You can probably run some webserver like i-jetty or nanohttpd, but i guess it will drain the battery if you keep it alive constantly.

GeoSMS offers location info over SMS, which is a rather costly method, but could work out on phones without internet access.  

NetCDF is a set of formats for creation, access, and sharing of array-oriented data. NetCDF is quite optimal in size and can be accessed with the thredds data server using OGC:CSW or OpeNDap. Seems not very optimal for single sensor transactions. Quite strong in aggregations. NetCDF is mainly used in oceanography and meteorology sensing  

SensorWeb  
SOS/O&M: standards for querying and inserting sensor observations and registring sensors (might be usefull for mobile use, although seems to follow same path as OpenLS in that the server takes initiative to read the sensor, and i'm not sure if this is possible on a mobile phone)  
SES (event service): register for certain events, and get notified if event occurs (might be needed in some usecases)  
 SPS (planing service): can be used to query if a sensor is capable of performing a task and assign the actual task (usecase: send a message to all registered phones: "who is in neighboorhood of xxx,yyy", if yes: "please go to xxx,yyy") 

Geopackage is mostly a database for use on a mobile phone in case of lack of network connectivity. Users can store their measurements in the local database and when back online use the data from the database to trigger posting of observations. Also users might cache image- or vector-tiles for an area so they still have a map while being offline. Geopackage offers some nice options over using plain file or sqlite storage, but comes at a price (extra dependencies for the app).  

WFS-transactional can be used to upload measurements in GML format  

WPS can be used to do any other request/response type even asynchronous, can be used to upload measurements

Conclusion:
  • Most suitable would be SOS or OpenLS, but i wonder if they'd fit in a usecase where a phone takes initiative to send observations as soon as it's back online.
  • If above doesn't work out WFS-t or WPS seem most appropriate
enable citizens living within Biosphere Reserves to collect environmental data using mobile devices - See more at: http://cobwebproject.eu/#sthash.tBOqUwad.dpuf
enable citizens living within Biosphere Reserves to collect environmental data using mobile devices - See more at: http://cobwebproject.eu/#sthash.tBOqUwad.dpuf
enable citizens living within Biosphere Reserves to collect environmental data using mobile devices - See more at: http://cobwebproject.eu/#sthash.tBOqUwad.dpuf
enable citizens living within Biosphere Reserves to collect environmental data using mobile devices - See more at: http://cobwebproject.eu/#sthash.tBOqUwad.dpuf
enable citizens living within Biosphere Reserves to collect environmental data using mobile devices - See more at: http://cobwebproject.eu/#sthash.tBOqUwad.dpuf

Wednesday, June 19, 2013

ArcGIS server and additional WMS styles

Today I had the opportunity to do some experimenting with publishing WMS services on an ArcGIS server instance. My goal was to publish some alternative styles for a WMS layer (most wms clients offer possibility to change a style on a layer, if multiple styles are published in capabilities). Unfortunately it appeared to be quite a challenge to get this done...

As mentioned here, http://resources.arcgis.com/en/help/main/10.1/index.html#/Using_Styled_Layer_Descriptors_with_WMS_services/015400000468000000/, Esri wants me to create an SLD file by hand (based on their snippets) and attach that to the service definition. Ok, quite experimental, but let's try

I used GeoCat bridge (http://geocat.net/bridge) to create the SLD from ArcMap. When I pointed to the SLD file created by bridge (on my local drive), no warning whatsoever, but no additional styles appeared in the WMS. It appears the file should either be located in the ArcGIS Server machine or accessible via the web (was it really strange for me to expect the file would be uploaded during publication?). So after having uploaded the SLD to a web account and inserting the url, the alternative style appeared, yeah!

The styles created by bridge need minor changes to get them working as extra styles in ArcGIS Server. For example the naming of layers is quite bizar in AGS. Layernames are actually increasing numbers (it must be quite a challenge to keep those numbers synchronised over time). So the named-layer section in the SLD should have something like

<sld:NamedLayer><sld:Name>1</sld:Name></sld:NamedLayer>

Also all styles for all layers in the service should be in a single SLD file, so the separate bridge SLD files should be concatenated to a single file.

Note that ArcGIS does not support the full set of SLD tags available in for example geoserver.
Test your style first before publishing to ArcGIS Server by adding the sld parameter to a single wms request.

http://AGS/Service/MapServer/WmsServer?LAYERS=0&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&STYLES=Velocity&FORMAT=image%2Fpng&SRS=EPSG%3A28992&BBOX=177900,314900,178000,315000&WIDTH=256&HEIGHT=256&sld=http://www/test.xml

During my small research I noticed following SLD tags/conventions not supported by AGS:
- <sld:rotation> on sld:mark is skipped
- having a ttf symbol as a wellknownname (convention within geoserver community), in stead use the well known names: circle, square, triangle, star, cross or x

Sunday, June 02, 2013

Amazing list of geonetworks around the globe

These days we head out to Bolsena Italy to have the yearly OsGeo Hack event. As geonetwork community this is one of our mayor events. This year i hope to do some work on geonetwork mobile, a Jquery Mobile implementation of a geonetwork client. In there I hope to include a list of geonetworks, so one can pick a node from a pick-list to query against. I did a search in google and it resulted in an amazing list of public geonetworks around the globe. Below is the bare list, i hope to categorize it to continent soon, include a proper title and have the version used. Maybe even provide a ping-service to check for it's presence over time. Let me know if I've missed some, which for sure i did.

http://www.geocat.ch/geonetwork
http://sdi.eea.europa.eu/catalogue
http://referencedata.rssportal.esrin.esa.int/geonetwork
http://catalog.waterschapservices.nl/geonetwork
http://nationaalgeoregister.nl/geonetwork
http://services.sandre.eaufrance.fr/geonetwork_CSW
http://meta2.isric.org/geonetwork
http://geonetwork.evk2cnr.org:8080/geonetwork
http://geonetwork.sopac.org/geonetwork
http://geonetwork.grid.unep.ch/geonetwork
http://vam.wfp.org/geonetwork
https://www.dov.vlaanderen.be/geonetwork
http://visualizadorgeominero.dinamige.gub.uy:8180/geonetwork
http://geo.ices.dk/geonetwork
http://kars.ku.edu/geonetwork
http://geonet.icarda.cgiar.org/geonetwork 
http://portal.auscope.org/geonetwork
http://cida.usgs.gov/glri/geonetwork
http://cida.usgs.gov/geonetworkUS
http://climate.iarc.uaf.edu/geonetwork
http://chiesa-gis.geography.helsinki.fi:8080/geonetwork
http://scotgovsdi.edina.ac.uk/
http://www.ithacaweb.org/geonetwork
http://spatial.dcenr.gov.ie/geonetwork
http://data.auscover.org.au/geonetwork
http://131.220.109.2/geonetwork
http://sig.cm-valedecambra.pt/geonetwork
http://www.tabi.la/geonetwork
http://www.gis.napier.govt.nz/geonetwork
http://www.metadados.inde.gov.br/geonetwork
http://geomatics.nlr.nl/unsdi
http://www.idera.gob.ar/catalogo
http://gn-evs.ens-lyon.fr/geonetwork
http://www.geoportal.org/geonetwork
http://catalogue.isde.ie/geonetwork
http://mapas.topografia.upm.es:9090/geonetwork
http://pegasosdi.uab.es/catalog
http://www.metoc.gov.au/geonetwork
http://www.ukpeatgeonetwork.org.uk
http://gisdata.nrri.umn.edu/geonetwork
http://www.metadados.geo.ibge.gov.br/geonetwork
http://www.ifremer.fr/geonetwork
http://geowww.agrocampus-ouest.fr/geonetwork
http://218.6.57.50:8080/geonetwork
http://geocatalog.webservice-energy.org/geonetwork
http://www.gogeo.ac.uk/geonetwork
http://clearinghouse.cisc.gmu.edu/geonetwork
http://metadata.provincie-utrecht.nl/geonetwork
http://www.geoshop.hu/geonetwork
http://inspire.wales.gov.uk/metadata
http://metamalaspina.imedea.uib-csic.es/geonetwork
http://ide.ayto-fuenlabrada.es/geonetwork
http://einstein.library.emory.edu/geonetwork
http://geoinformatie.aaenmaas.nl/georegister
http://rides.producciontucuman.gov.ar/geonetwork
http://metadados.ana.gov.br/geonetwork
http://210.107.255.33:8080/geonetwork
http://isde.ucc.ie/geonetwork
http://data-catalogue.mpl.ird.fr/geonetwork
http://sos.tpac.org.au/geonetwork
http://gis.socib.es/geonetwork
https://hub.sharedgeo.org/projects/GLRI/geonetwork
http://nsdiportal.gistda.or.th/geonetwork
http://www.evoltree.eu/geonetwork
http://safer.gisat.cz/geonetwork
http://190.25.231.237:8080/geonetwork
http://134.76.21.100:8080/geonetwork
http://138.100.63.169:8082/geonetwork
http://ide.igmbolivia.gob.bo:8080/geonetwork
http://fdc.formisvietnam.com
http://141.65.7.61:8080/geonetwork
http://geonetwork.wsl.ch/geonetwork
http://discovery1.cems.rl.ac.uk/geonetwork
http://www.statistik.at/gn-inspire
http://urbis.igag.cnr.it/geonetwork
http://www.sig.gov.ar/geonetwork
http://nsdiportal.gistda.or.th/geonetwork
http://nrmdatalibrary.dpiw.tas.gov.au/geonetwork
http://geoservergisweb2.hrwallingford.co.uk:8080/fecatalogue
http://geoportale.lamma.rete.toscana.it/geonetwork
http://osso.org.co:8080/geonetwork
http://www.cgis.nur.ac.rw/geonetwork
http://sedac.ciesin.org/geonetwork
http://neonet.bppt.go.id/geonetwork
http://catalogo.icv.gva.es/geonetwork
http://data.risk-habitat-megacity.ufz.de:8080/geonetwork
http://megaphone.crchum.qc.ca/geonetwork
http://mapas2.funai.gov.br:8080/geonetwork
http://mtcgeo2.mtc.gob.pe:8080/geonetwork
http://www.coastalatlas.net/geonetwork
http://www.fao.org/geonetwork/
http://geobru.irisnet.be/geonetwork
http://23.22.63.123/geonetwork
http://geonode.ithacaweb.org/geonetwork
http://yemen.rcdrrdri.org/geonetwork
http://moz-adapt.org/geonetwork
http://maps.virtualkenya.org/geonetwork
http://cariska.mona.uwi.edu/geonetwork
http://www.montagneaperte.it/geonetwork
http://geonode.wfp.org/geonetwork
http://cigno.corila.it/geonetwork
http://cigno.ve.ismar.cnr.it/geonetwork
http://sling.gosl.gov.lc/geonetwork
http://www.golfgis.com/geonetwork
http://geosnis.sns.gob.bo/geonetwork
http://geonode.igmbolivia.gob.bo/geonetwork
http://georiesgos.sergeotecmin.gob.bo/geonetwork
http://geosinager.defensacivil.gob.bo/geonetwork
http://paris.sopac.org/geonetwork

Wednesday, April 03, 2013

Auto ordering point layers on top of line/polygon layers in GeoExplorer

Once in a while we get this question for GeoExplorer (GXP):

 Force the webviewer to draw points over lines over polygons regardless of the layer menu structure
Off course i get the idea, one will not hide the point layer by overlaying it with polygon features. But still implementing this feature is far les obvious as expected.

This feature is not common in Geo, one will not find it in common libraries. Impact will be quite high to change it code-wise in GXP. One would need a) a procedure to determine the featuretype of a layer (point/line/polygon/mixed/grid) and b) a procedure to reorder the layers triggered by a layer-add/move event, without altering the tree-structure. I'm not even sure a. is obvious, since featuretype is not advertised by default in WMS capabilities.

This might be one of those points where you'll have to decide if the GXP library is suitable for you, it presumes some default GIS workflow, and it's quite impactfull to change it. In such a case using the plain components OpenLayers/Geoext might solve your challenge more easily. But leaving you with a viewer with far less functionality by default.

If a question like this pops up, check the use case! Maybe there are alternatives to get similar behaviour, which do fit the common GIS workflow. For example similar behaviour could be managed by configuration, where one should configure all point layers on top.

By the way, in most usecases I'm not in favour of having tens of layers in a TOC. In most usecases I prefer to have just a couple of layers in a map and present the user another map with an alternative set of layers if they are working in another context (WMC/OWSContext). But give them the possibility of adding additional layers to the context via a CSW-interface.

Saturday, December 08, 2012

Vooruitblik op GEO in 2013


De afgelopen jaren is het op een aantal terreinen hard gegaan met de ontwikkelingen in het ruimtelijke software veld. Google maps, OpenLayers hebben projecten als Mapbuilder en Chameleon (op zich hele leuke projecten) verdreven. En binnenkort zullen de html-5 viewers het stokje overnemen (leafletjs). Niemand durft meer een kaartje in Flash op te zetten en iedere website moet opeens weer leesbaar zijn op een 300*500 schermpje (of voldoen aan de webrichtlijnen). QGis heeft heel wat gebruikers overgenomen van de gevestigde partijen als ze niet al naar een WebClient overgestapt waren. Als u in 2005 echter zoals velen gekozen heeft voor OGC services als basis voor uw geo infrastructuur, dan is dat een duurzame keuze gebleken en de verwachting is dat dat ook nog wel zal blijven. Nog zo'n trouwe metgezel is mapserver, nog steeds de meest betrouwbare opensource kaartmotor die ik ken. Hieronder wat overpeinzingen over de afgelopen periode, ter inspiratie voor 2013...

Belangrijke recente ontwikkelingen zijn de ontwikkelingen rond de diverse portalen (PDOK, PGR, WGR) die in een grote mate voorzien in allerlei datasets met webservices ontsloten vanuit de bron (Kadastraal, BRT, BAG, Luchtfoto's, CBS, NWB). Hierdoor zal men steeds minder zelf tot aanschaf en opslag van door derden verzamelde gegevens over hoeven te gaan. Al bevatten de momenteel beschikbare services in veel gevallen nog niet een volledige historie. Voor ArcGIS en QGis zijn extensies beschikbaar die het gebruik van bijvoorbeeld de PDOK services vergemakkelijken.

De portalen en daarmee gepaard gaande regelgeving (Inspire, Basisregistraties) stellen wel vrij hoge eisen aan de dataleveranciers Dit speelt op diverse niveaus: ondersteuning van een datamodel, volledigheid van de metadata, voldoen aan de standaarden tot beschikbaarheidseisen van de webservices.

Als Geocat ondersteunen we overheden en bedrijven bij het publiceren van geografische datasets (op intra, extra en internet). Ons belangrijkste product is de opensource catalogus Geonetwork, de lijm in iedere spatial data infrastructure (SDI). Het terrein van metadata in combinatie met hoge eisen die Inspire/geonovum aan de metadata stelt maakt dit aspect voor velen vrij lastig. Geonetwork is geen eenvoudig product, echter door optimale inrichting van de templates, geautomatiseerde ETL processen en een losse catalog ontsluiting is het gebruik van de catalog binnen een organisatie wel degelijk te optimaliseren, zodat bijvoorbeeld ook niet-geo-gebruikers er goed mee aan de slag kunnen. Een portaal met een eenvoudigere interface (maar waarmee Inspire compatibiliteit weer lastiger te realiseren is) is bijvoorbeeld Geonode met daarin pyCSW.

Als voorbeeld, via de CSW extensie kan vanuit ArcGIS (maar ook arcgis explorer en QGis kennen een CSW extensie) direct gezocht worden in een catalog. De gevonden resultaten zijn direct aan de kaart toe te voegen. Ook Openlayers kent CSW-zoekopties.

Omdat het publiceren van metadata door velen als lastig ervaren wordt hebben we als geocat het initiatief genomen een "bridge" product te ontwikkelen dat publicatie van ArcGiS projecten naar een Open SDI tot het drukken op een knop reduceert. De data, styling, metadata en/of context wordt gepubliceeerd als kaartlagen in Geoserver of Mapserver, de metadata in geonetwork, waarbij zorg gedragen wordt dat alle wederzijdse koppelingen tussen service, dataset en metadata geautomatiseerd gelegd worden. Een context bestand is de OGC:variant van een themakaart. Een set lagen, een inzoom-extent en een titel met een omschrijving erbij. Optimaal inzetbaar als interactief kaartje bij een webpagina, email of bij netcentrisch werken, waarbij een specialist een kaart voorbereid en deze onder een community verspreid om een ruimtelijk probleem te duiden.


En wat komt er verder nog op ons af... Sensor services, 3D, Big data/Open data, authorisatie, WPS...

  • Steeds meer bedrijven en overheden hebben sensoren hangen/drijven, waarvan men de data stroom in sommige gevallen wil/moet delen met politie, waterschap, gemeente enz. Dan komt de OGC standaard SWE (sensor web enablement) om de hoek kijken. Deze ontwikkelingen zijn relatief nieuw, maar het is al vrij zeker dat bijvoorbeeld Inspire SWE op zal nemen in haar requirements voor bepaalde dataset-publicatie vormen. In geonetwork is SWE in de basis aanwezig, maar ik verwacht daar de komende tijd veel ontwikkeling rond. De meest gebruikte open source sensor server software is momenteel 52 north. 
  • 3D is nog altijd lastig om te visualiseren. Er zijn nauwelijks open source GIS pakketten die een goede 3D weergave hebben. De kaartserver deegree heeft een vrij groot pallet aan opslag mogelijkheden voor 3D data en ondersteuning voor de web perspective view service en 3D CityGML (via WFS). Maar er zijn nog nauwelijks clients die daar gebruik van kunnen maken.
  • 2012 staat onder andere in het teken van open data, door de overheid gestimuleerd is het vliegwiel gaan draaien, wekelijks wordt weer een nieuwe dataset gepubliceerd als open data (PDOK, RDW, RCE, Waterschappen). Altijd goed om de data licenties goed op een rijtje te hebben, sommigen dienen altijd vergezeld te gaan van auteurs vermeldingen (attribution), anderen mogen niet commercieel uitgebaat worden. De andere veelgehoorde term was big data. Met name de vele sensoren die we hebben genereren sneller data dan we kunnen verwerken. Een goede strategie in opslag en verwerking is dus onmisbaar.
  • In tegenstelling tot het punt hierboven wordt ook het aspect van authenticatie voor ruimtelijke services steeds belangrijker. Steeds meer processen lopen via het internet, de data komt overal vandaan. Men wil voorkomen dat niet geautoriseerde mensen bij de gevoelige data kunnen, maar tegelijkertijd ook niet steeds opnieuw een (afwijkend) wachtwoord in toetsen (single sign-on). En hoe dwing je een fair-use policy af?
  • WPS (Web Processing Services) gaan verder waar WMS en WFS ophouden. Analyses, route berekeningen, processen starten/volgen, alles is mogelijk met deze standaard die eigenlijk alleen een standaard biedt voor het formaat van de in- en output parameters. Met een product als taverna zijn dit soort services te combineren tot een workflow, alleen wordt alles remote uitgevoerd.

Een keuze voor Open Source?
In de praktijk blijkt dat de Open Source producten goed aan de OGC standaarden voldoen en qua functionaliteit niet onder doen voor de gesloten alternatieven. Ze passen dus goed in een architectuur gebaseerd op Open standaarden. Een eventueel nadeel is de bundeling van een aantal verschillende producten tot een SDI. Ik zie dat echter als een voordeel, met een Suite van een leverancier heeft men niet de mogelijkheid er een slecht presterende component uit te halen en te vervangen voor een beter alternatief. Een ander groot voordeel is dat als er wat mis is, men relatief eenvoudig op zoek kan naar de oorzaak. Rond Open Source producten zijn grote communities actief die actief op gebruikersvragen reageren. Er zijn ondertussen voldoende bedrijven die professionele dienstverlening hebben rond open source software, zoals OpenGeoGroep, B3Partners, Aris, GeoCat. Zij ondersteunen bij installatie, configuratie, aanpassingen, nieuwbouw, onderhoud en storingen.

Ik hoop u hierbij wat aanknopingspunten gegeven om uw visie rond geo verder uit te diepen.

Ik was dit verhaal aan het typen aan een potentiĆ«le klant, op basis van een advies aanvraag en dacht waarom niet op de blog. Anderen vinden het misschien ook interessant, zo'n compact overzicht.


Wednesday, November 07, 2012

Apply combined fill on multiple fields in geoserver SLD

Imagine you want to add a style to a map layer where the style is applied based on values of two attribute fields. Implementation like below seems quite logical if you see it, but I was quite surprised it works out of the box in geoserver... (Alternative would be to add the layer twice or have 10*10 rules, each field 1 value times each field 2 value)

The use case is a polygon fill based on crop cultivar as background-fill color and association (other crop that is mixed in) represented as a hash-pattern on top of the fill.

In geoserver you can add two featurestyles to a layer user style, the first implementing the background fill based on field A and a second style based on field B

<StyledLayerDescriptor> 
<NamedLayer>
<UserStyle>
<Name>test_style</Name>
<FeatureTypeStyle> ...</FeatureTypeStyle>
<FeatureTypeStyle>... </FeatureTypeStyle>
</UserStyle> 
</NamedLayer>
<StyledLayerDescriptor>

In featuretypestyle 1 now define the backgroundfill based on field 1
...
<Rule>
<Name>Cavendish</Name>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>cultivar_type</ogc:PropertyName>
<ogc:Literal><![CDATA[1]]></ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<PolygonSymbolizer>
<Fill><CssParameter name="fill">#FF0000</CssParameter></Fill>
</PolygonSymbolizer>
</Rule>
....
And in featuretypestyle 2 define the hash-pattern based on field 2

...
<Rule>
<Name>Associated with established perennial crops</Name>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>association</ogc:PropertyName>
 <ogc:Literal><![CDATA[1]]></ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<PolygonSymbolizer>
<PolygonSymbolizer>
<Fill>
<GraphicFill>
<Graphic>
<Mark>
<WellKnownName>shape://vertline</WellKnownName>
<Stroke><CssParameter name="stroke">#000000</CssParameter></Stroke>
</Mark>
</Graphic>
</GraphicFill>
</Fill>
<Stroke><CssParameter name="stroke">#6E6E6E</CssParameter><CssParameter name="stroke-width">1</CssParameter>
</Stroke>
</PolygonSymbolizer>
</Rule>
...





This will result in a combined style as follows



A potential challenge here is the legend-display, but the two featurestyles are nicely placed after each other...



Monday, October 15, 2012

why THE spatial metadata usecase not always succeeds

So what's THE spatial metadata usecase? Imagine you're looking for a nice map on butterflies in the Alpes region France. You open up your favourite map editor (be it ArcMap, QGis or an Openlayers webclient), be sure a metadata search plug-in is installed (http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm, http://nextgis.ru/en/blog/cswclient, http://gxp.opengeo.org/master/examples/catalogue.html). Imagine you already have the url for the french metadata portal (or to some portal harvesting all european/global datasets), be it http://www.geocatalogue.fr

Now when looking for keyword 'butterfly' and pointing to Alpes, in most cases you'll find a nice set of results, thanx to the CSW standard. But as soon as you want to add those datasets to a map the troubles start... Apparantly the standards (and/or implementations) are unfortunately not totally clear in describing the full use case. Here is a list of items which you'll encounter researching this use case in several implementations:

- CSW uses the Dublin Core standard to describe dataset metadata. There is however no clear way specified in DC how to put webservice (be it WMS, WFS or WMTS) information (like url, protocol) in the document. Apparantly a group of enthousast invented in 2006 a dclite4g profile on top of DC which introduced a key DC:Uri and DC:format http://wiki.osgeo.org/wiki/DCLite4G. Geonetwork still uses this DC:Uri. However without refering to the DCLite4G profile, resulting in a non-conformant DC-record. Inside the DC:Uri element attributes like protocol, name and description (from iso onlineresource) are available, which enables addition of the dataset-service to the map. The Geonode team recently proposed to solve the add2map challange by in stead of using a DC:Uri element, to use a DCT:references element (which is available in the DC Terms schema). The dct:references however has only one attribute, the attribute 'schema'. To be able to have parameters like protocal, name and url, they proposed to add a json object containing these values into the schema attribute (http://dev.geonode.org/trac/wiki/pycsw#MetadataLinks). Let's keep interoperability in mind while designing these standards-additions...

- A next challenge in this usecase is in the ISO online resource definition. Apparantly the standard doesn't describe where the layername is stored which presents the actual dataset. This results for example in ArcGIS CSW-client that all layers of a service are added to the map. Within the metadata community people have come to some form of an agreement to put the layername in the name element, and you'll see most of the current implementations use this agreement. For example the dutch government has put this agreement in their metadata profile (http://www.geonovum.nl/sites/default/files/nederlands_metadata_profiel_op_iso_19115_voor_geografie_-_v1.3.pdf).


I guess that's the reason they've put an option to choose your favourite flavour
of CSW 202 in ArcMAP CSW client

- Recent ISO standards offer more specified guidelines for creating these types of links. This approach however has quite some overhead, so won't get popular very soon, I haven't seen any client implemenation so far (besides the ones in Geonetwork and ArcGIS Portal). ISO proposed to add to each metadata for dataset record (iso:19115) a link to a number of metadata for service (iso:19119) records in which a layer presenting this data is available (WMS/WFS/WMTS). To get from metadata for dataset to the URL-properties one needs an additional CSW request.

- Apparantly the amount of requests needed to add a layer to the map needs to be minimised to keep up performance, especially in browser based applications like GeoExt. I saw some comments in the GeoExt/GXP code, that a Catalogue search implementation should not include a getcapabilities request to the actual mapserver. Probably because this is a very costly request taking quite some browser memory. But there is some information in that getcapabilities request you'll need for a seemless user experience: For WMS the projections are only in the getcapabilities, but also the available image formats and feature-info formats. One'll need to check them before being able to add the service to a map (which could have a different  projection/image format). This is especially true when adding a WMTS service (the tiling scheme is only available in getcapabilities). Getcapabilities request can turn really big as soon as 100's of layers are grouped in 1 service. So keep your services small. Latest Geoserver (2.2) supports splitting up the main service into multiple smaller services using workspaces. Or we might endorse OGC and the server vendors to also allow a layer parameter in a getcapabilities request. So you get a capabilities response for only the single layer you're interested in.

JeroenT, BartvdE, TomK, FrancoisXP, MarceldR Thanx for sharing these insights

Wednesday, October 03, 2012

Using comboboxes in an ExtJS PropertyGrid

When viewing/editing a database record in a PropertyGrid, you often encounter integer-foreign-keys referring to other tables containing lookup-labels. In the propertygrid you would want to display the lookup-label in stead of the integer. You could get the label with a json-ajax-request, but since you might need these values multiple time It's probaly better to have them cache in an ArrayStore.

var store = new Ext.data.ArrayStore({
fields: ["id", "label"],
data :  {"lookup":[[1,"blue"],[2,"red"],[3,"green"],[4,"yellow"]]}
});
Now you can reference the correct label from the ArrayStore in the customRenderer configuration of the PropertyGrid (ExtJS 3.4 implementation http://dev.sencha.com/deploy/ext-3.4.0).
 new ext.grid.PropertyGrid({
                            customRenderers: {
                                  //get the lookup label
                                'color': function(v){ return getLookup(store,v) }
                            },
                            propertyNames: {
                                'color':'Couleur' //set a localised property header
                            },
                            source: aRecordStore.record[0].data
                        })
function getLookup(store,id){
           if (store.find('id',id)==-1) return "-";
           else return store.getAt(store.find('id',id)).get('label');
}

Using a store here to retrieve a single label is not very optimal, but the store will come in handy when you want to edit the propertygrid. In the case of the foreign key, you would want to present the user with a dropdown (combobox) of available values:

new ext.grid.PropertyGrid({
                            customRenderers: {
                                'color': function(v){ return getLookup(store,v) } //get the lookup label
                            },
                            customEditors: {
                                //you don't want people to edit the id-field
                                'id': new Ext.grid.GridEditor(new Ext.form.TextField ({disabled : true})),
                                //get a combobox editor filled with lookup values to edit the color field
                               'color': new Ext.grid.GridEditor(new Ext.form.ComboBox({
                        store: store,
                    mode: 'local',
                    forceSelection: true,
                    triggerAction: 'all',
                    editable: false,
                    valueField: 'id',
                    displayField: 'label',
                }
            )
        ),
                            propertyNames: {
                                'color':'Couleur' //set a localised property header
                            },
                            source: aRecordStore.record[0].data
                        })

In case you want people to only be able to edit the propertygrid when a certain condition is met (is authenticated/edit button has been activated), use the beforeedit event:

listeners: {"beforeedit": function() {
                if(!readOnly) {
                    return true;
                } else {
                    return false;
                }
            }
}

Monday, September 24, 2012

Add dutch gridset to Geoserver 2.2

This weekend geoserver 2.2 got released. Besides the obvious novalties, like WFS2 support, new authentication system, able to connect to ldap, a nice feature has been added; the possibility to separate the workspaces as separate endpoints, each having it's own parameters (like title, abstract, point of contact, styles). To get the capabilities for just 1 workspace visit the url http://..../geoserver/workspace_name/wms?request.... To set individual parameters on a workspace check the 'settings' box in the workspace edit form.

Also new is the ability to create a gridset from within the geoserver admin interface, before only the gridsets epsg:4326 and epsg:900913 were available. Now you can easily create a gridset for any projection. The gridset is saved in the geowebcache.xml. For example the gridset for the dutch projection epsg:28992 would look like this (copy paste them in geowebcache.xml), according to the dutch tiling guidelines (by geonovum)

 <gridSet>
      <name>RD_NEW</name>
      <description>Scales indicated by geonovum in nederlandse richtlijn tiling v1.0 from june 2010</description>
      <srs>
        <number>28992</number>
      </srs>
      <extent>
        <coords>
          <double>-285401.92</double>
          <double>22598.08</double>
          <double>595401.92</double>
          <double>903401.92</double>
        </coords>
      </extent>
      <alignTopLeft>false</alignTopLeft>
      <resolutions>
        <double>3440.64</double>
        <double>1720.32</double>
        <double>860.16</double>
        <double>430.08</double>
        <double>215.04</double>
        <double>107.52</double>
        <double>53.76</double>
        <double>26.88</double>
        <double>13.44</double>
        <double>6.72</double>
        <double>3.36</double>
        <double>1.68</double>
        <double>0.84</double>
        <double>0.42</double>
        <double>0.21</double>
      </resolutions>
      <metersPerUnit>1.0</metersPerUnit>
      <pixelSize>2.8E-4</pixelSize>
      <scaleNames>
        <string>0</string>
        <string>1</string>
        <string>2</string>
        <string>3</string>
        <string>4</string>
        <string>5</string>
        <string>6</string>
        <string>7</string>
        <string>8</string>
        <string>9</string>
        <string>10</string>
        <string>11</string>
        <string>12</string>
        <string>13</string>
        <string>14</string>
      </scaleNames>
      <tileHeight>256</tileHeight>
      <tileWidth>256</tileWidth>
      <yCoordinateFirst>false</yCoordinateFirst>
    </gridSet>

Wednesday, August 22, 2012

custom workflow from featureinfo in GXP GeoEXT ExtJS

In a series of articles I would like to share some experiences with open source tooling we frequently use at GeoCat to fullfill customer wishes. I'd like to start with an article on the GXP library by OpenGeo. Developers at OpenGeo use this library in their famous products OpenGeoSuite, GeoNode and more to build interactive webbased mapviewers. The library is based on OpenLayers, ExtJS and GeoExt and can be used to build/configure a full interactive mapviewer including feature-query and edit in minutes. Download a copy from Github: https://github.com/opengeo/gxp.

At GeoCat we use the library if customers have very specific viewer demands which can not be met by a generic product like Geonetwork or Geonode. Today i did a small customisation which i think might be usefull to share with you, since a situation like this happens often. A customer wanted to display a list of coupled records from a non-geospatial table linked to a geometry a user clicked on in the map.

First challenge was to find an 'exit-point' from the default GXP workflow, in this case feature-info. I use exit point, because at that point you leave generic GXP workflow (display a record in a popup) and enter a customised workflow (open additional popups, ajax-requests and more). I wanted to convert the value of an attribute in the featureinfo result to a hyperlink, which starts up customised workflow. One way to set up such a hyperlink on an attribute is by addind a feature-template for that layer to geoserver and add the hyperlink in the template. Next choose html as display format for featureinfo (there is even another way available: one could add the hyperlink itself to the database, eg SELECT '<a href=' || www || '>click here</a>' AS link FROM ....). But in this case I added a ExtJS customRenderers on WMSGetFeaturinfo's itemConfig configuration. Such a renderer can override the default 'print as string' of a PropertyGrid to print about anything (like an image, hyperlink, ajax-lookup)



{
    ptype: "gxp_wmsgetfeatureinfo",
    outputConfig: {
        width: 400,
        height: 200
    },
    itemConfig: {
        customRenderers: {
            yourfieldname: function(value) {
                return '<a href='+value+'>Click here</a>';
            }
        }
    }
}

In stead of a hyperlink we'll need a javascript function call, to in this case load customised content and place it in a panel.



return '<button onclick="getPanelContent(' + value + ')"';



To retrieve the content from the PostGres database, i used PHP to generate JSON. Be sure to activate PostGres extension in PHP.ini.



<?php

$dbh = pg_connect("host=localhost dbname=postgis user=postgres port=5432");
$sql = "SELECT * FROM dummy where id =" + $_POST["id"];
$result = pg_query($dbh, $sql);   
$data = array();
while ($row=pg_fetch_object($result))
{
$data [] = $row;
}
echo json_encode($data);

?>


To retrieve the JSON I used an Ext.JSONStore with a load event that pushes the JSON result as a set of Ext.propertyGrids to a Panel with Accordion Layout (this is how GXP displays a usual getfeatureinfo result).



var store;

Ext.onReady(function(){

 store = new Ext.data.JsonStore({
    url: 'content.php',
    fields: [
            'Id','title', 'type'
        ],listeners: {
            load: {
                fn: function(store, records, options){
                 store.each(
                    function(record){
                     Ext.getCmp("accordionPanel").add(
                            new Ext.grid.PropertyGrid({
                            columns: [
                                {id:'Id',header: 'ID',   dataIndex: 'Id'},
                                {header: 'title',   dataIndex: 'title'},
                                {header: 'type',  dataIndex: 'type'}
                            ],
                            source:record,
                            title:record.get('title')
                        })
                     )
                });
                Ext.getCmp("accordionPanel").doLayout();
                }
            }
        }
    });
       
});



Finally only the load needs to be triggered when the button in the featureinfo panel is clicked, the id of the clicked record should be added here as a filter.



function getPanelContent(value){
store.load({params:{id:value}});
}



I hope this GXP customisation was interesting to read. Feel free to send me improvements.
I'll put up a live demo and full code-download soon.

Saturday, January 21, 2012

mapwindow & metadata

Today i looked at the mapwindow/dotspatial project http://mapwindow.org. A plain-functional .Net desktop gis product. The program has a very nice plug-in architecture. Through a vast list of plug-ins quite some advanced geo-actions can be done. My interest lies in metadata, i was hoping for a CSW-search imlementation. Unfortunately it's currently not available (and no work being done), even WMS/WFS is not supported out of the box (basic WMS through a plug-in). However I was quite surprised to find a metadata-plugin in 4.8 (not in 6?). The plug-in works quite nice. A tree structure for the metadata and for every item a clear edit-form appears. The metadata is however very ESRI-FGDC oriented. In the metadataviewer are actually esri-stylesheets used.
So disappointing to find very limited support for iso19115.
I think (through the WMS-plugin) the basis is there for a CSW search plug-in, extending mapwindow in that direction would be nice. A first quick win is in the context-menu for a WMS-layer, 'show metadata' should not result in a warning ('not available') but get the metadata-link from getcapabilities and display the metadata from the WMS-server!
Maybe i'll dive in the code one day and get it done myself...
Good luck dotspatial/mapwindow team....!

Saturday, December 31, 2011

Changing jobs: Nieuwland -> GeoCat

With the turn of 2011 to 2012 i had the oppertunity to change jobs. This year i start at Geocat bv (http://www.geocat.net). Geocat is the project lead in the open source project geonetwork (http://geonetwork-opensource.org/), a geo-metadata catalog server. Also they (or we) developed an esri-extension to publish data from ArcGIS to GeoServer, Mapserver, PostGis and GeoNetwork (or any CSW-server), GeoCat Bridge. The extension is sold all over europe, in the US and in Canada. Extra opportunities to visit the open source communities abroad. GeoCat also customises OpenLayers/ExtJS clients for customers in a variety of industries.

Aside the international oppertunities i'm looking forward to working in a fully opensource atmosphere amongst at least 4 great colleagues. I wish everybody a great 2012.

Tuesday, September 13, 2011

OpenLayers 2.11

Just upgraded to OpenLayers 2.11, unfortunately my scale control broke down, appeared to be because of new language-keys in i18n Use these new keys in Lang/language.js 'permalink': "Permanente verwijzing", 'graticule': 'Arcering', 'overlays': "Overlays", 'baseLayer': "Achtergrondkaart", 'scale': "Schaal = 1 : ${scaleDenom}", see: http://trac.osgeo.org/openlayers/ticket/3364 And somehow my bbox-strategy doesn't refresh anymore... I have to look into that further.

Sunday, July 03, 2011

Geoserver 2.1 and Inspire View Service Requirements

We currently host Inspire View Services for two customers using GeoServer. Since Geoserver 2.1 the required WMS 1.3 is available, and an Inspire extension is available to add some extra required fields to the capabilities document. However the View Services in Geoserver are not yet fully conformant to the Inspire requirements.

Some points of non-conformance:
- In the keywordlist a reference should be made to which thesaurus the keyword is coming from
- For every layer for every available CRS a bbox should be provided in that CRS
- In the top layer a authority url should be provided, referencing the publishing organisations website
- In every layer a identfier should be available referencing the
dataset (which is also mentioned in the metadata for data and
metadata for services records)

Note that this only applies to scenario 1 (where a metadata for service record is available). And only 1 language supported (which is also default language).

The dutch government proposed a 'workaround' to be able to use products like Geoserver and still be compliant. The capabilities document can be manually altered and saved anywere on the web. In the metadata for service record a hyperlink should be included to the altered capabilities document (however i don't know of any viewer supporting this workaround)

examle of altered capabilities document

Most of these short-comings also exist in the deegree project. Although the developers convinced me they're nearly there.

Thursday, June 23, 2011

OSGeo hacking event bolsena

It's been a while since i published an article... But here it is.
So i'm spending some days at the OSGeo hacking event in Bolsena.
Listened to some nice presentations about Talend Open Studio Spatial Plug-in, deegree, inspire, openSDMX and Heron-mc. I played a little with deegree. the guys from Bonn really did a nice job implementing the Inspire data schema's. I tested the hydropraphy data schema and the metadata store. Ok, it's not all perfect yet, some Inspire requirements are missing (even for view services), but i'm really surprised nobody is using deegree to host Inspire services up till now. Esri must really be big in Germany. I think it will change soon, because deegree (compared to others) is totally ready for download services.

Also i tested the metdatastore in deegree, since deegree 3 doesn't have a csw-search-interface itself, i used the excat javascript search tool, a very light weight csw-search option. Unfortunately it didn't work out of the box. Somehow excat uses lowercase fieldnames where deegree expected first letter uppercase. With some changes in cswclient.xml and getrecords.xsl it all worked fine (line44 escape should be escapeChar, title -> Title etc)

http://wiki.deegree.org/deegreeWiki/DownloadPage
http://wiki.osgeo.org/wiki/Bolsena_Code_Sprint_2011
http://spatialdataintegrator.org
http://heron-mc.org
http://www.couchbase.org
http://sourceforge.net/p/opensdmx
http://www.gdsc.nl/gdsc/software/simple_csw_client