nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

searching adresses requires the whole, exact phrase

DominikaBujanowicz

for a few weeks i have a problem in my application that was made in Web AppBuilder. While searching adresses in "near me" widget it recquires the exact name of the adress. Earlier, it was possible to enter only a part of street and a lot of examples were shown. Right now, I have to enter all the letters from the street segment instead of this main segment that is, for example, the name of the street patron. I know there is an option to turn on/off "exact match" but its not working. there is no difference whether its on or off.

Maybe it's the fault of some AGOL update...

It is like that:

Earlier it was possisble to find that adress by entering only this: (it says "no results")

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

RussRoberts

We recently made a change to improve search result performance and improve overall stability. I cover the improvements and changes in this blog:

https://www.esri.com/arcgis-blog/products/arcgis-online/mapping/searching-for-features-in-maps-and-apps/

If you are using Web AppBuilder there is an update coming in the next day to fully leverage the new full-text indexes. The blog covers how you can build these indexes by configuring a feature search in a web map on your hosted layer.

GreggRoemhildt2

So...this is a pretty big change, if I configure a field in the map viewer like this:

you've effectively changed the meaning of "Contains" it no longer means "Contains" and is in fact more of a "starts with" query. We now have now way to search for tax payer names by last name in this situation.

Maybe you can provide a workaround to achieve this capability @RussRoberts ?

RussRoberts

If you are using hosted and you are authoring a feature search post November release this will generate an index. If you are experienced with doing addToDefinition you can create the indexes this way. The index will then let you search any term within the defined field.

If no index exists then the search is then a starts with. This means it is no longer '%searched characters%' being sent to the service but is instead 'searched characters%'. If you want to use the leading % in a search you can enter that in the search widget and it will be treated like the old search.

We had to make this change to bring in performance improvements and hive stability. In testing we had samples where old search could take 5-10 seconds to return a result and then the index method returns results in sub second. Then the other factor was when we had content using the double wildcard search and search suggestions on layer-based searching. This also can become very expensive with increased search usage, # of characters being used in the search along with the number of characters in a field being searched. this then can lead to causing disruptions to your content.

GreggRoemhildt2

Thanks for that explanation! That makes a lot more sense now, I can see how users adding 10...20, 100 layers and expecting search to work on all of them could bring performance issues.

maybe you're already considering this but maybe adding a GUI to give users an option to add an index to fields to help get the capability back would be helpful. I'm not super familiar with addToDefinition but could figure it out, however, i know a lot of folks would not be able to get that far.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.