<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey Eli,<br>
<br>
The filtering is for visual purposes: since images from different
dates may be in the same location I want to see only those polygons
related to the image being shown.<br>
<br>
My particular use-case is such that there will never be very many
polygons served via WFS at once. but I do have some performance
concerns in general. Fortunately Geomoose/OpenLayers sends a
bounding box filter based on the display window so that will tend to
minimize the problem. <br>
<br>
I've hard-coded an OpenLayers attribute filter in WFS.js for
testing purposes:<br>
<br>
<tt> this._ol_layer = new OpenLayers.Layer.Vector(this.title,
{</tt><tt><br>
</tt><tt> strategies: strategies,</tt><tt><br>
</tt><tt> projection: this.srsName,</tt><tt><br>
</tt><tt> styleMap : this.style_map,</tt><tt><br>
</tt><tt> visibility: false,</tt><tt><br>
</tt><b><tt> filter: new OpenLayers.Filter.Comparison({
//BWF</tt></b><b><tt><br>
</tt></b><b><tt> type:
OpenLayers.Filter.Comparison.EQUAL_TO,</tt></b><b><tt><br>
</tt></b><b><tt> property: "image_id",</tt></b><b><tt><br>
</tt></b><b><tt> value: "204"</tt></b><b><tt><br>
</tt></b><b><tt> }),</tt></b><b><tt><br>
</tt></b><tt><b> proto</b>col: new
OpenLayers.Protocol.WFS({</tt><tt><br>
</tt><tt> version: '1.1.0',</tt><tt><br>
</tt><tt> srsName: this.srsName,</tt><tt><br>
</tt><tt> url: this.url,</tt><tt><br>
</tt><tt> featureNS: this.featureNS,</tt><tt><br>
</tt><tt> featurePrefix: this.featurePrefix,</tt><tt><br>
</tt><tt> featureType: this.featureType,</tt><tt><br>
</tt><tt> geometryName: this.featureGeometryName,</tt><tt><br>
</tt><tt> schema: this.featureSchema</tt><tt><br>
</tt><tt> })</tt><tt><br>
</tt><tt> });</tt><br>
<br>
and it works fine (the above code causes only those polygons
digitized from image 204 to be shown). Now I need to hack in some
code to change the filter value when the user selects a different
image. While it will be ok for my project, it would be nice to come
up with a more general approach. Maybe I'll get some inspiration
while hacking...<br>
<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<div class="moz-cite-prefix">On 3/15/2016 5:57 PM, Eli Adam wrote:<br>
</div>
<blockquote
cite="mid:CACqBkM_nYPVdmg-WryP8SXPmcUUmtkv8f2Kt3-+8igm0CYopvA@mail.gmail.com"
type="cite">
<pre wrap="">Hi Brent,
On Tue, Mar 15, 2016 at 7:38 AM, Brent Fraser <a class="moz-txt-link-rfc2396E" href="mailto:bfraser@geoanalytic.com"><bfraser@geoanalytic.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
Now that I've configured my Geomoose demo to do WFS-T, I need to think
about how to use it in my old Geomoose v2.4 Ice Digitizing application.
</pre>
</blockquote>
<pre wrap="">
Cool, good to hear that it is working.
</pre>
<blockquote type="cite">
<pre wrap="">
That application grouped digitized polygons by "image_id" (representing
the Landsat image used as a backdrop). There are hundreds of images and
thousands of polygons in the system and when the user selected an image,
Geomoose passed the image_id to mapserver to do a substitution in the
mapfile SQL so only those polygons related to that image were displayed (and
available for edits etc). That worked great.
</pre>
</blockquote>
<pre wrap="">
Is filtering for visual purposes so that you can see what is going on?
Or is filtering for performance and browser limits? Did you try
solution 0 which is to do no filtering and see if it works?
</pre>
<blockquote type="cite">
<pre wrap="">
How do I do the same thing with Geomoose v2.8 for my app? Some possible
"solutions" (I like #3):
1. Convert the old 2.4 vector editing system to a user extension and use it
instead of WFS-T
- a lot of work, uses deprecated code, and no benefit to the
Geomoose community
or
2. Create a layer per image_id in the TingyOWS config.xml file and have
Geomoose switch layer name when the user selects the image.
- as images get added to the system the config.xml file must be updated
(could be automated, but clunky)
- each layer would point to a table in the database which would make the
database ugly
(hundreds of tables). I might be able to use views instead of tables to
make it slightly less ugly, but TinyOWS might not do inserts into a view.
Dunno about that.
- could be some limitations on the number of layers in the config.xml
file (or performance issues?).
or
3. Add functionality to Geomoose to accept attribute filters in the mapbook
and pass the filters to the OpenLayers definition.
- adds complexity to the mapbook syntax (so more documentation, testing,
maint., etc).
- the logic may be similar to the mapbook's search/query mechanism of
specifying input types of layer,template,fieldname,comparitor,value so maybe
some of the code could be used.
</pre>
</blockquote>
<pre wrap="">
This sounds like an option worth exploring and may have other general
applicaitons.
</pre>
<blockquote type="cite">
<pre wrap="">
or
4. Other?
</pre>
</blockquote>
<pre wrap="">
My ideas are sort of light on this one, hopefully others have further ideas.
Best regards, Eli
</pre>
<blockquote type="cite">
<pre wrap="">
Thanks for any input!
--
Best Regards,
Brent Fraser
_______________________________________________
Geomoose-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/geomoose-users">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>