[ZMapServer-Developers] PrimaGIS design issues
Status: Alpha
Brought to you by:
sgillies
|
From: Kai <kai...@mb...> - 2005-05-13 21:23:03
|
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... |