Re: [ZMapServer-Developers] ZCO and Plone/CMF

[Arnaud B. <arn...@ma...>]

Sean Gillies wrote :
> On Jan 22, 2005, at 1:52 PM, Arnaud Bienvenu wrote:
>> So I think you definitely got it right implementing proxy objects.
> 
> 
> Have you taken a look at the demo/zdata/points_catalog DataStore in the 
> ZCO demo application?

I just did, nice work Sean :-)

> This geom property can be a simple feature represented in OGC WKT (well 
> known text) format.  Could be a point or a line or a polygon.  This 
> feature was added for a specific Zope application where the programmer 
> is using ZClasses to represent various project sites and project offices 
> around the world.  The OGC simple features specification also includes 
> MULTI* geometry types which would be useful for documents that are 
> related to a number of locations.
> 
> Attaching this property to Zope objects is intended to turn the ZODB 
> into a spatial database, like PostGIS/PostgreSQL or ArcSDE or 
> OracleSpatial, and the Zope Catalog is easily used to find 
> spatially-located objects.  To me, this seems to provide Geo-awareness 
> in a manner that is consistent with other GIS data sources.  And it also 
> allows users to spatially enable their existing applications by simply 
> adding a new property.
> 
> Of course, this is a bit harder with Plone because we can't just add 
> arbitrary metadata to a Plone object.  Correct?

Yes, you need to modify the code of the object. Anyway I do not think 
that some "geom" property should belong to Plone metadata, because Plone 
users will never learn OGC WKT.

Actually, we could make a portal-wide tool (for Plone, CPS, or other) 
that provides a user-friendly interface (zoom, pan, click) to edit the 
"geom" Zope property. This interface would be accessible through a 
"localize" tab on any object whose type has been declared as localizable 
in the portal configuration. Does this sound reasonable ?

Using a Zope propery is smarter that adding a python object member, 
because is does not require code modification of the content product. 
And I must admit that it is much simpler than using proxy objects.

However, I do not believe that "turn the ZODB into a spatial database" 
will become a reality, in the sense that WKT properties of Zope objects 
will never be queryable. If they need spatial queries, people will use 
spatial databases (PostGIS...). So I guess our portal tool should also 
be able to read/write into such a database instead of editing the "geom" 
Zope property.

Cheers,
-- 
Arnaud Bienvenu
Makina Corpus