Which geometry should be prepared?

[edzer]

As seen here, prepared geometries may speed up geometry ops a lot. The example also shows that it matters for speed (a factor 10, out of 4000) whether to prepare x, or y; it is pretty trivial to invert the returned matrix. It is not so likely that users will understand this, and try it out themselves.

Which heuristics can/should we take here to decide whether to prepare x, or y?

[mdsumner]

Is "prepare" a general term for this? I just hadn't encountered it before.

Is it different to "sp::disaggregate", and similar terms like "explode", "split" that are used in other packages? I guess the difference is that it's inherently encapsulated, disaggregation is only "internal" before wrapping up the ID-summary at the end?

[edzer]

Please search the API we use for the word prepared. Other info:

• GEOS ticket
• PostGIS blog

the word comes from prepared statements.

It builds an index on the fly and discards it, with potentially dramatic run-time gains, but only does this for one of the arguments. The return values of the commands involved don't depend on the value of prepare.

We have sp::disaggregate now in the sf method for st_cast (see also #210)

[mdsumner]

Well that's interesting, I wasn't expecting a correspondence between GEOS and DB language at all.

I see now the indexing context, and the relation to the comments here: #76

I didn't grok the use of "prepared" in November at all, though I do understand the cached index for nn and so on.

Clarified in spades, thanks!

[edzer]

Historical context: GEOS was, afaik, primarily written to provide geometry ops to PostGIS.

[edzer]

I did some testing which didn't bring much insight. "prepare" is on a per geometry basis (sfg), not over a geometry set basis, for that you'd need to build an index over geometries, like GEOS' STR tree or libspatialindex