OGR

The OGR datasource allows you to take any OGR datasource -- such as a shapefile, PostGIS database, GML file, or other formats supported by OGR -- and use it as a backend for a FeatureServer layer.

The OGR layer requires a 'dsn' property and a 'layer' property. In many cases, the layer is part of the DSN. An example OGR configuration might look like:

[myshape]
type=OGR
dsn=/home/example/myshape.shp
layer=myshape

Dependancies:

• OGR
• ogr Python bindings

DBM

The DBM datasource uses anydbm combined with pickle to store features in a file on disk. It should work on any platform. A sample DBM configuration might look like:

[scribble]
type=DBM
file=/home/example/scribble.db

Depending on the system on which it is running, the internals of this database may be different.

Dependancies:

• None

DBM Extra Features:

• Allows for non-fixed attribute schemas: every feature can have a different set of attributes.
• Allows for the setting of a 'unique' property on the layer. If unique is set, features will be 'merged' based on this key on creation, instead of a new feature being created.

BerkleyDB

The BerkleyDB datasource is a subclass of the DBM datasource. It uses a BerkleyDB module for storage. The bsddb module is not available under OS X, however, this datasource should work on both Windows and Linux. It is recommended to use this datasource instead of the DBM datasource when possible.

Performance testing suggests that this datasource is approximately 25% faster than the default anydbm module on Linux.

A sample BerkleyDB configuration might look like:

[scribble]
type=BerkleyDB
file=/home/example/scribble.db

Dependancies:

• working bsddb module

PostGIS

The PostGIS datasource implements a direct connection to PostGIS. This datasource requires dsn parameter and a layer parameter. It also accepts a variety of optional parameters, some of which you may need to override the default value of, depending on your schema. Please see the example below for details.

A sample PostGIS configuration might look like:

[mylayer]
type=PostGIS
dsn=host=localhost dbname=mydata user=myuser password=1234
layer=mylayer
fid=gid #defaults to ogc_fid
geometry=wkb_geometry # defaults to the_geom
srid=26910 #defaults to 4326
attribute_cols=name,some_interesting_column #optional
order=cost #optional

Dependancies:

• psycopg or psycopg2

SQLite

A simple sqlite datasource.

Dependancies:

• None under Python2.5
• pysqlite under Python2.4

WFS

The WFS datasource implements read-only access to WFS servers. The following parameters are required:

• url
• typename

A sample WFS layer configuration might look like:

[wfs]
type=WFS
url=http://zuluviz.sdsu.edu:8080/geoserver/wfs
typename=topp:states

Dependancies:

• OGR
• ogr Python bindings

Flickr

The Flickr datasource loads data from geotagged Flickr photos. Filtering the results can be done by using any of the parameters listed at:

http://flickr.com/services/api/flickr.photos.search.html

For example, a flickr source limited to all photos which match all the tags 'mit', 'food', '2007' from the user with ID '56541240@N00':

::

[flickr] type=Flickr user_id=56541240@N00 tags=mit,food,2007 tag_mode=all

By default, this only shows public photos. To grant the datasource access to your non-public photos, you must fetch a 'read' permissions token from the API. You can use the Flickr.py as a command line application to do this:

$ ./FeatureServer/DataSource/Flickr.py Open the following URL in a browser: http://flickr.com/services/auth/?api_key=[...]&perms=read&frob=[...] Press enter when complete.

The result of this will be something like:

Your token is:

721576-5d6044

Add the following line to a Flickr data source to complete configuration:

auth_token=721576-5d6044

With this example, a Flickr datasource would look like:

[flickr]
type=Flickr
user_id=56541240@N00
auth_token=721576-5d6044

Twitter

Powered by Twittervision, the twitter datasource lets you use twittervision's API to display the current location of a user.

Very simplistic, doesn't do much.

[twitter-crschmidt]
type=Twitter
username=crschmidt

OSM

Allows for requests to hit the OpenStreetMap API to request data. No configuration neccesary. Only supports query-by-bounding-box and query-by-id: the latter will only search for 'ways', not nodes or relations. Relations are not handled at all.

It is possible to add an 'osmxapi=yes' option. This will use the OSM Extended API instead of the main API. This API may be several hours out of date, but it does allow attribute queries: see http://wiki.openstreetmap.org/index.php/Osmxapi . It does no support ID queries, and if one is sent, it will instead be redirected to the main API.

[osm]
type=OSM
osmxapi=no