Right of Way Map - Vector (CAD) and Raster Image File Footprints

This page last updated: 12/16/2014
Metadata created using Minnesota Geographic Metadata Guidelines


Go to Section:
1. Overview
2. Data Quality
3. Data Organization
4. Coordinate System
5. Attributes
6. Distribution - Get Data
7. Metadata Reference

Section 1 Overview
Originator Minnesota Department of Transportation, Office of Land Management
Title Right of Way Map - Vector (CAD) and Raster Image File Footprints
Abstract The Right of Way Map - Vector (CAD) and Raster Image Footprint is a GIS data set created to represent the outer footprint or extent of a right of may map. The purpose is to aid the user in more rapidly identifying the desired map for a specific area of interest relative to other maps, roads, landmarks, etc. This data set is developed and maintained on a statewide basis. It does not include geo-referenced representations of right of way maps themselves.
Purpose The data set was created to enhance the accessibility to right of way maps by enabling the use of spatial indexing tools. A footprint of a map is created to represent the extent of the map and provides usefulness as a general aid to find a right of way map.
Time Period of Content Date Varies, see Currentness Reference
Currentness Reference The right of way maps used as the basis for the footprints span many decades worth of surveying and mapping. The original right of way maps were drafted by hand using ink on a linen medium with the map rolled for storage. During this period updates to the maps were performed directly on the surface of the linen. It is rare to find specific date information on a map corresponding to an update. In the 1980's technology advanced to a level where computer aided design and drafting software enabled the right of way map to be developed in an electronic vector (CAD) format. The earliest vector (CAD) files where plotted on mylar. A stable medium for preservation and essential for creating paper prints. Once the mylar was made the electronic file was typically discarded. In later years these mylar maps were electronically scanned and converted to a raster formatted map. In the 1990's all the linen maps were electronically scanned with their image converted to a raster format. An update to the raster map was made using a process where any new features were created in the CAD environment as vector features or text and then stamped into the previously existing raster image. The vector (CAD) file containing the updates was then discarded. This form of updating raster map files is typical of current practices. Eventually conditions evolved to where the vector (CAD) file for each new map was retained. New maps are prepared for projects involving new road locations, extensive relocations, horizontal alignment changes or divided highways. These files exist in a Bentley's DGN vector (CAD) format. Currently most of the larger highway project maps are created and maintained in a vector (CAD) format. Since May 2002 all maps, both vector (CAD) and raster formats, are foot-printed and geo-reference for quicker more streamlined access in a spatial index using GIS technology. The result is a statewide coverage consisting of map footprints for the two groups of file formats.
Progress In work
Maintenance and Update Frequency Continually
Spatial Extent of Data Statewide
Bounding Coordinates -97.5
-89.0
49.5
43.0
Place Keywords City, County, Trunk Highway, Section, Township, Range, Control Section, Minnesota State Highway, Minnesota, Midwestern United States, Minnesota Counties, Minnesota Cities
Theme Keywords MnDOT Right of Way Map, Right of Way Map, Final Right of Way Map, Trunk Highway, Parcel, Highway Right of Way, State Highway, US Highway, Interstate Highway, State_RW_FP_Current(feature class name), Transportation, Roads
Theme Keyword Thesaurus
Access Constraints USE OF THIS DOCUMENT IS SUBJECT TO MNDOT'S DISCLAIMERS, LEGAL NOTICES AND POLICIES FOUND @ http://www.dot.state.mn.us/information/disclaimer.html
Use Constraints USE OF THIS DOCUMENT IS SUBJECT TO MNDOT'S DISCLAIMERS, LEGAL NOTICES AND POLICIES FOUND @ http://www.dot.state.mn.us/information/disclaimer.html
Contact Person Information Jay Krafthefer, LIS & R/W Mapping Supervisor
MN Department of Transportation, Office of Land Management
395 John Ireland Blvd., M.S. 643
St. Paul, MN  55155
Phone: 651-366-3463
Fax: 651-366-3450
Email: jay.krafthefer@state.mn.us
Browse Graphic None available
Associated Data Sets Right of Way Map in their origianl vector (CAD) maps and raster image file formats
Right of Way Plats
Commissioner's Orders
Control Point Generated Public Land Survey

Section 2 Data Quality
Attribute Accuracy Attributes programmatically generated include: OBJECTID, FILENAME, SHAPE.AREA, SHAPE, and SHAPE_FILE. Those manually entered include: ROLL_NUMBER, SHEET_NUMBER, and MAP_NUMBER. The following attributes are created by cut and paste from the corresponding record in MnDOT's Electronic Document Management System (EDMS): COUNTYFIPS, TERMINI, COUNTY_NAME, COUNTY_NUM, DISTRICT, DISTRICT_NAME, CONTROL_SECT, NOTES, SITE, TH_CURRENT, LEG_ROUTE_NUM, SP_NUMBER, and DASH_900. Many of the EDMS values are selected from a given domain. The TH_HISTORIC attribute is captured from MnDOT's Electronic Document Access site.
Logical Consistency Foot-print representations are based on a closed "shape" created in Bentley MicroStation to ensure 100% polygon closure following ETL processing. Foot-print labeling is directly passed from the attribute table entries.
The map border which outlines a print of the map was used to define the footprint shape. Older vector (CAD) files, those created solely for use as a printed roll map and containing match lines due to road alignments which extend beyond the printed border causing match-lines, were foot-printed strictly using the border of the actual print. In this case, the spatial location of the foot-print may not be true for its entire extent. Current standardization practices call for reconstructing the map into its true form throughout and replacing the prior foot-print with a more precise representation.
Completeness As each new map is completed the map file is stored in MnDOT's Electronic Document Management System (EDMS). If the map already exists a new version of the existing EDMS document is created. In both cases, subsequent processing steps require the creation of a new foot-print and its geo-referencing to enable publication in MnDOT's Right of Way Mapping & Monitoring website. This process includes the use of a checklist and steps to verify publication. See also CURRENTNESS REFERENCE.
Horizontal Positional Accuracy The spatial placement of the footprint is based entirely on the geographic scale and coordinate reference system of the content of the map. In cases where the scale and coordinate system are limited or unknown, hand placement of the border representation is used based the location of roads and landmarks in MnDOT Base Map.
Vertical Positional Accuracy Not applicable
Lineage LINEAGE FOR VECTOR (CAD) FOOTPRINTS

An extract translate and load (ETL) process is used when a new vector (CAD) map is created. A new (blank) Bentley MicroStation vector (CAD) file is used to start the process. The newly completed right of way map is brought into the blank file as an attached reference. If the orientation of the new right of way map is something other than north pointing to the top it is rotated appropriately. A MicroStation "shape" created on the default level is drawn around the right of way map border. The referenced right of way map is then detached and the new file containing only a border representation is saved. The new file is then processed using the ETL_Footprint_Tool.mxd in ArcMap. With the ETL tool opened the network location of the new file is located and the correct projection and county are designated. The ETL program is run. The new file containing the map foot-print appears in the view window of ArcMap. The ETL tool is closed and a new ArcMap window opened in order to fill in the attribute table. With the new ArcMap window open the MnDOT dataset MNDOT_COMMON_LAYER is imported to verify if the new file containing the footprint is in the correct spatial location. Next the Statewide_RW_FP data set is brought into the ArcMap session. This is the data set containing all map footprints of both vector (CAD) and raster images. If the appearance is acceptable the master attribute table for this data set is edited with the new right of way map's information. A suite of programs maintained by MnDOT's Enterprise GIS Group runs nightly to process the vector (CAD) footprints (and raster image footprints) and update the databases contributing to MnDOT's Right of Way Mapping & Monitoring (RWMM) website. The overnight process is dependent upon a copy of the new right of way map file to be stored in a library organized by county on MnDOT's file network. In a near parallel process the Linen_Update_9.3 footprint tool is manually run to ready the new footprint for transfer to RWMM. Originally map foot-prints were created in ArcGIS 8.2. Current processes rely on ArcGIS 10.

LINEAGE FOR RASTER IMAGE FOOTPRINTS

Raster formatted maps foot-printed during the earliest days of this dataset were processed in batch. Subsequent updates and additions have been handled using a more case by case approach. Likewise a majority of the earliest map footprints where based on images that were the result of photographic to scanning process made of the original Right of Way map linen and mylar collection. See Right of Way Map - Raster Image File (Geo-Referenced) metadata for more detail.

The initial georeferencing process was handled on a county-by-county basis. It was done using individual map rolls (less than 3 feet to 86 feet long) each consisting of between two and twenty-six sheets per roll. These rolls were converted from multi-page TIF files to one file per sheet. The images were georeferenced one at a time. There were two main pre-georeferencing processes. The following process consists of the georeferencing itself.

Pre-Georeferencing

The pre-georeferencing starts by the identification of a target county and its surrounding counties. This was followed by the creation of two shapefiles, xx_cent and xx_corn, which were used to provide quick access to X and Y coordinate information for both the centers and corners. These files were created by two separate applications in ArcView 3.2 that did the spatial processing and stored it in the attribute table. This was done in a separate application due to query time and debugging issues.

Building PLS section, quarter corner, and centers of section was the next step in the process. To build centers of section, the quarter-quarter coverage from the 'Control Point Generated PLS' and the section polygons from the 'Section Level Public Land Survey' were used as acquired from the Minnesota DNR Data Deli website. These layers were unzipped using Pkzip. The Bld_cent.apr was used to calculate center of section nodes based on the quarter-quarter breakdowns by selecting the centroid of the polygon, and then looking for the breakdown that occurred closest. Once the center of section was established, the section, township, and range were calculated to that point. The application yielded a point shapefile that contained all the center of sections based on the Control Point Generated PLS.

To build corners, the corner building application, Bld_corn.apr, used both the section polygons and section arcs datasets from the 'Section Level Public Land Survey' at the Minnesota DNR Data Deli website. From the section arcs, a point theme was generated (nodes) where two section lines intersected. This process created the corners. Using section polygons, each individual polygon was selected and spatially queried against the point theme so all the corners that intersected with that section were selected. The section name, (e.g. T29, R22, Sec 22) was then calculated to those selected corners in the database. The application repeated this process until all the sections in the county were processed. The end result was a point shapefile containing the concatenated strings of all the sections that intersected each corner. When the GeoImage Translator was run, it was able to select from those text strings the particular corner the user was querying.

A one-mile buffer around the target county was created so all the corners and centers near the county border could be built. This, in turn, allowed for better georeferencing in those areas. The buffered features of the surrounding counties were appended to the target county.

The final step in the pre-georeferencing process was to convert multi-page TIF files to one TIF file per sheet.

Late in 2007 commenced the transition of maps from Standard Sheet Size (SSS) to Match line To Match line (MTM). See logical consistency for more detail regarding SSS to MTM.

Georeferencing

In general, the georeferencing process consisted of taking raster TIF files and aligning them with the road centerline of the MnDOT Base Map. The GeoImage Translator was developed to expedite this process.

Three different methods were used to align the two layers as closely as possible. The preferred method consisted of the user identifying (clicking) two points on the raster, either a corner or center of section, and entering in the values. The application then queried the support files to locate the corner or center and then retrieved their X and Y values. A corner was defined by entering three out of four sections that intersect it, and a center was defined by entering the section, township, and range.

Using the two X and Y coordinates defined on the raster (user clicks), and the two x, y pairs retrieved from the database, the application computed the factors needed to scale, move, and rotate the image. For example, if the distance of the raster x, y pairs was 10 feet and the distance of the x, y pairs from the database was 1,000 feet, the application knew to enlarge the image 100 times. Once the image was scaled, the application moved the image from the first raster x, y (the first user click), to its corresponding x, y point that was retrieved from the database. It set this point as an axis, computed the rotational angle based on the difference between the second x, y raster point and the second x, y point from the database and rotated the image. The end result was a georeferenced image based on a two-point translation that scaled both the x and y proportionately.

Because over half of the Right of Way map sheets didn't contain at least two corners or centers, a second method was used to georeference. For those images that had at least one corner or center, calculating a quarter-quarter breakdown could derive the second coordinate pair. The user would define one center or corner, and identify a quarter-quarter breakdown north, south, east, or west from that point. The application would then compute the breakdown at 402 or 804 meter, depending if the user selected one or two quarters for the calculation. The coordinate was calculated straight along the x or y axis depending on the direction specified.

If no center or corner points existed on the raster images, the third method was used. This procedure consisted of placing the image using the manual placement tools that were created for images with insufficient Public Land Survey information. The manual placement tools consisted of the following:
- User Defined Translator - Performed translation based on two pairs of user-defined x, y coordinates. The destination x, y pairs are provided by the user instead of being retrieved from the database.
- Move Raster Tool - Moved raster by user-defined placement (clicking and dragging).
- Rotate Raster Tool - Rotated raster around defined axis (single click) and by user-defined distance (clicking and dragging).
- Move to Layer - Moved un-georeferenced target image to extent of user-defined layer.
- Scale Manually - Scaled raster by a pre-defined scale.

There were a number of map sheets that needed to be split due to match lines on the sheet. These map sheets had two distinct images making them unable to be georeferenced using the above methods. In order to prepare these images for georeferencing, a process using Corel PHOTO-PAINT 8 was developed. The steps in this application included selecting 'To Fit' in the scale dropdown and entering one number smaller than the given value. Selecting the Deskew Crop Tool and dragging a border around the area to be kept was the next step. Right clicking inside the boxed area and double clicking to complete the polygon are the next steps. Right clicking inside the dotted line and selecting clear were next. Then, navigating to the File Drop Down Menu, clicking Export, entering a new name, and saving to the working directory followed. The final step in the application was to close the image and answer no when prompted to save. After reopening the original map sheet, the above process was repeated for the second image on the sheet. At this point, the two separate map sheets were ready for georeferencing. After these map sheets were georeferenced, sheets on either side that were unable to be georeferenced because of the images that needed to be split, could also be georeferenced in most cases.

Because the road centerlines were the most accurate on the raster images, the primary focus was to match the road centerlines on the two images as closely as possible. The Public Land Survey section lines were used as a secondary reference.

Creating Footprints

Images were loaded into the Footprint tool one county at a time. The tool found the extent of the image and drew a box around it, creating the footprint. The FILE_NAME and CNTYFD_NU fields were automatically populated during this process. The other fields (ROLL_NUM, SHEET_NUM, SPLIT_SHT, CNTYFD_STR and GEOR_PATH) were populated using data derived from these fields. All county footprint shapefiles were then appended to each other to create a statewide footprint shapefile.

Section 3 Spatial Data Organization (not used in this metadata)

Section 4 Coordinate System
Horizontal Coordinate Scheme Universal Transverse Mercator
UTM Zone Number 15
Horizontal Datum NAD83
Horizontal Units meters

Section 5 Attributes
Overview The Right of Way Map Footprints contains the following attribute data fields:

OBJECTID - data system file number, polygon identifier
FILENAME - map file system name, either in .TIF or .DGN format depending on which footprint layer selected
ROLL_NUMBER - individual map roll number based on MNDOT's final right of way map roll index
SHEET_NUMBER - sheet number for specific map sheet within a given map roll
COUNTYFIPS - county FIPS code for Minnesota counties
TERMINI - Map roll number, highway number, abbreviated beginning to end description of the highway segment
COUNTY_NAME - name of the county or counties, multi-value field
COUNTY_NUM - Minnesota county number based on alphabetic order
DISTRICT - MNDOT transportation office district number
DISTRICT_NAME - MNDOT transportation office district name
CONTROL_SECT - MNDOT control section number, multi-value field
NOTES - text field with supplemental information
SITE - MNDOT site number, multi-value field
TH_CURRENT - current trunk highway number, multi-value field
TH_HISTORIC - historic trunk highway number, multi-value field
LEG_ROUTE_NUM - legislative or constitutional route number, multi-value field
SP_NUMBER - MNDOT state project number
DASH_900 - MNDOT 900 numbering, a land management record index
MAP_NUMBER - map number in XXX-XXX-X (REALMS) format (similar to map roll number only format is different)
SHAPE.AREA - area value of the map footprint
SHAPE - type of attribute
SHAPE_FILE - area value of the map footprint
Detailed Citation
Table Detail:
Statewide_RW_FPCurrent - feature class name


Section 6 Distribution
Publisher Minnesota Department of Transportation, Office of Land Management
Publication Date periodically revised
Contact Person Information Jay Krafthefer, LIS & R/W Mapping Supervisor
MN Department of Transportation, Office of Land Management
395 John Ireland Blvd., M.S. 643
St. Paul, MN  55155
Phone: 651-366-3463
Fax: 651-366-3450
Email: jay.krafthefer@state.mn.us
Distributor's Data Set Identifier Right of Way Map - Vector (CAD) and Raster File Footprints
Distribution Liability USE OF THIS DOCUMENT IS SUBJECT TO MNDOT'S DISCLAIMERS, LEGAL NOTICES AND POLICIES FOUND @ http://www.dot.state.mn.us/information/disclaimer.html
Ordering Instructions Complete the on-line order FORM for a request of shapefile data. Provide a detailed description of what you are requesting including the location or extent of the area needed. Also include your contact information with a telephone number. For other information or assistance complete the on-line request FORM by including your contact information and telephone number or send the same information to lisrwmap.dot@state.mn.us.

Currently, no on-line download exists for Vector (CAD) and Raster Image footprint shapefiles. All maps, this includes vector (CAD) files and raster image files, can be downloaded directly from RIGHT OF WAY MAPPING & MONITORING or ELECTRONIC DOCUMENT ACCESS. See this CHART for a comparison between these delivery sites.

RIGHT OF WAY MAPPING & MONITORING - http://www.dot.state.mn.us/maps/gisweb/row/
ELECTRONIC DOCUMENT ACCESS - http://dotapp7.dot.state.mn.us/cyberdocs_guest/Libraries/Default_Library/Groups/GUESTS/frameset.asp

CHART - http://gisservices.dot.state.mn.us/mndot-rwmm/Right%20of%20Way%20Mapping.docx
FORM - http://olmwebservices.dot.state.mn.us/maprequest/requestmain.aspx

Statewide R/W Footprint shapefile is 14.7 MB.
Online Linkage I AGREE to the notice in "Distribution Liability" above. Clicking to agree will either begin the download process, link to a service, or provide more instructions. See "Ordering Instructions" above for details.

Section 7 Metadata Reference
Metadata Date 12/16/2014
Contact Person Information Jay Krafthefer, LIS & R/W Mapping Supervisor
MN Department of Transportation, Office of Land Management
395 John Ireland Blvd., M.S. 643
St. Paul, MN  55155
Phone: 651-366-3463
Fax: 651-366-3450
Email: jay.krafthefer@state.mn.us
Metadata Standard Name Minnesota Geographic Metadata Guidelines
Metadata Standard Version 1.2
Metadata Standard Online Linkage http://www.mngeo.state.mn.us/committee/standards/mgmg/metadata.htm


This page last updated: 12/16/2014
Go back to top