Implement Catalogue into Heron (GXP AddLayers, via W*S Capabilities)

[GoogleCodeExporter]

Implement a catalogue function to allow the user to pull layers from any of 
WMS/WFS/TMS/WMTS etc. Similar to http://suite.opengeo.org/geoexplorer/composer

* A implementer configurable button which can be added to the layers list that 
will allow users to add layers. [1]

* A separate button which will allow users to remove a selected layer from the 
layer list and the map. (already in layer-settings in a manner of speaking).

* The add-layers button should bring up a dialog/panel (which is better?) that 
includes a drop-down menu of all pre-configured systems. The bottom item on the 
list should be "Add new Server". [2]

*- The implementer can pre-configure services (probably with a "name", 
"description" as well as the URL) which will appear in a list.

*- Using the "Add new Server" item, the user is asked to enter a name and URL 
for the service. Once entered Heron will negotiate with the service invisibly. 
[3 (optional)]

*== It should support all of the following services at least: WMS, WMTS, TMS 
and WFS (the later can be styled by the user with the new tools after all). 
Other services too if desired ("anything supported by OpenLayers" was the 
quote).

*== Any service that is added by the user should be remembered in the drop-down 
list for future sessions (after browser restart), likely using cookies or HTML5 
storage.

*- Once a user has selected a service (implementer specified or user 
specified), Heron uses the GetCapabilities to list to the user the layers 
available. Layers should be listed alphabetically using the "Title" where 
available, or the "name" otherwise. The Abstract should be included somewhere 
too, along with any other pertinent information [4].

*- Above this layer list, heron will show the Service-wide title and abstract 
from the Getcapabilities.

*- This list of layers should be searchable (case insensitive). Ideally via a 
dynamic search box (similar to Google suggestions). It should search at least 
the title, but also keywords and maybe abstract too. [5 (optional)]

*- (WMS) For each layer there could be a small icon which should depict if a 
layer is queryable or not (WMS).

*- (WMS) How do we handle formats? Just assume PNG? Make the user select from 
available options using PNG as default?

*- (WMS) Where multiple styles are available, Heron should allow the user some 
way to specify which to use. [6 (optional)]

*- (WMS) Ideally it will include a preview of the style (the URL for the legend 
is in the GetCapabilities). I'd suggest only doing this if the legend 
width/height (also typically in getCaps) is below a certain threshold (though 
GeoServer currently has a bug where it mis-reports legend sizes).

*- User should be able to select multiple layers using standard Ctrl and Shift 
interface paradigms. [7]

*- Once a layer is added, it should be enabled by default on the map unless WFS 
(WFS would be off by default to stop accidental feature overload). [8]

* Any layers added should be remembered in the user's bookmarks if saved.

* Layers added later should be on top of layers added earlier.

* If a layer is added, Heron should use whatever the map projection is if the 
layer supports it. Otherwise use WGS:84 (always supported) and reproject. (that 
should cover everyone)

==============

The numbers is square brackets (i.e. [1]) are the order of actions I forsee a 
user taking.

Note: Due to the complexity of the UI for this feature, I'd *strongly* advise 
starting by creating a simple mockup of the proposed interface first and then 
liasing with us (and any other interested Heron devs/users) to confirm/tweak 
it. Alternately maybe 30 minutes with paint to knock up some screenshots may be 
an idea. I don't currently have any particular UI in mind, hence not providing 
any myself.

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 23 Dec 2013 at 1:55

[GoogleCodeExporter]

Courtesy of a post to the list unrelated to this - 
http://geo.zaanstad.nl/zaanatlas/composer/# - I like that as a potential 
interface!

In place of the big picture, use the style from the GetLegend maybe?

Original comment by jonathan...@warwickshire.gov.uk on 23 Dec 2013 at 3:33

[GoogleCodeExporter]

Original comment by jus...@gmail.com on 6 Feb 2014 at 2:48

• Added labels: Milestone-Release1.0.1

[GoogleCodeExporter]

Original comment by jus...@gmail.com on 6 Feb 2014 at 2:49

• Added labels: Milestone-Release1.0.2
• Removed labels: Milestone-Release1.0.1

[GoogleCodeExporter]

We have two exampless here 
"Composer" http://suite.opengeo.org/geoexplorer/composer and
"Zaanatlas" http://geo.zaanstad.nl/zaanatlas/composer. 

Both are based on GeoExplorer, a component of the Boundless OpenGeo Suite. Like 
Heron, GeoExplorer is built on GXP and GeoExt, thus a good start. Especially in 
"Composer", the Widgets come directly from GXP. In "Zaanstad" the pop-up window 
is developed proprietary.

But apart from this we need to determine what kind of sources we should support 
initially. "Catalogue" in GXP is a broad term that allows various Layer 
sources, the most prominent being: WMS URLs (WMS Capabilities) and CSW Queries. 
Apart from that many custom sources, like Google Maps are available.

So which sources need to be supported CSW and or WMS? The Zaanatlas uses only 
CSW Sources via GeoNetwork. GN also supports "thumnails", these are the images 
you see (ha, I did that thumbnail implementation for GN back in 2009!). 
Thumbnails are not a general CSW facility.

The OpenGeo Composer example provides several sources:
- via "Add Layers" various Layer  sources, preconfigured WMS URLs like "Local 
Geoserver" via WMS GetCapabilities, "Add new server.." one can add a WMS URL.
- via "Find Layers" a CSW is queries as in the Zaanstad example (in this case 
PyCSW, earlier versions used GN but they replaced that with the lightweight 
PyCSW). 
- via Upload, but this is via GeoServer proprietary REST (we could do Heron 
Vector layer upload here)

So the GXP widgets do not yet cover WMTS/TMS and WFS. The main question is: 
should we now support CSW. This makes sense when querying public CSWs as we 
have in the national Dutch SDI or when you run your own WCC CSW. This will in 
general provide more structured MD i.s.o. individual capabilities, but CSW has 
some complexities.

The easiest is to start with WMS Caps (preconfigured and "Add own server..") 
with the GUI as in the Composer example. I like the minimalistic approach. 
Possibly we can add "Find Layers later.

But first: "to CSW or not to CSW, that is the question" :-).

Original comment by jus...@gmail.com on 28 Feb 2014 at 2:56

• Changed state: Started

[GoogleCodeExporter]

<So which sources need to be supported CSW and or WMS? The Zaanatlas uses only 
CSW Sources via GeoNetwork. GN also supports "thumnails", these are the images 
you see (ha, I did that thumbnail implementation for GN back in 2009!). 
Thumbnails are not a general CSW facility.>

No. Thumbnails are a conditional xpath in CSW, but the most GDI's use them.
.....
<gmd:graphicOverview>
     <gmd:MD_BrowseGraphic>
        <gmd:fileName>
          <gco:CharacterString>MYGRAPHIC.jpg</gco:CharacterString>
        </gmd:fileName>
    </gmd:MD_BrowseGraphic>
</gmd:graphicOverview

Original comment by fotomich...@web.de on 28 Feb 2014 at 3:33

[GoogleCodeExporter]

I'm guessing CSW is Catalogue Service for the Web? We have no interest in that 
currently; we're not really using GeoNetwork and probably won't be using it 
properly any time soon if we can avoid it. The UK's national SDI (for INSPIRE) 
is still a mess. Allowing for CSW in the future is fine, but it's beyond the 
scope of our interest in this.

We're only interested in the OGC services, per the original quote:

'*== It should support all of the following services at least: WMS, WMTS, TMS 
and WFS (the later can be styled by the user with the new tools after all). 
Other services too if desired ("anything supported by OpenLayers"'

I don't believe thumbnail will work through this service, but as suggested, 
maybe the style from GetLegend? Although that can't be relied on either. 
Alternately it may be possible to create a thumbnail with a WMS request (QGIS 
does this), although that would be a significant hit performance possibly for 
larger lists. Also won't work for scale-thresholded data.

Hope that provides a good starting place.

Original comment by jonathan...@warwickshire.gov.uk on 28 Feb 2014 at 3:37

[GoogleCodeExporter]

@ fotomichi444@web.de true but my remark was based on that in the ZaanAtlas 
GeoNetwork example I see thumbnails returned like:
      <dc:URI protocol="image/png" name="thumbnail">resources.get?id=465&fname=afvalbakken_s.png&access=public</dc:URI>

See http://sourceforge.net/apps/trac/pycsw/wiki/GeoNodeNotes
"Both ISO and DC allow for the advertisement of HTTP links. ISO's 
CI_OnlineResource construct allows for a certain level of granularity to 
express links (linkage, protocol, applicationProfile, name, description, 
function). Dublin Core allows for dct:references [0..*], which has a scheme 
attribute. There is no further granularity within dc:references. 
Implementations have used dc:URI, however dc:URI is a non-standard element of 
DC record model in CSW 2.0.2"

Probably it should be done like here:
http://geonetwork-opensource.org/manuals/trunk/eng/users/quickstartguide/new_met
adata/linking.html

But ok, given Jonathan's CSW remarks just crossing, we luckily don't need to 
dive into the quirks of CSW and MD standards.

Original comment by jus...@gmail.com on 28 Feb 2014 at 3:55

[GoogleCodeExporter]

Attachmed are three screenshot sequences, as how the GUI and UX could like like 
when taking the default GXP-based catalogue widgets. Here these are based on 
local configuration of WMS URLs and the possibility of adding (WMS) Server 
URLs. Later this "Add Layers" option may be extended with CSW (Find Layers).
My proposal is to take this example as the basis implementation and extend this 
with requirements as above (additional server types, legends etc). Examples 1 
and 2 show the "Add Layers" widgets embedded in a Popup Windows. Example 3 is 
functionally identical but the widget is embedded in the right (west) panel 
layout item. I personally like Example 3, as it is minimal and integrates this 
functionality nicely in the layers navigation.

Original comment by jus...@gmail.com on 3 Mar 2014 at 1:17

Attachments:

• gxp-catalogue-screenshot1.jpg
• gxp-catalogue-screenshot2.jpg
• gxp-catalogue-screenshot3.jpg

[GoogleCodeExporter]

Hi Just,
The workflow in your screenshots is OK, but we'd prefer the interface from 
http://geo.zaanstad.nl/zaanatlas/composer - or something akin to it.
The layer list in the GXP examples is fairly ugly and hides a lot of the 
important information from the user requiring them to manually drill down.
The zaanatlas is much better suited to basic users being able to easily tell 
what a layer is.

Original comment by jonathan...@warwickshire.gov.uk on 3 Mar 2014 at 1:22

[GoogleCodeExporter]

Hi yes, that is true, but The Zaanatlas is totally based on a (single) CSW, not 
WMS, server with custom tweaks, client-side XSL,  and all to fetch and display 
rich data and thumbnails. As we need to base ourselves on general WMS 
Capabilities we will get less richer metadata. Although the Zaanstad Viewer is 
Open Source as well and partly based on GXP, their CSW Widget is totally 
developed from scratch. My initial estimate of 10 days was based on taking the 
GXP catalogue widgets (there are several) and modify and tweak these to fit 
requirements. To build this from scratch like the Zaanstad Viewer would at 
least double the days. GXP also has structured its catalogues widgets into an 
extensible framework. I would rather extend that framework than divert from it 
with all maintenance issues that would cause.

That said, I agree that the existing interface in screenshots 1+2 is somewhat 
"technical". What I would propose is to still use those widgets, but try to 
embellish their display and content style and further buttons/knobs to more 
match the ZaanAtlas

- single green + button (no dropdown)
- larger popup
- remove grid headers
- have single colums grid with custom HTML layout per record, showing 
title+abstract and button to add.
- thumbnail: attempt to fetch single image from WMS, but this may be tricky as 
some WMSs have scale delimiters

Original comment by jus...@gmail.com on 3 Mar 2014 at 3:38

[GoogleCodeExporter]

Oh yes, I know that the Zaanatlas is highly customised, I was more hoping to 
use it as a kind of reference pointer and target for what we'd like to see 
interface wise.

Things that can be taken from it:

- More space for each item.
- Plenty of white space.
- Abstract, name, title all nice and clearly positioned. All are in most 
Getcapabilities (not TMS).
- No need to drill down.

There will be some differences too - mostly listed in the original post here; 
things like selecting output formats/styles etc maybe. I guess a drop-down for 
styles selection if there's more than one (and grey it out if there is only 
one).

If you're going with the single green button, having text ("Add Layers") with 
it too would be a good idea I think.

See attached for an example / mockup. 
=The little icons are from the Legend (so a simple GetLegend Request) - don't 
show them if they're large though. :-)
=The buttons at the top simply change the list that's in the drop-down for what 
type of server is showing. Although I guess all server types could be on the 
same list, but that may get unwieldy.

Does that seem doable?

Original comment by jonathan...@warwickshire.gov.uk on 3 Mar 2014 at 4:18

Attachments:

• Clipboard09.png

[GoogleCodeExporter]

Ok, work started, the first step, integrating GXP catalog plugins into Heron 
has been done. But issue is not 'Ready'. The running example is being worked at:

http://lib.heron-mc.org/heron/latest/examples/catalog

See this as progress report. So the new Ready status will be set when the above 
requirements are met, but maybe it is better to do this in stages. Interesting 
is that GXP uses a custom ExtJS Grid extension 'RowExpander' which allows one 
to display metadata info records horizontally and vertically (after expanding 
via '+'). 

Specifics:

* WMS and TMS (and CSW, not enabled) are supported out of the box, WFS and WMTS 
will take effort
* many other plugins exist in GXP to connect to various mapping backends like 
ESRI, OSM etc.
* one can add own server URL
* GFI does not work yet (needs other settings)
* look if something from the ZaanStad layout can be implemented
* layer-context popups

At least a start. To be continued...

Original comment by jus...@gmail.com on 11 Mar 2014 at 4:30

[GoogleCodeExporter]

Hi Just,
Thanks, that looks like a good start!

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 5:01

[GoogleCodeExporter]

More enhancements (done in GXP via GXP issue 
https://github.com/boundlessgeo/gxp/issues/230).

Discovered a great feature in ExtJS: Templates. Using a single cell per row 
grid, the cell itself could be layout with some of the Zaanstad layout using an 
ExtJS HTML template and some CSS.
See the result here:

http://lib.heron-mc.org/heron/latest/examples/catalog

The template also fetches WMS Legends for each layer record. So yes, this is 
doable. The specific Template layout will even be made configurable. 

Original comment by jus...@gmail.com on 14 Mar 2014 at 4:24

[GoogleCodeExporter]

Wow, that's really awesome.

---
I realise it's still in development, but some thoughts/suggestions:

- The ability to specify a maximum size of legend to be displayed. Some of them 
are absurdly large (typically the basemaps).
- Alternating background colours for each row. I.e. stronger delineation.

Looks like an excellent start!

Original comment by jonathan...@warwickshire.gov.uk on 14 Mar 2014 at 4:32

[GoogleCodeExporter]

I realise it's still in development, but some thoughts/suggestions:

- The ability to specify a maximum size of legend to be displayed. Some of them 
are absurdly large (typically the basemaps).
==> ok, the width/height can be configured

- Alternating background colours for each row. I.e. stronger delineation.
This is possible, via the 'stripedRows' GridPanel config option, but with the 
"record-cards" already standing out, this made it visually very busy. The 
current version is more similar to Zaanatlas: a ligthgray background with cards 
in foreground. Via some CSS specific to this grid. 

Still some challenges:
- some GetLegendGraphic calls, also for WCC WMS, give an exception
- for TMS and later WFS we need another preview thumbnail strategy
- WMTS is really hard to implement, if even possible, the metadata and 
parameter also in OpenLayers are very complex. There is no GXP plugin. On the 
other hand all WMTSs support TMS, so that will be an option.

Original comment by jus...@gmail.com on 17 Mar 2014 at 10:19

[GoogleCodeExporter]

- 'This is possible, via the 'stripedRows' GridPanel config option, but with 
the "record-cards" already standing out, this made it visually very busy.'
Ok. I see you've improved the differentiation between rows by adding a border 
(that was going to be my other suggestion).

---
One thought - On a per layer basis, would it be possible to add a "Queryable: 
Yes|No" based on the WMS GetCaps? I don't think there's anything else useful on 
a per-layer basis.

I'm hoping this will be super configurable like the print preview dialog.

Looking excellent though!

Original comment by jonathan...@warwickshire.gov.uk on 17 Mar 2014 at 12:45

[GoogleCodeExporter]

- "'This is possible, via the 'stripedRows' GridPanel config option, but with 
the "record-cards" already standing out, this made it visually very busy.'
Ok. I see you've improved the differentiation between rows by adding a border 
(that was going to be my other suggestion)."
==> Yes, the Grid doesn't look like a grid anymore! Once one gets started with 
ExtJS XTemplate a whole new UX world arises!

"One thought - On a per layer basis, would it be possible to add a "Queryable: 
Yes|No" based on the WMS GetCaps? I don't think there's anything else useful on 
a per-layer basis."
==> depends: Style, Mimetype. Queryable is only for WMS but we can provide. 
Each Layer Type has its own GXP Plugin: WMS, TMS, OS, Google all extending from 
"LayerSource" class. No WMTS and WFS Layer Sources exist. WMTS is a pain, all 
Tileservers support TMS at the same time. I've extended the WMS and TMS Plugin 
to provide a "getPreviewImage()", a URL. For WMS this is a GetLegendGraphic 
URL, for TMS the topmost tile: 0,0,0. Default is a CSS-class ".layercard 
.preview-notavailable" with encoded background image in GXP all.css. Try e.g. 
Google Layers.
Next thought is that it would be very cool to have WMS map previews, but this 
is quite tricky w.r.t. providing the right SRS and scale. 

I'm hoping this will be super configurable like the print preview dialog.

Original comment by jus...@gmail.com on 18 Mar 2014 at 11:01

[GoogleCodeExporter]

One thing that's come up: the legend icons look good when they're visible but 
not when they're scaled down (due to being too large) because they're 
effectively invisible. We don't have a proposed solution for this, but we think 
that such legends will confound some users.
Anyone have any thoughts? I see WMS map Previews, but feel that'll kill our 
server in short order.

Original comment by jonathan...@warwickshire.gov.uk on 19 Mar 2014 at 12:45

[GoogleCodeExporter]

One thing that's come up: the legend icons look good when they're visible but 
not when they're scaled down (due to being too large) because they're 
effectively invisible. We don't have a proposed solution for this, but we think 
that such legends will confound some users.
Anyone have any thoughts? I see WMS map Previews, but feel that'll kill our 
server in short order.

==> That is exactly what I tested (and commented out) yesterday: WMS GetMap 
Previews. Indeed I may have killed a server or two ;-). One problem is: what 
area (bounds) to take. There are many poorly optimized WMSs out there that will 
choke on displaying the entire extent on 40x40 pixels. Another thing I came 
across is 'minScale' and 'maxScale' constraints especially SLD  
maxScaleDenominator (which translates to OL minScale, enough confusion there 
already!). I use them a lot (as not have others kill our server). But then: 
where to zoom in? For example for let's say cadastral parcels, or hiking 
trails, one may zoom into empty areas quickly.

I can make it a config option (none, GetLegend or GetMap). GetMap looks really 
attractive, but it remains tricky. I've even thought of some tiny controls for 
the preview to randomly pick a zoom/extent...
The most tricky part is the image loading. Naively setting the HTML <img 
elements to a GetMap will fire all requests and many get killed by well-behaved 
WMSs (or the other way around!). The JS_hackers trick is to do sequential image 
loading in the background but this is again complex. 

Ohter ideas? In a controlled environment with predefined WMS-es one could think 
of defining a "preview-Style" or even SLD Rule in the single Style, for each 
Layer with a fixed Style or Rule-name e.g. "preview-image". One could define a 
Style or Rule that uses a preview image as an icon. The Catalog WMS source when 
configured with that option for that WMS source may then request a Legend for 
that style and thus receive a preview image.   Another possibility is to 
(mis)use the WMS Attribution Logo image..In GeoServer one can fill in any URL 
that points to an image. But still a general solution that applies to all 
WMS-es is virtually impossible. That is maybe why CSW has been invented but 
that is another can of worms by itself...

Other ideas welcome!

Original comment by jus...@gmail.com on 19 Mar 2014 at 2:39

[GoogleCodeExporter]

> "There are many poorly optimized WMSs out there that will choke on displaying 
the entire extent on 40x40 pixels."
Some layers simply can't be optimised as a WMS. Some of our Layer Groups are 
inherently slow and that's after having Andrea optimise GeoServer source for 
those specific layer groups. So the actual optimisation is that they're meant 
to be used via TMS (but are still available via WMS). I mention this because it 
will probably apply to others too.

> "Another thing I came across is 'minScale' and 'maxScale' constraints 
especially SLD maxScaleDenominator"
Concur - we too use them a lot too, and I don't know what the solution would 
be. Although isn't this issue also applicable for GetLegend as well?

----

One possible general solution which would get past the optimisation issue 
(though not the Mina/Max scale one), though it certainly has its own (fairly 
significant) drawbacks.
Have all requests for a GetMap go to the heron.cgi script which would act as a 
form of cache server. Basically heron.cgi makes the GetMap request, stores the 
resultant image locally on the server, and serves that image back to the user. 
Any future requests for that image get the cached image back instantly.

I'll ask on the GeoServer list and see if anyone has any suggestions there. 
Might be worth asking on the Heron list (for those who don't read this digests).

Original comment by jonathan...@warwickshire.gov.uk on 21 Mar 2014 at 11:33

[GoogleCodeExporter]

> "There are many poorly optimized WMSs out there that will choke on displaying 
the entire extent on 40x40 pixels."
Some layers simply can't be optimised as a WMS. Some of our Layer Groups are 
inherently slow and that's after having Andrea optimise GeoServer source for 
those specific layer groups. So the actual optimisation is that they're meant 
to be used via TMS (but are still available via WMS). I mention this because it 
will probably apply to others too.

==> Yes, that is a known issue. Best solution is to have your tiling-WMSes on a 
different and non-public server. If that is not possible you may think of using 
GeoServer VIrtual Services, making these WMS-es a hidden URL. You may even put 
HTTP Basic Auth on this URL. GeoWebCache is able to be configured with 
credentials. But all Heron-unrelated.

Yes, minScale/maxScale affects getLegend as well, good that you raise this.
----

One possible general solution which would get past the optimisation issue 
(though not the Mina/Max scale one), though it certainly has its own (fairly 
significant) drawbacks.
Have all requests for a GetMap go to the heron.cgi script which would act as a 
form of cache server. Basically heron.cgi makes the GetMap request, stores the 
resultant image locally on the server, and serves that image back to the user. 
Any future requests for that image get the cached image back instantly.
===> I don't favor this solution. IMO there are quite some side-issues, 
basically dealing with error handling and stale caches. That said, one could 
even think of using GeoWebCache, tiling just one level with one tile. The TMS 
preview already gets tile 0,0,0. Even if you have minScale, you can configure 
GWC such that 0,0,0 is a zoomed in tile (via extent).
I've seen your question on the GS list. 

I'll ask on the GeoServer list and see if anyone has any suggestions there. 
Might be worth asking on the Heron list (for those who don't read this digests).

Original comment by jus...@gmail.com on 21 Mar 2014 at 3:30

[GoogleCodeExporter]

> Yes, minScale/maxScale affects getLegend as well, good that you raise this.
GetLegendGraphic has a parameter "SCALE" but if I fill in minScale or 
(minScale+maxScale)/2 I get the same exception as you already raised: 
https://jira.codehaus.org/browse/GEOS-5846. It is a small (scale) world ;-).  
But my issue is that minScale (as from the capabilities maxScaleDenominator) is 
somehow a different unit  than GetLegendGraphic expects. If I enter smaller 
values manually like '2134' I get legends back ok.
Leaving SCALE out gives better results, also legends that have a scale 
denominator are returned. 

One problem is that some layers give strange errors like:

http://maps.warwickshire.gov.uk/gs/wms?SERVICE=WMS&REQUEST=GetLegendGraphic&VERS
ION=1.1.1&FORMAT=image/png&WIDTH=40&HEIGHT=40&LAYER=z_OS_Vector_Basemap

gives 

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE 
ServiceExceptionReport SYSTEM 
"http://maps.warwickshire.gov.uk:80/gs/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd
"> <ServiceExceptionReport version="1.1.1" >   <ServiceException>
      java.lang.IllegalArgumentException: Filter Function problem for function round argument #0 - expected type float
Filter Function problem for function round argument #0 - expected type float
</ServiceException></ServiceExceptionReport>

> I'll ask on the GeoServer list and see if anyone has any suggestions there. 
Might be worth asking on 
> the Heron list (for those who don't read this digests).

I've seen Jody's reply on the GeoServer. Indeed some Layers don't obey 
width/height and give a complex legend.

http://maps.warwickshire.gov.uk/gs/wms?SERVICE=WMS&REQUEST=GetLegendGraphic&VERS
ION=1.1.1&FORMAT=image/png&WIDTH=40&HEIGHT=40&LAYER=TRO_ORDERS_WITH_ROADS_VIEW

Others like simple boundaries give better results.

http://maps.warwickshire.gov.uk/gs/wms?SERVICE=WMS&REQUEST=GetLegendGraphic&VERS
ION=1.1.1&FORMAT=image/png&WIDTH=16&HEIGHT=16&LAYER=Public_Data_DB:OS_BD_DIST_BO
R_WSHIRE

Problem is that it is a complex matter to determine the image size. Using <img 
did not work well, so using the GetLegend URL as CSS background image for each 
layer card DIV. 

Catch22? We need to make some progress. For preconfigured Layers we could try 
one of the above tricks with Styles, but this is also quite elaborate, plus all 
layers would need to be configured.

Any suggestions? At least we could make 'showPreview' configurable such that we 
at least can switch it off.

Original comment by jus...@gmail.com on 24 Mar 2014 at 2:02

[GoogleCodeExporter]

Got further:

- using additional Styles is not an option: won't work with raster layers 
(accepting only RasterSymbolizer)
- using WMS Attribution may work, but thus only for self-controlled 
preconfigured WMSs:
* define a WMS request showing a representative picture of the map, say: 
http://gis.kademo.nl/gs2/wms?LAYERS=kad%3Aopentopo&STYLES=&FORMAT=image%2Fpng&SE
RVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A28992&BBOX=179284.44793701,444
261.65649415,179681.17645263,444658.38500977&WIDTH=80&HEIGHT=80
* in GeoServer admin for Layer under tab "Publishing | WMS Attribution", enter 
the above GetMap URL (or any URL pointing to any image)
* Heron/WMSSource will check if the WMS Attribution Logo is present and show 
that image as preview
* see att.

Issues:
- Bug found in GeoServer: the Logo URL field does not accept long complex URLs. 
I solved it by using a URL shortener, like for the above: 
http://tinyurl.com/krzzd4o.
- in some cases the logo field may be populated with true attribution usually a 
real logo, but that is ok
- the Legend in the legendpanel does not know about the logo and will show the 
standard legend

So this may be reasonable for configured WMSs, adding any WMS URL is always a 
challenge as not all WMS are well-behaved anyway...

Original comment by jus...@gmail.com on 24 Mar 2014 at 8:04

Attachments:

• using-wms-attribution-logo.png

[GoogleCodeExporter]

Note to self: Another more simple idea, but again, only for preconfigured WMS 
sources: add a property 'previewExtent' with the bounding box that should be 
fetched by GetMap. Only problem is that some WMSes may have layers with objects 
in mutual exclusive areas, e.g. catholic and protestant churches in some 
cities/countries.

Original comment by jus...@gmail.com on 26 Mar 2014 at 1:56

[GoogleCodeExporter]

Thanks for the continued work Just.

> "- Bug found in GeoServer: the Logo URL field does not accept long complex 
URLs."

Did you report this bug? What's the GEOS number? It sounds like one we'd be 
able to get fixed using our support time for GeoServer.

> "- the Legend in the legendpanel does not know about the logo and will show 
the standard legend"
I'd imagine that's desirable isn't it? It's only on the "Add Layers" dialog 
that you'd want to show the attribution logo.

I do like the logo URL idea. I'd suggest using that in the first instance and 
falling back to the legend (maybe make it configurable?).
It also solves the WFS issue neatly.

Original comment by jonathan...@warwickshire.gov.uk on 28 Mar 2014 at 12:27

[GoogleCodeExporter]

> "- Bug found in GeoServer: the Logo URL field does not accept long complex 
URLs."

Did you report this bug? What's the GEOS number? It sounds like one we'd be 
able to get fixed using our support time for GeoServer.

==> No not yet, happens on 2.4.3. You may want to try as the current version is 
'attributionlogo' enabled.

> "- the Legend in the legendpanel does not know about the logo and will show 
the standard legend"
I'd imagine that's desirable isn't it? It's only on the "Add Layers" dialog 
that you'd want to show the attribution logo.

I do like the logo URL idea. I'd suggest using that in the first instance and 
falling back to the legend (maybe make it configurable?).

==> ok it is configurable in example/latest, as an ordered array of strategies 
to attempt: 
                    // First try 'attributionlogo' else fall back to 'getlegendgraphic'
                    owsPreviewStrategies: ['attributionlogo', 'getlegendgraphic']

                    // First try 'attributionlogo' else no preview
                    owsPreviewStrategies: ['attributionlogo'']

                   // no preview
                    owsPreviewStrategies: []
etc

You can try with the preconfigured Warwickshire historic WMS to add some 
attribution logo's and see if they pop-in in the example.

It also solves the WFS issue neatly.
==> right, but there is no WFSSource in GXP like there is TMSSource and 
WMSSource to fetch/collect MD, so that is still to implement.

Original comment by jus...@gmail.com on 28 Mar 2014 at 4:20

[GoogleCodeExporter]

Maybe pertinent:
https://jira.codehaus.org/browse/GEOS-6425

----

What was the URL you used for the logo? So I can see about replicating it.

Original comment by jonathan...@warwickshire.gov.uk on 31 Mar 2014 at 12:52

[GoogleCodeExporter]

This URL:

http://gis.kademo.nl/gs2/wms?LAYERS=kad:opentopo&STYLES=&FORMAT=image/png&SERVIC
E=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:28992&BBOX=179284.44793701,444261.65
649415,179681.17645263,444658.38500977&WIDTH=80&HEIGHT=80

fixed with URL shortener:
http://tinyurl.com/krzzd4o

Original comment by jus...@gmail.com on 31 Mar 2014 at 1:48

[GoogleCodeExporter]

That URL thing seems to work fine for me (using 2.5).
I basically just copied and pasted all the parameters/values:

http://wppgeog3/misc/icons/heatmap.png?LAYERS=kad:opentopo&STYLES=&FORMAT=image/
png&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:28992&BBOX=179284.44793701
,444261.65649415,179681.17645263,444658.38500977&WIDTH=80&HEIGHT=80

Original comment by jonathan...@warwickshire.gov.uk on 31 Mar 2014 at 3:52

[GoogleCodeExporter]

Yes, it works if one just pastes a URL. I was pointing at a maybe minor detail:
clicking on "Auto-detect image size and type" does not fill the input boxes 
below the logo URL like: "Logo Content Type" and "Image Width/Height". Looks 
like some error is generated. But the logo indeed is fetched in the Heron layer 
selection panel....

Original comment by jus...@gmail.com on 31 Mar 2014 at 4:03

[GoogleCodeExporter]

Small update: first stab at WFS support. Took a couple of days, given that 
there was no GXP WFSSource component, so created one in GXP. WFS is further a 
tough protocol with confusing, version-based metadata and multi-option 
encodings. Specifics:

- only WFS v1.1.0 with GML2 output gives repeatable results, GML3 fails on many 
WFSs (null namespaces e.g.)
- legends via attribution or other means are not possible (not in WFS 
metadata). Strategy 'randomcolor' gives random color preview image and layer 
color
- layer style editing not yet possible
- when layer added it is not enabled, as many WFS-es (and browsers/users) will 
suffer on getting the entire dataset
- works with WFS-es in different projections like EPSG:27770 (Proj code added 
in example) and EPSG:28992, no axis ordering hell yet. You may try the WCC WFS.

http://lib.heron-mc.org/heron/latest/examples/catalog/

Original comment by jus...@gmail.com on 2 Apr 2014 at 11:26

[GoogleCodeExporter]

Also WFS Vector Styling and WMS properties dialogs enabled.

Original comment by jus...@gmail.com on 2 Apr 2014 at 3:47

[GoogleCodeExporter]

We're fine if you just support WFS 1.1.0 with this. Support for the other 
versions you can leave for the future if you want.
Does WFS know what type of feature it is (point, line, polygon?) That would be 
useful information to convey if it does.

----
I tried with our WFS -it only works when very zoomed in. I suspect because 
there's no good set of EPSG:27700 coordinates for when zoomed out meaning I get 
this.

"    <ows:ExceptionText>java.lang.RuntimeException: Parsing failed for BBOX: 
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed 
linestring
Parsing failed for BBOX: java.lang.IllegalArgumentException: Points of 
LinearRing do not form a closed linestring
Points of LinearRing do not form a closed linestring</ows:ExceptionText>"

Looking at it, Heron is posting this:
"<gml:Envelope xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:27700">
<gml:lowerCorner>NaN NaN</gml:lowerCorner>
<gml:upperCorner>NaN NaN</gml:upperCorner>
</gml:Envelope>"

However, these layers all support WGS:84 and as that's the Heron project CRS, 
shouldn't that be the one that Heron requests? It's not an issue that's likely 
to affect us, but it may others.

Original comment by jonathan...@warwickshire.gov.uk on 3 Apr 2014 at 11:24

[GoogleCodeExporter]

We're fine if you just support WFS 1.1.0 with this. Support for the other 
versions you can leave for the future if you want.
Does WFS know what type of feature it is (point, line, polygon?) That would be 
useful information to convey if it does.

==> Most often yes, this is info in  DescribeFeatureType response not in 
GetCapabilities. Only the latter is used now. But strongly depends how data is 
configured. May also be generic "GeometryType". 

I tried with our WFS -it only works when very zoomed in. I suspect because 
there's no good set of EPSG:27700 coordinates for when zoomed out meaning I get 
this.

"    <ows:ExceptionText>java.lang.RuntimeException: Parsing failed for BBOX: 
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed 
linestring
Parsing failed for BBOX: java.lang.IllegalArgumentException: Points of 
LinearRing do not form a closed linestring
Points of LinearRing do not form a closed linestring</ows:ExceptionText>"

Looking at it, Heron is posting this:
"<gml:Envelope xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:27700">
<gml:lowerCorner>NaN NaN</gml:lowerCorner>
<gml:upperCorner>NaN NaN</gml:upperCorner>
</gml:Envelope>"

However, these layers all support WGS:84 and as that's the Heron project CRS, 
shouldn't that be the one that Heron requests? It's not an issue that's likely 
to affect us, but it may others.

==> Well, yes, saw the same for Dutch projection when zoomed out. One cannot 
rely that all WFSs support WGS84, hence took some trouble to use the SRS 
advertised in the Capabilities for that WFS-Layer. Other than WMS Capabilities, 
WFS only advertises a single, default SRS (not CRS) even if, like in GeoServer, 
multiple SRSs are configured. Another reason why WFS metadata is poor... A 
config option could be to always force WGS84 (EPSG:4326) for configured and/or 
all WFSs. 

Original comment by jus...@gmail.com on 4 Apr 2014 at 10:28

[GoogleCodeExporter]

I believe WGS:84 can be inferred as mandatory in the WFS spec so it should be 
possible to rely on it.

"If the crsuri is not specified then the 2-D coordinates shall be specified 
using decimal degrees and WGS84 as described in [15]." (from the WFS 1.1.0 
spec).

Although I can't see anything obvious to that effect in the 1.0.0 or 2.0.0 spec.
However WFS does provide a list of supported CRS's in the GetCapabilities, so 
that could be used to confirm WGS84 is there.

Thus the suggestion would be to go through this list of possiblities:
1 Use the same coordinate system as the project if supported/advertised by the 
server.
2 Use WGS84 is supported/advertised by the server.
3 ?? Use default coordinate system of server and hope for the best.

Ideally (2) should catch everything and nothing would ever need 3 except on 
very esoteric servers. This would allow international interoperation - useful 
for INSPIRE stuff. And for bonus points shouldn't require any special 
configuration by the user/implementer.

Original comment by jonathan...@warwickshire.gov.uk on 4 Apr 2014 at 10:51

[GoogleCodeExporter]

I'll get back to the WGS84 issue. Just added convenience buttons/fields in the 
catalogue panel toolbar:

See example:
http://lib.heron-mc.org/heron/latest/examples/catalog

- Search: text search within the current set of layers, via text and Enter or 
button. Empty text or clicking same search string twice brings back complete 
list.
- Sort: toggle ascending/descending sorting by title for layers

Original comment by jus...@gmail.com on 4 Apr 2014 at 2:19

[GoogleCodeExporter]

Both work very well!
The sort alphabetical has a couple issues:
- Some sort of icon-toggle to indicate when it's ascending/descending.
- The tooltip is larger than the tooltip backdrop.
- The button is wider than the text.
But I guess you're already on those anyway. :-)

Original comment by jonathan...@warwickshire.gov.uk on 4 Apr 2014 at 2:23

[GoogleCodeExporter]

@jm: For WCC WMS I get "Failed to load resource: net::ERR_NAME_NOT_RESOLVED" 
for the logo URL: http://wppgeog3/logo.png. This URL will work only locally. 
Maybe you can expand to full URL in GS attribution field?

Original comment by jus...@gmail.com on 4 Apr 2014 at 2:25

[GoogleCodeExporter]

That's definitely not supposed to be there! That logo just crept in during 
testing a long time ago (it's dated last July!). The fix will propagate by 
tomorrow morning. Thanks for the heads up.

(I'll see about coming up with a proper logo or two as well.)

Original comment by jonathan...@warwickshire.gov.uk on 4 Apr 2014 at 2:29

[GoogleCodeExporter]

Thought - what size logo's are you thinking of? If you're going to pull a full 
tile from TMS, that's 256*256. Would that be the max end? I guess there would 
be scaling as that seems quite large.

I ask to try and determine what size to use for my sample images to facilitate 
testing. Currently I'm looking at pulling a tile from our TMS which exemplifies 
some of the basemap layers.

Original comment by jonathan...@warwickshire.gov.uk on 4 Apr 2014 at 3:16

[GoogleCodeExporter]

This is configurable, like layerPreviewWidth. Default 20px which fits the 
default design. Scaling is done, always via CSS. It depends on the Source (WMS, 
WFS, TMS) and its config, how the preview image is fetched. e.e.g 
GetLegendGraphic requests layerPreviewWidth layerPreviewHeight but attribution 
takes URL as-is. TMS requests 256x256, WFS draws random color etc. 

Original comment by jus...@gmail.com on 7 Apr 2014 at 4:27

[GoogleCodeExporter]

replying at comment #36:

Although WFS 1.1.0 and higher support advertising multiple SRSs in the 
GetCapabilities (via xsd:element name="OtherSRS") , this is not supported in 
GeoServer. See several places, including:
http://osgeo-org.1560.x6.nabble.com/supported-crs-in-wfs-getCapabilities-td50659
26.html ;-)

So we only will have "DefaultCRS", in most cases. I propose to do the following:

1 Use the same coordinate system as the project (Map) if matching "DefaultCRS".
2 Use WGS84

Option 3) "use DefaultCRS and hope for the best", could be a config option at a 
later stage.
In a well-configured Heron-app with Proj4JS, any reprojection can be done 
locally.

Original comment by jus...@gmail.com on 8 Apr 2014 at 1:33

[GoogleCodeExporter]

New version available, see example: 
http://lib.heron-mc.org/heron/latest/examples/catalog

- Search/Sort button tooltip widths adapted

WFS Layer Projection now has options when adding WFS Layer from Catalog:

            // 1. Use the same coordinate system as the project (Map) if matching FeatureType "DefaultCRS".
            // 2. if defaultSrs NOT configured: use default value EPSG:4326
            // 3. if defaultSrs configured: then use that SRS, e.g. EPSG:27770
            // 4. if defaultSrs explicitly configured to null use record SRS , i.e. FeatureType "DefaultCRS"

Original comment by jus...@gmail.com on 8 Apr 2014 at 3:04

[GoogleCodeExporter]

> "Although WFS 1.1.0 and higher support advertising multiple SRSs in the 
GetCapabilities (via xsd:element name="OtherSRS") , this is not supported in 
GeoServer. See several places, including:"

I was confusing WFS and WMS. A poorly configured GeoServer lists thousands of 
SRS's withn the WMS Getcaps. i.e. - 
http://inspire.misoportal.com/geoserver/ows?service=wms&request=getcapabilities&
version=1.3.0

---

The new version looks good. I can't get it to connect to our TMS - projection 
mismatch - http://maps.warwickshire.gov.uk/gs/gwc/service/tms/1.0.0 - I guess 
because it needs data in 4326.
My suggestion would be to list in the results something that says "No 
compatible  layers found. Mismatched coordinate system." rather than an alert 
box. It will be far less confusing to users.

---

A further thought - how about autocomplete on the search layers box? As in, if 
you start typing something it starts autocompleting (like google searching or 
nomatim)?
I realise it's not in the quote but maybe it's fairly simple - all the data is 
already loaded in a list locally.

Original comment by jonathan...@warwickshire.gov.uk on 9 Apr 2014 at 9:46

[GoogleCodeExporter]

New version with better error handling for TMS errors.

Original comment by jus...@gmail.com on 10 Apr 2014 at 4:40

[GoogleCodeExporter]

New version with Layer search in gridpanel without Search button, but 
typeahead, i.e. like google searching or nominatim. Delay and minimal text 
length is configurable, default 500ms.:

    /** api: config[minTextSearchLength]
     *  ``Number``
     *  Minimal string length in text autosearch box.
     */
    minTextSearchLength: 2,

    /** api: config[textSearchQueryDelay]
     *  ``Number``
     *  `Delay before the search in the grid occurs, defaults to 500 ms.
     */
    textSearchQueryDelay: 500,

Was not quite trivial as textboxes do not have built-in delay etc like 
comboboxes...but better UX :-)

Original comment by jus...@gmail.com on 11 Apr 2014 at 2:51

[GoogleCodeExporter]

Looks good.

Issue noted when using TMS. Add layer - TMS -> Select one of the layers (i.e. 
OpenStreetMap) - It's added as an "overlays". TMS should be added as a 
baselayer. Probably selected by default too. WMTS too if/when that's 
implemented in the future.

Original comment by jonathan...@warwickshire.gov.uk on 11 Apr 2014 at 3:03

[GoogleCodeExporter]

Issue noted when using TMS. Add layer - TMS -> Select one of the layers (i.e. 
OpenStreetMap) - It's added as an "overlays". TMS should be added as a 
baselayer. Probably selected by default too. WMTS too if/when that's 
implemented in the future.

==> by default will have isBaseLayer: true and placed in group "background" 
(Base Layers). Is also configurable in case TMS overlays are needed.

Original comment by jus...@gmail.com on 13 Apr 2014 at 10:53

[GoogleCodeExporter]

Some enhancements:

- Added a Dutch example: http://lib.heron-mc.org/heron/latest/examples/catalognl
- TMS and WMS attribution preview images are scaled i.s.o. cropped
- added the OpacitySlider tool as a GXP plugin

Putting issue to Ready. 

Original comment by jus...@gmail.com on 14 Apr 2014 at 3:46

• Changed state: Ready