Collector for ArcGIS (iOS) update

[JeffShaner]

Today we updated Collector for ArcGIS on the iOS platform. This new release introduces some nice new features and a host of UX updates and bug fixes. Please read our official blog announcement from the ArcGIS Blog site for details.

What's New In Collector (April 2020) 

[RobertBorchert]

Recently I have had a few of or Telecom Field crew telling me that when they are on Wi-Fi they are having issues searching for a location in Collector.  Each of our substations have low power wi-fi available.  In some more remote locations there is no cell data so they have to use wi-fi.   My thought was they were trying to push to much data through wi-fi so I made a very lite version.

On of the crew foremen said he was having the same issue at home where his wi-fi is strong.

All the crews are on iPhone (6, 7, or 10) and should have the newest version of Collector on their phones. 

They are supposed to have VPN disabled.

Coincidentally ALL the issues have happened after the Collector update.  Would that update have been pushed to all devices automatically?

[RobertBorchert]

Consistently the most requested feature from our field crews that use Collector is the ability to have predesignated names available for the photos they are capturing.  When  crewman is 60 feet in the air installing an antenna and has to take a picture it is not always convenient to sit there and type in the name for the photo.

What would be of significant benefit (for our use at least) would be to have designated fields in Collector where the tech can press that field and it will open the camera, the picture can be snapped and automatically given that name.  If a second photo is taken it can have a number 2 put at the end.

[chyuwen]

We ran into an issue with 20.x versus 19.x. Can't say which versions exactly, but the error is at least with both 20.2.0 and 20.2.1.

A few of our Collector apps use a Feature service with geometry updates disabled, even if some of its layer do indeed contain geometry. The reason for this is that a database trigger handles the actual geometry allocation, dependant on whichever object a user clicked to get to the related geometry data (Relationship class).

In 19.x this worked fine and it dealt with the related (point) dataset as if it were a regular table, honouring the settings in the underlying feature service.

In 20.x it shows the 'update point/line' option and the submit button will not be clickable until the user has submitted a (dummy) location. The database trigger still inserts its own value though, but the user does have to take an extra step now and might also get confused, superfluously trying to pinpoint an accurate location.

The services and apps are the same, the only difference being the Collector version.

[JeffShaner]

Hey Rob,

Sorry for the late reply back. I am not on GeoNet very often unfortunately.

I don't think app updates should affect this (unless we introduced a bug). Is the issue still occurring? If so, please log it with our support team. Not sure if the "search for locations" is using feature search capabilities in the web map or if its using a geocode service. See that you mentioning VPN too so if it is an ArcGIS Server feature service that could be a factor too. Lots of variables to consider in debugging it.

Instead of going back and forth on the forum I think it would be best to have a support analyst walk through it with you so you get a timely response. Thanks for posting it.

[JeffShaner]

Thanks again for posting. We have a very similar request in our backlog and we have some upcoming development for further qualifying photo capture.

I would like to better understand exactly what you want to see out of the photo names. Can you provide more details on their need to rename the photos now? Also what conditions occur where they need to take a second photo?

Thanks!

Jeff

[JeffShaner]

Hi,

Can you please file a support request for this? Looking through our changes here: What's new—Collector for ArcGIS | Documentation we had some fixes to the way related tables work that may have inadvertently caused your workflow to fail - we may be checking for a valid geometry now where we were not checking for one in the past. 

Is there a reason why you are using a feature layer here if the geometry is not used? Would like to understand the need to do this so we can make sure its represented in our test cases.

Thanks

Jeff

[chyuwen]

Hi Jeff,

Ok, thank you. Submitted a suppport call with our distributor.

And the reason for choosing this solution is to make our single target feature geo-aware using the geometry of the 16 source features that are related to the target (1:1).

The benefit is then that we do not need to create layers or mapping services with joins in order to use symbologies or counts; the target set is now standalone and includes both geometry and field values from the related record in the original source feature.

The target set also holds the attachments (1:M). We can therefor use a single attachment table to collect photos from the field, regardless of the origin feature and whether that happened to be a point, line or area; all are converted to a point record using st_buffer_f -> st_pointonsurface_f -> st_y_f etc.