DXF file - how can "AcDbText" entity with a label text be linked to a geometry entity (AcDbPolyline)? - autocad

I suppose there may not be a precise answer to this question, but perhaps I can at least understand working with DXF files better...
I need to process DXF files (floor plans) and link the label, which is usually a room name, to the entity representing the specific room.
I have checked the DXF file and there seems to be no link between the two entities. The TEXT entity has a unique handle (code 5) and it has a soft pointer to another object (I think to the general block definition - code 330) but that is not it. So my questions would be:
do I assume correctly that the only way in this case is to compare the coordinates of the label to coordinates of the "nearest" geometry object? This is doable but what if there are a few overlapping objects - I could see some potential risks there.
Is there a way to include a "precise" link from a text entity to a geometry entity in AutoCAD or similar tools? Perhaps with the use of some attributes? My knowledge of DXF is minimal at this point so if anyone could point me to some documentation or example .dxf files where such "precise link" thing is included, it would be great.
Many thanks!

Is there a way to include a "precise" link from a text entity to a geometry entity in AutoCAD or similar tools? Perhaps with the use of some attributes? My knowledge of DXF is minimal at this point so if anyone could point me to some documentation or example .dxf files where such "precise link" thing is included, it would be great.
There may well be other ways to do what you want. Eg:
Grouping Objects
Attributed Blocks
Also, AutoCAD has a mechanism called Extended Entity Data which is included in any DXF data file (see the link provided).
AutoCAD provides some tools for working with XDATA and you can also use third-party extensions like CADPower and GeoTools that have an arsenal of XDATA tools. And ofcourse, you can write you own plugins to do what you what.
In summary, you could attach the handle of the TEXT as XDATA to the POLYLINE representing the room. Once you have attached the TEXT as XDATA it will be available in the DXF file and you will be able to parse it and locate the handle of the TEXT element.
It isn't too hard to write a VBA macro to run in AutoCAD that asks you to select the two elements and it then add the text entity handle as the XDATA. Then you are good to go.

Related

How to annotate the area of a polyline in autocad command / macro

Does anyone know of macro or custom command I can make to quickly annotate the area of a polyline in autocad?
I'm doing a project where I need to measure the lot and house size of several city blocks. I've got a drawing going but I don't want to measure and write out the area of each site, that will take to long. I've seen custom commands in the past that quickly do this kind of thing but I don't know how to make my own.
And I'm desperately avoiding doing it by hand one at a time as most likely I will need to make adjustments to my design later on.
The best method I can think of is to utilize the MTEXT command and use a FIELD to link the Area of the Polyline to the MTEXT box.
Type FIELD at the command line, choose Object, select your Polyline and you will see the Area property.
Here is a link on the CADTutor site that covers it a bit more in depth along with a link to a forum post that has this automated via a Lisp routine.
http://www.cadtutor.net/forum/archive/index.php/t-46628.html

Is it possible to programatically create labels in AutoCad?

Our engineering department wastes a great amount of time reviewing drawings for errors. The majority of these problems involve human errors in labeling (ie. two rooms have the name 01-01-00-RM). Our IT department has come up with a partial solution by automation the room names. However, the engineers still have to type this into AutoCAD.
Is there any way to create labels in AutoCAD based on another file (ie. an Excel/CSV document)? Ideally, one would create a group in a layer and enforce that all elements be unique, then have them retrieve their values from a document.
EDIT
Some screenshots of the labels. Note, for company reasons, I can't put full PDF screenshots up.
First image showing compact label next to a camera. This was on a floor plan overlay.
Second image showing the full lable next to a camera. This was in the block diagram
Yes it's possible, there some different paths:
Lisp: very common on AutoCAD environment and allow some basic (and not so basic) automations.
VBA/COM: can be used from inside AutoCAD or by external process, just need to CreateObject("Application.AutoCAD") and program the steps
.NET or C++: in-process automation that allow powerful customization, up to a major remodeling of AutoCAD.
So, depending on your expertise, you may choose different approaches. It may also combine with batch processing via AutoCAD Console.
Find more at http://www.autodesk.com/developautocad and at the blog http://adndevblog.typepad.com/autocad
If the labels were blocks with attributes then you could use the ATTOUT and ATTIN commands in Express tools to export / import them in to/out of Excel. Watch for cell formatting in Excel - eg. numbers like 1/2 turn into dates if you leave the formatting as "General".
Programmatically this is reasonably trivial if the data is structured. An AutoCAD drawing is actually a hierarchical object database so everything in it is addressable, finding it is often the hardest part. If you have an AutoCAD installation handy, have a look into a drawing with MGDDBG to get an idea of the database structure.

Manually upgrading Three.js JSON geometry files from r42 to r55

I have some JSON files that define geometries, as required by r42 of Three.js's JSONLoader class. The files are version 2 of the format.
Is it feasible to manually update these files between versions?
The first obvious difference is that the file is no longer JavaScript, but actual JSON. This was easy to correct for. However the new format has a metadata section, and thirty minutes of experimentation with is isn't getting me anywhere.
I'm seeing problems because the Geometry object's material properties has an empty materials array. The resulting geometry has multiple parts with different materials, as seen in r42.
Does anyone know how I might manually tweak these .json files to work with r55?
I have no complete knowledge how the internals of the format have changed, but here's a couple of hints:
If you have the source object, the best way would be to re-export/convert. There should now also be more converters and exporters to use if your source format is obscure. If the source is unknown, some Googling might be worth it.
metadata section doesn't matter, it isn't used for anything in the loader.
There is no more Geometry.materials. Instead, JSONLoader's callback returns the loaded materials as a separate parameter to the callback. See Migration Guide (r52->r53) for more on that. In fact, the loader interface has changed also in r46.
git log of some example model files (searching for changes there could be your way forward if you really need to manually migrate) suggests that there might be e.g. UV flipping which would be difficult to fix manually but could be worked around in code. But first you'd need to get something to display on screen.
Try dragging the file into the editor, then do File/Export Geometry.
Here is a fix for drag and drop into the editor. Add this code before the drop event in index.html. I tested this in Chrome ( 24.0.1312.56 ), Safari and Firefox in OSX.
document.addEventListener("dragover", function(e) {
e.preventDefault();
});
#mrdoob's answer worked after a few patches to the editor (here and here.)
However it's worth noting that upgrading the files by hand in a text editor is possible, especially if you don't have any UV coords.
Earlier versions did not use JSON -- they were JavaScript files. The conversion is straightforward.
You can either ignore the metadata section, or else port it from the comments into an object.
If you do have UV coords, then they must be mapped differently (I believe an axis is flipped)

Tools to document Core Data Models?

I'm starting a new project with a moderately complex Core Data model, and I'd like to know if there are any tools, within Xcode or external, that help document the decisions I'm taking while I shape the model.
Of course, I could just fire up a text editor.
if you're just referring to use with a doc generator:
you can use the functionality to copy the method/interfaces to the clipboard, paste to a text file which is not included in translations, then document it as usual. as long as it's in doxygen's (or whatever you use) search path, it will be added to the docs.
this could be useful in other scenarios, but that is a more common one.
This tool (Core Data Editor) may be useful...

Boxes linked by 'smart lines' - what's this called ? How's it done?

Terminology question !
In many graphics packages the user can draw a line between two objects (two boxes say) and then when the user moves one of the one boxes subseqently the line moves to keep the (visual) connection in place.
I want to learn more about this functionality might be implemented (really good to find some open source code to read).
So I want to find some terminology for what this type of stuff is called. I saw a reference on stackoverflow to 'wire-based drawing' but that seems to have been an invention of the author rather than a generally used term.
Is there a proper term for this area of graphics software technology ? Any open source libraries that implement it ?
thanks
I believe that most common name is "connectors". You can draw them using pathfinding algorithm (depends on how your objects are represented)
Here is an example of designer that implements what you described.
Diagrams - bloc, flowchart and so on. This type of drawings is usually created by software like Visio and Dia.
Btw, Dia is open source, so you can look at it to see how this is implemented.
These are connectors.
OpenOffice.org implements them. The feature is available in the Writer, Draw and Impress components (the Connectors menu on the Drawing toolbar). However, I have no idea how easy it would be to dig that feature out of their source code. Nevertheless, OpenOffice.org is open source.

Resources