...
Adding the index search input box to the client involves adding a new item to the UI, and that new item is called 'weave.indexcombo'. If we assume that we have a toolbar configured for our client and wish to add the index search box to that toolbar then we'd update the client configuration to something like:
| Code Block |
|---|
|
<toolbar>
<item component="weave.indexcombo"/>
</toolbar>
|
...
By default the index combo will only search for entities that match the currently active entity. To have the index search over all entities we can set a flag in the item to tell the client to ask for all matches, and if the user chooses an item that is not the same type as the currently active entity, then the active entity will be changed when the user chooses that entity. To do this we add a 'all' flag to the item tag and set its value to true, so we would then have:
| Code Block |
|---|
|
<toolbar>
<item component="weave.indexcombo" all="true"/>
</toolbar>
|
...
Beyond these settings it is also possible to change the stroke and fill of the geometry (if doGeometry is true) by adding a 'geometryStyle' tag to the configuration. The geometryStyle tag can set the fill and/or stroke used to draw the entity geometry when it is drawn on the client, but it will not change the style when drawing the selection.
| Code Block |
|---|
|
<toolbar>
<item component="weave.indexcombo" all="true">
<geometryStyle>
<strokeOpacity>0.75</strokeOpacity>
<strokeColor>#0000ff</strokeColor>
<strokeWidth>2</strokeWidth>
<fillOpacity>0</fillOpacity>
</geometryStyle>
</item>
</toolbar>
|
In addition, you can alter the tooltips that are displayed when the user enters the input area, and when they hover over the search button.
| Code Block |
|---|
|
<toolbar>
<item component="weave.indexcombo" all="true">
<geometryStyle>
<strokeOpacity>0.75</strokeOpacity>
<strokeColor>#0000ff</strokeColor>
<strokeWidth>2</strokeWidth>
<fillOpacity>0</fillOpacity>
</geometryStyle>
<tooltip>
<title>Quick Search</title>
<text>Type here to search</text>
</tooltip>
<tooltip2>
<title>Quick Search</title>
<text>Redisplay the last search results</text>
</tooltip2>
</item>
</toolbar>
|
...
If we look at an example of creating a simple index for roads where the user can search for a road in a suburb then we would need some supporting information available. Firstly we need the actual entity that we're going to be searching for and the spatial mapper that provided its geometry and would be something like:
| Code Block |
|---|
|
<!-- Create our roads entity -->
<entity:entity id="roads">
<label>Roads</label>
</entity:entity>
<!-- Link the roads entity to the ROADS layer in our spatial engine (not shown) -->
<mapper:mapper id="roads.mapper">
<spatialEngine>spatialEngine</spatialEngine>
<mapping>
<entity>roads</entity>
<table>ROADS</table>
<key>ROAD_ID</key>
</mapping>
</mapper:mapper>
|
Next we need a data definition that supplies the keywords and display fields, which could be separate data definitions, but we'll use the same one. An example of what our data definition may look like is as follows:
| Code Block |
|---|
|
<!-- Provide a road name, type and suburb based on ROAD_ID from the ROADS table -->
<data:datadefinition id="dd_index_roads">
<datasourcedataconnection datasource="datasource" key="ROAD_ID">
<prefix>DISTINCT</prefix>
<from table="ROADS"/>
<parameter name="name" column="NAME"/>
<parameter name="type" column="TYPE"/>
<parameter name="suburb" column="SUBURB"/>
</datasourcedataconnection>
</data:datadefinition>
|
Using the above information a simple index definition would look something like this:
| Code Block |
|---|
|
<index:entity id="index.roads">
<entity>roads</entity>
<display>
<datadefinition>dd_index_roads</datadefinition>
<level1>Road: ${name} ${type}</level1>
<level2>Suburb: ${suburb}</level2>
</display>
<keywords>
<datadefinition>dd_index_roads</datadefinition>
<level1>${name} ${type}</level1>
<level2>${suburb}</level2>
</keywords>
</index:entity>
|
...
So if we wanted our roads sorted so they're ordered by the suburb they're in followed by the road name then we could do the following:
| Code Block |
|---|
|
<index:entity id="index.roads">
<entity>roads</entity>
<display>
<datadefinition>dd_index_roads</datadefinition>
<level1>Road: ${name} ${type}</level1>
<level2>Suburb: ${suburb}</level2>
</display>
<keywords>
<datadefinition>dd_index_roads</datadefinition>
<level1>${name} ${type}</level1>
<level2>${suburb}</level2>
</keywords>
<sort>
<datadefinition>dd_index_roads</datadefinition>
<level1>${suburb} ${name}</level1>
</sort>
</index:entity>
|
Since the level in the sort works the same as the display and keywords it means that we can add additional text to the sort, and this can be used to our advantage to ensure that the order of the different types of entities found can be displayed to the user in a certain order. For example if we search enabled suburbs, roads and property addresses then we could use the sort field to ensure that suburbs are always listed first then followed by roads and then properties (regardless of how "well" the actual results match the search). To do this with our previous example we could change the level1 tag of the sort to
| Code Block |
|---|
|
<level1>0020 ${suburb} ${name}</level1>
|
...
As of version 1.8.17 of the com.cohga.server.index bundle you now have the ability to specify the weight values for individual records. As can be seen in the example below, the administrator can define a weights element inside the index comprising of a datadefinition and a value. The value is sourced from the datadefiniation in this case weight. The weight will be applied to the feature to increase it's score value when searching through the index.
| Code Block |
|---|
|
<index:entity id="index.roads">
<entity>roads</entity>
<display>
<datadefinition>dd_index_roads</datadefinition>
<level1>Road: ${name} ${type}</level1>
<level2>Suburb: ${suburb}</level2>
</display>
<keywords>
<datadefinition>dd_index_roads</datadefinition>
<level1>${name} ${type}</level1>
<level2>${suburb}</level2>
</keywords>
<weights>
<datadefinition>dd_index_roads</datadefinition>
<value>${weight}</value>
</weights>
<sort>
<datadefinition>dd_index_roads</datadefinition>
<level1>${suburb} ${name}</level1>
</sort>
</index:entity>
|
...
The first format has a single line for each group of synonyms with the alternatives separated by a comma, for example:
| Code Block |
|---|
| none |
|---|
| none |
|---|
| linenumbers | truenone |
|---|
|
ST,STR,STREET
|
And the seconds format has the original word followed by an equals sign and a space separated list of alternatives, for example:
| Code Block |
|---|
| none |
|---|
| none |
|---|
| linenumbers | truenone |
|---|
|
abandon=vacate
revoke=vacate
vacate=abandon revoke
|
To add synonyms to an index you must add at least one 'synonyms' tag to the index and rebuild the index.
| Code Block |
|---|
|
<index:entity id="index.roads">
<entity>roads</entity>
<display>
<datadefinition>dd_index_roads</datadefinition>
<level1>Road: ${name} ${type}</level1>
<level2>Suburb: ${suburb}</level2>
</display>
<keywords>
<datadefinition>dd_index_roads</datadefinition>
<level1>${name} ${type}</level1>
<level2>${suburb}</level2>
</keywords>
<synonyms>street.txt</synonyms>
</index:entity>
|
...
So at the OSGi console you can use 'is' to see what indexes are currently registered in Weave
| Code Block |
|---|
| none |
|---|
| none |
|---|
| linenumbers | truenone |
|---|
|
osgi> is
Weave Index Service
Index Id Entity Count Locked Modified
0 index.roads roads N/A N/A N/A
|
From this we can see that the 'index.roads' index has not actually been built, from here we can use the 'ib' command to build the index (assuming we haven't setup a schedule that would build the index for us)
| Code Block |
|---|
| none |
|---|
| none |
|---|
| linenumbers | truenone |
|---|
|
osgi> ib 0
Building index for 0
Processing index index.roads
Indexing non-unique features from ROADS based on ROAD_ID
...
Total time to build index index.roads 32468ms
osgi> is
Weave Index Service
Index Id Entity Count Locked Modified
0 index.roads roads 166131 false 19/05/09 11:10
|
And then we can actually test our index without having to start the client
| Code Block |
|---|
| none |
|---|
| none |
|---|
| linenumbers | truenone |
|---|
|
osgi> it "cameo ct" 1
Raw Query: +(keywords_1:cameo^21.0 keywords_2:cameo^16.0 keywords_3:cameo^11.0 keywords_4:cameo^6.0 keywords_5:cameo) +(keywords_1:ct^21.0 keywords_2:ct^16.0 keywords_3:ct^11.0 keywords_4:ct^6.0 keywords_5:ct)
Start search results for cameo ct
Start result 0
Score: 14.316717
Entity: roads
Id: 45132
Display 1: Road: CAMEO CRT
Display 2: Suburb: BULLEEN
Keyword 1: CAMEO CRT COURT CT
Keyword 2: BULLEEN
End result 0
End search results
|
...