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; } } }

Road Sign inventory/maintenance

RandySims

Hello,

I want to map all the roads signs in my county and keep maintenance history. Does anyone know of an app or a way to accomplish this? Our sales rep suggested the Damage Assessment app.

Thanks

Find more posts tagged with

Accepted answers

All comments

IanKidner1

I believe there are two general methods for this, one being using a GPS device in the field to record the location of each sign. The other is using digial photo-log technologies. There are companies that can take high definition photo images of your road, and by combining GPS coordinates assocaited with each photo, and aerial/satellite imagery, you can extract a sign's lat/long from the photo image. This is not done automatically (in solutions I'm aware of), and requires a user catalog the sigs with an application on a computer.

Each method has some pros and cons, given your available budget. The field GPS method will have a lower start-up cost, as all you need to purchase is a GPS unit, some processing software, and you can develop the database/form necessary for your purposes. But it will require more time in collecting the data, given you actually have to go to each sign. The photo method requires more up-front cost, as you will need to pay a company to help with the initial data collection of photos, but then the asset extraction from the photos will go much quicker than the other method.

If you are a more rural county with a smaller available budget, it might be possible with get some adjacent counties to pool money if you're interested in the photo-log method; you might be able to get a price break, but you'd need to work that out with a vendor.

TimothyTresohlavy

I've used a simple hiking-grade GPS device to collect Lat/Long points at wayfinding sign locations. The resulting table was converted to an XLS spreadsheet, and populated with some field notes such as size, type, condition, etc. The table can then be automatically digitized in ArcMap using Right-Click > Display X,Y Data.

As long as the coordinate system is set to a Lat/Long Geographic (non-projected) variety, such as "GCS_North_American_1983" the points will be correctly placed, and save you weeks of digitization.

Just pay some interns with an iPhone to collect the points.

BrianYoung1

There are also third party companies that make Assets Management Systems. They use GIS but may not be based on ESRI.

JoshuaDamron

Our sign inventory has not been fully completed or field truthed yet, however we got it started with interns driving the City using Google Street View and using our high quality (1/4 ft per pixel) imagery to locate and identify signs. We also had an intern go through the MUTCD and create sign blade symbols Esri didn't have using a program I found online called Font Creator. Using this program the intern found a method for importing images from MUTCD(CA) .pdfs or field photos and such to create the fonts.

The biggest obstacle for ArcGIS is how to map symbols for multiple signs on a single post. It is not advantageous to just have dots on a map, field crews and decision makers need to be able to visualize the different signs at each location (which ones the speed limit sign?). Trying to overcome this we tried several things but we were not successful. The project is currently stalled until we resolve how to track assemblies of multiple signs at a given location (fixed to the same pole). Can someone share some insights or ideas for symbolizing & tracking multiple signs at one location?

MartinsLinde

I am not sure whether our solution in mapping multiple signs on one pole can be adopted in ArcGIS (we have done it on open source software). The idea is to draw a line with two segments:
the first segment's direction shows sign activity direction;
the point between segments is the actual sign position (pole position);
the end point of the second segment is the place where to draw map sign symbol.

When symbolizing the feature the first segment is not drawn, it is used only for calculating sign direction field and rotating sign symbol, so you can also draw line with one segment and input angle field value manually.

Sounded more complicated than it is 🙂
You can see in screenshots how it looks symbolized and how it looks when drawing:

http://geokods.com/#!/work/road_traffic_control

RichardFairhurst

Our sign inventory has not been fully completed or field truthed yet, however we got it started with interns driving the City using Google Street View and using our high quality (1/4 ft per pixel) imagery to locate and identify signs. We also had an intern go through the MUTCD and create sign blade symbols Esri didn't have using a program I found online called Font Creator. Using this program the intern found a method for importing images from MUTCD(CA) .pdfs or field photos and such to create the fonts.

The biggest obstacle for ArcGIS is how to map symbols for multiple signs on a single post. It is not advantageous to just have dots on a map, field crews and decision makers need to be able to visualize the different signs at each location (which ones the speed limit sign?). Trying to overcome this we tried several things but we were not successful. The project is currently stalled until we resolve how to track assemblies of multiple signs at a given location (fixed to the same pole). Can someone share some insights or ideas for symbolizing & tracking multiple signs at one location?

There is no solution for multiple records as far as I know. At the moment I stack the signs on top of each other and it gives information that is used, but managers want perfection and I have told them it will cost them a lot to retroactively apply the fix on our existing 50,000 sign records. If I were starting from scratch it would be easier to collect the data correctly, which is much less costly.

You would have to create derived records from your individual signs grouped and pivoted by pole to create the assemblies. You would need to number each individual sign face with a sequential number representing its vertical position on the pole and then use that value to create the pivot field names. Then you concatenate the separate columns of sign codes on the post into a single field with all of the codes to represent an assembly and use that to create the symbols. I would not bother with trying to group actual assemblies, but if I did I would need an assembly grouping field for an initial pivot before pivoting the entire pole. Signs records would first have to be pivoted to create assembly records and then pivoted again to create pole records containing multiple assemblies.

My data has been developed over a 20 year period in table form and was not spatially designed. It only told me positions along the street and travel direction facing, but did not give any information related to pole groupings, lane positions or side offsets. As a result when I pivot the records, several signs and lane markings are generating false assemblies in my data that should be separated into separate lanes and poles and I get over 500 new unique assembly combination using this method, many of which are not real. They also did not specify any vertical position on the same pole so I currently can only order them alphabetically with the pivot, so the relative sign positions in an assembly are not real and multiple separate assemblies cannot be identified clearly. So I first have to account for side offsets, vertical position numbering and possibly assembly grouping numbers and then generate the actual set of assembly sign codes I really need using the pivot tool.

We are beginning to list side offset positions by lane number order for each DOT. I will have to add a vertical positioning field to control order on a pole. A single sign face would always be in vertical position 1. Multiple sign faces would start at position 1 relative to either the top or bottom of the pole location and have to work up or down. Probably starting at the top and working down is most intuitive.

I could use help with the sign face creation tools and would be interested in the techniques you used to create fonts. This is the real costly process if done to high quality. I looked at Font Creator, but could not figure it out. Instead I used scans of sign specification diagrams and recreated them as vector graphics to get the highest quality images I could and then exported those as .emf files to create picture graphic symbols. Time consuming, but I have about 300 of them now. (See the samples I posted here). But I still have hundreds to go without any assemblies. Ideally those vector graphics could be reused in the Font Creator tool.

Here is a related post that deals with some of these techniques

RichardFairhurst

I am not sure whether our solution in mapping multiple signs on one pole can be adopted in ArcGIS (we have done it on open source software). The idea is to draw a line with two segments:
the first segment's direction shows sign activity direction;
the point between segments is the actual sign position (pole position);
the end point of the second segment is the place where to draw map sign symbol.

When symbolizing the feature the first segment is not drawn, it is used only for calculating sign direction field and rotating sign symbol, so you can also draw line with one segment and input angle field value manually.

Sounded more complicated than it is 🙂
You can see in screenshots how it looks symbolized and how it looks when drawing:

http://geokods.com/#!/work/road_traffic_control

I don't understand the relationship of the lines you are creating to each individual sign. It seems like GIS would require the creation of the point between lines to actually symbolize the sign, since I don't know of a way to make a sign face appear on a line. How well does it scale to other zoom factors? How many signs are you managing?

I use Linear Referencing and do not intend to do any manual drawing. I have my LR position and angle and could use Bearing Distance to Line tool to derive a new line, but is that practical? Since I have no idea about the actual sign assemblies or poles I have to approach this in a way that keeps the amount of locations I actually physically touch to a minimum and use rule based logic to get it done within budget. It also has to work over a fairly wide dynamic scale range. I only need approximations, not exact locations and I have never actually had to manually draw any sign location to get what I currently have.

Not all field staff is cooperative with capturing more information to describe the sign for GIS uses, even though they want the end product in GIS to be perfect. They just don't want to do the work to make it happen.

MartinsLinde

We are drawing a Linestring and symbolizing 2nd segment's both endpoints - starting point is the sign exact position and end point is the sign face on map. In DB we also automatically extract sign exact point for use in advanced spatial searches. We have also cases with signs next to each other on one pole e.g. in the middle of picture:
http://goo.gl/maps/C5D27

You are right, this approach requires more manual input as one must place also sign face on the map, but it is certainly more visually enjoyable, cause sign faces are drawn away from the road and the map never looks crowded. Sign faces are symbolized in map units, so it looks good in all zoom levels. It looks more like CAD system, not GIS.

Actually at first we also implemented approach where each sign had a field with a vertical order number, but it was difficult to symbolize such a signs cause sign symbol heights are different. Also, map was much too overcrowded and we had to think for an approach to get sign faces away from the street.

System is managing ~40000 signs (Riga city, Latvia).

RichardFairhurst

We are drawing a Linestring and symbolizing 2nd segment's both endpoints - starting point is the sign exact position and end point is the sign face on map. In DB we also automatically extract sign exact point for use in advanced spatial searches. We have also cases with signs next to each other on one pole e.g. in the middle of picture:
http://goo.gl/maps/C5D27

You are right, this approach requires more manual input as one must place also sign face on the map, but it is certainly more visually enjoyable, cause sign faces are drawn away from the road and the map never looks crowded. Sign faces are symbolized in map units, so it looks good in all zoom levels. It looks more like CAD system, not GIS.

Actually at first we also implemented approach where each sign had a field with a vertical order number, but it was difficult to symbolize such a signs cause sign symbol heights are different. Also, map was much too overcrowded and we had to think for an approach to get sign faces away from the street.

System is managing ~40000 signs (Riga city, Latvia).

What do you mean by "Sign faces are symbolized in map units, so it looks good in all zoom levels." Is this being done in ArcGIS? Is it using a reference scale setting or something equivalent?

RichardFairhurst

Linear Referencing is much more flexible. It already got me everything I have in GIS for the 50,000 individual signs that were non-spatial in my database. It took a few weeks and the locations are usually within 10 feet of the actual true ground position if the description of the location and the GIS road alignments are accurate representations of field locations. With all of the LR based rules and calculations that I know now I could do the same thing today in under 1 day if all of the street names were spelled correctly.

Using LR, with a single table and one event record for a sign I can create the actual position of the sign and a huge number of alternative positions by just adding alternative measure and/or offset fields and configuring alternative position layers designed for each zoom factor. The base angle for the road is automatically generated by LR and I have already derived a single calculation that has rotated all of my signs to their correct orientation according to the DOT facing field value. The only angle adjustments needed are plus or minus 90 degree rotations where field crews do not agree with real compass directions when they represent them with N, S, E, or W. Usually this occurs where signs are facing NE, NW, SE, or SW or along sinuous roads, which LR allows me to isolate and examine using SQL statements. Since most of my roads are on a grid, these adjustments are the exception rather than the rule.

Using the alternate measure/offset fields I can do a single calculation after deriving a clustering factor from the actual sign measure and offset locations (I already have an LR based technique for coming up with that factor). Even if I get it slightly wrong for a given location a simple edit of a number will change the artificial sign position to make adjustments without any mouse clicks. After doing a few hundred individual locations I will derive another rule based calculation to apply to all locations as an initial default position for each chosen zoom factor. At that point I can process all the rest of the 50,000 signs for each zoom factor adjustment I want using rule based logic that can be automated and create a script for new signs captured from the field.

If I complete my approach of deriving the actual assemblies for each post from multiple sign records into a single assembly record I can create a single symbol for the assembly that spaces the signs exactly the way I want vertically. The assemblies are not infinite and once the symbol is created no maintenance time will be required to achieve that perfect spacing. For assemblies that account for hundreds of sign locations the time spent on the assembly symbol will be next to nothing compared to manually adjusting the individual signs at each of those locations. The problem is diminishing returns when I have assembly combinations that are only used in just a few locations. But in the majority of those cases I still have yet to spend time designing an individual sign face anyway and designing one assembly sign face instead will not consume much more time over designing two or three separate sign faces.

After all of the sign assemblies and sign faces are completed, the process I am envisioning will be nearly fully automated using rule based logic from the data captured by the field worker to achieve a more than acceptable presentation. An optional refinement process using a few localized field calculations can do any perfecting of the positions and rotations when an area is chosen for an actual presentation.

MartinsLinde

What do you mean by "Sign faces are symbolized in map units, so it looks good in all zoom levels." Is this being done in ArcGIS? Is it using a reference scale setting or something equivalent?

No, symbolization is done in GeoServer using OGC SLD standard.

MartinsLinde

Linear Referencing is much more flexible. It already got me everything I have in GIS for the 50,000 individual signs that were non-spatial in my database. It took a few weeks and the locations are usually within 10 feet of the actual true ground position if the description of the location and the GIS road alignments are accurate representations of field locations. With all of the LR based rules and calculations that I know now I could do the same thing today in under 1 day if all of the street names were spelled correctly.

Using LR, with a single table and one event record for a sign I can create the actual position of the sign and a huge number of alternative positions by just adding alternative measure and/or offset fields and configuring alternative position layers designed for each zoom factor. The base angle for the road is automatically generated by LR and I have already derived a single calculation that has rotated all of my signs to their correct orientation according to the DOT facing field value. The only angle adjustments needed are plus or minus 90 degree rotations where field crews do not agree with real compass directions when they represent them with N, S, E, or W. Usually this occurs where signs are facing NE, NW, SE, or SW or along sinuous roads, which LR allows me to isolate and examine using SQL statements. Since most of my roads are on a grid, these adjustments are the exception rather than the rule.

Using the alternate measure/offset fields I can do a single calculation after deriving a clustering factor from the actual sign measure and offset locations (I already have an LR based technique for coming up with that factor). Even if I get it slightly wrong for a given location a simple edit of a number will change the artificial sign position to make adjustments without any mouse clicks. After doing a few hundred individual locations I will derive another rule based calculation to apply to all locations as an initial default position for each chosen zoom factor. At that point I can process all the rest of the 50,000 signs for each zoom factor adjustment I want using rule based logic that can be automated and create a script for new signs captured from the field.

If I complete my approach of deriving the actual assemblies for each post from multiple sign records into a single assembly record I can create a single symbol for the assembly that spaces the signs exactly the way I want vertically. The assemblies are not infinite and once the symbol is created no maintenance time will be required to achieve that perfect spacing. For assemblies that account for hundreds of sign locations the time spent on the assembly symbol will be next to nothing compared to manually adjusting the individual signs at each of those locations. The problem is diminishing returns when I have assembly combinations that are only used in just a few locations. But in the majority of those cases I still have yet to spend time designing an individual sign face anyway and designing one assembly sign face instead will not consume much more time over designing two or three separate sign faces.

After all of the sign assemblies and sign faces are completed, the process I am envisioning will be nearly fully automated using rule based logic from the data captured by the field worker to achieve a more than acceptable presentation. An optional refinement process using a few localized field calculations can do any perfecting of the positions and rotations when an area is chosen for an actual presentation.

Of course, if you had an existing non spatial database, then your approach is much quicker. But if there is no previous data and signs should be clicked on the map anyway, then it's sometimes more straightforward and faster to make one more click then to fill field value.

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.