[Geomoose-users] using WFS-T
Brent Fraser
bfraser at geoanalytic.com
Wed Mar 23 16:02:29 PDT 2016
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 <mailto: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 <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
>> <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20160323/df321db8/attachment-0001.html>
More information about the Geomoose-users
mailing list