Posted on Leave a comment

Field devices for Sketch Layer

OCAD Sketch Layer screen

Recommended Tabs, Slates, Laptops for the field…

You want the utility of Sketch Layer but wondering which field device to acquire?

I asked OCAD Inc, they asked their resellers that also specialise in field mapping.

Off course

A person key to the efficiency of orienteering map production recently passed away. Charles Geschke invented the PDF (Portable Document Format).

He had been working with John Warnock on a page description language for Xerox. When Xerox decided not to pursue it further they left, founded Adobe and the rest is WYSIWYG history. Moving from direct print then EPS to PDF was a long process for some orienteering mappers but looking back I doubt any would regret it.

Posted on Leave a comment

Positional game changer for foot-o mapping

Latest technology at affordable price

by Geoff Peck, Ugly Gully Orienteers

I’ve been making foot-o maps for over 50 years now, and I think my latest GNSS acquisition is the biggest “game changer” I’ve seen…. sure, LIDAR is also a huge game changer, but there are still areas that don’t have LIDAR coverage whereas there is GNSS satellite coverage almost everywhere!

My GNSS history

I’ve been using GNSS devices since they became small enough to carry on foot, when the USA launched their GPS system. They have really helped in the production of orienteering maps, but still limited by their inaccuracy down under. I’ve found that most devices, including “data loggers” with better views of the satellites, are really only accurate to +/- 5m at best, and a lot less under tree cover.

They have been very good for general position and plotting isolated point features in the middle of nowhere, but can’t be used alone for “relative position” work where compass and distance methods still have to be used.

Recent developments

What has changed is that more satellite “constellations” have been launched (GLONASS, Beidou…). More recently the European Galileo system is now fully operational. Apart from increasing the number of satellites to obtain a fix, Galileo uses far better technology than the decades old GPS system, so is far more accurate.

In addition, there is now a network of reference “ground stations” (RTK) across Australia that can provide corrections for errors, such as cause by solar flares etc, in the raw satellite data. These corrections can be downloaded over the internet (NTRIP) and applied to the satellite calculations to increase accuracy.

Until recently the equipment required to use this new technology has been expensive (and bulky). However, a Spanish company has recently manufactured a small Arduino “board” featuring the newest U- Blox F9 multi constellation GNSS chip with RTK/NTRIP capability and a Bluetooth module. It was relatively easy to set up, although I am grateful to Peter Mousley for his frequent expert assistance and for explaining how RTK/NTRIP worked.

My GNSS present


I have been using this device for almost a year now and am truly impressed with its accuracy. When using NTRIP for corrections, the accuracy is in the order of 2-3 cm … yes, not a typo, that’s centimetres!

But this requires an internet connection which is not always available in remote bush (and sometimes not even available in urban areas). Also it is  only really usable within a reasonable distance of a ground station. But where available, having RTK/NTRIP has made it easy to measure the “native” accuracy of the GNSS.

Without RTK/NTRIP, the native GNSS has proved to be accurate to +/_ 1m in all situations, even under tree cover. Anyone who has  been involved in mapping will know that 1m accuracy is more than good enough for our sport, and so it has proved.

Proving my GNSS device

 My most recent project has been the Broadwater State Forest granite area. There was no RTK/NTRIP available, but I was lucky enough to have fairly good LiDAR coverage which I was able to use to check GNSS accuracy. There was 100% agreement between GNSS position and LiDAR point features at all times. So I was able to accurately plot all the boulders using the GNSS position.

More than once I marked a boulder as ‘medium boulder, S side’ then without realising returned to the same boulder from a different direction and marked it as ‘medium boulder N side’. The difference between the two positions was almost exactly the width of the boulder. When I walk back and forth along a vehicle track, keeping to the left, the GNSS shows two parallel tracks.

This GNSS gear

Apart from the Arduino board, there needs to be a dedicated remote aerial and Bluetooth module (which come as a package from the supplier), a metal “ground plane” to reduce multi-path effects, and a power supply (I used a standard USB external charger).

The Bluetooth module sends position data to a smart phone, where I use the Bluetooth GNSS app and one of Peter Effeney’s MyOmaps apps to record tracks, waypoints and display a KMZ version of the base map. Thus I can see exactly where I am when surveying.

The accuracy of all GNSS systems depends on the signal strength from the satellites. Avoiding your body getting in between the GNSS device and satellite ‘line of sight’ is one obstruction you can easily overcome. So mounting the antenna on top of your hat is essential. Unfortunately that almost guarantees getting some multi-path interference (reflected signals from the satellites). A ground plane keeps the interference  to a minimum. I use the top of an old metal tin, about 14cm diameter.

Acquiring the gear

GNSS setup

I purchased the main Arduino board (simple RTK2B) from ArduSimple. I added their multi band GNSS antenna – ANN-MB-00 (Galileo works on a different frequency to other systems). All for around 200 euros (A$320 at time of post).

To this I added a Keyestudio XBee 2.0 Bluetooth module (which just plugs in to the board) and made myself a plastic box to keep it fairly safe.

Parts list

  • Ardusimple simple RTK2B board
  • Multiband antenna
  • Bluetooth module
  • Ground plane (metal plate)
  • Hat (not necessarily from Bunnings, but works well!)
  • Power supply (or battery pack
  • Bluetooth GNSS app from on playstore
  • Tracking app such as MyOmaps, Maprun etc

From field to computer

Geoff GNSS ready to roll w

Regrettably I’m an ‘old school’ mapper so prefer to use this technology to help me draw my survey details on drafting film in the field. I then transfer that detail, plus GNSS data, into OCAD when I get home, You may prefer a set up with tablet to draw directly into mapping software.

If you do go down this track, then please do let us know how you get on. Geoff will gladly field queries at joffpeck at Feedback and reports are welcomed by Ken via this website or by Geoff.

Posted on Leave a comment

Lidar & Overlapping UTM Zones

Second zone DEM imported

by Rob Plowright

Intro by Ken: Other than Tasmania & ACT, all states & territories have 2 zones. NZ has just one zone. I recall struggling with marrying datasets from 2 zones for a map that was close to the edge of 54/55. So Rob’s experience will be valuable for the few who are faced with this issue. The general process will also apply to other types of data.

Coping with Australia’s 4 zones

Now that didn’t work

The other day I was doing some virtual exploring: processing lidar in OCAD to see if I could find some interesting terrain. One area I was interested in just happened to be on the boundary between UTM zones 55 and 56; first time I had experienced this. Getting adjacent lidar tiles from different zones to line up in one OCAD file proved to be more difficult than expected. After trying several different approaches and getting nowhere I finally managed to do it, with the help of a suggestion from Ken.

This involved processing the tiles in one zone then using Map > Transform > Change Coordinate System to change the map into the next zone, then processing the remaining tiles. There was one problem however: while the map (contours) transformation went well, the background images (hillshade, vegetation, etc)  did not.

Ken asked me to write-up the process for his up for his blog. Since there was the problem with the background images not transforming properly I sent the first draft to OCAD support. Gian-Reto got right back to me saying that while the method I described would work, there was a quicker way – just using the DEM Wizard. “That’s odd” I thought, “I tried that and it didn’t work”. Gian-Reto soon figured out there was a bug that meant southern hemisphere UTM zones did not process properly and he promptly fixed it.

So just in case anyone wants to know, here is how to do it.

The works

The lidar coverage

I will use an example from Kanangra in the Blue Mountains (not the area I was looking at – which shall remain secret for now).

  • I have five lidar tiles: two in zone 55 and three to the east of that in 56. They are:
    • Taralga201611-LID2-C3-AHD_7746232_55_0002_0002
    • Taralga201611-LID2-C3-AHD_7766232_55_0002_0002
    • Burragorang201805-LID2-C3-AHD_2226232_56_0002_0002
    • Burragorang201805-LID2-C3-AHD_2246232_56_0002_0002
    • Burragorang201805-LID2-C3-AHD_226232_56_0002_0002

As you can see from the double digit components above, the Taralga tiles are in zone 55 and the others in 56

Each tile is 2km x 2km and the numbers after ‘AHD’ give you the grid reference for the SW corner of the tile. So the  SW corner of the first Taralga tile is at 774000 6232000. and the first Burragorang tile is at 222000 6232000  You will notice that the Burragorang tiles have the same northings (6232000) as the Taralga tiles but different eastings.

1. Select co-ordinate system

The area is mostly in Zone 56 so I have decided to make the OCAD file zone 56. Set up a map in zone 56.  First process the zone 55 (Taralga)  tiles. (You could just as easily do zone 56 first).

Select co-ordinate system
Selecting co-ordinate system

The map now looks like this.

Lidar image
Lidar image first zone

Contours (5 and 25m)  are in grey and vegetation height is in the background (I have not bothered rotating the map to magnetic north for this exercise). The blue border shows the OCAD DEM boundary (which is oriented to zone 56)  but I have drawn in the actual boundary of the Taralga tiles’ data with the purple dashes. As you can see the Taralga tiles are sightly rotated relative to the Burragorang tiles, as you would expect since they are oriented to zone 55.

Looking closely
Rotation artifacts

If you look closely there is a little bit of junk in the gaps between the OCAD DEM and the actual (rotated) Taralga tiles.

2. Processing the other zone dataset

Now process the Burragorang tiles – but this time, in the DEM Wizard, make sure it says zone 56 for the DEM tiles.

DEM import next zone
Setting co-ordinate systems for next zone

Now the map looks like this…

Second zone DEM imported
Second zone DEM imported

I have made the Burragorang contours red for the sake of this exercise.

If you look closely at the above image, you can see that there is a large overlap between the westernmost Burragorang tile and the easternmost Taralga tile; almost a whole 2 x 2km tile. It is not always this much. In the area I was looking at before, it was only about 500-600m.

Also in the close-up below, you can see that the red and grey contours  are not exactly the same. This is because the two lidar sets are from different flights: Taralga 2016 and Burragorang 2018. In the other area I was looking at, both lidar sets (zone 55 and 56) were from the same year, and obviously from the same flight, as they matched exactly.

Difference in contours
Close up of difference in contours

The red contours above are more detailed (noisier) as, being more recent, that lidar is higher resolution. If  this map is just for a base map the slightly different contours is not necessarily a problem. But if you want to eliminate the overlapping contours you can crop one set.

3. Eliminate overlap

Since the Burragorang contours are more recent I am going to crop the Taralga contours. Start by hiding the Burragorang (red) contours and draw an area (light blue in this example)  over the parts you want to crop. Then use the Object > crop objects tool. You can also draw the cropping area so as to remove the junk around the edges.

Cropping the overlap
Cropping the overlap

And I get this…

Cropped overlap
Cropped overlap

Unhide the red contours to get this…

The full picture
The full picture

Up close the border between the zones looks like this…

Close up of the join
Close up of the join


  1. This process, excluding the DEM aspects, can also be used for non-lidar datasets over 2 zones.
  2. If you are new to lidar processing then download one of my DEM templates for use with the DEM Import Wizard. The template has 15 differentially coloured symbols to cover each of the contour selections in the wizard and to avoid confusion with any brown contours in your main or background map. Get one at
  3. If you have distortion in a small area, check out Map > Transform > Local transformation. It makes the adjustment of existing maps to geo-referenced base maps (hillshading, orthophotos etc.) easier and more accurate.
Posted on Leave a comment

2021 carto year starts with a laugh

Thanks to Kenneth Field of

Sort of seriously reflecting on 2020

Check out Bloomberg CityLab’s Your Year In Maps

Even more…

Jonathan Crowe’s The Map Room

Posted on Leave a comment

KML Export to MapRunF

For OCAD 12 and earlier version users

The latest OCAD blog announced that OCAD subscription editions now provide a straightforward process to get your maps and courses onto MapRunF.

Starter edition is your low cost route to this simplified process. Plus OCAD Australian and New Zealand buyers can take advantage of a lower price for 3 year subscriptions. Head to for pricing.

From the blog

To upload maps and courses to MapRunF, you need to export…

The full post is