Ne taip seniai buvau parašęs straipsnį "SOS Trimble programinės įrangos naudotojams", apie Trimble *.job darbo eksportavimo į Geodimeter formatą metu matavimo duomenims pritaikytą projekcijos mastelio koeficientą. Kadangi niekas nepadėjo išspręsti šios problemos, į ją toliau teko gilintis pačiam - čia ir pasidalinsiu tuo, ką pavyko atkapstyti.

Mano ankstesniame straipsnyje panaudotas terminas "klaida" nuskambėjo gana iššaukiamai, ypač turint omenyje ilgametę Trimble kompanijos patirtį geodezijos srityje. Tokiais atvejais visada abejoji savimi, tačiau  paskubėjau perspėti kolegas, kad pasitikrintų savo matavimo įpročius ir nepriveltų sisteminių klaidų.

Kaip paaiškėjo,  viskas priklauso nuo programinės įrangos išmanymo lygio, tačiau Trimble dar iki galo neatsiprašysiu, nes galimybių susipainioti yra nemažai ir kai kurie dalykai paties gamintojo nėra apgalvoti iki galo.

Pradėkime nuo to, kad Trimble matavimo prietaisai, kuriuose naudojama Windows CE OS, duomenis saugo binarinio formato *.job failuose. Tai yra, norint perskaityti jame esančius duomenis, reikia turėti programą, kuri skaito binarinį formatą, pvz. Trimble Business Center arba duomenis eksportuoti į tokį formatą, kurį supranta kitos programos.

Kadangi TBC neturiu, darbo failą tenka eksportuoti. Tai galima daryti tiesiogiai instrumente, arba kompiuteryje, naudojant Trimble ASCII File Generator programą. Tiek vienu, tiek kitu atveju Trimble programinė įranga naudoja eksportavimo taisyklių failą, kurio plėtinys yra XSL. Trimble siūlo parsisiųsti daug įvairių duomenų eksportavimo taisyklių.

Svarbiausia, kad šiose taisyklėse ne tik nurodoma, kuriuos laukus reikia eksportuoti, tačiau ir galima atlikti įvairius aritmetinius veiksmus, tai reiškia, kad pradiniai JOB faile esantys duomenys gali būti perskaičiuojami paties duomenų eksporto metu. Tai yra tiek pat lankstu, kaip ir pavojinga.

Kad būtų aiškiau, atsisiųskite žemiau esantį failą:

Failo peržiūrai rekomenduoju naudoti Notepad++ redaktorių, kuris naudoja spalvinį formatavimą.

Visų pirma, reikia atkreipti dėmesį į failo pradžioje esančius komentarus, kurie yra tradiciniai ir aiškiai sako, kad naudojatės eksporto failu savo nuožiūra.

<!-- TRIMBLE NAVIGATION LIMITED PROVIDES THIS STYLE SHEET "AS IS" AND WITH ALL FAULTS.         -->
<!-- TRIMBLE NAVIGATION LIMITED SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY -->
<!-- OR FITNESS FOR A PARTICULAR USE. TRIMBLE NAVIGATION LIMITED DOES NOT WARRANT THAT THE     -->
<!-- OPERATION OF THIS STYLE SHEET WILL BE UNINTERRUPTED OR ERROR FREE.                        -->

 XSL eksporto failas yra iš esmės programa, tačiau nebūtina dabar analizuoti, kaip ji veikia. Atlikime paiešką pagal žodį "Scale" ir programoje rasime tokį fragmentą:

<xsl:variable name="StnSF">
    <xsl:variable name="SF">
      <xsl:for-each select="key('stnID-search', StationID)">
        <xsl:value-of select="ScaleFactor"/>
      </xsl:for-each>
    </xsl:variable>
    <xsl:choose>
      <!-- Don't apply the computed station scale factor to backsight obs - they were used to compute it! -->
      <xsl:when test="(string(number($SF))='NaN') or (Classification = 'BackSight')"><xsl:value-of select="'1'"/></xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$SF"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>

Paryškinta 8-a eilutė iš karto atsakė į klausimą, kodėl eksportuotame faile skyrėsi kontrolinis matavimas aliktas orientavimo procedūros metu ir į tą patį tašką atliktas matavimas įprasto piketo matavimo režimu. Matau Trimble komentarą, bet nesuprantu jo logikos. Toliau formato faile randame tokį fragmentą:

<xsl:variable name="SDStr">
    <xsl:variable name="SD" select="Circle/EDMDistance" />
    <!-- Apply the prism constant, atmospheric ppm correction and station scale factor to the slope dist -->
    <xsl:choose>
      <xsl:when test="string(number($SD))='NaN'">?</xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="format-number(($SD * $DistConvFactor + $PrismConst + ($Atmosppm div 1000000.0 * ($SD  * $DistConvFactor))) * $StnSF, $DecPl3, 'Standard')"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>

Kaip matome, atstumo daugybos iš mastelio koeficiento veiksmas atliekamas 7-je eilutėje (pačiame jos gale). Užtenka panakinti daugybą iš mastelio koeficiento pakeičiant kintamąjį $StnSF į 1.0 ir turėsime atstumą be MK pataisos. Šiuo metu probleminę situaciją Kelprojekte taip ir išsprendėme.

Čia verta pažymėti, kad eksportuotame faile visiškai nematoma informacija apie tai, koks mastelio koeficientas buvo naudotas matavimų metu. Jau įsitikinau praktiškai, kad netgi darbui parinkus LKS-1994 koordinačių sistemą, yra galimybė rankiniu būdu nustatyti jį kokį tik nori, pvz. 1.0000, arba 0.9996 ar panašiai.

Manau, kad labai paprastai šį dalyką Trimble galėjo išspręsti paprastų komentarų forma galutiniame eksportuotame faile. Šiuo atveju, neturint pradinio binarinio darbo failo, vinareikšmiškai tikrai negalima pasakyti, ar atstumai yra teisingai eksportuoti.

Kad būtų dar įdomiau, pasakysiu, kad kituose Trimble eksporto formatuose, pvz. Fieldbook.xsl, mastelio koeficiento pataisa skaičiuojama dar kitaip - pasviras atstumas pirma išskaidomas į horizontalią ir vertikalią dedamąsias, tada horizontaliam atstumui taikoma MK pataisa, viskas vėl perskaičiuojama į pasvirą atstumą ir skaičiavimai tęsiami toliau.

Taip pat liko neatsakytas klausimas, kodėl ėjimas buvo neteisingai suskaičiuotas  pačiame valdiklyje, nors aš peržiūrėjau duomenų failą ir įsitikinau, kad stotyse buvo naudojamas tinkamas mastelio koeficientas - 0.9998. Į šį klausimą dabar jau neatsakysiu, nes kontroleryje atnaujinome programinę įrangą, todėl tikrinti ėjimų skaičiavimą bus galima tik kitą kartą po realių matavimų.

Taigi, išvada yra viena - visada reikia labai gerai išsinagrinėti visą veiskmų seką nuo pradinio matavimo iki piketo paklojimo brėžinyje, kadangi visame procese klaidas galima padaryti net keletą kartų.