idea Feature Layer Views for non-hosted data in ArcGIS Enterprise Ideas

Feature Layer Views for non-hosted data

ShelbyZelonisRoberson — Thu, 31 May 2018 14:56:33 GMT

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.

Re: Feature Layer Views for non-hosted data

JustinRoberson — Thu, 31 May 2018 15:03:23 GMT

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.

Re: Feature Layer Views for non-hosted data

AdelaideZumwalt1 — Mon, 10 Dec 2018 21:50:51 GMT

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.

Re: Feature Layer Views for non-hosted data

Anonymous User — Fri, 29 Mar 2019 00:24:03 GMT

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

Re: Feature Layer Views for non-hosted data

AdelaideZumwalt1 — Mon, 01 Apr 2019 15:30:17 GMT

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

Re: Feature Layer Views for non-hosted data

JustinRoberson — Tue, 02 Apr 2019 14:01:50 GMT

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!

Re: Feature Layer Views for non-hosted data

ShelbyRoberson1 — Tue, 02 Apr 2019 14:05:49 GMT

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

Re: Feature Layer Views for non-hosted data

Anonymous User — Thu, 04 Apr 2019 00:38:36 GMT

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

Re: Feature Layer Views for non-hosted data

Anonymous User — Thu, 04 Apr 2019 00:48:25 GMT

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

Re: Feature Layer Views for non-hosted data

AdelaideZumwalt1 — Thu, 04 Apr 2019 00:48:33 GMT

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.

Re: Feature Layer Views for non-hosted data

ThomasEdghill — Thu, 04 Apr 2019 00:53:05 GMT

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!

Re: Feature Layer Views for non-hosted data

ShelbyZelonisRoberson — Thu, 04 Apr 2019 11:16:24 GMT

It depends - for the most common use case it would be 6 different views per feature service (one for each of our police districts/crime analysts) and each view would hide features. Most likely each analyst would create their own view of a countywide dataset that shows features for their district only, and there are use cases where they would also want their own symbology. This would allow them to only use/see a much smaller and more manageable subset of the full data but retain a near real-time version since it is registered with the EGDB.

Re: Feature Layer Views for non-hosted data

JulieMikolajczyk3 — Thu, 04 Apr 2019 17:35:04 GMT

We have similar workflows to many of the use cases already listed. One use case is to apply different filters to the data after it is published (it's republished every six hours). We don't want to have to overwrite/republish five layers with definition queries when overwriting/republishing one and having several different views that "just work" does the same trick. Most of the data for this particular project is in an enterprise geodatabase using server services, but we have to publish this data to AGOL just to take advantage of hosted feature layer views.

Re: Feature Layer Views for non-hosted data

JustinRoberson — Thu, 04 Apr 2019 19:42:03 GMT

Hi Thomas,

Thank you for the suggestion. I am aware that a map service can be used for some use cases. Unless I am missing something, I believe that any additional configuration of the map service layer (pop-ups, filters, etc.) are only saved in the web map in which it is being used. If I use a feature service, I am able to save the layer configuration at the item level. This allows many users to grab the feature layer item and add it to a map and it will already be configured in the Portal environment. If this is incorrect, please let me know.

I also know that the feature service needs to be shared with the same permissions as the underlying map service. So I am unsure if this could cause issues where I want the underlying map service to have a different level of security than the feature service.

But to echo some of the other comments, I think there is value in this process being more simplistic and easy for users that do not have a ton of in-depth enterprise GIS knowledge.

Re: Feature Layer Views for non-hosted data

DominicDoiron1 — Wed, 02 Oct 2019 18:17:47 GMT

This is something that would be of importance to us. We have authoritative data hosted on our Enterprise Geo database that is used by non-GIS application. These datasets are updated anywhere between 15 minutes to every month. We want to be able to publish our data to ArcGIS Enterprise and give users the ability to create Views tailored for their needs without having to duplicate the data as Hosted Feature Services. We are using Enterprise as a Self-Service platform for users who whats to do their own maps and analysis on authoritative data. Right now a User that creates a map with our Feature Service (data in SDE) and applies a filter on it, this affects everyone accessing this particular layer.

Re: Feature Layer Views for non-hosted data

DamonNelton — Fri, 01 Oct 2021 18:17:23 GMT

Been awhile since a comment on this topic. Anyone still following this thread got any updates. I'd like to be able to publish a reference non-hosted feature layer that is filtered by geographic space like you can in a portal hosted layer.

Thanks Damon

Re: Feature Layer Views for non-hosted data

JoyDRoberts — Fri, 24 Jun 2022 17:36:58 GMT

^^What they all said. I have similar needs here at a large utility. I have data that is referenced from a database and that is edited by one, and only one, team.

Other teams/business units need some portion of that data, usually with fewer fields and definitely in a read-only state.

Creating Views like are available on hosted layers would seem to be the simple answer.
Having to publish multiple versions of the same data with different editing permissions, def. queries and symbology seems inefficient for both the GIS team and the server bandwidth/resources.

Re: Feature Layer Views for non-hosted data

MatthewKelly_SP — Thu, 01 Feb 2024 00:39:54 GMT

Need this from an operational point of view.

Re: Feature Layer Views for non-hosted data

Anne_Tetley — Wed, 28 Aug 2024 07:46:33 GMT

Old thread but we have the same requirements. Currently I publish view and edit versions of a lot of our referenced services. We use alot of services in ArcPro in which feature services are useful for a wider range of functionality even for view only user so I don't think we could just use the feature services for editing.

Re: Feature Layer Views for non-hosted data

MattyMaps — Wed, 04 Jun 2025 18:53:34 GMT

I cant share survey results normally, due to this limitation. Please add this functionality