The MassGIS parcel standard (http://www.mass.gov/mgis/ParstndrdVer1_5_1.pdf) utilizes a concatenation of the whole number portion of x- and y-coordinates to create a unique id (LOC_ID) for features. I'm considering doing the same for a point feature class. I like the consistent methodology, but perhaps I'm overlooking something. Is there a standard or best practice for creating unique ids for point features?
If you use that id for something like as a foreign key in relation to another table your whole database will get in big trouble if you have to move a point for some reason. Probably you then will have to keep the id even if it not describes the xy-coordinates any more.
As a unique key is often the best to have something not telling anything about the data, because most data might change.
Adding on from Nicklas answer and my comment.
I would say the most used convention and most recommended is just to use a auto-incrementing ID, eg start at 1 and just keep going. No logic and simple.
If you have a distributed system, or don't like auto-incrementing numbers, you could use a GUID. Most databases will handle creating this kind of ID for you. However they are a pain for a user to enter manually, for searching etc, so just keep that in mind.
The other option is to use some kind of hash of the data but I would not recommend this. It would mean that would you need to write an algorithm to do this for you, you can't always ensure uniqueness, they also tend to be a pain to enter for searching.
These are just my opinions, but from personal experience, trust me, never use business data in IDs.
Follow up question: Is it best to create and maintain the unique id in the DBMS (SQL Server) or in the GIS software (ArcGIS)?
I'd strongly suggest checking for uniqueness inside the DBMS. That's one of the many strengths of DBMSs. It also allows you to access your data with different GIS software that probably wouldn't be aware of the unique constraints.
Our identification scheme was not chosen by me but is as follows: 2,3,4 character code which is the class of asset and a 6-digit sequential number (you would choose whatever digit count works for you). A stored procedure creates these IDs and relies on a couple of non-geodatabase tables in the same SQL Server database.
I do keep a separate, sequential auto-increment ID. I also keep a 13 character geohash field (for point features), but I would never use that as a key. The field is auto-populated (by a custom editor extension) whenever the feature is moved.
If your GIS data is to be used with any sort of asset management system, you'll want your IDs to be globally unique within your geodatabase (and perhaps unique within all geodatabases within your organization). This will also make it a little easier to do geodatabase refactoring in the future.
Perrsonally I've used CRC calculations in the past to create similar values. Not too difficult to create and librarys/algorithms are available online.
The advantage there is that you can do features greater than points, whereas a concatenation would really have to be point features only (unless you want a really massive key).
And I think it's unlikely an end-user would be searching by this ID anyway, so I don't see that as a problem.
Having said that, I don't see many explicit benefits of assigning ID like that. I might use the method for change detection (because it's way mnore efficient to compare two CRC values than two sets of geometry) but even then - why use it as the primary ID?
"GUIDs can, of course, be generated using VB Script. But given the gradual deemphasis of VB Script by ESRI, we’ll perform GUID generation in ArcMap using the ninth wonder of the world, Python. For those of you not already in the know, Python is God’s gift to inveterate GIS hackers. My advice: Learn it! Live it! Love it!"
ESRI's Arc Hydro Tools come with a toolbar that also installs a unique ID manager which runs in the background. The toolbar lets you assign unique IDs per feature class or per geodatabase. The ID manager per default only handles unique ID attributes called e.g. HydroID, which is part of the Arc Hydro data model. But it can be set up to handle other attributes, too. The tools come with a lot of documentation, so configuring the ID manager to your needs shouldn't be a problem.
The unique ID is, to my knowledge, always an integer. After assigning unique IDs once the manager takes care of assigning new unique IDs for every newly created feature whichs fits the configuration.
The unique ID manager could be useful for database backends which (AFAIK) don't support auto-incrementing numbers like the personal geodatabase.