How to add road signs

[DannyWang]

Is there any way to add road signs(name of the streets) at the intersections of streets.

Like this :

or this:

[CherylLau]

You could write a rule to put a street sign on the corner of a shape of type junction or crossing (Street and Crossing Shapes ).  However, it is only possible to figure out the direction of the main street in the junction.  Unfortunately, we cannot yet determine the angle of the intersecting street from a junction shape.  So, if your streets are all at 90 degrees, then you can hard code your sign posts to have the second street name sign at a 90 deg angle from the first street name sign, but I realize this is not ideal as streets are not always 90 deg to each other.  Thank you though for sharing your issue as it is good for us to know these use cases.

To make the highway signs over the road, maybe you could position them using the u coordinate which goes along the street.

[DavidWasserman · Accepted solution]

Well it might be possible to use a mapped attribute to deal with the direction issue. If you use buffers around intersections to split segments near the intersection, then calculate a heading for that line (see line bearing)​, you could then do an object insertion that takes that mapped value as a parameter using the world coordinate system. Help - Rotate operation.
I have never tried this, but I have intended to experiment at some point. It would involve, finding a way to split a line at the intersection approach, calculating line bearing, then doing spatial joins from the line to the sign points (data required would be angle of rotation, and the obj file to be used), and then figure out how to use that line bearing to guide insertion angle in CE.

EDIT: Cheryl's suggestion is great if you want to do a street based approach (a hybrid approach is possible). The Complete Street Rule might give a good starting point for such an insertion.

Just an idea.

David

[Anonymous User]

David has made a really cool street rule, but I think both of these sign rules should just be stand-alone rules. No reason to over-complicate things.

There are also good reasons to make these as distinct rules. For the basic street signs, a city will likely have GIS point features for these signs. It would also be useful to all of the CGA authors to have a simple sign rule, which is not dependent on having a street rule.

And the overhead sign should just be a rule running on a long polygon stretched across the street. That would also be an excellent stand-alone rule. That's a challenging type of geometry. Wish I had that on top of my stack. Sounds fun.

Chris

[DavidWasserman]

I think Chris is right, this would likely be best as a standalone rule that uses the mapped attribute approach I mentioned above, and the polygon approach for the overhead sign. It would be interesting to see a polygon based sign rule that expanded and added different types of signs with longer lengths.
It would be nice if the rule made was modular enough to be imported into a street rule if you ultimately want to depend on street geometry more.

David

[CherylLau]

Agreed.  A standalone rule makes the most sense in this case.

Good point, Chris, that the input data could likely be GIS point data.  And, good idea, David, to import it into the street rule if you want to make the overhead sign align with the street's v coordinate, for example.

[DavidWasserman]

While this thread is old, it is worth providing an update. 
https://community.esri.com/people/GTaylor-esristaff/blog/2018/11/02/3d-street-sign-library-for-arcgi... 

Esri has developed a stand alone US sign rule that can take custom textures. It is also located in the Complete Street Rule Github in the "Stamp_Rules" folder. 

Hope this helps future users!