WOW! this hits the mark and has been forwarded to the afore mentioned
engineering firm, along with all (5 years of them, anyways) postings
mentioning the word AutoCAD-  TY TY TY!  no need to SUM at this point, yours
is the sum.   When we get our firm's suggested standards and SOPs, I will
post them.  That may take several months.

William "Woody" Woodruff
Zoning Administrator
Charter Township of Union, Isabella County, Michigan
-84.80947000 43.61095100
2010 S Lincoln Rd, Mt. Pleasant, MI  48858
(989) 772 4600 EXT 41
Visit our web site at http://www.geocities.com/ctuzoning/index.htm


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 16:11
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: MI-L AutoCAD Specs for Electronic Submissions to
Municipality (long)


Our gold plated but oh-so-effective GIS staff is standing by to assist
anybody struggling with these issues.  Feel free to contact me <grin>.
(Seriously, we do this for a living, at least some days).

As you note, it IS possible to have CAD drawings import flawlessly ---
BUT they need to be laid out that way from the get-go.  Most important
is that they be based in exactly one real world coordinate system.

Most folk who have been successful provide the contractors / engineers
with a seed or example drawing, sometimes with useful base map layers as
well as a standards document.  They also set up a mechanism to quickly
and effectively check each submission for compliance so they can request
re-work at a time that something can be done about it (not months
later).

I've never had much luck using DXF format and so I tend to avoid it.

The Blue-Marble universal translator works better; though you get a
MapInfo table for each layer and can't control which layers you get (at
least in the version that ships with MI).

Assuming that your CAD file is laid out "well" (more on that later)
here's what I do:
*  Open the DWG (or DGN if microstation) file in (ok I admit it)
ArcView.
*  manipulate the properties of the layers so that only the drawing
layers I want are visible (sometimes one, sometimes several). That is,
"lose the borders" and whatever other cruft you don't want.
*  do a "save as shapefile" -- this exports exactly the visible layers.
*  convert the resulting shape file to MapInfo using Universal
Translator.

This lets me control what I get in each MI table.  And has worked very
reliably -- though it requires the use of "that other product".  OK for
me, 'cause I have both installed.

At the risk of being flogged for giving away the magic incantation,
here's one version of our CAD file specification that some of our
clients have paid good Yankee dollars for.  You read it first here.

(and I quote)
Historically, our technical staffs have been trained that the end
product of CAD is the plotted, physical drawing.  No one cared how that
end product was created.  This has changed, and we now care a lot about
the internal structure of CAD drawings.  Organizations invest
substantial money in their drawings and maps and it is important that
this value be usable in engineering analysis.
We want our drawings to be "intelligent".  We define an intelligent
drawing as one that is:
*       constructed using a consistent real world coordinate system
*       contains descriptive information about its elements as data
fields in blocks or a database, not merely as annotation
*       refers to appropriate elements with a unique identifier that is
correlated with other external databases.
Each organization will translate this ideal into practical guidance for
their staff.
Here are some specific issues that you should address in order to
maximize the value of your mapping investment.
1.      All drawings must use the same real world coordinate system, and
this system should be compatible with other useful sources of
information such as regional planning agencies.
2.      Each layer should contain exactly one kind of feature or
element, and all related features should be on that layer.  For example,
sanitary manholes should all be on the one layer, and the pipes on
another.  It may be desirable to further separate some elements, such as
contours, into 50', 10' and 2' layers.  This will enable display of
appropriate contour information at various scales with no additional
manipulation.
3.      Layer names should be descriptive (soils, SaniMH, 10FtContours
etc., not 1, 2, etc.)
4.      Put non-geographic features on separate layers. (eg. borders,
logos, arrows etc.)  Do not include them in exports or conversions.
5.      Layers containing large amounts of detail (building outlines,
tax lots) may be tiled to improve computer response time.  Some layers,
such as sewer manholes and sewer lines, should not be tiled, as there is
great value in representing their connectivity.  In any case, tiled
layers should be carefuly edge-matched.
6.      Maps that are produced by photogrammetry contain a wealth of
detail.  Sometimes all this detail gets in the way when producing maps
at larger scales (city-wide, for example).  It may be useful to produce
"thinned" layers that work at a wider scale, preferably by automation.
7.      Linework should intersect where intersections occur, (ei. 4
lines to make an X) especially in area features. Line features should
intersect if the features intersect. (eg. pipelines may or may not
intersect).  In the case of sewers, the manholes should not interfere
with the arcs connecting ( -----O----- ).   Snap to nodes or the
matching endpoints.
8.      Line types should all be continuous. (no dashed or dotted line
types).
9.      Continuous line types should be digitized as continuous lines
10.     The direction of linework representing conveyance facilities
(like sewers or some water lines) should agree with the real world
direction of flow.  This enables efficient extraction of data for use in
hydraulic modeling.
11.     Lines should not be broken for text (e.g. contours --------350
------- ) unless the missing line segment is present and turned off for
the output drawing and turned on for the output dxf.  This is also often
done with force mains.
12.     Contours should connect and edgematch across drawings.
13.     The hash marks on depression contours should not contain
elevation values or be on a separate layer to be turned off for the
output dxf.
14.     Circles and arcs should be avoided (too many vertices) or
generalized later
15.     Data about elements (such as contour elevation, or pipe diameter
or material) should be contained as data in the drawing, not merely
annotation.  There is legitemate debate about which data should be
contained in the map, and which should live in an external database with
a common key.  Ease of labeling in the drawing is one obvious concern.
16.     Each element in selected layers must have a unique identifier
assigned, beyond any internal 'handles' assigned by the CAD package.
This allows cross-references to be constructed to databases such as
maintenance management systems.  In general, man-made elements should
have identifiers, but natural features will not.  There are exceptions.
Some examples of layers not needing identifiers are: contours,
vegetation.  Depending on the analysis expected, rivers and streams may
need ID's for each reach.  Likewise, roads may or may not need
identifiers, depending on transportation planning needs.
17.     There should be only one text insertion point per polygon and
this should store the attribute. This 'label' must reside inside the
polygon regardless of overlapping text.
18.     The method of drawing polygons may depend on the analysis tool
used.  Where adjacent polygons share a common boundary (a basin, for
example), there are two choices:  a) one polyline that represents the
boundary, b) two exactly co-incident lines, one part of each polygon.
Option a) is less error-prone if the analysis tool is ArcInfo, which can
build it's own topology, but option b) is required if analysis will be
done in ArcView.  Once again, a long range plan must inform the current
choice.
19.     In any case, maximum care must be taken that polygons have no
gaps, slivers, overshoots, undershoots or duplicate nodes (two vertices
at the same spot).
20.     Area features (polygons) must always close (eg. no "C" shaped
areas).
21.     Do not use any symbol fonts to place features.
22.     Point features should be digitized as points, not graticules,
symbols or icons.  Use graphic groups to link a point feature with the
feature identifier
23.     The x,y location of a block representing a point feature (such
as a manhole, valve, etc.) must be at the center of the block rather
than at the lower left corner (for example).
24.     Each drawing should have at least four uniquely numbered
reference points or tics that contain 1 x-y coordinate, preferrably
spread out around the drawing. These should be points that can be
geo-referenced to a known grid such as latitude/longitude, State plane
or UTM coordinate grids.

(end quote)

David Cautley
Regional Technology Lead
CH2M HILL, Inc.
Portland, Oregon 97232
(503) 235-5022x4478
[EMAIL PROTECTED]



---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 9695

Reply via email to