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 8 Next »

A spatial mapper links an Entity to a Spatial Engine. This linkage is not required and in fact, may not be possible if there is no spatial information associated with the entity.
If there is spatial information that relates to the entity and you want the users to be able to perform spatial operations (select by polygon, etc.) on the entity then a link should be set up.

The mapping is actually between the entity and an object that is managed by a spatial engine. The type of object will be different depending upon the spatial engine. For example, if the spatial engine is ArcSDE then the mapping will be between the entity and an ArcSDE Layer, for Oracle Spatial it will be between the entity and a spatially enabled table.

When adding a definition for a spatial mapping, the setup will be the same regardless of the spatial engine type but the "name" of the spatial object may be different. For example, a shapefile based spatial engine will refer to the spatial objects based on the filename which may be case sensitive depending upon the underlying operating system, but an Oracle Spatial engine will refer to a table name which may need to be fully qualified when a schema.

The spatial mapping also specified which column in the underlying table is used to uniquely identify an entity, this is set with the key attribute.
Because the key used by Weave to identify an entity may be different from that used by the underlying spatial entity to identify a feature there has to be a mapping performed between the Weave keys and the spatial engine feature ids.
Generally, this mapping is performed once at system startup and doesn't change unless Weave notices a change in the count of the available rows in the underlying table (which is checked every five minutes). This is assuming that the underlying keys/feature ids don't change and only the addition/removal of a row in the table would have an effect on the key mapping.

However there may be times when this is not suitable, for example, if the table if very large it can take a long time to read all of the key mappings and they can take up a large amount of memory, or if the key mappings do actually change frequently, so this initial key mapping can be disabled and the mapping between the Weave keys and the spatial engine feature ids can be performed on-the-fly each time Weave needs to transform a key to a feature id, or a feature id to a key. Obviously, this will have an impact on performance, since it requires a trip to the spatial engine for each transform, rather than having it done once and the transform performed in memory.

The initial loading of the key/fid mapping can be disabled, for either all spatial mappings in a spatial mapper or for a single spatial mapping, by setting the dynamic flag in the configuration.

In addition, if dynamic mapping is turned on you can indicate that the values retrieved from the spatial engine for a mapping should be kept in memory to avoid the cost of querying the spatial engine next time the mapping is required, this is done by setting the cache flag in the configuration. This can be useful if you want to avoid the longer startup time but the key/fid mappings are still fairly static (so it's safe to have them loaded once). This provides a middle ground, if suitable, between a static, loaded at startup, key/fid mapping, and a dynamic, performed each time, key/fid mapping.

Namespace

urn:com.cohga.server.spatial.mapper#1.0

Tags

mapper

Properties

Name

Type

Required

Description

id

string

yes

unique identifier

spatialEngine

ref urn:com.cohga.server.spatial.geotools#1.0:spatialEngine

yes

The identifier of the spatial engine that the mappings should link to

crs

string

no

The CRS to override for entities that don't provide an explicit value

filter

string

no

Provide a CQL formatted filter to apply when performing spatial operations with this mapper

dynamic

boolean

no

Should the key/fid transform be performed on each lookup

cache

boolean

no

Should dynamically looked up key/fid transforms be cached in memory

Sub-tags

Name

Type

Cardinality

Description

mapping

urn:com.cohga.server.spatial.mapper#1.0:mapping

1..n

A collection of mappings that link entities to spatial items

Content

None

Notes

  • The CRS property does not perform any transform, it just tells the server how the actual data is stored in cases where the underlying spatial engine does not supply this information or supplied an incorrect value.

mapping

Properties

Name

Type

Required

Description

entity

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

yes

The identifier of the entity that this mapping applies to

table

string

yes

The name of the spatial item within the spatial engine that this mapping applies to

key

string

no

The attribute of the spatial item that uniquely identifies an entity

crs

string

no

Provide a Coordinate Reference System if the underlying spatial engine doesn't provide the correct information

filter

string

no

Provide a CQL formatted filter to apply when performing spatial operations with this mapping

dynamic

boolean

no

Should the key/fid transform be performed on each lookup

cache

boolean

no

Should dynamically looked up key/fid transforms be cached in memory

uniquebooleannoTells Weave that the key values will be unique, so that it doesn't have to check for itself. Weave can optimise the handling of spatial selections if the keys are unique, if you know the keys are unique you can set this to true and Weave will not need to pre-check for itself.

Sub-tags

Name

Type

Cardinality

Description

mapping

urn:com.cohga.server.spatial.mapper#1.0:mapping

0..n

If more that one underlying feature maps to the entity then multiple sub-mapping tags can be used to specify additional mappings

Content

None

Notes

  • The CRS property does not perform any transformation, it just tells the server how the actual data is stored in cases where the underlying spatial engine does not supply this information or supplied an incorrect value.
  • Only 1 level of nesting is supported for sub-mappings.
  • Only table and key are allowed in sub-mapping tags.
  • Only table is required, key can be inferred from the parent mapping.

Examples

Basic spatial mapping setup
<mapper:mapper id="mapper.arcsde">
	<spatialEngine>spatialengine.arcsde</spatialEngine>
	<mapping>
		<entity>property</entity>
		<table>PROPERTY</table>
		<key>PID</key>
	</mapping>
	<mapping>
		<entity>roads</entity>
		<key>RD_NAME</key>
		<mapping>
			<table>MAJOR_ROADS</table>
		</mapping>
		<mapping>
			<table>MINOR_ROADS</table>
		</mapping>
	</mapping>
	<mapping>
		<entity>suburbs</entity>
		<table>SUBURBS</table>
		<key>LOC_NAME</key>
	</mapping>
	<mapping>
		<entity>council_buildings</entity>
		<table>BUILDINGS</table>
	</mapping>
</mapping>
<mapper:mapper id="mapper.oracle">
	<spatialEngine>spatialengine.oracle</spatialEngine>
	<mapping>
		<entity>drainage</entity>
		<table>DRAINAGE</table>
	</mapping>
</mapper:mapper>
Spatial mapping for dynamic data
<mapper:mapper id="mapper.edit">
	<spatialEngine>spatialengine.arcsde</spatialEngine>
	<mapping>
		<entity>grafitti</entity>
		<table>GRAFITTI</table>
		<key>PID</key>
		<dynamic/>
	</mapping>
</mapper:mapper>
Mapping with a filter
<mapper:mapper id="mapper.main">
	<spatialEngine>spatialengine.arcsde</spatialEngine>
	<mapping>
		<entity>property</entity>
		<table>PROPERTY</table>
		<key>PID</key>
		<filter><![CDATA[status = 'C']]></filter>
	</mapping>
</mapper:mapper>

Filters

Simple filters
<filter>lga_code == 0</filter>

<filter><![CDATA[lga_code <> 0]]></filter>

<filter><![CDATA[planno = 'LP129263']]></filter>

<filter><![CDATA[planno LIKE 'LP%']]></filter>

<filter><![CDATA[planno NOT LIKE 'LP%']]></filter>

<filter>further_de IS NULL</filter>

<filter>further_de IS NOT NULL</filter>
Geometry filters
<filter><![CDATA[CROSS(the_geom, LINESTRING(332312 5815856, 333688 5823904))]]></filter>

<filter><![CDATA[CROSS(the_geom, LINESTRING(332312 5815856, 333688 5823904)) OR CROSS(the_geom, LINESTRING(331312 5814856, 332688 5822904))]]></filter>

<filter><![CDATA[BBOX(the_geom, 332312,5815856,333688,5816856)]]></filter>

Other Filters

Geometry filter, only works with units stored in the database
<filter><![CDATA[DWITHIN(the_geom, POINT(331899 5818553), 500, meters)]]></mapper:filter>
Geometry filter, only works with units stored in the DB
<filter><![CDATA[BEYOND(the_geom, POINT(331899 5818553), 500, meters)]]></filter>
Geometry filter with collection. Does not work in PostGis as it does not like geometry collections, not tested in other spatial engines
<filter><![CDATA[INTERSECT(the_geom, GEOMETRYCOLLECTION(LINESTRING(332312 5815856, 333688 5823904), LINESTRING(333312 5815856, 334688 5823904)))]]></filter>
  • No labels