I am going to disagree with placing more information on the CgPoint object from a couple of different perspectives. First, a CgPoint is a COGO point not a Survey point. The Survey point has the fields needed for recording historical information. There are numerous ways to create a CgPoint that have nothing to do with surveying, ie line intersections, station-offset, ... If you want to preserve the information on a CgPoint, the description field can be used. Second, this sounds like an office software problem, not a LandXML problem. The office software should do a better job of supporting LandXML. The office software should also support multiple points with the same PointID. My 2 cents. Regards, Peter Peter Kistler Engineering Manager, Office Software Trimble Navigation -----Original Message----- From: landxml-bounce@xxxxxxxxxxxxx [mailto:landxml-bounce@xxxxxxxxxxxxx] On Behalf Of Kevin Murphy Sent: Wednesday, July 05, 2006 7:45 AM To: landxml@xxxxxxxxxxxxx Cc: David Lofberg Subject: [LandXML] Re: Electronic Field Book Id I would agree with Mr Lofberg. We need to always be able to trace the point ID back to its source. Is it possible to tie the point number to the date or perhaps julian day ? To the best of my knowledge, this would give any point a unique id. I do not work with many data collection packages, but I think most will try to warn you if you use the same point number within a given file. Of course if you use the same file over many days and simply append the next days work to the previous days file, that system might not work so well. I think...a discussion is in order... What say ye Ladies and Gents ??? -K. Murphy Kevin J Murphy, PE,LS Michael Baker Jr Inc 301 College Road East Princeton, NJ, 08540 phone...609-734-7927 fax........609-734-7950 email: kmurphy@xxxxxxxxxxxxxx >>> "David Lofberg" <dlofberg@xxxxxxxxxxxx> 7/3/2006 9:44 AM >>> Does the CgPoint need to have an EFB (Electronic Field Book) ID ? The receiving surveying application must have a reference back to the observation in the field book.(if its worth anything) For example the following lines of Nikon raw data : CO,Nikon RAW data format V2.00 CO,108370 CO,Description:Works as Executed CO,Client:John Doe CO,Comments:Good weather CO,Downloaded 09-Apr-2006 16:38:50 CO,Software: Pre-install version: 1.02 CO,Instrument: Nikon NPL-352 CO,Dist Units: Metres CO,Angle Units: DDDMMSS CO,Zero azimuth: North CO,Zero VA: Zenith CO,Coord Order: ENZ CO,HA Raw data: Azimuth CO,Tilt Correction: VA:ON HA:ON CO, 108370 <JOB> Created 09-Apr-2006 14:11:18 MP,708,,6999.442,4468.979,5.650,STMM MP,715,,7219.505,4625.567,4.962,STJJ MP,731,,7152.246,4732.165,4.224,SS69066 CO,Temp:25C Press:1013hPa Prism:0 09-Apr-2006 14:20:58 ST,715,,731,,1.545,327.4459,327.4459 F1,731,0.935,126.060,0.0000,90.3706,14:20:58 SS,732,40.000,174.908,220.4430,89.4552,14:24:52,SS2 SS,733,1.440,53.693,163.0918,89.5604,14:26:07,SS1 SS,734,0.400,20.388,241.4830,92.4011,14:29:23,NW SS,735,0.400,13.998,236.3158,94.3637,14:29:50,NW SS,736,0.400,,215.5314,93.5526,14:30:21,DHW When reduced within or imported to a surveying application, the observation #736 (ss = side shot) to field code DHW may not get the point ID 736 because that number might already be taken up in the existing dtm/project/pointsdb. It is critical that a point in a project file be referenced back to its observation source. This link should be application independent and therefore cotained within the xml. Consider: The scenario of transfering points between surveying app1 and surveying app2. If app1 does the fieldbook reduction and for some reason points are transferred to app2, the users of app2 should be able to reference the original observation in the field book. It is also worth mentioning that the nikon raw data format allows that the observation field be alpha-numeric. So : SS,736,0.400,,215.5314,93.5526,14:30:21,DHW Could have been : SS,A-736,0.400,,215.5314,93.5526,14:30:21,DHW In which case a unique counter in a points db needs to be allocated anyway. So how do you do this with the current schema? Could someone please set me staight on this. David Lofberg Registered Surveyor N.S.W. Australia -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.8/380 - Release Date: 6/30/2006