Tag : esri

5 ways to make a GUID or UUID in ArcGIS


Globally Unique Identifiers or Universally Unique Identifiers: Humanity’s attempt to make enough unique values to assign one to everything on the Earth. These funny values are the subject of many debates on when to use them and when not to, should we use a GUID or an Integer? What is faster? Can a user remember a GUID (no, no they can not)? etc.

Side note: GUIDs and UUIDs are the same thing, a GUID is just Microsoft’s implementation of a UUID!  For a quick primer on GUIDs and UUIDs I suggest the Wikipedia pages.

We may not agree on when we should use them, or how to pronounce them (GUID seems most commonly pronounced GOO-id, but I don’t say it that way…) we can all agree that they are becoming more a part of our every day lives when dealing with data. As Data Geeks we often want to shield our users from these internal values, but we need them, and generating these values is the subject of much consternation but ultimately we need not be afraid, they are just 128-bit integers and there are simple ways to generate them in most programming languages!

Enough with the discussion, lets see how to generate these things! I picked 5 common languages that I have needed to generate GUIDs in for one reason or another, feel free to skip down to the one that matters to you: ArcMap/Pro (Python), Javascript, SQL, .Net, Swift.

ArcMap/Pro (Python):

Python has this handy library called uuid, we can easily convert this to a string using: "{" + str(uuid.uuid4()).upper() + "}"

Bonus: You can use the above method in a Calculate Field Code Block and simply call the function in the Value box.  For examples on using Esri’s Calculate Field tool, check out: http://resources.arcgis.com/en/help/main/10.2/index.html#//00170000004s000000

For a complete working example, check out this fiddle: http://pythonfiddle.com/makerandomguid


Javascript can be a bit harder to generate a GUID in, however if we are using Esri’s Javascript library, then we have access to the Dojo library already, and we might as well use it! We can require['dojox/uuid/generateRandomUuid'] and from there convert to upper case and add brackets: "{"+uuid().toUpperCase()+"}" Putting it all together:

For a complete working example, check out this fiddle: https://jsfiddle.net/cmq3u7jn/


It seems that automating and building things in SQL is sometimes forgotten, but SQL provides a very powerful platform to store an analyze data, and there is always room to balance what you process in the database vs what you process on the client.  For example, when doing an insert via SQL you can easily generate the GUID that you need.  This example is for SQL Server, but Oracle is pretty close (try using sys_guid).

For a complete working example, check out this fiddle: http://sqlfiddle.com/#!6/9eecb7/1474/0


In a typically simple yet complicated fashion, .Net (c#) makes it pretty easy to generate a guid, it comes down to one line:  System.Guid.NewGuid().ToString("B").ToUpper();

For a complete working example, check out this fiddle: https://dotnetfiddle.net/TdPCoD


Last but not least, Swift.  Apple’s newest excursion into building new programming languages provides a pretty clean and neat syntax and is pretty fun to use!  Generating GUIDs in Swift is as easy as I would expect:  "{"+NSUUID().UUIDString+"}"

For a complete working example, check out this fiddle: http://swiftstub.com/15398662/?v=gm

What to do about “[Shape_STLength__]” Errors?

Oh boy….
Database error: The field is not nullable. [Shape_STLength__]. The geometry is not Z-aware.

That field shouldn’t be there, you can safely remove it. I wrote a quick script to do so here: https://gist.github.com/morehavoc/3e86f535bf204b040ee2

Now for the full story…

It took me a bit to figure this one out, I thought “Hmm, that looks like an Esri field, why would I be populating the Length from my javascript app, shouldn’t the server take care of that for me?” As it turns out I was wrong, that is not an Esri field… but in my case it was caused by Esri.

For me the field was in a feature class that I had created via a Python script using another feature class as a template; that was the issue. Esri, being so helpful, decided to convert the Shape.STLength() field into Shape_STLength__ and to top it off, make it required as well. The field Shape_STLength__ has no use, other than to cause trouble. The Shape.STLength() field is not actually a real field, it is a alias created by Esri to get the length of the geometry, handy right!

Once I figured out that was the issue, I was able to remove all of the Shape_STLength__ and Shape_STArea__ fields using a python script (making sure to shut down my services first) and all was well once again.

You can check out the python script here: https://gist.github.com/morehavoc/3e86f535bf204b040ee2


OAuth2 and ArcGIS Online

For a while now ArcGIS Online has had the ability to allow a user to login, and create a Map, publish data, etc.  And of course there were APIs that allowed us developers to get access to that data created by the users.  However, there was a big problem: The app couldn’t access the data without the user logging in, and to do that the app basically had to ask for the user’s username and password, which is a big no-no in the security world, and a level of responsibility that you probably don’t want if you were the developer.

Around March of this year Esri released an update to AGOL that for the first time provided a new way to authenticate users, OAuth 2.0.  And to make things even better, they didn’t just make up some new protocol  they used an industry standard and accepted process for authenticating users.  If you have already done OAuth 2.0 in the past, you can probably stop readying here and jump over to developers.arcgis.com and check out the walk-throughs and examples that Esri provides.  If not then here we go!

In a nut shell OAuth 2.0 is a standards based authentication system that provides reasonable protection, yet is simple and easy to implement correctly and allows developers to authenticate users without ever knowing that user’s password.

OAuth 2.0 is all about the workflow!  And it looks something like this:

  1. The Client or Application offers the user an option to login via AGOL.  This option is in the form of a link or button that directs the user to a web page hosted by AGOL.  Here the user has the option to login this providing the application access to his/her data. During the “redirect” to the AGOL login page the application identifies itself via a special ID, this allows AGOL to let the user know what application is requesting the login.
  2. Once the client logs in, AGOL sends the user back to the application, and provides that application with a special code.  This code is an agreement between the server and the application to allow the application to complete the login process, however the code itself does not allow access to any secured data.
  3. The application makes a POST request to AGOL that specifies the code, the application id and the application secret.  This secret is known only by the application and AGOL, not the user.  AGOL can then verify that these three pieces of information all match, if they do…
  4. AGOL returns a bearer token to the application.  This bearer token provides access to data via any AGOL API call that accepts a “token.”
  5. The application can now use the token from the server to request secured resources
  6. The server uses the token to validate the user and apply any permissions to requested resources, and returns either an error condition stating the user does not have access, or the data back to the application.

And authentication is complete!  The client can now use the bearer token to requested secured services, as seen in parts E and F above.  It is a little bit complicated at first, but there is plenty of code out there to help get you started.

There are variations on OAuth 2.0 that I did not cover here in this post, if you would like more information check out these links for more info: