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.
When we were approached to add a Catchment Report tool to our Civil3D tools package, we were pessimistic at first, since the API exposes very little about catchment objects. However, if there’s one thing we have plenty of it’s determination and after some experimentation we found a way to collect the necessary data. The results turned out better than we initially hoped.
A common request in Civil3D is the ability to add station and offset values to CogoPoints placed along an alignment. Since this is not a built-in ability we approached the problem and found a very good way to do it. Also, since Civil3D users expect dynamic results, we added reactors so that if the points are moved, the station offset values update instantly.
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).
If you receive a drawing from a Civil3D user, there is a possibility it contains CogoPoints that appear locked. You can’t move them, you can’t rotate them, etc. Since you don’t have the Survey Database you can’t unlock them like the original creator did. If this happens to you, read on.
Like a lot of things in Civil3D, it is possible but not easy to do. This post is an attempt to provide a step-by-step procedure on how to add additional properties to AeccCogoPoints.
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.
The process of importing contours from shapefiles is actually a two step process, since the results from Autodesk’s MAPIMPORT command does not elevate the resulting polylines. This is a step-by-step procedure on how to take a shapefile of contours to elevated polylines in AutoCAD (Map/Civil3D).
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.