Help with Street Lights in LGIM

Question

I have a shape file with Street Lights data that was collected by an outside contractor. I am now putting it in the LGIM. So, I see a Street Light 
table i the LGIM, but no feature class. Our workers will be actively using this data to map out work orders for bulb and fixture replacement.
Is there a reason to have a street light table but not a feature? 
Thanks

AllisonMuise1 · Answer

Hi Kathleen,

The Local Government Information Model contains several references to streetlights; hopefully I can help clear up this confusion for you by explaining the differences:

- Streetlight feature class: Found in the FacilitiesStreets feature dataset, this point feature class holds your streetlight features and their attributes

- Streetlight_ATTACH table: This is the table of attachments of features in the Streetlight feature class. These attachments could be photos or other documents related to each streetlight feature

- StreetlightOutage raster: This raster is a heatmap of outage reports for use as a summary of what's going on during an incident, or for presenting to an executive to give a status of whats going on.

If you haven't already, I recommend taking a look at our Street Light Inventory solution that makes use of this streetlight feature class and attachment table. The heatmap is used in the Executive Dashboard application.

RichardFairhurst · Answer

If your Street Light table contains Longitude and Latitude in the WGS 1984 projection (used by Google and most GPS devices) or X and Y coordinates in the spatial reference you normally use locally, then the table is a feature class as soon as you use the Make XY Event Layer tool or right click the table and set up its XY Event layer option.  If it contains an ID that relates it to a pole position in a separate feature class, then you can calculate the X and Y coordinates of the poles into the pole feature class and join the pole feature class to the table and fill in the X and Y coordinates into the table.  After that the table can be a feature class using the XY Event layer option.

In a sense, the latter situation is better, since if you repeatedly capture new GPS coordinates each time you inspect the pole or log a new bulb, outage or repair you will get minor variations in the coordinates that make it harder to tell what features should be summarized.  You always want the same pole coordinates each time for the one-to-many relationship so that it is easier to do Spatial Joins, summaries, or Collect Event operations to get counts of the number of bulbs, inspections, outages, repairs, etc and the one-to-many relationship allows you to achieve that.  You may have two sets of coordinates, one for the GPS capture of the bulbs, inspection, repair, etc, and a second for the pole position, but for accounting purposes and map displays I am sure you want everything to match up to the one pole coordinate pair every time.

Normally for a printed map one-to-many relationships that would create overlapping features get mapped using summary values rolled up to the one pole point, rather than trying to show each individual event for the single position, and you include a group ID value label that relates the count to the individual line items shown in a separate table sorted by that group ID.  But the XY Event table allows you to overlap the points and do labeling, etc for the individual events when you need that.  But I find that maps which do display all of the overlapping events or filtered groupings of overlapping events are best to interact with live and use the Identify tool to see the individual event listings for a position without trying to show every distinct event as a separate visual item or label on the map.

ElliottRobinson · Answer

Try this exercise - look at the back of your left hand.

Your left hand represents your shapefile (a feature class because it has geographic info in it).

Let's say you've had this shapefile for years - it was created back when the light poles were plonked into the ground by gruff but clever pole plonkers. It tells you where the poles are and gives them each an identification number, represented by your thumb.

Now look at the back of your right hand.

Your right hand represents the bulb outage data that the contractor collected. Your right thumb represents the identification number that the contractor read off the pole.

Now, while holding your hands out in front of you, bring them together until your right thumb covers your left thumb. You've successfully joined the two tables, one with geographic info (the left hand), and one with non-geographic info (the right hand). This will of course not work if you've had a terrible carpentry accident leaving you with only one thumb.

Here's my attempt at explaining the advantages of this system: There are probably many ways that a non-geographic table (your right hand) can be used. The company that provides you light bulbs doesn't care where the poles are (because they are not installing the bulbs), but they do care what type and how many. Whoever orders the bulbs can use the info from the outage table to order the bulbs each month. The person in the warehouse doesn't care where the poles are, they just need to know how many bulbs and which type they need to bring to the maintenance crew.

The maintenance crew needs both hands - the table that tells them where the poles are, and the table that tells them which of the poles need bulbs replaced.

The advantage in this case as that everybody has the information they need, but not information they don't need (which wastes their time).

Displaying the location of the poles will be a lot quicker if their attribute table is as small as possible, and with massive databases, that can mean a big difference in productivity.

Sorry this has been a bit convoluted, but I hope it at least partially answers your questions.