In recent years, Geographic Information Systems (GIS), like other facets of information technology, have been subjected to continuous and rapid advancement. This has resulted in a demand from clients of land survey firms to have all of their digital data delivered in a GIS format creating a need for many small to mid size firms to build and maintain a GIS department. Such departments are expensive to maintain in a highly competitive market where GIS talent is relatively scarce and financing increasingly difficult to obtain. These firms would benefit from new, inexpensive methods and procedures for delivering their spatial data along with the associated attributes and metadata. A software package that delivers such methods would obviate the needs for small firms to staff their own GIS departments.
Companies in Alberta, Canada, that are required to submit their vector based pipeline right-of-ways and well site plans for approval in AutoCAD or MicroStation formats (DXF, DWG or DGN) to government agencies such as Alberta Sustainable Resources Development and Alberta Land Titles need an efficient, economic and easily adaptable method of spatial data submission. Such a method should allow for the transformation of this spatial data into different data models and would include reliable quality control checks. The best solution would allow for the data to be presented in AutoCAD or MicroStation formats to these government agencies and would permit the subsequent conversion of the data to ESRI shapefiles along with the attachment of attributes from other business systems that could then be delivered to the client. In addition, any proposed method for resolving the above problems should find the most transparent way of organizing the spatial data so that it can be easily managed and retrieved for future reference by the company itself. DXF/DWG, ESRI shapefiles and Portable Document Format (PDF) are the most useful formats for delivering this spatial data. In an ideal system, PDF files should include any document sent by the client, field staff or indeed any comment made by the project manager about the project in question.
This research describes the development of a simple, cost effective and easy to organize enterprise GIS with the ability to serve different types of information using open source technology (Reid and Martin, 2001) coupled with customized applications written in Microsoft Visual Basic that permit end-users to access spatial and non-spatial information on a single platform. The main components of this Enterprise GIS system are a Web Server, a Mapping Server and a File Transfer Protocol (FTP) server. The intention was to design and develop a system that effortlessly connected to other sub-components of the business process model. The system allows for simple and routine information updates that permit the end user to access the most recent and reliable information. The designed system completely relies on CAD operators but takes full advantage of the state-of-the-art, open source GIS server environments. Customized applications run and update the GIS data on an hourly basis while integrating the business process logic with appropriate quality control checks.
Recent developments and improvements in commercial and non-commercial (or, in other words, free and/or open source) geospatial software have the attention of many public and private organizations and as a result many small to mid size servicing companies have started to get spatially aware information requests from their customers. Large clients are interested in seeing their data use standard protocols such as Web Map Service (WMS) and Web Feature Service (WFS) Interface Standard while other mid to small size clients want to have their data submitted to them in GIS formats, such as shapefiles along with additional, non-spatial attributes. In addition many jurisdictions require that the same files must be submitted for approval to government agencies in AutoCAD or MicroStation format formats (i.e. as DXF, DWG or DGN files). This diverse requirement list has caused enormous pressure for companies specialized in geomatics or legal surveying to find a low cost, enterprise solution that has the ability to fulfill the demands of internal and external clients along with being able to communicate with other business systems to retrieve some of the client specific attribute information (Tomlinson, 2007). Moreover such an enterprise solution should have the ability to serve documents to clients, such as PDFs or any other image document, through the Internet.
Since an enterprise geographic information system (EGIS) provides access to shared geospatial information and analysis resources for a large number of concurrent users located in different parts of an institution (Rich et al. 2001, Somers 2002), the implementation of an EGIS is mainly based on how different users participate to maintain the currency of the spatial and non-spatial data. As well as the hardware, software, and data, there are other important, often-overlooked components of technical design that are essential for successful implementation of an EGIS, involving, in particular, process integration and the distinct roles of participants (Oppmann 1999). Despite rapid growth in the use of GIS technologies in public and private organizations, recent advances in data storage, processing, and networking do not necessarily result in increased data accessibility (Keating, et al., 2003). With the goal of enhanced geospatial data sharing within and across organizational boundaries, organizations increasingly focus on enterprise, or institutional, solutions for effective information exchange (Meredith 1995, Burrough and McDonnell 1998), thereby avoiding redundant systems and services and incompatible infrastructure (Pinto and Onsrud, 1995).
This research reports on the design and implementation of a low cost, platform independent, open source EGIS that is tightly integrated with an organization’s workflow (Figure 1). After consideration of existing and requested information products by internal and external clients and the presence of several sources of spatial and non-spatial data used by different departments within the organization we decided to use a centralized spatial database as an integrated repository for all types of survey and management data, with the capability of “talking” to and retrieving information from other business systems within the organization. Visual Basic programs were written to achieve the capacity to convert GIS data from one format to another, add additional attributes from other business systems and, finally, to import converted data dynamically and back it up in a time stamped way from a variety of sources so that every user would get access to the most recent and current version of the data and so that layers could be shared internally and externally, in real time, via WMS/WFS or MapGuide (for a detailed introduction see Bray, 2008; also Gittings, 2009). In one test of the system, the simplicity of the proposed GIS data update process and tight integration within the organization’s workflow made it possible to easily manage, update and serve sixty seven (67) different vector and raster data layers coupled with some sophisticated reports and coordinate conversion tools without using existing resources/staff.
Systematic organization of PDF documents was made possible through a customized Visual Basic application so that staff in the quality control (QC) department could decide which documents needed to be uploaded to the File Transfer Protocol (FTP) server in order to associate the geographic features and extend the functionality of the mapping system to a basic document management system. Likewise these PDFs could then be retrieved by multiple departments when needed by clicking on the appropriate features in a web browser. Finally, functionality of the Web-GIS site was extended by adding custom reports to share information on data currency and to eliminate the use of outdated information distributed via paper maps. A number of coordinate conversion routines were added to the main website to provide field crews a single platform with all the crucial functionalities.
Figures 1 and 2 show the contributing departments and their activities as well as the processes necessary to bring about this integration of the GIS and CAD environments using an open source technology.
To summarize, this research sought to resolve issues relating to the rapid advances in GIS technology and the concomitant changes and expectations in a client’s spatial requests to the surveying industry. Specifically, the research sought to develop an enterprise wide system that would accomplish three major goals:
- Share spatial data in real time with local and remote draftspersons and field crews within the organization, and finally with external clients;
- Update data seamlessly, effortlessly and rapidly;
- Store and subsequently share data with customers at their request (i.e. have the customer ‘pull’ data from the database rather than ‘push’ prepared reports to them).
The research described here developed an integrated database and an EGIS for survey data that had been prepared using CAD programs. Also developed was a web enabled map and document presentation system that used low cost software to achieve complex functionality.
First, in order to accomplish these technical goals, it was required to develop effective, efficient and reliable ways to store multiple, disparate data sets in a time-stamped way in a single GIS database. By creating a single database, the following goals would be accomplished: a single integrated repository of data; a process for providing updates to the data sets that would be shared to all future maps (this would allow for the creation of real time maps that incorporate current information and eliminate the outdated information that had previously been distributed via paper maps); and an automatic data archival and backup.
Second, it was necessary to automatically incorporate other types of data sets (for example, contract documents) from other business systems into the GIS database and subsequently to provide document management for these types of data. Third, data security was a concern and so it was important to secure the data via firewalls between various client data sets. As part of data security, it was necessary to filter the data and control the distribution of it through the implementation of a security layer so that different users would interact with the data based on their credentials in a Client/Server environment.
Fourth the system had to be able to automatically input data remotely and in real time from the field for the purposes of automatic vehicle location, displaying “safe places to go” for field crews working near sour gas facilities and to enable ERP (Emergency Response Planning). A fifth concern was the desire to securely share data, initially internally among the draftspersons, then to field crews, and finally to clients and other third parties. To do this we needed to carry out the following activities: provide an interface that allows requests for geographical features across the web using platform-independent calls; display the data independently from the original front end display application; source remote data sets (for example, from government databases); improve the speed of accessing the data; be browser independent, (that is, make the data available to a variety of web-based tools) and be platform independent (for example, be able to operate under Windows, Unix, Linux and Macintosh operating systems). The sixth and final capability that we desired to incorporate in the system was the ability to publish raster data as a layer of a map or, using a standard protocol, as a geo-referenced image over the internet.
Technical Challenges and Advances
To summarize, once more, the goals of the research were to develop a platform independent, EGIS-based survey and document database and management system, with the ability to update itself automatically on an hourly basis and communicate and retrieve information with other business systems when needed and be available over the internet through virtually any browser.
The technical advances that were necessary to achieve these goals included first the construction of a single centralized spatial database that would serve as an integrated repository of data for all types of survey and management data employed by the enterprise. Second, it was necessary to develop software to convert a spectrum of customer and legacy data to the new database format and populate the database with the universal data set.
Third we needed to develop the capacity to import new data dynamically in a time stamped format from a variety of sources. Fourth, we needed to be able to produce custom reports under MapGuide Open Source including the ability to share updates with the data sets for all future maps so that we could eliminate the outdated information distributed via paper maps.
Fifth, a browser / platform independent way to access and share data both securely and remotely was needed. Initially this would be a system that was used internally among the draftspersons, then the field crews, and, finally, would be made available to clients and other third parties. The sixth and last component of the system involved developing a method to integrate LiDAR data into the database and to display it using MapGuide or other similar programs.
Numerous technical issues had to be resolved in order to develop a smoothly functioning system that was transparent to the client. Each of these solutions will now be described.
Budget Restrictions for Small to Mid Size Companies
The project required new, leading-edge technology. Many of the advanced features of MapGuide Open Source had never been tested by the GIS community and therefore some features of the technology were initially untried. For example, the software tested was able to create buffers in some cases but not in other cases such as when a feature (e.g., a segment of an oil/gas pipeline or a road) was running in a north-south direction. The desired system was complex with a centralized relational database management system (equipped with almost all of the advanced spatial operations including solutions to nearest neighbor, advanced spatial analysis, data integrity operations, distance queries, spatial joins, overlay analysis and coordinate projections). The main component needed to communicate asynchronously with other business systems and so it was necessary to find methods and to write custom applications that would automatically update the data.
The clients’ budget limitations meant that a low cost method was needed to serve out the data using a centralized database via the internet that had to be browser and platform independent with those capabilities that would allow it to serve data out in software independent protocols including WMS and WFS. The most important goal was to achieve all of these requirements without compromising the overall efficiency of the system.
The Requirement that Data is Submitted to Government in CAD or MicroStation Format
This research was conducted in Alberta, Canada, where there is a requirement that pipeline right-of-ways and well site plans requiring approval be submitted in AutoCAD or MicroStation formats (DXF, DWG or DGN) to government agencies such as Alberta Sustainable Resources Development and Alberta Land Titles. The results of this research should therefore be of considerable interest to organizations working in jurisdictions where there are similar government regulations.
Two options were available. The first was to draft every drawing using a GIS product that had the capability to directly edit centralized data and convert that to DXF, DWG or DGN format. The main limitation of such a system was the monumental task of running and coordinating two or more very different software packages and of course the training/retraining of draftspersons working locally or remotely. The second option was to find a way to create or convert to a GIS format using some customized and accurate methods. It is important to note that different clients often ask for their drawings in different coordinate systems. In order to be able to create, update or maintain a universal database it was necessary to consider the projection of the child vector file when appending to the master file (see discussion below). Further, a facility for adding additional attributes from other business systems such as those that are normally used to keep track of the status of jobs during a life cycle was required.
The Requirement for a Vector Data Projection Transformation
To implement the required vector data projection transformation an AutoLISP routine was written and added to the basic AutoCAD interface. This permitted the export of the selected features of desired layers as spatial data files (Autodesk SDF 2), we call them “child” files. Once finished with the drawing, the draftsperson needed to select the features and the option ‘Export to MapGuide’. Before exporting the files, the routine would determine the predefined topological rules, producing an error message if these were violated. Once everything was confirmed as correct, the various layers, following re-projection to NAD83(CSRS) / Alberta 10-TM (Resource), were exported as an SDF 2 file, with a file name identical to the unique job number (a number that was assigned to every work assignment). This name was further used to append this child file to the master file in the PostgreSQL based system. In addition, attributes from the non-spatial business system could be included (Figures 3 and 4).
The features exported include the cadastral limits of new and existing surveys in both line and polygon formats. Further routines were developed to include surface developments as point features and their attributes. A Surface Development is defined in the Alberta Energy Resources Conservation Board’s (ERCB) Directive 56 as an occupied permanent or part-time dwelling, a publicly used facility, including a campground, place of business, and any other surface development where the public may gather on a regular basis, (Examples may include a residence, campground, church, community centre, compressor site with an office where people gather regularly etc.).
Robots: Adding attributes from other Business Systems
Robots are customized Visual Basic applications that were used to perform basic data transformations in combination with the Autodesk MapGuide SDF Component Toolkit. The robots were implemented to open specified folders on an hourly basis and read all the Autodesk’s SDF 2 files in that folder convert each SDF 2 file to an ESRI shapefile.
They worked in combination with the Autodesk MapGuide SDF Component Toolkit, a set of Component Object Model (COM) objects distributed as a Win32 DLL for reading and writing Spatial Data Files (SDF), including version 2.0, Spatial Index Files (SIF), and Key Index Files (KIF). All SDF 2.0 files were given a name based on a unique job number after being converted to a shapefile, and then saved to a temporary shapefile folder. The robot then read the shapefile folder and converted every shapefile to a PostgreSQL script file, subsequently saving them into a temporary script folder. In addition, it read the right-of-way table in the PostgreSQL database to make certain that there were no existing entries for this job number. If there were it would delete them and subsequently run the PostgreSQL script file to append the table. Once appended it contacted other business systems to fetch additional information associated with that particular job assignment in the non-spatial business system. This process was iterative and was run for all the script files created from the child shapefiles, once appended it deleted the SDF 2.0, shapefile and script files associated with the different appended child files (Figure 3). In the right-of-way table there was an additional field that saved the time and date when the feature was appended. This field was used for backup and archival purposes.
The Client’s Need to Submit Data in GIS Format
Real time data is good in most instances but not in every case. Different clients may ask for different projection systems for their drawings and some of the layers within these drawings represent a time stamp of the GIS data at the time of drafting. In these instances, it is necessary to keep that information for future reference in order to see the exact condition of the different GIS layers at that point in time. Thus the biggest decision at the time of designing the GIS system was to duplicate the GIS data so that every drawing, incoming/outgoing and other associated information would be stored inside a separate folder automatically created when a new job/work assignment was started using our non-spatial business system. In addition, this folder had to be easily accessible by our web based system simply by doing a small search after entering the job number. At the same time different internal and external clients may need help planning a new project and so some of the most important layers would have to be updated in the centralized database meaning that the near real time status of all the different layers would have to be accessible.
Often clients tend to give service providers a simple call, asking various legal questions about the possibility of drilling a well before even proposing a formal work order, it is useful if the administration or management department of the service provider can check on the current status of the area of interest. For example they should be able to determine if the desired location is inside a National Park, Provincial Park, Wilderness Park, Wilderness Area, or Wildland Park, and establish whether it is Exploration Restricted, has potential for coal development, whether there are significant historic sites and whether the client has the legal right to drill in the area.
The proposed system represents an attempt to implement the easiest method for updating the centralized data so that there should not be any additional training required for remotely located draftspersons to actively participate in the data update process. Once the spatial data has been stored in PostgreSQL/PostGIS it was simple to serve that out, after implementing the security layer, through WFS/WMS protocols using MapGuide Open Source. NAD83 and NAD27 UTM are the most popular geodetic reference projections as far as the clients are concerned but the NAD83(CSRS) / Alberta 10-TM (Resource) projection was the chosen projection because it has the capability of displaying the whole of Alberta in a single map. Most of the drawings drafted were based on the client requirements and, as a result, are in NAD83 or NAD27 UTM projections but for the centralized database the NAD83(CSRS) / Alberta 10-TM (Resource) projection was selected. For this system to be used in other jurisdiction the appropriate UTM projection would have to be used.
Raster Data Projection Transformation using GDAL
Raster data has its own importance in the field of GIS and in most cases helps managers and planners in the decision making process. One concern is how best to store such huge amounts of raster data and how to serve it to the client using an efficient method, especially when there are various projection systems (e.g. NAD 83 and NAD27 UTM) and there is a need, as in the case of our system, to serve the data as a single map using the NAD83(CSRS) / Alberta 10-TM (Resource) projection.
Many software packages provide the capability of transforming the original coordinate system on-the-fly for raster data but at a cost of efficiency to the overall system. As discussed earlier our drawings are time stamped and everything must be kept intact for future reference. Consequently, it was decided to have the server keep all the raster data in the NAD83(CSRS) / Alberta 10-TM (Resource) projection.
Since the GIS system is designed to rely on a CAD department it was again decided to find the easiest method to re-project the data from various projection systems to a NAD83(CSRS) / Alberta 10-TM (Resource) projection using open source technology. To keep the process simple for draftspersons a Visual Basic application was developed in combination with GDAL (Geospatial Data Abstraction Library) translator library that was written by GDAL team for raster and vector geospatial data formats and comes with a variety of useful commandline utilities for data translation and processing (GDAL, 2015). Using this Visual Basic application the user simply needed to select a raster file or, for multiple files, a folder of raster files, their input coordinate system, the destination folder and, finally, the output coordinate system. The Visual Basic utility read all the raster files, created a batch file for every raster in a temporary folder, ran the batch files, re-projected the raster, and saved the files into a destination folder (Figure 5). Finally, these newly created raster files were copied into the folder on the server. For further details please see our previous article titled Systematising raster data for effective image processing, discussing all the details about this process.
A document management capability was added to the enterprise GIS System by adding a new FTP server. This server’s main responsibility was to store all the PDFs and it was decided to add a quality control (QC) inspector. A new Visual Basic application was written to upload the PDFs from non-spatial database folders to the FTP server. Once a job number was entered by a QC inspector into the search dialog box of the PDF synchronizer it was possible to see all the PDFs stored during the whole life cycle of the job in question (Figures 6 and 7).
These PDFs included field notes submitted by the field crews, any relevant information provided by the client, and any previous plans for the same job. The QC inspector just needed to check the selected PDF and then the operator would press the synchronizer button to upload the selected PDFs. Another checkbox permitted the automatic deletion of all the PDFs associated with the job currently residing on the FTP server, alternatively when not selected it retained all the files. Since the Visual Basic utility created a new folder on the FTP server for the newly synchronized job, this location was easily specified as a tooltip in the MapGuide open source software. Accordingly, the user merely needed to use the built in ‘Ctrl + Click’ option on the feature to open a Uniform Resource Locator (URL) and the PHP file would run. Running the PHP file created a new session in the FTP server, opened a new window with a list of all PDFs as URLs, and allowed instant access to all the uploaded PDF files (Figure 10).
Coordinate Conversion Tools
Different companies and organizations use different coordinate systems for their various map based data. Consequently, surveying companies acquire this information from their clients in different coordinate systems when embarking on a new project. Coordinate information based on a client’s base map system would be given to a service provider in various forms that in our case range from Alberta Township System (ATS), NAD83 Geographic, NAD27 Geographic, NAD83 UTM, NAD27 UTM and sometimes NAD83(CSRS) / Alberta 10-TM (Resource) (Burrough and McDonnell, 1998; Gahegan, 1996). It was useful to have a web based utility that could be integrated easily into the existing GIS system and avoid the licensing problem that would result from the use of third party software. Such a utility would allow users to change their coordinate systems into the desired or target system. Because there is a relatively small number of coordinate systems utilized in the province of Alberta it was decided that an effective solution was to write our own code in PHP to convert coordinates from one system to another. Using PHP5 and its object oriented programming (OOP) techniques we created different coordinate conversion functions and then grouped all these similar functions into a Coordinate Conversion class to provide a better organization and also to allow for a common access point for these and similar functions.
The INTGRID (Interpolate Grid) Program is a program made available by Natural Resources Canada, Geodetic Survey Division, for converting geographic coordinates (latitude and longitude) or Transverse Mercator (TM) coordinates (Northing and Easting) from one reference system to another (http://www.geod.nrcan.gc.ca). This program, written in Fortran, produces analytical information, such as coordinate shifts, accuracies of the shifts, and grid cell distortions. For the sake of our internal use we converted this DOS-based, desktop application written in Fortran to PHP and included some major changes in the logic that produced an increase in efficiency when working in a client/server environment.
ATS (Alberta Township System) is a land surveying system extensively used to describe a location by different clients in the Canadian province of Alberta (ATS, 2015). Therefore we also wrote PHP functions to transform Lat/Long to ATS, UTM to ATS and ATS to Lat/Long, ATS to UTM so that our field crews could make effective use of these tools in almost all scenarios.
Access to Field Crews
An important objective of the proposed system is to give field crews access to the GIS system with its information on survey well sites, access roads and pipeline right-of-ways. The goal was to serve this information accurately and in a time saving manner, leveraging all aspects of recent advances in the fields of GIS and IT. Once the field crew’s surveying is complete, it was necessary to obtain approval from the ERCB, ensuring that the survey plan contains the information needed by the ERCB to satisfactorily process the application (for further details see the Alberta Land Surveyors’ Association website at http://www.alsa.ab.ca/.
Once connected to the GIS system surveyors are able to see the electronic map of the area of interest with layers from different internal and external data providers with all the required information, including aerial photography, well-sites location, pipelines, facility locations, and previously submitted plans. The requested information, as shown in the figures 8, 9 and 10 can be retrieved as a PDF document simply through the use of a control key.
Transparent Data Organization and Data Backup and Archiving
In this section three aspects of geospatial data are discussed: source, database, and application. At the source of geospatial data, stewardship is the generator’s primary responsibility, including ensuring quality and accuracy; performing updates and corrections as needed; and protecting the resources from accidental loss or security violations (Information Architecture Project 2001). However, at the larger level of the institution as a whole, the cycle of information management is broken and GIS coordination is difficult. The translation from small, semi-independent GIS teams to an institutional, EGIS is faced with many challenges, including duplication of facilities, lack of coordination, incompatible data format and architecture, inconsistent quality control and change control, and lack of data protection.
An understanding of these challenges is fundamental to a successful implementation (Keating et al., 2003). An EGIS requires an institutional effort in order to develop an integrated GIS database that will meet the needs of GIS applications across the various agency departments. It must focus on consistency, integration and extensiveness of agency-wide applications of GIS. If project-oriented GIS are considered the first generation of GIS, the EGIS can be called the second generation (Peng et al., 1998).
Tight integration of GIS within the organization eases the updating of data and the completion of the cycle of information management and storage of data at a single location. There are many advantages to storing data at a single location, including the simplicity of maintaining the integrity of the spatial data at a centralized location, the maintenance of a multi-user client/server environment, relationships, the availability of a rich collection of data types at a single location and, finally, the ease with the data can be backed up.
In the system described here, the GIS database was consistently backed up so the data could be restored without causing any major processing delay or downtime. Although there are basically three different approaches to backing up PostgreSQL data (namely a SQL dump; a file system level backup; and continuous archiving), we are currently using the SQL to dump the data to an external file while the database remains in production mode. PostgreSQL dump files are text based. Database dumps created by a pg_dump are internally consistent, that is, the dump represents a snapshot of the database at the time the pg_dump begins running (for more information http://www.postgresql.org/).
Reports are an integral part of any GIS. They help people from different departments to access and display the required data and maps. This straightforwardness in accessing the data also helps to improve the reliability in the centralized database, and reduces the time needed to create the reports. Therefore different custom reports were added to our system based on the requirements of the various users. Users are required to select the feature and information from different parts of the enterprise wide spatial database that would be displayed in predetermined formats. These reports were fully equipped with almost all of the advanced spatial operations including solutions to nearest neighbor queries, advanced spatial analysis, data integrity operations, distance queries, spatial joins and overlay analysis and even provided attributes from other business systems as a result of back and forth communications between these systems.
The Surface Development Report
The Surface Development Report provided a map that was used as a guide for field crews for gathering and confirming all surface developments for the well site. If there were no surface developments within the shown radius, surveyors needed to indicate where the nearest surface development was. The interface that was created for accessing the Surface Development Report is shown in Figure 11.
For many of our clients’ projects LiDAR data is an important resource. When using such data the client often requires rapid acquisition and delivery of dense, accurate, topographic point-based data. The availability of such data is an important consideration for many clients and can reduce the cost of the entire project. In addition, the client may require the servicing company to store LiDAR data for them. Depending upon the size of the project area, the level of detail of the elevation data and the format in which it is stored, this necessity may require significant storage capacity and a systematic retrieval facility.
The LiDAR data we receive from our clients is normally in 1 by 1 meter, grid point format that is used to create the ArcGIS TIN (Triangulated Irregular Network), Grid or DEM (Digital Elevation Model) (Waters, 2009). These can then be utilized to create an end product based on the client’s requirements. To handle these huge amounts of data few custom tools are essential to extract that data as required, and subsequently to transform and load the data into our centralized database with a fluent method for creating, managing and retrieving the metadata. Thus the next step towards managing the LiDAR data would be to create a Visual Basic utility in combination with PostgreSQL/PostGIS. PostGIS is an extension to the PostgreSQL object-relational database system which allows GIS (Geographic Information Systems) objects to be stored in the database. PostGIS includes support for GiST-based R-Tree spatial indexes (Kornacker, 1999), and functions for analysis and processing of GIS objects (Manual of PostGIS). Such a utility should be able to import the LiDAR point data efficiently with an additional geometry field using a default spatial reference system (SRS). The Spatial Reference ID (SRID) should then be used, based on the output data file requirement, to convert the projection of primary data to any other desired projection. As the LiDAR data is loaded, the proposed, Visual Basic utility should also update the metadata table with the required information.
The development of the Internet and associated, wireless technologies has assisted organizations in providing anywhere, anytime access to the most up-to-date information. When a worker or field operative is moving to an unknown area and making a search for spatial data, only maps can provide the desired information in a precise and concise way (Schmidt-Belz et al, 2002). Due to the current complexity of the MapGuide Open source AJAX viewer it is not available for mobile devices, so currently we are using OpenLayers to publish our GIS data for mobile devices with limited functionalities. In near future we are planning to extend the functionalities to serve our most valuable data effectively for mobile devices.
Enabling Emergency Response Planning (ERP) is used extensively by Oil and Gas organizations these days to assist in responding to any emergency situation. That sometimes includes evacuation plans using the nearest route, and so for the next phase of software development we have plans to incorporate pgRouting in our system to create ERP maps online. pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality.
Importantly, as the sophistication of these software systems develop, they must be constantly evaluated and feedback from users and clients should be acquired on an ongoing basis. A formal system for such an evaluation that recognizes the differences in modes of use and technical versus operational characteristics of the software solutions has been proposed by Kjeldskov et al. (2005) for mobile guides and is advocated here.
Shahid Raza, All-Can Engineering & Surveys (1976) Ltd.
Cameron Gartner, All-Can Engineering & Surveys (1976) Ltd.
Nigel Waters, Professor Emeritus of Geography, University of Calgary
- ATS 2015. Alberta Township System Explained. http://www.ags.gov.ab.ca/gis/map_converters/alberta-township-system-explained.html Last accessed November 2nd, 2015.
- Bray, R. 2008. Map Guide Open Source. Ch. 7, pp. 131-54 in G. B. Hall and M. G. Leahy, eds., Open Source Approaches in Spatial Data Handling, Advances in geographic Information Science 2, Springer-Verlag, Belin, Heidelberg.
- Burrough, P.A. and R.A. McDonnell, 1998. Principles of Geographic Information Systems, Spatial Information Systems and Geostatistics (Second Edition). Oxford: Oxford University Press.
- Gahegan, M. 1996. Specifying the transformations within and between geographic data models. Transactions in GIS, 1: 137-52.
- GDAL, 2015. GDAL – Geospatial Data Abstraction Library. http://gdal.org
Last accessed November 2nd, 2015.
- Gittings, B. 2009. Reflections on Forty Years of Geographical Information in Scotland: Standardisation, Integration and Representation. Scottish Geographical Journal, v. 125, #1, 78-94.
- Information Architecture Project, 2001. Glossary of IA Terms, Los Alamos National Laboratory, May 2001.
Last accessed November 2nd, 2015.
- Keating, G.N., P.M. Rich, and M.S. Witkowski, 2003. Challenges for enterprise GIS. URISA Journal, v. 15 (2), pp. 23-36. http://downloads2.esri.com/campus/uploads/library/pdfs/35777.pdf
Last accessed November 2nd, 2015.
- Kjeldskov, J., Graham, C., Pedell, S., Vetere, F., Howard, S., Balbo, S. and Davies, J. 2005. Evaluating the Usability of a Mobile Guide: The Influence of Location, Participants and Resources. Behaviour and Information Technology Volume 24, Issue 1, 2005, Pages 51 – 65.
- Kornacker, M. 1999. High-Performance Extensible Indexing. Proceedings of the 25th VLDB Conference, Edinburgh, Scotland. http://www.vldb.org/conf/1999/P65.pdf
Last accessed November 2nd, 2015.
- Meredith, P.H., 1995. Distributed GIS: If Its Time is Now, Why is it Resisted? In Onsrud, H.J. and G. Rushton (Eds.), Sharing Geographic Information, (New Brunswick, New Jersey: Center for Urban Policy Research, Rutgers), 7-21.
- Oppmann, R.S., 1999. An Organizational Model for Successful Enterprise GIS. In Enterprise GIS. URISA, Park Ridge, Illinois, pp. 44-52.
- Peng, Z-R, Groff, J. N. and Dueker, K. J., 1998. An Enterprise GIS Database Design for Agency-Wide Transit Applications. Journal of the Urban and Regional Information Systems Association, 10 (2) 46-55.
- pgRouting Last accessed November 2nd, 2015.
- Pinto, J.K. and H.J. Onsrud, 1995. Sharing Geographic Information Across Organizational Boundaries: A Research Framework, In Onsrud, H.J. and G. Rushton (Eds.), Sharing Geographic Information, (New Brunswick, New Jersey: Center for Urban Policy Research, Rutgers), 44-64.
- Raza, S. and Olsen, N. 2012. Systematising raster data for effective image processing
Last accessed November 2nd, 2015.
- Reid, J. and Martin, F., 2001. The open source movement and its potential in implementing Spatial Data Infrastructures. Paper presented at the International Symposium on Spatial Data Infrastructure, Melbourne, Australia.
- Rich, S., Das, A., and Kroot, C., 2001. Spatial data management in an Enterprise GIS. In Proceedings of Twenty-first Annual ESRI International User Conference, San Diego, CA, July 9-13, 2001.
- Schmidt-Belz, B., Zipf, A., Poslad, S. and Laamanen, H. 2003. Location-based mobile tourist services – first user experiences. In Frew, A. J., Hitz, M. & O’Connor, P. (eds.): Proceedings of the 9th International Conference on Information and Communication Technologies in Tourism, in Innsbruck, Austria, 2002, pp. 115–123, Springer, Berlin.
- Somers, R., 2002. Managing your move to Enterprise GIS. Geospatial Solutions, (12), 22-26.
- Tomlinson, R. 2007. Thinking about GIS: Geographic Information System Planning for Managers (Third Edition). ESRI Press, Redlands, CA.
- Waters, N.M. 2009. Representing Surfaces in the Natural Environment: Implications for Research and Geographical Education. Ch. 3, pp. 21-39, in Mount, N. J., Harvey, G. L., Aplin, P. and Priestnall, G., Eds., Representing, Modeling and Visualizing the Natural Environment: Innovations in GIS 13, CRC Press, Florida.