Subscribe to this thread
Home - General / All posts - wmf datasources missing mandantory parameter
KlausDE

6,316 post(s)
#10-Jan-19 16:23

I have problems to work with wmf datasources. Mfd9 reports:

Request rejected due to errors.

... (GetFeature) InternalExceptionCode: iiOperationParsingFailed.

... (GetFeature) Reason:

... (GetFeature) The mandatory parameter TYPENAMES is missing.

Here is an example:

https://www.wfs.nrw.de/gd/bk05?request=getcapabilities&service=wfs

Actually I had no luck with any of out administrations wmf services.

It would be nice if the Parser could be more forgiving when parameters are missing.

[title not editabe ]

KlausDE

6,316 post(s)
#10-Jan-19 16:43

Well, I found a wms server working with mfd9. But it contains only points apparently all of the same type:

http://www.bml3.nrw.de/service/bmlh

Dimitri


5,436 post(s)
#10-Jan-19 17:59

There are many WMS servers published. I believe the JOSM sources.map project has two.

Dimitri


5,436 post(s)
#10-Jan-19 18:05

I tried that link and got "Cannot get data from server" ... Does it require a login and password? Is the server up? Do they reject links from places they don't like, like China, or France?

[Edited... I changed my VPN to use a different geography. I can now see the get capabilities response in a browser, so I'm guessing they have some geographic filtering going.]

Dimitri


5,436 post(s)
#11-Jan-19 10:48

I had no luck with any of out administrations wmf services.

I suppose you mean WMS. So far, I've had good luck with WMS (see below).

About WFS: I had no luck with the link you provided. Trying it with QGIS reports that Q does not support the WFS version for that server. Strange...

Anyway, that got me curious, so I used Google to try to find WFS servers I could use for testing. Here is what I found:

1. It is surprisingly difficult to find a functioning WFS server, even if you avoid US government servers that might be off due to the current partial shutdown.

2. It's routine for a WFS server to be misconfigured.

3. It's routine for WFS servers to be unthinkably slow.

A good example of 2 and 3 above is:

http://giswebservices.massgis.state.ma.us/geoserver/wfs?request=getcapabilities

That is a WFS server run by the Massachusetts government which returns a huge number of "features" that are available. But the server is so incredibly slow it takes a while for those to appear. If you ask for one of them, even a very small one like the airports, consisting of a total of 42 points, it takes what seems to be almost five minutes for the server to provide the data.

At the same time, various layers within what is advertised to be a public server are forbidden to the public. Looking at the log, we see things like...

2019-01-11 09:44:31 Web request: (root)::[MassGIS]::[massgis:GISDATA.WETLANDSDEP_ARC] (DescribeFeatureType) (0.304 sec, 1.3 KB)

2019-01-11 09:44:32 Web request: (root)::[MassGIS]::[massgis:MASSNET.WEYMOUTH_FIBER_ARC] (DescribeFeatureType) (0.286 sec, 1.3 KB)

2019-01-11 09:44:32 *** (root)::[MassGIS]::[massgis:MASSNET.WEYMOUTH_FIBER_ARC] (DescribeFeatureType) The remote server returned an error: (403) Forbidden.

2019-01-11 09:44:32 Web request: (root)::[MassGIS]::[massgis:MORIS.DPA_WEYMOUTH_FORE_RIVER_ARC] (DescribeFeatureType) (0.315 sec, 1018 B)

2019-01-11 09:44:32 Web request: (root)::[MassGIS]::[massgis:WhitmanEnvironsL3TaxParAssess] (DescribeFeatureType) (0.310 sec, 5.7 KB)

The bottom line is that working with such servers can be frustrating because they may be misconfigured, or because when the server takes minutes to respond to even a tiny request it can appear that Manifold has hung, when it is simply waiting for a very slow server.

I think it should be possible to to abandon a too-slow server, and to allow a connection to a server to proceed while you do other things. I've written up and submitted a suggestion to that effect.

It looks like connection issues to WFS servers are fairly common. ESRI has written a page that I think was prompted by connection problems. It explains how to look at a WFS server in a browser:

http://enterprise.arcgis.com/en/server/latest/publish-services/windows/communicating-with-a-wfs-service-in-a-web-browser.htm

That's a good idea, because if the WFS GetCapabilities URL won't return sensible results in a browser, it won't do so in Arc, Q or Manifold, either. So that's a good first filter to see if a WFS server is functioning well enough to try a connection.

If you ever encounter a WFS server that responds OK when you put the GetCapabilities URL into a browser, but it does not render as expected (after applying big patience in the case of slow servers), send a bug report to tech support. It could be a misconfigured server, or it could be a problem in Manifold, or it could be both. Let tech sort that out.

In the meantime, all the WMS servers I've tried seem to work. For example, the National Map WMS servers at

https://nationalmap.gov/small_scale/infodocs/webservices.html

all work.

If anybody has a list of fast, guaranteed "on" WFS servers that are open to the public and can be used for testing, that would be very helpful!

KlausDE

6,316 post(s)
#11-Jan-19 11:25

Thank you. That is useful information and I can conform the incredible slow connections.

According to the description of the supplier the data are free.

Attached is the Capabilities document for the first not working link. It's not a valid xml document. The "mandatory parameter TYPENAMES" really is missing in this discription.

I have not installed the Data Interoperability Extension for our ArcGIS 10. So I sadly can't test access from ESRI and if for them TYPENAMES are mandatory.

Attachments:
BK5 WFS_Capabilities.txt

Dimitri


5,436 post(s)
#11-Jan-19 11:57

I'm going to go out on a limb here, as I really don't know the WFS spec, but just taking a wild guess I think that mandatory parameter error message is coming from the server, not from Manifold. I think the server is complaining that the request from Manifold is not including a parameter that the server wants.

Now, whether that parameter was never disclosed in the GetCapabilities document or if the necessary info is in there but Manifold isn't using it like the server wants, or whether any of that is something the spec requires, is over my head. I'd let tech sort it out. :-)

A lot of this stuff with servers is just accumulating a zoo of examples that are unusual. If Manifold can do something, whether or not it is in the spec, to enable very many more servers to work, that's OK, I think.

A good example are the servers that refuse to function if the client doesn't announce what web browser it is. Well, that's not in the spec at all, but if big organizations like NOAA insist on it, may as well humor them and tell them you're Mozilla or whatever when you connect. This could be something like that, or it could be an outright error in Manifold. Either way, I'd report it and get it into the pipeline.

KlausDE

6,316 post(s)
#11-Jan-19 17:14

I'd expect the Capabilities document should be some sort of xml document.

However renaming to extension .xml neither IE, nor Crome nor Firefox nor Opara can parse the document.

It would be helpful if someone from germany could try to access the data with ArcGIS and data interoperability extension. It's the map of soils of Northrhein-Westfalia in 1:5000 and might be interesting for others, too.

KlausDE

6,316 post(s)
#11-Jan-19 17:38

typeNames BTW is a mandatory parameter in the DescribeFeatureType request and then used by GetFeature to address a layer (from GeoServer 2.15 documentation)

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.