nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

All fields MUST be visible when publishing from the Parcel Fabric?

Keith_Forte

Today, we began attempting to publish individual Parcel Types as feature services. We have long been publishing simple feature classes to Enterprise and it has been our policy to field map as 'not visible' a number of system fields that unnecessarily overload the public users.

We discovered that we are not able to do so from the feature classes within the Fabric because of the following error: 00302: All fields in datasets with <value> must be visible: field <value> in layer <value> is not

I am hoping that this is a bug, but the help page for the error does not indicate as such...I am getting the sense from the documentation that this is a "too bad, deal with it" kind of issue.

Our knee-jerk work around is to run the Feature Class to Feature Class GPtool with the desired Field Mapping to an output location outside the Fabric, then publish from there...here is what stinks about that...after every editing period, we will have to stop the service, run the GPtool, start the service.

This can't be the endgame...all we are asking for is to be able to serve out live edits with only the desired fields...jane and john have no use for MiscloseRatio data!

I am hoping I am missing something quite obvious...please advise 🙂

Najděte více příspěvků označených jako

General

Accepted answers

jcarlson

This is a totally different solution, but what we do for our parcel fabric is maintain a separate "Hosted Fabric" layer, which you can see here (or at least the "current features" view of it): https://maps.co.kendall.il.us/portal/home/item.html?id=c500c8284edd4112a9ee1a96236a72fc

There's also a separate service that collects all the boundary lines and points in a similar manner.

We then have a nightly script that checks the "real" fabric for changes, then applies them to the hosted layers.

We do this for a number of reasons.

hosted feature services use the server's shared instance pool, so public viewers do not impact users actively editing or working with the "real" fabric
through a reshaping process, the hosted features have the actual created/retired record name and recorded date, rather than simply the globalID of the records
our DB machine can actually cycle down for maintenance, updates, etc., with no impact to the public layers
- we have a dedicated machine for the parcel fabric database. as a cloud machine, being able to turn it off outside of business hours represents hundreds of dollars in savings
extra fields can be dropped
the hosted layer can have extra fields not in the fabric, which get updated from our assessments database (another script)
hosted records layer can have attachments, to which we attach PDF "change record" documents, etc

It was a lot of work to set up, honestly, but it provides our end users with the data they really want. The updates are all automatic, so I haven't had to even think about updating the public layers in months, but they refresh every night with the latest data. It's great!

All comments

Syvertson

Please correct me if I am wrong, but I think I understand your use case and I think I anm doing something different that would help.

I only use the feature service for internal use for parcel fabric. Then I created a separate Map Service connected to the original database, not the feature service. In the map service, I can customize which fields are visible and also can add joins or relates. You add only the features not the parcel fabric "controller."

Does this help?

Keith_Forte

Interesting...I will test!

Keith_Forte

Thanks for the idea...unfortunately we do want to continue to offer public users the ability to export.

jcarlson

There's also a separate service that collects all the boundary lines and points in a similar manner.

We then have a nightly script that checks the "real" fabric for changes, then applies them to the hosted layers.

We do this for a number of reasons.

hosted feature services use the server's shared instance pool, so public viewers do not impact users actively editing or working with the "real" fabric
through a reshaping process, the hosted features have the actual created/retired record name and recorded date, rather than simply the globalID of the records
our DB machine can actually cycle down for maintenance, updates, etc., with no impact to the public layers
- we have a dedicated machine for the parcel fabric database. as a cloud machine, being able to turn it off outside of business hours represents hundreds of dollars in savings
extra fields can be dropped
the hosted layer can have extra fields not in the fabric, which get updated from our assessments database (another script)
hosted records layer can have attachments, to which we attach PDF "change record" documents, etc

Keith_Forte

Josh,

Your process is eerily close to what we have on our whiteboard! We are in the process of testing multiple courses of action, all of which are leading us to 'nightly' rather than 'live' updates. We are hamstrung by a lot of internal legacy business processes that leverage extremely old technology...one of which is the assessment CAMA system, so your 'extra fields' script is on our radar as well.

Thanks again!

Also, I just recognized your Name/Org...we will likely cross paths through Panda at some point 🙂

Keith

jcarlson

Great minds think alike, right? Sounds like the same boat we're in over here.

Speaking of Pandas, I did a guest presentation for them and a good chunk of it was actually walking through the "hosted layer update" script referenced in my post. They posted the recording here: https://www.youtube.com/watch?v=EsU4mmXlt0Y

The assessments, parcel sales, and CAMA scripts aren't demoed here, but they use a lot of the same concepts. The biggest thing is getting familiar (if you aren't already) with the pandas Python library, and ESRI's spatially enabled dataframe that builds off it via the ArcGIS Python API.

AmirBar-Maor

@Keith_Forte

THIS IS NOT A BUG.

There is a valid reason why all of the fields must be visible when you publish feature services as branch version.

Before I try to explain...

1. You can take a publish feature layer and configure it in a web map to hide any fields users are not supposed to see.

2. You can publish the map as read-only: without enabling versioning, without having the parcel fabric controller in the map, without allowing editing of features. In that case, you should be able to hide any fields

3. You can create a database view of any table (DBA skills required), with any fields and publish it.

So why you must have all the fields visible?

Every time you publish a map with versioning enabled it acts as a workspace (geodatabase). Every published map has its own versions - it acts as a workspace.

for example - if you have an attribute rule on a field that doesn't exist it would fail.

In the new paradigm of 'web GIS' you can configure your published layers.

This also aligns with a future vision in which you might never see the 'geodatabase' similar to how ArcGIS Online hosted feature layers work.

There are other software engineering aspects that are hard to explain.

Amir

Keith_Forte

Thank you Amir! The explanation of the requirement is much appreciated.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.