Regards, Helmoet de Zwijger.
Hi guys, I'm trying to read a WMS using a FeatureReader. Using an ordinary reader works just fine, however, creating a box and use it as input for a featurereader (same params etc) yields no result.
Page 1 / 1
Hi Helmoet,
the FME log window should contain the URL used by the FeatureReader to access get the bitmap from the WMS server. Try copying the URL and pasting into a regular web browser to see if you are able to intercept an error message (usually downloaded as a text file).
David
Hi Helmoet,
Did you try the HTTP fetcher instead of the feature reader?
Groet,
Itay
Hi Helmoet, the feature reader should work as you describe. Is the bounding box in the same coordinate system? Please share the url of the WMS for further investigation.
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 @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
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
7. So for now, "that's all, folks"
Hi,
Thanks for your answers!
I think that #5 in helmoet's answer might be the best way to handle the problem.
Thanks and 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
7. So for now, "that's all, folks"
I've tested the WMS using a featureReader in 2017.1 and works as expected.
If it's possible to upgrade you should do it otherwise use a workaround.
Greetings from sunny Hyeres,
Wilko
Hi,
I started using the WMS Reader yesterday, and I experienced the same behavior. After analyzing the http calls made from from FME, ArcGIS and MapInfo to the WMS server using the network traffic sniffer Wireshark, I can see that the X and Y values are switched in the http call from FME. The correct order is Ymin, Xmin, Ymax, Xmax. FME sends Xmin, Ymin, Xmax, Ymax.
In other words, it seems to me as this is a long lived bug in FME.
Regards,
Daniel