Vector Digiting Methodologies


Scope
This lab exemplifies practical experience manually digitizing topological a vector dataset, and semi-automatically vectorizing a non-topological dataset.

Software
Manual vectorizing MIGS Digitizing, Editing
Semi-automatic vectorizing PixelTrak
Operating System Windows NT

Data Inputs
Region of Interest Australia
Projection geographic
Image Data austral.tif

Method
The flowchart illustrates the process involved in both modes of digitizing for the purpose of this lab. Output maps are attached and outlined at the conclusion of this report.

Analysis
In comparing the two FILESTAT output reports, it appears that the PixelTrak generated data contained more coordinates, and coordinates per segment, as well as a lower coordinate length on average (and less distance between coordinates), resulting in a denser coordinate dataset representative of the PixelTrak generated dataset. This can be attributed to the intelligence and configuration settings (endpoint snaps, etc.) of the PixelTrak software package as well as the behaviours of the individual performing the manual digitizing process.

It also appears that the bounding box defining the region of interest, in xy coordinates, for the MIGS dataset is shifted northwest of the PixelTrak generated data. This is a result of the digitizing orientation / calibration process. Below is some C code to calculate the area from the Calculated Minimum Bounding Rectangle values from the FILESTAT outputs, with output encoded in Geography Markup Language (GML):

#include<stdio.h>
#include<stdlib.h>

int main(int argc, char *argv[]) {

  double x1, y1, x2, y2;

  if (argc != 5) {
    printf("Usage: %s x1 y1 x2 y2\n", argv[0]);
    return 1;
  }

  x1 = atof(argv[1]);
  y1 = atof(argv[2]);
  x2 = atof(argv[3]);
  y2 = atof(argv[4]);

  printf("<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n");
  printf("<calculation type=\"area\" xmlns:gml=\"http://www.opengis.net/gml\">\n");
  printf(" <inputs>\n");
  printf("  <gml:boundedBy>\n");
  printf("   <gml:Box srsName=\"AUTO\">\n");
  printf("      <gml:coordinates>%f %f %f %f</gml:coordinates>\n", x1, y1, x2, y2);
  printf("   </gml:Box>\n");
  printf("  </gml:boundedBy>\n");
  printf(" </inputs>\n");
  printf(" <output>%f</output>\n", (x2 - x1) * (y2 - y1));
  printf("</calculation>\n");

  return 0;
}
   

The preceding program produced the following output:

MIGS dataset output:

<?xml version="1.0" encoding="utf-8" ?>
<calculation type="area" xmlns:gml="http://www.opengis.net/gml">
 <inputs>
  <gml:boundedBy>
   <gml:Box srsName="AUTO">
      <gml:coordinates>6.800003 5.799999 205.100000 182.300000</gml:coordinates>
   </gml:Box>
  </gml:boundedBy>
 </inputs>
 <output>34999.949669</output>
</calculation>
   
PixelTrak dataset output:
<?xml version="1.0" encoding="utf-8" ?>
<calculation type="area" xmlns:gml="http://www.opengis.net/gml">
 <inputs>
  <gml:boundedBy>
   <gml:Box srsName="AUTO">
      <gml:coordinates>10.160000 3.132667 207.772000 179.239300</gml:coordinates>
   </gml:Box>
  </gml:boundedBy>
 </inputs>
 <output>34800.783960</output>
</calculation>
   

The areas differ, again, due to the calibration / area definition when digitizing. This can be systematically shifted with software, to align the origins of both datasets, and therefore better visualize and analyze variations in data having similar extents and / or origins.

The statistical differences are illustrated visually as well between the MIGS and PixelTrak generated datasets. However, there are some areas where manual digitizing produced output closer to the original scanned map then it semi-automatic counterpart process. This is evident in the Midwest region of the data (two finger like areas which were not picked up as well with the PixelTrak software). The shapes appear similar to the human eye, relative to the scale of the data.

Overall, the results of the two methods of digitizing have variances, however the degree of variance and acceptability is at the discretion and data requirements of the application, and / or project requirements.

As an interactive solution, the PixelTrak software enabled quicker digitizing in comparison to MIGS. PixelTrak enabled quicker, 'smarter' digitizing in comparison to MIGS, and results (precision, accuracy, consistency) produced similar results in both methods.

As far as ease of use, PixelTrak provides a very cumbersome interface, and is not user friendly (DOS environment / interface). MIGS' modules provide a simple, clear, concise interface. Menus are easy to navigate, supplemented with the help notes provided. Suggestions to both interfaces would be to update them to take advantage of modern desktop GUIs (Win32, Linux), however this would impact the processing modules themselves to port to new / other platforms.

Appropriate Applications
Manual vs. semi-automatic digitizing both have pros and cons to their usage, most of which are based on time, accuracy and position. Though manual conversion can produce high accuracy results, a human operates it. Semi-automatic digitizing, though also interactive, provides more automation to the process of vector dataset creation. Errors derived from semi-automatic approaches have more chance of being systematically corrected than that of those produced manually. Semi-automatic digitizing also saves time in terms of operational and budgetary constraints within a project. However, a concentrated digitizing process (manually) within a small area of interest can yield very accurate results, which a semi-automatic approach may miss, such as the midwest features missed by PixelTrak in this lab. Also important is relative and absolute positional accuracy, which is again dependent on the scale of the data, as well as the requirements.

As a result, the choice of manual vs. semi-automatic digitizing is dependent on the application type, end users, and functionality. Mission critical applications, such as military / aeronautical navigation charts, etc. require a high degree of accuracy and precision, so discretion and caution is vital to producing quality maps, which may be better suited to manual digitizing. Small scale data, such as 1:1 000 000 or 1: 7 500 000, which contains a high degree of generalization, may be better suited for a semi-automated process. A hybrid approach is also useful, i.e. using semi-automatic digitizing software, with strict tolerance / snap settings, combined with a prudent quality control process.



Analytical and Computer Cartography Home