FeatureReader for WMS

Hi @helmoet & @david_r,

I'm having the same problems with WMS in a FeatureReader in FME 2017.1. I've tried the same in FME 2015, but with the same problem.

The url that is printed in the fme log works just fine though.

With a "Normal" reader it works just fine also, but then i have to set the bounding box directly in the reader (and cannot calculate it in the workspace).

Are you still having the same problems? Did you find any solution?

Regards,

/Mikael

Hi @stalknecht, @miay, @david_r, @etls_itay,

I did some playing around (in FME 2015...) with this VERY old issue. This is what I found:

1. Using FeatureReader on WMS, in the logging there is this message - not sure how to interpret it:

Notice - reader format `WMS' does not support querying by spatial predicate, but supports envelope queries.  FME will create equivalent results by performing spatial predicate calculations locally.  Performance should not be affected.

2. Ignoring this message, I tried to use different kinds of spatial filters. Some of them (No spatial filter, Envelope intersect, intersect, within) resulted in the complete contents of the whole dataset (since I was experimenting on the dutch AHN1 - PDOK, it gave me the whole of the Netherlands at a small scale). Other spatial filters didn't come up with any result (crosses, disjoint, overlaps and touches). Luckily, the remaining two (containing, Equals) gave me three correct responses out of the four bounding boxes I was feeding to the FeatureReader 

3. Inspecting the log file again, it struck my eye that the first request was fired to the WMS using a bounding box that contains the whole of the Netherlands. Strangely, this big bounding box was also the one missing result out of the four supplied bounding boxes. So, a solution for this pathway is to supply the bb-to-be-missed myself using a BoundingBoxAccumulator and have the Original features wait until the bb-to-be-missed has been processed, using a FeatureHolder. Like this:

And indeed, it gave me a good result (yet might not be intended use of FeatureReader).

4. Thanks David for the suggestion on the URL in the log window. I collected them, put them in a file and read them back in a workspace using a textfile reader. Using the HTTPCaller (thanks Itay) I fired the requests (GET...) to the WMS server. Now what should I do with the response? I tried very unsuccessfully to use the GeometryReplacer on the _response_body attribute (there really should be an 'Automatic' Geometry Encoding method). Reluctantly, I finally ended up writing the HTTPCaller result to file and read it back into the workspace using a FeatureReader (Geotiff), and that works nice also, although one has to construct the GetMap request URL oneselve (which I prefer to have FME puzzle about it)  Anyway, like this:

The Counter and the AttributeCreator I used to construct a different filename for the output from the HTTPCaller, since I suspect the FeatureReader to take some time to read the results, time FME uses to fire up the next record from the text file which overwrites the intermediate file (missed something there, too). However, using different filenames for each fetched WMS request works fine.

5. And Mikael, not sure how you are going to deploy your setup, but a completely different approach could be using the WorkspaceRunner. First, create the 'workhorse' workspace that uses a WMS reader the normal way. You can publish the search envelope parameter on the WMS reader, and let the workhorse do whatever you want to do for one tile. Then a pretty simple workspace calls the workhorse for all tiles you want to be processed, like this:

and the publishing stuff (do not forget to supply the resulting attributes from the BoundsExtractor into the workspace parameters in the WorkspaceRunner):

6. And Wilko, since you're asking, the URL I was experimenting with: 

https://geodata.nationaalgeoregister.nl/ahn1/wms?SERVICE=WMS&SERVICE;=WMS&VERSION;=1.1.1&REQUEST;=GetMap&LAYERS;=ahn1_5m&STYLES;=&FORMAT;=image%2Fgeotiff&SRS;=EPSG%3A28992&BBOX;=100000%2C400000%2C100500%2C400500&WIDTH;=100&HEIGHT;=100&EXCEPTIONS;=application%2Fvnd.ogc.se_xml, I entered it in the WMS reader as 

https://geodata.nationaalgeoregister.nl/ahn1/wms?SERVICE=WMS&SERVICE;=WMS&VERSION;=1.1.1&REQUEST;=GetCapabilities

7. So for now, "that's all, folks"

Hi @stalknecht, @miay, @david_r, @etls_itay,

I did some playing around (in FME 2015...) with this VERY old issue. This is what I found:

1. Using FeatureReader on WMS, in the logging there is this message - not sure how to interpret it:

Notice - reader format `WMS' does not support querying by spatial predicate, but supports envelope queries.  FME will create equivalent results by performing spatial predicate calculations locally.  Performance should not be affected.

2. Ignoring this message, I tried to use different kinds of spatial filters. Some of them (No spatial filter, Envelope intersect, intersect, within) resulted in the complete contents of the whole dataset (since I was experimenting on the dutch AHN1 - PDOK, it gave me the whole of the Netherlands at a small scale). Other spatial filters didn't come up with any result (crosses, disjoint, overlaps and touches). Luckily, the remaining two (containing, Equals) gave me three correct responses out of the four bounding boxes I was feeding to the FeatureReader 

3. Inspecting the log file again, it struck my eye that the first request was fired to the WMS using a bounding box that contains the whole of the Netherlands. Strangely, this big bounding box was also the one missing result out of the four supplied bounding boxes. So, a solution for this pathway is to supply the bb-to-be-missed myself using a BoundingBoxAccumulator and have the Original features wait until the bb-to-be-missed has been processed, using a FeatureHolder. Like this:

And indeed, it gave me a good result (yet might not be intended use of FeatureReader).

4. Thanks David for the suggestion on the URL in the log window. I collected them, put them in a file and read them back in a workspace using a textfile reader. Using the HTTPCaller (thanks Itay) I fired the requests (GET...) to the WMS server. Now what should I do with the response? I tried very unsuccessfully to use the GeometryReplacer on the _response_body attribute (there really should be an 'Automatic' Geometry Encoding method). Reluctantly, I finally ended up writing the HTTPCaller result to file and read it back into the workspace using a FeatureReader (Geotiff), and that works nice also, although one has to construct the GetMap request URL oneselve (which I prefer to have FME puzzle about it)  Anyway, like this:

The Counter and the AttributeCreator I used to construct a different filename for the output from the HTTPCaller, since I suspect the FeatureReader to take some time to read the results, time FME uses to fire up the next record from the text file which overwrites the intermediate file (missed something there, too). However, using different filenames for each fetched WMS request works fine.

5. And Mikael, not sure how you are going to deploy your setup, but a completely different approach could be using the WorkspaceRunner. First, create the 'workhorse' workspace that uses a WMS reader the normal way. You can publish the search envelope parameter on the WMS reader, and let the workhorse do whatever you want to do for one tile. Then a pretty simple workspace calls the workhorse for all tiles you want to be processed, like this:

and the publishing stuff (do not forget to supply the resulting attributes from the BoundsExtractor into the workspace parameters in the WorkspaceRunner):

6. And Wilko, since you're asking, the URL I was experimenting with: 

https://geodata.nationaalgeoregister.nl/ahn1/wms?SERVICE=WMS&SERVICE;=WMS&VERSION;=1.1.1&REQUEST;=GetMap&LAYERS;=ahn1_5m&STYLES;=&FORMAT;=image%2Fgeotiff&SRS;=EPSG%3A28992&BBOX;=100000%2C400000%2C100500%2C400500&WIDTH;=100&HEIGHT;=100&EXCEPTIONS;=application%2Fvnd.ogc.se_xml, I entered it in the WMS reader as 

https://geodata.nationaalgeoregister.nl/ahn1/wms?SERVICE=WMS&SERVICE;=WMS&VERSION;=1.1.1&REQUEST;=GetCapabilities

7. So for now, "that's all, folks"