Opened 8 years ago
Closed 8 years ago
#3710 closed defect (fixed)
ST_AsMVT doesn't support numeric or arrays
Reported by: | stvn | Owned by: | Björn Harrtell |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.4.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: | Björn Harrtell |
Description
I'm using r15304 and I have a table with a numeric (numeric(16,0)), a numeric array (numeric[]) and a string array and I want to produce mapbox vector tiles with the new ST_AsMVT function.
However ST_AsMVT fails on the numeric with the error: ERROR: parse_values: numeric type not supported
When I cast the numeric to a bigint the query continues without a hitch and the value shows up in the feature properties.
However the arrays don't appear, nor does the query produce any error.
I would have expected the values of the arrays to be stored as arrays of values in the feature property, or at least produce an error.
Change History (5)
comment:1 by , 8 years ago
Cc: | added |
---|---|
Owner: | changed from | to
comment:2 by , 8 years ago
comment:3 by , 8 years ago
I think you are right, I wrongly assumed that the mapbox vector tile spec allowed for arrays. However it clearly states it doesn't cover those:
Attributes in geometric data, such as the properties object in GeoJSON can include more than just strings and numbers. They can be arrays or objects. The specification doesn’t cover how to encode these values and is up to the encoder to decide.
https://www.mapbox.com/vector-tiles/specification/
And it suggests the same as you do: turn them into strings. I have done so for my arrays and that works fine. Might be nice to put a note in the documentation that only smallint, integer, bigint, real, double and boolean are cast to their javascript counterparts and everything else is turned into a string.
comment:4 by , 8 years ago
I've made a patch so that things that not specifically fit into a number will be encoded as string, letting PostgreSQL do the casting.
I agree the behavior is not optimal, but at the same time these are types that cannot be represented by the set of types available in the vector tile specification.
A perhaps better solution, which I have thought about before, is to only parse the bool, int and float types to the corresponding vector tile type and let PostgreSQL return the string representation of any other type. What do you think?