Author Topic: Exporting custom data linked to graphical objects  (Read 1980 times)

0 Members and 1 Guest are viewing this topic.

SIDESHOWBOB

  • Guest
Exporting custom data linked to graphical objects
« on: November 28, 2012, 02:03:02 PM »
Forgive me for putting (an earlier version of) this question up in another subforum but it got no replies there.

I am trying to think of an efficient way for data to get in/out of my app, which currently stores custom data either in graphical entities or a document dict.

Aims:

1. allow someone to export a spreadsheet for external analysis
2. allow someone to export/import the data into map3d for GIS type analysis

Exporting a csv file of data is easy, the trouble is, how can a user determine which line of data corresponded to which entity in the drawing?  Can individual entities be named/labelled?  And if so, can they be named/labelled in a way that map3d can easily re-join the external spreadsheet to the entities (using object data generation keyed on labels perhaps?)

I'm unwilling to attach to an external database as that brings in more requirements for the user.  Map3d's object data - using adeattachdata - looks great, but is alas not supported in vanilla autocad. 

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exporting custom data linked to graphical objects
« Reply #1 on: November 28, 2012, 03:00:44 PM »
Assuming I've correctly understood your predicament, perhaps look to store the entity handle amongst the data associated with an entity, since entity handles are persistent between drawing sessions.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exporting custom data linked to graphical objects
« Reply #2 on: November 29, 2012, 01:19:00 AM »
Yep your simplest way would be to use the HANDLE string (or if you prefer numbers, the ObjectID, but I'd go with handle instead) as the key column of your DB table.
 
That way if you search on the object's handle through a SQL query - it will be the fastest possible way of getting the data since it would be an indexed search (most DB's would give an O(1) search on that - at worst O(log N)).
 
Also with an external DB you could design the rest of your data to be even more efficient - both speed & size wise. Since you can have relational tables - effectively reusing data between separate entities. And you can also add indexes to any other columns to make searches on those also closer to O(1) time. Though designing the DB might be a very complex scenario - that particular idea was a whole 3 year course for me in university. But the gist can be picked up through some research, e.g. this shows some fundamentals with examples using MS Access:
http://www.deeptraining.com/litwin/dbdesign/fundamentalsofrelationaldatabasedesign.aspx
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Pepe

  • Newt
  • Posts: 85
Re: Exporting custom data linked to graphical objects
« Reply #3 on: November 29, 2012, 06:42:02 AM »
Hi...

Maybe VLAX-LDATA could help you, attaching this way all data you need to the objects, and retrieving them when necessary to the spreadsheet (which path & name you could attach if needed).

Regards.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exporting custom data linked to graphical objects
« Reply #4 on: November 29, 2012, 08:31:30 AM »
I've mentioned it in his other thread. Where I've also implemented a set of routines which do a similar job as the ldata vlax functions: http://www.theswamp.org/index.php?topic=43254.0
 
Seeing as in yet another of his threads he's asking for the availability of some vlax function in Mac: http://www.theswamp.org/index.php?topic=43267.0
 
So using my routines it should be able to get the same effect as those ldata stuff, even on a mac, since mine only uses vanilla AutoLisp.
 
Though this was already discussed in the other thread: The form of his data is making the use of embedded data slow. Thus the easiest way to get it to work faster is to go with an external DB. Otherwise you'd need something like a double-linked dictionary - i.e. each dictionary attached to an entity needs to be listed in a global dictionary so you can search through that for all the entities. Effectively you'd then manually create the index which the DB would have done automatically and much more efficiently.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

SIDESHOWBOB

  • Guest
Re: Exporting custom data linked to graphical objects
« Reply #5 on: November 29, 2012, 10:01:16 AM »
@irneb - thanks for putting 2+2 together from my other threads :-)

Actually the main lesson I took from the mac thread was to decide not to develop for mac, at least not in the near future.  If lots of existing plugins don't work on acad mac I don't want to be one of the first.

I do want to keep the embedded data though as it seems to be the simplest way of keeping data with entities.  It's a bit slower than I'd like but not overly so.  This thread is about finding a way to export that data.

SIDESHOWBOB

  • Guest
Re: Exporting custom data linked to graphical objects
« Reply #6 on: November 29, 2012, 10:08:40 AM »
On the subject of handle strings and objectIDs.

What happens to these when a drawing is imported into another drawing?  Presumably they change otherwise there would be conflicts with the new drawing?

Do you know if it's possible to set up the handle->sql query you describe directly through the map3d interface?  It doesn't seem possible through ADEGENLINK.

Would it work to wrap every graphical entity in my drawing in a block?  That way I could label them all, if acad can cope with 100,000 unique blocks..?

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exporting custom data linked to graphical objects
« Reply #7 on: November 30, 2012, 12:13:22 AM »
To export the data you've got lots of options, at least from lisp. I'm not sure of a standard (or even vertical) command which would allow export of XRecord data though. But you can export quite easily from list to CSV, or to XLS using an ActiveX link to Excel, or even to any DB through something like ADOLisp. Though only the CSV one would work on Mac - the other 2 use ActiveX/COM objects.

As for Handle/ID changing when a DWG is inserted as a block. Yes this does happen, unfortunately I don't know of any way to get around this.

I don't know map at all, and haven't used other AEC verticals that much, so I'm not able to tell for sure if they can work directly with SQL. I'd go with ADOLisp myself - that way I can be sure I know what's going on.

I'd try to steer clear of making so many unique blocks just so you can distinguish them from one another (bloated file size for no reason), and you're not going to get any help from that either since you either need to generate a unique name for each or use unnamed blocks - which give the same problem as Handles do. Why not rather just have another "Key" value in your xrecord - you can thus generate a "unique" code for each - perhaps us a GUID string: http://www.theswamp.org/index.php?topic=41820.msg469380#msg469380
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exporting custom data linked to graphical objects
« Reply #8 on: November 30, 2012, 12:34:43 AM »
I'd suggest if you go the DB route to look into designing using ER (Entity Relation) diagrams. E.g. here's a sample showing how an entity is contained in a unique drawing and has a link to data which can be the same data for many entities.

This would make for a set of 3 tables looking something like this:
 
  • DWG
     
    • Key: Long Integer, Auto-Generated, Unique, Primary Key
    • Path: VarChar, Unique, Indexed
  • Entities
     
    • Key: Long Integer, Auto-Generated, Unique, Primary Key
    • Handle: VarChar, Indexed
    • DWG: Long Integer, Foreign Key to DWG table
    • Data: Long Integer, Foreign Key to Data table
  • Data
     
    • Key: Long Integer, Auto-Generated, Unique, Primary Key
    • Data1: VarChar
    • Data2: Float
    • etc.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.