zmapserver-developers — ZMapServer Developers List

[ZMapServer-Developers] Fwd: Comments about the ZCO document

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

One more from Yves ...

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: February 4, 2005 8:54:37 AM MST
> To: <sgi...@fr...>
> Subject: Comments about the ZCO document
>
> Hi Sean,
>
> Please allow me a few comments in relation to your document :
> http://zmapserver.sourceforge.net/ZCO/manual.pdf.
>
> First, I must say this is a very well thought out architecture.  I find
> it very rigorous in attempting to make objects as simple as possible 
> and
> because you rely a lot on interfaces, which is in agreement with what I
> think (with my very limited knowledge of patterns) to be the singlemost
> important software design pattern : the expert pattern.  If I recall
> well, following the expert pattern one identifies object's
> responsibilities in terms of what object is the "expert", IOW which
> object holds the data or information to perform the task.  All in all,
> it does not require much mind twisting to understand why property X
> belongs to object Y.
>
> At this point, I'll make some general remarks.  More technical stuff
> will come as I actually start hacking.
>
> In order to grasp the project, I reworked the ZCO diagram with the
> following aims :
>
> - put the focus on the Layer object, since it's the only one that has
> georeferencing (I think this is a particularly important point to
> stress!); to show that, I tried to center the Layer object in the
> diagram
>
> - repurpose the diagram in a time/object space (more on this below)
>
> - time axis : in order to give some sort of feel of time I added a time
> dependency axis; The resulting diagram is a mixture of a
> conceptual/class diagram as your original diagram was and an activity
> diagram.  The usefulness for me lies in that the diagram shows there
> can't be a Layer if there are no "previous" DataStore and Style objects
> (and no style if there is no previous Symbolizer), no Image without a
> previous Layer and no View without a previous Image.  I know this may
> sound trivial (you wouldn't include a style object in a layer if there
> were no style object to begin with) but I fin dit useful to see this in
> t diagram.  Note : Any objects that are along a particular value of the
> time dependency axis (e.g. DataStore and Style) are independent of each
> other relative to time.
>
> - object axis : Orthogonal to the time axis, I drew an object 
> dependency
> axis; if you look at the relative positioning of the Style and Layer
> objects, you can see a that there are components to both the time and
> object dependency axes; it's not all that rigorous in the sense that I
> did not try to modulate the strength of the dependencies (e.g. by the
> distance along the particular axis); I just wanted to get a feeling for
> the objects in that particular analysis space.
>
> I tried to (but couldn't) illustrate the idea of "foreigness of
> resources".  I wanted the diagram to somehow convey that both the
> DataStore and Symbolizer objects, although they are true ZCO objects,
> could point to foreign resources (e.g. a postGIS layer for the
> DataStore, some XML definition file for Symbolizer).  The fact that
> DataStores and Symbolizers can be shared with any number of Layers and
> Styles suggests they are good candidates to be factored out of Zope in
> certain cases, e.g. when some normalization organization comes up with
> SVG icons to represent things like fire hydrants or whatever the
> Symbolizer can point to some third-party namespace.  In contrast, Style
> and Layer objects are ZCO things that won't point to foreign (external)
> resources.
>
> Not shown in your original diagram are the "Views" object and more
> specifically the relation between those views and the Image and Layer
> objects.  It would be nice to give a bit more context to the idea that
> "Layers" are separated from "Views".  I don't know how all of this is
> tied yet, but I would think a view is made up of 1..N layers.  The
> relation in the diagram between View and Image objects would be
> interesting to position, even approximately at this stage.  IMO,
> combining views would render the diagram pretty much complete from a 
> ZCO
> developer and user point of view.
>
> Please find an OO document attached to illustrate my thoughts.  One
> thing I haven't done is to quantify the relationship ends between
> objects (it's my first go with OO drawings and it's not quite like
> SmartDraw, but close!).  I think it would help if the relation between
> DataStore and Layer is quantified both ways, that is 1 .. * (DataStore
> -> Layer) and 1 .. 1 (Layer -> DataStore).
>
> Also, I think we need to think about objects (or how to modify current
> ZCO objects) that could help developers cater for user specific needs 
> in
> the form of *profiles*.  For example, if user X is part of group Y and
> if it were possible to associate a particular "view" (I am not talking
> about the View object here, but rather of a view in general) to group 
> Y,
> then all members of group Y would see the default (profilewise) view of
> the group.  The user could further customize the default view and save
> his new profile.  I don't know how that can be worked out, but it seems
> pretty easy to see how containment could help us define default views
> all the way from the Plone (Zope) root object and beinn overloaded on
> the way into the Plone object.  An example for the petrol company 
> stated
> in a previous email : the default view for the root of the site would 
> be
> the entire geographical domain in which the petrol company operates
> (e.g. your map of Europe in the demo), then as we move to regional
> offices a default regional view would override the previous one etc.
> There should be a provision to disable the automatic loading of the
> current folder-related view (e.g. a user in the local town XYZ does not
> want to change the map portlet he has built because he is wandering
> about the company web site and happens to be at a national level ...).
>
> That's it for now.  I've got a bit more doc reading to do and I should
> be starting playing around with ZCO soon.
>
> Cheers,
>
> Yves

[ZMapServer-Developers] Fwd: SVG/GML matchup

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

Forwarded on behalf of Yves Moisan who is the victim of overzealous (I 
hope) or incompetent network administrators :)

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: February 7, 2005 10:07:31 AM MST
> To: <sgi...@fr...>
> Subject: SVG/GML matchup
>
> Hi Sean,
>
> I'm getting more and more acquainted with PCL/ZCO and I now have a
> better feeling for the origin of the class design of PCL looking at the
> pointer you make to OGC's GeoAPI.  Good thing we can get rid of
> getters/setters in Python indeed!
>
> I think a lot of the things I would ultimately want can be done by
> Python scripts on the filesystem (e.g. your examples of DataStore and
> Styles). BTW, I find this a pretty clever idea to allow such user
> extensions via the filesystem!  Since I'm rather obsessed with 
> standards
> (I know I'll have to calm down a bit at least in the first iterations
> ...), I was trying to find URL's pointing to standard symbol sets on 
> the
> internet in a bid to provide a filesystem based wrapper style object
> providing the necessary Python interface (and eventually having a local
> application to synchronize with the third-party symbol list).  I 
> haven't
> found any yet but I was thinking it could be interesting to start
> building "open standardized" symbols.  I found some standardization of
> geological symbols at the FDGC, but it does not seem to be very active
> (proposed document in 2000 ...).
>
> One interesting avenue could be to use SVG for symbol definitions.
> There is plenty of resources on carto.net to help one build symbol
> definitions in SVG and I also found this URL which demonstrates the
> combined use of GML and SVG :
> http://www.svgopen.org/2004/papers/VisualizingEditingGISdatawithSVG/
>
> Quote : " As GML is not for data display, SVG is an ideal vector 
> graphic
> for displaying geographic data. GML sets at the backend to store and
> transport data and on the other side SVG sets on front end to render 
> and
> display geographic data. They not only can visualize geographic data on
> the web, but also give the possibility to edit geographic data online."
>
> I think using GML as a transport layer only could be good enough if the
> data store is in ZODB.  There could be the equivalent of 
> AsGML()/AsSVG()
> for Zope objects, in which case it could be relatively easy to combine
> data stored in the ZODB with data stored in PostGIS, for example, and
> the backend would be abstracted from the GML (i.e. it wouldn't have to
> store data as GML per se).  Imagine a Zope-based WFS service : we'd ask
> for data, Zope would get data from any number of DataStores and
> everything would come out as GML.  For client Zope applications
> (displaying maps), data could be requested to DataStores AsSVG().  I
> don't know where AsGML()/AsSVG() functions would belong in your class
> diagrams for now but my feeling is that those would be very useful
> utilities.  Or else ZCO could be responsible for AsGML() only and leave
> the SVG transformation to an external XSLT engine like mod_transform
> (which uses libxml2 AFAIK) ??  I guess that boils down to what 
> GeoClient
> offers : SVG rendering of a WFS.
>
> What do you think ?
>
> Yves
>

Re: [ZMapServer-Developers] Re: update: feature querying for PCL and ZCO

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

Etienne,

On second thought, I should clarify.  The iterator I am writing now=20
can't immediately give you the bounds of *all* selected features.  To=20
know the bounds we would have had to already finish the iteration.

Here are a couple proposals:

1) have FeatureStore.features() return not an iterator, but a=20
collection of features with a bounding box attribute.  This should be=20
used for results with a relatively small number of features.

2) return the iterator from a different method for use with very=20
numerous results.

Boy, PCL is becoming more like geotools every day :)

Will this suit you, Etienne?

Sean


On Feb 3, 2005, at 7:22 AM, Etienne Desgagn=E9 wrote:

> Hi,
>
>
>     It seems very interesting for me. I will try it as soon as I will=20=

> get it.
>
> I have one question, I want to know if it will be possible to access=20=

> the spatial
> attribute of a selected feature like (ex: left, right, top, bottom=20
> coordinate)
> for developping a zoom to selected feature function?
>
> Thanks a lot and continue your great work!
>
> Etienne
>
> Selon Sean Gillies <sgi...@fr...>, 02.02.2005:
>
>> Hi all,
>>
>> Following up on my email about ogr.py ... the primary reason why I=20
>> want
>> to use this module is to support feature querying in PCL (and thereby
>> ZCO).
>>
>> I am about 1/2-way through the querying api that I would like to
>> release as PCL 0.7.  Right now there is a WFS-ish means of getting
>> features from disk data stores (through ogr.py).  I'll do the same =
for
>> in-memory data stores next and then defer querying features from
>> external data stores (like WFS or PostGIS) until later releases. =20
>> Chris
>> Holmes has expressed interest in ZCO as a WFS client and so I might
>> that up to him :)
>>
>> Here's how the feature querying API will work, example below comes=20
>> from
>> data.IFeatureStore:
>>
>>      def features(properties=3D[], filter=3DNone, maxfeatures=3D0,=20
>> **params):
>>          """Return an iterator over filtered features
>>
>>          Provides a WFS-ish means to query a store for features.
>>
>>          Attributes
>>          ----------
>>          properties : []
>>              list of property names to be returned with the feature.
>>
>>          filter : filter.Filter
>>              An instance of Filter.
>>
>>          maxfeatures : int
>>              Default value of 0 means all features.
>>
>>          params : mapping
>>              Mapping of key=3Dvalue parameters that can be added into=20=

>> the
>> locals
>>              namespace for evaluation of PythonFilters only.
>>
>> calling the features() method of a FeatureStore gives you an iterator
>> over stored features, each item of which is a (geom, attributes)=20
>> tuple.
>>   The iterator will filter features depending on the "filter"=20
>> parameter
>> above.
>>
>> We're going to have two kinds of filters:
>>
>> 1. A very verbose and recursive filter, a fairly literal adaptation =
of
>> the OGC's Filter Encoding spec along the lines of Geotools2
>>
>> 2. A filter as Python expression as exist now in the expressions of
>> cartography.mapping.Rule.
>>
>> The second is for convenience and will only be useful for local disk
>> data stores.  The more complete filter (#1) will allow us to create
>> full SQL queries to PostGIS or XML requests to an external WFS=20
>> service,
>> two cases that can let us offload feature queries onto highly=20
>> optimized
>> servers.  I am also expecting that the #1 filter will provide a good
>> basis for filter-generating web widgets.
>>
>> For you, Etienne, here is an example of the PythonFilter syntax:
>>
>>>>> pyfilt =3D filter.PythonFilter('f.FIPS_CNTRY =3D=3D "UK" and
>> g.BBOX(-20,25,60,75)')
>>>>> features =3D store.features()
>>>>> for (geom, attributes) in features:
>>>>>     ... # do something with features
>>
>> Assuming you have the same world countries data as me, this gets you=20=

>> an
>> iterator over all the U.K. countries within the specified bounding=20
>> box.
>>   Feature attributes are stuffed into an "f" object (as I've=20
>> documented
>> under Rule filters) and feature geometries are represented by the "g"
>> object.  I'll be implementing the full complement of spatial =
operators
>> to go along with BBOX, such as intersects, within, contains, etc.  =
The
>> ogr.py module will be used to evaluate these operations.
>>
>> Will that work for you, Etienne?  And the rest of you?  Does anybody
>> have strong feelings about features being a tuple rather than an
>> object?
>>
>> If you want to play with this, you can check it out from CVS.  Will
>> require the GDAL/OGR software and installation of the Python modules.
>> Take a good close look at the rewritten PCL/setup.py file too.
>>
>> thanks for letting me think out loud here :)
>> Sean
>>
>> --
>> Sean Gillies
>> sgillies at frii dot com
>> http://users.frii.com/sgillies
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive =
Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> ZMapServer-Developers mailing list
> ZMa...@li...
> https://lists.sourceforge.net/lists/listinfo/zmapserver-developers
>

Re: [ZMapServer-Developers] Re: update: feature querying for PCL and ZCO

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

On Feb 3, 2005, at 7:22 AM, Etienne Desgagn=E9 wrote:

> Hi,
>
>
>     It seems very interesting for me. I will try it as soon as I will=20=

> get it.
>
> I have one question, I want to know if it will be possible to access=20=

> the spatial
> attribute of a selected feature like (ex: left, right, top, bottom=20
> coordinate)
> for developping a zoom to selected feature function?
>
> Thanks a lot and continue your great work!
>
> Etienne

Etienne,

Since my objective is a WFS-like interface to data stores, it would be=20=

natural to return a bounding box of selected features.  Good point.  I=20=

think that will probably use the mapping.View class for this.

Sean

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

[ZMapServer-Developers] Re: update: feature querying for PCL and ZCO

[Etienne <eti...@ul...>]

Hi,


    It seems very interesting for me. I will try it as soon as I will get it.

I have one question, I want to know if it will be possible to access the spatial
attribute of a selected feature like (ex: left, right, top, bottom coordinate)
for developping a zoom to selected feature function?

Thanks a lot and continue your great work!

Etienne

Selon Sean Gillies <sgi...@fr...>, 02.02.2005:

> Hi all,
>
> Following up on my email about ogr.py ... the primary reason why I want
> to use this module is to support feature querying in PCL (and thereby
> ZCO).
>
> I am about 1/2-way through the querying api that I would like to
> release as PCL 0.7.  Right now there is a WFS-ish means of getting
> features from disk data stores (through ogr.py).  I'll do the same for
> in-memory data stores next and then defer querying features from
> external data stores (like WFS or PostGIS) until later releases.  Chris
> Holmes has expressed interest in ZCO as a WFS client and so I might
> that up to him :)
>
> Here's how the feature querying API will work, example below comes from
> data.IFeatureStore:
>
>      def features(properties=[], filter=None, maxfeatures=0, **params):
>          """Return an iterator over filtered features
>
>          Provides a WFS-ish means to query a store for features.
>
>          Attributes
>          ----------
>          properties : []
>              list of property names to be returned with the feature.
>
>          filter : filter.Filter
>              An instance of Filter.
>
>          maxfeatures : int
>              Default value of 0 means all features.
>
>          params : mapping
>              Mapping of key=value parameters that can be added into the
> locals
>              namespace for evaluation of PythonFilters only.
>
> calling the features() method of a FeatureStore gives you an iterator
> over stored features, each item of which is a (geom, attributes) tuple.
>   The iterator will filter features depending on the "filter" parameter
> above.
>
> We're going to have two kinds of filters:
>
> 1. A very verbose and recursive filter, a fairly literal adaptation of
> the OGC's Filter Encoding spec along the lines of Geotools2
>
> 2. A filter as Python expression as exist now in the expressions of
> cartography.mapping.Rule.
>
> The second is for convenience and will only be useful for local disk
> data stores.  The more complete filter (#1) will allow us to create
> full SQL queries to PostGIS or XML requests to an external WFS service,
> two cases that can let us offload feature queries onto highly optimized
> servers.  I am also expecting that the #1 filter will provide a good
> basis for filter-generating web widgets.
>
> For you, Etienne, here is an example of the PythonFilter syntax:
>
>  >>> pyfilt = filter.PythonFilter('f.FIPS_CNTRY == "UK" and
> g.BBOX(-20,25,60,75)')
>  >>> features = store.features()
>  >>> for (geom, attributes) in features:
>  >>>     ... # do something with features
>
> Assuming you have the same world countries data as me, this gets you an
> iterator over all the U.K. countries within the specified bounding box.
>   Feature attributes are stuffed into an "f" object (as I've documented
> under Rule filters) and feature geometries are represented by the "g"
> object.  I'll be implementing the full complement of spatial operators
> to go along with BBOX, such as intersects, within, contains, etc.  The
> ogr.py module will be used to evaluate these operations.
>
> Will that work for you, Etienne?  And the rest of you?  Does anybody
> have strong feelings about features being a tuple rather than an
> object?
>
> If you want to play with this, you can check it out from CVS.  Will
> require the GDAL/OGR software and installation of the Python modules.
> Take a good close look at the rewritten PCL/setup.py file too.
>
> thanks for letting me think out loud here :)
> Sean
>
> --
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies
>
>
>

[ZMapServer-Developers] update: feature querying for PCL and ZCO

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

Hi all,

Following up on my email about ogr.py ... the primary reason why I want 
to use this module is to support feature querying in PCL (and thereby 
ZCO).

I am about 1/2-way through the querying api that I would like to 
release as PCL 0.7.  Right now there is a WFS-ish means of getting 
features from disk data stores (through ogr.py).  I'll do the same for 
in-memory data stores next and then defer querying features from 
external data stores (like WFS or PostGIS) until later releases.  Chris 
Holmes has expressed interest in ZCO as a WFS client and so I might 
that up to him :)

Here's how the feature querying API will work, example below comes from 
data.IFeatureStore:

     def features(properties=[], filter=None, maxfeatures=0, **params):
         """Return an iterator over filtered features

         Provides a WFS-ish means to query a store for features.

         Attributes
         ----------
         properties : []
             list of property names to be returned with the feature.

         filter : filter.Filter
             An instance of Filter.

         maxfeatures : int
             Default value of 0 means all features.

         params : mapping
             Mapping of key=value parameters that can be added into the 
locals
             namespace for evaluation of PythonFilters only.

calling the features() method of a FeatureStore gives you an iterator 
over stored features, each item of which is a (geom, attributes) tuple. 
  The iterator will filter features depending on the "filter" parameter 
above.

We're going to have two kinds of filters:

1. A very verbose and recursive filter, a fairly literal adaptation of 
the OGC's Filter Encoding spec along the lines of Geotools2

2. A filter as Python expression as exist now in the expressions of 
cartography.mapping.Rule.

The second is for convenience and will only be useful for local disk 
data stores.  The more complete filter (#1) will allow us to create 
full SQL queries to PostGIS or XML requests to an external WFS service, 
two cases that can let us offload feature queries onto highly optimized 
servers.  I am also expecting that the #1 filter will provide a good 
basis for filter-generating web widgets.

For you, Etienne, here is an example of the PythonFilter syntax:

 >>> pyfilt = filter.PythonFilter('f.FIPS_CNTRY == "UK" and 
g.BBOX(-20,25,60,75)')
 >>> features = store.features()
 >>> for (geom, attributes) in features:
 >>>     ... # do something with features

Assuming you have the same world countries data as me, this gets you an 
iterator over all the U.K. countries within the specified bounding box. 
  Feature attributes are stuffed into an "f" object (as I've documented 
under Rule filters) and feature geometries are represented by the "g" 
object.  I'll be implementing the full complement of spatial operators 
to go along with BBOX, such as intersects, within, contains, etc.  The 
ogr.py module will be used to evaluate these operations.

Will that work for you, Etienne?  And the rest of you?  Does anybody 
have strong feelings about features being a tuple rather than an 
object?

If you want to play with this, you can check it out from CVS.  Will 
require the GDAL/OGR software and installation of the Python modules.  
Take a good close look at the rewritten PCL/setup.py file too.

thanks for letting me think out loud here :)
Sean

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

[ZMapServer-Developers] Using ogr.py in PCL

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

Hi all,

I think we could really use GDAL and OGR in the Python Cartographic 
Library to support the various disk-based data stores.  For those of 
you are aren't from the GIS world, this software

    http://gdal.maptools.org/

provides a great interface to both raster and vector data.  The 
libraries are a bit heavy, but not difficult to build from source and 
have binaries for most platforms including win32.

Any objections?

cheers,
Sean

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

[ZMapServer-Developers] Re: [ZMapServer-Users] Need help with PCL/ZCO Query

[Chris H. <ch...@op...>]

On Fri, 28 Jan 2005, Sean Gillies wrote:

> Forwarding this to the developers list ... comments at bottom.
Cool.  Brief comment from me below as well.

> 
> On Jan 27, 2005, at 2:57 PM, Chris Holmes wrote:
> 
> >> Etienne,
> >>
> >> You should allow_class(Query) instead of IQuery.  And make sure to
> >> restart, although I am sure you are doing that.
> >>
> >> Please keep in mind that I am evaluating a couple possible query
> >> interfaces for ZCO which will extend PCL like the ZCO.MapRenderer
> >> extends the underlying PCL functionality.  One possibility is for this
> >> query interface to behave like the Python DB API.  Another possibility
> >> is for the queries to act more like the OGC's GetFeatureInfo request.
> >> Currently, I am leaning towards this second way.
> >
> > I would definitely recommend the OGC approach, but if you're thinking  
> > of
> > OGC style I would recommend GetFeature of WFS instead of  
> > GetFeatureInfo of
> > WMS.  GetFeatureInfo was sort of added to provide some additional info  
> > for
> > WMS, whereas the GetFeature query is the central part of the WFS.  It
> > allows complex filters, handles, maxFeatures, specific properties, ect.
> > See
> > http://svn.refractions.net/geotools/geotools/trunk/gt/module/main/src/ 
> > org/geotools/data/Query.java
> > for how we did it in GeoTools (GeoAPI is quite similar I am sure).  Or
> > http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd which contains the  
> > xml
> > schema for a Query (which gt2 was modeled upon, though it currently
> > contains a few additions, like coordinate systems stuff, which will be  
> > in
> > 1.1 I am pretty sure).
> >
> > best regards, and keep up the great work
> >
> > Chris
> >
> 
> Chris,
> 
> I'm convinced to take the GetFeature route and have spent some time  
> today outlining a Python-ic way of expressing query filters that will  
> be a lot like the rule filter expressions under  
> cartography.mapping.Rule and ZCO.Style.  This means that a filter would  
> be a string and simple usage would be something like this
> 
>      shape = spatial.Polygon(...)
>      filter = 'f.the_geom.intersects(shape)'
>      names = ['*']                                         # all  
> attributes
>      results = layer.query(names, filter, maxfeatures=-1)  # no limit
>      for result in results:
>          ...
> 
> There are some cases where the filter would be evaluated in Python, and  
> for the cases that the layer pointed to some external WFS or a PostGIS  
> database I think the filter expression should be munged to XML or SQL.   
This is definitely the way we do it in geotools as well, and we've been 
extremely happy with it.  I still don't know exactly how mapscript works, 
if they have a filter model at all, but if you're not doing it already you 
should pass the filters to GEOS.  David Blasby is looking into generating 
GEOS code automatically from JTS, so geotools and your python filters 
would be using more or less the same code.  

> This would mean using the Python parser on the filter strings ... I'll  
> have to consider whether we are not better off with Filter objects.   
> I'll take a closer look at GeoTools2 over the weekend.  
We went with Filter objects.  I'd like to redo a few things, but we have
had good results with a visitor pattern.  It's nice because you can keep
the code that encodes to SQL or to WFS, or to XML (so you can serialize as
an ogc filter) separate.  You also may check out the SQLUnpacker (not well
named, as it does more than unpack sql, and it was one of my first
geotools (and professional programming) classes ever, so it could be a lot
more useable).  When passing a Filter expression to SQL or WFS oftentimes
it won't be able to process all filters.  But if you have a complex OR
filter you may be able to split the filter up to do some preprocessing in
the backend SQL (or WFS) so you don't have to load all features into
python.  The SQLUnpacker will recursively figure out if the filter can be
split up into pre and post-processing filters.  I don't know that I'm
explaining well, or making clear why this might be needed.  But ask
questions if you don't understand, I'm more than happy to hear the lessons
we learned.  But the filter package with these classes is available at: 
http://svn.refractions.net/geotools/geotools/trunk/gt/module/main/src/org/geotools/filter/

> Thanks for the  input!
My pleasure - you're doing great work, I think it's going to quite well.  
And I'm pretty positive my company will eventually be using it, as we are 
now moving solidly into wiki and plone space, and will want GeoServer 
integration and fun maps.  I'm sorry that I personally can't play more 
yet.

best regards,

Chris

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

-- 

[ZMapServer-Developers] Re: [ZMapServer-Users] Need help with PCL/ZCO Query

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

Forwarding this to the developers list ... comments at bottom.

On Jan 27, 2005, at 2:57 PM, Chris Holmes wrote:

>> Etienne,
>>
>> You should allow_class(Query) instead of IQuery.  And make sure to
>> restart, although I am sure you are doing that.
>>
>> Please keep in mind that I am evaluating a couple possible query
>> interfaces for ZCO which will extend PCL like the ZCO.MapRenderer
>> extends the underlying PCL functionality.  One possibility is for this
>> query interface to behave like the Python DB API.  Another possibility
>> is for the queries to act more like the OGC's GetFeatureInfo request.
>> Currently, I am leaning towards this second way.
>
> I would definitely recommend the OGC approach, but if you're thinking  
> of
> OGC style I would recommend GetFeature of WFS instead of  
> GetFeatureInfo of
> WMS.  GetFeatureInfo was sort of added to provide some additional info  
> for
> WMS, whereas the GetFeature query is the central part of the WFS.  It
> allows complex filters, handles, maxFeatures, specific properties, ect.
> See
> http://svn.refractions.net/geotools/geotools/trunk/gt/module/main/src/ 
> org/geotools/data/Query.java
> for how we did it in GeoTools (GeoAPI is quite similar I am sure).  Or
> http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd which contains the  
> xml
> schema for a Query (which gt2 was modeled upon, though it currently
> contains a few additions, like coordinate systems stuff, which will be  
> in
> 1.1 I am pretty sure).
>
> best regards, and keep up the great work
>
> Chris
>

Chris,

I'm convinced to take the GetFeature route and have spent some time  
today outlining a Python-ic way of expressing query filters that will  
be a lot like the rule filter expressions under  
cartography.mapping.Rule and ZCO.Style.  This means that a filter would  
be a string and simple usage would be something like this

     shape = spatial.Polygon(...)
     filter = 'f.the_geom.intersects(shape)'
     names = ['*']                                         # all  
attributes
     results = layer.query(names, filter, maxfeatures=-1)  # no limit
     for result in results:
         ...

There are some cases where the filter would be evaluated in Python, and  
for the cases that the layer pointed to some external WFS or a PostGIS  
database I think the filter expression should be munged to XML or SQL.   
This would mean using the Python parser on the filter strings ... I'll  
have to consider whether we are not better off with Filter objects.   
I'll take a closer look at GeoTools2 over the weekend.  Thanks for the  
input!

cheers,
Sean

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

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

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

On Jan 26, 2005, at 3:01 PM, Arnaud Bienvenu wrote:

> 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 ?
>

Yes, this is a great idea.  It makes sense for users to pick locations 
off a map instead of typing coordinates into a field.

> 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

I'm only thinking about ZODB as a lightweight spatial database.  For up 
to a few hundreds of points such as the restaurants in a city or the 
vineyards in an appellation -- two of my favorite examples :)  For 
roads and streets, engineering data, etc. users should instead be using 
a real spatial database.

cheers,
Sean

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

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

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

Arnaud Bienvenu a =E9crit :
> However, I do not believe that "turn the ZODB into a spatial database"=20
> will become a reality, in the sense that WKT properties of Zope objects=
=20
> will never be queryable.

I just realized this is implemented in PCL. Congratulations :-)

> our portal tool should also=20
> be able to read/write into such a database instead of editing the "geom=
"=20
> Zope property.

This is still a point, since ZODB spatial queries will be very slow=20
compared to a _real_ spatial database.

Regards,
--=20
Arnaud Bienvenu
Makina Corpus

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

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

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

On Jan 24, 2005, at 8:09 AM, Moisan Yves wrote:

> Hi Sean,
> =A0
> I meant to elaborate more on my use cases in a bid to find=20
> commonalities with mine and the ones you have posted, but the many=20
> posts I have seen on this list up to now show me that we basically=20
> have similar needs : easy point and click ways of=20
> adding/modifying/deleting geo-info, something I would call "map=20
> agility", which encompasses zooming/panning/roaming, but also thinks=20=

> like "magnifier" or linked maps showing more/less details as someone=20=

> pointed out.=A0 I guess that's what you mean by :
> =A0
> "I am hoping that if we can keep the spatial description of Zope and
> Plone objects as simple as possible that we can focus more of our
> resources on the map image and navigation tool widgets."
> =A0

Right.  I'd like to see ZCO and its Plone tools be concerned more with=20=

application objects than data objects.  More comments below ...

> One thing I haven't heard much in the discussion so far=A0though is=20
> metadata and more specifically where to store it.=A0 I'll throw in a=20=

> bunch of things here for people to help me sort out.=A0
>  =A0
> We have a CMS (Plone, Silva, CPS ...) whose main function is to store=20=

> and index content *together with* metadata.=A0 Extending the ZODB by=20=

> adding a geom properties and therefore "spatially enabling" the ZODB=20=

> in terms of content is one step.=A0 I wonder how far we can go with =
that=20
> one step.=A0 Or in fact how far we should get in that direction.=A0 In=20=

> particular, I would like to ask where the domain of the ZODB stops and=20=

> where that of an ORDBMS back ends starts.=A0 Let me explain.
> =A0
> First a point about spatial enablement.=A0 User Y wants to "geo-tag" a=20=

> report.=A0 To take Paul's example, the report is a OO document written=20=

> by a studebt about some rock outcrop.=A0 One way to attach spatial =
info=20
> to the report could be to=A0 "tagg them into the existing location=20
> information that I already put into the website" as Paul mentions,=20
> that is spatially enable the report by attaching it to an "anchor=20
> object" that is somehow georeferenced.=A0 The report=A0becomes =
queryable=20
> (is that a word?) through that anchor object in Zope.=A0 That is, you=20=

> can make a page template that returns all objects of type "report"=20
> sorted by anchor objects.=A0 But you can't query the object in a "SQL=20=

> fashion" (e.g. give me all reports which were written in province X of=20=

> Kentucky, which would be a spatial query like postGIS would allow one=20=

> to do) unless there was an easy way to dereference the anchor object=20=

> in Zope and make that info available to postGIS or unless one would=20
> want to duplicate/proxy the postGIS polygon representing province X in=20=

> Zope.=A0 Do we need data to be queryable in SQL fashion? =A0I think =
so, if=20
> one wants to share it with other systems/parties without having to go=20=

> through the CMS for such a third party access (see below).
> =A0

In this discussion we have now had 3 (at least!) notions of=20
geo-tagging.  You have just outlined a many-to-one relationship, right?

     +----------+ *  0..1 +----------+
     | Document | ------> | Geometry |
     +----------+         +----------+

Previously, Arnaud had been talking about the reverse of this=20
relationship, and I have been advocating the Geometry as an attribute=20
(or metadata) of the Document.  The latter still makes more sense to me=20=

from the GIS perspective.

Yves, you should definitely be using an RDBMS for your sensor data.  As=20=

far as I can see, the *only* advantage to be had by storing your=20
spatial data in the ZODB (in any form) is that you can take advantage=20
of through-the-web editing, CMS workflows, permissions, undo, etc. --=20
these features are immediately available for objects in the ZODB, but=20
would have to be reimplemented to some extent if you keep your data=20
outside of Zope.

It's not only geo-spatial programmers that run up against this issue=20
... remember that for a long time there has been a product for storing=20=

your Zope application objects in external RDBMS.

For a class of applications that involve just hundreds of point=20
"events" -- whether field sites or petrol stations or locations of=20
portal members -- and are not full-fledged SDIs, I think it is=20
perfectly fine to keep spatial data in the ZODB.

> Now my point on metadata.=A0 User X (or sensor X) wants to upload a=20
> water temperature measurement at a point station.=A0 First, I think we=20=

> upload the data per se in an ORDBMS back-end via Zope.=A0 It would=20
> probably not be a problem to upload a point measurement in a Zope=20
> object, but I don't think that would scale well to a few thousand=A050=20=

> KB polygons.=A0 That is, I don't see the ZODB as a data repository; I=20=

> see it more like a place to store Zope object states.=A0 Plus, it =
would=20
> make the data less amenable to be used by third paerty systems, IMO.=A0=20=

> Second, where do we store the metadata?=A0 Since we are in a CMS, we=20=

> already have a bunch of metadata info (author, date of publication,=20
> workflow info e.g. who is queued in for revision=A0...) for the new=20
> object.=A0 But for the metadata that pertains to the data more closely=20=

> (in our case,=A0 the range of temperatures measurable by the sensor=20
> ...), where would that info be stored ?=A0 Do I want to store it in =
the=20
> CMS only or do I somehow want to decouple it from the CMS and persist=20=

> the metadata by coupling it physically to the data (that is, store it=20=

> in the backend where the data is stored, e.g. postGIS and access it=20
> through Zope for the particular case of my own system, but potentially=20=

> not through Zope for third party; pretty much sounds like the=20
> definition of a decoupled service to me)?=A0
>  =A0
> I am asking this because I think a definite need for any geolocated=20
> piece of info to be reusable in a collaborative fashion by third=20
> parties with known levels of confidence is to have access not only to=20=

> the data, but also to the metadata.=A0 I surmise that process of =
making=20
> the data and related metadata available should bypass the CMS as much=20=

> as possible.=A0 That is, the data should be self-contained in the=20
> back-end and any specific CMS metadata tied to the data (e.g. name of=20=

> the author) should be easily dereferenceable or proxied/copied into=20
> the back-end.
> =A0
> I understand the ideas people on this list are currently discussing=20
> have more to do with how people using Zope-based CMS's can=20
> view/add/edit georeferenced info, but my feeling at this point is that=20=

> if users should be able to upload data, that data should be fully=20
> qualified for future use by third party systems given the need to=20
> eventually *share* the data with other systems/parties.=A0 So long as=20=

> the Zope-based system is in a two-way connection mode with the geodata=20=

> backend, there is no problem.=A0 The data can be stored in the back =
end,=20
> proxied in the CMS=A0and the metadata can be split between the CMS and=20=

> the backend just about any way we like.=A0 The minute there is a need =
to=20
> open one's data to others, we have to ask how we can make sure that=20
> all metadata is available.=A0=A0
> =A0
> My inclination at this point would be to try and decouple as much of=20=

> the metadata from the CMS as possible and make Zope much more of a=20
> client app to a back-end than a data/metadata repository.=A0 =
Otherwise,=20
> we would have to think of Zope as a geodata server in its own right,=20=

> that is direct all data queries to Zope first, but I think that=20
> defeats some of the purpose of something like postGIS (or does ir=20
> complement it ?).=A0 Putting such machinery in place could provide a=20=

> truly powerful geo-info solution.=A0 And of course I haven't talked=20
> about data validation (Python scripts, XML validating parsers ...) and=20=

> dynamic map rendering through SVG (new ZSVGGraph just appeared!) , but=20=

> that's for another post.
> =A0
> Cheers all,
> =A0
> Yves Moisan
>

I don't have any plans to program a generic metadata editor for Zope,=20
that's for sure :)  But I am planning to add full editing and=20
management of WMS Capabilities metadata to ZCO Layers and Styles so=20
that a ZCO application can readily emit capabilities documents and=20
serve as a good platform for creating WMS services.  Better than=20
hacking mapfiles by hand for use with mapserv.
Will this metadata be kept in the ZODB?  Yes.

I'm glad you mentioned ZSVGGraph again.  That is exactly what I was=20
thinking of when I hoped our Plone work would focus more on application=20=

objects.  Graph widgets would be great for many types of mapping=20
applications.

cheers,
Sean

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

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

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

On Jan 22, 2005, at 1:52 PM, Arnaud Bienvenu wrote:

> ...
>
>> Another way (and this I've done already) would be to have sort of 
>> proxy
>> objects that represent the actual objects in the map. This might help 
>> to
>> keep the map implementation lighter as these proxy objects tend to 
>> quite
>> small compared to the arbitrary sized data objects.
>
> Yes, much smarter. The geo-properties of a content object belongs to 
> the map, not to the object itself. Not only this preserves code 
> independance, but also allows users to geo-localize one Plone object 
> differently on different maps.
>
> In example, let's imagine an article that talks about Tibet and Nepal. 
> On a world map, we would like it to be represented by one point in 
> Asia. But on a map of Asia, we would like to see two points, probably 
> set with another coordinate system. And on third map which would be a 
> nice drawing of the Himalayas, we would like to locate more points 
> with pixel coordinates.
>
> You may implement this geo-localization as a sort of property (or 
> sub-object) of each map, or as one clever proxy object that makes the 
> link between one plone content object and several maps. But this 
> rather complex stuff does not belong to any Plone Article object.
>
> 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?  It relies on objects having a "geom" property.  
See the objects in demo/content which are then mapped using the 
demo/layers/zpoints layer.

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?


>
>> The Plone administration interface to the map should allow even a
>> non-technically oriented person (= 99% of our userbase) to easily 
>> manage
>> the layout and outlook of the map using the same methods used with
>> managing other Zope content. For example, ordering of layers could be
>> implemented as ordering the contents of a folderish object.
>
> Yes, this idea has been successfully implemented in PloneMap. While it 
> lacks functionnaly and ease of use, I think it is a good direction. 
> The more we reuse the existing look&feel of Plone for our purpose, the 
> better.
>
> > Objects
> > could be added to the map by simply clicking on the desired target.
>
> Many people have difficulties using the "add" feature of PloneMap. 
> Selecting an object type, then clicking onto the map to instanciate 
> it, seems not to be user-friendly enough. Maybe we should let people 
> create their Plone objects the standard way, an add an entry into the 
> Plone menu called "localize this object". Then the users chooses a map 
> between those existing in the portal, zooms to the desired location, 
> and clicks one (or several) points.
>
> What is your opinion about that ?
>
>> It would be nice if the layout of the whole map interface (map image,
>> 8-way panning, action buttons (zoom-in, zoom-out, center, reset, etc),
>> reference map, scalebar) would be user configurable (or
>> semi-configurable). We've been using the concept of page models
>> (provided by the PloneArticle product) with our clients and they've 
>> been
>> very happy with it, so I was thinking something similar with the map
>> interface. If the underlying functionality is properly modularized, it
>> should be easy to provide the user with "different" maps for different
>> purposes.
>
> Nice idea!
>
> Cheers,
> -- 
> Arnaud Bienvenu
> http://plonemap.makina-corpus.org/
>

I am hoping that if we can keep the spatial description of Zope and 
Plone objects as simple as possible that we can focus more of our 
resources on the map image and navigation tool widgets.  I'm going to 
have another email about widgets soon.

cheers,
Sean

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

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

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

Hi Kai, hello all,

I am glad to read about Plone/CMF and ZCO. Here are my comments...

Kai H=E4nninen a =E9crit :
> As to making arbitrary objects "geo-aware", there are atleast two
> approaches. One would be to have a base class, that would hold the
> required imformation (just the x,y-coordinate pair in the simplest case
> for POINT type) that arbitrary objects could inherit from and thus make
> themselves geo-aware and usable with the map.

I would say no, by experience. This requires to modify the code of the=20
arbitrary object. Any Plone content object should be able to become=20
geo-aware, but who wants to recode all Plone objects in a geo-aware=20
flavour, even if it is as simple as adding an inheritance?

That is what I began to do with GeoPloneTypes, which are archetypes that=20
all inherit from a base class named "GeoType". But this does not lead=20
very far.

> Another way (and this I've done already) would be to have sort of proxy
> objects that represent the actual objects in the map. This might help t=
o
> keep the map implementation lighter as these proxy objects tend to quit=
e
> small compared to the arbitrary sized data objects.

Yes, much smarter. The geo-properties of a content object belongs to the=20
map, not to the object itself. Not only this preserves code=20
independance, but also allows users to geo-localize one Plone object=20
differently on different maps.

In example, let's imagine an article that talks about Tibet and Nepal.=20
On a world map, we would like it to be represented by one point in Asia.=20
But on a map of Asia, we would like to see two points, probably set with=20
another coordinate system. And on third map which would be a nice=20
drawing of the Himalayas, we would like to locate more points with pixel=20
coordinates.

You may implement this geo-localization as a sort of property (or=20
sub-object) of each map, or as one clever proxy object that makes the=20
link between one plone content object and several maps. But this rather=20
complex stuff does not belong to any Plone Article object.

So I think you definitely got it right implementing proxy objects.

> The Plone administration interface to the map should allow even a
> non-technically oriented person (=3D 99% of our userbase) to easily man=
age
> the layout and outlook of the map using the same methods used with
> managing other Zope content. For example, ordering of layers could be
> implemented as ordering the contents of a folderish object.

Yes, this idea has been successfully implemented in PloneMap. While it=20
lacks functionnaly and ease of use, I think it is a good direction. The=20
more we reuse the existing look&feel of Plone for our purpose, the better=
.

 > Objects
 > could be added to the map by simply clicking on the desired target.

Many people have difficulties using the "add" feature of PloneMap.=20
Selecting an object type, then clicking onto the map to instanciate it,=20
seems not to be user-friendly enough. Maybe we should let people create=20
their Plone objects the standard way, an add an entry into the Plone=20
menu called "localize this object". Then the users chooses a map between=20
those existing in the portal, zooms to the desired location, and clicks=20
one (or several) points.

What is your opinion about that ?

> It would be nice if the layout of the whole map interface (map image,
> 8-way panning, action buttons (zoom-in, zoom-out, center, reset, etc),
> reference map, scalebar) would be user configurable (or
> semi-configurable). We've been using the concept of page models
> (provided by the PloneArticle product) with our clients and they've bee=
n
> very happy with it, so I was thinking something similar with the map
> interface. If the underlying functionality is properly modularized, it
> should be easy to provide the user with "different" maps for different
> purposes.

Nice idea!

Cheers,
--=20
Arnaud Bienvenu
http://plonemap.makina-corpus.org/

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

[Paul H. <ph...@uk...>]

At 03:10 PM 1/22/2005 +0200, Kai H=E4nninen wrote:
>As to making arbitrary objects "geo-aware", there are atleast two
>approaches. One would be to have a base class, that would hold the
>required imformation (just the x,y-coordinate pair in the simplest case
>for POINT type) that arbitrary objects could inherit from and thus make
>themselves geo-aware and usable with the map.

+1  Absolutely.  Bravo.  Need to have a nice, consistent starting point for=
=20
building custom Archetypes that are geo-aware.


>The Plone administration interface to the map should allow even a
>non-technically oriented person (=3D 99% of our userbase) to easily manage
>the layout and outlook of the map using the same methods used with
>managing other Zope content. For example, ordering of layers could be
>implemented as ordering the contents of a folderish object. Objects
>could be added to the map by simply clicking on the desired target.

+1  Fits my needs too.  Perfect.


>It would be nice if the layout of the whole map interface (map image,
>8-way panning, action buttons (zoom-in, zoom-out, center, reset, etc),
>reference map, scalebar) would be user configurable (or
>semi-configurable). We've been using the concept of page models
>(provided by the PloneArticle product) with our clients and they've been
>very happy with it, so I was thinking something similar with the map
>interface. If the underlying functionality is properly modularized, it
>should be easy to provide the user with "different" maps for different
>purposes.

+1  That sounds wonderful... I wasn't really thinking about=20
user-configurable so much as easily Manager-configurable, but I can see why=
=20
it might be very useful to do so.

Kai, this is a wonderful vision.  I'll share a use case of my own, from the=
=20
world of Geology.  I'm a professor at the University of Kentucky, and my=20
role here is mostly teaching and little research... I'm exploring the use=20
of ZCO and Plone to create a website where members from the geoscience=20
community can locate and post information about rock outcrops in their=20
area, including descriptions and photos and virtually any content type that=
=20
can be uploaded.

I see this as a web resource for the larger geoscience community, not just=
=20
professional geologists.  For example, in my area I plan to add information=
=20
about a large number of outcrops that are easily accessible and safe for=20
people to visit.  My purpose is to describe them in terms of rock types,=20
fossils that are present, etc. so that anyone interested in Kentucky=20
geology can find this information and go visit them and explore them for=20
themselves.  I see it being used first by other geology faculty looking for=
=20
field trip sites for their students, and then by K-12 teachers looking for=
=20
information about rocks in the area where they live and teach, and=20
certainly by students and the general public interested in local geology,=20
fossils, faults and folds, minerals, etc.

I also want anyone who joins to be able to upload and add their own=20
information about the rocks.  Say I enter initial information and location=
=20
for the Camp Nelson outcrop on Highway 27.  Then Fred Jones goes to the=20
outcrop and takes some very nice photos that he'd like to share... Fred can=
=20
join and add those into his own Member area, but tag them into the existing=
=20
location information that I already put into the website.  He should be=20
able to add additional location information (perhaps UTM coords from his=20
GPS unit), but still tag his entries to my mapped starting point.  [[ This=
=20
might be as simple as using Archetype references, although I don't have=20
much experience using them yet. ]]

Because there is a lot of text information associated with each outcrop, it=
=20
becomes valuable as a searchable resource as well... Show me a map with=20
locations containing brachiopod fossils and the word "Devonian".   When=20
such a resource expands to encompass the larger world beyond Kentucky, it=20
will be incredibly valuable to a wide audience.

I hope to get started later this semester.
=3DPaul

Paul Howell, Associate Professor
Department of Geological Sciences
University of Kentucky
101 Slone Research Bldg.
Lexington KY 40506-0053
email: ph...@uk...  phone: 859-257-3932
Geology Department office phone: 859-257-3758

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

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

pe, 2005-01-21 kello 08:17 -0700, Sean Gillies kirjoitti:
> Hi all,
>=20
> I'd like to start a discussion about use cases for ZCO (or mapping in=20
> general) and Plone or CMF.  Please feel free to jump in and add your=20
> own thoughts.

[...]

The use cases that I have had in mind are based on a hybrid setup of
cartographic data from external sources (shapefiles, databases, etc) and
Zope objects. My approach is Plone/ArcheTypes oriented, but any
implementation should be easily generalized to include other settings.
At an abstract level you can just replace "Plone" with your favourite
framework.

I am interested in creating a sort of base map out of the external data
which can be overlayed with arbitrary Zope/Plone objects that are made
"geo-aware".

An important aspect would be that while setting up the base map would
require a (somewhat) more knowledgeable user, using and editing the Zope
based objects on the map should be as easy and userfriendly as using
Plone otherwise. That is, the user shouldn't have to deal directly with
any specific map information, such as coordinates etc, but rather
through a "point-on-the-map" interface.

Another important thing for me is that the interface should (atleast try
to) be as standard conformant as Plone itself, so no browser specific
hacks or external plugin requirements.

As to making arbitrary objects "geo-aware", there are atleast two
approaches. One would be to have a base class, that would hold the
required imformation (just the x,y-coordinate pair in the simplest case
for POINT type) that arbitrary objects could inherit from and thus make
themselves geo-aware and usable with the map.

Another way (and this I've done already) would be to have sort of proxy
objects that represent the actual objects in the map. This might help to
keep the map implementation lighter as these proxy objects tend to quite
small compared to the arbitrary sized data objects.

The Plone administration interface to the map should allow even a
non-technically oriented person (=3D 99% of our userbase) to easily manag=
e
the layout and outlook of the map using the same methods used with
managing other Zope content. For example, ordering of layers could be
implemented as ordering the contents of a folderish object. Objects
could be added to the map by simply clicking on the desired target.

It would be nice if the layout of the whole map interface (map image,
8-way panning, action buttons (zoom-in, zoom-out, center, reset, etc),
reference map, scalebar) would be user configurable (or
semi-configurable). We've been using the concept of page models
(provided by the PloneArticle product) with our clients and they've been
very happy with it, so I was thinking something similar with the map
interface. If the underlying functionality is properly modularized, it
should be easy to provide the user with "different" maps for different
purposes.


As a concrete use case, here is one from our company that I will have to
implement in the near future.

- the client is a large petrol station chain, with many full service and
automated stations located around the country
- the different types of stations are modeled as ArcheTypes based
objects with heterogenous attributes, which the client can arbitrarily
add, delete, edit etc.
- the client wants to display the stations on a country wide map and
update the map as easily as editing the ArcheTypes based station
objects.
- the station objects in the map should display some "teaser" type
information about the actual stations and provide a link to the actual
station page.
- the chain is growing fast and the customer needs to update the map
frequently and with ease.
- in the future the client will most propably wish to display other
information on the map and it should be as painless as possible to make
other objects geo-aware, so that they can be used with the map

cheers,
Kai

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

[ZMapServer-Developers] ZCO and Plone/CMF

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

Hi all,

I'd like to start a discussion about use cases for ZCO (or mapping in 
general) and Plone or CMF.  Please feel free to jump in and add your 
own thoughts.

My immediate uses for mapping with Plone (I'm using that in one place 
instead of CMF) are these:

1) allow members of a portal to locate themselves on a portal-wide map 
by using a Geometry widget .  If you've looked at the ZCO demo you may 
have seen how I am doing this in Zope with a Catalog and a "geom" 
property that uses WKT formatted geometry like 'POINT (-107 41)'.

2) allow portals members to publish a small number of features to a 
portal-wide map for the purpose of a spatial "marketplace" -- comparing 
area of interest of a consumer to a producer's resources.  For this we 
would use a Plone/CMF content type that extended the CSV file mechanism 
in ZCO.

I have thought less about portal members creating their own maps, and 
would like to hear more from you about this use case.

cheers,
Sean

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

Re: [ZMapServer-Developers] New ZCO developer Kai =?ISO-8859-1?Q?H=E4nninen?=

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

ke, 2005-01-19 kello 08:41 -0700, Sean Gillies kirjoitti:

[...]

> >
> > Just a side note, as I was sometimes confronted to such things.
> >
> > If (IF) it is possible, and if it fits in your product plans and
> > architectures (and If I understand what you are talking about), i wou=
ld
> > be happy with a CMF compliant product (I guess more on the
> > functionality/API side) associated with a plone component (I guess mo=
re
> > on the interface side).
> >
> > This way such a product could be used (or at least the CMF part can b=
e)
> > with other CMF framework (CMF alone, Sylva, CPS, ,...)
> >
> > This way we can get best of both worlds, and in the same idea of
> > separing PCL/ZCO, anyone not using Plone can use and/or contribute to
> > the CMF product and thus we can have a larger base.
> >
> > I hope i didn't missunderstood your goals.
> >
> > Regards.
> >
>=20
> Didier,
>=20
> I am +1 for making ZCO useful to CMF.  I expect that our Plone users=20
> will want to develop using Archetypes, and although this can not be=20
> immediately shared with CMF, can quickly add functionality and serve as=
=20
> a prototype for functionality that we can port to CMF.  Does that make=20
> sense?

This sounds sensible, since it would enable even wider use of ZCO and
support multiple interfaces. The work that I have been doing on the
Plone interface is heavily based on Archetypes (which is an excellent
tool for both fast prototyping and actual implementions). Personally I'm
interested in a Plone interface, but if a CMF port doesn't hinder the
product functionality/usability wise, so much better for the project.

As Sean suggested, I feel that the CMF port should/could be done maybe
at a later stage of development, when we have a better view on how the
interface layer on top of ZCO should work, or how do you feel?

cheers,
Kai


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

[ZMapServer-Developers] =?ISO-8859-1?Q?Re:_[ZMapServer-Developers]_New_ZCO_developer=09K?= =?ISO-8859-1?Q?ai=09H=E4nninen?=

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

On Jan 19, 2005, at 1:09 AM, didier.georgieff wrote:

> Hello Ka=EF,
>
> Le mer 19/01/2005 =E0 08:27, Kai H=E4nninen a =E9crit :
>>>
>>> I am pleased to welcome aboard Kai H=E4nninen as a developer on the =
ZCO
>>> project.  Kai works for MB Concert of Finland and will be working on=20=

>>> a
>>> product for Plone that will be developed and distributed alongside=20=

>>> ZCO.
>
> Great news.
>
>>>   I am very excited about this, as Plone shows signs of being an =
even
>>> more successful software than Zope itself, and users will be very
>>> interested in a good mapping component.
>
> Just a side note, as I was sometimes confronted to such things.
>
> If (IF) it is possible, and if it fits in your product plans and
> architectures (and If I understand what you are talking about), i =
would
> be happy with a CMF compliant product (I guess more on the
> functionality/API side) associated with a plone component (I guess =
more
> on the interface side).
>
> This way such a product could be used (or at least the CMF part can =
be)
> with other CMF framework (CMF alone, Sylva, CPS, ,...)
>
> This way we can get best of both worlds, and in the same idea of
> separing PCL/ZCO, anyone not using Plone can use and/or contribute to
> the CMF product and thus we can have a larger base.
>
> I hope i didn't missunderstood your goals.
>
> Regards.
>

Didier,

I am +1 for making ZCO useful to CMF.  I expect that our Plone users=20
will want to develop using Archetypes, and although this can not be=20
immediately shared with CMF, can quickly add functionality and serve as=20=

a prototype for functionality that we can port to CMF.  Does that make=20=

sense?

Sean

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

Re: [ZMapServer-Developers] New ZCO developer Kai =?iso-8859-1?Q?H=E4nninen?=

[Paul H. <ph...@uk...>]

I am new to all of ZMapServer and ZCO, but have some Plone development=20
experience and would like to help out too.  I plan to have a decent=20
development server environment up and running for this purpose shortly.  I=
=20
have many quasi-academic purposes for a good Plone/GIS marriage.
=3DPaul
Paul Howell
University of Kentucky

At 09:09 AM 1/19/2005 +0100, didier.georgieff wrote:
>Hello Ka=EF,
>
>Le mer 19/01/2005 =E0 08:27, Kai H=E4nninen a =E9crit :
> > >
> > > I am pleased to welcome aboard Kai H=E4nninen as a developer on the=
 ZCO
> > > project.  Kai works for MB Concert of Finland and will be working on a
> > > product for Plone that will be developed and distributed alongside=
 ZCO.
>
>Great news.
>
> > >   I am very excited about this, as Plone shows signs of being an even
> > > more successful software than Zope itself, and users will be very
> > > interested in a good mapping component.
>
>Just a side note, as I was sometimes confronted to such things.
>
>If (IF) it is possible, and if it fits in your product plans and
>architectures (and If I understand what you are talking about), i would
>be happy with a CMF compliant product (I guess more on the
>functionality/API side) associated with a plone component (I guess more
>on the interface side).
>
>This way such a product could be used (or at least the CMF part can be)
>with other CMF framework (CMF alone, Sylva, CPS, ,...)
>
>This way we can get best of both worlds, and in the same idea of
>separing PCL/ZCO, anyone not using Plone can use and/or contribute to
>the CMF product and thus we can have a larger base.
>
>I hope i didn't missunderstood your goals.
>
>Regards.
>
>--
>didier.georgieff <did...@ag...>
>DIDSIT du Bas-Rhin
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>_______________________________________________
>ZMapServer-Developers mailing list
>ZMa...@li...
>https://lists.sourceforge.net/lists/listinfo/zmapserver-developers

Re: [ZMapServer-Developers] New ZCO =?ISO-8859-1?Q?developer=09Kai=09H=E4nninen?=

[didier.georgieff <did...@ag...>]

Hello Ka=EF,

Le mer 19/01/2005 =E0 08:27, Kai H=E4nninen a =E9crit :
> > 
> > I am pleased to welcome aboard Kai H=E4nninen as a developer on the ZCO 
> > project.  Kai works for MB Concert of Finland and will be working on a 
> > product for Plone that will be developed and distributed alongside ZCO. 

Great news.

> >   I am very excited about this, as Plone shows signs of being an even 
> > more successful software than Zope itself, and users will be very 
> > interested in a good mapping component.

Just a side note, as I was sometimes confronted to such things.

If (IF) it is possible, and if it fits in your product plans and
architectures (and If I understand what you are talking about), i would
be happy with a CMF compliant product (I guess more on the
functionality/API side) associated with a plone component (I guess more
on the interface side).

This way such a product could be used (or at least the CMF part can be)
with other CMF framework (CMF alone, Sylva, CPS, ,...)

This way we can get best of both worlds, and in the same idea of
separing PCL/ZCO, anyone not using Plone can use and/or contribute to
the CMF product and thus we can have a larger base.

I hope i didn't missunderstood your goals.

Regards.

-- 
didier.georgieff <did...@ag...>
DIDSIT du Bas-Rhin

Re: [ZMapServer-Developers] New ZCO developer Kai =?ISO-8859-1?Q?H=E4nninen?=

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

ti, 2005-01-18 kello 18:53 -0700, Sean Gillies kirjoitti:
> Hi all,
>=20
> I am pleased to welcome aboard Kai H=E4nninen as a developer on the ZCO=
=20
> project.  Kai works for MB Concert of Finland and will be working on a=20
> product for Plone that will be developed and distributed alongside ZCO.=
=20
>   I am very excited about this, as Plone shows signs of being an even=20
> more successful software than Zope itself, and users will be very=20
> interested in a good mapping component.

Thanks Sean,

I'm looking forward on working with ZCO and the Plone interface.

cheers,
Kai

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

[ZMapServer-Developers] =?ISO-8859-1?Q?New_ZCO_developer_Kai_H=E4nninen?=

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

Hi all,

I am pleased to welcome aboard Kai H=E4nninen as a developer on the ZCO=20=

project.  Kai works for MB Concert of Finland and will be working on a=20=

product for Plone that will be developed and distributed alongside ZCO.=20=

  I am very excited about this, as Plone shows signs of being an even=20
more successful software than Zope itself, and users will be very=20
interested in a good mapping component.

cheers,
Sean

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

[ZMapServer-Developers] New PCL and ZCO releases, new ZCO Manual

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

Hi all,

New and improved ZCO release is available today from the projects 
download page, and the beginning of a user manual is at the URL

   http://zmapserver.sourceforge.net/ZCO/manual.pdf

As usual, the latest ZCO release (0.3.1) requires the latest PCL 
(0.6.3).

cheers,
Sean

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