aodn-archive / delete_me.geoserver-layer-filter-extension Goto Github PK

What is needed

The '_map' layers, those layers for visualisation that have attributes, start_time and end_time are intended to be displayed in a single dateRange filter in the portal. The user picks a date range and when downloading the corresponding '_data' layer has a single attribute eg: time. The resulting download contains all matching Time's within the DateRange

How is this configured?

There is a type missmatch where datetime is not recognised as a java class by the filter extension.
Blocking aodn/aodn-portal#1707

What happens

http://geoserver-123.aodn.org.au/geoserver/wms?request=uniqueValues&service=layerFilters&version=1.0.0&workspace=imos&layer=argo_profile_layer_map&propertyName=juld

This fails as juld is not recognised as a java date

Caused by: java.lang.RuntimeException: Unrecognized type
    at au.org.emii.geoserver.extensions.filters.layer.data.ValuesDocument.encodeValues(ValuesDocument.java:90)
    at au.org.emii.geoserver.extensions.filters.layer.data.ValuesDocument.build(ValuesDocument.java:30)
    at au.org.emii.geoserver.extensions.filters.LayerFiltersService.getUniqueValuesDocument(LayerFiltersService.java:108)

What should happen

All filterable types should be handled

http://geoserver-systest.aodn.org.au/geoserver/wms?request=uniqueValues&service=layerFilters&version=1.0.0&workspace=imos&layer=anmn_ctd_profiles_data&propertyName=cruise_id

This link is not working, however, the property cruise_id does exists, as well as the layer name.

@jkburges mentionned the log ouput was :

<jkburges> 19 Mar 13:29:27 ERROR [geoserver.ows] -
<jkburges> java.lang.RuntimeException: java.io.IOException: Schema 'anmn_ctd_profiles_data' does not exist.
<jkburges> not sure if that's actually true or not?```

Previously in the Portal filter labels were reformatted to remove underscores and to make them title case. The suggestion is to use this in the filter plugin to generate the initial filter name (which users could then alter). This way, users configuring filters get the benefit of a nice default value, but they can change it to anything they want and the Portal won't mess with it.

e.g.
A filter with the column name drifter_id would get a default filter name Drifter Id.

What is happening now

The 'uniqueValues' service does not perform well enough to provide the portal date pickers with start and end date information. Layers such as Argo take 13 seconds plus to return all date values.

What is needed

A minMaxValues service to satisfy populating the portal datepickers

The default types are of the wrong kind (or should I say, "type"!), meaning that geoserver filter admins must manually alter the type (that's if they know it) to the correct one, otherwise the portal will not handle that filter property properly.

Steps to reproduce

1. Run up geoserver in po box.
2. Delete file "/workspaces/imos/JNDI_argo_data/argo_profile_download_data/filters.xml"
3. Edit filters for that layer (WMS Layer Filters > argo_profile_download_data)

What does happen
Types are taken from the wrong set, e.g. "String" rather than "string", "Timestamp" rather than "datetime", "Geometry" rather than "geometrypropertytype" etc.

What should happen
Correct types, i.e. as above.

Note: this only affects properties which are currently disabled. For (previously) enabled filters, the correct type remains (if it was initially configured correctly).