Feature Layer Views for non-hosted data

[ShelbyZelonisRoberson]

Hosted feature layer views in AGOL/Portal are great, but are there plans to allow these to be created on non-hosted feature layers (i.e., data that is registered with an enterprise geodatabase)? Yes, I could create my own views on the back end, but then I have to publish multiple layers. In some cases it would be easier to just make Views of them in my Portal like I can with hosted layers.

[JustinRoberson]

I would find this functionality to be very useful as well. This would prevent the need to publish many feature services on the ArcGIS Server just to have different views of the same data. Perhaps the views could be hosted feature services that are regularly updated based on the parent feature service that comes from the server and references registered data.

[AdelaideZumwalt1]

Feature layer views for non-hosted data would save me a ton of time as well. I want to hide certain data from contractors without having to publish it twice. 

[Anonymous User]

Thanks for posting & commenting on this idea.

We want to dig into this one a little more. Ultimately, creating a hosted feature layer view also creates/publishes a service, but the user interface/experience is different since you publish in the portal. Is your feedback mostly around the workflow for publishing - you would prefer to publish a view from your portal rather than from Desktop? 

It was mentioned, but I wanted to be sure to add that for referenced services, you can create views by applying definition queries and publishing services that still reference the source data. Let us know, though, if there is something specific for hosted views that you feel is missing for referenced data.

Hilary

[AdelaideZumwalt1]

Hi Hilary,

To answer your question:

You would prefer to publish a view from your portal rather than from Desktop?  Yes.

As most contractors are "users" of the data, it appears, unless I'm missing something, that they can easily go into the map, access the original data, and/or change the filters. I need certain fields to be gone (and not just hidden from view where they could easily change a filter and access them). This would be easy to do if I could simply create a view instead of republishing from Desktop.

Please let me know if I'm missing something.

Thanks,

Adelaide

[JustinRoberson]

Hi Hilary,

We presently do a lot of work with Collector. For this workflow we are publishing federated feature services into our portal that reference our enterprise geodatabase and are editable. If I want to then provide a read-only service of the same data, I need to then publish a second service of the same data so that I can share it more broadly without fear of it being edited accidentally. This consumes additional resources on our ArcGIS Server that could be used for more editable services. We are also starting to perform a similar workflow with more and more WebApp Builder web applications. We have 5 servers federated and are trying to use one for all of our hosted services and one for all of our federated services that reference registered data to help balance the load.

If this cannot be done via a federated service, I’d love to see something similar to the collaboration functionality, where you identify a “parent” federated service that references our enterprise geodatabase. And then on some predetermined schedule (daily, weekly, etc.) a hosted service is generated or updated. This would allow for different views of the same data but reduce the amount of server overhead to provide them since they would be hosted and could scale better. This would still preserve that connection to our enterprise geodatabase so that we can be certain all of our data remains up to date and we do not need to republish hosted data via a scripting or manual process.

Many of our users are comfortable managing and dealing with hosted data. Once you introduce the server and enterprise geodatabase portions we are mostly only allowing GIS staff to publish those types of services given the nuances and complexities of doing so.

I hope this provides the context you are looking for.

Thanks!

[ShelbyRoberson1]

Hi Hilary,

In my agency, I'm the only true GIS professional so I'm the only one who is publishing registered datasets from Desktop. However, I have a team of lighter GIS users who create content in our Portal. It’s much easier for them to create and save their own views of already-published layers than for me to teach them how to do it in Desktop (not to mention explaining the whole concept of geodatabases, enterprise systems, definition queries, etc).

I work for a police department, and we have datasets like incidents, calls for service, etc. that refresh every few seconds, so having this content registered to the enterprise geodatabase instead of hosted is a must.

Let me know if you have more questions!

Shelby 

[Anonymous User]

Hi Adelaide,

Thanks for the response. If you apply a definition query in ArcGIS Pro and then publish off of of that query, your users in the portal wouldn't be able to see/expose data outside of the query. (If I apply a definition query to only show 3 field then publish that data, users in my portal would only see those 3 fields in the map, under the item's data tab, etc.) If you are just using a filter on the data (for example, applying a filter on the layer in your portal) and then sharing that data, users would be able to unfilter and see the rest of the records.

Hilary

[Anonymous User]

Hi Shelby,

Thanks for the context! When you're creating views, how do you characterize the view? Hiding certain fields/features, changing symbology, etc? How many views would you need to create off of one service?

Thanks!

Hilary 

[AdelaideZumwalt1]

Thanks for your response Hilary. I should clarify that we have enterprise, but we have not implemented Portal. So any publishing we do has to do from ArcMap until 2.4 comes out. But yes, it still requires republishing, then I have to add the data to my content using a different username/password (security), then add it to the map and configure pop-ups, labeling etc. when creating a layer view would just be so much simpler. 

And like Shelby said, allowing others to create views would be really nice without them needing ArcMap.

[ThomasEdghill]

Hi Justin, thank you for providing this feedback and deeper insight into your workflows. There is one part of your comment which I was hoping to offer some suggestions and gather further feedback on. You mentioned:

...we are publishing federated feature services into our portal that reference our enterprise geodatabase and are editable. If I want to then provide a read-only service of the same data, I need to then publish a second service of the same data so that I can share it more broadly without fear of it being edited accidentally.

If you are using feature services which are published to your federated server, you may have luck by using only the Map Service endpoint in order to deliver a "read-only" service of the same data.

When a Feature Service is published, investigating at REST shows that you are really publishing two endpoints: A Map Service, and a Feature Service. The Feature Service will retain any of the editing permissions defined upon publishing or set in ArcGIS Server Manager, and provides editing capabilities to the underlying data. The Map Service on the other hand does not provide editing capabilities, and can optionally be used to query the underlying data in a read-only manner, depending on how it's configured.

I pulled up Esri's Sample Server to demonstrate this. There is a Feature Service published to this server called DamageAssessment, but when looking at REST, we can see that there are actually two associated endpoints, the map service, and the feature service. 

If you were to load the map service endpoint into a webmap, there is no way to perform edits, but you can still see all of the underlying data and perform queries on it. Editing is not possible unless the Feature Service is also added to the map.

It sounds like this could perhaps be a strategy to use if you wanted to provide a read-only service of the same data, without needing to impose any additional load on the server. Have you explored this capability? If so, I'd love to learn more about what works and doesn't work for you, so that we can better understand some of these limitations. I hope this helps!