The current data files for the Varley and Gulliver masts hold minimum foundation width for use with the FCL 'cast-in cradle' anchors. They are indeed storing the larger distances "for drilled and resin fixed anchors" and not the values for "cast-in anchors". The default assumption in KeyPOST for posts for which cradles are available is that the posts are used with them embedded by concrete cast in situ. The minimum width information will be changed accordingly in the new version and, when available (and tested) updated data files can be supplied on request. I hope this is OK.
The short answer is yes.
Whilst it would be hard to go into exactly how here, there are a couple of things to note. Firstly, KeyPOST doesn't consider how the sign is to be attached to the support, it assumes that a suitable fixing is available. Secondly, there are two ways that people consider what a cantilevered attachment is, either using clips into the channel behind the sign, with a small portion of the sign overlapping the post, or a 'true' cantilever where no part of the sign overlaps the support. Of course, in the latter case and if this for example was a triangular warning sign, some sort of channel or other horizontal attachment from the top part of the sign would be needed. KeyPOST doesn't need this as it assumes some sort of fixing will be in place. You can of course add channel to the sign if you want to see this. Have a look at the two images attached as files to this post. IN the one showing a triangular sign I haven't added any channel so it seems impossible but KeyPOST can still verify the design is a valid structural overall.
If you want more information about exactly how to achieve this please feel free to give us a call and we can try to set-up a screenshare to talk you through the process.
Hi Guy, you're right and it is something that we have known about for a few releases. The issue is to do with having a live update as you change a property which is sometimes good, but doesn't always make sense or work correctly. We will take another look at this for the next version and see if we can't make things a bit better. Thanks for reporting it.
In the meantime you just need to careful to make sure, when you press the delete key, that the focus (the cursor is still flashing) in the box of property you are editing. Please call us if you want to discuss this further.
Whilst finding and listing any Stats 21 errors in your data is easy in KeyACCIDENT, resolving these can be a tricky process. Again, it is easy to access any collision in which an error has been identified, but some are easy to figure out what the resolution may be than others. For example, if a collision has been recorded as having occurred at a junction, both a first road class/number and one for the second, intersecting road must be recorded. If one is missing this is a Stats 21 error, so filling in the second road's details will resolve the error. Some, however, are more 'esoteric'! Lastly, some errors are just a call to query the validity of the data, such as driver's age. It is stated in Stats 21 that 'IF 2.5 (Type of Vehicle) = 02-05, 08-11, 17-21, 23, 97 or 98 THEN query 2.22 [the driver's age] if less than 16'. So this is not strictly an error and you won't want to change the age, if under 16, if this was the actual age of the driver.
A great suggestion as always, and thanks for using the forum. Hopefully others will comment and help us to shape KeyACCIDENT. It might get quite complicated to store all adjustments, such as a small move here and a slight rotation there. Perhaps one easy win might be to enable a snapshot of the edited manoeuvre to be captured as an image and, if an image has been stored, optionally for KeyACCIDENT to place this instead of the geometry it creates at present.?
Comments always welcome.
Thanks again for your feedback.
We do run courses, absolutely, in our fully equipped training suite, and can bring this out to customer offices if required. We haven't run an advanced course for KeyPOST yet as most elements of the software and design Standards etc. are covered in the first day. However, the finer points of how to get from a wind speed to a design pressure, using BS EN 1991-1-4:2005 (Eurocode 1), is not covered. This is because getting from a wind speed to the force on the structure involves many pieces of information, including for example the slenderness (aspect) ratio of the sign. Another thing to note is that the force used to calculate the design meets all parameters (classes) such as post bending or torsion, is different for the Ultimate Limit State (ULS) and for the Serviceability Limit State (SLS). All this means there isn't one loading appropriate for every sign at any given location for every class.