-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISSprOM 2019-2 symbol set #1037
Comments
I'm not sure these are official notes, and I think final draft will differ, but anyway I put this here so you can get a hint of what we can expect. So please, use this just for information so far. 4.1 Landforms 4.2 Rock and boulders 4.3 Water and marsh 4.4 Vegetation 4.5 Man-made features 4.6 Technical symbols 5.7 Overprinting symbols |
Is the document available somewhere? |
No since it's not official. I think it will change a bit before it gets
official.
2018-01-29 9:23 GMT+01:00 Aleš Hejna <[email protected]>:
… Is the document available somewhere?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1037 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APa4D2GEFM4jdLgtGwuRsF00yLKj4ELeks5tPYALgaJpZM4RvqpU>
.
|
This still needs work to align with ISOM2017.
Extra remarks:
I would very much appreciate if the same code number would not have a different meaning in ISOM vs. ISSOM. Code numbers offer unique identification independent of time and language. In that sense, the renumbering in ISOM2017 was a mistake. I would even appreciate an ISOM2018 restoring old numbers where appropriate ;-) Don't mind the gaps. Most significant change is that the the levels of brown for paved area now indicate the level of traffic. Still a quite subjective measure. And narrow footwalks along busy roads (or parking cars) cannot be mapped to scale, anyway. @krticka You should be subscribed to this issue. |
I agree that numbers still need some work. I think it would be good idea to
give subnumbers, as for the parts in a cliff for example. Today it's ot
standardized fully, so interpreting it in programs might be done in
different ways.
2018-02-06 18:19 GMT+01:00 Kai Pastor <[email protected]>:
… This still needs work to align with ISOM2017.
- 104 Slope line is part of Contour/Index contour/Form line in
ISOM2017.
On the other hand, this change made effective code numbers for slope
line symbols non-standardized.
(I start to believe that we should turn slope lines into a "dash
symbol" feature of the contour lines, i.e. maintained by marking dash
points on the contour.)
- 105 Contour value is part of Index contour in ISOM2017.
As with slope line, this made the effective code number
non-standardized.
- Cave become part of Rocky pit in ISOM2017.
On the downside, the symbol alone no longer carriers the full
information. While it must not be rotatable for Rocky pits, it must be
rotatable for most caves.
- Major power line got an alternative representation of carrying masts
in ISOM2017.
- Pipeline is no longer just pipeline in ISOM2017.
Extra remarks:
- 108.1 is a number with decimal point. It shouldn't be used in the
standard.
I would very much appreciate if the same code number would not have a
different meaning in ISOM vs. ISSOM. *Code numbers offer unique
identification independent of time and language.* In that sense, the
renumbering in ISOM2017 was a mistake. I would even appreciate an ISOM2018
restoring old numbers where appropriate ;-) Don't mind the gaps.
Most significant change is that the the levels of brown for paved area now
indicate the level of traffic. Still a quite subjective measure. And narrow
footwalks along busy roads (or parking cars) cannot be mapped to scale,
anyway.
@krticka <https://github.com/krticka> You should be subscribed to this
issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1037 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APa4D9s6o6g7DyKrgphKfT8MZ5JZ5Yv3ks5tSImngaJpZM4RvqpU>
.
|
Discussion on ISSOM 201X in "Orienteering Mappers Int." group on Facebook As addition, there is issue with color naming in all standarts, as discussed under this image published in "Orienteering Mappers Int." group |
ISSOM 201X final draft (ISSOM 20XX/2018?), as published above: What has changed from ISSOM 2007: ISOM 2017 Appendix 1 -- CMYK printing and colour definitions: |
Regarding the numbering. I suggest to make a formal proposal and give it to MC IOF (from OOM developers). It can concern both ISSOMxx and also ISOM2017 (there shall be also an update of this one). What do you think? Or is a discussion here as a form of feedback to MC IOF enough? Could you scrap it from here Luděk? @krticka |
Good idea to send a proposal. |
When a white border (framing) is added to numbers they become opaque and have no overprint simulation. This is due to a technical limitation that seems to effect all orienteering software. The Appendix does suggest how to achieve a pseudo effect but it seems a bit dirty. You obviously need to also move the framing colour track accordingly:
I highlight this so everyone is aware of the implications of this proposed change. I would not like to see framing introduced at the expense of proper overprint simulation. It is still important, even for numbers. |
Agnar Renolen posted in "Orienteering Mappers Int." group on Facebook
|
Many interesting details published in IOF Meetings minutes (January 19-20, 2018) Read this first:
Also published invitation for ICOM'2018 in Prague, Czech Republic (October 5, 2018)! P.S.: @dg0yt, what you think about presenting current state of OpenOrienteering Mapper on ICOM'2018? |
IOF Council Meeting Minutes 189 Published
|
Presentations from 18th ICOM now available for downloading as PDFs:
|
This is wrong. It is neither backed by the presentation, nor the talk at ICOM 2018. |
It will be not official part of ISSOM. It will be published separately as recommended use for school maps. We don't want to make any clash with the existing school specifications which are used in many countries like sCOOL etc. More it should serve as a guide for new member countries and for those who wants to use it.Dne 17. 10. 2018 6:45 dop. napsal uživatel Kai Pastor <[email protected]>:
Major addition is that official IOF School-O symbol set would be part of upcoming ISSOM 2018 (ISSOM 20XX)
This is wrong. It is neither backed by the presentation, nor the talk at ICOM 2018.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
|
Sorry me, I was wrong.
OK. Lets discuss |
ISSprOM 2019 published by IOF and would be valid since January 1, 2020 ISSprOM 2007 (corrected in November 2012) valid until December 31, 2019. TODO
|
For old sprint specification I think it is good to keep valid name ISSOM
2007.
…---------- Původní e-mail ----------
Od: app4soft <[email protected]>
Komu: OpenOrienteering/mapper <[email protected]>
Datum: 18. 4. 2019 19:24:21
Předmět: Re: [OpenOrienteering/mapper] ISSOM 2018 (draft) symbols set (#
1037)
"
ISSprOM 2019 published by IOF and would be valid since January 1, 2020
ISSprOM 2007 (corrected in November 2012) would valid until December 31,
2019.
TODO
* Keep ISSprOM 2007 symbol set (for compatibility reasons;
* Create and add new ISSprOM 2019 symbol set.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
(#1037 (comment))
, or mute the thread
(https://github.com/notifications/unsubscribe-auth/ADZ2ZGVOZKCNDEEAN5ODYILPRCVDZANCNFSM4EN6VJKA)
.
"
|
FTR, Orienteering South Australia published on own site symbol sets in OCAD12 format:
|
Hello! I've finished to implement ISSprOM 2019 symbol set. I'm going to test the implementation on our local events in the beginning of September. You are welcome to join to testing and send me feedback or make a commit by yourself. You can get file here. |
Thanks @yevhenmazur. I will try to merge this in smaller pieces.
|
Possible to suggest good numbers to IOF MC?
måndag 19 augusti 2019 skrev Kai Pastor <[email protected]>:
… Thanks @yevhenmazur <https://github.com/yevhenmazur>. I will try to merge
this in smaller pieces.
- We can take the CMYK values from the IOF docs, but the layers
"proposed" by IOF might neglect aspects which are important to us
(upgrading of older maps, reusing existing translations,
overprinting/non-overprinting equivalence).
- We may need to carefully review which numbers we are going to use.
The IOF standard merged multiple symbol variants or aspects into a single
code number.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1037?email_source=notifications&email_token=AD3LQD3TMPKG6XKUKCNAN6LQFL3KXA5CNFSM4EN6VJKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4UDUXI#issuecomment-522730077>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD3LQD5PXSAB446K7CJVT6TQFL3KXANCNFSM4EN6VJKA>
.
|
Probably not in another form than our implementation. I cannot do that work twice. |
Good enough.
Den mån 19 aug. 2019 kl 23:45 skrev Kai Pastor <[email protected]>:
… Possible to suggest good numbers to IOF MC?
Probably not in another form than our implementation. I cannot do that
work twice.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1037?email_source=notifications&email_token=AD3LQD4N4IUVVYHX5GSNVFTQFMIBJA5CNFSM4EN6VJKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4UMRTY#issuecomment-522766543>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD3LQD3LVAJDKNWWTBVWRU3QFMIBJANCNFSM4EN6VJKA>
.
|
As far as I understand CRT support resolve this problem regardless of symbol set properties. If I am wrong, please specify which properties to pay attention to.
As a person who responsible for IOF docs translation in our Orienteering Federation I want to say it is bad idea. Almost every symbol description has small update. Technical committee of our federation decided to translate the whole document. Also it is chance to make the translation more solid. I'd recommend to stick to this approach and don't reuse existing translations.
It is implemented according to App.1 and my personal experience where App.1 leaves white spots. However, I agree that additional testing is needed here. |
I dont now how to create a pull request. Sorry i totaly discover how it works. |
Ok, don't worry! I will check your attached updated symbol set & will create pull request myself ;) |
I finally managed to publish one but I'm not sure I did it right. |
Don't edit the per-scale files. The symbol set source files are located in: |
Based on the work of @eolmapper and combinded it with the IOF color appendix I present my proposal for the ISSprOM, May I ask one of the experienced contributors to push and moderate the process in a way we can get out not only this one but of course also ISOM and ISMTBOM updated soon? thx. |
@mlerjen, I will try to pull it in, when get a little bit more time. TL;DR: I'm Ukrianian livine in Ukraine. |
Some small fix here: Inner radius for 530 must be 0.56mm. Thanks @krticka for reporting. |
@mlerjen After some days working with ISSprOM symbol set I have 2 proposals for symbols:
|
added. |
Adjusted. What is the practical use of the k.o. setting? |
It had practical use with overprinting. Now it is either pointless or abused: No overprinting means knockout everywhere. |
Thus .pdf export and print do not "simulate" overprinting... |
It is pointless or abused on IOF maps. Some users still prefer overprinting for national/local events (for example here in Czechia it is still common). Two-level white hatch with simulation went into very bad result, thus KO is needed. For example in OCAD there is separate symbol for every two-level situation what is not very elegant solution but white stripes are not overlaying underlying colour and problems with simulation cannot occur. |
Do we have this symbols in oMapper?
|
I guess you are referring to the "SYMBOL SET FOR SCHOOL ORIENTEERING MAPS 2019". This is not yet implemented in OO Mapper. Please follow discussion in #613 |
@bujke018 Thank you. Next time we could coordinate efforts better. :-) |
533 should be transparent, not white |
I corrected the mistake.
pet, 01. mar 2024. 10:02 PskovFF ***@***.***> je napisao/la:
… ISSprOM v6.2024_4000.zip
<https://github.com/OpenOrienteering/mapper/files/14371652/ISSprOM.v6.2024_4000.zip>
533 should be transparent, not white
—
Reply to this email directly, view it on GitHub
<#1037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANGT5AJDGRKSTM3Z3LQF7E3YWA72LAVCNFSM4EN6VJKKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGI3TQNZRGMYA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@bujke018 I'd just like to point out that the 533 pattern can be rotated. So option adjustable per object should be checked on. Such option allows to better draw smaller and narrow areas of 533. |
Thanks for the advice. You are right about the rotation of the 533 symbol. |
For review: Report on colors and symbols |
For 714.1 the IOF Spécification does not specify which purple to use. Yes 715 must be able to rotate you must uncheck "oriented to the north" |
The report should probably list symbol colors with full name. Need to move them to the other column then. |
Your comment is a long time ago, have you created the symbols in the meantime? I have been using table and bench for a long time (bench even in ordinary sprint maps!) but 541 was new to me, and I am unsure how to understand the IOF specification about it Is the area inside the small black circles meant to be transparent or white? If transparent, I can't imagine how to use the colour table to achieve that. So I would create 541 three times, once for use on sand, once for use on paved area, and once for use on open land. Or is there a better solution? |
IOF Council meeting (187) minutes published!
New ISSOM draft (ISSOM 2018 ?) coming soon!
Update
The text was updated successfully, but these errors were encountered: