The "unusually large" project mentioned in the previous post had a length of seven miles on two intersecting segments of two highways, as well as around 900 individual stripes. (The figure of 800 that I gave previously was erroneous.)
In contrast, the latest project assigned to my office has a length of fifty miles spread across tennon-intersecting segments of six highways, and has around 1600 individual stripes. (The new project has fewer stripes per mile because it's mostly on two-lane cross sections and includes no interchanges, while the "unusually large" project was mostly on six-lane cross sections and included several interchanges. In terms of lane-miles, it's an increase from 55 to 120.)
How did this happen? Supposedly (as relayed by my immediate boss), the bigwigs decided to merge multiple smaller projects into a single gigantic project, so that the paving contractors will bid lower unit prices on the larger quantity of thin-surface-treatment material. Decisions of this nature have been made before. An egregious example on which I worked:
A pavement-preservation project was originally slated to cover a single nine-mile-long segment of highway (reusing the topo files of an older resurfacing project that included the same segment).
Then, for reasons to which I was not privy at the time, the bigwigs decided to split it up into three three-mile projects prior to the start of design.
And, finally, after the three projects had already been designed by three different engineers and submitted for initial review, the bigwigs decided (again, for reasons to which I was not privy at the time) that they had to be glued back together into a single project in the brief period between initial review and final submission!
It was utterly mindboggling.
On the bright side:
It seems that four of the new project's ten segments have been resurfaced within the past few years, and we may be able to reuse the electronic files of those resurfacing projects. So "only" twenty miles of baselines/topo/stripes, rather than the entire fifty miles, will have to be drawn from as-builts and satellite photographs.
Supposedly, the topo drawing for this project will be done by my organization's drafters, rather than by us designers. How well the arrangement will actually work out remains to be seen.
On another bright side, the HTML/Javascript program that I mentioned in a comment that I was writing as a replacement for a clunky old Excel/VBA program has turned out to be surprisingly functional. The engineers of my office have successfully used it on multiple projects so far.
It's reasonably simple:
Manually measure all the quantities in your project's prop (proposed-work) files.
Using Excel, input the numbers into a bunch of CSV files with predefined columns (pay-item ID, pay-item name, sheet group, sheet number, quantity, unit, location on sheet, comment, etc.), arranging the pay items in and among the files however you want—e. g., one CSV file for each construction sheet, one CSV file for all the project-wide boilerplate items (like mobilization and steel price adjustment) that aren't associated with a sheet, one CSV file for all the project-wide environmental items (like silt fence and concrete washout) that aren't associated with a sheet, etc.
Open an HTML file on your computer and "upload" the CSV files into the HTML file. (The dataset is still in your computer's memory, not actually uploaded to an external server.)
Check the warning and error messages. (Did you input a quantity as zero or negative? Did you input a non-integer quantity for a pay item (other than permanent signs, which uniquely are allowed to be non-integer quantities of square feet)? Did you forget to add the federal project number or a "state-funded" placeholder? Did you forget to list your initials in the "calculator" column and your immediate boss's initials in the "reviewer" column? For a project-wide lump-sum pay item, did you input a quantity that is not 1 (100 percent)—or, if the pay item is split between multiple funding sources (I haven't personally seen any such projects, but the author of the old Excel/VBA program explicitly mentioned this as something that (1) does happen and (2) can't be handled by his program), quantities that do not sum to 1? Did you input pay items with the same ID but different names in two different places? Et cetera.)
Click another button to get in HTML format ("printable" directly to 22″×36″ PDF) the table of quantities that always constitutes sheet 2 of the project's sheet booklet.
Click a third button to get in HTML format ("printable" directly to 8.5″×11″ PDF) a list of all the quantities in the project sorted by ID and sheet, with location on the sheet noted (required by the Construction people).
In the semi-near future, this manual process may be partially or entirely superseded by automatic quantity-calculation functionality in the new CAD software that I mentioned in the same comment. (That functionality appears to be accomplished via VBA. Sigh.) But I still am quite surprised that a random civil engineer who has done a little programming in his spare time can whip up in just two or three months something that seems a lot more intelligible than the Excel/VBA program that's been used for twenty or thirty years by the designers of an entire reasonably-large transportation organization.
More people need to make lengthy posts about their cool jobs in the vein of my previous post! I've been waiting with bated breath for the past year to hear about the dreaded "scrum master", "daily stand-up", and "Git merge conflict" from some of the 10× programmers that supposedly frequent this website. Maybe we even have an architect who can complain about his clients' wishy-washiness and scoff at all the pathetic free (libre) attempts to compete with Chief Architect, or a paving contractor who can express his hatred of his local transportation authority's resident engineers and in-house designers in the strongest of terms.
p
If anybody is interested, the shenanigans that I described almost exactly a year ago in my "Six Months in the Life of a Civil Engineer" AAQC have not gotten any less ridiculous.
The "unusually large" project mentioned in the previous post had a length of seven miles on two intersecting segments of two highways, as well as around 900 individual stripes. (The figure of 800 that I gave previously was erroneous.)
In contrast, the latest project assigned to my office has a length of fifty miles spread across ten non-intersecting segments of six highways, and has around 1600 individual stripes. (The new project has fewer stripes per mile because it's mostly on two-lane cross sections and includes no interchanges, while the "unusually large" project was mostly on six-lane cross sections and included several interchanges. In terms of lane-miles, it's an increase from 55 to 120.)
How did this happen? Supposedly (as relayed by my immediate boss), the bigwigs decided to merge multiple smaller projects into a single gigantic project, so that the paving contractors will bid lower unit prices on the larger quantity of thin-surface-treatment material. Decisions of this nature have been made before. An egregious example on which I worked:
A pavement-preservation project was originally slated to cover a single nine-mile-long segment of highway (reusing the topo files of an older resurfacing project that included the same segment).
Then, for reasons to which I was not privy at the time, the bigwigs decided to split it up into three three-mile projects prior to the start of design.
And, finally, after the three projects had already been designed by three different engineers and submitted for initial review, the bigwigs decided (again, for reasons to which I was not privy at the time) that they had to be glued back together into a single project in the brief period between initial review and final submission!
It was utterly mindboggling.
On the bright side:
It seems that four of the new project's ten segments have been resurfaced within the past few years, and we may be able to reuse the electronic files of those resurfacing projects. So "only" twenty miles of baselines/topo/stripes, rather than the entire fifty miles, will have to be drawn from as-builts and satellite photographs.
Supposedly, the topo drawing for this project will be done by my organization's drafters, rather than by us designers. How well the arrangement will actually work out remains to be seen.
On another bright side, the HTML/Javascript program that I mentioned in a comment that I was writing as a replacement for a clunky old Excel/VBA program has turned out to be surprisingly functional. The engineers of my office have successfully used it on multiple projects so far.
It's reasonably simple:
Manually measure all the quantities in your project's prop (proposed-work) files.
Using Excel, input the numbers into a bunch of CSV files with predefined columns (pay-item ID, pay-item name, sheet group, sheet number, quantity, unit, location on sheet, comment, etc.), arranging the pay items in and among the files however you want—e. g., one CSV file for each construction sheet, one CSV file for all the project-wide boilerplate items (like mobilization and steel price adjustment) that aren't associated with a sheet, one CSV file for all the project-wide environmental items (like silt fence and concrete washout) that aren't associated with a sheet, etc.
Open an HTML file on your computer and "upload" the CSV files into the HTML file. (The dataset is still in your computer's memory, not actually uploaded to an external server.)
Click a button to process the input.
Check the warning and error messages. (Did you input a quantity as zero or negative? Did you input a non-integer quantity for a pay item (other than permanent signs, which uniquely are allowed to be non-integer quantities of square feet)? Did you forget to add the federal project number or a "state-funded" placeholder? Did you forget to list your initials in the "calculator" column and your immediate boss's initials in the "reviewer" column? For a project-wide lump-sum pay item, did you input a quantity that is not 1 (100 percent)—or, if the pay item is split between multiple funding sources (I haven't personally seen any such projects, but the author of the old Excel/VBA program explicitly mentioned this as something that (1) does happen and (2) can't be handled by his program), quantities that do not sum to 1? Did you input pay items with the same ID but different names in two different places? Et cetera.)
Click another button to get in HTML format ("printable" directly to 22″×36″ PDF) the table of quantities that always constitutes sheet 2 of the project's sheet booklet.
Click a third button to get in HTML format ("printable" directly to 8.5″×11″ PDF) a list of all the quantities in the project sorted by ID and sheet, with location on the sheet noted (required by the Construction people).
In the semi-near future, this manual process may be partially or entirely superseded by automatic quantity-calculation functionality in the new CAD software that I mentioned in the same comment. (That functionality appears to be accomplished via VBA. Sigh.) But I still am quite surprised that a random civil engineer who has done a little programming in his spare time can whip up in just two or three months something that seems a lot more intelligible than the Excel/VBA program that's been used for twenty or thirty years by the designers of an entire reasonably-large transportation organization.
More people need to make lengthy posts about their cool jobs in the vein of my previous post! I've been waiting with bated breath for the past year to hear about the dreaded "scrum master", "daily stand-up", and "Git merge conflict" from some of the 10× programmers that supposedly frequent this website. Maybe we even have an architect who can complain about his clients' wishy-washiness and scoff at all the pathetic free (libre) attempts to compete with Chief Architect, or a paving contractor who can express his hatred of his local transportation authority's resident engineers and in-house designers in the strongest of terms.
More options
Context Copy link