Drupal Geo Stack

This wiki page is aimed at describing how to build the Drupal Geo Stack and how Drupal core and contributed modules can work together to create a full geospatial stack in Drupal that solves peoples problems around their use cases. This is NOT a list of modules, please refer to the geospatial module comparison wiki page for that.

• Goals
• Use Cases
• Libraries
  • Internal Data Format
  • Data Storage
  • Input
  • Visualization
  • Geocoding
  • Data Feeds
• Packaged Configurations
• Previous Discussions
• Other Resources

Goals

The goals of this page is to outline a general approach for the Drupal community to handle geospatial data and operations. This should be accomplished with the following general approach:

• Create, design, and support interoperable libraries that accomplish specific technological tasks well.
• Create, design, and support packaged configurations solutions (ie Features) that allow users to solve their specific use cases.

Use Cases

We need to start collecting use cases around these sorts of things to ensure we are building things in the right way. There is currently a Drupal Geospatial Use Case wiki page.

Libraries

The following are the general areas of geospatial operations where solutions should focus on. Overall, modules or solutions should only focus in one area and be interoperable with other modules. There is not necessarily any reason for there to be only one solution in each area, but the important thing is that they are interoperable.

Internal Data Format

A format for passing around data internally in Drupal. This is some sort of structure or object that can represent geospatial data and that can be passed around to different modules.

Currently, the Geofield module requires the geoPHP library. This is the closest to this sort of thing.

Some questions:

• Should this standard (or a different one) be abstracted to a single module that other modules depend on? (zzolo) I would say yes, so that a single project can focus on including a library or some API calls.
• Does it have to be a native standard in Drupal?
• Is this standard good? Are there others we can look at?
• What about GeoJSON?
• What about the idea between a data type and a full object (that can handle operations)?

Data Storage

This item is focused on how to store geospatial data in Drupal. Ideally, this would utilize native geospatial support in databases in order to leverage the performance gain of native queries.

In Drupal 6, the Geo module aims to do this.

In Drupal 7, there are some large changes to the database layer and structures such as entities. For Drupal 7, Geofield may be a better direction.

Some questions:

• Should Data Storage include data querying, such as proximity searches?
• Drupal 7 core still doesn't really handle extending data types, but can it handle extending PDO for geospatial query calls.

Some, if not all, of this should be in Drupal core. Drupal should be able to handle geospatial types. See this issue for geospatial data types in core.

Input

The mechanisms for inputting data. There are many different methods for inputting geospatial data.

Questions:

• How much can this be disconnected from data storage or other areas?

Visualization

This focuses on displaying geospatial data visually, such as with a map.

There are currently many different solutions in this area. It is hard to determine what is the best method for mapping. With more standard other libraries around geospatial tasks, a visualization solution can

The mapping module aims to abstract our the connection points with Drupal and contrib modules and provided a pluggable architecture to put mapping libraries on top of it (such as Google Maps or OpenLayers). Is this a good direction?

Geocoding

Geocoding is getting geospatial data, such as a lat/lon pair, from a non-geospatial source such as an address or an image.

I think this is an area that needs an abstract module architecture to plug different services into, as there are a number of different geocoding services and different types of data that services can handle.

Currently, the Geocode module attempts to provide this pluggable mechanism.

Questions:
* Support support for multiple provider in a single "geocode query" with a preferred order?
* IP address geocoding?

Data Feeds

Drupal geo data needs to be outputted outside of visualizations like maps. More than likely these solutions should be Views plugins. Since we already have the above storage and querying (in theory), formatting a Views query to be in a specific format seems pretty easy. It might make sense for each standard to have its own module to keep up with specs and handle other dependency.

Questions:

• Should this include a service like, WFS?

Packaged Configurations

This section could probably be renamed, but the idea is that once interoperable libraries are made, then there can be modules that are packaged configurations (ie Features) around solving specific use cases.

Previous and Other Discussions

A lot of this is based off bdragon's Drupal as a GeoCMS vision.

Other Resources

• It may be good to check out GeoDjango at is known to be a good comprehensive geospatial solution in Django.
• A simple Wikipedia article on the concept of a GeoCMS