Skip to content
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

Update ISOM 2017 to rev.2018-11 #1187

Closed
wants to merge 2 commits into from
Closed

Update ISOM 2017 to rev.2018-11 #1187

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Nov 29, 2018

This is pull with changes related to issue #1184

NOTE: Few changes not yet added due to unclear definition in ISOM-2017-corrections-approved-2018-11.pdf:

  1. There are no 501.1? Stairway symbol added yet due to unclear definition and no any sizes defined;
  2. Cliffs (symbol 202) "edges" not rounded yet. Need additional review on symbols 202..202.3 for switching line caps (and line joins?) to rounded;

app4soft added 2 commits November 30, 2018 01:19
Remove symbols 411.1 and 411.2 and related object on map.
<cmyk method="spotcolor"/>
<rgb method="cmyk" r="0.772" g="1.000" b="0.727"/>
</color>
<color priority="24" name="Green 20%" c="0.152" m="0.000" y="0.182" k="0.000" opacity="1.000">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krticka I guess that all uses of "Green 50%" and "Green 20%" (including forest runnable in one direction, narrow ride) are to be replaced by "Green 60%" and "Green 30%", respectively, not only 406, 408?

BTW I would appreciate if the MC could clarify the spelling of its specs (ISOM2017 vs. ISOM 2017 vs. ISOM-2017).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dg0yt Yes, your assumption about Green 60% and Green 30% is correct. Such change affects other symbols using these colours.

Regarding naming convention the true is, that we are using ISOM 2017 and ISOM2017 in our documents interchangeably. I will discuss this with Christer, but probably we can stick to this format: NAME space YEAR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new changes in ISOM will be published officially as ISOM 2019.

Copy link
Author

@ghost ghost Dec 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new changes in ISOM will be published officially as ISOM 2019.

When?

And what we should do with ISOM 2017 symbol set now? Left it as is (but rename ISOM2017_15000.xmap to ISOM_2017_15000.xmap) and move all changes into separate ISOM_2019_15000.xmap?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, for now ISOM_2017_15000 is OK. When ISOM 2019 will be published officially just rename the file. Maybe there will be some additional small corrections from MC meeting in January based upon the requests by federations/commissions. At least you have to wait with ISOM 2019 for official PDF where dimensions of new symbols will be defined.

Copy link
Author

@ghost ghost Dec 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just rename the file.

No, for OpenOrienteering Mapper we should create new file (i.e., ISOM_2019_15000.xmap) for each new specification & keep all legacy symbol sets (such as ISOM_2000_15000.xmap, ISOM_2017_15000.xmap, etc.) for compatibility reasons.

At least you have to wait with ISOM 2019 for official PDF where dimensions of new symbols will be defined.

I can't understand why MC published changes as ISOM-2017-corrections-approved-2018-11.pdf, and not as ISOM_2019_draft_2018-11.pdf?!

Really misunderstanding :-/

@lpechacek lpechacek mentioned this pull request Nov 30, 2018
Copy link

@valdisj valdisj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ISOM 2017 Corrections approved November 2018 (https://orienteering.sport/iof/resources/mapping/) coming as add-on to 0.8.4 or as new template for 0.8.5?

@ghost
Copy link
Author

ghost commented Mar 20, 2019

Is this ISOM 2017 Corrections approved November 2018 coming as add-on to 0.8.4 or as new template for 0.8.5?

This symbol set not finished yet. It would be added into 0.8.5 (as 0.8.4 already released) or into 0.9.0.

P.S.: But if you want, you could download and use it for testing purposes only in 0.8.4

@dg0yt
Copy link
Member

dg0yt commented Mar 22, 2019

Is this ISOM 2017 Corrections approved November 2018 (https://orienteering.sport/iof/resources/mapping/) coming as add-on to 0.8.4 or as new template for 0.8.5?

  • The file proposed in this pull request introduced additional colors instead of adjusting the existing ones. This blocks the review of other changes. I recommend to not use this file for productive work.
  • I'm waiting for this ISOM 2017 Corrections to be published as ISOM 2019. I do not want to support two versions of ISOM 2017.
  • There is also a color appendix to be looked at. However, this is a very strange document anyway.
  • I don't think there will be another 0.8.x release.

@ghost
Copy link
Author

ghost commented Apr 4, 2019

The file proposed in this pull request introduced additional colors instead of adjusting the existing ones. This blocks the review of other changes.

What should I do with colors? I found colors comparsion chart, but not yet know how I should implement it

pic.1

@ghost
Copy link
Author

ghost commented May 1, 2019

So, I just reproduce "Appendix 1 - CMYK Printing" instruction for colors in OpenOrienteering Mapper, but how should I design colors for "ISOM2017-2" and "ISSprOM2019"? (currently I'm working on both latest symbol sets for Mapper)

UPD: More screenshots added in comment behind.

@dg0yt
Copy link
Member

dg0yt commented May 2, 2019

When in doubt, retain as much as possible from the current Mapper symbol sets. Test in overprinting simulation and in regular view. Any substantial change to (our) existing color layers will make it harder to upgrade existing maps to (our) new symbol sets. Even more when users added own colors and symbols.

I wonder if the Appendix should really be taken literally. I can't remember it being discussed before publishing, and there seems to be more agreement between OCAD and Mapper than between either software and this Appendix. All those new standards had some serious issues. But the standardization process seems to involve only national societies, not software providers.

Fun point: The color layers were originally designed to support spot color printing while allowing editing and printing in "normal" mode. With spot color printing being effectively banned by that Appendix, there is no need for color layers - using (default) z-levels per symbol, maybe adjustable per object as in any other vector graphics tool, would make much more sense.

@ghost
Copy link
Author

ghost commented May 2, 2019

I wonder if the Appendix should really be taken literally. I can't remember it being discussed before publishing.

Yeah, on Facebook many mappers tells the same: Appendix 1 should be fixed or fully rewrited for ISOM2017-2 , ISSprOM2019 and upcoming specs.

Fun point: The color layers were originally designed to support spot color printing while allowing editing and printing in "normal" mode. With spot color printing being effectively banned by that Appendix, there is no need for color layers - using (default) z-levels per symbol, maybe adjustable per object as in any other vector graphics tool, would make much more sense.

But we should keep current Mapper spot colors for compatibility with older symbol sets.

BTW, There is solution on define Cyan/Magenta/Yellow/blacK colors as "spot colors" and then combine it for each color defined in Appendix 1.

P.S.: I will publish later examle of this CMYK-to-Spot idea.

@krticka
Copy link
Contributor

krticka commented May 2, 2019 via email

@ghost
Copy link
Author

ghost commented May 2, 2019

Map Commission is working on new Appendix.

@krticka , can MC create own GitHub repo for organize public development on IOF specifications for orientering maps?

Then mappers community could help fix issues before it would be realeased! ;-)

@yevhenmazur
Copy link

Could @Symbian9 share his progress in relevant GitHub repo for organize public development? Then mappers community could help with his tasks and they will not hang in status "work in progress" for two years, like #694

@ghost
Copy link
Author

ghost commented May 2, 2019

Could @Symbian9 share his progress in relevant GitHub repo for organize public development?

@yevhenmazur as you can see this pull request based on my braches with patches & all them are public

Then mappers community could help with his tasks and they will not hang in status "work in progress" for two years, like #694

What? My "Topographic" symbol sets not related to current pull requrest or official IOF MC's specifications.

@ghost
Copy link
Author

ghost commented May 2, 2019

Offset names > Spot

Offset2Spot

CMYK values of Offset names > Spot

CMYK2Spot

Appendix 1 Mistakes

Appendix1

  1. There NO CMYK values for CMYK (non-offset) colors! How should we adjust such colors (to still NOT available "PrintTech 2018/2019 Test Sheet") if we don't know initial values?
  2. There are NO "Green 30%" and "Green 60%" that mentioned in ISOM2019.
  3. There are NO new "PrintTech 2018/2019 Testsheets" yet.
  4. Names of colours for CMYK printing is not clear: why Black and not Black 100%?; where is Black (for borders)?; also some extra , added in "Blue 100% (areas, marshes,)" name (or there should be some word after last ,?).

@lpechacek
Copy link
Member

@Symbian9, if I'm not mistaken, over past months IOF MC have published information giving answers to many of your questions. Has there been progress on updating the ISOM symbol set, please?

@dg0yt
Copy link
Member

dg0yt commented Sep 22, 2019

PR replaced #1363.

@dg0yt dg0yt closed this Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants