Proceed to GeoCommunity Home Page


SpatialNewsGIS Data DepotGeoImaging ChannelGIS and MappingSoftwareGIS JobsGeoBids-RFPsGeoCommunity MarketplaceGIS Event Listings
HomeLoginAccountsAboutContactAdvertiseSearchFAQsForumsCartFree Newsletter

Sponsored by:


TOPICS
Today's News

Submit News

Feature Articles

Product Reviews

Education

News Affiliates

Discussions

Newsletters

Email Lists

Polls

Editor's Corner


SpatialNews Daily Newswire!
Subscribe now!

Latest Industry Headlines
SiteVision GIS Partnership With City of Roanoke VA Goes Live
Garmin® Introduces Delta™ Upland Remote Trainer with Beeper
Caliper Offers Updated Chile Data for Use with Maptitude 2013
Southampton’s Go! Rhinos Trail Mapped by Ordnance Survey
New Approach to Measuring Coral Growth Offers Valuable Tool for Reef Managers
Topo ly - Tailor-Fit for Companies' Online Mapping Needs

Latest GeoBids-RFPs
Nautical Charts*Poland
Software & Telemetry GPS
Spatial Data Management-DC
Geospatial and Mapping-DC
Next-Gen 911-MO

Recent Job Opportunities
Planner/GIS Specialist
Team Leader- Grape Supply Systems
Geospatial Developer

Recent Discussions
Raster images
cartographic symbology
Telephone Exchange areas in Europe
Problem showcasing Vector map on Windows CE device
Base map

GeoCommunity Mailing List
 
Mailing List Archives

Subject: Re: [gislist] Advice on heads-up digitizing
Date:  05/24/2007 08:38:46 AM
From:  Quantitative Decisions



At 01:06 PM 5/24/2007 +0200, Gillian McGregor wrote:
>We are woking with time series photos, captured at a scale of 1:20 000 to
>about 1:50 000. The pixel size of the photos in their scanned form is
>about 6mx6m. Pixelation is evident at a scale of about 1:12 000.
>
>1. Can someone advise what would be a reasonable scale to digitize at, and
>suggest how we would justify this choice?

There are several considerations. Let's see where they lead.

(a) When you are zoomed into just a few pixels, it usually is not possible
to identify features. Let's suppose, then, that to digitize anything you
need to see an array of about 10 by 10 pixels on the screen, which itself
is at most a half meter across. That gives a practical upper bound scale
of about 0.5 m : (10 * 6 m) = 1:120. In reality, you're going to have
difficulty with digitizing at scales much larger than 1:1000, which would
put about 80 by 80 pixels on the screen.

(Just to be clear: a scale of 1:500, for example, is _larger_ than 1:1000
and 1:2000 is _smaller_ than 1:1000.)

(b) Map accuracy standards in the US usually translate to a manual
digitization error (RMS) of 0.5 to 0.25 mm. This can be compared to a
photo resolution by equating it to the cell size, whence we obtain a
working scale of about 0.25 mm : 6 m = 1 : 24000.

(c) You state the photos were "captured at" scales around 1:20,000. It is
not clear what that means, but this number is consistent with that derived
in (b).

(d) The purpose of the digitizing will determine much. For instance, if
you only need a generalized outline of a large feature, then high-accuracy
digitization from these photos would be overkill.

(e) The intended analysis of the digitized data is also an important
consideration. For instance, if you will be computing areas of polygonal
regions, then you can tolerate larger errors (and therefore smaller
digitizing scales) than if you are computing lengths of digitized lines.

(f) The amount of effort to digitize will increase roughly in direct
proportion to the scale. The increase is a little bit worse than a direct
proportion because at large scales you usually have to do a lot of panning.

In summary, these photos could support digitization at scales around 1:1000
and smaller and it looks like they are intended for digitization around
scales of 1:24000 and smaller. The choice of scale depends on your needs,
objectives, and the time available.


>2. Can anyone direct us to literature on the levels of error encountered
>when using un-ortho-rectified images or advise based on experience?

The error is a combination of many things. We can compute the contribution
from orthorectification itself. Orthorectification references all features
to a common height, the rectifying plane. Let the ground elevation above
the plane be 'h' (which can be negative) and the camera angle to the object
be 't'. Rectification displaces the object by h * tan(t) radially outwards
from the point directly beneath the camera (the origin): draw a picture,
this is a simple calculation. Usually you don't know 't', which varies
across the image, but for cameras that are much higher than any visible
feature, tan(t) is going to be close to r/z where 'z' is the camera height
above the rectifying plane and 'r' is the radial distance from the origin.

Often you can identify the origin, at least approximately, by looking in
the image for vertical objects like trees and buildings whose tops exhibit
no displacement relative to their bottoms. From that you can compute r (as
a grid). Separately, subtract the median elevation from a DEM of the area:
this will be 'h'. Multiply grids [r] and [h] and divide by the constant
value 'z'. The histogram of the resulting values gives the error
distribution due to elevation differences. Orthorectification, if done
perfectly accurately, would eliminate this error (but leave other sources
of error due to atmospheric distortion, camera properties, etc.)

The range of this histogram can be as large as the range of elevations
multiplied by the largest value of 'r' in the image divided by the camera
height: that gives you a quick way to estimate the potential size of this
error. For example, consider a photograph covering a 1000 by 1000 meter
region taken from an airplane directly above the center at a height of 2000
meters, and suppose the total relief of the region is 100 meters. The
largest possible value of 'r' is about 700 meters (from center to a
corner), so the range of error is bounded by

700 meters * 100 meters / 2000 meters
= 35 meters

and often will be much smaller throughout most of the image.

--Bill Huber


_____

Sponsored by:

For information
regarding
advertising rates
Click Here!

Copyright© 1995-2012 MindSites Group / Privacy Policy

GeoCommunity™, Wireless Developer Network™, GIS Data Depot®, and Spatial News™
including all logos and other service marks
are registered trademarks and trade communities of
MindSites Group