[Requests] Comments on OGC18-067, OGC Symbology Conceptual Model: Core

Little, Chris chris.little at metoffice.gov.uk
Thu Nov 15 11:59:17 EST 2018


PART A

1. Evaluator:         Chris Little, chris.little at metoffice.gov.uk

2. Submission:      OGC18-067, OGC Symbology Conceptual Model: Core

PART B

1. Requirement: General 
The title should be changed to "OGC 2D Symbology Conceptual Model: Core"

2. Implementation Specification Section number: Title Page, various other places.

3. Criticality: Editorial

4. Comments/justifications for changes: 
The editors have stated that higher dimensionality can be added as an extension to this proposed standard. The examples are resolutely 2D and refer to 'layers', and it is not at all clear how 3D or higher dimensionality extensions can be added with any form of backward compatibility. 
--
1. Requirement: General 
Only two submitting Members.

2. Implementation Specification Section number: Prologue (v)

3. Criticality: Minor

4. Comments/justifications for changes:
OGC rules require three submitting Members for a standard. I recognise that this is an early public review, but having more supporters would be encouraging.
--
1. Requirement: General
Assumptions about underlying colour rendering capability are not made explicit. 

2. Implementation Specification Section number: 5.4, 5.8

3. Criticality: Major

4. Comments/justifications for changes:
There seems to be an assumption that there is a colour compositing model, as 'opacity' is mentioned, but no minimal requirement stated. Is it only 'additive' as for light emitting computer screens (Red + Green = Yellow)? Or are 'subtractive' colours envisaged, as applicable to paper (Red + Green = dingy brown, Yellow + Cyan = Green)  RGB Colour is mentioned in 5.8, but not RGBA.
--
1. Requirement: General 
Assumptions about underlying topology capability are not made explicit.

2. Implementation Specification Section number: 5

3. Criticality: Major

4. Comments/justifications for changes:
The document discusses styling applied to some simple examples, but does not discuss whether multi-part things are assumed, needed or supported. 
Example 1: A (green) island in a (blue) lake on a bigger (green) island in a (blue) sea. Are the different interpretations of this example all supported? Can the same style be applied to the islands and to the water expanses even if they are geometrically distinct?
Example 2: A (red) road crosses a (blue) canal, and further along the valley, the canal crosses the road on an aqueduct. How would the expected good practice styling be achieved? Is there a hidden requirement to create multi-part roads and canals? Would an assumed opacity and colour compositing model address the issue?
--
1. Requirement: General
There is no mention of map or layer styles.

2. Implementation Specification Section number: 5

3. Criticality: Major

4. Comments/justifications for changes: 
It is not clear to me how features could be consistently styled across a layer, a set of layers or a set of maps.
--
1. Requirement: General
There is no mention of inheritance or cascading of styles.

2. Implementation Specification Section number: 5

3. Criticality: Major

4. Comments/justifications for change:
It is not clear that the abstract model supports the modern concept of a hierarchy or cascade of styles, suggested or mandated by the map author or server, and perhaps allowed to be overridden by the user or client, or any intermediary.
--
1. Requirement: General 
Style lazy evaluation/delayed gratification or rendering

2. Implementation Specification Section number: 5.2

3. Criticality: Major

4. Comments/justifications for changes:
Styles could be explicit ( thick red line with black edges) or implicit ('main road') with actual instantiation delayed until rendering, whether the rendering is under control of the client or server. It is not clear to me how this functionality can be enabled just by stating 'the graphic pipeline ...must be expressed  unambiguously..." 
--
1. Requirement: General
Remove pixels.

2. Implementation Specification Section number: 5.7

3. Criticality: Minor

4. Comments/justifications for changes:
The pixel was originally a fixed aspect of hardware. In 1985, the international graphics standards replaced it with a 'cell array' which is intrinsically transformable, consistently with all the other graphical primitives. Pixels arrays were still allowed, but did not transform. All modern interactive graphical devices are capable of transforming large cell arrays at refresh rates. Some devices are capable of displaying cell arrays, and pixels, at higher resolutions than the human eye can resolve. The 'virtual pixel of size 0.28 x 0.28mm' is an anachronism and should be abolished or at least deprecated.


Chris Little BA, MSc, FRMetS, MBCS
Chair, OGC Meteorology & Oceanography Domain Working Group
Chair, OGC Temporal DWG
Member, OGC Architecture Board

IT Fellow - Operational Infrastructures
Met Office  FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
Tel: +44(0)1392 886278  Fax: +44(0)1392 885681  Mobile: +44(0)7753 880514
E-mail: chris.little at metoffice.gov.uk  http://www.metoffice.gov.uk




More information about the Requests mailing list