Subscribe to this thread
Home - General / All posts - How to georegister an image based on a USGS 1:24000 7.5' quad

386 post(s)
#18-Jul-09 13:49

I know I can do this manually by getting the applicable DRG from the USGS site and assigning control points etc. but I wondered if anyone has an easier way, since I need to georegister tens of images. The images are of points, lines, polygons. etc. placed on a USGS 7.5' quad (likely the DRGs) and the projection doesn't appear to have been modified, so I can find lat/lon coords on the image to place and scale it correctly. The particular series I am working with was done with the Washington State Plane South NAD27 projection, if that helps any.


386 post(s)
#18-Jul-09 14:04

Sorry, I meant to say 1:100000 quads, not 1:24000 quads, which are UTM Zone 11, NAD 27.

222 post(s)
#19-Jul-09 12:32

You can skip the DRG step, I think and buld a drawing just for your control points. If I'm going to use tick marks in the map image as my control points, I set up a table and enter the control points I plan to use as lat-lon pairs corresponding to the ticks I'm going to use. I paste the table as a drawing, assign projection as lat-lon, then reproject it to the desired projection of the map image. With the drawing as the active layer, I set the drawing to "snap to points" and enter the control points by clicking on or near them. I then make the image layer active and set up the corresponding control points by zooming with the mouse wheel and clicking the senter of the tick marks. If what your registering is not an image but a drawing, it's even easier--you can snap to the features you want to use.

That method doesn't really lend itself to automation, however.

Maybe that's why the call it "Work?"


6,118 post(s)
#19-Jul-09 17:49

A genuine USGS DRG imports correctly georeferenced with no additional work necessary. For example, go to the USGS site at - search for DRG data. When you download a DRG you get a file that is a UNIX .tar file which has been further compressed using .gz (gnuzip) format to make a .tgz file.

Decompress that using any program that can uncompress .gz and unarchive .tar (I like to use Igor Pavlov's wonderful 7-zip utility... see ...or you could use winzip or many others). The result is a geotiff with a worldfile that Manifold imports correctly with full and exact and accurate georegistration. No need for manual georegistration.

Could it be that what you have is not really a USGS DRG but is instead an image that was created from a DRG using a process that destroyed the projection info USGS so helpfully attaches to their DRGs? If so, pause a moment to curse the shortsightedness of whoever destroyed that data and then consider using a process like that in - if you know the DRG from which the image came you can infer the missing projection info and then use Edit - Assign Projection to specify the correct projection for that image without having to do any manual georegistration.


386 post(s)
#19-Jul-09 21:08

Like I said above, it is an image based on a DRG, not a GIS file. The images are from a document so there is no way to store any georeferencing information. Thanks for the tips, I will try it if I can figure out what you are suggesting. Assigning a projection even when I know the UTM offsets for the bottom left corner doesn't work, but it is definitely in the native projection (they used a program like Photoshop to place points and labels on the image of the DRG so they couldn't have reprojected it).


3,126 post(s)
#11-Jan-17 21:25

instead of using the images from the document, I would download the corresponding DRG from the USGS site. You should be able to create a list of the name, and maybe use a url library to download the data with a Python package, or from VBScript.


9,342 post(s)
#11-Jan-17 21:48

I think you're replying to an old post here Art. The new post is only visible with blacklisting off.


1,052 post(s)
#12-Jan-17 07:21

Tim thank you for your xml. It works so far that i have now the MODIS Sphere as DATUM.

But the surface isn`t at the right position, its to far at the south, so i must change the Local offsets:


1,052 post(s)
#12-Jan-17 07:32

After reading "A practical Guide to Geostatistical Mapping" from T. Hengl, there is a how to input image an reproject to UTM in the ModisReproject Tool from

There, T. Hengl wrote (for an MODIS example in Croatia):

input_projection_type: SIN

input_datum: WGS84

output_projection_type: UTM

output_zone_code: 33

output_datum: WGS84

I think the Sinusoidal projection in MFD is not right...?

Another story: after reading "A practical Guide to Geostatistical Mapping" the more i miss the possibility of doing Regression Kriging (or Kriging with External Drift) in MFD. I do it now in SAGA (R is to complicated (in the moment) for me).

The results i get out of regression kriging a very impress me....


9,342 post(s)
#12-Jan-17 07:33

Can you give me the exact source for the MODIS data?

A nice challenge! They make it easy on purpose!


1,052 post(s)
#12-Jan-17 08:03

or directly by ftp:

but i think registration is necessary...


1,052 post(s)
#12-Jan-17 13:12

found this at

Import a *.prj-File don`t work. Must do this in a xml...

PROJCS["MODIS Sinusoidal", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], PROJECTION["Sinusoidal"], PARAMETER["false_easting",0.0], PARAMETER["false_northing",0.0], PARAMETER["central_meridian",0.0], PARAMETER["semi_minor",6378137.0], UNIT["m",1.0]]


1,052 post(s)
#15-Jan-17 19:08

Had no luck to generate a MFD-xml-file with the parameters above.

But i change the local offsets per hand (CTRL+grabber).

The result is more ore less ok, but i think my pixel size isn`t right


Output Pixel Size

Because native MODIS spatial resolution is based on arcseconds at the equator, input pixel size is not likely to be exactly as advertised. For example, 250-m products actually contain 231.7-m pixels; 500-m products have 463.3-m pixels; 1,000-m products have 926.6-m pixels.

But i think that's only right (the pixelsize) near at the equator...?

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.