fix: apply sortby when building vector tiles

[slesaad]

Collection.get_tile() accepts a sortby argument and never uses it, so ?sortby= has no effect on vector tiles. /items sorts correctly; /tiles silently drops the parameter. Feature order inside an MVT is the only draw-order control renderers such as deck.gl have, so overlapping polygons stack arbitrarily. Present in every released version I checked (1.0.0 through 1.6.0).

Decisions

ORDER BY goes before LIMIT. Beyond fixing feature order, this makes truncation deterministic — LIMIT with no ORDER BY currently keeps an arbitrary subset once a tile exceeds tipg_max_features_per_tile.

Applied unconditionally, not only when sortby is passed. With no sortby, _sortby() already falls back to the primary key, so this matches /items. It adds a sort to the default path in exchange for deterministic truncation. Happy to gate it on sortby if you would rather not pay that.

Ordering is repeated inside the ST_AsMVT aggregate. PostgreSQL only guarantees the order rows reach an aggregate when the ORDER BY is inside the aggregate call. The CTE-level ORDER BY does work today, because the LIMIT forces the sort to be kept — but that protection is incidental, and the failure mode is a silent 200 with wrongly stacked features. To be clear about how strong this is: I could not construct a plan that actually reorders, so this is insurance, not an observed fix. No measurable cost (timings overlap fully).

Only an explicit sortby adds the aggregate ORDER BY. The primary-key default keeps the CTE ordering alone, so existing properties=-restricted requests are unaffected.

A sort column excluded by properties= is rejected rather than silently unsorted. The aggregate can only order by columns present in its input row. The alternative — quietly widening the projection — would return a property the caller explicitly excluded. Raises InvalidPropertyName (404), consistent with how /items treats an unknown column.

_sortby() split into _sort_expressions(), which returns (column, SQL fragment) pairs so get_tile() can reuse one parse for the CTE, the aggregate, and the projection check. _sortby() is now a thin wrapper; its existing callers are unchanged.

Behaviour changes

• Invalid sort column on /tiles: 200 (ignored) → 404, matching /items
• ?properties=x&sortby=y where y is not in x: 200 unsorted → 404
• Tile feature order now follows sortby; LIMIT truncation is deterministic

Testing

Four tests, each watched fail against main first. Full suite passes (106 → 108).

Also verified against real data (NOAA HMS smoke polygons, 932 features, three overlapping density classes). Counting features drawn after something heavier was already down, on one tile of 257 features:

query	buried
no sortby	167 / 257
sortby=density_rank	0

Note

This supports the AIR4US work for visualizing HMS smoke data. The vector tiles have density property - denser features should be drawn on top of overlapping less dense features. Even though sortby is advertised as a query param for tiles, it isn't honored.