Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Follow up question: Is it best to create and maintain the unique id in the DBMS (SQL Server) or in the GIS software (ArcGIS)? –  cwb Oct 26 '10 at 15:11
1  
Can you provide more details on your project. What do teh features represent? Do they already have a natural unique ID. What are you planning to use this number for (ie track feature, link to other datat sources, etc) These all factor in on the best way to handle ID creation. –  Chris M Oct 26 '10 at 16:42
    
The point features represent catch basins. There is no natural unique ID. DPW staff want to link to a table of information about the catch basin cleaning program. I don't have more details, but surmise that staff in the field will be making notes on when cleaning took place, the condition of the catch basin, etc. –  cwb Oct 26 '10 at 17:10
    
for basins you have ottobasins number. My guess is that it is unique. look for ottobacia (ottobasins) to get a grip of the methodology. I only found results in portuguese. –  George Nov 25 '11 at 20:12
add comment

7 Answers

up vote 16 down vote accepted

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.

/Nicklas

share|improve this answer
6  
+1 Never ever ever ever use ids that mean something or use business data in them. Someone at my work just got burnt because they used road names in the ID and lo and behold the road name had to be changed, now the ID is wrong. –  Nathan W Oct 25 '10 at 21:53
add comment

"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!"

http://eaglemap.com/blog/bid/45555/How-to-Generate-GUIDs-in-ArcMap

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.