I’m trying to geocode a scanned map.

I followed the instructions in this: http://www.youtube.com/watch?v=Cb_qrNh_6_Q and the first time it worked OK. I stuck in WGS 84 the source map CRS, as stated on the map, and used the cross hair (dd mm,dd mm) markers as my points. I used 3 points, and it stuck the map in pretty much the right place – maybe 50m off in some places. But it messed up the resolution, so the placenames weren’t readable and countours were messed up and basically it wasn’t much use.

I tried again, and it put the map at 0,0 – meridian,equator. Tried again with the Blue UTM lines, polynomial transformation with 6 points instead of linear, “create world file” checked and unchecked, different Target SRS (using the WGS 84 as per the map, and the modified WGS84 that the open source maps play nicely with in QGIS). tried reproducing the jpeg again from the original pdf in case there’s georeferencing data in there messing things up.

If I georeference using the blue UTM line refs, the equivalent degrees and minutes show in the GCP table, and vice versa, so the data seems to match up, I’m using the right co-ordinates.

If I input UTM refs, the georeferencer puts the raster in the atlantic or the north sea, depending on the target srs, if I use degrees and minutes, even if I only use 3 points, it says “Failed to compute GCP transform: Transform is not solvable”

arg. driven me slightly crazy this weekend any pointers Perleeease?! There aren’t that many things to change in the goereferencer tool, I have no idea what I did to put it in the right place to start with and mess up the resolution, and why now the resolution’s fine but the map’s in the wrong place or it won’t georeference at all.

arg. again.

???

[url=https://flic.kr/p/qaAjQn]error2[/url] by no1heroclub, on Flickr

Have you tried using 4 points instead of 3? It’s been awhile since I used QGIS to georeference an image (I normally use MapInfo), so can’t remember the various option, but if you send me one of the raster images, I can try to do it tomorrow at work.

Greg

3 used to be min number of points in MapInfo too
Maybe the problem lies elsewhere?

Maybe the coordinates of the source data are not in L/L WGS84? They could be on some local system. For example the French sometimes use Lambert system where the Meridian is in Paris, which messes with your head ‘cos you get an eastward shift of ~1.5°. All the coordinates look sensible until you forget it is Lambert

I would try keeping everything in utm (or whatever the blue gird is in, Norway does use utm but I think it is their own version as the country spans a few utm zones), don’t bother with wgs84just now. Put the gcp on an intersection and type in the x and y, the more you do the better it should be, the minimum is 3. You should not need a complex polynomial as you are not warping it too much ( the source file is not going to be too distorted as it was a referenced map). Out put with a worldfile, this is an auxiliary file which tells the image where to go, although this info may also be in the image itself. Once its in the right place in utm you can there project it to wgs84.

Cheers guys, I started with 4, then 3 to save time trying different thinhs. I figured fewer points would also have less transformation difficulties; it wouldn’t be as accurate, but if I could just get it to work, I can work on the accuracy later with more points. Tried 6 with the polynomial transformation, because that’s

The map blurb says “Blue UTM grid refers to EUREF89 (WGS84)” I’ve assumed that’s the standard WGS84 (rather than any of the modified versions listed in QGIS) ?

In the last picture above, I’ve input the L/L, and the geo-referencer has given me the srcX,srcY refs which match the UTM line references on the paper map for those points. So it seems the references match up, and they’re in the right place: Put 20.166E, 69.916N into google, and it points to the top right position in the map (it does then display them the other way round in the “address” box i.e. Northings first any reason why?)

The map blurb also refers to UTM zone 34 when talking about declination: “Declination 2005, UTM zone 34 is 6.1°E relative to UTM grid lines. correct line of march is… [blah de blah]” Any significance to that for georeferencing?

I’ve got a feeling I’ve knocked a setting somewhere because everything seems to be right, I’ve got a flat scanned map with verified (google) L/L co-ordinates, which match the UTM refs on the same map. I’ve watched/read a few tutorials which describe exactly what I’ve been doing, there aren’t too many steps in the process and it should be pretty simple.

First thing when I get home is to look for UTM zone 34N in the CRS list.

Should that make any difference, though? It’s just this bit:

And the are of map is only 70km from the easterly bound of that zone, but the UTM easting is 470km. So it’s not using zone 34N as a starting point?

Thanks very much for the offer Greg, I’ve 15 scans to do, so I need to work out what I’m doing wrong. I might ping one over anyway though, I’d imagine you won’t have any problems! I think I’ve only got pdfs on this computer, I’ll see what I can do.

and I might try MapInfo too!

I have used QGIS once, but can’t help with your problem, however I googled your error message and people are reporting the same message with a variety of problems.

So I had a peek at the source code and had a look around for the error message and rather amusingly, just above the message is a comment reading

TODO: Be more specific in this error message

A bit more poking around and that error could mean pretty much anything.

If you send me the offending image and I can replicate the problem I can help you find out what the problem is (Or at least I can help find which bit of the code isn’t working with your image).

I’ve just georeferences your 2nd screenshot above using the grid numbers and selecting UTM 34N as CRS and it fits okay. The format of the coordinates are:

x = 467000, y= 7747000

Huzzah. The UTM 34N was the key to sticking it in the right place.

Sadly, the probalems aren’t over, because the QGIS Garmin custom map generator just does what’s in the screen view at that moment, so if you zoom out to try to generate a map of a decent slice of what you’ve referenced, that’s all the detail that’s captured. i.e. no zooming back in afterwards in your garmin map – a pixel on the screen when you generated the map is a pixel in your custom map.

Zoom in in QGIS to get a decent resolution before you use the garmin custom map plugin and you only a get a custom map for the small chunk that was on the screen when you pressed go.

Baby steps…

Using okmap to produce the kmz files from the GeoTIFFs. Works lovely.

Now I can start playing to find out what’s the best balance between reolution and file size.

Pffff….

Good job I don’t need them til next February…