[Geomoose-users] using WFS-T
Dan Little
theduckylittle at gmail.com
Tue Mar 29 13:35:18 PDT 2016
Ok Brent, y'all got more code to test:
https://github.com/geomoose/geomoose/issues/121
On Wed, Mar 23, 2016 at 6:50 PM, Dan Little <theduckylittle at gmail.com>
wrote:
> 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>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/20160329/51938a55/attachment-0001.html>
More information about the Geomoose-users
mailing list