[Geomoose-users] using WFS-T
Dan Little
theduckylittle at gmail.com
Wed Mar 23 15:04:09 PDT 2016
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/03c6a234/attachment-0001.html>
More information about the Geomoose-users
mailing list