https://sashat.me/2017/01/11/list-of-20-simple-distinct-colors/

https://sashat.me/wp-content/uploads/2018/08/colors_display.html
In making my Roman Roads project, I came across a problem. The challenge was to color-code 20 different rail lines for a metro system diagram, and I found myself spending an inordinate amount of time choosing the colors. No matter what I did, some colors were too similar and could be easily confused.

(Update: I went with repeating colors instead, numbering each line and making sure that same-colored lines were far from each other.)

Surely I’m not the first person to have this issue, I thought. So I did some googling and came across Kelly’s 22 Colors of Maximum Contrast. Unfortunately towards the bottom of Kelly’s list things get a bit complicated. The orange yellow, purplish red, yellowish brown and reddish orange all seemed to blend together. Not only that, there were no hex triplets, nor RGB nor CMYK values.

Every list of colors that I found online suffered from the same problems. So I made my own, with colors that are:

• Easily distinguishable
• Tastefully luminant
• Given simple, intuitive names
• Supplied with hex, RGB and CMYK values

Without further ado, I present my own list of 20 simple and visually distinct colors, plus black and white.

I’ve arranged the “convenient” order so that if you want six colors, for example, just choose the first six. The order of the colors is inspired by their frequency of appearance on all the world’s subway maps (yes, I did count them all!).

Some of the color names (like blue or green) don’t match up to typical HTML or RGB conventions. I did this deliberately, to further differentiate the colors. The conversions between various color spaces are not exact, but in my experience they work well.

Update 2: Now with accessibility! With the help of Color Blindness Simulator and this page listing color blindness frequencies, I’ve added a function that allows the user to choose what percentage of the population they are seeking accessibility for:

• Approximately 95% of the general population has normal color vision and would have full access to the original palette.
• Another 4% of the population has all three types of cones (RGB), but the red or green cones may not be fully functional, making it more difficult to distinguish green/yellow and blue/purple combinations. I remove some colors that get too close to each other, such as olive, which becomes like brown.
• A further 1% of the population is missing red or green cones. Roughly speaking, they see colors with wavelengths longer than cyan (e.g. red, green) as shades of yellow, and colors with wavelengths shorter than cyan (e.g. purple) as shades of blue. Since they appear to have the same hue, the only differentiating factors become luminance and chromaticity. Orange and yellow can still be distinguished, but orange looks like a darker yellow.
• The final 0.01% of the population may have weak or missing blue cones, only one type of cone, or no cones at all. People with tritanomaly (weak blue cones) can see almost the entire spectrum just fine, while people with tritanopia (no blue cones) see, roughly, yellow through purple as cyan, and magenta through orange as red. However, this is such a rare condition that I made the final option tailored for the lowest common denominator: people who cannot distinguish any hues. Yellow becomes light grey, and blue becomes dark grey.

NOTAM Data

The tool below enables you explore the NOTAM APIs by building queries and viewing live data. Along with your user key, fill in the parameters for the desired API and click ‘Try it out!’. If you don’t have a user key, Sign Up here for an account.

The APIs listed on this page have Global data coverage.

NOTAM Data is available in XML via the AIXM 5.1 Digital NOTAM Event Specification or in GeoJSON format.

Visit our GitHub Repository for a complete list of schemas used to serve the XML data found on the Laminar Data APIs.

Check out the Laminar Data UML model for a full breakdown of how the Laminar API is structured and how individual elements relate to one another.

Extensions

To increase the usability of the data, Laminar Data inserts a custom extension within the EventTimeSlice elements under the event:extension. This contains useful properties that cannot be expressed in the standard AIXM Event model. The section below will explain the fields present within that extension.

Cancelled NOTAMs

If a NOTAM is cancelled, the date and time at which the cancellation was recorded will be available within the extension element, as shown in the example below:

<event:extension>
   <sflake:EventExtension>
      <sflake:cancelled>2016-01-01T00:30:00Z</sflake:cancelled> 
   </sflake:EventExtension>
</event:extension>


NOTAMs that are cancelled will cease to be returned by the NOTAMs by FIRAPI call, but will remain accessible via their UUID in the NOTAMs by ID API call for a period of time after cancellation.

This field will only be returned on NOTAMs by ID API calls.

Replaced NOTAMs

A NOTAM may be subsequently replaced by another NOTAM after it has been issued. When this has occurred, a link will be made between the two NOTAMs based on their identifiers. The older NOTAM will contain a reference to the UUID of the NOTAM that has superseded it, as shown in the example below. The older NOTAM should also generally contain a cancellation time as it will no longer be in force.

<gml:identifier>d49837c1-624f-57d0-b805-b73e5744528b</gml:identifier>
...
<event:extension>
   <sflake:EventExtension>
      <sflake:replacedBy>0006059c-05fc-533f-9435-3f11796c0119</sflake:replacedBy>
      <sflake:cancelled>2016-01-01T00:30:00Z</sflake:cancelled>
   </sflake:EventExtension>
</event:extension>


Likewise, the newer NOTAM will contain an inverse link to the older NOTAM UUID:

<gml:identifier>0006059c-05fc-533f-9435-3f11796c0119</gml:identifier>
...
<event:extension>
   <sflake:EventExtension>
      <sflake:replaces>d49837c1-624f-57d0-b805-b73e5744528b</sflake:replaces> 
   </sflake:EventExtension>
</event:extension>


These fields will only be returned on NOTAMs by ID API calls.

NOTAM Geometries

Where possible, an approximate area of effect of the NOTAM will be provided as a standard GML geometry, for example:

<event:extension>
   <sflake:EventExtensionGeometry>
      <sflake:eventLocation>
         <aixm:Surface srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:patches>
               <gml:PolygonPatch>
                  <gml:exterior>
                     <gml:LinearRing>
                        <gml:posList srsDimension="2">52.0333 -3.6333 ...<gml:posList>
                     </gml:LinearRing>
                  </gml:exterior>
               </gml:PolygonPatch>
            </gml:patches>
         </aixm:Surface>
      </sflake:eventLocation>
   </sflake:EventExtensionGeometry>
</event:extension>


The EventExtensionGeometry will be returned for both NOTAMs by IDand NOTAMs by FIR API calls, but the element will be omitted if it was not possible to determine a geometry for the NOTAM.

NOTAM Data APIs (v2)

This page allows you to explore the NOTAM APIs available on the Laminar Data Hub and makes it ease for you to make queries and view live data. Along with your user key, fill in the parameters for the desired API and click ‘Try it out!’. If you don’t have a user key, Sign Up here for a Laminar Hub Account. 

There are many different types of NOTAMs in the aviation industry all of which are difficult to decipher. Some are mandatory or regulatory in nature, others advise pilots and other airspace operators, such as drone operators, of a closed airspace or runway, obstacles, or even alert airports and airlines about a nearby flock of birds. 

Our Laminar Data Hub APIs make it EASY and SIMPLE to access, view and utilize NOTAMS in your applications and workflows. We also published Top 7 Things to Know About NOTAMS that describes key things you need to know about NOTAMS.

You can access our previous release here: NOTAM Data APIs (v1).

The APIs listed on this page have Global data coverage.

Features

The API publishes GeoJSON feature types. All features have an id that uniquely identifies the NOTAM. The following fields are currently published as feature properties:

The possible values of the purpose field are as follows:

• N – NOTAM selected for the immediate attention of aircraft operators.
• B – NOTAM selected for PIB entry.
• O – NOTAM concerning flight operations.
• M – Miscellaneous NOTAM; not subject for a briefing, but it is available on request.
• K – NOTAM is a checklist.
• BO – Combination of B and O.
• NBO – Combination of N, B and O.
• NB – Combination of N and B.
• NM – Combination of N and M.

Scope

The possible values of the scope field are as follows:

• A – Aerodrome.
• E – En-route.
• W – Nav warning.
• K – NOTAM is a checklist.

Any combination of these codes may appear.

Traffic

The possible values of the traffic field are as follows:

• I – Instrument Flight Rules (IFR) traffic.
• V – Visual Flight Rules (VFR) traffic.
• IV – Both IFR and VFR traffic.
• K – NOTAM is a checklist.

Geometries

The API attempts to obtain a geometry for each NOTAM. Geometries are currently either taken from the center point and radius stated in the NOTAM Q-line, or inferred from the text content of the NOTAM.

Geometries are published in GeoJSON form. Currently, the geometrymember of each Feature will either be null where a geometry is not available, or a GeoJSON geometry object of type GeometryCollectionwhere a geometry has been obtained. The type of geometries within the GeometryCollection will be Polygon. Clients should be compliant with the full GeoJSON specification, and be prepared to accept other types of GeoJSON geometry object on the geometry member or within a GeometryCollection in the future.

Each geometry object within the collection represents a volume of space the NOTAM affects. Since there is no standard way to express a volume with upper and lower bounds in GeoJSON, the geometry objects are extended in order to encapsulate this additional information. The properties upperLimit and lowerLimit are added, which describe the maximum and minimum vertical limits respectively.

An example of this representation is shown below:

{
    "id": "2d6fb513-5512-432b-9eaf-cda8ab643e0d",
    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [ ... ],
        "lowerLimit": {
            "reference": "SFC"
        },
        "upperLimit": {
            "reference": "AMSL",
            "uom": "FEET",
            "value": 6000.0
        }
    },
    "properties": {
        ...
    }
}


Note that the upperLimit and lowerLimit properties are optional. As a general principle, the API does not create additional information that did not exist on the input. If the information is unavailable, you may assume the NOTAM has a surface lower limit and unlimited upper limit.

The following properties are defined under upperLimit and lowerLimit:

• reference – An enumerated value that describes the type of limit. The allowable values of this field vary depending on whether an upper or lower limit is being described.
• • For all limit types:
• • • FLIGHT_LEVEL – The value refers to a flight level. The type of flight level is described by the uom. If the uom is FEET this is an imperial flight level; if the uom is METERS, this indicates standard metric levels are in used, however this construct is not currently expressed by the API. Note that no conversion to MSL at standard pressure is applied, i.e. FL250 will be represented as a value of 250, not 25000.
• • • AMSL – The value refers to a height above mean sea level (MSL) in the given uom.
• • • AGL – The value refers to a height above ground level in the given uom.
• • For lower limits:
• • • SFC – The lower limit is at the surface. In this case no uom or value is given.
• • • GND – The lower limit is at the ground. In this case no uom or value is given. For most practical purposes this is equivalent to SFC, however because the NOTAM specification allows originators to use GND or SFC the distinction has been retained in the API.
• • For upper limits:
• • • UNL – The upper limit is unlimited. In this case no uom or value is given.
• • Note that a reference may not always be provided if one was not explicitly specified in the input. In this case, you may generally assume the reference is AMSL for the purposes of interpreting the value and uom.
• uom – An enumerated value that describes the measurement system. This field is optional for some types of reference.
• • FEET – The value is measured in feet.
• • METERS – The value is measured in meters.
• value – The actual measure of the limit. Interpreting the valuerequires inspection of the reference and uom fields as described above. This field is optional for some types of reference.