Forum   |   Links    


Forum Home   Start New Topic   Edit Profile   Register  

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70  


Show Profile  Michael Posted: 14 November 2008, 4:05 AM  
I'm not sure if I have understood you correctly Bryan, I would have thought you were an expert! Excuse me if the following is sucking eggs. There seems to be two parts to this: setting up a map from scratch, and changing it if you decide it needs changing.

From scratch, the relationship (coords of the paper map origin, and the angle) would be first set in the scales dialogue. Then when you import contours in NZMG coordinates from shape files or DXF they are rotated appropriately so that paper north is magnetic north.

As to what that angle should be, I had an interesting time finding the authority on this. It isn't Land Information NZ, it's Geological and Nuclear Sciences. See If you read this carefully, you'll realise that it isn't the magnetic-true angle that you're after, but the magnetic-grid north angle. There are graphs of its variation for NZMG (and I'm hoping that its not very different for NZTM). Somewhere between 23 and 23.5 for Wellington, maybe closer to 24 for Wairarapa.

For practical purposes I don't think a degree out is a problem. (22 degrees WAS a problem for me on the first leg of a sprint race in a complex park, though:-)) So I wouldn't be worried about the change through time. If you want to change from zero to 20-something however, I think you CAN, and there's an option whether to rotate symbols oriented to paper north or not. There is a snag with any templates you have though, the "fit" doesn't follow the rotation and they will have to be re-adjusted.

I have also changed the offset values - from their NZMG values to the NZTM values. I was prepared for complications, but it isn't the map that is moving, its the real world. (I think this makes sense in the OCAD paper-based view of things!) I'm still learning here, be good to know if I'm off beam.

Show Profile  Bryan Posted: 14 November 2008, 5:12 AM  
Thanks for that Micheal - I did go to the same web page as you but used the wrong chart (which said 22.5 for magnetic declination vs true north - instead of the chart for NZMG)

One day I might migrate to Ocad 9 which will allow me to use NZTM.

On the Ocad site there is a flash demo showing how to georeference an existing map:

Show Profile  Michael Posted: 14 November 2008, 6:30 AM  
I think you can probably use NZTM in version 8. My understanding is that the "real-world coords" is whatever system you want it to be. If you put into the scale dialog the NZTM coords of a point in the middle of your map, then you could import files that are referenced to NZTM. I can't prove that tho, I haven't got any NZTM DXFs.

However I suggest you do move to version 9. And right now, if you upgrade 8 to 9 (CHF380/Euro245) you'll get version 10 for free when it comes out next year. See

Show Profile  Michael Posted: 15 November 2008, 4:09 AM  
Bryan wrote, "With some clubs creating a master OCAD file combining all their maps in one file..." Maybe I'm old-fashioned, but I'm wary of putting too much in one file. Eggs in one basket and all that.

I think the important thing is to have related maps on the same coordinate system, and with the boundary a tidy feature like a road, so that you can import one into another and have them match perfectly.

What file sizes are mappers getting up to?

Show Profile  Selwyn Posted: 15 November 2008, 8:01 AM  
NZTM is in OCAD8. By the way OCAD10 Beta is now released, full version early next year.
There seems to some variance in magnetic variation even if you stand still! I understand that True North and Grid north are slightly different, possibly one to 1.5 degrees. and there might be a slight difference bewteen NZMG and NZTM.
In Auckland using the old TOPO paper map variation with alleged increases, I calculated a variation of just under 21 deg. for 2010 The international web site gave me something about a degree less. My Garmin GPS says 19 degrees difference between NZTM and Magnetic. It's hard to a straight answer from offialdom, I presume because there are different norths. My solution has been to make all my Auckland maps 20 deg from whatever base map I'm using and all the base data is now aligned to NZTM. A single degree out here and there is not a problem for orienteers. But that one degree might cause some minor distortions in various backgrounds that are imported or if importing another OCAD map that didn't use the same deviation.

The BigMap that AOC has of Woodhill covers from Muriwai to Rimmer Rd being all the forest that our club is currently using and not using thanks to MTB and 4WD.
That map is 6.6 MB in OCAD, compresses to about half that. Most mapping members use broadband and have reasonable computers. For course setters we just create a partial map for them to use. Ideally all the peripheral stuff like legend, logo and outlines are kept as a separate map. It can be imported, or the actual map used as a background to the outlay map.
The 3 maps of LIDAR contours only that cover the same area of Woodhill together are 66 MB. But as the dxf files they were supplied were 400 MB. The 1m contours use only points to create "curves".
We bought 3 corresponding georeferenced TIFF orthophotos that were 260 MB each.
So I am using big background maps and recently upgraded to new computer with a gutsy CAD style video card.

Show Profile  Selwyn Posted: 15 November 2008, 8:18 AM  
Who is using a GPS for fieldworking?

Richard Hensby from PAPO has worked with our Woodhill BigMap to convert an OCAD map to a Garmin map. He also did the same with the LIDAR contour map, and the previous version of one area of the map that Michael Wood mapped 8 years ago "Whose Game". On the Garmin screen I can show one or two or all of the maps together and the pointer shows where the GPS says I am.
The 3 maps are 1.4 MB in Mapsource and also very readable in Mapsource. The LIDAR contour map for the Garmin is a selected part map to cover the area being fieldworked.
Richard has done this map as an experiment at this stage.

My first use was yesterday and I was really impressed.

How many other mappers are using a GPS and might find it useful? Obviously your map must be carefully and accurately georeferenced first.

And as an afterthought, how many orienteers might use or misuse it!

Show Profile  Michael Posted: 16 November 2008, 6:36 AM  
It took me a while to suss out these coordinate systems and its still hard. The important thing to note is that NZMG and NZTM are flat approximations of the earth's surface, and grid north is only the same as true north on longitude 173. If we're using grid data, its the magnetic-grid angle we should use. Seems from GNS it was 20 to 20.5 in Woodhill in 2005 so 20 is plenty close enough.

I haven't been able to think of any good reasons for finding a really accurate value, or for chasing the tiny change over time. The "real world coords" setting (including angle) will control the translation into "OCAD paper coordinates" and if the OCAD north is not exactly magnetic north its no problem. I think it may be possible to switch the real-world offsets from say NZMG to their NZTM values if it became necessary to import data on the other grid, but the angle should stay the same.

Selwyn points out that importing another OCAD map would escape the translation process, so its supposed magnetic north needs to be queried. (And in my experience so does its supposed scale!) If it has a "real-world" setting, then OCAD 9.x can import based on real-world coords, which would take care of the translation. And this is the key factor in all this - the NZ grids are known, stable coordinate systems, whereas most of our OCAD maps have no known location or orientation.

Show Profile  Michael Posted: 16 November 2008, 7:06 AM  
OHV's largest maps are its super-topos which cover 1300 from Wellington to Waikanae. (The same mapping is used for rogaines and MTBO, planners give me updates event by event.)

When I started on these some years ago I wasn't at all sure what the limits were, and with previous computers I did have "freezing up" problems, usually when I was swapping between large template files (orthophotos). At any rate I divvied up the area into 7 files. I put these on the same paper coordinate origin so I could join adjacent ones together perfectly. (The import using real-world coordinates wasn't then possible). These are now 2-5mb each.

I no longer have any problems that might be size-related. However an example of the "feeling in my bones" is a problem I have with "partial map" on one of these files. When using a curved "selected object" as the cut line, the partial map sometimes contains stuff outside the line, and some stuff (usu contours) inside the line is missing. By subdividing into files at least this problem is minimised.

A more significant issue I would think is that of a club which has several mappers (or contractors). One needs to give update rights for a file to one person at a time. One wouldn't want to lock up half of Woodhill because someone is working in one corner of it.

Show Profile  Michael Posted: 16 November 2008, 8:34 AM  
The symbol table again. And recalling that the IOF has started calling for submissions on a revision of the ISOM.

Selwyn has pointed out that (in addition to symbol renumbering between the 1990 and 2000 specifications) the symbol numbering in the sprint specifications is DIFFERENT AGAIN. There, the green circle is 418, the dot is 419 and the cross is 420.

This is not a problem if you start a fresh map with a fresh symbol table. But often we don't, I have my special symbols designed to be hidden, and therefore a new map will take the symbols from a previous one. Further I would think that at least some sprint maps start life as a regular map converted over to the sprint speci.

Calling here for opinions on what should be done about it. We could for example ask the IOF mapping committee not to arbitrarily change symbol numbering. Though I can't think of a good reason why they needed to renumber all the black symbols after 510 last time. (511-514 were shuffled, 515 disappeared, and everything after that came down by 1.) On the other hand there might be a good reason why the numbering might HAVE to be changed, and we might lobby OCAD for a technical solution which magically sorts out this stuff "behind the scenes".

Show Profile  addison Posted: 16 November 2008, 9:19 AM  
Hi Michael,

I think the key to the update rights issue is something that is based along the lines of an online storage for clubs. You download the latest version of the map for when you are doing fieldwork, then the moment you finish you reupload. This shows what file you used to do the updates - there is fields for descriptions of what you have changed etc... and the file online could even be 'locked down' until the file is reuploaded. Yes this would have issues, but the reality is if people download quickly, do their work, then upload - it would be a relatively smooth approach

Show Profile  The Map Guy Posted: 16 November 2008, 2:01 PM  
I have drawn several maps using NZTM co-ordinates with OCAD8. This OCAD version does not allow you to import GPX data files (OCAD9 does).

The largest OCAD map file I have used so far is 9.8MB (for a topo map) My older computer is coping OK, but the monitor refreshing takes a while. Much faster on my newer computer.

Regarding the symbol numbering differences: I wouldn't get too hung up about it as it only affects a few symbols and we know which ones they are. We are still going to use a green circle for a tree regardless of whatever number it has. I don't choose my symbols from the icon range by number, but by what they do (as illustrated by the picture on the icon).

Show Profile  Bryan Posted: 17 November 2008, 10:28 PM  
The problem with symbol and symbol numbers in Ocad/IOF I think can be answered using accepted normal database standards.

In my work, I really cringe when someone reuses the same key for something else - this is an absolute no-no for the database world.
Every object should have a unique key which does not change over time.

The IOF should come up with a numbering system which does not reuse a key for a symbol at any time in the future. This could be a simple number or unique letters. Other attributes like version, type, definition, colour, screens etc can all be related to the unique symbol. A symbol with a slightly different attribute (eg one version has line width 0.25 the other has 0.35) would require a different key.

Instead of the current funny numbering system in OCAD, the new unique numbers could be used meaning that importing symbols from other maps in the future would not be a problem. This could be done right now in OCAD but I think it will take a while for the IOF to assign unique keys if they ever get round to it.

Show Profile  Selwyn Posted: 18 November 2008, 12:20 AM  
Michael said "When using a curved "selected object" as the cut line, the partial map sometimes contains stuff outside the line, and some stuff (usu contours) inside the line is missing."

I have never encountered this problem. I have always used straight line mode to create my cut lines. Could that be the difference?

Show Profile  Michael Posted: 18 November 2008, 5:49 AM  
Yes, for this problem map the get-around is to to create partial maps with straight cutlines, which have never given me any problem.

I have sent the problem map to OCAD. As I recall they said something like, "yes the partial map function sometimes gives problems." They're a bit disappointing like that, one would hope for "thank you this has been registered as bug #1234, we'll let you know when its fixed."

Show Profile  The Map Guy Posted: 18 November 2008, 3:28 PM  
Interesting to note that the Partial Map feature has changed with with each version of OCAD since it was first introduced in OCAD 7. The rule of thumb is to make sure that at least one point from each symbol around the required edge of the map is inside the "cutting line" (i.e. the line symbol selected as a cutting tool).

If you've been sloppy with your drawing techniques you can easily be exposed when creating partial maps.

I wouldn't like to be without the partial map tool. I well remember the frustrations trying to manually cut segments from a map in the OCAD 5 and 6 days.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70  

Ruffneck Productions © Ruffneck Productions