SocialGeo¶

Effective sharing of geographic data is a long standing problem. Myriad organizations and individuals collect and maintain geodata, and it’s challenging to discover data sources in any particular location or around a particular theme. The traditional “solution” is to fall back on ad-hoc social networks, informal connections among GIS professionals. If you need data, pick up the phone or drop an email to a friend at another agency. If you’re lucky, there’s an email list. But what if your colleague is on vacation? Or has left their job? Or what if you’re deploying to a new region? How do you know who is working there and what they have to offer?

There are a number of active technical developments for sharing geodata. Cataloging systems like GeoNetwork, application frameworks like GeoServer, hosted sharing services like GeoCommons, and even the web itself, with Google indexable KML. Technical infrastructures are essential, but only supply part of the solution. SDI (Spatial Data Infrastucture) concepts propose a combination of technical, access, schemas, and organizational agreement, but such approaches have proven unwieldy and slow moving. What OpenStreetMap has demonstrated is that the key to enabling sharing and collaboration is a strong community. Through active discussions lists, wikis, and crucially real life meetups, the social connections in OSM are the glue that make it work. To replicate the success of OpenStreetMap more generally, a platform for sharing must be social. Social networks like Facebook and Twitter enable sharing a wide scale; open source projects like Crabgrass and Drupal enable sharing in specialized communities of interest.

This initiative aims to connect systems for cataloging, storing, distributing and visualizing geodata with systems for connection human beings. Through either the social or geo interface, information about identities and permissions of users are retained, and the social interface gives a rich set of views and actions on the geodata. The work can be divided in a number of phases, starting with experimental, specific instances of this concept outlined below. From these implementations, issues and questions will direct development and adaptation of standards for connecting these systems. From there, the goal is to build abstract libraries that allow for compatibility between any arbitrary piece of geospatial and social software.

Instances¶

GeoServer + Crabgrass¶

GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards. It has an active developer and user community, and is primarily supported by OpenGeo.

Crabgrass is a software libre web application written in Ruby on Rails, designed for social networking, group collaboration and network organizing. It also has an active developer and user community, particularly in activist communities and the UN, and is primarily supported by RiseUp.

From Crabgrass, a new “tool” will be developed to interface with GeoServer. A tool is a special kind of plugin in Crabgrass that inherits properties of ownership and permissions. Tool creation and update allows for the upload of geodata sets. The tool will interface with the GeoServer REST API to store the geodata; on creation, Crabgrass will store reference ids returned from the GeoServer API.

You can put a zipped shapefile, and it’ll automatically create a featureType. The weak part right now is styling, since if you don’t have styling in that step then you get a bunch of boring looking geodata, just a default black style. GeoServer has plans to improve this, starting with their Styler. The initial phase can just have this basic rendering.

GeoServer itself has an authentication system; for this initial phase, a single account will be available on the GeoServer install for the entire Crabgrass install, and all access will go through this single account, with Crabgrass managing the specifics of which people and group can modify, view, and download particular data sets. Another potential way to limit access to GeoServer is to stick in behind a firewall, and allow the Crabgrass access through a proxy.

Each geodata page in Crabgrass will feature an OpenLayers slippy map to easily browse the data. Basic openlayers embedding in other systems is easy, and WMS Reflector with openlayers output format makes it super easy. Given a data id, GeoServer has the ability to serve a complete OpenLayers instance through its WMS interface. Groups will also have a home page widget, which allows group members to select from the available data sets, and display a map with a number of togglable data layers. Some of the access restriction on GeoServer might need to be loosened up at this point, to get the WMS request working.

This specification is a only guideline for work, and it’s expected that during the course of the project, the specifics will change and adapt.

GeoServer + Drupal¶

GeoCommons + Crabgrass¶

Standards¶

GeoRSS, KML, WMS and Tiles are used to share geodata on the open web
AtomPub and RESTful APIs used for Creation/Update/Deletion in databases
OpenID, OAuth for authentication and authorization
OpenSocial for defining profiles, memberships, and permissions

Future work¶

New instantiations of the SocialGeo pattern in various platforms. Full sharing of identities and permissions from social systems to geo systems.