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

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;
                }
            }
}