To perform this task well you might need to invest in a better format translator, such as the full version of FME. This should provide you with the additional utility you will need to handle some of the anomalies you will encounter.
I have done this for several local governments in the past, including the one I worked for a long time ago. The specs offered are a very good list, I would offer the following additional thoughts. 1) Being in Michigan are you using State Plane coordinates as your base coordinate system or are you using the DNR Michigan Georef system? I'm not familiar enough with Michigan law to know what latitude you have. If you are using the DNR georef system I suspect there may be a conflict with engineering and survey firms as they will tend to provide data in the State Plane Coordinate system to meet their legal obligations (assuming they are providing more than just a paper drawing to their clients). 2) Much of the task you are embarking upon will require some lengthy communications / negotiations with the local engineering and survey firms. I'm sure there are some willing players that you can organize around that can help you resolve the numerous political fallout issues that will occur. While the list presented the technical components don't forget there is a political side to this as well. Build some allies and political support, you will need it before it is over, guaranteed. An alternate route is to build a specification yourself and get it adopted as a regulation (This is a strong arm approach that I do not recommend). 3) I believe YOU should make accommodations to support properly defined ARCs from a CAD system. MapInfo handles ARC rather badly (In my opinion this is a major downfall of MapInfo). ANY effort to provide legal land descriptions requires the use of ARCs. The survey professional can only provide legal descriptions that contain such geometry. It will be incumbent upon you to determine how this information is transformed and stored in the GIS. 4) Define very clearly what data you are willing to provide as well as any disclaimers and conditions of use. In my opinion I would like to see local government charge itself with providing a data set of control geometry used in mapping and surveying the jurisdiction. This again requires additional coordination with state government, and private surveying firms (who have most of the data). NOTE: I would like to use the word "Metadata" here, but am some what hesitant. The Metadata framework is good, but to date the implementation has varied from very good to very bad. In the end however, ALL data providers must have accompanying metadata that properly describes the product; especially its origin, dependencies, and limits of use. 5) About layer identifications... While managing the use of GIS data on rezoning case review there often arises disputes between the jurisdiction and land owner regarding the "correctness" of the data. In the jurisdiction I worked at there were a number of land use policy regulations that were reviewed. Our ability to keep up with the data demands was limited, our data could be questioned. We adopted a policy and procedure that defined the principles of how we would review data submitted by a property owner (engineering firm, surveyor, etc.) and resolve data conflicts. The land use policy would not change, but more accurate data could be provided by the land owner to assess the policy against. I would recommend you consider defining how you will incorporate "new" or "modified" data provided by an outside source. It may have an impact on your data storage schema. In my case it was how DBMS table structures were organized and procedures used to take data through a screening process prior to incorporation into the main data tables. -----Original Message----- From: Woody Woodruff [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 11:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: MI-L AutoCAD Specs for Electronic Submissions to Municipality (long) 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 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 9707
