Configure the search component to use exact phrase without the end user needing to add double quotes.
Terminée
RELEASED: Web 5.30
RELEASED: Web 5.14 (first changes were related to Geocoder results)
Geoocortex Web "Search" component searches each word separately So for example for 128 E Buffalo St, it'll be doing a query on the ArcGIS layer to find any features that have any of the words "128", "E", "Buffalo", or "St" in any fields. There was a bug filed for this at some point (#32004) and the resolution was to require double quotes. This is not feasible for end users. Please consider an option for the search component that can be configured from the designer, so that search uses the exact search phrase without needing the end-user to add double quotes".
-
Hate to state the obvious here but shouldn't the search just work exactly the same as the search box in ESRI apps and maps. I've used it for a few web apps over the years and it seems to be pretty solid in terms of it's wildcard searching and also grouping of results. (ex: header is layer name and results from the layer underneath).
In summary, agree, use of double quotes not good for end user. Thanks! :)
1 -
I'm planning to leave this here for a while. The idea here as presented would not give you the results you desire. Pretty much every search in the world breaks things into tokens and searches them independently and then returns a ranked order of results. Nothing wrong in the approach as long as we do it properly The solution is not to automatically wrap searches as "exact matches".
That said, Search has been flagged by a few users as not returning results the way one would expect, and you are right, based on user examples there is an issue. When fixed, search should once again "just work".
My statement above that the idea as presented here would not give you the results you would expect is because if you search for "128 E Buffalo St" the only way to get a hit is for the string to match that exactly "128 East Buffalo St" would not get a hit, nor would "128 E Buffalo Street", nor would "128 E Bufalo Street". The reason search engines break up, search, and reassemble into ranked results is so that the variants would still return the result near the top of the ranked list.
1 -
It would be great if the search could behave as it does in the geocortex html5 viewer, agol web map search, or web appbuilder. In all of these if the database you are searching contains a string exactly matching your search term, that is the only result you get. If there is no exact match, then a multitude of result options are presented.
Please have the GXW web search behave this way. Thanks!
2 -
Yes a pull-down search like AGOL would work just fine. I do understand that an improved search is coming in August? September? So will reserve judgment until after that.
1 -
Hi there!
I just wanted to post my thoughts here on search:
With the Esri 3.x api retirement we have been researching, planning, and testing VertiGIS Studio web functionality vs our current deployments of Essentials. We want to make sure we can give users at least the same functionality they have in Essentials with a new VSW application.
Currently, within our Essentials app, the users input what they wish to search on in the Global search input and it go through the geocoder and designated fields within many map layers and returns relevant results. However, when I do the same setup (geocoder + specific layer fields) in VSW it returns many seemingly irrelevant results.
After some searching, I found this: Understanding Search in Geocortex Web – VertiGIS Support and it appears that VSW evaluates the input and returns results a bit different than Essentials.
One simple scenario is a simple intersection search that our users perform very regularly. In Essentials, the users would simply input ‘SW 6th Ave & SW Main St’ (without quotes or anything else) hit return and essentials would prioritize the geocoder and it would return a few results stating that they are form the geocoder and they click on usually the top result, it zooms, done.
That same scenario in VSW will produce many results (with the same geocoder + layer search fields defined) because it’s searching on “SW”, “6th", “Ave”, "SW”, “Main”, “St”. We have an open text “Description” field that must be searched by our users that often has lot of values like the ones above but aren’t truly relevant. Essentials didn’t search this way, so users weren’t presented with those many potentially irrelevant results. VSW will produce many results with many ranked above what appears to be the geocoder result (because there might be a “SW” and an “Ave” mentioned in that aforementioned “Description” text field), unless the user either puts the entire search string in quotes or selects from the suggestion drop down.
This really isn’t the search experience we were planning on for simply moving from Essentials to VSW. I just want to verify that’s the intended search experience in VSW and if there are any other ways I can help narrow down results for the users (aside from quotes and search suggestion picks) or if there are any plans to change the VSW search experience.
Thank you!
1 -
Hi Cam Barnard, is this fixed? it says released in 5.14, but I'm on 5.26.2 and searching for a parcel PIN gives me way too many results of other PINs until I put it in quotes. Then I get the exact result. Is there a setting somewhere I need to flip? Andrew Oldham did you find any other ways to narrow down search results?
0 -
Chelsea Rozek unfortunately, no. From what I've gathered so far (and from Support) this is how the search is intended to operate in VSW.
0 -
thanks for the reply, though it's a bummer that's intended. I ended up making a workflow for search that just adds in the double quotes. I converted the default Search events to a workflow, then added in an "Evaluate Expression" before tasks.search with an expression of =$getWorkflowInputs.inputs.context.searchText='"'+$getWorkflowInputs.inputs.context.searchText+'"'
1 -
Greetings all. Wanted you to know I'm paying attention, and thought I'd give you some insight into what is planned, but also why things work the way they work.
First, we’ve heard you loud and clear. We are working on adding a setting to the Search component along the lines of “disable search string tokenization” that when enabled will treat your search string as if it was inside “ “. It may take a couple of releases to get this out, but it is coming.
---
If you are interested in more detail of why the existing behavior exists, and where it could be helpful, read on.
There are two distinct use cases for Search within a web GIS application.
The first use case is “I know it exists, just find it for me”. You are looking for a building, or an address, or an asset, or an inspection record and you are using Search to locate it so you can access additional information about it.
Most existing web GIS frameworks do a reasonable job of allowing this type of search.
The second use case is “I have no idea what exists, show me things that might match”. Is there a hydrant inspection with comments about rust?
Few (if any) web GIS frameworks allow for this more ‘what exists’ type of search.With VertiGIS Studio Web, we wanted to enable the second use case, while still making the first use case possible.
This is why Web’s default behavior is to ‘tokenize’ the search string and find a number of results which are then sorted by rank. If you want an exact match, you just enclose your search string in quotes. This matches how almost every major search interface on the Internet works today.
Said differently, you can go from a tokenized search to an exact search by putting quotes around it, but if the system default behavior is exact, there is no way to make it tokenized.
As a web GIS framework, VSW gets used to build different types of applications.
For customers building apps where their user base is mostly performing “I know it exists” searches, such as a property lookup app, they really wanted the behavior of a single exact match, and didn’t want their users to have to manually add “ “ around the search term.
The new config option will enable that without needing to work around existing behavior.
For customers building public facing apps with different types of data in it, we recommend leaving the “show me things that might match” default behavior as inexperienced users who don’t know what data exists are more likely to find what they are looking for that way.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
9 commentaires