wms and global search

Permanently deleted user

15. Januar 2016 16:54

I am currently using GE 4.1 (4.01) with the Silverlight viewer (GVS) 2.2.  I have successfully loaded a WMS layer with a WFS Query provider in an Essentials Site.

 

I know I have everything configured correctly, but global searches do not work at all and queries only work when I use exact matches for string fields (suchs as workspace:layer = 'value'...I cannot use something akin to workspace:layer LIKE 'val%').

 

Global searches are giving me the common Java error of: Parsing failed for PropertyIsLike: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean java.lang.String cannot be cast to java.lang.Boolean. (Caught using Fiddler).  The same error appears when I try a LIKE expression in my where clause in a query.

 

I have actually gone to the Geocortex REST endpoint and tried the same "LIKE" query on the particular layer and I still get the same errors.  I have also tried the query against the layer in geoserver using CQL and the LIKE expression does NOT cause errors--it actually returns values.  So, I believe something is being lost in translation between the GVS and Geoserver.  (BTW, does GVS actually pass CQL to Geoserver in a query expression??  It seems like it should, but this is a mystery to me.)

 

Any ideas as to what is going on?

 

Thanks beforehand!

0

• 

  Stefan Schweigert

  20. Januar 2016 22:42

  Hello Michael,

   

  There is currently an issue filed regarding this in our system; I've added your name as a stakeholder. From our notes: The problem is the matchCase="false" attribute. The request succeeds if you remove it: <fes:PropertyIsLike matchCase="false" escapeChar="!" singleChar="_" wildCard="%">

   

  Without this attribute the query becomes case sensitive though. http://sourceforge.net/p/geoserver/mailman/message/32470384/ suggests that 'matchCase' is no longer supported at version 2.0.

   

  I hope this answers your question.

   

  Thanks, Stefan

  0
• 

  Permanently deleted user

  21. Januar 2016 16:42

  Stefan,

   

  Thanks for that reply.  I am still trying to figure all of this out...coming from the Esri world to OpenSource has a bit of a learning curve.

   

  Can you explain what is happening when I type a query into the global search when global search is configured against a wms/wfs layer?  Is the query being passed with the <fes:...> xml?

   

  Thanks,

   

  Michael

  0
• 

  Ryan Cooney

  21. Januar 2016 22:13

  This is what happens when you type something into the global search bar:

  1. The viewer finds all the layers in the application that are marked as searchable.
  2. For each searchable layer it assembles a SQL where clause using all the fields that are marked as searchable.
  3. The viewer then issues the query against that layer using the GeoREST specification.
  4. If the layer is an ArcGIS Server layer the query simply goes straight to ArcGIS Server where it is understood and resutls are sent back as JSON.
  5. If the layer is a WMS layer backed by a WFS the query is sent to Essentials using the GeoREST specification.
  6. Essentials then decomposes the where clause (and other query parameters) and reassembles it as the "equivalent" XML payload that the WFS will understand.
  7. Essentials gets back an XML/GML response from the WFS and translates that into a JSON response.

   

  A where clause like this: FirstName like ('bob%') OR LastName like ('bob%') becomes something like this: <fes:Filter ... <fes:Or> <fes:PropertyIsLike matchCase="false" wildCard="%" singleChar="#" escapeChar="!"> <fes:ValueReference>FirstName</fes:ValueReference> <fes:Literal>bob%</fes:Literal> </fes:PropertyIsLike> <fes:PropertyIsLike matchCase="false" wildCard="%" singleChar="#" escapeChar="!"> <fes:ValueReference>LastName</fes:ValueReference> <fes:Literal>bob%</fes:Literal> </fes:PropertyIsLike> </fes:Or> </fes:Filter>

   

  As Stefan pointed out we belive it is the matchCase attribute that is causing the trouble for some WFS implementations. The attribute is no longer part of the FES specification, so arguably the correct thing to do would be to take it out. However some WFS implementations continue to support it today and there is no suitable replacement for case insensitive matches. If we took it out we'd negatively affect some people. We'll see if there is a way to allow you to opt-in or out so that it will work for everyone.

   

  --Ryan

  0
• 

  Permanently deleted user

  25. Januar 2016 22:12

  Ryan,

   

  Thanks for all of that info!  That helps alot.

   

  Now I am wondering if it would be possible for me to develop a custom workflow to get around the current issue that you stated above?  Is there a current workaround that you could suggest at this time?

   

  Michael

  0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.