Latest Contributions by PeterKnoop

I just verified that it still works correctly with our ArcGIS Online organization. Accounts created are enterprise accounts, not built-in, arcgis accounts. We have been relying on this method for awhile now, so I suspect the person with which you communicated at Esri may be mis-informed. For instance, our ArcGIS Online instance is configured to automatically join authorized enterprise users to our organization, so a user is able to do whatever they need to the first time they login. Sometimes, however, circumstances arise where we need to add an enterprise user to a specific group, before they have logged in that first time. As the user has not logged in before, their enterprise account doesn't yet exist in the system, so we cannot add them to the group. Therefore, we use we use the above method to create enterprise accounts, so that we can add users to the groups, even if they haven't logged in themselves previously. As I mentioned, if you don't supply all the parameters it is expecting, then you get unexpected errors. In same cases this means an account is created, but it is a built-in account, rather than an enterprise account.  Give it a try. ... View more

I like the idea of substituting a Story Map for the traditionally paper field guide for a field trip! Now I'm wondering if there is an easy way to take a Story Map "offline", to deal with field trips where the points of interest are in locations with no cellular data coverage? Is the a simple way to host a Story Map on one's mobile device? We've been using offline maps in Collector and Explorer to hold our field guide content, which we split up and attach as PDFs, image files, etc. to relevant locations on the map. We also have a master PDF for overview materials, which can be downloaded and read offline in the student's favorite PDF app. A Story Map for that purpose instead, still with links that would open the Collector/Explorer project on the same device to correct location would be great! ... View more

I found the documentation and videos in the QuickCapture github repo very helpful for getting started. (You might miss the documentation links on first glance... there is a table of contents in the box on the right with, "Home, 1. Introduction, 2. Basic configuration, ..." ... View more

As noted ArcGIS QuickCapture can be configured to have just a single button. That might be the simplest way to go here. The iPad itself is probably too big to have easily accessible under the conditions you describe, however, you could use QuickCapture in conjunction with an iPhone (or other small mobile device) strapped to the user's forearm. Then as you're doing your task, you can easily reach and click on the button to record your current location. (Note that the device's battery can drain fast with this approach, as you need to leave the device on, so that the button is readily available to press. We carry an extra battery in this case, and charge the device during breaks to make it through the whole day; and we are using Collector or Survey123 directly, rather than QuickCapture.) If you just want a "button" -- AND, you can access WiFi where you are, rather than Bluetooth -- then another approach to consider is using an Amazon IoT Button. (Maybe you have a cellular iPad that can serve as a hotspot? Maybe you are already carrying a separate WiFi hotspot to provide connectivity for your iPad?)  When pressed, the button's Lamda function runs, utilizing the ArcGIS API for Python (you could also leverage the ArcGIS REST API) to record information in ArcGIS. Meanwhile, your iPad is running Collector with a Location Tracking layer. (Note that I do not believe Location Tracking layers are supported in the new Collector yet, so we have had to stick with Collector Classic for this specific purpose for now; you can run both side by side on your device.) So when the button is pressed, the code that is run in the cloud grabs the most recent record in the location tracking layer, and appends it to another feature. Your code should also check the the button press timestamp and the most-recent tracking point are from about the same point in time, as the GPS might have lost signal and the location tracking layer isn't being updated at the moment. You can leverage the notification capabilities of the AWS button service to text you that your location wasn't recorded properly; though there is a bit of a delay with notifications, so you may find yourself having to walk back to the previous location to record it again. (One of our main uses for this has been for "I'm here now!" purposes over the course of a day. Think of it as a tracking layer filtered to record your location only when you manually choose to have it do so, and you don't want to fuss with having to pull out your phone and do something directly in Collector. That sounds pretty similar to what you're looking to do? Recoding the button press timestamps makes it easy to join/filter with all sorts of data after the fact too.) The IoT button works best if your need for location accuracy isn't too high. The iPad GPS, as you're already aware, can be off by quite a bit, especially under canopy. The delay of recording the button press and the temporal resolution of the tracking layer can add to the error too, especially if you move a lot during the delay it takes to process. Depending on your use case, however, that error source can be greatly reduced if you click the button at the start, rather than the end, of the task, so that you are "in the area" while things are being recorded, rather than walking or driving away to somewhere else. Hope that helps! ... View more

Hi Kelly, I would like to echo Pat's comments. In particular, the lack of support for automatically assigning a default set of entitlements to a new enterprise login. In other words, the first time an enterprise user logs into a component of the ArcGIS platform, they would get immediate access to a predefined combination of ArcGIS Online, ArcGIS Pro, GeoPlanner, Business Analyst, Insights, etc. They would get the access when they need it, rather than placing a barrier in their way, and generating an extra, per-user administrative burden on the institution. (This is for enterprise logins, not arcgis logins.) Addressing that need (as it sounds like you might in the next release?) will also eliminate a number of related issues; issues which typically only occur as a result of people struggling to deal with that simple piece of missing functionality. Whether an institution implements scripting or manual workarounds for that missing piece, it generates a number of additional failure points and/or extra work. Not what one expects from software sold as an enterprise-class, scalable, Software as a Service (SaaS) system. The introduction of User Types perhaps is a step toward solving the problem, but it doesn't at the moment. I suspect the introduction of user types is setting up some longer-term changes? Otherwise, like Pat, I find it to be confusing, and I am failing to the see the benefit at the moment... If you do not plan to implement a way to specify a default set of entitlements for enterprise logins in the next release, then perhaps the user type capability can be leveraged instead? Since you can specify a default user type for a new enterprise login, will you be adding the ability for administrators to define a custom user typer? That would lead to a relatively simple, yet powerful, workflow for Administrators: they would create a custom user type, set the desired combination of entitlements for that user type (from all available in the instance, not just Pro), and then set that user type as the default for new enterprise logins. Then, when a new enterprise login hits the system the first time -- and automated join is configured -- they can start working right away, without being stuck waiting on an automated script or manual intervention by an admin. On the enterprise login configuration page you can specify that a new user can join automatically, and default values for Role, Group(s), credit quota, Esri Access, etc., but not a default set of entitlements. To get around this oversight, some institutions, including mine, periodically run an automated Python script to provide the missing license auto-provisioning capability. Requiring an institution to have to perform this task using a script is, I believe, the largest, single barrier to broader adoption of the ArcGIS platform in the educational realm. (I suspect it is, or will be soon, a barrier for any large customer, education sector or otherwise, that needs to automate things, after they enable enterprise logins. Having to know scripting to have a scalable system, that provides a basic level of functionality, is not a typical expectation for SaaS. Furthermore, many people tasked with ArcGIS Online Administration, in education or otherwise, are not possessed of the level of scripting expertise required. You cannot have thousands of users dependent on a script hacked together from examples in the ArcGIS API for Python. Such a script needs to be to robust, secure, scalable, provide logging, handle exceptions, etc., if it is to be successful and reliable in an enterprise environment. Additionally, if scripting isn't an option for an institution, then the manual management requirements scale linearly with the number of users. The more users, the more administrative workload; again, not a typical expectation for a SaaS system. If the issue with automated licensing/entitlements were addressed, then the requirement for scripting expertise and/or cumbersome, manual management would be eliminated, or significantly reduced. This change would enable the many institutions with ArcGIS administrators, who don't have the time for manual tasks, nor the scripting expertise, to empower all their members with access to ArcGIS. There will always be the occasional exception of course. This functionality, however, is about setting the majority of the institutions implementing ArcGIS up for success, rather than failure, as they scale-up access across their organizations. Enabling enterprise logins, or Single-Sign-On, is also a barrier for some institutions, however, it is one with a clear solution, once the right people at an institution are involved in the conversation. Simply enabling enterprise logins, however, without also being able to auto-provision entitlements, still leaves one with the significant barrier of manual effort or scripting to support broad adoption. Currently many institutions are trapped by the "more users, more time commitment" issue. That approach does not scale. Rather, it sets up an institution for failure; or, just as bad, forces them to implement a digital divide; creating an environment of haves and have-nots, where, even though they have an institution-wide license, some users get access while others are denied. Thanks for reaching out here for input on this topic. Hope you find the above helpful as you plan the next release! Cheers, -peter ... View more

It is indeed a case of practicality. When someone took their Named User license offline, it often resulted in unexpected complications because they didn't remember to check it back in from say their laptop, and then wanted to use Pro on their office computer or a classroom computer, while their laptop with the license was elsewhere.  Or, as in Peter Wiringa's example above, which has happened to our users numerous times as well, they lose access to their license altogether, which means a support request to Esri. It then typically takes several days to get things sorted, meanwhile that use has no access. Instead, we recommend giving access to everyone to a Single-Use license instead, then they can choose to use it if they think they might be using Pro offline. Then they don't have to remember to check something back in; however, they do have to remember to update their Single-Use license once a year when the site license renews. ... View more

Option #2 is certainly a starting point, however, as Geri Miller points out in her last bullet in that section, the approach does not scale well in the long-run. As the number of students and courses using ArcGIS grows, you eventually will be challenged to keep up in an appropriately timely fashion with all the course requests, students dropping and adding courses, etc. Even simple things start to add up when you have to do them over and over... Not to mention all the requests for ArcGIS software and licenses that fall outside of courses! And, as you point out, option #2 unfortunately has the side-effect of erecting a barrier to people easily adopting GIS technology on campus. It creates a (hopefully!) undesired digital divide.  (Are there institutions out there who still limit the use of Excel to just Business students and courses, or Word to English classes... 😉 Last semester, more than half of the University of Michigan's user-base came from fields outside of the traditional realms of desktop GIS. While most of those are users of Web GIS (e.g., ArcGIS , StoryMaps, GeoPlanner, Collector, Survey123), there are some who end up moving on to Pro, and even some who are jumping straight in with Pro; both for coursework and research. Option #1 makes it easy for them get started with the software on their own timeline, as they already know how to use our institutional file system.  Option #2 works, however, the sooner you can move on to Option #1, the easier you can make it for members of your institution to leverage ArcGIS, and the less time you'll have to spend on  trivial system administration tasks. ... View more

We've moved on to use the ArcGIS API for Python for tasks like this (see arcgis.gis.UserManager.create), which wraps the REST API call for you. If I remember correctly, however, from the days before the Python API, the REST API call is Create User.  The following works with ArcGIS Online and Shibboleth, so the username format might need some minor tweaking to work with one of the other SAML providers. https://<url_key_for_org>.maps.arcgis.com/gis/portaladmin/security/users/createUser username = 'knooptp_<url_key_for_org>', password = 'None', firstname = 'Peter', lastname = 'Knoop', email = 'knooptp@devumich.edu', role = 'org_publisher', provider = 'enterprise',  idp_username = 'knooptp', level = '2' I believe you have to have password set to None, and that you cannot simply leave the parameter off, as some of the documentation suggests. ... View more

It is indeed a limitation of the shapefile format. A "date" type field in a shapefile or a coverage can only store date values, not date and time values. One place you'll find this information is in the ArcMap documentation on the Fundamentals of date fields, "A coverage or shapefile stores dates in a date field with this format: yyyy-mm-dd. A geodatabase formats the date as datetime yyyy-mm-dd hh:mm:ss AM or PM." If you leave your data in the geodatabase format in which it comes from Collector, rather than converting it to a shapefile, then your field won't be truncated to date-only, and no workaround is required.  If you have some other need that is forcing you to use the shapefile format, then before you export from the geodatabase, you can split your "date" field into two separate fields, one for the data value and one for the time value. There a lots of ways to do that, one being to use the Field Calculator and its VB Script DatePart() function. For details, plesae see this helpful Esri Technical Article, How To: Extract a portion of the Date field. ... View more

I've added an ArcGIS Idea for this: https://community.esri.com/ideas/14565  ... View more