Latest Contributions by MichaelDavis3

Hi - just want to confirm what you are saying still applies. If we add additional entries to a geodatabase domain those values are not updated in existing offline geodatabases when we sync.  This is what is currently happening in our apps, and to be honest is not ideal, especially when a minor domain update could require re-downloading an entire database. Are there any plans to include domain changes in the sync process in the future?  As it stands now we are having to replace many of our domains with geodatabase tables for things like crew names, or animal/plant lists that might be updated throughout a project. ... View more

FYI - this seems to apply to authentication against AGOL for app licensing purposes as well. ... View more

Not really - and trying to "sync" the database from the device can be a bit of a pain, especially if there are edits to existing data and you need to figure out what changed and what didn't. There is a shortcut you can take that might help though.  When you sync, ArcServer saves a copy of the data that the device transmits to a folder like this: \\servername\ArcGISServer\directories\arcgissystem\arcgisuploads\services\servicename\ In there you will find a folder containing a sqlite geodatabase with the diff data (adds/deletes/edits) for your feature service.  If you grab these files and convert them to a file geodatabase you can take care of adding/replacing/deleting features in an ArcMap session. ... View more

This is fantastic - thanks Nick! ... View more

Yep, basemaps can be downloaded as a part of the data check-out process in Collector.  You are given an opportunity to define a work area and the app checks out the data for that area as well as downloading the basemap. We avoid that step for the most part however.  We generally make our own tile caches (tpk files) in ArcMap using project data or a public web service and then side-load them onto the mobile devices (through iTunes for iOS).  We primarily do this because we typically deal with large survey areas and hefty tile cache sizes (2-17GB in size) and that just wouldn't be practical to do on a device over WiFi.  Also it doesn't consume AGOL credits. Collector recognizes any tile cache files you side load and makes them available for use in the maps you take offline. ... View more

This should be very possible.  We use Collector as well as our own custom apps and have found that full size images will quickly make checkout databases too large to download. Our solution in custom apps has been to re-size the attached photo to 1024x1024 max size and store the full size original photo in a folder in the app's document directory.  I'd think a similar workflow could be used for Collector. ... View more

You might consider moving to an offline collection workflow.  This way you can submit all the collected data at once at the end of the day, preferably on WiFi. We pretty much exclusively use offline collection - even in areas with decent LTE coverage. ... View more

Are you using offline data collection or collecting data directly to the feature service? Is the data hosted in AGOL or in ArcGIS Server? ... View more

I get what your are saying.  As far as expecting more from Esri, I don't think you become the 4th largest privately held software company in the world by giving things away 🙂 Serious question about the costs of Portal though... I thought the Portal license was included with ArcGIS for Server Standard or Advanced at no additional cost, is this not correct?  It sounds like they give you a fair number of named users with that as well, although I don't know the specifics of how many. ... View more

I think you are correct that AGOL is at the core, or at least a component of, most of the push-button development tools Esri is releasing.  That said I'm pretty sure you can substitute an on-premise Portal instance for AGOL in most cases.  Now that Portal is included with ArcGIS Server Standard and Advanced this is a very realistic alternative if you still want to take advantage of the push-button app-builders and other tools.  For us the issue hasn't so much been the requirement to use AGOL or Portal in the development process, but the named-user requirement that comes along with it.  We keep running into circumstances where named users just don't make any sense (multi-person field crews doing offline collection, service accounts for various automated processes, citizen-science/crowd sourced data collection, etc...) But this seems to be the way Esri has chosen to license (and generate revenue from) these capabilities...   ... View more

The underlying Javascript API has no AGOL requirement.  I guess Esri is recovering the investment to build the fancy app-builder tools through AGOL subscriptions.  For mobile you can build and deploy runtime apps without using AGOL.  You could authenticate against an in-house instance of Portal, or you can purchase runtime license codes in 25 packs. ... View more

We did a similar exercise a while back... We ended up settling on iPads for now for the following reasons: Support.  An iPad that breaks can be exchanged at any Apple Store... usually in the same day.  We buy Apple Care + with our iPads which means we can exchange them for any reason (even if it's totally our fault) for $50.  The support varies widely for Android tablets, but usually requires mailing the device in for service. Memory.  The iPads have internal memory up to 128GB.  This was important for us because some of our offline tile caches are> 17GB.  Android tablets often rely on SD cards for storage, and many of them can't support file sizes larger than 4GB. Constancy.  We use Collector, but also develop our own in-house apps.  Any iPad that runs the current version of iOS (iPad 2 all the way up to the latest iPad Air 2) will work just fine with any app we throw at it.  This is very complicated with Android; with different tablets running different versions of the operating system.  Some might be upgrade-able to the latest OS, but many receive no updates after purchase. Ease of management.  Like it or not, iOS is a pretty locked down system.  From our perspective (managing large numbers of tablets) this is a good thing.  We don't restrict what people can do with the iPads we send out in the field, they are free to install apps, change settings, whatever they want... but when the device comes back to us we can reset everything to factory fresh in a couple taps.  We weren't interested in buying a 3rd party management service just for data collectors and with iOS we really didn't need to. Enterprise Apps.  This might not apply in your case, but for us Apple's Enterprise App program is fantastic.  We can develop apps and deploy them to our devices using an internal app store without having to go through the Apple App store approval process.  This lets us quickly develop and push out updates to apps as needed on our projects. These might not all apply in your case, and the fact is this is all changing really quickly.  We are starting to see more Android tablets with internal memory instead of SD card expansion, and Google is doing what it can to address the OS update issues.  For now, for us, iPads in Lifeproof cases are where it's at for field work. As far as the required memory - this will depend on what and how you are collecting.  We do offline collection and tend to have lots of attached photos, so we are regularly dealing with large TPK files and large .geodatabase files on the devices.  It isn't uncommon to have a TPK file in the 3-6GB range, and we frequently have multiple versions for a project (topo, imagery, streetmap, etc...).  Photo attachments are an issue as well, with full size pictures from a tablet camera coming in at 5-8MB each.  Multiply that times 20-50 pictures per day on some of our projects and the database can get really large fast. ... View more

We've run into heat issues with iPads using Collector and Runtime apps as well. Our experience is primarily anecdotal, but the white iPads/cases seems to be a bit more resilient to heat.  We keep our field units in Lifeproof cases and I'm sure those aren't helping with heat dissipation. In some cases where we are working areas with high temps and high humidity we've had better luck deploying iPad Mini's, primarily because we can instruct field crews to keep them in a field vest pocket when not in use.  It is really important to keep the devices out of direct sun for an extended period, so any sort of pocket or shade will help. Battery live will tank whenever you are using the GPS.  We include a battery booster in the field kit we deploy with our iPads and try to optimize GPS use wherever possible.  This can be difficult using Collector, but if you are using the runtime you can design your app to be conservative with the GPS. ... View more

Yep - there should be 3 files (.geodatabse, .geodatabase-wal, .geodatabase-shm).  These are the "runtime geodatabase".  There is a tool in ArcCatalog 10.3 called Copy Runtime Geodatabase to File Geodatabase that will convert it. Are you running SQL Server?  If so you might see my post here for some additional info on what might be causing your error. Are SQL Server, ArcGIS Server, Runtime/Collector really production ready?!? ... View more

The easiest thing to do is use the Copy Runtime Geodatabase to File Geodatabase tool in ArcToolbox 10.3.  I've found I can only make this work if I have the source files on the C: drive. The .geodatabse is a SQLite database with Esri's special sauce, so you can rename the files to xxx.sqlite, xxx.sqlite-wal, xxx.sqlite-shm and open them in any SQLite editior if you want to look at the guts. ... View more