XMap users run the gamut, from large corporations to standalone GIS enthusiasts. The former usually have a well structured I.T. infrastructure to facilitate the central management and distribution of data. The latter don’t need to concern themselves about central data management; their data is locally managed by the SQL server conveniently installed on their hard drive during the installation of XMap.
The target of this article is for those XMap users who fall somewhere in the middle: organizations that are large enough to realize the importance of sharing data among their workforce but small enough to get away with not hiring a full-time I.T. manager. Judging by the calls that are received by XMap technical support and product specialists, this group represents a sizable percentage of XMap users.
Sharing GIS data often involves the simple act of exporting, delivering, and subsequently importing Openspace layers. Under this scenario, each user of XMap is their own data manager and their local version of SQL acts as a single-user data repository.
While the export/import process is a reasonably effective data distribution solution in situations where data is shared on an occasional basis, it does have its limitations and potential drawbacks if layers are continually changing hands:
- It is time-consuming and inefficient
- It requires the action of the data host to physically extract the data; if that person is unavailable, others cannot access the data
- Multiple versions of a particular layer might accumulate in each user’s database causing confusion and possible storage capacity issues
- Most importantly, edits made by each individual user will not be reflected in other users’ versions of the layer
An obvious solution is to develop a more collaborative working environment in which a single version of each layer is maintained and updated in a universally accessible location. A prerequisite for developing this type of data management model is to have all of the required users on some sort of network. This network does not have to be overly complex and for small organizations, it can be easily set up using off-the-shelf hardware.
Once the network has been established and the required users have been granted the appropriate access, a shared XMap database can be created. For this process, there are two possible approaches:
- All users can be given access to an existing XMap database on an individual’s computer
- A new instance of Microsoft SQL can be installed on a dedicated computer or server.
The benefit of the first option is that no additional hardware needs to be purchased and no additional databases need to be built and maintained. The shortcoming of this approach is that it doesn’t solve the problem of accessing data when the owner of the host database is away from the office.
If it is feasible, dedicating a continually accessible computer to act as a central SQL server is a much better approach. How is this instance of SQL installed and how is the requisite XMap database created? Thankfully this part is easy.
As previously mentioned, all versions of XMap include by default, an instance of Microsoft SQL on the same hard drive on which the software was installed. During the installation process, SQL is installed before XMap itself. This version of SQL is freely distributed by Microsoft so there is no limitation or license restriction applied to its distribution. Therefore, the simplest way to install SQL on the server is to insert the XMap disc in an available DVD drive and allow the installer to run the prerequisites. After a few minutes, the installer will ask for an XMap license number at which point, the installation can be terminated using the Cancel button. The XMap-ready instance of SQL remains, in spite of the fact that the software itself was not installed.
Using any connected version of XMap, a database can now be created and access granted to all XMap users. The simplest way to create a database on this new server is to create, import, or copy an existing layer. Instead of adding the layer to a local database, choose New under the Target Database dropdown list, type the name of the server (usually [computer name]\XMap7) and type a database name.
Other XMap users can then access the layers in this database by selecting Manage from the Layers menu in the GIS tab and choosing Other from the Source Database dropdown list. After typing the server name as noted above and clicking the Connect button, a list of available databases on the server will be displayed. Back in the Manage Layers window, the available layers can now be added to the Workspace.
This collaborative environment requires a certain level of workflow management to ensure that multiple users are not trying to simultaneously edit the same records. In such cases, the edits performed by the last user to click the Commit button will be the ones applied to the layer. Thankfully XMap includes several tools to help administer this workflow process.
The Database Manager, which is accessed from a button in the Workspace in XMap, allows the administrator to offer database permissions and assign roles (Server User, Database Creator, or Server Administrator) to each user. It can also be used to initiate the database synchronization process that allows GIS layers to be automatically delivered to the local database on each user’s computer so they can work in a disconnected environment.
The layer Check-out/in process can be utilized to assign data within a specified geographic area to an individual user who can subsequently edit, add, or delete records within the limits of that area. While this data is checked-out, the corresponding area in the original layer is locked for editing ensuring that multi-user concurrent editing is avoided.
If an individual user simply wants a copy of a centrally stored layer to work on independently or to take into the field, the easiest way to achieve this is to create a duplicate version of the layer in a local database. To do this, select the required layer in the Workspace, click the Layers button, click Create, and choose Copy Layer. In the resulting window, make sure the local database is selected from the Target Database dropdown list.
Setting up a shared working environment is not a difficult process for small companies or organizations. For XMap users, the benefit of being able to effectively share data and centrally administer key GIS layers results in a more efficient workflow.
For more detailed information on XMap from the I.T. perspective, read the XMap Admin Guide.
