Opened 14 years ago
Last modified 7 years ago
#853 new enhancement
topology.Envelope(TopoGeometry)
| Reported by: | strk | Owned by: | strk |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS Fund Me |
| Component: | topology | Version: | master |
| Keywords: | Cc: |
Description
Currently, calling ST_Envelope(TopoGeometry) relies on a cast from TopoGeometry to Geometry, which is more expensive than needed, when only the bounding box is of interest (say, in building an index)
Change History (7)
comment:1 by , 14 years ago
comment:2 by , 13 years ago
| Milestone: | PostGIS Future → PostGIS 2.0.0 |
|---|
So the plan became not doing anything with boxes.
comment:3 by , 13 years ago
| Milestone: | PostGIS 2.0.0 → PostGIS 2.1.0 |
|---|
comment:4 by , 12 years ago
strk - are you planning to do this like within the next month. If not PLEASE push to 2.2
comment:5 by , 12 years ago
| Component: | postgis → topology |
|---|---|
| Milestone: | PostGIS 2.1.0 → PostGIS 2.2.0 |
| Owner: | changed from to |
comment:6 by , 10 years ago
| Milestone: | PostGIS 2.2.0 → PostGIS Future |
|---|
Note:
See TracTickets
for help on using tickets.
More over: we really want a "quick" bounding box here, using caches if available. So maybe this should not be called "Envelope" as the Geometry equivalent (ST_Envelope) does not use the cached bounding box at all.
Probably what I'm looking for would be a BOX2D cast, but it seems we want to get rid of that type completely ? If we could get to whatever bounding box is quick to get and use that in bounding-box based operator it'd make a lot of sense to me.
So, what's the plan here ? Adding another indexable type to replace BOX2D ? Gbox ?