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  jeffg Posted: 26 November 2015, 8:55 AM  
No, at best I notice the dots and classify it as (some sort of) scattered trees. Can't say that I make that much effort in a race, but if they were more readily distinguishable I'd probably make more effort.

Show Profile  fraser Posted: 28 November 2015, 1:05 AM  
Thanks for the replies. I will do some more testing to decide if it is still too glaring and hard to read with green dots as per the ISOM specification. OpenOrienteering Mapper had a small version update this week which included changes to the green colours for printing (cmyk option) so I will see how that changes things too once I get it printed at the print shop versus my own home printer.

The minimum area for 402 and 404 is particularly large for these symbols, 10 and 16 square mm respectively, so if used correctly there shouldn't be any issues with identifying the difference other than ignorance, which I have probably been guilty of as a non-mapper in the past.

I will add OOM has a useful feature with the measuring tool window showing a warning if the selected object is below the minimum size.

Show Profile  Michael Posted: 1 December 2015, 4:18 AM  
I installed the latest OOM and had another go at transferring OCAD files. I previously had problems with the geo-referencing. I succeeded this time but am not entirely sure whether it was just luck. I list below the steps I took in the hope that others can increase my understanding.

1. Opened an OCAD file containing some GPS tracks and waypoints turned into symbols; and some aerial photos in the background exactly positioned via their world files.
2. There were some messages about some symbols not being able to be translated, that's another topic I think. The important thing is that the photo positioning seems fine.
3. Want to re-import the GPX to see whether it would sit directly on top of lines in the file. Note the way OOM treats GPXs is to open them as templates (backgrounds). Chose the geo-referenced option. This opens the geo-referencing dialogue.
4. I would have thought it would know from the OCAD that my coordinate reference system was NZTM, but apparently not. I can put in a Proj.4 string, or use the EPSG method (2193 if I remember correctly).
5. This then stuffs up the offsets (coords where the paper origin is) and makes a difference between the declination and grivation numbers. Proceeding without fixing them up is I think what led to my problems before.
6. I don't know what it decided my offsets were but I put them back to the right values. Editing is strange, I couldn't select the whole field, but I could select the bit before the decimal point and retype, and the bit after. Almost as if I wasn't supposed to be doing this!
7. The angle in OCAD is the grid-magnetic angle. It sums up the declination (true-magnetic) and the convergence (grid-true), only on latitude 173 does grid=true for NZTM. Seems that OOM calls this the "grivation" and it is now wrong. But you can't edit it. You can only edit "declination" and you have to fiddle it to get the grivation right. There is the same problem with editing this field as above.
8. After saying OK, OOM says "declination changed, do I want to rotate the map", I say no (although not the default). I have lots of adjacent maps with the same offset/angle and I don't care if my grid is not PERFECTLY mag north, more important is for them to be consistent.
9. After all this, the gpx file opens in exactly the same place as it did in OCAD. Whew.
10. To fully test the aerial photo positioning, I removed some and re-opened them (world file option), they fit fine, but I would think only because I had adjusted the geo-referencing parameters as above.

The above seems soooo tortuous that I think it can't be the intended method. Could someone who understands the geometry behind map projections please enlighten us?

Show Profile  Michael Posted: 9 December 2015, 2:47 AM  
Something more straightforward. At the recent sprint mapping seminar in Australia the use of black X's for all sorts of miscellaneous objects was discouraged. They are supposed to be described in the legend, so can only be used for one or two things, eg "car wreck/roadside transformer" - whatever is most useful on the map. To cover all the things that are in urban parks how about using the "fodder rack" for picnic tables and fixed barbeques? Then X can be used for something else.

Show Profile  Martin Posted: 10 December 2015, 6:08 PM  
ISOM 201x final draft:

Show Profile  fraser Posted: 10 December 2015, 11:40 PM  
I see 404 Rough open land with scattered trees has changed to 50% yellow to match rough open. The dots slightly reduced and they show an example using green dots now, and have even added a 60% green option which is pretty close to what I had dabbled with.

402 Open land with scattered trees is now yellow with white dots and the green dot options have been added to this symbol too.

There are ocad and mapper symbol files that can be downloaded from this page to test it out

And all course planners take note:

All overprint symbols shall be printed over the map content (transparently). They shall never mask out other map

Show Profile  Michael Posted: 12 December 2015, 4:32 AM  
(Please excuse me if you have something underway Nick.) National federations have been invited to comment on the "final draft" of a revision of the ISOM. Its not everyone's cup of tea, but any mappers who want to contribute to a NZ view should contact the ONZ Mapping Committee. See that link by Fraser above. Another link that is relevant is submissions to the previous draft, including by NZ.

Show Profile  fraser Posted: 26 December 2015, 1:16 PM  
OpenOrienteering Mapper version 0.6.0 has been released.

They have been working towards this milestone for a while and is worth updating your version.

Show Profile  Michael Posted: 11 January 2016, 1:18 PM  
Reshape may have been the most significant feature of version 11. What of version 12? This may be eyesight-related, but I seem to spend an inordinate amount of time trying to pick a point on a line or edge. You can now define larger marks. These little things can be very productive. Other suggestions?

Show Profile  Michael Posted: 12 January 2016, 2:51 AM  
This is really really rare but it might be useful to know that OCAD files can contain bad objects. Optimise/Repair deals with some of these, but doesn't deal with eg line objects of zero length, rectangles with one dimension zero, etc. How they get there I wouldn't have a clue, and they seem to do no harm. Until you use the file with Condes. I've found some problems lately. Finn Arildsen just has to be the world's most responsive program author, he confirms that there are some odd objects that he has to trap when displaying the map, and presumably we haven't exhausted all the oddity types yet:-))

Show Profile  Michael Posted: 21 January 2016, 4:07 AM  
For OCAD 12 users. Doing my first real job in OCAD12 and having a bit of bother with out of memory stoppages after extensive editing sessions. It's only 2mb so not what you would call big. The lesson is, don't have OCAD 11 running at the same time. There's only one "unsaved map" kept by OCAD, and you miss out on the chance to "open unsaved map?" Let me know if you have any similar issues with 12.

Show Profile  Michael Posted: 21 January 2016, 4:13 AM  
That remark about larger marks in OCAD 12 was not right. Larger marks can let you see them better but it doesn't control picking an object or vertex. That is controlled by a preference: drawing and editing: tolerances. I've been experimenting and a big tolerance isn't necessarily better. When there are several objects close, it sometimes stubbornly refuses to select the one you want. Gone back to a smaller tolerance of 5 pixels.

Show Profile  Michael Posted: 9 February 2016, 2:17 PM  
Four out of six maps at the weekend were at 1:3000 for everyone. Looks like we're in for a repeat of the 1:15,000->10,000->7500 saga. I thought the best area was the tightest one, Whitireia Poly, and I wouldn't have liked a smaller scale. But perhaps if a vet could read it, younger people could have managed 1:4 or 5000?

Show Profile  Bryan Posted: 10 February 2016, 12:47 AM  
Even at 1:3000 parts of Whitireia were hard to read - eg one area had two paths, several fences and a covered area - all within a few square metres - at 1:3000 looked impassable at first glance - probably required simplification.

I think if the area was used for a WRE/national or international event which required offset printing, a 1:4000 map could have been created but it would have required extra work to simplify/generalise more.

At the moment comparing offset versus digital printing, offset approximately about 5-10% better but I think this is changing. There was little difference between the digital prints and the offset prints for the 1:4000 Raumati map.

Show Profile  onemanfanclub Posted: 10 February 2016, 10:07 PM  
That particular spot on the Whitireia map Bryan refers to certainly generated a lot of discussion. I think it's a good example to use when we think about what to map and why. I know I'm guilty of this myself, but rather than try to squeeze in every bit of detail that is there on the ground, we need to think about what will be useful for the competitor to know. In this case, all the competitor really needed to know was that there was a passable gap between buildings, and maybe a small section of 'normal' fence or similar could have been used to indicate there was enough 'barrier' created by the fences and split level paths to slow you down relative to a completely open gap?

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