Water Sampling Point Connundrum

[BrianO_keefe]

Ok. We are working on a Fish sample project for our Stormwater group.

The basics of the project are that they have X number of Sample Sites. Each site is sampled X times per year. They gather fish from these sites, count, label, identify, etc. Then they run reports on those sample sites against that collected fish data.

This is "part" of Phase 1 of a larger project that will have more OBVIOUSLY spatially related data. In THIS instance, we don't "technically" need to have a dot on a map for each report because those dots on the map are identified by the Sample Site ID. However, we want to build this "part" of Phase 1 for Collector... as a web map. So we have some questions about Collector and AGOL.

Since we only need to register each sample event with a sample site, is there some way to allow them to open collector, hit the plus button, and enter their fish data with the sample site being a drop down, and ignore the spatial aspect... in other words, ignore the X,Y coords for each sample event because they will ALWAYS happen at one of the pre-arranged, permanently stationed Water Sample Sites. I ask because Collector TECHNICALLY includes the spatial component with each entry. It automatically logs each new entry with a new X,Y point. I want to ignore that. BUT I want each report to line up perfectly with the exact same coords for the Sample Site locations.

Ideas?

[TobiasFimpel1]

Perhaps useful info for your project: ESRI just announced that the Collector App will support editing related tables in the December release. "Ability to edit pop-up windows with related data from the Collector for ArcGIS app" ... we'll need to wait and see what the details look like.

[GISSupport3]

You could have the sample sites' location pre-populated in your map?

How you manage the multiple samples (with todays functionality) is another issue.

[PaulLohr]

Brian,

If this were my project, I would focus on a proper data structure rather than making a piece of software a requirement. It sounds like you may want to consider a one-to-many relationship between sample sites and sampling events. "Will this fulfill your reporting requirements" is a question you may want to ponder. Once you have your data model established, then perhaps think about how the data will be collected and maintained.

Support for viewing, editing, and creating related data is weak to non-existent in Collector, Explorer, ArcGIS for iOS, and ArcGIS Online. If you find something in one of these applications that fully supports your efforts...great. I would spend a fair amount of time making sure it works.

ArcPad will almost surely cover your needs in mobile data collection with related data. It is a stable and well developed product when compared with the above mentioned applications. Presentation of your data might be handled by the ArcGIS Online system.

Paul Lohr

[TobiasFimpel1]

Good point Paul, if both offline usage and related tables are necessary it's hard to beat ArcPad. Although I would add that from my experience it is not a stable and well developed product, despite it's age. I have had to (try to) work through too many bugs with it. But that's just my experience and I'm definitely not  at all an expert ArcPad user.

Two solutions that I have used as alternatives (but not in production environments, so I can't say whether the rubber has hit the road yet with these):

1. if you know javascript and your field crew has a decent network connection you can use the Geofrom template and modify it's "form-constructor-query" (lacking a better word here) and it's applyEdits statement to point to a related table in your feature service. Then get the primary field field value from the feature on the map - i.e. the lake that the user clicks on.   

2. You can have a SQL-intersect-view on the back-end that intersects observation-event-points submitted by the field crew (using collector, for example) with a sample site polygon that you have in the map. That way you get your key ID and effectively build a "related table". The only requirement here is that your field crew is able to place the point within the sample site polygon (perhaps this could even be a point feature, that you only create a buffered dynamic sql-view from...not sure, maybe than then gets more complex and dynamic than it needs to be).