Which "format" for expression?

[m-mohr]

Which format should be used for the expression? It just says "Band arithmetic formula to apply to the referenced assets.", but this can be ambiguous.

Simple math should be somewhat clear, like the example: (B05–B04)/(B05+B04)

But let's say I want to compute the power of 2 or square root, how is this done?

• sqrt(123)
• math.sqrt(123)
• \sqrt[n]{123} (latex)
• 123^2
• 123²
• 123^{2} (latex)
• etc.

It is unclear how a client should implement and translate this to e.g. a OpenLayers style expression...

[vincentsarago]

it depends on the implementation

in titiler we use numexpr 🤷

[m-mohr]

Which effectively means everyone ships something else and no once can actually reliably render it. That seems not overly useful to me.

[vincentsarago]

I'll be happy to review yet another specification that explain how user can interact with data (render).

TiTiler was pretty much the only dynamic tile server for a long time, so the render extension followed the language it was using. Now with direct client access, developers can use the language they want.

IMO there are as many renders specification as software capable of rendering data!

[m-mohr]

I think it's better to choose any (e.g. numexpr - assuming it has a specification for its implementation) than none. This at least gives everyone a target to implement against. Having none just leads to chaos and bug reports.

[emmanuelmathot]

I believe there is a misunderstanding regarding the purpose of the renders extension. The goal of this extension is to provide an "abstract" representation of rendering, as mentioned in the specifications:

The renders extension is designed to be generic enough for use by any dynamic tile server.

As @vincentsarago pointed out, when this extension was first developed, TiTiler served as a reference point. Consequently, some concepts were directly borrowed from TiTiler, but they are largely applicable to other rendering systems as well. I would argue against relying on a specific implementation to define rendering operations.

[emmanuelmathot]

🤦🏼 Forget my previous comment, I did not see the issue applied specifically to expression. But still, the logic would apply and I would favor the most cross-language represention. numexpr can be a good candidate.

[m-mohr]

#23 leaves me a bit puzzled as now there are even more types, but none exposes what it actually is. So a client needs to guess? This is a big interoperability flaw. How do I know whether an object is MapLibre or MapBox or any other style language that's in form of an object?

[vincentsarago]

maybe a render entry should have a href to a conformance class or name (e.g titiler, maplibre...) 🤷

Then a client would refer to the value to understand what the render entry is.

[emmanuelmathot]

We actually want render to be implementation agnostic. Then having renderer mappings (e.g. titiler, openlayers, ...).
For this specific issue, I will propose a way to express properly the expression format.
@m-mohr, #23 was only for aligning schema and readme.