[ZMapServer-Developers] PrimaGIS design issues

[Kai <kai...@mb...>]

Hi

I'm CCing the ZMapServer lists too in order to let people know about the
new ZCO/PrimaGIS mailing list that has been created. I would encourage
anyone interested in ZCO and PrimaGIS to join the new mailing list,
since we are moving the discussion there. You can join the new list at:
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/primagis



Yesterday we were talking about some use cases and future features for
PrimaGIS at #zco and I'd like to present them here in hopes of getting
some feedback and ideas.

For those not familiar with the PrimaGIS structure, it has two classes
that represent layers that can be rendered on the map: PrimaGISLayer and
PrimaGISDataLayer. PrimaGISLayer simply refers to layers in ZCO that
have datastores defined outside of Plone (e.g. shapefiles). From a Plone
point of view, PrimaGISDataLayer is the more interesting one, since it
allows spatial data created within Plone to be used and rendered on the
map and this is what I would like to discuss.

In our discussion we identified three scenarios how Plone content
objects could be used with PrimaGIS (through PrimaGISDataLayer):

1. "Dumb" content objects with geo-aware proxy objects
2. Geo-aware content objects with "dumb" proxy objects
3. Geo-aware content objects used directly as data for PrimaGISDataLayer

By "dumb" i mean non-geo-aware. The actual content object may be
arbitrarily complex. I'll explain each scenario below.

Scenario #1
----------
This is what we have currently and can be seen at the demo site. We have
GeoArchetypesProxy which is geo-aware (currently it knows only about
coordinates) and it uses the AT references mechanism to refer to the AT
content objects. The references are many-to-many by nature and a single
proxy object may reference multiple content objects and a single content
object may be referenced by multiple proxies (on a single or different
maps).

The main advantage of this model is that no changes are needed in the
content objects and it's possible to spatially extend sites that have a
large base of existing content.

Semantically, scenario #1 is best suited for objects that don't have a
natural spatial dimension. In this case, it is ok to store the spatial
information in the corresponding proxy object. While it is possible to
use this approach on any object, it would be much nicer to include the
spatial information within the objects that have a natural spatial
dimension.


Scenario #2
----------
In scenario #2 we would have objects that are natively geo-aware. The
proxy objects would be even simpler and they would only keep track of
the referenced objects. This doesn't differ from scenario #1 that much,
but would have better data encapsulation and would allow using the
spatial data within the content objects. Unless the content objects
supported multiple locations, this approach would change the
many-to-many relationship to one-to-many. The objects could still be
located on multiple maps, but they would only be in a single location.

The main advantage of scenario #2 comes out when a Plone site has many
natively geo-aware objects scattered around at different places. The
proxy objects can be used to gather these objects together to be used as
data for PrimaGISDataLayer without having to move them around.


Scenario #3
----------
Scenario #3 deals away with the proxy objects and uses the actual
content objects as data for the PrimaGISDataLayer. Again we deal with
natively geo-aware objects. This approach is most effective when the
content objects are located in the same place (e.g. a single folder). We
can simply point PrimaGISDataLayer to look for its data from this
location.=20

The main advantage of this approach is that if geo-aware objects already
define a logical collection (at least in a layer sense) of data, we can
simply use this instead of creating an additional (identical) grouping
with the proxy objects.=20



I believe each scenario has its merits and I'm planning on implementing
them all, since they are not mutually exclusive. There are some
technical consideration I would also like to discuss.

The proxy objects use the AT reference mechanism, which in turn uses a
dedicated catalog (reference_catalog) for implementing the references.
While catalog operations are (relatively) cheap, using the
object.getReferences() method returns the actual objects instead of just
catalog brains and this requires fetching them from the ZODB. Because
PrimaGIS shows information about these objects in the JS-popups, it
needs to fetch the objects from ZODB for every rendered map image. With
a PrimaGISDataLayer with a large number of data objects, this might
effect performance. This applies to both scenarios #1 and #2. The
objects will of course be cached, but I still feel this might be an
issue.

With scenario #3, it would be possible to query the normal site catalog
for the objects and possibly make do with the data available from the
brain objects. This would benefit performance, since we wouldn't have to
load the actual content objects (the currently used information: URL,
Title, Description is available in the brains). In the worst case we
would have to load all the objects which is the same as with scenarios
#1 and #2.

Eventhough the the reference mechanism may have some performance
penalties, it also has one very useful feature. Once an object is
referenced, you can move it around freely in the site without affecting
the reference link. So the PrimaGIS will continue to work regardless of
the location of the content object in the site.


A smaller issue is the containment of the proxy objects. Currently
PrimaGISDataLayer just allows the user to define a traversable path to
the location of the proxy objects. I plan to contain the proxy objects
within the PrimaGISDataLayer so the user doesn't have to know worry
about them. I'll leave the option for defining an external location for
the data so that scenario #3 is possible.

Finally, in order to have natively geo-aware objects that are compatible
with PrimaGIS, we need to either have some MixIn class or an interface
that AT developers can use when they design their AT classes.



OK, this ended being a lot longer than I thought it'd be, but at least
it helped me clear my thoughts :) If you feel that any of the scenarios
would serve your needs, please let us know.

cheers,
Kai


--=20
Kai H=E4nninen                  mobile:+358-44-541 9567
Software engineer             www.mbconcert.fi
MB Concert Ky                 kai...@mb...