Latest Contributions by PeterKnoop

A single one. ... View more

Not sure if all this goofiness is still present in more recent versions API. The reason for it in this specific case was that the API was treating the values supplied in this way as strings, rather than as numbers. While numerically 000001 equals 1, "000001" and "1" are not equal. It also wanted values in microseconds, rather than milliseconds. Hence the additional factor of 1000 in the conversion. -peter ... View more

If you haven't already, I would recommend taking a look through the generic AWS guide, Changing the Instance Type. Sounds like you are interested in only adding more memory to your setup, and  do not need to change anything else about it. In other words, you plan to stick with the same instance family, but want to use a different instance type within the family, one with more memory (e.g., maybe you want to migrate from an m4.xlarge with 16GB to an m4.2xlarge with 32GB.) I would strongly recommend that you do make a snapshot first, in case something goes wrong along the way, and you need to revert to your existing setup. The basic process for "adding memory" to an instance -- assuming you are using a typical EBS-backed instance -- is to stop your instance, change its instance type to a compatible one that has more memory, and then start the instance again.  The steps are outlined in detail in the section of the AWS document titled, Resizing an Amazon EBS–backed Instance.  Hope that helps, -peter ... View more

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