Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rickmastfan67]

Sorry for the double post.

Don't worry, this isn't a "double post".   A double post is a post made 5 minutes after the first.  Your 2nd post was 6 days later, hence, not a double post.

[myosh_tino]

The California-spec city limit sign (sign code G9-5) also includes the population and elevation...

[Quillz]

Apparently, Arkansas uses a slight variant of the otherwise standard '70-spec US route shields:




Made as cutouts, obviously. But note how the bottom is curved. I've seen some older custom shields, mainly in Wisconsin, that used this style. Didn't know it was still around, though.

[vtk]

Apparently, Arkansas uses a slight variant of the otherwise standard '70-spec US route shields:




Made as cutouts, obviously. But note how the bottom is curved. I've seen some older custom shields, mainly in Wisconsin, that used this style. Didn't know it was still around, though.

Is their square shield really a squished version of their wide shield?

[Quillz]

Apparently, Arkansas uses a slight variant of the otherwise standard '70-spec US route shields:




Made as cutouts, obviously. But note how the bottom is curved. I've seen some older custom shields, mainly in Wisconsin, that used this style. Didn't know it was still around, though.

Is their square shield really a squished version of their wide shield?

No, that's a (bad) concept. I've fixed it since I posted last. Seems only the wide shield has the curved bottom, and I'm not even sure why, since it's inconsistent with the standard shape.

[agentsteel53]

there is historic precedent for the 'gullwing' shape.



California, 1956 - one of the earliest wide shields.  I know only of MA and NY who had wide shields earlier.  I believe that this 1956 style is the first abstract wide shield, without a state name.  it, and several later revisions, would serve as the model for the federal 1961 and 1970 styles.

[Quillz]

The gullwing looks a lot less pronounced on the US-466 shield that the one that Arkansas and a couple other states appear to be using, though. It's not a bad look, but I just think the flat bottom is simpler.

[WolfGuy100]

Look familiar?  I'll give you a hint...look for my FIRST sign I made in this thread when I first came here. I'm rather happy with this sign since it look so much better. Although, exit number tab bothers me because PowerPoint won't automatically attach it to main sign. But I'm still happy with it.

[Takumi]

The use of a different shield for another region is a nice touch. Out of curiosity, do you have shields picked out for Johto, Hoenn, and Sinnoh?

[WolfGuy100]

The use of a different shield for another region is a nice touch. Out of curiosity, do you have shields picked out for Johto, Hoenn, and Sinnoh?

Thanks, man. And no, I'm still experimenting with what shape their route shields should look like. And don't forget Unova too!

[Quillz]

Does anyone here use Illustrator? If so, how do I make different regions that I can color, a la an Interstate shield? I want to alter California's US Route shields to add a crossbar. Once that's added, I want to be able to make the crown a different color from the rest of the shield.

[WolfGuy100]

Does anyone here use Illustrator? If so, how do I make different regions that I can color, a la an Interstate shield? I want to alter California's US Route shields to add a crossbar. Once that's added, I want to be able to make the crown a different color from the rest of the shield.

You should ask KEKInc because he was the one who made these signs.

[Quillz]

Does anyone here use Illustrator? If so, how do I make different regions that I can color, a la an Interstate shield? I want to alter California's US Route shields to add a crossbar. Once that's added, I want to be able to make the crown a different color from the rest of the shield.

You should ask KEKInc because he was the one who made these signs.

What signs? I'm working with simple shield templates, and I can't figure out how the people who made said templates were able to get the two regions of the interstate shields so they can be different colors. (Red for the crown, blue for the rest of the shield.)

The reason I'm asking is because I want to make a US Route shield that has interstate colors.

[J N Winkler]

You need to find your graphics program's "Break apart" command (to convert an object with multiple subpaths into multiple objects with one subpath per object).  The crown and blue field of an Interstate shield are typically drawn as one object, the crosspiece is subtracted from it (thus creating two subpaths), and then the subpaths are broken apart so that one object is the crown while the other object is the blue field.  Each object can then take its own color fill.

This technique is also useful for making guide signs with a color transition at a ruled line (e.g., green-background guide and brown-background tourist information messages on the same sign panel).

[Quillz]

You need to find your graphics program's "Break apart" command (to convert an object with multiple subpaths into multiple objects with one subpath per object).  The crown and blue field of an Interstate shield are typically drawn as one object, the crosspiece is subtracted from it (thus creating two subpaths), and then the subpaths are broken apart so that one object is the crown while the other object is the blue field.  Each object can then take its own color fill.

This technique is also useful for making guide signs with a color transition at a ruled line (e.g., green-background guide and brown-background tourist information messages on the same sign panel).

Thanks for the info. I believe Illustrator's equivalent command is Pathfinder -> Subtract. I'll have to look into it.

[Ace10]

I use Microsoft Expression Design and Inkscape for vector graphics, and the way to split a path is to create another object (a rectangle would be great for this) and place it over the region you want to split. Look for something like path operations, and there should be options for union, difference, intersect, front minus back, back minus front, etc. The names differ from program to program, but the overall concept is the same.

[vtk]

I've got an interesting project going in my spare time right now.  I'm building a layout and drawing engine for highway signs.  It takes structured input (currently in my own goofy format, but I plan to support an XML-lookalike flavor in the future) and produces a finished sign or sign assembly in SVG.  The layout is based on concepts from the HTML box model, except it treats the horizontal and vertical dimensions the same, plus a few other tweaks.  I might be reinventing the wheel, but somehow I doubt there's any free product that does what I have in mind.

Anyway, here's a sample showing off what I've got so far:

Code: [Select] type=vstack {   type=vstack   halign=fullwidth   backcolor=green   bordercolor=white   border=1.5   border-bottom=0   radius=8   bordergap=0   bordergap-bottom=0   rounding=border   rounding-bl=none   rounding-br=none   padding=6   containmargins=yes   {     type=hstack     halign=fullwidth     {       type=routemarker       route=I-71       width=24       height=24       margin=2       color=white     }     {       type=text       text=NORTH       fontseries=E       color=white       height=8       width=30       valign=top       margin=2     }   }   {       type=text       text=Columbus       fontseries=E(M)       color=white       height=12       width=72       margin=9   } } {   type=zstack   halign=fullwidth   backcolor=yellow   bordercolor=black   border=1   border-top=0   radius=8   bordergap=.6   bordergap-top=0   rounding=border   rounding-tl=none   rounding-tr=none   padding=4   containmargins=yes   {       type=text       text=EXIT ONLY       fontseries=E(M)       color=black       height=8       width=64       margin=4   } }

It doesn't know how to draw text or route markers yet, so those unrecognized elements are represented by placeholder boxes.  What it can draw so far essentially consists of various rectangular panels (with or without various borders) and of course placeholder boxes.  The example doesn't quite show off all of the layout features, nor does it come close to show off all that can be done combining the features that are shown.  I still need to get it to do text, route markers (which ideally will feature "optically spaced" numerals), and other graphic elements.  Eventually I intend to code some advanced layout features dealing with world-space alignment and negotiation, the most obvious use of which involves downward-pointing arrows.

As soon as I get it doing text and the crudest of route markers, I'll open it up to the public.  Readers of this thread will be my beta testers, I guess!

PS Yes, I had Indiana in mind when I made this example.  It's a good first test of full-width horizontal alignment of horizontal stack elements.

[Steve]

Note to VTK: watch the border widths. The white is too wide - should not be equal to black + inset.

[Dr Frankenstein]

I can have a look at if and when you'll take actual testers. And if so, are you publishing the source code as well?

[J N Winkler]

Note to VTK: watch the border widths. The white is too wide - should not be equal to black + inset.

Just to add:

*  Remember the conventions of horizontal spacing = uppercase letter height and vertical spacing = lowercase loop height (reference letter height being that of the primary destination legend).  The example sign has cramped spacing out to the borders.

*  When producing positioning code, remember that in many contexts (particularly arrow-per-lane diagrammatics) there is no unique choice as to how to position legend and other elements.  Frequently the solution that "looks right" is not the same as the solution that would be autogenerated by naïve application of positioning rules.  This is an example of a sign which has had to be "fixed" by overriding positioning rules (in this case, by adding more space to divide the right-hand side of the sign panel equally between the two directions of I-235):



*  Will there be a way to produce vector output?

[NE2]

produces a finished sign or sign assembly in SVG.

*  Will there be a way to produce vector output?

[Ace10]

vtk: I dabbled a bit in road shields and ended up programming my own shield generator which took a predefined shield (Interstate 2D and 3D, US Route 2D and 3D, Florida State Road 2D and 3D, Florida Toll 3D, etc) and replaced the route number with a standard string of numbers and letters. It then exported them into a raster image that I used for what used to be my OpenRoad project. I imagine you can extract the SVG for the road shield, place a number in some predefined position (and you'd have to play with the spacing to get the numerals exactly right), and then import it into a predefined position on your finished BGS.

My OpenRoad project was going to be a fully-functional road navigation system AND toll & mileage calculator, but it defaulted to the latter because it's just too cumbersome for one person to develop the entire thing. I'd be happy to provide my current expertise on the subject (which isn't that much, but it may help) of auto-generating road shields in both vector and raster formats, or to test what you come up with. Just PM me if interested.

[vtk]

Re my example sign: The border widths were based on the estimated text stroke width of the destination and action message for the green and yellow panels, respectively; by coincidence, the border+gap on the yelloww panel nearly matches the border width on the green panel.  The margin around the destination legend was set to ¾ the nominal text height; I'm aware that the side margins should be equal to the full text height.  The image shown here is a PNG file, converted from SVG because I didn't want to worry about forum support or browser compatibility.

Re the project: My layout engine does not attempt to enforce specific metrics or propoortions from the MUTCD or sign design manuals.  Dimensions are largely driven by properties specified in the input.  There may be, in the future, facilities to apply common properties to multiple elements to reduce redundancy in the input.  The output is currently a report about the parsing and positioning process, plus SVG; when it goes beta, the primary output will be switched to SVG only.  The source code will probably be made available when the featureset is stabilized.

Arrow-per-lane signs may require specialized elements; it's too early to know how to approach that type of sign at this early stage of development.

[J N Winkler]

Re my example sign: The border widths were based on the estimated text stroke width of the destination and action message for the green and yellow panels, respectively; by coincidence, the border+gap on the yelloww panel nearly matches the border width on the green panel.

But doubled borders on bottom yellow "EXIT ONLY" panels are hardly vanilla provision--the more usual approach would be to run a black border (of the same width as the white border for the green background) out to the edge of the sign.  We also don't attempt full scalability (unlike some other countries, e.g. Britain), so border width and corner radius are typically fixed without referring to the stroke width of the legend.  The usual rule of thumb is 2" border with 12" corner radius for a sign having 16" UC/12" LC for primary destination legend.

The margin around the destination legend was set to ¾ the nominal text height; I'm aware that the side margins should be equal to the full text height.

This is fine, but actually the 3/4 spacing should apply across the whole sign except for the yellow panel, which implies 3/4 spacing between the top of the shield and the inner edge of the border.  (Yellow panels are of fixed height and don't quite follow the usual spacing rules because of the downward-pointing arrow, which is usually 22" on a sign with 16" UC/12" LC primary destination legend and a yellow panel 36" high, inclusive of 2" black border.)

In any case, these are relatively low-level details and can be tackled at a later stage.

Re the project: My layout engine does not attempt to enforce specific metrics or proportions from the MUTCD or sign design manuals.  Dimensions are largely driven by properties specified in the input.  There may be, in the future, facilities to apply common properties to multiple elements to reduce redundancy in the input.  The output is currently a report about the parsing and positioning process, plus SVG; when it goes beta, the primary output will be switched to SVG only.  The source code will probably be made available when the featureset is stabilized.

I wish you the best of luck as you progress through development.  I have actually considered something similar, which would accept sign design parameters encoded in a structured markup language and output finished signs in SVG.  This could be used to make large numbers of relatively simple signs, which would be useful for making a pattern-accurate sign log of a rural Interstate highway.  However, I eventually realized that the problem of positioning digits correctly in route shields was a bit more complex than simple optical centering, and that even with a large majority of signs being simply formatted, it would still be necessary to custom-build some signs using the CorelDRAW scripts I already had in hand.  I came to question whether a SVG-producing program would deliver any significant time savings above and beyond drawing each sign in hand in CorelDRAW using my existing script suite, recycling elements from adjacent finished signs as necessary.  I put this premise to the test by drawing several hundred signs on Columbus I-270 (using a photo sign inventory as a source).  The results prompted me to stick with the CorelDRAW scripts in the end, but this was more because the scripts were already in hand while the "sign autogenerator" would have required added development.

[vtk]

In any case, these are relatively low-level details and can be tackled at a later stage.

These details can be tackled now, as they are controlled by the input data, not by the program itself.  The dimensions in the example were chosen based on a combination of MUTCD guidelines, personal preference, variety for the sake of testing, and laziness.

Positioning digits in a route shield (considering the shape of the digits and of the shield itself) is the exact objective of another program I've been bouncing around in my head for a while now.  When done, it will be available as its own service, and incorporated into the sign maker service.