You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose that we provide a mechanism for allowing some amount of post-processing of feature data to support some common tasks, e.g.:
Shape simplification or other geometry edits (note that currently simplification is enabled as a server-wide flag with not additional options)
Property data edits or potentially conditional adding/removing of data
String formatting
Numerical conversions
Adding style information to feature properties
Creating new features based on tile-wide data
Aggregated grid cells
Tile-local clusters
The reason to consider this a post-processing step is so that a singular representation of this logic can apply to feature data coming from multiple backend sources, especially for the scenario of computing some tile-wide aggregations.
One thought would be to introduce support for some basic, embeddable scripting language (e.g. Lua, JS, etc.) that can be provided either statically in the tilenol configuration, or potentially in the request URL itself (e.g. script=<BLAH>). By using a simple scripting language (especially a familiar one), users would be able to quickly pick up the scripting capabilities. Furthermore, by providing the option to support request-time scripting, this could be used for very powerful, expressive, and interactive geospatial analyses over mixed datasets.
The text was updated successfully, but these errors were encountered:
I'd like to propose that we provide a mechanism for allowing some amount of post-processing of feature data to support some common tasks, e.g.:
The reason to consider this a post-processing step is so that a singular representation of this logic can apply to feature data coming from multiple backend sources, especially for the scenario of computing some tile-wide aggregations.
One thought would be to introduce support for some basic, embeddable scripting language (e.g. Lua, JS, etc.) that can be provided either statically in the tilenol configuration, or potentially in the request URL itself (e.g.
script=<BLAH>
). By using a simple scripting language (especially a familiar one), users would be able to quickly pick up the scripting capabilities. Furthermore, by providing the option to support request-time scripting, this could be used for very powerful, expressive, and interactive geospatial analyses over mixed datasets.The text was updated successfully, but these errors were encountered: