[Geomoose-users] using WFS-T
Dan Little
theduckylittle at gmail.com
Wed Mar 23 16:50:35 PDT 2016
At some point, you'll need to get brave and do a pull request. For now,
I'll put merging this code on my to-do list.
On Mar 23, 2016 6:02 PM, "Brent Fraser" <bfraser at geoanalytic.com> wrote:
> Dan,
>
> Not an extension (hmm, that never occurred to me), just a few minor code
> additions. The mapbook would look like (actually I don't test for the
> type):
>
> <filter type="CQL"><![CDATA[image_id = 0 and
> reviewstatus_id<>24]]></filter>
>
> and the new Geomoose API call would be used like:
> var filter = "reviewstatus_id<>24 and image_id="+id;
> GeoMOOSE.updateLayerFilter("Icebergs_WFS",filter);
>
> and the code additions :
>
> geomoose.js, line 228
> // BWF (Add feature filtering): updateLayerFilter (CQL)
> updateLayerFilter : function(layerName, CQL_text) {
> Application.getMapSource(layerName).updateFilter(CQL_text);
> },
>
> Vector.js, line 266
> // BWF (Add feature filtering): CQL filter to restrict features
> sent from server
> var filter_tag = mapbook_entry.getElementsByTagName('filter');
> if (filter_tag) {
> var filter_text =
> OpenLayers.Util.getXmlNodeValue(filter_tag[0]);
> var filter = new OpenLayers.Filter.Logical();
> var format_CQL = new OpenLayers.Format.CQL();
> try {
> filter = format_CQL.read(filter_text);
> } catch (err) {
> // GeoMOOSE.error('OpenLayers CQL parser is unable to
> parse:'+filter_text);
> }
> if (filter) {
> this.filter = filter;
> }
> }
>
> WFS.js, line 47:
> filter: this.filter, // BWF (Add feature filtering)
>
> WFS.js, line 88:
> /* BWF: (Add feature filtering) CQL filter
> */
> updateFilter: function(filter_text){
> var filter = new OpenLayers.Filter.Logical();
> var format_CQL = new OpenLayers.Format.CQL();
> try {
> filter = format_CQL.read(filter_text);
> } catch (err) {
> // GeoMOOSE.error('OpenLayers CQL parser is unable to
> parse:'+filter_text);
> }
> if (filter) {
> this.filter = filter;
> this._ol_layer.filter = this.filter;
> this._ol_layer.redraw({force: true});
> this._ol_layer.refresh({force: true});
> }
> },
>
>
> Best Regards,
> Brent Fraser
>
> On 3/23/2016 4:04 PM, Dan Little wrote:
>
> Brent,
>
> I'd love to see the extension once it's done and look at including it in
> the 2.9 code. My GeoMoose coding always comes in bursts and I'm bursting
> today...
>
> -Duck
>
> On Mon, Mar 21, 2016 at 12:23 PM, Brent Fraser <bfraser at geoanalytic.com>
> wrote:
>
>> 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>
>> 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> <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 listGeomoose-users at lists.osgeo.orghttp://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
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Geomoose-users mailing listGeomoose-users at lists.osgeo.orghttp://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/20160323/57144534/attachment-0001.html>
More information about the Geomoose-users
mailing list