Discussion: What shortcuts do you use in ocad?

OCAD defines very little amount of shortcuts.

I have added two:
ctrl+d for duplicate in place and
ctrl+r for change direction.

I will probably add
ctrl+t for remove vertex.

What do other people use?

I just colour everything in 'Settlement Green' to save time and field checks.

I still use pen, ink and Letratone, that way avoiding OCAD altogether ;-)

But seriously, I probably don't use enough shortcuts, though the defaults (in OCAD9) seem to cover most of what I need often for drawing. Perhaps newer versions have more possibilities so don't use the same defaults.

One of the most useful for me is for registering templates (background maps) quickly. A separate finger on each of: F7(Zoom in), F8(Zoom previous), and F9 (Adjust template) with the right hand on the mouse for drawing a Zoom box.

I can't remember what is a default and what I have changed - they seem to stick with me rather than be stored in each map file.

I suspect that Ctrl-H for "Hatch" might be one I have defined.

One should never ever adjust a template. A map made with even a single F9 cannot be correct. All of your sources must be georeferenced to the same coordinates to within the accuracy of your fieldchecking—otherwise you're pushing an error around and distorting reality. This was OK in the 20th century, but is no longer OK. If a source isn't georeferenced, find one that is; if it's not georeferenced, it's most certainly also not properly orthorectified. If a source is georeferenced but incorrectly, you can't use it. All online sources (Google, OSM) can be georeferenced to UTM with a minimum amount of work.

(ducks)

You didn' t really have to duck ;-) I was referring to registering the grid on scanned fieldwork to the map grid. One point move to get it close, then Zoom in/out to register the four corners taking just a few seconds witht he shortcuts. If the grid was traced accurately onto the FW mylar then it should always match perfectly -right!! :-)

Base-map creation is a whole different issue and for me (using OCAD9) , best done elsewhere. I used Manifold, and now mostly Global Mapper. I'm kind of new here, but I see F9 is a whole other topic which I'll happily duck.

Rubbish, T/D. I have a number of non-geo-referenced sources, and I like to use them as backgrounds in a geo-referenced OCAD file. Putting them in position with F9.

Other than fieldwork, what kind of non-georeferenced sources can you justify using?

I'm on a crusade here against distorted reality.

I hold down the left mouse button to help draw straight lines. My freehand straight lines are just not good enough.

On any map that isn't going to be used for a WRE, and where you can't get a geo-referenced background map, ie 90% + of all maps produced. For example, I make around 20 school maps a year, plus 2-3 maps that are used for street orienteering or a local sprint event. None of these need to have a good source, however we have been fortunate here in that digital geo-referenced photography has been available free. This is about to change, and we may end up having to pay big money and will only be able to use it for major event maps. Bear in mind T/D that not every mapper spends all of their time making world-class maps.

T/D, would you please clarify your crusade in as simple terms as possible.
Are you saying that all new or revised O maps should be georeferenced?
or that a georeferenced base should not be distorted/ polluted with non-georeferenced data?
or something else?

Yes, yes, and yes. I've had near heart attacks witnessing our mapper friends take a perfectly georeferenced photo with <1 m absolute accuracy and F9 the crap out of it so it'd fit something else they like more (usually their fieldwork, or an old map). There's this mindset in orienteering (partly contributed to by the availability of OCAD's F9, and the fact that OCAD is a drafting aid, not a GIS editor) that absolute accuracy doesn't matter and it's sufficient for things to just "look right". Well, things that look right to someone but aren't actually right have a high chance to not look right to someone else—perhaps that very same someone who's just moving slower.

If your map is georeferenced, you have instantly bought yourself compliance with the future. There will only be more data in the future, and all of it will be georeferenced, and it will only be more accurate than what you just used. If your map doesn't fit absolutely, then there's a very high chance whoever works on it next (maybe also you) will throw it out of the window and start anew... because standards will have changed.

If your map is georeferenced, you instantly bought yourself context. You can stitch maps along a boundary that are made with different surveys at different times. You can take a smaller map and drop it into a larger map and everything sits "right there" without need for further fixing up. If at some point orienteering truly joins the digital age, you'll be able to serve up tiles from your map. And last but not least, when you go out into the field, the GPS track fits where it should fit...

F12 for hatched areas. I think. (I haven't done much drafting lately.)

What's an F9?

T/D I'm also on a crusade to geo-reference legacy maps. Well all orienteering maps actually. I think we just differ on methods.

One example. Only recently has it been possible to obtain geo-referenced imagery around here. Sometimes we have to wait for it to "fall off the back of a truck". But for years we've been able to obtain free non-geo-referenced but ortho-rectified photos from the government land agency. Well they are "sort of" geo-referenced because they are related to the old paper map sheets. So the cornerpoints are exactly known. I suppose I could have geo-referenced these outside OCAD. However I chose to position them in the real-world coordinate system using "template adjust".

Another example. Features traced from the above source are by definition geo-referenced. They provide the framework for placing legacy maps into position. It's now possible to import/rubbersheet these old maps into position, but often they are so bad that they are best used only as a background. Each case is different, but cutting a jpg into chunks and separately fitting is often my technique. Then print for re-fieldwork.

Another example. The above orthophotos are fairly grainy. Google Earth can be high res but its positioning and rectification is suspect round here. If there's nothing else available, saving small bits and one-by-one fitting to the framework (established above) is a way of "containing" the distortions.

Glad to find someone who shares the crusade. Some mappers here understand but many peoples' eyes glaze over when you mention geo-referencing. Do you have free high res g-r imagery for the whole USA?

Indeed we do. We have free imagery with 1 meter or better resolution for most (all?) of the U.S, referenced to UTM NAD83, and we have free digital elevation models (on a regular, uniform lat/lon grid). The DEMs are lidar-derived in many places; there are several States with 100% lidar-derived DEM coverage. The non-lidar-derived DEMs are no better or worse than the old-time paper maps, which are also available georeferenced.

Google (or its providers) have resolution far superior to 1 m for perhaps all of the U.S., and their tiles are of course georeferenced—you just have to know how to transform EPSG:3785 to UTM if you want to work in UTM in OCAD. Of course you're violating the terms of user agreement if you download enough to make a rogaine map, but probably not if it's only enough for a Sprint map. Doesn't OCAD 11 understand EPSG:3785 natively? (meaning it will fit this projection to UTM so that you don't have to warp the photo yourself?)

Lucky you. Seems we have different data sources and hence methods. I wonder if your assertion should be: "One should never adjust a geo-referenced template":-))

My short cut is along the lines of "Juffy, could you read the above and then use your planet-sized mapping boffin brain to help me?" It usually works a treat, but used to require unfulfilled promises of cartons of beer.

tRicky - F9 key on your keyboard is the shortcut used to adjust a background map.

Lucky old USA. Presumably all the free imagery & lidar is ultimately paid for by taxpayers, so T/D better hope the current Republicans never get back.

I miss beer. :(

Actually business loves free stuff from the government, they just talk like they couldn't care less. USGS's funding is relatively independent of the political climate.

Most of the nationally available lidar seems to be paid for by the individual States' agencies.

Huh, I used to click on the dropdown "Background map" menu and clicked "Adjust". I have now saved myself half a second in time!

Times change, and it's good to change with the times. Some things don't change though, and going forward, the thing that has always mattered most with respect to O' maps will still matter most.

What matters most is not whether or not a map is georeferenced but whether or not a map is useful.

To the extent there is a great ill plaguing maps today, it isn't a lack of georeferencing, but a lack of legibility. The un-useful and excessive detail is drowning out the useful and necessary.

Does Georeferencing handle plate tectonics?

+1 to Swampfox.

A bit of a thread hijack to talk about georeferenced source data, but a good one.

I think much of what you say is right in priciniple T/D. With the availability of more source data georeferenced then it doesn't make any sense not to do that with orienteering maps. Data is way more available in US than UK (or at least more available within financial constraints) but no reason not to do what you can get in that way. Anybody starting a new map in OCAD should definitely go down the georeferenced route.

Pretty much every map I've ever updated has had some important set of line features in the wrong place, and only a bit of work with GPS and/or other known good sources really debugged which bit(s) was at fault. Mistakes like that can be (and are) there for years.

However, a georeferenced map does not necessarily make it a good map and one that is "F9"d all over the place does not make it a bad map. The skill is with the mapper, and understanding what the importance of what you are adjusting to fit, and the end effect on that accuracy to the orienteer. E.g. copying of a vague vegitation boundary from a random aerial photo without georeferernce/orthorectified will need a bit of localised F9 work and will usually produce a reasonable result. If that photo is more recent than an "proper" one, it may actually produce a better result as vegitation does tend to grow. (Maybe bad example with good aerial stuff these days, hopefully you get the drift)

They sell beer in cartons in Western Australia? Strange. Where I live, it comes in bottle or cans. I don't think they even sell milk in cartons around here any more.

Yes, georeferencing does account for plate tectonics.... sort of.

The most established world coordinate system is WGS84, favored by the DOD,and I believe this is used for most GPS systems. However, the USGS and NOAA use the NAD83 system, which is nearly identical to WGS84, but is defined to remain stable for points on the North American plate - accounting for plate drift. Islands in the Pacific sit on a different plates (Pacific and Mariana plates), and so there are variations of NAD defined for them.

NAD83 is periodically updated to account for local deviations that occur due to plate tectonics. When a new coordinate system is released, it is accompanied with formulas that designate how to convert between systems. I think the biggest recent release was 2010.

This is why I would say that OCAD (at least in my outdated version) doesn't really support georeferencing. It stores coordinates, but doesn't store information about which reference system is being used, and doesn't have the ability to transform between major systems.

A carton is more usually known as a slab, and consists of 24 stubbies or tinnies. Hard to believe though that Tooms would be offering Juffy cartons (plural).

JJ - the cans come in cartons (of 24 or 30 cans). A can / bottle of beer won't get you many mapping favours.

Nice catch, BsB. Heh heh.

Gah... Too slow

It's quite easy to believe Tooms would offer me a carton. Getting him to pony up the goods is another matter entirely. :p

I'm still waiting for my Connoisseur tub, empty or otherwise.

I agree 100% with Swampfox. However peppering your map with correct but unnecessary information cannot be accomplished with an OCAD shortcut... or can it?

So here are 4 of my custom shortcuts:
ctrl+d, duplicate in place an object - good when working on some form lines from a good elevation grid.
ctrl+f, (f==force!) - change symbol to different one - good as for crl+d.
ctrl+r - reverse direction of an object.
ctrl+t - delete node from line

TD you said you can georeference google. Do you mean the photos? I have always been wary of them - I didn't think google maps photos are necessarily that accurate - ie photos that are not 'orthophotos' have inherent distortions in them. Especially in hilly terrain. Certainly where I am (japan) if you zoom in and compare the map data (which is detailed and accurate - not the contours but roads, buildings etc) with the photos there are discepancies.

Anyway I am curious as to how you georeference data from google or OSM, etc.

I've also found GE images to be unrectified where I've used them. (Alberta, British Columbia and in Barbados). It's quite noticable in hilly terrain. Perhaps it's a copyright issue. In BC at least the government isn't very generous with sharing their data yet, and they have the orthos.....

I am cheap so I have to jump through hoops to get the referencing, and sometimes it doesn't work. I am trying to figure out exactly why, and hope to be able to generate a consistent set of instructions soon. If you have proper software like Global Mapper, I bet things become much easier, but a cheapie like me basically downloads as much as possible in SAS.Planeta before Google cuts off, and then warps in Gdal. Same recipe for OSM, except it never cuts off. SAS.Planeta is a wonderful tool but it's very limited in the formats it can export, therefore the hoops.

Google maps uses EPSG:3857, which is a weird projection, using mercator, but with a shperical spheroid, kinda. See http://alastaira.wordpress.com/2011/01/23/the-goog... for more info.
You should be able to grab tiles, merge them, and just reproject to get them referenced ok.
I would guess they are all orthorectified, as otherwise it would be a pain for them to get the road data to match up.

... get the road data to match up. It doesn't always round here. And they need photos from all over the world so you can expect they have to accept some dodgy standards.

So I've had a distrust of Google photos from way back. If I HAVE to use them, I save small bits at a time, and fit them separately to a trusted framework, to at least contain the distortions. Guess what shortcut key I use for fitting.

Your mouse?

(waving hand) I know, I know!

About google's images - you should not be stitching them together unless their license has changed.

And SAS Planeta is awesome. AWESOME!

T/D - what should the maps be georeferenced to? I'm using State plane coord system, which I think is not the correct choice. Mostly because the lidar data comes in it.

about georectifiying - from SAS Planeta store as KMZ, then load in global mapper, then store as tiff, open in OCAD.

Yes. The Global Mapper is the part that I am missing.

I use UTM because all USGS's photos are to UTM. You can certainly work in state plane, you will just need to rewarp your photos to state plane if they are originally in UTM (you can use gdalwarp).

@Tundra/Desert I'm pretty cheap as well, but have found GM well worth the investment. Mostly got it as it was recommended by a LIDAR provider for manipulating their data.

But also, I've just assembled a basemap in GM which included all of the following:
- an unprojected 1:50000 DEM (from which I generated 5m contours with GM)
-1:50000 Topographic vector data (NTS -Mercator)
-1:50000 Scanned NTS Topo
-a 1:20000 ortho in BC Albers projection (state plane equivalent?)
-Some gps tracks (UTM)
-some trail data extracted from a pdf (not georeferenced)
I then exported geotiffs and dxfs in UTM for use with OCAD
...and all this with nary an f-keyword ;-)

I am curious as to how you georeference data from google or OSM, etc.

Here's the most latest cheapie's version, no Global Mapper:

1. Mark your rectangle of interest in SAS.Planeta. Then use both "Download" and "Stitch" at exactly the same zoom. SAS tries to sneak in a different zoom when you "Stitch". Save as PNG; click the checkbox "Create georeferencing file", ".w". You will find map.png, map.pngw, and map.prj as the outputs.

2. Photoshop your PNG as you see fit. Backstreet Boy swears by edge enhance for OSM (Mapnik) exports if you are going to print the resulting product on dead trees. Makes the streets and trails stand out better.

3. Open the .pngw file in Notepad and see what the scale and upper left corner are. The horizontal scale (in meters per pixel) is the first line, the vertical, the fourth, and the last two numbers are the easting and the northing. Then figure out the easting and the northing for two more corners (you only need three out of four), write them down.

4. gdal_translate -a_srs "map.prj" -co COMPRESS=LZW -gcp 0 0 UL_easting UL_northing -gcp image_width 0 UR_easting UR_northing -gcp 0 image_height LL_easting LL_northing "map.png" "map1.tif"

5. gdalwarp -s_srs EPSG:3785 -t_srs EPSG:26910 "map1.tif" "map.tif"

The file will come out uncompressed and georeferenced in UTM. Older free OCADs only understand uncompressed. The destination EPSG, 26910, is for my UTM 10N. Put in the appropriate EPSG for your UTM zone or your state plane, I believe Gdal also understands state plane mnemonics.

You may be violating Google's license if you do this with Google's maps or images, and/or if you distribute the generated product. We don't redistribute Google's products. If you are going to incorporate or redistribute OSM, you have to abide by the Creative Commons license. You have been warned.

If you have Global Mapper, see ledusledus's instructions above.

P.S. I wouldn't be cheapie if orienteers would actually value the supplies, effort, and time that go into putting on a quality production, but for now free software is all we can afford.

After reading Google's ToS and Restrictions, and then reading this article on fair use, it appears you may, or quite possibly may not, be able to use GE images.

If you are able to use them, here is his method for importing georeferenced GE images.

I've also found the graticule lines in GE aren't straight, especially in hilly terrain. I had thought that meant the GE images weren't rectified, but I'm now thinking that perhaps GE images, unlike a map, are the earth viewed from a single point, so may be distorted at the edges when zoomed in, similar to the distortion of an original unrectified air photo?

T/D thanks for that!

What are you trying to do with the gcp data to gdal_translate? gdal should read the map.pngw file directly to get that data.

Ed, as what argument do I feed Gdal the .pngw? I couldn't see where the .pngw would be able to come in. All I saw in the instructions for gdal_translate was the gcps. The .pngw is just a text file with the scales and the 0,0 pixel coordinates, it's not a georeferenced bitmap.

There are other formats that I can feed into gdal_translate, of course, but the only one that contains georeferencing within the file and in which there is overlap between what SAS.Planeta can export and what Gdal can read is JPEG2000. SAS's JPEG2000 export is broken, and Gdal's JPEG2000 import is also broken in the latest version, so double whammy. Just like I said above, those who are cheapies have to jump through hoops to get what they want for free!

Contrary to widespread public perception, you can redistribute screenshots of Google Maps and even charge for them without violating the Terms of Service, as long as you never exceed a certain maximum image size for a given zoom level. This size is such that you can't put on a meaningful street orienteering event using a Google Map screenshot even if the event is of a Sprint length. This is a summary of my research without references.

http://www.gdal.org/frmt_various.html#PNG just says that the png driver will read world files with .pgw, .pngw or .wld extensions. I haven't tried it, but I think it will automatically read the world file if it is in the same directory and has the same name as the png file. With the world file, and the prj file, gdal_translate should have all the info it needs. Using the gcp syntax is doing the same thing, but with more steps.

Looking at the gdal source, http://trac.osgeo.org/gdal/browser/trunk/gdal/frmt..., it tries two searches for a world file when you open a png. The first tries to derive the extension from the driver format, and looks for a .pgw, or a .pngw file. It then always tries to find a .wld file.
I would try running the gdal_translate command without the gcp parameters, and see if it works just automatically reading the pngw file. If that fails, try renaming it to a .wld file and see if it reads that.

You are certainly right, I didn't read that part. Simplified instructions follow. I verified that they work for me.

---

1. Mark your rectangle of interest in SAS.Planeta. Then use both "Download" and "Stitch" at exactly the same zoom. SAS tries to sneak in a different zoom when you "Stitch". Save as PNG; click the checkbox "Create georeferencing file", ".w". You will find map.png, map.pngw, and map.prj as the outputs.

2. Photoshop your PNG as you see fit. Backstreet Boy swears by edge enhance for OSM (Mapnik) exports if you are going to print the resulting product on dead trees. Makes the streets and trails stand out better. Don't change the image size in pixels, though.

3. Make sure the .png and the .pngw files have the same base name (only the file extensions are different) and are in the same directory. That is, if you changed the file name after Photoshopping it, also change the name of the .pngw to match.

4. gdal_translate -a_srs "map.prj" -co COMPRESS=LZW "map.png" "map1.tif"

5. gdalwarp -s_srs EPSG:3785 -t_srs EPSG:26910 "map1.tif" "map.tif"

The file will come out uncompressed and georeferenced in UTM. Older free OCADs only understand uncompressed. The destination EPSG, 26910, is for my UTM 10N. Put in the appropriate EPSG for your UTM zone or your state plane, I believe Gdal also understands state plane mnemonics.

You may be violating Google's license if you do this with Google's maps or images, and/or if you distribute the generated product. We don't redistribute Google's products. If you are going to incorporate or redistribute OSM, you have to abide by the Creative Commons license. You have been warned.

If you have Global Mapper, see ledusledus's instructions above.