[LandXML] Re: Electronic Field Book Id
- From: "Hugh Dixon" <hugh.dixon@xxxxxxxxxxxxxx>
- To: <Peter_Kistler@xxxxxxxxxxx>, <landxml@xxxxxxxxxxxxx>
- Date: Fri, 7 Jul 2006 10:16:52 +1000
Hi,
I also have made negative comments about 'non essential' - as per MY
definition :) - data increasing the size of LandXML files unnecessarily,
however...
There is a need, in some cases to include a history of the data and its
sources. An element that contains a date, time, source and responsible
person, that can be placed against any other element may well be of use
for more than just downloaded data.
The important thing, as Peter says, is that the application support the
data you require.
That makes 4c!
Hugh Dixon
LISTECH Australia
> -----Original Message-----
> From: landxml-bounce@xxxxxxxxxxxxx
> [mailto:landxml-bounce@xxxxxxxxxxxxx] On Behalf Of Peter Kistler
> Sent: Thursday, 6 July 2006 6:42 AM
> To: landxml@xxxxxxxxxxxxx
> Cc: David Lofberg; KMURPHY@xxxxxxxxxxxxxx
> Subject: [LandXML] Re: Electronic Field Book Id
>
> 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
>
>
>
>
Other related posts:
