Commit graph

6 commits

Author SHA1 Message Date
Dane Springmeyer
bc4a74f5b0 python plugin: catch and report exceptions, closes #1422 2012-10-19 17:05:51 -07:00
Manel Clos
8f7083d14d Add tolerance parameter to features_at_point
Make map.query_point() always pass tolerance to datasources
2012-09-28 15:12:10 +02:00
Dane Springmeyer
b81f8f0ee8 link the python plugin to libpython by default 2012-08-22 10:39:49 -07:00
Dane Springmeyer
cc1ddc3015 simplify linking logic in python plugin fixing os x install (where we do not want to link the plugin explicitly to python) 2012-08-06 06:32:41 -06:00
Rich Wareham
16ffdf1fb5 python plugin: remove useless Makefile 2012-07-31 17:07:11 +01:00
Rich Wareham
156a7590f4 python: a new plugin to use arbitrary Python as a data source
This plugin allows you to write data sources in the Python programming language.
This is useful if you want to rapidly prototype a plugin, perform some custom
manipulation on data or if you want to bind mapnik to a datasource which is most
conveniently accessed through Python.

The plugin may be used from the existing mapnik Python bindings or it can embed
the Python interpreter directly allowing it to be used from C++, XML or even
JavaScript.

Mapnik already has excellent Python bindings but they only directly support
calling *into* mapnik *from* Python. This forces mapnik and its input plugins to
be the lowest layer of the stack. The role of this plugin is to allow mapnik to
call *into* Python itself. This allows mapnik to sit as rendering middleware
between a custom Python frontend and a custom Python datasource. This increases
the utility of mapnik as a component in a larger system.

There already exists MemoryDatasource which can be used to dynamically create
geometry in Python. It suffers from the problem that it does not allow
generating only the geometry which is seen by a particular query. Similarly the
entire geometry must exist in memory before rendering can progress. By using a
custom iterator object or by using generator expressions this plugin allows
geometry to be created on demand and to be destroyed after use. This can have a
great impact on memory efficiency. Since geometry is generated on-demand as
rendering progresses there can be arbitrarily complex 'cleverness' optimising
the geometry generated for a particular query. Obvious examples of this would
be generating only geometry within the query bounding box and generating
geometry with an appropriate level of detail for the output resolution.
2012-07-31 17:05:27 +01:00