I introduced just some of the many facets of this decision making process. I recommended that a trusted, experienced advisor could be consulted for help in navigating the marketplace and building an optimal solution.
In part two, I will briefly explore some of the most important questions to address before implementing geospatial technology, and then I will elaborate on an increasingly common question: whether to use a Web service to provide location intelligence or to build a solution and host the technology in-house.
What are some of the key issues that should be addressed when planning a location intelligence system?
Lets first address the advisory role and its value to the solution building process. What are the types of decisions with which a trusted advisor can assist? First, an informed and competent consultant should follow a particular methodology for collecting key requirements for the system. This involves stakeholder interviews, inventories of existing technology and human resource considerations not different from any other type of project. But there are fundamental considerations the geospatial planning process demands upfront.
COTS vs. Custom
One of the first decisions that will need to be addressed is whether to build a custom solution or leverage existing commercial-off-the-shelf (COTS) software. Out-of-the-box GIS packages should be employed to reduce the need for custom development as much as possible. Professional GIS packages can, however, be saturated with dozens of buttons, features and modules that require specialized training and are liable to confuse end users. Further, GIS packages can be expensive, leaving the opportunity for significant savings through the license-reducing potential of custom solutions. Custom solutions further afford the opportunity to implement only the two or three functions that may be required. After all, why buy a Swiss Army knife when all you want is the can opener?
How will your data become mappable?
Another fundamental consideration is how the organizations data will be mapped. To make your data useful in a location intelligence context, some data must have geometry attached to them geocoded, in the favored lexicon of GIS geeks. The most common type of geocoding is address geocoding. The advisor can help the client determine how often data change and what the required geographic extent is. Other questions involving the preparation and structuring of location data elements - such as whether or not addresses need to be validated and what is the desired level of accuracy for geocoded data - need to be resolved before any system design occurs.
Is street routing technology needed?
Another common need is for routing and directions. This is a domain that can rapidly develop its own set of considerations. For instance, are there multiple locations required for the routing (the traveling salesman problem)? Is there a logistical element that should be addressed, such as optimizing deliveries for a vehicle fleet? Routing and fleet management are rarely as simple as they appear, and it is important to have the proper expertise on board when determining a routing solution.
Is there a requirement for spatial analysis?
What if an organization needs to perform spatial analysis, such as a proximity query? Is it simple proximity, or network proximity? Perhaps point-in-polygon operations are required? Ill stop there, but this subject is easily one of the most misunderstood. Prospective buyers of geospatial technology should glean some degree of understanding before attempting to implement this type powerful analysis.
Will the system involve a demographic component?
The list of considerations expands when demographic information is required. Is there a need to generate custom demographic attributes based on territories or in-house data? What is the desired resolution of the demographic data? How up-to-date do the data need to be? Demographic data occupy their own domain filled with complexities and requirements.
When to use Web services and when to self-host location intelligence
I would like to focus on a relatively new alternative for building a GIS solution: a Web services-based system. This is a frequently encountered alternative when an organization begins exploring options.
Sometimes this decision can be black-and-white. For instance, a simple store locator application would not require an organization to build a complex GIS infrastructure. Alternatively, an electric utility that wants a large team of engineers to maintain its lines and substations should not be advised to pursue a Web services solution. There is, however, a vast gray area between these two extreme examples that requires more planning.
What are the questions that should be answered before pursuing a hosted Web services solution or building an in-house infrastructure? This is, like most business decisions, a multi-dimensional problem and there is no simple rule-of-thumb. But there are a number of fundamental considerations an organization should examine before moving on to the finer details. Some of these basic questions, listed below, discuss these first steps in the decision making process.
Will your applications always have access to the Internet?
While this might sound basic, some prospective users overlook the fact that the weakest link with a Web services solution is an Internet connection. Commercially available mapping Web services are accessed through the World Wide Web. A fast and reliable Internet connection is a prerequisite to any Web services deployment. If an organization has persistent Internet outages but a more stable internal network (intranet), then it should not consider a Web service solution. This is particularly relevant for those building emergency or homeland security applications where a network should be available even in rugged environments.
Does your data have rigorous security requirements?
Commercially available Web services allow uploading of custom data (some limited to point locations). But despite vendor disclaimers of rigorous security measures, this is still not acceptable for most organizations with sensitive or highly proprietary data. Some organizations might only require geocoding from a Web service, but most service providers log every transaction by IP address or username. Lets say a health organization is geocoding individuals who were diagnosed with an infectious disease. In this case, a Web services deployment would have created a database (albeit indirect) of highly confidential information off-site. If your data or application are sensitive, you should think twice about a Web services solution.
What usage volume do you anticipate?
Since the price of mapping Web services is based on transactions, sites with high traffic levels can become more expensive than purchasing a commercially available dataset and hosting it in-house. This varies widely between different pricing schemes, the geographic extent of the data needed, and the type of transactions you require from the service (will there be a lot of panning and zooming?). But there is a tipping-point where high-volume usage eliminates the savings of a Web service. A cost analysis would also include indirect factors, such as data maintenance costs, the need for a spatial module within your relational database, and the staffing requirements of maintaining the data in-house.
What type of data do you require?
Consumption of Web-based maps can be thought of using a vending machine analogy. A product (or map) is requested in exchange for a token or tokens. Although the dispensing mechanism is uniform, in this case the products are not. Some vendors charge proportionally for data accuracy and content. So a map created using, say, sub-meter imagery will cost more than a simple map consisting of political boundaries. If your mapping objectives require persistent visualization of finely detailed areas at high accuracy, the cost of a Web-based mapping solution could be prohibitive. Also, youll want to make sure the data you need are actually available. Maybe you want to see business locations in Albania, or maybe you just want to see municipal boundaries in Chicago its best to carefully inventory data availability and pricing before making any commitments.
Do you need sophisticated cartographic control?
Want water to be that certain blue? Cant live without your meticulously designed highway shield set? Commercial Web services provide large amounts of base map data, but often limit the ability to control the cartographic display of those data. If you have specific cartographic needs or must provide dynamic or custom symbology, these services may not meet your needs. Labeling map features can be particularly problematic and in some business cases can obscure important business data.
Do your applications require specific service level agreements?
Self-hosting your spatial data ensures that you have control over performance and availability. When considering a Web service solution, you should investigate what transaction speeds and uptimes are guaranteed (if at all) by the service provider. Mission critical applications merit additional performance and stability considerations.
Do you have intensive data editing requirements?
Web services can work very well where the map acts within a reporting context or is used strictly for visualization. But many geospatial applications require a transactional element where custom spatial data needs to be updated (moved, deleted or augmented). True, it is possible to build a mix of Web services and self-hosted data using SVG, AJAX and some other acronyms, but the limits of this arrangement are fairly narrow.
Do you have the budget to build and maintain a self-hosted GIS solution?
Lets face it, this stuff can be expensive and Web service-based solutions have provided a wonderful means of lessening the financial burden that geospatial technology can impose. Web services have lowered the barrier for entry for those who might previously have been priced out of the market. The additional hardware, staff, data and licensing that a self-hosted solution requires can become expensive compared to the alternatives of a Web services solution.
These are only the fundamental, high-level questions you should consider when addressing the dichotomy between Web service and self-hosted geospatial solutions. In the interest of brevity, I will not detail the finer points of this decision making process. This would include many more questions about the type of data the organization wishes to display. Furthermore, once you decide that a Web service is a good fit for your objectives, it will be necessary to decide which vendor to select. Vendor offerings vary considerably in price, definition of a transaction, content availability, functionality and programming interfaces.
A cherry on top?
Fundamental location intelligence considerations, such as geocoding, routing, spatial analysis and demographics, each require their own set of decisions. It is rare that an organization has expertise in any one of these, let alone in how they relate to one another. Even though we only touched on this decision making process, the Web services versus self-hosted solution paradigm demonstrated one such decision process. Location intelligence, however valuable, does present a number of choices and building a sundae out of these choices is no easy task. Selecting an advisor who can provide the type of insight that only comes with experience can help ease this situation.
I hope that this article provides a compelling case for the need to secure a trusted advisor to assist with the planning process. With that, Ill end this abused analogy with a cherry on top.