Sign Inventory in LGIM anyone?

4775
10
04-24-2013 11:55 AM
Labels (1)
KennethLohr
New Contributor III
I'd like to hear from anyone who is successfully or unsuccessfully using the LGIM for purposes of street sign inventory.  We at the City of Titusville are finding it mostly useful.  We've overcome some snags and still have issues to address.

Most currently, in anticipation of using some of the newer apps, I wanted to upgrade to the newest release of LGIM.  Having downloaded it today, it appears that the relationship class tying the Sign table to the Pole feature class has been removed.  I can't find any information on when this happened, why it happened and what the recommended action is to continue use of the model.  Has another method been implemented?  Should I create the relationship class myself? Not sure what to do at this point. 

We want to use ArcGIS Online maps and/or the Collector app to maintain the data, so we've put the model into SDE to permit remote feature editing.  Any commentary relating to LGIM, SDE and mobile workflows would be most appreciated as well. 

What have you been able to accomplish with it?
10 Replies
KennethLohr
New Contributor III
Also,
How would one propose to track changes that are made during sign inspections over time?
0 Kudos
ScottOppmann
Esri Contributor
We removed the physical geodatabase relationships between poles and signs because we're relating multiple tables (signs, lights, signals) in the geodatabase to a single pole feature class.  As such, we'd instead suggest you do a map join in ArcMap before you publish the service so you don't see all three features (signals, signs, and lights) in your service. 

If you're interested in using AGOL and the Collector to tackle a sign inventory project, you'll have to flatten out the structure a bit more and essentially collapse the pole feature class and sign table in to a single Sign feature class.  The Collector app does not support related tables at this time. 

This workflow will work really well for your sign inventory, but won't help you with subsequent inspection workflows.  The best solution right now if you want to use AGOL and the Collector app for ongoing inspections is to create a SignInspection feature class and capture point features for each inspection activity. 

Scott
0 Kudos
KennethLohr
New Contributor III
Thanks for the thorough answer, Scott.  Much appreciated.  One more question.  What is the recommended method for making sign inspections with respect to the geodatabase?  Just editing the table in ArcMap? Generally, those folks doing the inspections are not going to be ArcMap users, so is there some other method to edit this table in a mobile or more user-friendly environment?  I thought I remember running into this issue of editing related tables before when trying to wade through this process.
0 Kudos
ScottOppmann
Esri Contributor
Ken -

Sorry I didn't get back to you sooner.  Just saw your post today unfortunately. 

I don't think its realistic to think the sign inspection data will be collected using ArcGIS for Desktop.  As I mentioned in a previous post, there are a couple different ways you could make this data available for field inspection. You could:

1. Flatten the data structure out and create a sign inspection feature layer that can be used by field inspectors with the Collector for ArcGIS app.
2. Deploy a custom mobile app (like the code violation app we have in the solution) that allows users to collect information on the poles and then add one more signs in a related table.
3. Use ArcPad to take this data offline and collect the poles and signs.

Bottom line, you�??ll need to nail down exactly what your field collection device and application approach is going to be first and then start to work through how you structure the maps and underlying information model.
0 Kudos
BrianMcLeer1
New Contributor
I had to create a new feature class for the street signs using the Loc Gov't Data Dictionary as a guide. I used domains for the sign code/ description and used subtypes for sign type (regulatory, warming, etc.)
0 Kudos
DeeannaGall
New Contributor II
Would you mind sharing your flattened structure you came up with?  I would be curious to compare the two and see what works better for our applications.

Thanks,
Deeanna
0 Kudos
BrianMcLeer1
New Contributor
I am not sure how to share it from here, but you can email me at bmcleer@cityofclovis.org and I can email you the dataset template.
0 Kudos
NancyGnanicys
New Contributor II
I had to create a new feature class for the street signs using the Loc Gov't Data Dictionary as a guide. I used domains for the sign code/ description and used subtypes for sign type (regulatory, warming, etc.)


Brian,
How did you deal with multiple signs on one pole? I imagine that the coordinates would be just a tad different when collecting multiple signs for that one location. I'm trying to implement a collection effort as well.  Also, was there a way you could control the subfields for the sign type?  For example if Regulatory was selected, the next field would only give the option of stop, speed, turn etc rather than show all signs so that a warning sign doesn't get selected and then a stop sign get specified as the series type.
0 Kudos
BrianMcLeer1
New Contributor
Brian,
How did you deal with multiple signs on one pole? I imagine that the coordinates would be just a tad different when collecting multiple signs for that one location. I'm trying to implement a collection effort as well.  Also, was there a way you could control the subfields for the sign type?  For example if Regulatory was selected, the next field would only give the option of stop, speed, turn etc rather than show all signs so that a warning sign doesn't get selected and then a stop sign get specified as the series type.


Nancy,
I have only had to deal with collecting single sign features so far. Most of the data for my collection was for Stop and Yield signs for a traffic flow question. I did you use subtypes (regulatory, warning, etc), and when I choose a subtype it would go into the selection of signs appropriate for that subtype (regulatory: stop sign, warning: yellow chevron, etc). If I had to account for multiple signs on one post, I would add the subtype and domain field again as a second choice. To display this, I would probably have to query it to NOT NULL on the second fields as a second layer on the map.

Unfortunately, the subtype option first then the sign type only worked in ArcMap. In the collector app, I have not found a way yet for it to observe a subtype first, then the sign type, which led to a very long list when collecting signs.
0 Kudos