Latest Contributions by PeterKnoop

Shannon, to go back to the original question, what is possible now, during the beta, for measuring usage? Using the ArcGIS API for Python, with search() we can find out who has a Notebook and we can count the number of Notebook items, and with usage() we can find out the number of times a notebook has been opened.  Is there anything else available at this point? Is there perhaps more information available via the REST API? Thanks! -peter ... View more

Hi Shannon, Our main goal for tracking usage is to identify who is using it and how they are using it, both to offer support and guidance, where needed, as well as to understand the benefits of Notebooks in ArcGIS Online for our users.  It is also important to understand usage in terms of how Notebook will need to be treated and justified as a potential additional cost to using the Esri platform in our organization.  For our purposes it is key that usage information be provided: per user -- We need to join the usage information to data from other enterprise systems and directories to form a full picture, such as a user's role (faculty, staff, student), enrollment (what classes are they currently taking?), degree program (what's their major?), and so on... per offering -- The three flavors Notebooks currently come in, Standard, Advanced, Advanced with GPU, (and their versions) to help ensure some of the comparisons we make will be done apples to apples. per time -- Users association over time can change. Being able to extract time-range snapshots of usage information will help us understand use cases tied to specific periods of time (e.g., a specific course a student might have taken, participants in a Data Science workshop series.) The kind of usage information we would like to have on those basis are: time of use -- How long was a user using a particular Notebook type over a particular period of time. credits -- Same as for time. I'm sure there will be a costing structure that relates time of use and credits, however, since that costing structure will likely evolve over time, it is important to track the two separately, so that we have a route to make apples to apples comparisons. Plus, there will presumably be credits used when running analysis, accessing premium data, etc., in addition to the credits consumed running the Notebooks themselves. Related to our thinking about what we would like see for usage tracking is the expectation that the same ArcGIS Online credit allocation will serve as a limit on Notebook usage, as it does for other aspects of ArcGIS Online. We have too many users, with too much variation in needs, to micro manage individual users' credit usage. We count on the credit allocation to serve as protection for users from mistakes like endless loops, and to guide them to seek advice where there might be a better, more economical alternative approaches to achieving their goals. Hope that helps! -peter ... View more

Perhaps you would consider adding StoryMaps to the health dashboard? It is nice to have one place to go when things aren't working right, to see if it is a large-scale issue or "just me".  Thanks! ... View more

Hi Mark, As long as each user using the shared machine is logging into the machine with their own Windows account, then there should not be any problem. The ALLUSERS=1 parameter in the installer options shared above, installs ArcGIS Pro in a single location, and makes it available to all users on that machine. When each user runs ArcGIS Pro, their user-specific settings for Pro -- such as their cached authorization info -- is stored in that user's Windows profile, so that only that user's Windows account has access to it.  If the users of your shared machine are all logging in using the same Windows account, then it would be a problem. They would be accessing the same Windows profile, so whomever last logged into to Pro on that machine would have their Pro authorization cached in that Windows accounts' profile. -peter ... View more

Hi Mark, Not in an unexpected way. Pro caches the info from a successful login, so a user doesn’t have to login every time they start Pro. Once the authorization times out, however, they will have to login again. That auth info is cached in the user’s profile, so if you’re not deleting it from the profile — or deleting that user’s profile itself —after the user logs out of the shared machine, then it will still be there the next time they login to use that machine.  ... View more

Another 3D Analyst tool you might consider for tasks like this is Minimum Bounding Volume. I find Minimum Bounding Volume to be very convenient for converting points to volumes in the context of archaeological excavations. I use it to turn the points that define the often uneven boundaries of levels (or contexts, or stratagraphic units, or whatever your preferred terminology is...) into closed multipatch features (i.e., 3D volume representations.) I use ArcGIS Pro, though if you are a Desktop user, it also has a version of this tool, Minimum Bounding Volume - Desktop. As you've already done, the first step is loading the data from your Excel spreadsheet into a point feature class. You did not provide the coordinate system for your data; however, since it looks like an arbitrary example with units of meters, picking a coordinate system, like UTM, should do for this example. I arbitrarily choose to work with your data in my local UTM Zone. Otherwise, by default, ArcGIS may assume a coordinate system that treats your X and Y values as degrees longitude and latitude, and your Z value as meters. As you can probably imagine, it would then take a lot of vertical exaggeration for a few centimeters of elevation difference to show up in a 3D view of your Level, when it is being treated as one-degree in areal size. Not to mention that you might get some very unexpected volume estimates as well!) (I notice that your data seems to go up in elevation from your Start of the Level to the End of the Level, for point pairs with different elevations, rather than down, as I would expect for excavation. Your data will still work, however, it places your Start points below your End points, when you visualize it.) The second step is to generate multipatch features from each Levels' points. In your sample data you only have a single Level. Assuming your full data set contains more than one Level, then you would want to use the Level column to indicate which points should be grouped together to form an individual Level's volume.  Because you have duplicate points for the same Level, you will see a warning message about such points being ignored in creating the multipatch feature. (When you have more than one Level in your data, then you should have points with duplicate coordinates, however, they will be associated with different Levels, so that won't interfere with each other; one Level's ending point is another's starting point, until you hit the bottom.) when running the tool, checking the box for "Add geometry..." will add an attribute, MBV_Volume, which will contain the volume of your Level. This is not an auto-calculating attribute, however, so if you edit your multipatch feature, then you will want to re-calculate this field (e.g., Update Feature Z.) Why would you edit your multipatch features? If you surveyed your "duplicate" points multiple times -- maybe it took more than a day to excavate a level, then the inaccuracies of the survey method will likely produce slightly different coordinates each time. So you might edit the multi-patch feature's vertices to average the difference, or to ensure one Level's vertices snap to an adjacent Level's.  Also, because of those duplicate points, you will get an area that may not agree with how you are thinking of the area of this feature. Keep in mind that the whole "square" area is defined by the points you provided, however, more than half of the area the tool identified also has zero-thickness, and is, therefore, not part of the actual multipatch feature. If you visualize the resulting points and multipatch features in a Local Scene in Pro, then you can see the 3D shape of your Level. Something like this:   In practice, levels/contexts/stratagraphic units can end up with some fairly convoluted shapes, so I would strongly recommend taking the time to visualize and explore the resulting multipatch features, before trusting their volumes (or areas). The "Concave Hull" method usually does the right thing, however, occasionally you may find that you need to manually drop some points that are duplicates or superfluous, which are confusing the algorithm relative to your expectations for the shape of the volume. Hope that helps! ... View more

Below is an example of the silent install options we use in many of our computer labs. Since you are using Named User licensing, you can point to your organization's ArcGIS Online instance, rather than the generic www.arcgis.com, to potentially save users steps logging in. This is especially handy if you have configured your instance to use Enterprise Logins for users, and configured Enterprise logins as your only login option. Then your users are sent straight to your single-sign-on dialog when they start-up Pro, rather than having to fill out Esri's generic login dialog and find their way to your organization. msiexec.exe /i <path to installer>\ArcGISPro.msi \ ALLUSERS=1 \ SOFTWARE_CLASS=Professional \ AUTHORIZATION_TYPE=NAMED_USER \ License_URL="https://<your org>.maps.arcgis.com" \ Portal_List="https://<your org>.maps.arcgis.com" \ CHECKFORUPDATESATSTARTUP=0 \ LOCK_AUTH_SETTINGS=TRUE One important note: make sure you specify the parameters in the order presented above! (The installer for ArcGIS for 2.4.2, and maybe any 2.4.x, introduced a bug whereby it does not properly parse the command line arguments, so re-arranging them can cause unexpected failures. For example, if you construct your command line in the order in which the parameters are explained in the documentation, then the installer will report success, however, the settings you specified will not be applied correctly, and you will get errors or unexpected behaviors when you try to login to Pro.) ... View more

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