Hi Neil,
"In my experience there are many times when it
> is necessary to examine the original topography data, whether to verify
> the accuracy of a DTM "
Can you clarify? If the point data was used to build the model it will be
part of the model and it seems to me that you can't do a meaningful
computation that uses that data to check the model.
"to glean information about points that were not used to
> build the surface."
I have not specifically said you shouldn't have these points in the
database. My major concern in reducing data is the NS points shot purely to
establish level at a location.
If you wish to check the quality of a surface you should shoot points which
are not added to the surface and compare them with the level predicted by
the surface. CADApps wrote a program to do this years ago and sell it as
part of its Land Toolbox Suite.
--
Regards,
Laurie Comerford
www.cadapps.com.au
"Neil W" wrote in message news:421b4852$1_2@newsprd01...
> If I may interject an opinion about removing points from the database:
>
> While your argument for reducing the size of the database to improve
> performance has merit, I would think that there would be stronger
> arguments for keeping them. While the DTM does provide a means to obtain
> the spatial data that was used to create it, that data is subject to
> change and could be lost should the DTM be edited. In my experience there
> are many times when it is necessary to examine the original topography
> data, whether to verify the accuracy of a DTM or to glean information
> about points that were not used to build the surface. While the topo data
> can be recovered from the survey data files, it would be a relatively time
> consuming effort to re-import them into the point database, depending on
> point numbering shemes.
>
> I agree that database performance is an issue, particularly when Land
> Desktop has to refresh the points groups, but the convenience of having
> the data readily available when needed offsets the loss of performance in
> my experience. Ideally we would like Land Desktop to be more effiicient in
> handling the point database so that we would not even have to consider
> this issue.
>
> Your experience and insight has been a valuable resource Laurie. Thank you
> for the time you invest in sharing it. I will watch for your reply as to
> how you deal with these issues.
>
>
> "Laurie Comerford" wrote in message
> news:4218f15c_1@newsprd01...
>> Hi Don,
>>
>> It's very simple.
>>
>> Keep the data in the drawing as small as possible to:
>> a) avoid cluttering your mind with superfluous data
>> b) speed up AutoCAD which slows down significantly as the drawing size
>> goes up.
>> c) avoid the need for huge amounts of drafting effort to ensure that
>> the
>> text from the points does not overlap.
>>
>> A Point Object displaying PtNo, Elev and Desc can be over 1300 bytes. so
>> 1,000 points gives 1.3Mb etc.
>>
>> As I've often indicated here, an A1 plot with more than about 200 points
>> will be effectively unreadable.
>>
>> Q1
>> Most surveyed points are there merely to enable level prediction for
>> purposes of design. Once you have combined the data from these points
>> into
>> a DTM the data from an individual point is unnecessary. If you need it,
>> you
>> can get the level from the DTM.
>>
>> Even the Access database slows down as you increase the number of points
>> in
>> it - so if the only purpose of the point is to build the DTM, why clutter
>> the Points Database with it.
>>
>> Associated with this is the capability of the human mind. There will be
>> very few people who can use the data from more than 4 or 5 points
>> simultaneously and get meaningful information from them. Instead, some
>> form
>> of amalgamation - or summary of the points becomes necessary - we join
>> centreline points with lines, we join surface points into a DTM and use
>> different methods of displaying the information in the DTM.
>>
>> Where you are joining points with a string (figure, polyline) - once the
>> join is made the string represents the information and the raw data of
>> the
>> points is superfluous.
>>
>> I know that many users do not accept these arguments - instead work in
>> drawings with huge amounts of useless data making wonderful use of Layer
>> Off
>> and Layer Freeze and Xrefs of huge drawings using serious hardware to
>> cope
>> with it.
>>
>> These practices probably arise from the training courses in AutoCAD which
>> on
>> the whole are orientated to Mechanical/Architectural drafting where the
>> data
>> quantities are trivial and data management is not part of the course.
>>
>>
>> --
>>
>>
>> Laurie Comerford
>> CADApps
>> www.cadapps.com.au
>>
>> "Don Reichle" wrote in message
>> news:4217f5e1_2@newsprd01...
>>> Hey Laurie;
>>>
>>> In reading your 02FEB2005 reply to Jeff Mishler re. adding Points via
>>> VBA
>>> you wrote the following:
>>> In the main, for me a point is source data for:
>>> 1 building a DTM - should never be in the points database let alone
>>> the
>>> drawing.
>>> 2 guidelines for drawing strings like kerbs etc. should never be in
>>> the
>>> drawing
>>> 3 location of specific things like trees, bench marks etc. should be
>>> in
>>> drawing as needed.
>>> 4 setout points. Create at end of project and should be in plots
>>> provided to setout surveyor
>>>
>>> I was going to reply there, but thought that you might not get round to
>> that
>>> old a post.
>>>
>>> I'm interested in how you chose to adopt this philosophy, because Points
>>> 1
>> &
>>> 2 (no pun intended, well maybe a little one) I have seen almost the
>>> direct
>>> opposite here in the Western US.
>>>
>>> In regards to Point 1 - Do you import AutoCAD points with elevation for
>> use
>>> in the DTMs? All of the Field Topo points from Data Collection go into
>>> our
>>> Points.mdb files and are subsequently used in an editable Point Group in
>> the
>>> EG Surface.
>>>
>>> In regards to Point 2 - Your firm's fantastic new app known as Stringer
>>> looks like it places the breaklines directly into the DWG, or did I not
>> pay
>>> close enough attention to Shane's narrative on the video? We normally
>>> use
>>> either a form of fieldbook app, or just play connect the Data Collected
>>> Points with a 3D polyline that identify hard fault lines for the EG
>> Surface.
>>>
>>> In regards to Points 3 & 4 - I think you would find whole-hearted
>> agreement
>>> here in the States.
>>>
>>> And I'm not looking to pick a fight with you, I am truly interested in
>>> finding out what led you to adopt these procedure. I'm guessing that
>>> Point
>>> Protection may have something to do with Point 1.
>>>
>>> --
>>> Don Reichle
>>> "King Of Work-Arounds"
>>> LDT3 - SP1/CD3 - SP1
>>> On WIN2K SP4
>>> Dell 1.6 Ghz P4
>>> 512MB RAM
>>> NVIDIA 32MB AGP
>>>
>>>
>>
>>
>
>
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")