Sometimes when you receive a drawing, the contents can often be far from what you need, but you have no choice but to make the best of it. Such is case when (one instance) Civil3D users have moved labels away from the point, exported to AutoCAD then exploded the resulting anonymous blocks.
The list of file formats that CAD users need to deal with never seems to stop growing. For a long time the ESRI Shapefile was pretty much the exclusive format from ESRI users but it was always an export from the GIS. Now users find themselves receiving folders of content with the folder having a .GDB (GeoDatabase) extension.
In mapping environments, the problem occurs when you receive a drawing that has not been properly assigned a coordinate system. Without a proper system assigned it’s nearly impossible to merge data from other systems or view the project in tools like Google Earth. A glance at the coordinates indicate large numbers that should reflect a known system, not random coordinates.
It’s usually easy enough to draw a coordinate grid on your project in the current coordinate system. But what if you need to draw a latitude longitude or other coordinate system grid. The lines and labels aren’t ortho anymore nor is the spacing the same (or even consistent).
Because of the way IntelliCAD creates a copy of a partial menus content and resource DLL (the icons), then locks that DLL at the operating system level, users of our add-ons that change have to do a special procedure in order to see the new menu items and icons. For example our MapWorks product receives additions on pretty much a weekly basis and while we can update the files in our install folder, that’s not enough as it is on other platforms. Follow this procedure to see the new menu items and icons.
The ESRI Shapefile is a common exchange format with GIS systems and users often receive .SHP files representing contours. However, most of the time the elevation data is not stored on the shapefile geometry, instead it’s a column in the associated .DBF file. This typically leads to multiple steps having to import then do processes to read the attached data to elevate them properly, so why not do it all in one step.
We’ve often said “we don’t mind hard work, it’s unnecessary work that bothers us“. Such is the case in obtaining lidar data for surface generation. From our previous experience the process involved:
- Use a browser to go to a certain government website.
- Zoom and pan around till we found the area of interest.
- Click to select our area and place our order.
- Wait for an email to arrive telling us our data is ready.
- Download to find it’s a massive file.
Sometimes things that should be simple turn out to be (at best) difficult to do in CAD engines. For example the need to draw text along linear objects such as lines, arcs, polylines, etc. Long street names are a good example, if there isn’t a long straight segment for a regular (but rotated) text, what’s left to do.
Most users won’t hit this limit and shouldn’t worry about it until they do. However a handful of our users processing extremely massive surfaces have reported an error message like “System.OutOfMemoryException” and/or “Array dimensions exceeded supported range”.
Legends are a standard inclusion on any civil/survey drawing. A table to describe the graphic symbols and even linetypes are needed. The question is when these table are generated and how. Some users wait until the project is nearly complete then manually draw the tables. Revisions may introduce new symbols that can’t be forgotten. There has to be a better way.