Category Archives: plone

3D virtual gallery for Plone

Today we released version 1.0 of hexagonit.virtualgallery which provides a Flash based 3D gallery view for images. The meat of the package is a Flash viewer which renders images as framed paintings on the walls of a gallery. The viewer is configured using a JSON configuration and such has no direct Plone dependencies, you can easily use it in a Pyramid, Rails, or whatever web project.

The original use case for the gallery was part of a larger art related project we are working on but due to its generic nature we decided to open source it and release it separately. By default the Plone integration in the package provides views for Folders and Collections allowing you to easily control which images are placed in the gallery. It is also very easy to integrate the gallery in custom use cases where more control over the images is needed.

Additionally, you can configure the viewer on a gallery (context) basis by choosing which image scale should be used within the gallery. This is particularly useful if you are storing larger images (for example digital originals) but wish to make the gallery load up faster using a smaller scale for it.

We’d be interested in hearing out any feedback or ideas about the package!


Posted by on August 26, 2011 in plone, python


Snowsprint report

Once again the annual Snowsprint hosted by Lovely Systems was a great experience. This was my second time to attend the sprint and I enjoyed it very much. The scenery at the Austrian alps is just amazing. I even managed to hold off catching the cold only after the sprint this time 🙂

Alternative indexing for Plone

This year I wanted to work on subjects that I’m not the most familiar with. On the first night I expressed interest in the alternative indexing topic proposed by Tarek Ziadé which lead us to work on an external indexing solution for Plone based on the Solr project. Enfold Systems had already started on working with Solr on a customer project and Tarek had arranged with Alan Runyan to collaborate on their work. Tom Groß joined us in our work and our first task was to produce a buildout that would give us a working Solr instance. We ended up creating two recipies to implement the buildout: collective.recipe.ant, which is a general purpose recipe for building ant based projects (kind of like hexagonit.recipe.cmmi for Java based projects, although you can use ant for non-Java projects just like make), and the Solr specific collective.recipe.solrinstance, which will create and configure a working Solr instance for instant use.

Enfold Systems had already a working implementation of a concept where the Plone search template ( was replaced by their own which implemented the search using only an external Solr indexing service. However, everything was still indexed in the portal_catalog as usual, so there was no gain in terms of ZODB size or indexing speed compared to a vanilla Plone site. Querying the Solr instance was of course extremely efficient which we verified using a JMeter based benchmark later on. We wanted to experiment on replacing some indexes from portal_catalog with Solr and try if we could gain any benefits in ZODB size or indexing speed.

As anyone who is at least a bit familiar with portal_catalog will know, replacing the whole of it can be a bit difficult because of special purpose indexes such as ExtendedPathIndex, which Plone heavily relies upon. So we decided to try if we could replace the “easier” indexes with Solr and have the rest be in portal_catalog. This would mean that we would need to merge results from both catalogs before returning them to the user. We did this by replacing the searchResults method in ZCatalog.Catalog.

To test our implementation we generated 20,000 Document objects in two Plone instances each and filled them with random content (more on this later) and compared the ZODB size, indexing time and query speed. The generated objects resulted in roughly 100 Mb worth of data and the size difference was about 8 % in favor of using Solr. Since we didn’t test this further with different data sets, I wouldn’t draw any conclusions based on this except to notice the (obvious) fact that externalizing the portal_catalog makes it possible to reduce the size of the ZODB to some degree. I know that some people use a separate ZODB mount for their catalogs so using an external catalog may be a good solution in some cases. The indexing times didn’t have much difference, but they were slightly in benefit of Solr. Querying our hybrid ZCatalog/Solr index turned out to be much slower than either ZCatalog or Solr by themselves 🙂 I’m sure this was because of our non-optimized merging code that we did in searchResults.

In the end, I think the approach Enfold Systems originally had is the correct one for near-term projects. Querying Solr is very fast and indexing objects in both the portal_catalog and an external Solr instance doesn’t produce much overhead. If you need a customized search interface for your project with better than portal_catalog performance you should check Solr out. The guys at Enfold Systems promised to put their code in the Collective for everybody to use, including our buildout.

zc.buildout improvement

Godefroid Chapelle had a proposal to improve the zc.buildout so that you can use buildout to get information about the recipes it uses. After discussing the matter with Godefroid and Tarek and a quick IRC consultation with Jim Fulton we decided to prototype a new buildout command — describe — that would return information about a given recipe. Jim Fulton expressed his desire to keep recipes as simple as possible so the describe command simply inspects all the entry points in a recipe egg and prints the docstrings of the recipe classes. If the functionality is merged into mainline buildout, recipe authors should consider putting a description about the recipe and the available options in the docstrings (something that we currently see in the PyPI pages of well disciplined recipes).

The code is in an svn branch available at The following examples are shamelessly ripped from Tarek’s blog

$ bin/buildout describe
    The coolest recipe on Earth.

Multiple entry point support

$ bin/buildout describe
    The coolest recipe on Earth.
    No description available

Random text generation with context-free grammars

The alternative indexing topic required us to generate some random content in our test sites and both me and Tarek found doing this quite interesting on its own. After the other work was finished we started playing with an idea of creating a library for generating random text based on context-free grammars. You can read Tarek’s post on the library for more information. The end result was that we created a project on called Gibberisch which currently contains some random text modules and a Grok interface called Bullschit 🙂

I worked with Ethan Jucovy on the Grok interface and which was great fun. Since this was our last day project there were really no serious goals. We just wanted to play with Grok and ended up building a RESTful interface for building up a grammar and then generating random content out of it. If you’re working on a RESTful implementation I can recommend using the RestTest add-on for Firefox, it’s a real time saver!

Basically, Bullschit models the grammar using Zope containers so that you can have multiple different grammars in one application, each grammar consists of sections that contain parts of sentences (in the context-free grammar) called Schnippets. You can use the basic HTTP verbs: POST, PUT, GET and DELETE to maintain the grammar and generate the random text.

For our presentation we hooked in the S5 slide show template to produce endless slides of total gibberisch. You can have even more fun by using the OSX speech synthesizer (or any other for that matter) to read aloud your presentation! Here’s an example of a slide generated with Bullschit and S5.

Presentation with Bullschit & S5

If you’re interested in giving it a go, you can get the code using git.

$ git clone git://

For those interested in Git, don’t miss the recent 1.5.4 release!

1 Comment

Posted by on February 3, 2008 in plone, zope


Improved zc.buildout recipes with ZopeSkel

Today I worked with Tarek Ziadé on ZopeSkel. Tarek concentrated on refactoring the ZopeSkel layout to put each template in its own module and wrote doctests for all available templates. Go Tarek! The test runner actually runs tests in two layers: first testing the output of the generated items and then, if the items contain tests themselves running them also.

I concentrated on improving the template for creating new zc.buildout recipes. Many useful recipes suffer from lacking documentation and an unappealing front page on PyPI. I refactored the template to include a common set of documentation files, such as CHANGES.txt, README.txt, CONTRIBUTORS.txt etc. and added code that puts all those documents nicely together to produce a serious looking ReST document that looks good on PyPI. So now its up to the recipe author to just fill in those files accordingly.

To help recipe authors and especially people new to zc.buildout I also added comments in both the documentation files and the code to help on implementing the recipe and especially on how to document it so that other people are able to use the recipe in their own buildouts. To me, one of the most importart parts of a recipe’s documentation is the list of available options and their semantics. Looking at the PyPI pages for zc.buildout and zc.recipe.egg you can easily get information about the component. I’ve also tried to do the same with my own recipes (hexagonit.recipe.cmmi, The template provides a stub for documenting the options in the README.txt file that authors can fill in.

I also created a minimal doctest for the buildout. While being only a skeleton the test actually runs a buildout using the recipe so you can run the test case for the recipe right after ZopeSkel is finished generating it. This should help recipe authors to get started with testing the recipe while they implement it.

In addition I updated the trove classifiers to appropriate values for a buildout recipe and added support for getting the trove classifier for the license to be added automatically in the file. So now when paster asks for a license for the recipe and you answer, for example, ZPL you get ‘License :: OSI Approved :: Zope Public License’ in your automatically. This code is actually in zopeskel.base and you can easily re-use it in the other ZopeSkel templates. Just take a look at how the recipe template uses it.

If you haven’t used ZopeSkel before, give it a try!

$ easy_install ZopeSkel
$ paster create --list-templates
$ paster create -t recipe collective.recipe.foobar

If you want to try the recent changes, you need to get ZopeSkel from the collective.

There’s been lots of interest in ZopeSkel here at the Snowsprint so expect to have cool new templates there soon!

Update: 25.01.2007

ZopeSkel 1.5 was released which contains the latest changes.


Posted by on January 22, 2008 in plone, software engineering, zope


PrimaGIS sprint report

The Plone Conference was held in Naples, Italy this year and, as expected, was a great experience. Like last year in Seattle, we had a PrimaGIS focused sprint where a group of people worked on the next version of PrimaGIS which is based purely on Plone 3.0.

We had a list of sprint topics that people were able to choose from listed at the official sprint page. Below is a breakdown of the sprint activities, what was accomplished and what is still left to do.

OpenLayers integration

One of the biggest changes in the upcoming PrimaGIS version is OpenLayers integration. I had initially planned that OpenLayers would be used as an alternative user interface for PrimaGIS, but after a thorough introduction and discussion with Josh Livni we decided to use OpenLayers as the sole interface to PrimaGIS and retire the old custom one. I believe that this decision will serve us well in the future and the resources of PrimaGIS developers can be put to better use without having to worry about the map UI. The OpenLayers developers seem to be doing an excellent job at that and we’re grateful to use their work.

Currently the OpenLayers view works fine but there is little user configurability. The next step is to refactor the code so that the UI can be configured using user friendly forms and to make it easier for power users to customize the relevant parts. We also want to hook in the more advanced OpenLayers features such as spatial feature editing.

We also implemented TileCache support for PrimaGIS, so that people can easily configure their TileCache servers to improve PrimaGIS performance. Each presentation layer is able to produce a TileCache configuration section that can be copy/pasted to your TileCache configuration file.

Sean Gillies participated remotely and implemented support in PCL for the Python Geo Interface which allowed us to pull in feature data using all geometry types (point, line, polygon) directly into OpenLayers. Thanks Sean!

Big thanks also to Josh Livni for giving a lightning talk on using OpenLayers maps (including examples on FeatureServer and WPServer), for helping me to understand OpenLayers a bit better and working on the actual integration during the sprint!

New layer classes

Partly inspired by the OpenLayers and partly by the changes made to PCL and ZCO we decided to refactor the PrimaGIS layer classes. Previously there were two types of layers: PrimaGISLayer and PrimaGISDataLayer. PrimaGISLayer was used to create a map layer from spatial data from outside of Zope and PrimaGISDataLayer for data from within the ZODB. In either case it was difficult to share layers between multiple maps.

It had always been a goal to get rid of the artificial difference between the layers and data layers and adding support for sharing layers between maps seemed a good idea also.

The new types of layers are: Layer and Presentation Layer. A Layer class is a combination of what PrimaGISLayer and PrimaGISDataLayer used to be. It is used to select the data source where spatial data is acquired and to define the styling of the spatial features. It doesn’t matter whether the data comes from within Zope or not. The difference is that Layers don’t need to be located within Map objects. They can be located anywhere on your site and shared between multiple maps. A map administration may choose to have a folder where all Layers are stored but this is a totally arbitrary choice.

A Presentation Layer is an object that is stored within a Map object and refers to one or many Layer objects. It is tied more tightly into OpenLayers concepts such as a layer type which can be either base, overlay or vector layer. Each presentation layer is available as a Web Map Service (WMS) layer and renderable by OpenLayers. Connecting multiple Layers into a Presentation Layer allows you create composite layers that can be switched on and off as one. Below is a simple diagram that shows how the different objects are tied together.

PrimaGIS object relations

Buildout for Linux distributions

Alessandro Amici took on the daunting task of refactoring the primagis.buildout into an alternative buildout configuration that can take advantage of installed system libraries. By default, primagis.buildout builds all the required components from scratch which is a process that can more than an hour even on a modern machine.

The new buildout simply assumes that a given set of packages is installed system wide and compiles the rest of the dependencies against those. Currently the buildout provides a list of debian packages that users of Debian based distributions (such as Debian or Ubuntu) should install prior to running the buildout. See README-deb.txt in the buildout source tree for more specific instructions.

Eventhough the new buildout configuration was put together for Debian based distributions it is also usable on other distributions if a similar set of dependency packages are available. Users of other distributions are invited to contribute a list of packages suitable for their distributions.

The implementation of the buildout, which was initially estimated to take less then an hour :), turned out to be much more complicated task due to packaging bugs and differences in libraries between Debian and Ubuntu. We even created a new buildout recipe to help with working with C-libraries which Alessandro released as bopen.recipe.libinc. Users of 64-bit distributions should give the buildout a try since there have been reported problems when compiling some of the dependencies by hand on these systems.

Demo product

Sune Woeller and Chris Calloway worked together on a new demo product for PrimaGIS called zgeo.primagisdemo. The idea is to provide a similar effect to the script found in the previous versions. However, instead of putting the demo map in PrimaGIS itself, a separate product was created that sets up the map using a GenericSetup profile for content import. This is still work in progress so stay tuned for a release announcement soon!

Once it’s ready you can simply copy to package into your python path and run the GenericSetup import step to get a PrimaGIS demo in your Plone site.

Remaining tasks

There are still a few items I would like to see in PrimaGIS 0.7.

  • Persistent data stores and symbolizers
  • Better OWS properties management view
  • Spatial index for ZODB data
  • Feature inspection
  • Feature editing

On most items the work has already been started and some are are a simple matter of hooking into the functionality provided by OpenLayers.

Thanks again for all the people who participated in the sprint! It’s always great to people meet you know from IRC in real life.

1 Comment

Posted by on October 19, 2007 in GIS, plone, primagis


Orderable formlib form fields

The zope.formlib is the form framework in Zope 3 that makes it easy to generate browser forms using Zope 3 schemas and perform validation on user input. This is of course something what we’ve come to expect using using existing tools like Archetypes schemas and CMFFormController. The good news about formlib is that you can already use it in Plone (and we do so extensively in the Plone 3 version of PrimaGIS).

One of the advantages of formlib is that you can easily take multiple schemas, throw them into a single form, select the fields that you want to include in the form and have formlib automatically handle the different schemas by adapting your content object accordingly when saving the data. Although formlib matches up very nicely to Archetypes generated forms (if you ignore the small amount of fields/widgets available for formlib compared to AT) there is one feature in Archetypes that does not exist in formlib: field reordering.

In Archetypes, you can take an Archetypes.Schema.Schema instance and reorder fields programmatically using the Schema.moveField() method, e.g.

>>> from Products.Archetypes.atapi import Schema, StringField
>>> schema = Schema((StringField('a'),
...                  StringField('b'),
...                  StringField('c')))
>>> schema.keys()
>>> schema.moveField('c', before='a')
>>> schema.keys()
>>> schema.moveField('a', pos='bottom')
>>> schema.keys()

Moving fields around is usually necessary when you’re (re)using an existing Schema defined somewhere else and wish to modify it for your own use. Having to define a new schema (by copying code) simply to get the form to display fields in a different order would feel like a waste of resources so having the ability (and a nice API) to modify existing schemas is useful.

For this reason I implemented an enhanced version of the zope.formlib.form.Fields class that supports reordering formlib fields using an API almost identical to the one in Archetypes. The package is called hexagonit.form and is available from the Cheeseshop.

To use the enhanced version, you simply use hexagonit.form.orderable.OrderableFields in place of zope.formlib.form.Fields in your code. Below is a dummy example demonstrating its use.

We first need to declare a simple schema for which the form will be generated.

>>> from zope.interface import Interface
>>> from zope.schema import TextLine, Bool, Int

>>> class ISomeSchema(Interface):
...     text = TextLine(title=u"text field")
...     boolean = Bool(title=u"boolean field")
...     integer = Int(title=u"integer field")

Now that we have a schema, we can generate the form fields using hexagonit.form.

>>> from hexagonit.form.orderable import OrderableFields
>>> form_fields = OrderableFields(ISomeSchema)

The form_fields variable now contains your normal formlib fields with the additional moveField method that allows reordering the fields on the fly.

>>> [field.__name__ for field in form_fields]
['text', 'boolean', 'integer']

>>> form_fields.moveField("boolean", direction="up")
>>> [field.__name__ for field in form_fields]
['boolean', 'text', 'integer']

>>> form_fields.moveField("boolean", position=2)
>>> [field.__name__ for field in form_fields]
['integer', 'text', 'boolean']

>>> form_fields.moveField('boolean', before='integer')
>>> [field.__name__ for field in form_fields]
['boolean', 'integer', 'text']

The moveField method allows reordering the form fields in a variety of ways using the different keyword parameters:

  • direction parameter with values “up” and “down” for changing the position of the field relative to its current position
  • position parameter with values “first” and “last” (or alternatively “top” and “bottom” ) or using absolute positions with integer values (first field at position 0) to place the field in a specific position
  • after and before parameters to place the field in a position relative to another field.

The doctests in the package describe the functionality of the moveField in full detail. An actual form implementation would look something like this in Plone:

from Products.Five.formlib import formbase
from hexagonit.form.orderable import OrderableFields
from somewhere import IMySchema, MyCustomWidget

class MyAddForm(formbase.AddFormBase):
    # Instantiate the form fields
    form_fields = OrderableFields(IMySchema)

    # All normal functionality of zope.formlib.form.Fields is
    # available, such as [field].custom_widget, .omit(), .select() etc.
    form_fields['somefield'].custom_widget = MyCustomWidget

    # After setting up the fields you can reorder them according
    # to your needs
    form_fields.moveField('somefield', position='last')
    form_fields.moveField('otherfield', direction='up')

    # Rest of form implementation follows..


The easiest way to install and try hexagonit.form is to use easy_install:

$ easy_install hexagonit.form

You can also manually download the egg or the source tarball from the Cheeseshop page.

1 Comment

Posted by on February 15, 2007 in plone, zope


PrimaGIS in Plone 3.0

Up to (and including) version 0.6 PrimaGIS has been a traditional Archetypes based project. Almost all map components (maps, layers, symbolizers, etc) were modelled and implemented as AT content types.

Having all the components be full-blown AT content types made development easy up to a certain point but also at the same time made the objects unnecessarily heavy. Also, most map components are not content-like by nature and thus, for example, having them all support Dublin Core and be indexed in the portal catalog is unnecessary.

The next major version of PrimaGIS is based on Zope 3 components.

Using the Component Architecture

The Zope 3 Component Architecture made it relatively easy to remodel the map components as light-weight domain objects . In most cases we are now able to use objects from the Python Cartographic Library (PCL) directly, where earlier versions needed to define wrappers around these PCL objects. One reason for this is that PCL uses zope.interface internally, so useful interfaces are already defined and available for use.

In Plone 3.0 map renderers, spatial data stores and feature symbolizers are registered as utilities in the Component Architecture using ZCML. The components are registered using custom ZCML directives defined under the namespace. For details on the custom directive implementation you can refer to the and files in the ZCO codebase.

Map renderer

A map renderer is a component that is responsible of rendering the final map image given a collection of map layers (and some metadata). The current map renderer in PrimaGIS is based on the MapServer project. It is registered using the following ZCML code:


which registers the MapServer based renderer as an unnamed utility providing cartography.styles.interfaces.IMapRenderer.

In the future we can also support other map renderers and swap them transparently by registering them instead of the MapServer renderer — without having to modify any existing map setups.

To acquire the map renderer in code we can now simply do:

>>> from cartography.styles.interfaces import IMapRenderer
>>> from zope.component import getUtility
>>> renderer = getUtility(IMapRenderer)

Spatial data stores

Data stores are components that provide the spatial data for map layers. Data stores can be divided into two categories: feature stores that provide vector data and raster stores that provide raster data.

The data stores are registered using custom ZCML directives. Each type of data store has its own parameters, but all are registered as named utilities providing Below is an example of a Web Map Service (WMS) data store registered in ZCML.

    name="NASA Jet Propulsion Laboratory WMS"

For a more comprehensive set of examples see the datastores.zcml.dist file in the ZCO codebase. Registered data stores can now be easily acquired in code:

>>> from import IDataStore
>>> from zope.component import getUtility
>>> datastore = getUtility(IDataStore, "Name of data store")


Feature symbolizers determine how selected spatial features are rendered on the map and in concept are similar to CSS rules. In a similar manner the symbolizers are defined and registered using ZCML. The four different types of symbolizers: point, line, polygon and text symbolizers, are each registered using their respective ZCML directives.

The symbolizers get registered as named utilities providing cartography.styles.interfaces.ISLDSymbolizer. Below is an example of a line symbolizer defined in ZCML.


For a comprehensive set of examples see the symbolizers.zcml.dist in the ZCO codebase.

Maps and Layers

Maps are composite objects that contains one or more layers. Each layer draws data from a spatial data source and determines the styling (using rules and symbolizers) applied to its spatial features. For maps and layers there is benefit in modeling them as content types, for example to be able to apply workflow to maps or individual layers or allow the layers to be managed using the default folder management methods.

For this reason, and primagis.layer.Layer are Archetypes derived content types. However, the AT schema mechanism is not used to manage the configuration of the components themselves, but used only to manage the content like attributes such as Dublin Core metadata. This gives us a nice separation of concerns between the content related attributes and the actual mapping attributes.

The map configuration forms are implemented using Zope 3 schemas and formlib. There are some custom schema fields and widgets that make it easier to manage the mapping specific attributes, such as bounding boxes. KSS has also been used to make the editing screens more user-friendly. In the future KSS might also be used in the map view also.

Web Map Service (WMS)

The Web Map Service support makes it possible to share and re-use the imagery produced by PrimaGIS in other WMS compliant clients such as, for example, uDig, OpenLayers, and PrimaGIS itself. OpenLayers is of special interest to PrimaGIS since it allows us to provide an alternative UI for PrimaGIS itself.

OpenLayers uses a tiled approach where the map image is put together by tiling multiple smaller images requested from the WMS server. It also provides a nice Google Maps like panning mode previously not available in PrimaGIS.

The WMS support is implemented as a Zope 3 view registered as wms for primagis.interfaces.IMap. This means that you can just point your WMS client to an URL like http://domain.tld/path/to/primagis/@@wms.

For an efficient WMS implementation we will need to be able to cache the rendered tiles, possible using an existing solution like TileCache.

Future work

Below are listed some features (in no particular order) I would like to see in PrimaGIS.

  • Persistent local versions of data stores and symbolizers
  • Management UI for the local data stores and symbolizers
  • Cached WMS requests
  • GeoRSS support
  • Better OpenLayers integration / configuration support
  • Spatial indexing
  • ZODB datastores

Posted by on February 12, 2007 in plone, primagis, zope


Snowsprint 2007

The fourth (and my first) Snowsprint was held in Bregenzerwald, Austria during 27.03. – 3.2.2007. Altogether 56 developers attended the sprint from 14 different countries who worked on a variety of topics including calendering, multimedia, KSS, GIS, REST, textmate extensions, and caching.

The Gasthaus Hirschen where the sprint was held at proved to be everything one could hope for and the great common room was just the right environment for a week of intensive brain storming and coding.

My goals for the sprint were to learn more about the upcoming Plone 3.0 and to continue on the work on the next major version of PrimaGIS. In earlier sprints in Dublin and Seattle we had already refactored the Cartographic Objects for Zope (ZCO) and PrimaGIS using the Component Architecture of Zope 3 and now it was turn to work on the Plone UI for PrimaGIS.

I had decided to use Zope 3 technologies as much as I could, which meant I would be using Zope schemas and formlib for all forms in PrimaGIS. I also wanted to learn how to implement custom schema fields and widgets using formlib. This all turned out to work quite well, although the Zope2 publisher and security mechanism required to do some acquisition trickery to make everything play nicely together.

One exciting new feature of Plone 3.0 is the KSS (Kinetic Style Sheets) framework (found in the plone.kss and packages), which makes it extremely simple to do cool AJAX style programming without having to touch Javascript at all. I took part in the KSS tutorial given by Godefroid Chapelle and Balázs Reé which helped to get started working with KSS really fast. This turned out especially useful in implementing the custom formlib widgets.

In addition to the UI work I also worked on an experimental Web Map Service (WMS) server implementation for PrimaGIS. In Zope 3 terms, this simply meant that I needed to implement a view for the object that implements the WMS specification. The immediate benefit of implementing WMS server support is that then PrimaGIS maps may be reused by any standards compliant mapping client totally independent of Zope and Plone.

For PrimaGIS itself the WMS support means that, for example, it’s now possible to chain multiple PrimaGIS maps together so that one PrimaGIS instance is able to use the data provided by another. Another cool thing was that we can now provide alternate UIs for the PrimaGIS maps. As an experiment I integrated the Open Layers Javascript UI into PrimaGIS which worked right out of the box. All this code is still very experimental and in the future we will need push most of it into OWSLib and have PrimaGIS use that to implement WMS support.

I will post more detailed entries on how the Plone 3 version of PrimaGIS works and how it differs from the current version. For now you can check out the code at the following branches:

or alternatively use the primagis.buildout system to build a development instance (using the --develop switch) which contains the latest code.

Many thanks to Lovely Systems for hosting a great sprint. See you next year!

1 Comment

Posted by on February 6, 2007 in plone, primagis, zope