[Geomoose-users] using WFS-T
Brent Fraser
bfraser at geoanalytic.com
Mon Mar 21 10:23:28 PDT 2016
Jim,
I've changed my mind. I've implemented CQL filters to allow me to
easily do things like:
<filter type="CQL">
<![CDATA[reviewstatus_id<>24 and reviewstatus_id<>18 and
image_id = 0]]>
</filter>
This requires only a minimal amount of code additions to Geomoose as
OpenLayers has a parser to convert CQL to its filter object.
And using the new API function would be like:
var filter = "reviewstatus_id<>24 and reviewstatus_id<>18 and
image_id="+id;
GeoMOOSE.updateLayerFilter("Icebergs_WFS",filter);
I'll file an issue, and after some more testing, I'll do a pull request.
Best Regards,
Brent Fraser
On 3/17/2016 9:45 AM, Brent Fraser wrote:
> Jim,
>
> Yes, this is my thinking as well. The additional mapbook syntax is
> a bit of a question mark, but I guess that would depend on how much of
> the OpenLayers filter syntax we would want to support.
>
> For my purposes I've added to my wfs mapsource:
> <filter type="equal_to" property="image_id" value="204"/>
>
> but this will likely be too trivial for general cases since OpenLayers
> allows queries like:
>
> filter: new OpenLayers.Filter.Logical({
> type: OpenLayers.Filter.Logical.OR,
> filters: [
> new OpenLayers.Filter.Comparison({
> type: OpenLayers.Filter.Comparison.EQUAL_TO,
> property: "TYPE",
> value: "highway"
> }),
> new OpenLayers.Filter.Comparison({
> type: OpenLayers.Filter.Comparison.EQUAL_TO,
> property: "TYPE",
> value: "road"
> })
> ]
> })
>
> Not impossible but might take a little bit of design.
>
> Another possibility would be be to use CQL and let the user specify
> the CQL text then have OpenLayers parse it. I've run across
> references to this in my Googling, but I don't know much about it.
>
> As for the Geomoose code, I'm hacking together some code to do:
>
> from my extension code:
> params['image_id'] = id;
> GeoMOOSE.updateLayerFilter("Icebergs_WFS",params);
>
> where geomoose.js has
> updateLayerFilter : function(layerName, paramObject) {
> Application.getMapSource(layerName).updateFilter(paramObject);
>
> Now I have to do the rest of the coding...
> Best Regards,
> Brent Fraser
> On 3/17/2016 9:03 AM, James Klassen wrote:
>> I'm not sure this will work with the WFS layer, but this sounds like
>> something that GeoMOOSE.updateLayerParameters() would accomplish for WMS.
>>
>> Currently (and subject to change between versions), you can get at
>> the underlying OpenLayers layer object with:
>> Application.getMapSource('mapbook/path')._ol_layer
>>
>> This is something you could call from a script return from a service
>> or from a custom tab.
>>
>> Having to dig in the internals in an unsupported way is what usually
>> prompts me to suggest additions to GeoMOOSE.* Generally, I just do
>> what I need to get done and after it shakes out for a bit figure out
>> how it could be done more generically.
>>
>> Jim
>>
>> On Tue, Mar 15, 2016 at 9:58 PM, Brent Fraser
>> <bfraser at geoanalytic.com <mailto:bfraser at geoanalytic.com>> wrote:
>>
>> Hey Eli,
>>
>> 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.
>>
>> 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.
>>
>> I've hard-coded an OpenLayers attribute filter in WFS.js for
>> testing purposes:
>>
>> this._ol_layer = new OpenLayers.Layer.Vector(this.title, {
>> strategies: strategies,
>> projection: this.srsName,
>> styleMap : this.style_map,
>> visibility: false,
>> * filter: new OpenLayers.Filter.Comparison({
>> //BWF**
>> ** type: OpenLayers.Filter.Comparison.EQUAL_TO,**
>> ** property: "image_id",**
>> ** value: "204"**
>> ** }),**
>> ** proto*col: new OpenLayers.Protocol.WFS({
>> version: '1.1.0',
>> srsName: this.srsName,
>> url: this.url,
>> featureNS: this.featureNS,
>> featurePrefix: this.featurePrefix,
>> featureType: this.featureType,
>> geometryName: this.featureGeometryName,
>> schema: this.featureSchema
>> })
>> });
>>
>> 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...
>>
>> Best Regards,
>> Brent Fraser
>>
>> On 3/15/2016 5:57 PM, Eli Adam wrote:
>>> Hi Brent,
>>>
>>>
>>> On Tue, Mar 15, 2016 at 7:38 AM, Brent Fraser<bfraser at geoanalytic.com> <mailto:bfraser at geoanalytic.com> wrote:
>>>> 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.
>>> Cool, good to hear that it is working.
>>>
>>>> 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.
>>> 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?
>>>
>>>
>>>> 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.
>>> This sounds like an option worth exploring and may have other general
>>> applicaitons.
>>>
>>>> or
>>>>
>>>> 4. Other?
>>> My ideas are sort of light on this one, hopefully others have further ideas.
>>>
>>> Best regards, Eli
>>>
>>>> Thanks for any input!
>>>>
>>>> --
>>>> Best Regards,
>>>> Brent Fraser
>>>>
>>>>
>>>> _______________________________________________
>>>> Geomoose-users mailing list
>>>> Geomoose-users at lists.osgeo.org
>>>> <mailto:Geomoose-users at lists.osgeo.org>
>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> <mailto:Geomoose-users at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
>
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20160321/42b2cb15/attachment-0001.html>
More information about the Geomoose-users
mailing list