Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

A spatial search is similar to an attribute search, but uses the results of the search to then perform a geometry intersection search on another entity, which is the real target of the search.

So a spatial search works like this:

  • The user enters the search parameters and submits the search
  • The sever searches for the source entities that match the search parameters
  • The geometry of the found source entities are then used in a spatial search for the target entities
  • The selection for the target entities is then updated based on the spatial search

Namespace

urn:com.cohga.server.search.database#1.0

Tags

spatial

Properties

Name

Type

Required

Description

id

string

yes

unique identifier for this search

entity

ref urn:com.cohga.server.entity#1.0:entity

yes

The id of the entity that this search will be searching for

sourceEntity

ref urn:com.cohga.server.entity#1.0:entity

yes

The id of the entity that the search parameters apply to

label

string

yes

Text to be displayed to the user to represent this search

description

string

no

Description of the search that could be displayed to the user to explain this search

acl

ref urn:com.cohga.server.acl#1.0:acl

no

A reference to an ACL to attach to the search

Sub-tags

Name

Type

Cardinality

parameter

urn:com.cohga.server.search.database#1.0:parameter

1..n

acl

urn:com.cohga.server.acl#1.0:acl

0..1

cache

urn:com.cohga.server.cache#1.0:cache

0..1

Content

None

Notes

An ACL can either be defined in-line or referenced indirectly, but only one should be used (the in-line version will take priority)

parameter

Properties

Name

Type

Required

Default

Description

id

string

yes

 

A unique identifier for the parameter

label

string

yes

 

The prompt text displayed when user input the parameter value

column

string

yes

 

The name of the column within the table that this parameter references

displayname

string

no

label

Provides a user-friendly name for the element

helptext

string

no

 

Additional text to display for the parameter to explain how to use the parameter

hidden

boolean

no

false

Hides the parameter from the parameter UI

alignment

'left', 'center', 'right', 'auto'

no

'auto'

How the items should appear in the UI

controltype

'listbox', 'checkbox', 'radiobutton', 'textbox'

no

'textbox'

The suggested type of UI control to use when displaying the parameter

datatype

'any', 'boolean', 'datetime', 'decimal', 'float', 'integer', 'string'

no

'string'

The data type for the parameter

allownull

boolean

no

false

Whether a null value is allowed for this parameter

allowblank

boolean

no

true

Give the user the choice of an empty value in the listbox (as opposed to a null value)

allownewvalues

boolean

no

false

Allow the user to enter values not in the listbox already

defaultvalue

any

no

 

The default value of the parameter

displayformat

string

no

 

the formatting instructions for the parameter value within the parameter UI

dataset

ref urn:com.cohga.server.data.database#1.0:datadefinition

no

 

Where to get the values for a listbox

labelcolumn

string

no

 

Column in the datadefinition that supplies the label of the value to show the user

valuecolumn

string

no

 

Column in the datadefinition that supplies the value of the value to use in the SQL

uppercase

boolean

no

false

Should the value be converted to upper case in the generated SQL

Sub-tags

Name

Type

Cardinality

parameter

urn:com.cohga.server.data.database#1.0:parameter

0..n

Notes

  • If the controltype is listbox then a dataset must be provided, this dataset will provide the values to be displayed in the listbox.
  • If the listbox dataset only contains 1 column then that column will supply both the label and the value, if it contains two values then the first column will supply the label and the second the value.
  • If a parameter contains another parameter then you are defining a cascading parameter, where setting the first sub-parameter will enable, and filter, the second parameter, and setting the second parameter will do the same for the third, etc.
  • In a cascading parameter all sub-parameters must be of listbox type, and the dataset should be set in the outer parameter, not the sub parameters.
  • In a cascading parameter only one level of nesting should be used.
  • In a cascading parameter the dataset should supply the columns for all of the parameters, and valuecolumn properties should be set for each sub-parameter, and labelcolumn should be also set for all parameters if a different label is to be displayed to the user.

Examples

<data:datadefinition id="dd_wards">
	<datasourcedataconnection datasource="datasource.main" table="WARDS" prefix="DISTINCT">
		<parameter name="name" column="WARD_NAME"/>
		<parameter name="code" column="WARD_CODE"/>
	</datasourcedataconnection>
</data:datadefinition>

<search:attribute id="property.byward">
	<label>by Ward Boundary</label>
	<description>Locate a property or properties by ward</description>
	<entity>property</entity>
	<sourceentity>ward</sourceentity>
	<parameter id="ward">
		<dataset>dd_wards</dataset>
		<label>Road Name</label>
		<controltype>listbox</controltype>
		<column>CODE</column>
		<valuecolumn>code</valuecolumn>
		<labelcolumn>name</labelcolumn>
	</parameter>
</search:attribute>
  • No labels