The title is a quote from William Shakespeare’s Romeo and Juliet. The whole quote is as follows (and you may be surprised what the Bard's wisdom can tell us about naming GIS features):
“What’s in a name? that which we call a rose
By any other name would smell as sweet”
I am not a poet, but to me that means that we could call a rose anything (i.e. a fishing pole, a truck) and it would still smell good. So…what difference does it make what we call it?
If we forget the fact that the man may not have existed, it is probably good that Billy wasn’t a Utility Engineer or GIS Consultant. The naming of utility features (i.e. poles, transformers) is extremely important. Other than a feature's spatial location, the name is a primary method of distinguishing features apart and potential linking to other databases. This makes naming GIS features a huge opportunity for database users to communicate.
Having deployed GIS for numerous municipalities and utilities, the topics causing the most passionate disagreement are the coloring of features and their naming methodology. This post is not about feature symbology, but about naming GIS features.
Often utility poles are named based upon its coordinates. I took a photograph of a pole near my house (Figure 1).
Other than seeing that I drag my feet (footprints in the snow), we see “56045-35034” on the pole. This is obviously not latitude/longitude. My first guess was PA State Plane South NAD83 projection system coordinates. Let’s fire up ArcGIS Pro, and see if this is correct projection system.
When creating a new project and map in Pro, the coordinate system defaults to WGS 1984 Web Mercator (auxiliary sphere). We need to change the projection to PA State Plane South NAD83 as follows:
At this point, we want to test if the assumption of our projection system is correct. The cursor is placed approximately where the pole is located. Looking at the coordinates (Figure 4), there is something wrong.
First thing we must do is drop the first “2” in the x-coordinate. With the guessed projection system, we are left with (52888,35039) (note that we are dropping the remaining numbers). The Y-coordinate looks fairly close, but X-coordinate isn’t close enough for a potential margin of error.
In a previous life, I did a great deal of GIS work for small boroughs and townships in the area. I remembered that several used NAD 1927. After we change the projection system to NAD 1927 and repeated the verification procedure (Figure 5), our coordinates look much closer (56029,35035).
Once we have figured out the correct projection system, we are quickly going to create a pole feature class in the default file geodatabase for the project (Figure 6).
Once our new feature class is created and added to the map’s Contents, we can create a new pole with the exact coordinates as specified. It should be noted that we need to add a “2” to the front of the X-coordinate and a “0” at the end of both (Figure 7).
Once the coordinates are entered, the pole is placed (Figure 8).
It should be noted that the pole came in on the wrong side of the road. The purpose of the pole name is not to convey the accurate coordinates, but to have a general idea where it is located just reading the name.
We’ve established that naming GIS features is essential to differentiate features from each other. In the example of the light pole (demonstrated above), we see a name may be utilized to determine where the pole is spatially. However, the reliability and therefore trust in a name depends on the data being consistent. If a light pole down the street uses a different coordinate system, the coordinates in the name would lead us to a completely different location. Names can become meaningless or even misleading when there isn’t any consistency in the naming conventions. ArcFMTM AutoUpdaters offer a possible solution to this problem.
Automating data tasks are a surefire method to ensure consistency in your data. AutoUpdaters do just that. Attribute AutoUpdaters can be used to update field data on events specified by the user. For example, SSP recently implemented Attribute AutoUpdaters to name features as soon as they were digitized/placed. Automating naming when a feature is created guarantees unique names for every feature. This allows us to safely make assumptions about the feature based on its name. Let’s take a look at a specific example below:
A client recently requested SSP to implement custom AutoUpdaters to automatically ID features in their water network. The requested naming format for point features was the ID of the grid the features were placed in followed by a sequential number for each feature class. This naming convention gives us two important pieces of information right away: where the feature is spatially (grid ID) and how many of those features are in that specific grid. As shown in Figure 9, we can see two fittings labeled with their automatically generated names.
For naming GIS features that are lines, a different naming convention was utilized. The name for a main, for example, would be the names of the features connected to each of its endpoints along with abbreviations indicating the type of connections (pictured to the right). In the example shown in Figure 10, we see a main connected from an elbow fitting to a cap fitting we placed in the first picture. In this case, we can tell the types of connections present and which features each main feature is connected to just from the name.
After seeing how the careful naming of features can relay us vital information, it's easy to see why so many clients have chosen to automate this process already. When names contain details about a feature, the users don't need to waste time searching for important data. If they're also leveraging AutoUpdaters, they can be sure this information is always correct.
“Good night, good night! Parting is such sweet sorrow,”