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
>