"search" feature in App Builder

[SeanGambrel]

Hi all,

We are in the process of upgrading our server from 9.3 to 10.3, and I am attempting to re-create our flex apps using the App Builder.  We are running a federated server and I am building apps via Portal.  The first thing I noticed is with App Builder is that there is no "search by attributes" functionality, which is really the fundamental use in all of our flex apps.  Typically users start by searching an address (located in an attribute field) or a facility ID #.  Essentially users enter a value and the attribute table is searched and matching features are highlighted...

Regardless, this functionality does not appear to be there  "out-of-the-box", though one can configure the Query widget or use the Geocoding widget to approximate it.  I started with the Query widget, thinking it would be the easiest to set up and maintain, however there is some bug or problem with the data that I and Tech support cannot figure out.  So I'm now looking at using the Geocoding widget to perform the search task.

In researching this, I am a little confused and hoped some of you could verify my understanding of the situation.  As I understand it:

1.  in order to use the geocoding widget, I will need to build a locator for each field and feature class I want to search.  These different locators will be able to be selected via drop-down in the entry box of the geocoding widget.  So for instance, if I want users to be able to search by Property ID, Owner Name, and Place name, I will need to build three locators for this one widget.  Is this correct?

2.  I've only built an address locator once and it was a long time ago.  In reading through the resources, it seems like any locator that is built is considered an "address locator", even though it may use an attribute field instead of geometry to identify a feature.  Is this correct or do I need to be looking at something else?  For instance I may need to have manholes "searchable" by manhole ID number, which actually has little to do with geography.  And "address locator" doesn't sound like the correct tool for this purpose.

3.  As values in the attribute table (or a joined table) change, does the locator need updated manually, or will it always read the data dynamically?

Thanks for the input.  This is a bewildering workflow for what should really be out of the box functionality...  

Sean  

[SeanGambrel]

Hi Ryan,

I'd like to try this out!  I've not created a database view before, perhaps you can give me a nudge in the right direction?  I have a few questions:

1.  You say this is created "for the mapservice" - but just to clarify, this is something that you create in SDE, not in a map document, correct?
2.  What kind of view did you build?  Was it a true database view or a spatial view or a versioned view?

3.  If the geometric data is going to be continually edited (but the table is static), will this impact which kind of view I need to create?  Will the geometric data still be editable (via version)?

Thank you Ryan (and everyone else who's chimed in)!

Sean

[deleted-user-HSuL64f_Zmut]

Hi Sean,

1) & 2) Correct. I used the Create Database View tool in ArcCatalog to create the view in the SDE. You can find it in the toobox under Data Management Tools > General > Create Database View. This tool asks for the Input Database Connection, Output View Name, and View Definition. I think your feature class and table need to be in the same database. If your not proficient at SQL you may want to consult your DBA to help write the definition. The View Definition for my database view looked like this example...

CREATE VIEW VIEWNAME AS SELECT        TEST.FIELDNAME1, TEST.FIELDNAME2, TEST.FIELDNAME3, TEST.FIELDNAME4, TEST.FILEDNAME5, TEST.FIELDNAME6, TEST.FIELDNAME7, TEST.FIELDNAME8, Spatial.*

FROM            FEATURECLASSNAME AS Spatial INNER JOIN

                        SDETABLENAME AS TEST ON Spatial.FIELDNAME1 = TEST.FIELDNAME1

Once the view was created I recreated my map service MXD, pointing to the view, and then republished it. If you try to re-point the source in your original map service MXD to the view you may run into issues, better to just recreate it.

3) Editing the geometric data will still be done through the feature class (not the view) and should not impact your view. My geometric data is not versioned, it is updated through an FME process once a week. My table is updated daily by another department. This did not cause any issue with the view.

Good luck!

Ryan

[SeanGambrel]

Hi Ryan,

Well, this is getting a little advanced for me, but I'm not afraid to tinker.

So in the definition above, I'm confused about the "TEST" prefix on all of the fields.  Do I leave that as-is, or is it a temporary value, or am I supposed to replace that with a value from my own database?  And, "FIELDNAME1" is the join field (for both the table and geometry), and "Fieldname2-8" are the fields from the table that I want joined to the geometry?

So would my query look like this, for instance:

CREATE VIEW JOINEDPARCELS AS SELECT       

TEST.ACCOUNT, TEST.MAP_LOT, TEST.PROP_ADDRS, TEST.OWNER, TEST.ACRES, spatial.*

FROM            PARCELPOLY AS Spatial INNER JOIN

                       PARCELTABLE AS TEST ON Spatial.ACCOUNT = TEST.ACCOUNT

Again, thank you for the help!

[deleted-user-HSuL64f_Zmut]

You are correct in your assumption, "TEST" is just a placeholder. And "FIELDNAME1" represents the join field from both the feature class and the table. In the example they are the same name but could vary in your actual data. "FIELD2-8" are the names of the fields from your table you want to join to the feature class. I believe you got it right.

[SeanGambrel]

Hi Ryan,

Thank  you so much for all the help so far.  I don't want to consume any more of your time, but I'm not having an success.  Would you mind looking at my definition below and see if anything basic really jumps out at you?
  

PARCELSJOIN = name of the view I'm creating

gisdata.GISADMIN.PARCELS = geometry

gisdata.GISADMIN.PARCELDATA = table

TEST = temporary value, as you mentioned above.

CREATE VIEW PARCELSJOIN AS SELECT TEST.ACCOUNT, TEST.MAP_LOT, TEST.OWNER1,  TEST.OWNER2,  TEST.OWNER_ADD1, TEST.OWNER_ADD2, TEST.OWNER_ADD3, TEST.OWNER_ADD4, TEST.OWNER_ADD5, Spatial.*

FROM gisdata.GISADMIN.PARCELS AS Spatial INNER JOIN gisdata.GISADMIN.PARCELDATA AS TEST ON Spatial.TAX_ACCT = TEST.ACCOUNT

Any thoughts?

[JacobKohute]

Ahh  yes..the dreaded join issue. That's been around for a while in different forms with different apis. Have you ever done a composite geocoder, it's one built off multiple individual geocoders. I'm using one currently for our geocoder. It looks at an address range and an address point geocoder. If you were to build one that looked for Owner Name, one that looked for parcel number, etc etc. then build a composite using those, publish it perhaps it would get you the results you wanted.

[SeanGambrel]

Interestingly, Jacob, I attempted to build a geocoder that looked at Property Address (values from a field, not a geometric locator), but it couldn't be built with our data for some reason that's still a bit unclear to me.  Again, I engaged Tech Support on this issue and the reason they gave is that the data didn't have enough parameters or something to that effect.  I'm still waiting to hear back if they have another solution.  I'm really striking out here.  

[JacobKohute]

Wow you’re hitting walls. Not enough parameters is a little weird. Did you try a single line geocoder? That takes a single field as input.

Thanks,

Jacob

[SeanGambrel]

Yup.  Single line geocoder wouldn't build.  Walked through it with support in a few different configurations.  I suspect its the join again.