Re: [ZMapServer-Developers] Fwd: Archetype wrapper products for ZCO

[Sean G. <sgi...@fr...>]

Yves, and all, I finally have comments.

On Apr 27, 2005, at 1:25 PM, Sean Gillies wrote:

> Begin forwarded message:
>
>> From: "Moisan Yves" <ym...@gr...>
>> Date: April 27, 2005 12:52:18 PM MDT
>> To: "Sean Gillies" <sgi...@fr...>
>> Subject: Archetype wrapper products for ZCO
>>
>> Hi Sean,
>>
>> Please forward to ZMapServer-developers.  IT promised they would try 
>> to
>> find out why I can't email directly to the list ...
>>
>> Thanx
>>
>> Yves
>>
>> Hi All,
>>
>> This is a call to arms for all those ZCO developers who want to have a
>> sharp and slick mapping interface in Zope/Plone.
>>
>> I would like to propose my view of sample content Archetype wrapper
>> products to Sean's ZCO so that Zope/Plone users can have their own map
>> profiles and all the nifty things a CMS is supposed to provide.  Some 
>> of
>> you may recognize my pet applications, but I tried to keep the subject
>> matter as general as possible.  I would *really* appreciate feedback
>> from the community and I would also like to know if people are doing
>> some stuff in their basements with ZCO that I (we !!) could leverage 
>> on.
>>
>> IMO, PCL 0.8.1 + ZCO 0.5 is pretty mature.  Of course there will be
>> stuff to connect to postGIS and certainly other nifty stuff (e.g. 
>> being
>> able to use another rendering backend, such as Agg or Matplotlib/Agg)
>> coming along but for all intents and purposes I believe Sean's work 
>> has
>> all that's needed in terms of basic map display in Zope.
>>
>> With the upcoming release of Plone 2.1 with all content types being AT
>> (ATCT) and with the current impetus among AT developers to bridge the
>> gap with Zope 3, I think AT (not CMF) is the way to go to develop
>> content objects.  CPS/Silva developers, speak up if that doesn't work
>> with you!
>>
>> What I am interested in are 3 AT products (names are only 
>> suggestions) :
>>
>>
>> - GeoDataContainer,
>> - GeoDataObject (or GeoDataDocument ?),
>> - OGCMapContext
>>
>> The scope of this email is about *content* types, that is things 
>> people
>> will work with TTW in the Plone interface.  For example, people will
>> want to add a new station, or a new GPS point, or a new Map Context
>> document etc.  I don't think there should be a "map" AT product to 
>> wrap
>> a MapRenderer, for example (but I may be wrong, especially if one uses
>> somtehing like CMFContentPanels to brush up a collection of products 
>> in
>> one nice UI).  Also, things like layers visible as a function of scale
>> won't be controllable in the content space (only through ZMI).
>>
>> The basic mechanism I see for now is that AT content products would
>> override the attributes necessary for ZCO to work (e.g. bbox, layers
>> ...).  Controls over actual map generation and viewing space (map 
>> view,
>> choice of layers, zooming/panning, automatic legend generation ...)
>> would be thru-the-ZMI.
>>
>> ==== GeoDataContainer ====
>>
>> Purpose : provide a general geodata container.  The definition of
>> containment for such an object would have to rely on some bbox or some
>> WKT representation : we are talking about geographical containment 
>> here,
>> although it would be paralleled in the CMS as a mere object 
>> containment.
>>
>> Use Case :
>>
>> - for content developers (ContentAdmin, see Glossary below): derive 
>> from
>> this object, e.g. to get a Watershed object; contained objects could 
>> be
>> other instances of GeoDataContainer (e.g. for a "SubWateshed") in 
>> which
>> the bbox (and other attributes ??) could be overridden;
>>
>> - add GeoDataObject instances (see below), e.g. point measurements,
>> station locations, etc; there should be validation to make sure such
>> GeoDataObject instances are within the WKT or bbox defined by the
>> container object.
>>
>> Implementation :
>>
>> - derive from the base folder schema (option of a BTreee folder ??) 
>> and
>> add a bbox string attribute (and other attributes ??); maybe a WKT
>> representation would be better than a bbox, like Sean mentioned in an
>> earlier email; in that case we would need to provide either a simple 
>> WKT
>> edit form or else allow uploading vertex data from a shapefile thru 
>> OGR
>> ??  MapRenderer would use WKT to derive a bbox automatically.
>>
>> ==== GeoDataObject ====
>>
>> Purpose : provide a general geodata object.  Would be contained in a
>> GeoDataContainer (or could be independent ??)
>>
>> Use Case :
>>
>> - for developers : derive from this object, e.g. to get a
>> "PointMeasurement" or a "StationLocation" or whatever.
>>
>> "Add GeoDataObject" or a derived object would prompt the user with an
>> edit form with potentially FGDC metadata info ...
>>
>> Implementation :
>>
>> - derive from the base document schema and add a bbox or WKT string
>> attribute
>>
>> ==== OGCMapContext ====
>>
>> Purpose : Provide an object (folderish ?) to hold one's mapping
>> preferences.
>>
>> Following index_html and especially mapping_html from Sean's ZCO demo
>> folder where the page templates are calling themselves upon form
>> submission and showing some default layers if selected_layers == None,
>> we could just add a TAL condition to check for the existence of a
>> context document upon first form post (not upon postback though ...).
>> The resulting UI effect could be that all layers are shown and only
>> those in the context document are ticked on.  The user can always tick
>> layers on/off and zoom/pan away, but the default would come from some
>> context.  We could even show a dropdwon of all available context
>> documents so that predefined set ups could be readily available to 
>> users
>> (e.g. inherit one from their group membership for example).
>>
>> Independent of GeoDataContainer ??  Maybe but not of the general 
>> mapping
>> context of the application, defined by the available ZCOLayers etc.
>>
>> NOTE : "context" now replaces "here" in TAL expressions, so we should
>> refrain ourselves from talking about "context" documents ...
>>
>> Use cases :
>>
>> - users could "Add OGCMapContext" in their member folder; they would 
>> be
>> prompted an edit form to add all relevant information : bbox, layers 
>> (a
>> dropdown list based on SiteAdmin choice of layers), title ?.
>>
>> - users could copy/paste such documents to some accessible directory 
>> for
>> other users to go fetch it (or just point to it) or somehow share it
>> through group membership
>>
>> - users could edit their OGCMapContext (but beware of overriding
>> previous versions of the object : maybe some Plone version product 
>> could
>> be used here)
>>
>> - users could eventually export their OGCMapContext documents as an 
>> XML
>> OGC context document (maybe we could build on Zope's export as XML
>> functions here, modulo an XSLT transform ??)
>>
>> Is there a need for a ZCOMapContext object ?  I don't think so, since
>> defining a context just means overriding bbox and layers (symbols?).
>> There is definitely a need to keep session information to allow a user
>> to "Save Current Mapping Context" though.
>>
>> Implementation :
>>
>> - derive from the base document schema and add a bbox or WKT string
>> attribute and a layer string attribute; do we want to provide layer
>> ordering options as well (e.g. "Add New Layer" would add a new layer
>> string attribute and it would be a matter of calling ZCO with a string
>> concatenation of those layers in the order specified by the user) ??
>> For now, I would tend not to do that and basically let the user choose
>> the layers they want as it is currently done in index_html, which 
>> would
>> store the concatenated string.  Same is true for Symbols : in the 
>> short
>> term, I would not give the user the possibility to upload whatever PNG
>> they want to represent a station or a geological cross section : 
>> symbols
>> should be accessible from the SiteAdmin only (ZMI).  Allowing full
>> control over one's symbols and map layout falls in the realm of 
>> desktop
>> apps IMO.
>>

Yves, I am liking this approach very much, and think that we could get 
an AT product going quickly if we focus first not on map and layer and 
symbol archetypes, but on archetypes for the actual content.  Features 
and their attributes.

My first need for such an AT product won't require any user 
manipulation of layers at all: all that is needed is for portal members 
to create new points and regions, and have these features show up 
immediately in a pre-defined map.


>> ==== Zooming/Panning Utilities : Javascript ! ====
>>
>> We need a nifty zoom/pan interface.  Where are those JavaScript
>> experts??  All we would need is to call the zoomMap/shiftMap Python
>> Scripts found in Sean's demo with JS.  Should be easy right ??  Sean
>> proposed a look ala Google Maps (with all pan directions grouped in 
>> the
>> top left corner).  A zoom slider would be neat to : it would be a 
>> matter
>> of calling zoomMap with a zoom factor.
>>
>> I tried playing with Javascript in the <head> of a ZPT, but I found 
>> out
>> that using the Plone machinery to render (e.g. fill-main) effectively
>> bypasses any information in the <head> of any particular ZPT.  I found
>> that out when I tried to add a <style> in the <head> : it wouldn't
>> render and I had to put it in ploneCustom.css for it to work; same 
>> holds
>> true for JS in Plone, but I don't know where to stick it : somebody on
>> this list must know!.
>>
>> ==== Data Access Utilities : AJAX !? ====
>>
>> Clicking on a point, we need to have a means of outputting some
>> attribute data or calling in some simple data visualisation goodies
>> (tables, plots ...).  I don't know how to tie this in yet, but we need
>> to think of some framework.  AT provides an alternate storage 
>> mechanism
>> so data could be stored in a postGIS back end for example so we would
>> need an AJAX strategy to fetch data from such a backend (that is get 
>> the
>> data without having to redraw the map).
>>
>> Since Plone 2.1 will ship with Kupu as a default editor and since Kupu
>> heavily relies on AJAX (Asynchronous JavaScript And XML) to work, 
>> there
>> should be ample example code to implement an AJAX solution for data
>> retrieval.
>>

My demo application was intended to be as simple as possible and 
javascript free.  the shiftMap and zoomMap Python Scripts are 
completely arbitrary and not necessarily what we want to use with a 
richer UI.

A rich UI is essential for the success of a Plone ZCO product.  
Something that is in harmony with other Plone products like Kupu.


>> ==== Action plan ====
>>
>> I can take on AT development (at least set the wheel turning!) unless
>> someone has stuff I can build upon.  It would be great if other folks
>> could take Zooming/Panning Utilities and Data Access Utilities.  I 
>> guess
>> the former can be readily addressed, but I don't know about the 
>> latter.
>> IMO, a nice zooming/panning experience is key in promoting Sean's nice
>> work.  It would be nice if we had some repository for code so that
>> Sean's demo site (or any one else's) can show it off.
>>
>> So, what is going on out there with you ZCO developers.  Does this 
>> make
>> sense ?
>>
>> Thanx for your comments !
>>
>> Yves Moisan
>>

It seems to me that what we may be lacking is a site on which to 
collaborate.  I could set up a Plone instance on my zcologia.org site 
for this purpose.  Yves, which version are you using at work?  Should I 
wait until the 2.1 release?

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies