[LandXML] Re: Electronic Field Book Id

  • From: "David Lofberg" <dlofberg@xxxxxxxxxxxx>
  • To: <landxml@xxxxxxxxxxxxx>
  • Date: Fri, 7 Jul 2006 20:43:55 -0700

This discussion isn’t about software its about data exchange.

 A point in a design file like a 'Station offset' or 'intersection point'
will always remain on a hard drive until it is given to a surveying entity
so it will become real. And when that happens the points go into an
electronic field book and get allocated an EFB ID.

In a Surveying operation points constantly go back and forth between field
books and ANY number of surveying applications - Which is why I came to this
forum in the first place – data exchange.

Yes, I use software applications which handle the link between a point or
string and an observation db of some kind. (Even if in some of these it is
only an EFB pt number which is separate to the project file point numbering,
which can be manually traced in the Field book)  In recent years developers
of surveying software have made it a standard facility that the observations
be linked to the resultant point in the DTM. This is because surveyors need
this traceability for QA purposes, and for better data analysis. If a survey
application does not do this then I certainly would not recommend its use.

I need to transfer this observation ‘DNA’ between Platforms and
applications.

So my original question was not whether I should be doing this because I
know I require it.

My original question was how should I be doing it? What way does the current
landXML format support this if at all.

 

Points from field books don’t have to be ‘Surveyed’ to be in a field book.

Many Cogo calculations can now be performed in the field by the onboard
functionality of the equipment. This is also now a standard.

They are recorded in the Book and can be downloaded into the project file.

Points can also be uploaded into equipment from one software application,
staked in the field, then downloaded into another different application.
This stuff happens.

 

Peter Kistler says ‘The Survey point has the fields needed for recording
historical information.’ – is there a Survey Point element? Or is he
referring to the enumerated type ‘survPntType’.

 

If surveyors stove and squeeze enough industry standard information into
‘description’ attributes or ‘feature’ elements then I can only hope it
becomes part of the schema one day.

 

Anyway for now I'll use the description attribute until someone mistakes it
for something else.

 

P.S. Where is the information that explains what attributes like 'oID'
actually mean.

 

 

David Lofberg

 


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 

Other related posts: