1 of 33

Spatial data and maps...

A Drupal Perspective

Presented by Alex Parker @ Perth Drupal Meetup 6/8/2013

2 of 33

Scope?

  • Geographical Information Systems (GIS) are a huge topic. Let’s review.
  • Industry Standards (OGC’s WFS, WMS, WCS) - Good to know.
  • Data capture (LIDAR / LASER, satellite imaging, theodolites, etc) - Out of scope :’(
  • Backend (GeoServer, ArcGIS, MapServer, custom Drupal backend, etc) - In scope
  • Presentation & Manipulation (Openlayers, Leaflet, Mapstraction, etc) <- In scope

3 of 33

Scope - Brief:

  • Industry Standards - how GIS data is represented and communicated.

​

  • Backend systems - how GIS data is persisted and accessed.

​

  • Presentation & Visualisation - how GIS data is presented and displayed.

4 of 33

GIS Standards

Open Geospatial Consortium (http://www.opengeospatial.org/)

Standards for:

  • Maps (WMS)
  • Features (WFS)
  • Coverage (WCS)
  • Representation (GML / KML)
  • Business / Defense Intelligence
  • Emergency Services
  • Sensor Web Enablement (SWE)
  • Heaps of other stuff.

5 of 33

GIS Standards: SWE

Image source: Open Geospatial Consortium (http://www.opengeospatial.org/)

6 of 33

GIS Standards Summary

  • There are a lot of acronyms to remember
  • For most purposes, just a general awareness is needed.
  • The OGC website is the best resource for GIS standards.

More info:

http://en.wikipedia.org/wiki/Open_Geospatial_Consortium

http://www.opengeospatial.org/standards/is

​

7 of 33

Backend Systems

8 of 33

GIS Backend Options

Dedicated (e.g. Geoserver)

vs

Web Service (Fusion Tables, WebMap)

vs

Roll your own (PHP / Python / JS / PostGIS)

vs

Framework + Modules (e.g. Drupal, Zend)

​

9 of 33

Dedicated Backend Options

  • Dedicated (e.g. Geoserver).

Pros

Built for the job. Fast. Powerful. Consistent.

​

Cons

Domain knowledge required. In-house skills. Server resource requirements.

10 of 33

Web Service Backend Options

  • Web Service (Fusion Tables, WebMap).

Pros

Pre-built, just import-n-go. Server resource requirements offloaded.

​

Cons

Service provider lock-in. 3rd party business risk to measure, proprietary data formats.

11 of 33

Framework (e.g. Drupal) Backend Options

  • Framework + Modules (e.g. Drupal)

Pros

Some control & customisation, leverage existing functionality, use existing in-house skills.

Cons

At the mercy of 3rd party developers for quality code, features and updates.

12 of 33

Drupal 7 GIS Data

Storage: Custom RDMS

  • Custom RDMS storage

Pros

Full control over queries, potentially faster, fully customise functionality.

Cons

Kind of restricted to MySQL spatial extensions. PostGIS types and indexes would be nice.

Verdict

Would do this when performance is key.

13 of 33

Drupal 7 GIS Data

Storage: Use Modules

  • Use Modules

Pros

Easier to implement, basic skills required, leverage existing functionality.

Cons

As with any reliance on 3rd party code.

Verdict

Would do this when maintainability and ease of use are key. Which is most times.

14 of 33

D7 GIS Data Modules

Example

Three powerful friends:

​

​

A useful combo for geocoding addresses.

15 of 33

Geofield project

  • Basic in scope, well implemented
  • Supports features comprised of points�and polygons.
  • Well supported: views, GeoJSON, openlayers, leaflet, search, etc (see project page)
  • Supports inputs such as KML, WKT, direct entry of lat / lons, draw directly on a map, and HTML5 geolocation API.
  • Great community support, actively maintained.

16 of 33

Google Fusion Tables

  • Offload system resource requirements
  • Quick processing of many spatial queries
  • Some limits, e.g. queries only operate on the first 100’000 rows, limit of 1mb data returned per query, 5 million vertex limit.
  • Must use Google Maps API to access data
  • Still quite new, Drupal integration is very much custom coding.

​

https://developers.google.com/maps/documentation/javascript/layers#FusionTables

​

17 of 33

D7 GIS Data Summary

  • Storage of spatial data is quite easy
  • Manipulation may require some custom�queries and overrides.
  • Associate spatial data with metadata�with geofield project.
  • Fetch and present spatial data using views�plugins or custom queries.
  • Watch out for specialised modules that only offer a subset of features in hacky ways.

18 of 33

Now what?

  • How do we present data to the user?

19 of 33

Presentation options

  • Code it yourself

20 of 33

Presentation options

  • Use a single vendor’s library, such as google maps, bing, etc.
    • Limited to features provided by vendor
    • Restricted to a single vendor’s license / usage terms
    • May be easier to implement simple maps with basic features, like a store location or a collection that doesn’t require any filtering or manipulation.
    • You’re stuck if you want to switch providers.

21 of 33

Presentation options

  • Use an abstraction layer.
    • May lose some library-specific flexibility.
    • May gain additional abilities not present in vendor specific libraries.
    • Far easier to aggregate spatial data across different providers.
    • Can switch underlying service providers with ease.

​

Which web-friendly mapping abstraction layers exist?

22 of 33

Map Abstraction Layers

  • Google Maps
  • OpenLayers
  • Mapstraction
  • Leaflet.js

​

Among others...

23 of 33

Map Abstraction Layers

  • Google Maps - [The library]
    • Lots of functionality in the API for manipulations, calculations and representation.
    • Quite easy to customise with CSS.
    • Well backed by one of the biggest companies on the planet.
    • Plenty of documentation and support.
    • No direct support for WMS standards, must code tile fetchers yourself (see example at http://www.gisdoctor.com/v3/v3_wms.html)
    • If you want to switch to a different mapping engine, you will need to recode business and presentation logic.

24 of 33

Map Abstraction Layers

  • Google Maps - [Drupal Support]

Pros

    • Google map field - basic marker support, gmap module - views, location support (no geofield)
    • Actively maintained and supported, plenty of documentation, mature.

Cons

    • API V3 support still under development
    • OGC standards not readily supported.
    • Google API limitations & lock-in

25 of 33

Abstraction Layers: Openlayers

  • OpenLayers [The library]
    • JavaScript based, very portable.
    • Lots of functionality, well structured OO approach to layers and features.
    • Standard compliant, supports WMS / WFS / ISO projections.
    • Can be difficult to customise the appearance, uses some odd layouts at times, very much forces you to do things their way.
    • Very heavy, everything is in the one gigantic library that’s almost 700kb. Not fun to serve to users.
    • v3 is on the way, so let’s hope that fixes some of the issues.

26 of 33

Abstraction Layers: Openlayers

  • OpenLayers [Drupal support]

Pros

    • Geofield / Views integration
    • GeoField Input widgets
    • Decent admin config interface

Cons

    • Patchy views AJAX support
    • Heavy! Huge page load size
    • Tricky to customise beyond provided functionality
    • Accessing the map instances for direct API calls can be tedious

27 of 33

Abstraction Layers: Mapstraction

  • Mapstraction [The library]
    • JavaScript based
    • Is an abstraction layer over other libraries.
    • In theory, can quickly change the underlying engine from OpenLayers to Leaflet while keeping the same business logic.
    • Documentation incomplete.
    • Drupal project not updated since v6
    • Great concept, worth keeping an eye on.

28 of 33

Abstraction Layers: Mapstraction

  • Mapstraction [Drupal Support]
    • Haven’t personally tested.
    • Drupal project not updated since v6
    • Lacks support? Interested in feedback.

29 of 33

Abstraction Layers: Leaflet.js

  • Leaflet.js [The library]
    • JavaScript based
    • New kid on the block, only 3 years old!
    • Lightweight core - 31kb
    • Modular - pick and choose the features you want from a growing library of modules.
    • Clean CSS-able output
    • Easy to code
    • Not leaky - leaves your global namespace alone.
    • Mobile friendly - tap / pinch & zoom support.
    • Not quite as mature as other systems yet.
    • Not as feature rich (expect more modules).

30 of 33

Abstraction Layers: Leaflet.js

  • Leaflet.js [Drupal support]

Pros

    • Views support with leaflet project
    • Field formatters work well for basic needs

Cons

    • Too much functionality is hidden - e.g. try and access map features from a views leaflet display.
    • With more than a handful of features on a map, the generated GeoJSON in a view can be heavy, something like 2mb for 120 features in one instance.

31 of 33

In Summary

Personal opinions:

  • As a library, leaflet is the most promising option due to size, performance, standards compliance and features.
  • None of the drupal module implementations seem to shine - Modules become glorified library includers for advanced needs.
  • Any requirements for large data sets or complex queries? Code it yourself using the Javascript API’s directly.

32 of 33

In Summary

  • Storing and manipulating map features in Drupal is fairly easy with projects like GeoField.
  • If you have a choice, try to use an abstraction layer like Leaflet rather than a provider’s proprietary API, e.g. gmap.
  • Presenting map features for basic purposes is quite easy with projects like Leaflet.
  • Modules can hide API functionality too much, for better customisation use libraries directly.

33 of 33

TL;DR:

Drupal + Leaflet.js + Custom JS = Win.