|
1
|
<!--
|
|
2
|
* spatial_option.html
|
|
3
|
*
|
|
4
|
* Authors: Matthew Perry
|
|
5
|
* Copyright: 2006 Regents of the University of California and the
|
|
6
|
* National Center for Ecological Analysis and Synthesis,
|
|
7
|
* and the University of New Mexico.
|
|
8
|
* For Details: http://www.nceas.ucsb.edu/
|
|
9
|
* Created: 2006 December 29
|
|
10
|
* Version:
|
|
11
|
* File Info: '$ '
|
|
12
|
*
|
|
13
|
*
|
|
14
|
-->
|
|
15
|
<HTML>
|
|
16
|
<HEAD>
|
|
17
|
<TITLE>Metacat Spatial Option</TITLE>
|
|
18
|
<link rel="stylesheet" type="text/css" href="./default.css">
|
|
19
|
<style>
|
|
20
|
h5 { margin-left: 12px; }
|
|
21
|
</style>
|
|
22
|
</HEAD>
|
|
23
|
<BODY>
|
|
24
|
<table width="100%">
|
|
25
|
<tr>
|
|
26
|
<td class="tablehead" colspan="2">
|
|
27
|
<p class="label">Metacat Spatial Option</p>
|
|
28
|
</td>
|
|
29
|
<td class="tablehead" colspan="2" align="right">
|
|
30
|
<a href="./properties.html">Back</a> |
|
|
31
|
<a href="./metacattour.html">Home</a> |
|
|
32
|
<a href="./unimplem.html">Next</a>
|
|
33
|
</td>
|
|
34
|
</tr>
|
|
35
|
</table>
|
|
36
|
<h4>Introduction</h4>
|
|
37
|
The Metacat spatial option enables you to query and visualize the geographic coverage of metacat documents.
|
|
38
|
This document is intended to provide a high-level overview of the Metacat spatial functionality. It is primarily a resource for users and developers who want to understand the architecture before digging into the code to extend the existing functionality.
|
|
39
|
<P>
|
|
40
|
Although the spatial option is included with a Metacat installation (beginning with
|
|
41
|
Metacat version 1.7.0), it is an extention to Metacat's functionality
|
|
42
|
that may be used optionally.
|
|
43
|
</P>
|
|
44
|
<h4>Outline</h4>
|
|
45
|
<ul>
|
|
46
|
<li> <a href="#definitions">Defintion of Terms</a> </li>
|
|
47
|
<li> <a href="#overview"> Overview of the major components </a>
|
|
48
|
<ul>
|
|
49
|
<li> <a href="#spatial_harvester"> Spatial Harvester </a> </li>
|
|
50
|
<li> <a href="#wms"> Web Mapping Service </a> </li>
|
|
51
|
<li> <a href="#spatial_query"> Spatial Query </a> </li>
|
|
52
|
<li> <a href="#html_client"> HTML Mapping Client</a> </li>
|
|
53
|
</ul>
|
|
54
|
</li>
|
|
55
|
<li> <a href="#install">Installing and Configuring the Spatial Option</a> </li>
|
|
56
|
<li> <a href="#adding_data">Adding Other Spatial Datasets to the Web Map</a> </li>
|
|
57
|
<li> <a href="#dev">Developers Notes</a> </li>
|
|
58
|
<li> <a href="#future">Future Directions</a> </li>
|
|
59
|
|
|
60
|
</ul>
|
|
61
|
|
|
62
|
<h4> <a name="definitions">Definitions</a></h4>
|
|
63
|
The following table defines a number of terms that are useful in discussing
|
|
64
|
Harvester and its features.
|
|
65
|
<br><br>
|
|
66
|
<table border="1">
|
|
67
|
<tr>
|
|
68
|
<td><b>Term</b></td>
|
|
69
|
<td><b>Definition</b></td>
|
|
70
|
</tr>
|
|
71
|
<tr>
|
|
72
|
<td>Spatial Cache</td>
|
|
73
|
<td>
|
|
74
|
A cached version of the metacat documents representing their geographic coverages in a GIS-compatible data format; the ESRI Shapefile.
|
|
75
|
</td>
|
|
76
|
</tr>
|
|
77
|
<tr>
|
|
78
|
<td>Web Mapping Service (WMS)</td>
|
|
79
|
<td>
|
|
80
|
A standard interface specification for requesting spatial data as a web-deliverable map image. WMS servers accept a common set of parameters via http, render the spatial dataset into an appropriate image and deliver it back to the client. The <a href="http://www.opengeospatial.org/standards/wms">WMS spec</a> was developed by the <a href="http://www.opengeospatial.org/">Open Geospatial Consortium</a>.
|
|
81
|
</tr>
|
|
82
|
<tr>
|
|
83
|
<td>Bounding Box (BBOX)</td>
|
|
84
|
<td>
|
|
85
|
A Bounding Box is two sets of geographic coordinates representing the full geographic extent of an entity; the minimum lat/long (the lower-left) and the maximum lat/long (the upper-right).
|
|
86
|
</td>
|
|
87
|
</tr>
|
|
88
|
<tr>
|
|
89
|
<td>Spatial Dataset</td>
|
|
90
|
<td>
|
|
91
|
A collection of <em>spatial features</em> in a common datastore.
|
|
92
|
</td>
|
|
93
|
</tr>
|
|
94
|
<tr>
|
|
95
|
<td>Spatial Features</td>
|
|
96
|
<td>
|
|
97
|
Analagous to a "row" in a tabular dataset, a feature is an entity comprised of both tabular attributes and a <em>spatial geometry</em>.
|
|
98
|
</td>
|
|
99
|
</tr>
|
|
100
|
<tr>
|
|
101
|
<td>Spatial Geometry</td>
|
|
102
|
<td>
|
|
103
|
The geometry is a vector representation of an entities' geographic location. This can be a point (a single vertex), line (a series of vertices) or polygon (a series of vertices forming a closed area).
|
|
104
|
</td>
|
|
105
|
</tr>
|
|
106
|
<tr>
|
|
107
|
<td>Multi-Geometry</td>
|
|
108
|
<td>
|
|
109
|
A <em> Spatial geometry </em> represented by one or more geometry primitives (points,lines and polygons). For example a single species census (the <em> spatial feature </em>) might have mutltiple sample sites and could be represented as a multi-point geometry.
|
|
110
|
</td>
|
|
111
|
</tr>
|
|
112
|
<tr>
|
|
113
|
<td>Styled Layer Descriptor (SLD)</td>
|
|
114
|
<td>
|
|
115
|
Styled Layer Descriptors are an OGC standard for defining the filtering, classification and styling of datasets. They are essentially the configuration file which describes how to convert your raw spatial dataset into a cartographic product.
|
|
116
|
</td>
|
|
117
|
</tr>
|
|
118
|
<tr>
|
|
119
|
<td>Web Map Context (WMC)</td>
|
|
120
|
<td>
|
|
121
|
Web Map Context documents are an OGC standard for combining various WMS layers into a coherent map. WMC describes which wms servers and layers comprise the map, the layer order, the initial map extent, the requested image formats, etc. This is used by the HTML web map client to construct the interactive map.
|
|
122
|
</td>
|
|
123
|
</tr>
|
|
124
|
</table>
|
|
125
|
|
|
126
|
<h4><a name="overview">Overview Of the Major Components<a/></h4>
|
|
127
|
|
|
128
|
|
|
129
|
<h5> <a name="spatial_harvester"> Spatial Harvester </a> </h5>
|
|
130
|
|
|
131
|
|
|
132
|
|
|
133
|
|
|
134
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The Spatial Harvester component syncs the metacat database with the spatial cache (an ESRI shapefile which contains the geographic coverages of the documents). </span></p>
|
|
135
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The Spatial Harvester is implemented entirely in Java using the Geotools library which allows manipulation of spatial datasets. In rough terms, a spatial dataset is a collection of Features which are comprised of a geometry (i.e. the geographic coverage) and associated attributes (i.e. the document's title).</span></p>
|
|
136
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> There are a number of Java classes which, collectively, make up the spatial harvester functionality. They are found in the </span><span style="font-style:italic" lang="en-US">edu.ucsb.nceas.metacat.spatial</span><span lang="en-US"> package:</span></p>
|
|
137
|
<ul>
|
|
138
|
<li style="margin-bottom:12pt"><span lang="en-US"> </span><span style="font-weight:bold" lang="en-US">SpatialDataset</span><span lang="en-US"> : Provides read/write access to the spatial cache.</span></li>
|
|
139
|
<li style="margin-bottom:12pt"><span lang="en-US"> </span><span style="font-weight:bold" lang="en-US">SpatialDocument</span><span lang="en-US"> : Represents the geographic coverage of a document as a Geotools Feature. </span></li>
|
|
140
|
<li style="margin-bottom:12pt"><span lang="en-US"> </span><span style="font-weight:bold" lang="en-US">SpatialFeatureSchema</span><span lang="en-US"> : A class of static memebers defining the properties of the spatial cache (location on the file system, attribute and geometry schemas, etc.)</span></li>
|
|
141
|
<li style="margin-bottom:12pt"><span lang="en-US"> </span><span style="font-weight:bold" lang="en-US">SpatialHarvester</span><span lang="en-US"> : The high-level interface for manipulating the spatial cache and initiating the harvesting process.</span> </li>
|
|
142
|
</ul>
|
|
143
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"></p>
|
|
144
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The spatial cache currently represents the geographic coverage of XML documents based on a bounding box. The four bounding coordinates (either latitudes or longitudes) can be specified in the metacat.properties file by their xpaths. For example, the geographic coverage of EML documents is defined as:</span></p>
|
|
145
|
|
|
146
|
<pre>
|
|
147
|
westBoundingCoordinatePath=geographicCoverage/boundingCoordinates/westBoundingCoordinate
|
|
148
|
eastBoundingCoordinatePath=geographicCoverage/boundingCoordinates/eastBoundingCoordinate
|
|
149
|
southBoundingCoordinatePath=geographicCoverage/boundingCoordinates/southBoundingCoordinate
|
|
150
|
northBoundingCoordinatePath=geographicCoverage/boundingCoordinates/northBoundingCoordinate
|
|
151
|
</pre>
|
|
152
|
|
|
153
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0.1250in;text-indent:0in"></p>
|
|
154
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> It is important to note that, at the moment, only one set of xpaths are defined in metacat.properties meaning only documents of the chosen schema can be accessed by the spatial harvester. Also note that, for performance reasons, the xpaths to the bounding coordinates must also appear in your indexPath (defined in build.properties).</span></p>
|
|
155
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The bounding coordinates are spatially cached in two ways: t</span><span lang="en-US">he centroid(s) of the bounding box(s) and the actual bounding box(es). These are stored as two seperate shapefiles with multi-point and multi-polygon geometry types respectively. By default, </span><span style="font-size:8pt;font-family:'Courier New'" lang="en-US">${tomcat_webapps_directory}/${context}/data/metacat_shps/</span><span style="font-size:8pt;font-family:'Courier New'" lang="en-US">data_points.shp</span><span lang="en-US"> is the storage location of the point cache while </span><span style="font-size:8pt;font-family:'Courier New'" lang="en-US">data_bounds.shp</span><span lang="en-US"> represents the polygon cache. </span></p>
|
|
156
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The bounding polygon is not relevant to every document as bounding coordinates are allowed to be of zero-area (ie west = = east and north = = south). In this case they are represented only as a point. In cases where no bounding coordinates are defined, the document is not represented at all in the spatial cache. Note that special care has been taken to account for cases where the bounding box crosses the international dateline or polar regions (at which point Cartesian calculations are invalid).</span></p>
|
|
157
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Because documents may have more than one geographic coverage, it is necessary to define the two spatial caches as </span><span style="font-style:italic" lang="en-US">multi</span><span lang="en-US">-point and </span><span style="font-style:italic" lang="en-US">multi</span><span lang="en-US">-polygon geometry types. This means that each feature's geometry field can contain a collection of one </span><span style="font-style:italic" lang="en-US">or more </span><span lang="en-US">primitive geometries.</span></p>
|
|
158
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> With the spatial option properly installed, the default metacat.properties setting is to set </span><span style="font-style:italic" lang="en-US">regenerateCacheOnRestart=true.</span><span lang="en-US"> This is very useful the first time you install metacat since it will generate the spatial cache from scratch when your servlet container is restarted. Depending on how many documents you have in your metacat database, this can take a considerable amount of time; several minutes in the case of a few thousand documents. For this reason, Metacat sets this property to <em>false</em> after the spatial cache has been generated the first time. This prevents the regeneration of the spatial cache every time you restart your servlet container. Note that if you upgrade or reinstall metacat, the spatial cache will be regenerated again. </span></p>
|
|
159
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Once the spatial cache has been generated, the Metacat servlet will keep the spatial cache in sync with the metacat database by triggering the spatial harvester on every insert, update or delete. This does not regenerate the whole spatial cache, instead simply updating features in the cache as needed. It is fairly quick and should not add more than 1/2 second to any given transaction. As mentioned earlier, all high-level interactions with the spatial cache are handled through the SpatialHarvester class. </span></p>
|
|
160
|
<ul>
|
|
161
|
<li style="margin-bottom:12pt"><span lang="en-US"> W</span><span lang="en-US">hen a document is deleted, the SpatialHarvester.addToDeleteQue() method is called directly from the Metacat Servlet. </span></li>
|
|
162
|
<li style="margin-bottom:12pt"><span lang="en-US"> Inserts and updates are handled during the indexing process; after BuildIndex for a document has completed successfully (see </span><span style="font-style:italic" lang="en-US">DocumentImpl.java </span><span lang="en-US">) the SpatialHarvester.addToUpdateQue() method is invoked. The document is purged from the spatial cache (if updating) and the new document (or document revision) is added.</span> </li>
|
|
163
|
</ul>
|
|
164
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> There is one very important note about document authentication. While metacat provides very fine-grained permissions control at the document level, the Web Mapping Server component does not. For this reason, only documents that are publicly readable (i.e. documents which match the following SQL query : </span><span style="font-size:9pt;font-family:'Courier New'" lang="en-US">select distinct docid from xml_access where principal_name = 'public' and perm_type = 'allow')</span><span lang="en-US">will be added to the spatial cache. </span><span lang="en-US">In the Future Directions section of this document, the potential for adding feature-level permissions to the WMS server are discussed.</span></p>
|
|
165
|
|
|
166
|
|
|
167
|
<h5> <a name="wms"> Web Mapping Server </a> </h5>
|
|
168
|
|
|
169
|
|
|
170
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The primary function of the Web Mapping Server component is to render the spatial cache as a web-deliverable map image. It is also responsible for rendering other geographic data to provide base maps or other auxillary map layers.</span></p>
|
|
171
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The OpenGIS consortium has defined a standard for requesting maps, the Web Mapping Service or WMS standard. WMS servers accept a common set of parameters via http, render the spatial dataset into an appropriate image and deliver it back to the client. </p>
|
|
172
|
<p> For Metacat, we chose to go with GeoServer, a WMS-capable application written in Java. Geoserver (and the Geotools library upon which it depends) are seamlessly integrated into the metacat servlet context. This allows all of the Geoserver/Geotools functionality to be accessible to all of metacat and allows easier deployment than if it were distributed seperately. The downside to this approach is that upgrading geoserver later becomes slightly more complicated.</span></p>
|
|
173
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Geoserver comes with a default configuration that is already aware of the spatial cache and a world countries base layer. In order to configure existing data and add new data sources, geoserver comes with an web-based configuration utility. It is available at http://your.server/context/geoserver.jsp </span></p>
|
|
174
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Geoserver has lots of built in functionality and can support a wide variety of vector GIS data sources. These data sources can be styled using SLDs and can be made available via open distribution standards such as WMS and WFS. For our purposes, it mainly outputs Images (via WMS) but can be used to output raw vector data in the form of GML or KML.</span></p>
|
|
175
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> There are several issues with geoserver tha users should be aware of. The version of Geoserver (1.4) used by Metacat does not support raster input dataset (ie satellite imagery or digital elevation models). For distributing rasters, we recommend UMN Mapserver be set up independently. Geoserver, though it offers a web configuration interface, is lacking in several key areas and you may still have to hand-edit some XML files in order to customize your WMS server. </span></p>
|
|
176
|
|
|
177
|
|
|
178
|
|
|
179
|
|
|
180
|
<h5> <a name="spatial_query"> Spatial Query </a> </h5>
|
|
181
|
|
|
182
|
|
|
183
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Displaying the spatial cache as a map is important but users also need to query the spatial cache in order to answer the question "What documents lie in this geographic region?". The functionality is invoked through the metacat servlet itself; there is a </span><span style="font-style:italic" lang="en-US">spatial_query </span><span lang="en-US">action for this purpose. An example spatial query would be:</span></p>
|
|
184
|
<p dir="ltr" style="text-align:left;margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span style="font-size:8pt;font-family:'Courier New'" lang="en-US">http://localhost/knb/metacat?action=spatial_query&xmin=-117.5&xmax=-64&ymin=3&ymax=46&skin=default</span></p>
|
|
185
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US">Where xmin, xmax, ymin and ymax represent the west, east, south and northern bounding coordinates respectively. This will return an html document listing (in the style of the specified skin) all documents whose geographic coverage intersect the given bounding box.</span></p>
|
|
186
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The core functionality of the spatial query mechanism is found in the </span><span style="font-style:italic" lang="en-US">edu.ucsb.nceas.metacat.spatial.SpatialQuery</span><span lang="en-US"> class and, like the spatial harvester, relies heavily on the Geotools library. This class has a single method,</span><span style="font-style:italic" lang="en-US"> filterByBbox()</span><span lang="en-US">, which compares the bounding box to both the point and polygon cache. For each shapefile, the process requires two steps: First, filter the spatial cache for features whose bounding box overlaps the specified bounding coordinates; Second, iterate through the remaining features and perform an an actual geometric intersection. The second step, though more costly than comparing the bbox, is necessary because the feature's geometry may be a multi-geometry whose bounding box is large but whose component primitive geometries are scattered over that area. The end result is a vector of docids matching the spatial query.</span></p>
|
|
187
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> This docid list is then sent to DBQuery. Using a special constructor that takes a vector of docids, the DBQuery class is able to use the Docid override mechanism to perform an optimized query (for cases where the list of docids is already known).</span></p>
|
|
188
|
|
|
189
|
|
|
190
|
|
|
191
|
|
|
192
|
|
|
193
|
|
|
194
|
<h5> <a name="html_client"> HTML Mapping Client</a> </h5>
|
|
195
|
|
|
196
|
|
|
197
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> In order to provide a web-based user interface to the WMS and the spatial query functionality, Metacat relies on Community Mapbuilder. Mapbuilder is a pure HTML/javascript application which uses AJAX and XSLT on the client side to create a desktop-GIS-like environment for interacting with geographic data through a web browser.</span></p>
|
|
198
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The main function of mabuilder is to act as a front-end to WMS services. The WMS layers are configured through a Web Map Context document (typically found in the skin directory under spatial/context.xml). This context document (or WMC) can define the initial extent of the map, the ordering and visibility of layers and, of course, the source and name of the WMS layer.</span></p>
|
|
199
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> Mapbuilder provides several interface components or widgets (map, box zooms, layer list, "select location" dropdown, scalebar, coordinates, info query) that make it easy to deploy highly-functional web mapping applications with minimal coding. There are three main configuration files you need to work with in order to customize the map interface: The context document discussed above, the mapbuilder configuration file (typically under spatial/config.xml) which defined the widgets and their behavior and finally the html file (typically spatial/map.html) which loads the mapbuilder javascript library and places the widgets in your html layout.</span></p>
|
|
200
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> For integration with metacat, we built a custom mapbuilder widget, the AOIMetacat Query, which allows you to click query the map, either by box or point, and call the metacat spatial_query action. </span></p>
|
|
201
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"><span lang="en-US"> The cleanest way to integrate a mapbuilder interactive map with any page in your application is to simply create an iframe element with the src pointing to a standalone map.html. </span></p>
|
|
202
|
|
|
203
|
|
|
204
|
|
|
205
|
|
|
206
|
|
|
207
|
<h4> <a name="install">Installing and Configuring the Spatial Option</a> </h4>
|
|
208
|
|
|
209
|
<h5> Initial Installation </h5>
|
|
210
|
<p style="margin-bottom:12pt"><span lang="en-US">To install the spatial option, choose a version of metacat >= 1.7.0. You'll want to ensure that </span><span style="font-style:italic" lang="en-US">runSpatialOption</span><span lang="en-US"> is set to </span><em>true</em><span lang="en-US"> in lib/metacat.properties before you build. Running the spatial option is <em> true </em> by default so, unless you explicitly set it to be false, the spatial option will install and run automatically when you install metacat.</span></p>
|
|
211
|
|
|
212
|
<h5>How do I configure the layout of the html mapping interface?</h5>
|
|
213
|
The layout of the map components is defined in the spatial/map.html file within the skin's directory. It is a simple tabular layout and the map components are abstracted into "widgets", blocks with a specific id, which can be reorganized within the table. For deeper customization you can modify the web map context document (spatial/context.xml) and the mapbuilder config file (spatial/config.xml).
|
|
214
|
<h5> How can I change the lat/long display to degree-minutes-seconds ? </h5>
|
|
215
|
By default, the map display shows the cursors position in decimal degrees since this is the prefered format for many GPS/GIS applications. However, there may be cases where you need to report coordinates as degrees minutes-seconds. To do so, go into you skins spatial configuration file (usually ${skin.dir}/spatial/config.xml) and edit the CursorTrack widget as shown below:
|
|
216
|
<pre>
|
|
217
|
<CursorTrack id="cursorTrack">
|
|
218
|
<mouseHandler>mainMap</mouseHandler>
|
|
219
|
<showDMS>true</showDMS>
|
|
220
|
<showLatLong>true</showLatLong>
|
|
221
|
</CursorTrack>
|
|
222
|
</pre>
|
|
223
|
|
|
224
|
<h5>How can I configure the size and initial extent of the map?</h5>
|
|
225
|
The map's initial extent is defined in the web map context document for each skin. To change the map size and/or initial extent, edit the following lines:
|
|
226
|
<pre>
|
|
227
|
<Window width="720" height="360" />
|
|
228
|
<BoundingBox SRS="EPSG:4326" minx="-180" miny="-90" maxx="180" maxy="90" />
|
|
229
|
</pre>
|
|
230
|
Where the width and height are the image size in pixels and the minx/maxx represent the range of longitudes and miny/maxy reprsent the range of latitudes.
|
|
231
|
|
|
232
|
<h5>How do I configure the "select location" dropdown to contain different predefined locations?</h5>
|
|
233
|
The locations data are held in a file called "named_locations.xml" in your skin's spatial directory. This defines each location as a gml:featureMember. Within each featureMember, you can edit the gml:name and gml:coordinates fields to edit or add new locations.
|
|
234
|
|
|
235
|
<h5>Can I use a different web mapping interface?</span></h5>
|
|
236
|
<p>Certainly. Since our mapping server conforms to the WMS standard, you can develop a map interface using any WMS client application. There are many of WMS clients ranging from desktop GIS applications (ArcGIS, QGIS, JUMP, UDig) to javascript web mapping frameworks (openlayers, mapbender, mapbuilder) and anyone of them could be used to build a novel spatial application from the metacat wms.</p>
|
|
237
|
<p> There is an experimental version of OpenLayers (a tiled, google-maps-esque web interface) included with Metacat spatial. This can be accessed at http://your.server/context/style/common/spatial_templates/openlayers1/map.html. Keep in mind that this is experimental and not supported as an official interface.
|
|
238
|
|
|
239
|
<h5>How do I configure the styling and classification of the data?</h5>
|
|
240
|
|
|
241
|
The datasets are styled through the use of Styled Layer Descriptors (SLD). The default SLDs used for the data points and data bounding boxes are in {context}/data/styles and named <em> data_points_style.sld </em> and <em> data_bounds_style.sld </em> respectively.
|
|
242
|
You can find more a more detailed tutorial on using SLD with geoserver at : <a href="http://docs.codehaus.org/display/GEOSDOC/SLD+Intro+Tutorial"> http://docs.codehaus.org/display/GEOSDOC/SLD+Intro+Tutorial</a>.
|
|
243
|
|
|
244
|
<h5>What versions of tomcat are supported?</h5>
|
|
245
|
|
|
246
|
<p>The spatial functionality has only been tested on tomcat 5. The web.xml.tomcat4 distributed with metacat is no longer supported after Metacat 1.6.0 . If you <em>need</em> to use tomcat 4, you might be able to update this file to reflect the incorporation of geoserver (see web.xml.tomcat5) though we have no intention of supporting it's use.</p>
|
|
247
|
|
|
248
|
<h5>How do I add the map to another page or metacat skin?</h5>
|
|
249
|
|
|
250
|
The map interface is held in a seperate html document and can be easily included in any html page through the use of an iframe :
|
|
251
|
<pre>
|
|
252
|
<iframe scrolling="no" frameborder="0" width="736" height="520"
|
|
253
|
src="/knb/style/common/spatial_templates/spatial1/map.html">
|
|
254
|
</iframe>
|
|
255
|
</pre>
|
|
256
|
The map URL referenced here is the default, common spatial template for use in any skin. If you plan on doing any customization of the map interface, you should copy that spatial template into your skin's directory:
|
|
257
|
<pre>
|
|
258
|
cp -r style/common/spatial_templates/spatial1 style/skins/myskin/spatial
|
|
259
|
</pre>
|
|
260
|
and access it with the url "/knb/style/skins/myskin/spatial/map.html".
|
|
261
|
|
|
262
|
|
|
263
|
<h4> <a name="adding_data">Adding Other Spatial Datasets to the Web Map</a> </h4>
|
|
264
|
|
|
265
|
<h5> Adding your own spatial datasets </h5>
|
|
266
|
If you have other vector GIS datasets on your server that you'd like to include in the interactive map, there are two main tasks:<ul>
|
|
267
|
<li> Registering the dataset with geoserver </li> <li> Adding the layer to the web map context </li> </ul>
|
|
268
|
|
|
269
|
<h6> Registering your dataset with geoserver </h6>
|
|
270
|
There is a <a href="http://docs.codehaus.org/display/GEOSDOC/User+Tutorial+Shapefile"> geoserver tutorial </a> which covers the precise steps of adding a new layer via the web interface. The actual process will differ slightly depending on your configuration so we'll clarify and summarize the steps below:
|
|
271
|
<ol>
|
|
272
|
<li>Creating a datastore (ie registering the raw data)</li>
|
|
273
|
<ul>
|
|
274
|
<li> Point your browser to http://your.server/context/geoserver.jsp, login and navigate to the "data stores" config page.</li>
|
|
275
|
<li> Define your new shapefile datastore and point to the shp file on the filesystem (relative to {tomcat.dir}/webapps/{context}/ ). </li>
|
|
276
|
<li> Use the "metacat" namespace to describe your data </li>
|
|
277
|
</ul>
|
|
278
|
<li> Creating the feature type (ie registering the data as a recognizable layer)</li>
|
|
279
|
<ul>
|
|
280
|
<li> You must define a spatial reference system number for each layer. Most lat/long data is "4326". If your data is in another projection, you'll have to determine its SRS using the help links provided. </li>
|
|
281
|
<li> The dropdown list of styles provides some good default choices but to get more control over the styling, you'll need to create a new Style object and corresponding SLD. </li>
|
|
282
|
</ul>
|
|
283
|
<li> Testing </li>
|
|
284
|
<ul>
|
|
285
|
<li> Make sure you "Apply" and "Save" ! </li>
|
|
286
|
<li> Try out the featureType as a WMS layer using a URL like:<br/>
|
|
287
|
<span style="font-family:monospace; font-size:9pt;">http://your.server/context/wms?VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=metacat:<strong>newLayer</strong>&SRS=EPSG:4326&BBOX=<strong>-180,-90,180,90</strong>&WIDTH=720&HEIGHT=360&FORMAT=image/gif&STYLES=&TRANSPARENT=TRUE&UNIQUEID= </span></li>
|
|
288
|
<li> If this displays your data properly, it's time to add it to your map context document. </li></ul>
|
|
289
|
</ol>
|
|
290
|
|
|
291
|
<h6> Adding your layer to the web map context </h6>
|
|
292
|
|
|
293
|
<ol>
|
|
294
|
<li> Locate the web map context document (usually {skin}/spatial/context.xml) and open in a text editor </li>
|
|
295
|
<li> Locate the Layer entry for an existing layer next to which you want your layer stacked (the first layers in the context are rendered at the bottom). </li>
|
|
296
|
<li> Create a new Layer entry, copying an existing entry for the metacat data_points layer to use as an example. </li>
|
|
297
|
<li> Edit the layer Name to reflect the name of your new feature type (ie metacat:newLayer ) </li>
|
|
298
|
<li> Edit the Title; this will be displayed in the map legend. </li>
|
|
299
|
<li> Special note about the image format: image/gif is the only option if you want transparency (since IE pre-7 has trouble with PNG transparency). image/jpeg is a good option for base layers.
|
|
300
|
<li> Point your browser to the map interface using this context document and your layer should show up stacked with the others </li>
|
|
301
|
</ol>
|
|
302
|
|
|
303
|
|
|
304
|
<h5> External WMS data sources </h5>
|
|
305
|
|
|
306
|
There are hundreds of sources of spatial data made publically available through WMS. Check out <a href="http://wms-sites.com/"> wms-sites.com </a> for good catalog. In order to add these data sources to your map, locate your skin's context document and add a Layer as appropriate. Using an existing Layer as an example, modify the OnlineResourceURL, Name, Title and Style to match the WMS layer you're after. See the mapbuilder <a href="http://communitymapbuilder.org/display/MAP/Add+WMS+Tutorial"> Add WMS Tutorial</a> for further details.
|
|
307
|
|
|
308
|
<h5> Raster Images </h5>
|
|
309
|
|
|
310
|
The version of geoserver currently shipping with metacat (geoserver 1.4) does not support raster images as input data sources. We suggest setting up UMN Mapserver if you aim to serve raster data as a WMS. Note that once a WMS service is set up, the process of adding it to your map context is the same regardless of what WMS software is serving it. (ahhh the beauty of open standards).
|
|
311
|
|
|
312
|
|
|
313
|
<h4> <a name="dev">Developers Notes</a></h4>
|
|
314
|
|
|
315
|
<h5>web.xml</h5>
|
|
316
|
|
|
317
|
The process of integrating geoserver with metacat involved merging the two web.xml documents. Special care must be taken to preserve the order of loading for various components in the geoserver stack. The web.xml.tomcat5 document is commented in the relevant places to indicate its purpose.
|
|
318
|
|
|
319
|
<h5>Upgrading geoserver</h5>
|
|
320
|
Great care has been taken not to modify geoserver so heavily as to "fork" it. Any small changes made should be submitted to the geoserver development team or maintained as patches against released versions.
|
|
321
|
|
|
322
|
Still, upgrading geoserver is not as seamless as one might hope. Most notably, any changes in the geoserver web.xml will have to be integrated by hand into out metacat/geoserver hybrid web.xml.tomcat5 document. In addition, geoserver distributes some unneccesary files that have been cut from the metacat version. When upgrading geoserver, make sure any old files get deleted, new files get added to cvs (if they are needed) or removed (if superfluous).
|
|
323
|
|
|
324
|
|
|
325
|
<h4> <a name="future">Future Directions</a> </h4>
|
|
326
|
|
|
327
|
<h5>Automatically handle spatial datasets</h5>
|
|
328
|
<p style="margin-bottom:12pt">When users put spatial data into the Morpho system, it would be nice if we could automatically pull all the avialable metadata from the spatial dataset itself. </p>
|
|
329
|
<p style="margin-bottom:12pt">On the metacat side, it might be worth trying to auto-detect spatial datasets and add them to the WMS service do that they could be displayed along with the metadata coverages. This is tricky since the styling of spatial data is intentionally seperated from the data itself; we'd have to have some sort of easy way to prompt the user for the classification and styling info and construct the appropriate SLDs. </p>
|
|
330
|
<p style="margin-bottom:12pt">It's worth noting that, currently, one could do this manually. There is nothing, aside from editing a few configuration files, to prevent any Geotools-supported dataset from being displayed through the WMS map interface.</p>
|
|
331
|
<p style="margin-bottom:12pt">For vector datasets, it would be possible to store the data directly in the database itself (This is a logical extension of the future work to put tabular data directly in a relational database). Postgresql has the PostGIS extensions to handle this so we would have to require postgresql if we went this route.</p>
|
|
332
|
|
|
333
|
<h5>WMS bypass</h5>
|
|
334
|
<p style="margin-bottom:12pt"> Filter which spatial cache features are displayed by access contraints, skin constraints and the current non-spatial query set. This would involve intercepting incoming WMS requests and appending a styled layer descriptor (SLD) with an OGC filter to prevent/allow certain docids. </p>
|
|
335
|
|
|
336
|
<h5>SLD factory</h5>
|
|
337
|
<p style="margin-bottom:12pt">Closely related to the WMS bypass implemetation, the SLD factory would be in charge of constructing the filter based on on the contraints mentioned above. In other words, it would construct a document specifying which docids were to appear in the map. Because it would have to generate this list of docids on every wms request, performance is a big concern. Likely we'll need to cache docid lists as session variables.</p>
|
|
338
|
|
|
339
|
<p> There is currently a stub implementation of the SLD Factory servlet in <em>src/edu/ucsb/nceas/metacat/spatial/SldFactory.java</em>. It is functional except that it doesn't generate a dynamic list of allowable docids. Assuming we can modify the SldFactory servlet to quickly generate a list of allowable docids based on stored session variables, applying this SLD to a WMS request is fairly easy and simply requires appending the URL of the sldfactory as an "SLD" parameter to the WMS GetMap request: </p>
|
|
340
|
|
|
341
|
<pre> http://indus/knb/wms?REQUEST=GetMap&SERVICE=WMS....&SLD=http://indus.msi.ucsb.edu/knb/sldfactory?originalSld=data_points_style.sld</pre>
|
|
342
|
|
|
343
|
<p> where data_points_style.sld is the original style document existing in <em>{context}/data/styles/</em>. The sldfactory servlet will construct a list of allowable docids, append those to the original sld as an ogc filter, an return a (modified) SLD document. There are two possibilities for implementing this:</p>
|
|
344
|
|
|
345
|
<ol>
|
|
346
|
<li>
|
|
347
|
Mapbuilder (the WMS client in charge of constructing WMS request) can be told to append this SLD parameter through the use of the WMC config document. This would work for the skins but, alone, would not ensure that every WMS request were filtered since other clients could simply ommit the SLD parameter.
|
|
348
|
</li>
|
|
349
|
<li>
|
|
350
|
An alternative, one that would ensure that EVERY wms request was filtered, would be to handle it all server side with a WMS bypass.
|
|
351
|
</li>
|
|
352
|
</ol>
|
|
353
|
|
|
354
|
|
|
355
|
|
|
356
|
<h5>Map configuration interface </h5>
|
|
357
|
<p style="margin-bottom:12pt">Geoserver currently offers a nice web-based configuration but it is lacking a few key features and may be difficult for a novice GIS user. We may want to reinvent a custom geoserver configuration interface to</p>
|
|
358
|
<ul>
|
|
359
|
<li style="margin-bottom:12pt"><span lang="en-US"> D</span>efine the available datasets (ie editing the geoserver xml config files)</li>
|
|
360
|
<li style="margin-bottom:12pt"><span lang="en-US"> Define</span> classification and styling (ie editing the SLDs)</li>
|
|
361
|
<li style="margin-bottom:12pt"><span lang="en-US"> Define which layers get displayed in which map (ie editing the Mapbuilder WMCs)</span></li>
|
|
362
|
<li style="margin-bottom:12pt"><span lang="en-US"> Picking a layout ( from a list of pre-configure mapbuilder templates)</span> </li>
|
|
363
|
</ul>
|
|
364
|
<p style="margin-bottom:12pt;margin-left:0pt;text-indent:0in"> Ideally we could pull as much information as possible from the metadata and make the UI very intuitive. This does bring up issues of web-based admin access constraints and developing a subsytem to handle who has edit access to the map configuration.</p>
|
|
365
|
|
|
366
|
|
|
367
|
|
|
368
|
<table> <tr>
|
|
369
|
<td align="right">
|
|
370
|
<a href="./properties.html">Back</a> |
|
|
371
|
<a href="./metacattour.html">Home</a> |
|
|
372
|
<a href="./unimplem.html">Next</a>
|
|
373
|
</td>
|
|
374
|
</tr> </table>
|
|
375
|
|
|
376
|
</BODY>
|
|
377
|
</HTML>
|
