[ZMapServer-Developers] bbox attribute container

[Moisan Y. <ym...@gr...>]

Hi Sean,

I've been playing around lately with ZCO and I would like to share some
thoughts.  The context is that I am trying to find a way to override the
default bbox values sent to the getMap script (demo/index_html),
specifically bbox values to implement zooming.

First, the layer object.  Looking at the attributes sequentially :=20

- datastore : OK since the layer is a sort of ZCO wrapper or abstraction
of the DataStore
- geometryType, srs : those really are attributes of the DataStore (??),
except maybe for srs which can be thought of as the datastore srs or the
"desired" srs for map viewing (which points to a view object IMO, at
least comceptually)
- bbox (e.g. the layers/line object in the ZCO demo) : IMO this is an
attribute for some other object; in fact, I've been creating layers for
a personal demo and I never put any bbox (if it had been a necessary
attribute, I would have been brought naturally to add a bbox attribute
to my layers).

So in short I view the Layer object as a Python/Zope wrapper object to a
DataStore and a container for style variants.

Now, the bbox attribute.  Considering the width/height invariant,
zooming/panning and providing default views really are just bbox
arithmetic stuff.  I was wondering where the bbox attribute would find
its best home (Zope object).

Use Case : I have users in city X and other is city Y.  Those
geographical attributes are mimicked in a zope hierarchy, e.g.
country/province/city.  Upon entering the cityX folder, I would like my
map portlet to display a predetermined zone of my layers, which would
call for some object holding the bbox (or a folder property ??).  Since
I'll be reusing the same layers, I wouldn't want to define a Layer to
hold my bbox attribute corresponding to predefined views.

I don't know where bbox should be held.  I think isolating it in some
sort of view object to allow one to set specific views in the current
context is interesting.  I wonder if a bbox container in the current
context could be used to write user-specified zooms?  E.g. a box asking
the user for a zoom level (potentially float) the contetn of which would
be stored in the current mapper context and somehow hooked to before the
call to getMap.  We could probably think of objects to allow for bbox
arithmetic first on the client side (combination of zoom and pan
requests from the user) that would not call MapServer, then once the
user is ready after playing around, he can send the request.

Cheers,

Yves Moisan