Color Relief Specification

[NathanMOlson]

See #1067 and #1089 for discussion of this issue.

Option 1 (#1089):

layers: [
    {
        "id": "elevation",
        "source": "terrainSource",
        "type": "color-relief",
        "paint": {
            "color-relief-color": ["interpolate",
                ["linear"],
                ["elevation"],
                0,"black",
                8000,"#FFFFFF"
            ]
        }
    }
]

Option 2 (#1099):

layers: [
    {
        "id": "elevation",
        "source": "terrainSource",
        "type": "elevation",
        "paint": {
            "elevation-algorithm": "color-relief",
            "elevation-color": ["interpolate",
                ["linear"],
                ["elevation"],
                0,"black",
                8000,"#FFFFFF"
            ]
        }
    }
]

Option 3 (#1098):

layers: [
    {
        "id": "elevation",
        "source": "terrainSource",
        "type": "hillshade",
        "paint": {
            "hillshade-method": "color-relief",
            "hillshade-color-relief-color": ["interpolate",
                ["linear"],
                ["elevation"],
                0,"black",
                8000,"#FFFFFF"
            ]
        }
    }
]

[louwers]

So I guess with option 3 many of the other paint properties are no-ops when using color-relief?

[NathanMOlson]

Correct.

Also, hillshade-color-relief-color would be a no-op for other hillshade methods.

Similarly, with option 2, if new algorithms were added, they would likely come with properties that would be no-ops when using color-relief.

[JBLINZ]

It would be common for a cartographer to combine or overlay a hillshade and colour relief shading, so I'd avoid an approach that prevents this.

I appreciate this isn't possible right now due to a lack of blending/transparency options, but I hope this will be solved in the near future (noting the active bounty >> maplibre/maplibre#269)

With option 2, I'd imagine "elevation-algorithm": "color-relief", forming a logical group with contours, aspect, slope and other common elevation-based outputs. Having hillshade separate feels ok.

[louwers]

Are there other layer where a bunch of properties are a no-op?

[neodescis]

I voted for #1, and apparently I am the first to do so. I thought I should share my reasoning since it seems I am bucking the voting trend:

1. I understand the desire to provide something "general", but in my mind that should be done in the implementation and not the spec. I think the spec should strive for clarity over generality.
2. We already have a layer type for one method (hillshade) in the spec. It is a given that we do NOT want to break existing styles and remove it. In the same vein, it seems to me that we should have a very good reason to leave a (for lack of a better word) "vestigial" layer type. I do not think that burden has been met.
3. With each method in its own layer type, we can provide TypeScript-based typing support in a much more straightforward manner. It seems strange to me to have no-op properties based on what is essentially a subtype, and I think users will find this confusing. The typing could be made to address this to some degree with some contortions, but in my opinion it will be more complex than it should be.

Also, I would like to point out that while a poll like this does have some value, we have been bitten by such a poll pretty recently and ultimately had to roll back a breaking change. That said, I do very much want to thank @NathanMOlson for pushing this!

[HarelM]

I think the typing can be solved either way, even if the type definition would be a bit more complicated, at least for typescript I know this is true.
This is basically not so much different than the type field of a layer that defines other properties it supports, this time it's the hillshade-method that defines which other properties are supported.
Having said that, I don't have strong feelings either way.
Maybe a voting as part of the monthly meetings would a better impact for visibility sake.

[louwers]

I agree voting is not always best way to resolve disagreements.

I think you make a strong case for #1.

[dwsilk]

Not keen on "hillshade-method": "color-relief" since colour relief is not a hillshade method. They are different functions/methods that share a common data source (elevation data). Looking to a future where aspect / slope / roughness could potentially be added in addition to hillshade, colour-relief and contour generation, I think it would be a bit strange and misleading to have all of these added as additional hillshade-methods.

See gdaldem or xDEM where hillshade is listed alongside these other methods, rather than these other methods being a subtype of hillshade. Geospatial desktop software like QGIS and ArcGIS Pro are similar too.

I voted for #2 but maybe #1 is also fine? I'm not sure how many types it makes sense to have.