Currently when manually defining a catchments subareas we are only able to hard code in a percentage of the total drainage area instead of the acreage of that subarea (see attached file). This causes us to have to manually calculate the percentage of the total drainage area and input in a percentage instead of just inputting the area of the shape found using the measure area tool and the software calculating the percentage of the total drainage area this subarea represents.
Civil Product Used | OpenSite Designer, OpenRoads Designer, OpenRail Designer |
Jonathan, I agree that it is straightforward to calculate the percentages of impervious and pervious areas, however, it is even more straightforward to just use the measure area tool to find the area of that subarea and the program determine the percentage of the total drainage area for you. In the simplest of examples like you provided below where your drainage area only consists of a constant width roadway with a constant width grass strip behind it makes sense that the thought of a percentage would be easier, however, in all my experience designing drainage I have never come across such a project. Our projects consist of a constantly changing cross section, with large existing areas of land feeding water into the project outside of the proposed project limits that contain all sorts of different land uses. It doesn't make any sense for us to have to do an additional calculation when we could just type the area we already know the size of into the program and it do that percentage calculation for us.
Between the inconvenience of this issue and the time of concentration method our DOT requires us to use not being one of the time of concentration methods available in the software it is hard for us to justify doing our drainage area calculations in OpenRoads, which is what we were hoping to do as we moved into the OpenRoads software.
I appreciate you responding to my post so quickly and you all hopefully taking this suggestion into consideration. I also apologize if I have come across as rude during our interaction, it is just extremely frustrating to have to pull out my calculator and divide the sub area by the total drainage area for every single sub area on a project just to type in a percentage when there is literally an area column right next to the percentage column that is blocked for editing.
The subareas functionality that we currently have followed a pattern that we've seen before, where the land uses were split into percentages, and the Drainage Designer made an assessment of what those percentages were. For example, for a given road cross section which includes a grass strip behind the sidewalk, it's straightforward to calculate the percentages of impervious and pervious areas. Also, the percentages don't vary depending on the distance between two catch basins - assuming that the road cross section stays the same.
Having said that, I can see that if you already know the area of each subarea, then it would be helpful to be able to input it directly.
Jonathan, yes we have used this feature, however these polygons are not easy to manipulate, and the DOT's workspace we use is still in development so the land use feature definitions that assign the correct C value are few and far between, so we prefer to just manually hardcode in the land uses for the time being. On top of that, when doing these calculations normally there is a range of acceptable values for the C value of a certain type of land use based on things like the slope of that land use area, so even a feature defintion that has a specific value tied to it still does not allow us the full range of values we should be able to use which is another reason we prefer hard coding these values.
Is there a reason as to why only the percentage is allowable to be filled in? Even if we were to use the land use polygons I'm assuming the program reads the polygon size to determine the percentage of the total area, why not allow us to hard code in the area size and have the program compute the percentage like it is probably doing for the land use polygons?
Have you considered using the Land Use Polygons functionality? This will read the areas automatically, so you don't have to convert them to percentages.