I am trying to add layers from a WFS-service as a new item in our Portal. So that users only can use the selected, approved layers within the service
When adding the WFS with the New Item-button in our content, I can choose the layer from a list of available layers in the WFS-service.
The problem now is:
The portal-item always uses/connects to the first layer in the layerlist.
For example the WFS-layerlist contains the layers:
- layer 1
- layer 2
FIrst I add New item to the portel choosing Layer 1.
Then I use the same WFS-service-url and then I choose Layer 2.
Now I have 2 portal-items. 1 connecting to Layer 1 and the connecting to Layer 2.
I check in a web map. Both layers display Layer 1.
When I check the item in the AGOL-assistent I see both items using the layer with the name Layer 1. And I am very sure I chose different layers for the items. If I change the layername in the JSON for the item connecting to Layer 2, then it works as intended.
Anyone had this problem and found a solution? Besides using AGOL assistent?
Feel free to ask for more information, English is not my first language (Dutch is).
Solved! Go to Solution.
Hi @DaveDaverveld which version of Portal are you using please?
This is a known defect and has been fixed in version 11.5.
One possible workaround solution is to add the service directly within Map Viewer Classic (it should use the correct layer) then save that layer as a portal item from there.
Please do let me know if this helps!
Hi @DaveDaverveld which version of Portal are you using please?
This is a known defect and has been fixed in version 11.5.
One possible workaround solution is to add the service directly within Map Viewer Classic (it should use the correct layer) then save that layer as a portal item from there.
Please do let me know if this helps!
Thanks. This helps in the future.
We can't go to 11.5 yet because of the mulitude of apps that can't be used after 11.5 update. After converting those apps we will go to 11.5 very fast.
That's great to hear. I hope the Map Viewer Classic workaround is useful in the meantime.
I've experienced similar strangeness. From what I can remember, the workaround (for whatever reason) was to use the Portal root admin account and/or login to the portal from the server or server url i.e. hostname:port\arcgis\home