En:
I have encountered a difficulty with modelling of topsoil removal. Being used to PowerCivil workflow, I liked the ability to import a table with topsoil depth at certain chainages as an .eav file during end area volumes analysis - it was quick, it behaved as expected and was easy to change when new data appeared. With OpenRoads I have arrived at two different ideas of how to model it. Both are bothersome, and I have a hard time trusting, that they are not going to mess with the rest of the model. First idea is to add overlay/stripping components to the template - but for templates with multiple end conditions, ditches, additional service lanes etc. it is just too much. Templates become too heavy and complicated. Also, those additional elements might not work well with cut/fill values. Other idea is to model topsoil removal as a separate model, with a template including overlay/stripping component only, using extends of the main model to control width of topsoil removal. This is also bothersome since it requires us to create additional models and update them whenever there is a change in plan.

Could you please point us to an easy and efficient method of modelling topsoil removal? A way to import a table of depth at chainge would be perfect. Or maybe even suggest to developers a need of adding a dedicated tool for that in future versions?

PL:

Napotkałem trudności z modelowaniem zdjęcia warstwy humusu. Będąc przyzwyczajonym do pracy w PowerCivilu, lubiłem to, że grubości humusu można było zaimportować tabelarycznie w pliku .eav podczas raportowania ilości - było szybko, humus zachowywał się tak jak się tego spodziewałem i łatwo było zmienić dane. Teraz, w OpenRoadsie mam dwie metody na to modelowanie humusu, ale obie są kłopotliwe i wciąż nie jestem gotowy uwierzyć w 100% że zamodelowane tak humusy są poprawnie uwzględnione w raportach robót ziemnych. Pierwszą z metod jest dodanie komponentów "overlay/stripping" do szablonu modelowanej drogi. Kiedy szablon zawiera wiele "end conditions" takich jak rowy, pasy technologiczne itp. to modelowanie tego w taki sposób sprawia że templaty są bardzo ciężkie i skomplikowane. Poza tym nie mam pełnego zaufania czy te elementy nie psują czasami obliczenia robót ziemnych. Drugim pomysłem jest tworzenie osobnego modelu zdjęcia humusu, z templejtem zawierającym wyłącznie overlay/stripping i sterowanie jego szerokością na podstawie zakresu modelu głównego. To również jest kłopotliwe bo wymaga tworzenia dwóch osobnych modeli dla każdej drogi i pilnowania ich aktualizacji po każdej zmianie drogi w planie.

Czy mogliby Państwo wskazać prostszą i bardziej wydajną metodę modelowania zdjęcia humusu? Idealna byłaby możliwość zaimportowania tabeli grubości warstwy w kilometrażach. Może dałoby się zasugerować deweloperom dodanie jakiegoś narzędzia do tego w kolejnych wersjach ORD?