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