Author Topic: WRITING SCRIPT FILES  (Read 14524 times)

0 Members and 1 Guest are viewing this topic.

tcopeland

  • Guest
WRITING SCRIPT FILES
« on: October 13, 2009, 05:52:41 PM »
This may be in the wrong forum here but it does have to do with spatial data.   :|  Feel free to move this if it does need to go somewhere else.

I am trying to write a script that would insert a variety of points.  These points are coordinates for different facilities; substations, towers etc.  What I want to do is take the data that I have and insert a block for that particular set of facilities.  Within the block I have defined a set of attributes that would tie back to a database, spreadsheet etc.  What I have found is that I can not get the info to fall into the correct location for the attributes.

This is what I have done:
-insert "Y:\Drawings\Blks\substation.dwg" 10000000.00,1000000.000,0 1  0 05 abc Substation

The bolded letters above is the attribute information.  If I do the insert command as I have listed above the bolded section all goes to the first attribute and then the next insert command goes to the second attribute and so on ..... until they are all done.  NOT HOW I WANT IT TO WORK!

If I were to separate the attributes out listing them below the insert command it all works fine.  But I really don't want to do that for a thousand entries.  Is there a command or a certain way to force the script to do a hard carriage return in a line sequence?  I know that a space acts as a return but it does not work while trying to insert multiple blocks with attributes.  So is there another way to accomplish what I am trying to do above, or is there an easier way to get the same result.

Thanks for the help,

Bob Wahr

  • Guest
Re: WRITING SCRIPT FILES
« Reply #1 on: October 13, 2009, 06:35:04 PM »
-insert "Y:\Drawings\Blks\substation.dwg" 10000000.00,1000000.000,0 1  0
05
abc
Substation
-insert "Y:\Drawings\Blk...

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #2 on: October 14, 2009, 08:34:37 AM »
If I were to separate the attributes out listing them below the insert command it all works fine.  But I really don't want to do that for a thousand entries.  Is there a command or a certain way to force the script to do a hard carriage return in a line sequence?
-insert "Y:\Drawings\Blks\substation.dwg" 10000000.00,1000000.000,0 1  0
05
abc
Substation
-insert "Y:\Drawings\Blk...

I have tried that and it does work but that is not going to be helpful for the amount of data I would like to bring in.  I would need to then re-write all of the text from the text file to do what you have listed above.  Is there another way to get the same results?  Is there a way to force the script to recognize the attributes or is what you have shown the only way to accomplich this?

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #3 on: October 14, 2009, 08:46:28 AM »
Todd,

This looks like a job for your Description Key Sets and the additional point attribute method we worked out.
Don't insert these as blocks with attributes, so much as insert them as Points.
Then when that is done, save the file, and then create your Database links. 
You will find that by using the database linking, that you won't have to attach all that information to the points/blocks that represent those facilities; as attributes, as it will all be available via the database connectivity.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #4 on: October 14, 2009, 09:21:16 AM »
I didn't stat that these points are not points that have survey codes, these points were derived from a lat long coordinate then converted into a grid format.  I was trying to use MAP to insert the points through the insert command then the plan was to link them using the database connection method you described.  I could go the route that you are referring to.  I was trying something simple to just insert a block with attributes and then wanting to tie that info to the database.  It didn't take long to write the script it was the beating I took afterwards trying to get the attributes to show up. (there needs to be a smiley with tweety birds for that kind of beating)

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #5 on: October 14, 2009, 09:46:34 AM »
the point is they do not have to be 'SURVEY' points in order to make the process work as described.
they have coordinate pairs, and they have attributes...therefor they are perfect candidates to use points, and description keys on...
then you wouldn't have been beat upon by scripting in order to get all those hard returns in the script in the right places to match your block attributes...

just a comma delimited file...that you would treat as if they were 'survey' points and leverage the power of C3D first, and then apply MAP to the resultant....
Be your Best


Michael Farrell
http://primeservicesglobal.com/

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #6 on: October 14, 2009, 12:58:19 PM »
Upon pondering this a little more; and taking the fact that C3D objects (this includes Points) can not be queried by Map, I must revise this suggestion as follows:

I would use your file to insert a very simple point object, say something like a Point number label inside a circle.
I say this because; after you insert your points to get this Circle with text inside it, your next step is to then Export to Autocad
Open that file
Create a Link Template
Then you use the Enclosed Text method of creating your database links using the unique identifier (Point Number) to create the link template. In your case it might be that you use one of your attributes, or the description as the unique identifier.
No Script or Description keys required.

(you might also try this with the Description Key method, and see if exporting the data to SDF proves to be more or less effective)
Be your Best


Michael Farrell
http://primeservicesglobal.com/

Bob Wahr

  • Guest
Re: WRITING SCRIPT FILES
« Reply #7 on: October 14, 2009, 06:52:14 PM »
I'm not trying to disagree with Michael.  Map/C3d/et al are his bailiwick and I would definitely follow his advice.  You can very easily modify your current script using something like notepad++(http://notepad-plus.sourceforge.net/uk/site.htm)  Just replace all of your spaces with hard returns.  Judging by the line you posted, it should work fine.  Do the replace like the attached.

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #8 on: October 14, 2009, 07:13:33 PM »
no problem with alternates Bob...that's one of the strengths of autocad...
given that his destination with the data is GIS, I think the last process would serve his needs best...combined with the tools he has to work with C3D/Map.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #9 on: October 15, 2009, 11:07:56 AM »
I'm not trying to disagree with Michael.  Map/C3d/et al are his bailiwick and I would definitely follow his advice.  You can very easily modify your current script using something like notepad++(http://notepad-plus.sourceforge.net/uk/site.htm)  Just replace all of your spaces with hard returns.  Judging by the line you posted, it should work fine.  Do the replace like the attached.

no problem with alternates Bob...that's one of the strengths of autocad...
given that his destination with the data is GIS, I think the last process would serve his needs best...combined with the tools he has to work with C3D/Map.


I have tried both methods as listed above.  I did try your way first Michael, that did work but when I went to import in the SDF file it did not place the information incorrectly on the drawing.  It appeared that it wasn't scaled quite right, or something.  The points basically were extended beyond our service area.  Not good!  So I went to the next method.  I had to do a little work with the original file but i was able to import the blocks with the attributes.

Thanks for all of the help.  I plan on trying to export out the block data as SDF and re-import the info to see how it differs from the previous import.

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #10 on: October 15, 2009, 11:13:38 AM »
and your units and zone were set to???

and you used this method here: http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=7146338&linkID=9240857

Issue


In Autodesk Map® 3D, you want to access a drawing with Civil objects that were created with Autodesk® Civil 3D®.

Solution


To access Civil objects in Autodesk Map® 3D, you need to export the data to SDF format from Autodesk® Civil 3D®. Follow these steps:

1.  In Civil 3D, on the File menu, click Export > Export to SDF.
2.  In Map 3D, Display Manager, click Data > Add Data.
3.  Connect to and add the exported SDF to the map.
?
« Last Edit: October 15, 2009, 11:21:46 AM by mjfarrell »
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #11 on: October 15, 2009, 11:21:04 AM »
Units for the points are in UTM83-14F and the drawing was set to the same coordinate zone prior to importing the points unsing C3D.  When I created the SDF it asked what zone and that was also the same.  When I inserted the SDF into MAP the zone was set to the same for the SDF coming in and also the drawing.

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #12 on: October 15, 2009, 11:25:15 AM »
in otherwords, the output, and the input file were both set to the same, and somehow the data STILL got scaled?
this might be something you need to report to your dealer so they can escalate a support/bug report for you...

Let's see what your other tests reveal.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #13 on: October 16, 2009, 08:15:17 AM »
Well after a day of testing and confusion, I have found that I have some bad lat long data! :roll:  It does appear that both the SDF and the points that I inserted using the script are lining up.  So i will be able to use either method to get the points in that I need, when needed.  8-)

Thanks for the help.

P.S. thanks Bob for the link to notebook++ that is a very handy tool to have in the toolbelt!!

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #14 on: October 16, 2009, 09:16:32 AM »
OK, that was one of the suspects....good to know it isn't just 'scaling' data without a cause.   ;-)
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #15 on: October 22, 2009, 10:13:25 AM »
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

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #16 on: October 22, 2009, 10:39:15 AM »
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
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #17 on: October 22, 2009, 11:04:57 AM »
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

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #18 on: October 22, 2009, 11:18:54 AM »
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
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #19 on: October 22, 2009, 11:38:10 AM »
Well riddle me this Batman,  :lol: 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

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #20 on: October 22, 2009, 12:10:49 PM »
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...
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #21 on: October 22, 2009, 12:18:34 PM »
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

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #22 on: October 22, 2009, 12:48:53 PM »
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
Be your Best


Michael Farrell
http://primeservicesglobal.com/

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #23 on: October 22, 2009, 02:14:58 PM »
You can tell by the delayed respose that the the answer to that question is both!  :lmao:

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:
« Last Edit: October 22, 2009, 03:03:01 PM by mtc49 »

tcopeland

  • Guest
Re: WRITING SCRIPT FILES
« Reply #24 on: October 22, 2009, 02:28:06 PM »
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

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #25 on: October 22, 2009, 04:47:47 PM »
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.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: WRITING SCRIPT FILES
« Reply #26 on: October 22, 2009, 05:52:28 PM »
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
Be your Best


Michael Farrell
http://primeservicesglobal.com/