Field Data Organization Best Practices - Geometries in one Hosted Feature Service or Separate?

[Henry]

Hi all,

Typically around the end of the year I like to reasses our organization's field data collection layers for improvements, schema changes, etc.

We used to have a cloud-based Enterprise system that had a EGDB with feature datasets which had each geometry type in it. We had some trouble with that and our field tools so we started using Hosted Feature Services for each geometry.. I transitioned to doing everything in ArcGIS Online this year (for cost and other reasons).

We have in the past used hosted feature services to collect data in. We would have one for polygon geometry, one for line geometry, one for point geometry, all with generally the same fields/domains.

However, these had been independently uploaded as a separate feature service for each geometry.

I'm wondering if it may be more prudent once I've finalized any schema changes to upload the new datasets with each geometry type into the same Hosted Feature Service. So store them in one GDB, publish as one Hosted Feature Service that has Point, Polygon, and Line geometry. Different Hosted Feature Services for AGO can do this with the Build A Layer options, or it could be published from ArcGIS Pro/ArcMap.

Anyway, just wondering what others have done and their experience with this type of dataset organization. We like to use Survey123 to do field data collection, so ideally I'd like to be able to point Surveys to each different geometry type in the same feature service if possible, one form for each geomatery.

Thanks!

[jcarlson]

It really depends on how you plan to use the data. Setting up different survey forms to submit edits to different layers in a single service is easy enough, though.

If you ever need to get data back and forth between layers, having them in the same service makes things easier. For instance, I have a hosted feature layer with polygons and points. While there is not a relationship class between them, there are certain cases where I'd like pull in an attribute or summary statistic from one to the other. When they're in the same service, you can reference the $datastore global and get at your other layers that way, regardless of whether those other layers are in your map.

There's also only a single item in your Portal to maintain for settings, sharing, etc., and that can be a plus.

If it's just the 3 layers, I'd go ahead and put them all together.

[Henry]

Thanks for the input, @jcarlson. Having just one item in the Portal is a definite goal to streamline things a little better.

You bring up an interesting point about Relationship classes. Each one has and is intended to carry forward at most two photo attachments. I'm hoping with the existing GlobalIDs if I were to import the three feature classes to the same .GDB there wouldn't be any conflict or confusion about which which feature class has which related atttachments?