Abstract | Full Paper | PDF | Printer friendly format

Page 3 of 4
| Previous | Next |

Web Based Maintenance of Data Assets
For organisations that still need to develop and maintain their own datasets, data maintenance and update remains a significant cost. To date, update of spatial data has been largely restricted to dedicated workstations running relatively expensive software and located within the same LAN as the databases being edited. Despite the fact that frequently data collection/ update is being undertaken in the field or remote offices, facilities for remote update - across either fixed WAN or Internet connections - have been limited.

This is beginning to change. Based on web services technology and standards, web based spatial edit applications are appearing. These rely on the ability to write, transmit data in standard formats (XML or Vector Markup Language (VML)) across the web, and convert these to standard GIS formats such as Shape, ArcSDE or Oracle Spatial.

Web editing tools offer organisations maintaining data a cost effective approach to disseminated editing functionality across either intranets or the Internet. This is of significance as it permits the update and maintenance of data within central data stores to be carried out remotely – allowing data to be updated from the field, site office or remote station. Data update is no longer restricted to LAN on which the central database is stored, it is accessible to WAN and Internet connections.

One example of such initiatives is WebEdit (we) from TIG Centre, which appeared in July 2002 (www.tigcentre.com). Based at present on ESRI technology, it operates within a standard ESRI ArcIMS environment and focuses on editing ESRI suite of data formats (ArcSDE and Shape). It is briefly described below as an illustration of the functionality and approach taken by this kind of technology.

As is shown in Figure 1, in principle we operates in much the same way as a traditional editing application. The we Server is responsible for handling data extraction, transaction management, post back and conflict resolution and edit tracking. The client selects elements to edit, edits these locally and then posts them back to the server. Where we differs is that all client activity is undertaken in a standard Microsoft Internet Explorer web browser.


Figure 1: we Components and Operational Relationship
we is based on four distinct components:

• we client – handles user interface providing view control, query, selection, edit and print functionality;
• we server – handles edit session administration, data extraction and synchronisation, roll back and edit tracking;
• we website – provides access and run-/one-time download JavaScripts; and
• ArcIMS Server – used to provide the basic map service carrying data to be edited.