In SS2 we were able to offset a survey chain horizontally and vertically how would I do this now in SS4 looks like that command does not exist any more
Thanks
Dan
PowerGEOPAK SS10 and ORD
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration
Sorry guys - I finally got back to this and have figured out how to use the tmpl linking code in PowerGEOPAK SS4 08.11.09.878 version - but I believe their is a bug somewhere - I am using the setting files provided by our DOT and they don not use the TMPL code so they have it set to false but when I turned it on (true) the templates would not draw - I found I had to also turn on (true) the linking code for TapeDistance DIST for the template to work with my data see screen shot - Sent this in to support and I am waiting for them to verify it
I do have another question I tried this but could not get it to work
since I know what my dimensions are for my curb I tried to replace a p-code of TBB6R with TBB6 BL TMPL YYY .60 0.0 XXX .67 -0.5 so our surveyor do not need to key it in while in the field - I thought the Substitute Strings could handle it but it looks like the only handles text strings without spaces so it can only replace a linking code or a point code only but not both at once - does any one have experience using the Substitute Strings and verify that it is limited to text elements without spaces
Sorry looks like my image did not post
The codes entered in the field get converted to Linking Codes and are now separate from the CODE as it used to exist in InRoads Survey. If you create an XML Report from InRoads Survey, the SurveyObservation nodes contain an attribute code and its value is the exact field codes entered by the crews or as edited during processing. The XML you can get out of OpenRoads Survey does not contain the codes as originally entered. There is some attribute which contains many of the codes, but it also includes a lot of other data. It would take some fancy XSL coding to strip out the extra data and reconstruct the code attribute value.
I found a spreadsheet that I wrote out the observations report to and found the controlCodes attribute contains the following:
17 1176 TCD TD1 ST TCD1 ST JPT 1176 TCD TD1 ST 0
As near as I can tell, the original CODE would have been
TCD1 ST JPT1176 TCD TD1 ST
How I would ever figure out in XSL code which parts of the first example needs to be thrown out to recreate the second example is anyone's guess.
It is this code attribute value that I can now often pass on to Civil 3D and get survey linework and survey points and even a Civil 3D Terrain Object.
In reality, I'd really need to rework this as Civil 3D requires the JPT to be the last code and does not allow spaces between the JPT and the point number.
The new Linking Codes do not offer me any value in Civil 3D.
One thing that seems to weird to be a coincidence, but before we used InRoads Survey we used an ETI process that used the code C17 as a Joint Point command. I immediately noticed the number 17 followed by the point number when I first looked at the controlCodes attribute.
We use the substitute codes here, but they do have spaces. We use them for link and point codes. For instance, we use the delivered Link Codes from Bentley:
Since we didn't want our surveyors changing field procedures, we added in the substitutions:
Spaces are allowed...you may just need the following config variable set (I need to verify this):
CIVIL_SURVEY_LINK_CODE_IS_SPACE_SEPARATED = 1