nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sign Inventory in LGIM anyone?

KennethLohr

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?

Find more posts tagged with

Local

Accepted answers

All comments

KennethLohr

Also,
How would one propose to track changes that are made during sign inspections over time?

ScottOppmann

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

KennethLohr

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.

ScottOppmann

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.

BrianMcLeer1

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.)

DeeannaGall

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

BrianMcLeer1

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.

NancyGnanicys

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.

BrianMcLeer1

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.

JoshuaDamron

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.

I completely get what you are talking about! If the user is looking up a guide sign then they don't want need to scroll through 50 regulatory sign options. While I know how to build this into an Access database, I don't know if ArcGIS is able to do it. I have seen this done before though. I just got the most recent ArcNews magazine and there was an article about the City of Highpoint successfully creating a sign inventory. You can read the article here: http://www.esri.com/esri-news/arcnew...vity-standards.
They also did a FHWA presentation that drilled into some of the more technical aspects of their inventory work, you can view it here: http://www.gis.fhwa.dot.gov/webcast19_nc.asp.

Anyways, they built a FLEX collector app that has the functionality you are wanting. You may contact Highpoint and see if they are up for sharing the lessons they learned.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.