Topic: WRITING SCRIPT FILES

[tcopeland]

OK.  I am back working on this file again.  I have noticed that the data is bad but if I were to go back to the script file and do a search for the site I imported and compare it to the original data it is correct.  Then I do a find in ACAD for the same site and notice that the data is incorrect.  What is the deal with that.  I have one site in particular that when I did a find for it I found 11 different locations on the same site all but 1 had bad data, but in the script file it was all correct.   :realmad:

I have the data from the script listed below (three different locations with different cords), followed by the cords listed in ACAD for the same sites I have listed below.

-insert
"Y:\Drawings\Blks\substation.dwg"
2267858.256,16102837.71,0

-insert
"Y:\Drawings\Blks\substation.dwg"
2245349.364,16098645.25,0

-insert
"Y:\Drawings\Blks\substation.dwg"
2241600.828,16264287.05,0

2155540.3269,16172267.2910 - these are the cords where I had 11 different sites located at, but according to the script file they should not all be here.  :ugly:

Any thoughts on this?

[mjfarrell]

verify that the BASE has not been changed in your DWG's that you are inserting as blocks.....
check their origins....sometimes things get moved about

[tcopeland]

If that was the case then they all would be messed up not just a few here and there.  But anyways the center of the block has an insertion of point at 0,0,0

[mjfarrell]

I dont think so...

lets say you have n+1 blocks you are inserting with your script
some number of those blocks insert exactly as you expect them to
some subset of the total has been MOLESTED by someone (accidentally of course) and they issued say
the BASE command, and altered where 0,0,0 is in those files
the UCS command, and altered the origin
or during some other operation, sent the data flying out of view (moved it all), perfeormed a  Zoom Extents and kept right on working 'as if' nothing had happened....and to them it didn't the data was still right there on the screen.

it can and does happen

[tcopeland]

Well riddle me this Batman,  I went to the block that was created and verified if it had been moved etc.  Nothing has been altered.  The problem that I have noticed in prior attempts to get the information in is that some of the block that I am moving now to their correct locations were inserted correctly before.  Since I am just testing all of this stuff for now I am only inserting the same block for multiple locations.  I have not yet inserted any other blocks yet.

Another reason that I know that the blocks have been inserted correctly in the past is that I had generated some SDF for all of our facilities to see how they came in.  And they are all in the correct locations other that a few I now we have bad data on.

Is there a possibility that the script may need to be revised to show a break in the commands instead of running multiple inserts back to back.  If that is the case then what do I need to do to fix that.  If I were to place another return that will end the command and not resume or continue on with the rest of the insertions.

[mjfarrell]

so it's is somehow inserting only a few 'random' instances of the SAME block into locations other than those that you know to be correct?


hmmm

I may be asking to see that data...The Good, The Bad, and The Ugly


or you might try breaking it into smaller groups and identifying the 'bad' ones....


unless they then propagate as other random 'bad' block insertions...

[tcopeland]

Since I can not leave this alone.  I took the exact same script file and inserted into a new black slate drawing with the correct coord zone etc.  I went to check some of the points that wer misaligned earlier and they are all in their correct location.  Go Figure!!  This wouldn't have anything to do with memory or the lack of it would it?

[mjfarrell]

This wouldn't have anything to do with memory or the lack of it would it?

yours, or the PC?   

one would need to benchmark this theory with alternate machines

[tcopeland]

You can tell by the delayed respose that the the answer to that question is both!  

I ran another test to confirm my earlier problem.  I opened a new drawing set all the parameters and then inserted the script file.  All of the points appeared to be in the correct location.  So I then decided to create SDF and then import that into my basemap drawing.  What do you know it all matches correctly!!  I double checked 5 or 6 counties and it seems to be correct.  So why can't I run the script in the basemap to populate this drawing with the facilities I want?  I'm guessing it has something to do with the overall size of the drawing and also I still believe the amount of RAM I have available.

On another note how can I have the SDF show up as a block or something that would look similar to what the block is, i.e. a filled triangle for a substation instead of the default square block that shows up when you insert the SDF?

I forgot about how to stylize.  I think that brain has decided to shut down!  :kewl:

[tcopeland]

Another question regarding file size.  What is going to be better for keeping file sizes smaller, SDF or SHP files?  I was just wondering if the size of my basemap is rather large and has a lot of shape file information in it, would it be better to convert the SHP files to SDF or does it really matter?

[mjfarrell]

you may want to break the data down into logical divisions in separate drawings, all attached as source files...
yet one would only query what one needed for that map...
or one might look into Data connection to SDF format..however in the end your BASE map may actually need to be comprised of multiple  source files, that you run queries against to get the other types of maps you need through use of the Map Book Query operation.

[mjfarrell]

alternately you might try to slice this 'facilities' grouping a little thinner into more discrete types and keep those that are most alike in unique files...
by voltage/type/function should that provide enough division as to keep the data size manageable,  in the long term you still may need to divide the data in a logical fashion