Corridor row limit suggestion

[andrew iannello]

With regards to the row limit on corridor plotting. It would be helpful if we could increase the row limit to say 500. The work around is to copy all your survey utilities models to one Model and use unique naming. Well, this process under ISO standards requires consultants to be able to track that data. If you can avoid creating a system to track data (which you have to do when you copy survey to a single model). It would save the industry a few dollars $$$. We could then just lump all the survey models in the corridor list as they are delivered. It's no extra work for us as the incoming data is tracked under normal import processors and data collection registers.

[Owen Thornton]

Keep the original data however you need it. But make temporary copies of it, purely for corridor plotting purposes (renaming/recolouring/restyling to your heart's content, controlled via a map file, say). You can then delete the copies after the plot. The plotting process can be wrapped up in a chain and nobody else needs to know.

[Owen Thornton]

Ideally, a different map file can be created for each job, to copy the data into consistently named corridor models for plotting (as few as possible). That way, all your PPFs can all be setup the same way on each job and they will always just work. The time saving is potentially immense.

(This is the way the Public Works "PW services" example PPFs have been configured and installed in $LIB.)

See also, this vid from Tech Forum 2021: https://vimeo.com/763285491/42d4116c25

[andrew iannello]

We don't live in an ideal world Owen

Could we make the n value customisable, stick it in the corridor settings tab? I mean if 500 lines is too slow to process, then I understand why you might suggest alternatives or work arounds.

You have the issue of historic surveys also to deal with. So, concept work gets expensive, you don't want to be stuck formatting at that phase.

Map files are great, but no one follows the rules.

[Owen Thornton]

There are technical issues with bumping up the number of allowable corridor models and cuts models. The plotting code is not ideal, either. It has a very long history.

The whole idea of the map file is entirely because nobody follows the rules and every job is mind numbingly different. The map file (or whatever process you prefer) will be different on every job, but its intention is always the same: copy whatever random stuff you are given, into a consistent model naming convention (and potentially rename the strings based on how you want them labelled). It is much easier to create a single map file on every job, than to modify all your PPFs on every job. Simple as that.

[andrew iannello]

I understand, I thought it might be difficult.

Well keep it in mind in the future, it would save us time managing data and setting up map files that tend to need massaging. We'll have a few less industry mistakes.