Through the Interface

21 responses to “What would you use AutoCAD I/O for?”

1. 

   James Maeding

   November 3, 2014 at 4:53 pm

   Kean,
   There is a question that comes up a lot - where is this file xreffed?
   That is asked because someone wants to delete, split, or rename the file. On top of that, Civil3D allows labeling of xreffed civil objects, and the labels erase themselves if that object in the xref does not resolve. Also, most places do not want some data management prog controlling their files. So I did a prog that catalogs the xref trees for files in a folder. It also catalogs files xreffed from outside the folder if it encounters them. Then it can show where files are xreffed, and allows renaming and fixing of the paths where xreffed.That data collection takes a couple hours for say 40,000 files. I think Autodesk is missing a ton of opportunity on tools that do this kind of thing. The thing is, I have to send Autodesk the file to scan, and info on the folder structure where it sits so found xref paths could be resolved. So the time it takes to send a file and process through IO must be less than doing it local, or its not worth it. Are you suggesting the thing to balance that would be not having to use a seat of acad and use IO instead? As a cad manager, I must know dependable pricing before I spend time making a prog using it. Part of the risk is that tool relying on strong internet speed too. So you really have to give us a decent idea of how available the service is, and what kind of wait times does autodesk consider reasonable before the processing even begins on their end. I like that Autodesk is opening their eyes more to batch processing. They need to write tools that require it, then could sell the service better.

   Reply
   1. 

      Kean Walmsley

      November 3, 2014 at 5:10 pm

      Thanks, James. A great kick-off for the discussion. 🙂

      Some heavily data-centric operations will be better run where the data resides: so if you're working on a set of 40,000 drawings stored in S3, AutoCAD I/O would be a great choice. If they're on your local network, you'll probably want to process them there.

      Sometimes it's not necessarily about time, but about freeing up local resources. Cloud-based rendering is a great example of that.

      Yes, cost will certainly be an important factor for many applications: some people will only want to invest once that's clear, but many independent software developers will prefer to bet on being able to pass the cost on to their customers once they know what it is (with some additional margin compensating them for their value-add, of course).

      We do have a couple of key internal services depending on AutoCAD I/O right now, with more coming on line. So yes, we're learning a lot about scaling and availability from those. I'm confident we'll be able to meet the needs of external services, too (which I'd generally expect to scale more modestly, with the occasional runaway success leading to a spike in demand).

      Kean

      Reply
   2. 

      Khoa Ho

      November 3, 2014 at 5:45 pm

      James/Kean,

      If you would like to use local/remote scripts to run the local/intranet web service rather than remote AutoCAD I/O web service, consider .NETScript for AutoCAD. I had it on demo last year and will have it in better demo after AU 2014. Local I/O is better than remote I/O to process large drawing files. Remote I/O is better for deployment on client side.

      Other potential Activities of AutoCAD I/O are:

      - Drawing generation from client hosted database (local or remote).

      - Drawing entities and attributes/texts interaction from internet resources.

      - DWG import/export with other CAD file formats.

      Reply
2. 

   Dave Wolfe

   November 3, 2014 at 6:58 pm

   Object enablers

   Reply
3. 

   Dave Wolfe

   November 3, 2014 at 7:00 pm

   Vertical/custom object support really has to be treated as a first class citizen, rather than an add-on.

   Reply
   1. 

      james maeding

      November 3, 2014 at 7:25 pm

      Surely the standard ones are operational on the adesk end. That is very tricky though, as sometimes drawings become unstable when enablers are there. So you must know more about the original environment to be handled the same. Assume the OE's will be there, forget about custom environment handling.

      Reply
      1. 

         Dave Wolfe

         November 3, 2014 at 7:34 pm

         I agree with the stability aspect. Being in the plant3d world, that product gets left out of the loop of "standard." I was hoping for the current Autodesk products to be supported.

         Reply
         1. 

            james maeding

            November 3, 2014 at 9:22 pm

            is that the new landscape architect tool?? ha ha

            Reply
      2. 

         Albert

         November 3, 2014 at 11:59 pm

         Right we have ACA, MEP, Civil3d and Plant3d OEs currently available on AutoCAD IO. We will have Advance Steel OE there soon.

         Reply
4. 

   Adam Reilly

   November 3, 2014 at 9:32 pm

   Could I/O be used for a catalog service?
   Say, I want to catalog my companies details, but I don't want to have to make pdf's of them every time one (or more) gets updated. I want to have a small webpage on the local server that dynamically builds a catalog based on the file structure, and can give me a thumbnail and link to the cad file, or pdf/dwf of the file to be opened and viewed.
   I would ideally like to be able to only have the dwg files and have the image versions generated as needed.
   In this case, it seems like I/O would require putting the dwg files online, or at least sent to I/O during processing.

   Reply
   1. 

      Albert

      November 4, 2014 at 12:04 am

      Yeah, I think this is nice scenario that AutoCAD IO can easily support. You would need to make your DWGs available for processing but they don't need to live online permanently.

      Reply
   2. 

      james maeding

      November 4, 2014 at 5:10 pm

      In my experience, that will be too slow if you want dir structure figured out and images created new every time. Its better (and maybe what you meant) to have some database with file modified times so you can only update the ones needed. You can also use a .net filesystem watcher object to see when files change in real time and react to that. Those two parts seem better to run locally. But I see the web page idea, where a seat of cad is maybe not even installed. Pricing on this seems odd though, as you would have to have some kind of payment system. And I can say the whole cloud credit system has frustrated most cad managers I know so far as its user based, not company based. You don't want to sprinkle salt on that wound even more.

      Reply
5. 

   Tilo Pfliegner

   November 5, 2014 at 1:05 pm

   Could we do computationally expensive automatic point cloud (pre-)processing (e.g. feature extraction) on AutoCAD I/O?
   Where should the point cloud data ideally reside to widen the bottleneck of accessing the potentially massive amount of point cloud data?

   Reply
   1. 

      Kean Walmsley

      November 5, 2014 at 9:00 pm

      It might be possible, but the amount of data to transfer or co-locate could well be the dealbreaker for this scenario. I haven't done extensive profiling of this kind of application, but I would think that as we're probably talking about GBs of data, it would need to be in the same datacentre - or have a very fast connection to it - for processing to be done in a timely fashion.

      Kean

      Reply
      1. 

         Tilo Pfliegner

         November 6, 2014 at 4:17 pm

         Right, this would only make sense if only the raw (and relatively lightweight) scan data would be uploaded and the whole processing tool chain would then run on that data, i.e. file format conversion/indexing, registration, feature recognition, but this is probably a bit beyond the scope of AutoCAD I/O... 😉

         Reply
         1. 

            Kean Walmsley

            November 7, 2014 at 7:08 am

            I was interested by the overall problem of "where best to co-locate large datasets", so checked in with the AutoCAD I/O team. The advice I got from Albert made a lot of sense. Ideally (and it's not clear this is easy, of course) the point cloud processing logic would be separate from AutoCAD, so you would run it independently (co-located with your data, possibly behind its own web-service) and pass the extracted feature data etc. as JSON to a CRX inside AutoCAD I/O for the DWG-related activities. This doesn't necessarily support the situation where you work on point clouds linked into DWGs, of course, but it gives you a sense for the idealised scenario.

            Kean

            Reply
6. 

   Massimo Cicognani

   November 8, 2014 at 8:25 am

   Hi everybody,
   I strongly believe the key factor for large data handling is the location of the data itself. For some lucky realities, this may not be a problem. If I were the IT manager of a large global company, I'd have high speed connection in all of the company's sites and I'd use this opportunity to distribute my internal application an let them run with these new API along with some cloud based distributed file system, and why not, powerful caches all around, since my budget would allow it...

   But I think this scenario would remain reserved to higher budgets for many years to come, especially if you live in some country where high speed connection are still missing at all.
   But I understand Autodesk has to think for a longer stretch of time ahead, while the rest of us has to work with present resources.

   So, to give you a signal from the street, and from the present time, I'd say that most of the tasks can be accomplished locally with a very limited resource investment. Actually, I have already on place a sort of remote services plug-in, where 'remote' is one free workstation, and if you dedicate a workstation to this task (but it's not required, any unused workstation would do), stripping away expensive graphics card and multiple monitors, you'll have a very performer remote service working at wire speed.
   To tell you the true, I don't cover the anti-malware service, but I didn't know dwg files were at risk... I'll have to fix this... 😐

   I believe that in the short term, AutoCAD I/O must be thought as a global interconnection service, a single place where company wide applications can be centralized and that offer the same service to multiple site, not necessary of the same company, but of a few that must collaborate.
   What about a centralized document management? The data flow would be minimal for inquiries and files flow may be easily optimized and locally cached.
   What about a worldwide service that will notify a list of subscribers when a drawing is changed? This one may be for AutoCAD360 API's, but the two things may merge in the future, who knows?

   Reply
   1. 

      Kean Walmsley

      November 10, 2014 at 7:16 am

      I absolutely agree: location of data is critical when dealing with larger amounts of it. If the data is all contained in the DWG, then this will certainly be a key point for AutoCAD I/O. But if you're actually primarily using data from elsewhere and DWG is a small part of your system, then there's less to worry about (your heavyweight processing should be co-located with the data and then talk to AutoCAD I/O for all things DWG).

      All of this implies a different way of thinking about applications, of course (and not be appropriate for everyone).

      We're working hard on making sure malware isn't a problem for AutoCAD data, so the need for a scanning service is somewhat speculative.

      Kean

      Reply
7. 

   Rod

   November 10, 2014 at 1:08 am

   Kean,
   I think the functionality of Autocad MAP query drawings would greatly benefit from I/O.
   For example the data for government infrastructute assets. Data could be kept by the owner in a password protected area. An area or areas could be requested by the user or client.
   The relevant objects would then by queried into a new drawing. As a base
   In my state the infrasturcture data is broken down into 300 1.2 x 1.6 km DWG files. We have a password protected URL where we can download the most current information. We programatically download and unzip any DWGs that have been updated each fortnight.
   When we beging a new drawing we query in the releveant drawing objects to start as a base.
   We could simply query the relevant areas of work (through I/O) to create our base drawings.
   Then at the end of the project we could subimt our "Work as executed plans" that would become part of the dwg data available for query/download.

   Reply
   1. 

      Kean Walmsley

      November 10, 2014 at 7:36 am

      Interesting - I assume you'd use it as an aggregator/DWG builder rather than a storage service (which AutoCAD I/O is not, of course). Seems like a very good use for the service, assuming you have the needed Map bits.

      Kean

      Reply
      1. 

         Rod

         November 10, 2014 at 9:37 am

         Yes assuming you were using a cloud service. You would probably keep the dwg files tiled (maybe a spatial filter as well) and also keep some of the data in a database (GIS).
         The service looks up the location of the relevant data. Downloads the relevant DWG tiles, extracts the relevant information (by area and property) and creates the drawings.
         Usually local governments keep track of their infrastructure (or would like to) and would prefer to share their data (where possible) to keep the price of planning and design low.

         Here are some examples of current projects and how they would benefit from this service.

         To upgrade 500 signs to a new national standard.

         To assess and upgrade 1000 bus stops for wheelchair accessibility.

         Assess 50 black-spot (accident prone intersections)

         Reassess the lane design of 100km of road (done when it is about to be repainted anyway)

         The service could also be used on the return trip to assess that the drawings conform to standards and break them down so that the information can be inserted back into the relevant DWG tiles.

         Reply