I've found that using an PostGIS query as datasource makes labels silently fail unless the field used for labelling is fully typed.
Ie: SELECT 'x' as id, 'POINT(0 0)'::geometry as g; does NOT show the [id] value, while SELECT 'x'::text as id, 'POINT(0 0)'::geometry as g; does.
SELECT 'x' as id, 'POINT(0 0)'::geometry as g;
SELECT 'x'::text as id, 'POINT(0 0)'::geometry as g;
This is as of mapnik-2.0.0 and 2.0.2-pre, I'm rebuilding from the 2.0 branch to produce a focused testcase.
Did not try with 2.1
Here's the testcase:
?xml version="1.0" encoding="utf-8"?>
<Map srs="+init=epsg:4326" maximum-extent="-10,-10,10,10">
<Style name="label_test" filter-mode="first" >
<TextSymbolizer face-name="DejaVu Sans Book" ><![CDATA[[id]]]></TextSymbolizer>
<Layer name="label_test" srs="+init=epsg:4326">
<Parameter name="table"><![CDATA[(SELECT '45'::text as id, 'SRID=4326;POINT(0 0)'::geometry as g) as f]]></Parameter>
Omit the ::text cast from the '45' value and the label disappears
How can I print the type of an expression_ptr, for debugging this issue ?
And also a value_type...
The problem is this snippet:
value_type result = boost::apply_visitor(evaluate<Feature,value_type>(feature),*name_expr);
UnicodeString text = result.to_unicode();
resulting in an empty string, but only if the name_expr refers to the non-casted attribute.
I'm trying to figure what's the difference in terms of value_type (or node_expr type) differences.
Note: output operator for *exression_ptr doesn't work (dunno if it's supposed to)
Also the result from apply_visitor outputs as the empty string (not a 'value_type'?)
Alright, got it: Postgis Plugin: uknown OID = 3407481 FIXME
Glad to see it's a FIXME... will fix and report back
So I have mixed feelings about how to fix this.
One way is to encode the "unknown" type oid (705) and only threat that one like text or varchar.
Another way is to encode any unknown OID as text or varchar.
I think the latter makes more sense as it catches more cases (either known or still not known).
the return from getValue is guaranteed to be null-terminated, so the worst that can happen is spending time in transcoding something which is not text.
Also, it would fix this silent discard of unknown things (the FIXME message only comes out if MAPNIK_DEBUG is defined at compile time).
What do you think ?
Add support for literal types in PostGIS queries. Closes #1464.
Fix support for literals in postgis plugin
REF: #1626, #1464
finish backport to 2.0.x of fix for #1464
backport support for postgis literal type to 2.1.x - refs #1464 - clo…