Confusing pcpatch::geometry cast

[strk]

pcpoint::geometry returns a POINT geometry, pcpatch::geometry returns a POLYGON geometry, shouldn't it be a MULTIPOINT instead ? I guess it's returning the envelope instead, but sounds confusing.

[strk]

also, is there a way to get a multipoint geometry out of a pcpatch ?

[pramsey]

Not currently (well, explode, cast those points to geometry, and collect).

[Remi-C]

Hm,
the interest of pg_pointcloud would be very limited if the cast to geom was
to multipoint.

For instance a multimillion point patch would be very very big in geometry.

The idea is precisely to "generalize" a multipoint with an area.

One of my concern with this is that I find this area a little bit too much
geenralized.
FOr instance an orietned bounding box would be much better for me
(or even a surface looking closer to original points, I wrote a function
for this, whihc is quite expensive)

Cheers,
Rémi-C

2015-02-02 17:22 GMT+01:00 Paul Ramsey notifications@github.com:

Not currently (well, explode, cast those points to geometry, and collect).

—
Reply to this email directly or view it on GitHub
#30 (comment)
.

[strk]

To add to the confusion, an index built on geometry(pcpatch) is not used when the query filter uses pc_envelope(pcpatch) instead. But as noted in this issue the geometry cast is really nothing different from a call to pc_envelope(pcpatch), so why the duplication ? In other words, why should the "generalization" take the form of a cast ?

[strk]

answering to myself, I just realized that pc_envelope returns a bytea rather than a geometry, and the planner uses a cast from bytea to geometry when it comes to compare in a spatial filter, which does not match the field used for creating the index.

[mbredif]

I also find the semantics of casting with pc_envelope not so intuitive.
I would rather have a cast to multipoint and indices explicitly built using pc_envelope.
Would that be viable or would it incur some performance penalty?
I understand that pc_envelope returns a hand built bytea to prevent a c-dependency on postgis. Would not it be more intuitive to have pgpointcloud expose the current function as something like PC_Envelope_AsBinary, and have the pointcloud-postgis SQL extension expose PC_Envelope as a POLYGON geometry?