Opened 12 years ago

Closed 12 years ago

#1289 closed enhancement (fixed)

Override GeometryType for TopoGeometry

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 2.0.0
Component: topology Version: master
Keywords: Cc:

Description

… or it takes ages to convert to Geometry for no real reason …

Change History (13)

comment:1 by strk, 12 years ago

I wonder if I should add such overrides in the "topology" schema or "public". The former would follow policy set up so far for topological support, but won't be found by those not having "topology" in their search_path…

comment:2 by robe, 12 years ago

strk? Not sure I understand this ticket. You mean makeTopGeometry a type of Geomtry? or just cdonsidered in GeometryType output?

comment:3 by strk, 12 years ago

@robe I'm talking about the function GeometryType(). There's no such function taking TOpoGeometry so what happens is an implicit cast is engaged, which is slow if all you need is knowing the type (which is in the TopoGeometry value itself…)

Same applies to ST_GeometryType() but QGis is using the old GeometryType()

Dunno what a call to GeometryType(myTopoGeometry) would end up calling if "topology" schema isn't in your search_path and the override is topology.GeometryType().

comment:4 by robe, 12 years ago

I think it would just end up calling the geometry one. I've had similar issue before where I had an application that changed schemas on me and my casts suddenly didn't work. It turned out it was not seeing my casts because they weren't in its search path. Took me forever to figure out why things behaved differently in the app.

comment:5 by strk, 12 years ago

Eh… so what do we do ? Requiring users to append "topology" to their search_path sounds the cleanest, but it is less transparent. Alternatively maybe we are fine in public as long as drop schema topology cascades to it ?

comment:6 by strk, 12 years ago

Robe: I've been suggested to look at the CREATE EXTENSION thing, as it does support specifying a schema to install all objects in. In particular, can you check if it changes any database specific setting, so that you end up with having the extension schema appended in your search_path?

comment:7 by strk, 12 years ago

Filed #1300 for appending "topology" to the database search_path

comment:8 by strk, 12 years ago

Alright, so all we need now is a topology.GeometryType for closing this.

comment:9 by strk, 12 years ago

Next issue: such override could be _very_ fast if we don't care about the type being SINGLE or MULTI. This is because that information is already encoded in the TopoGeometry type itself (1 for puntal, 2 for lineal, 3 for areal, 4 for collection).

Would always returning MULTI* be an acceptable response ? This could be diffrent from calling geometrytype(input::geometry), which could be a single (not multi) version of the same space.

comment:10 by strk, 12 years ago

… which actually brings us back to "a function which returns Puntal, Lineal or Areal or Mixture (ST_Dimension would be the closest, except it returns max dimension for Mixture)

comment:11 by strk, 12 years ago

Status: newassigned

comment:12 by strk, 12 years ago

I guess having the TopoGeometry::Geometry converter always return multi* would turn the multi/or/not/multi into a non-issue

comment:13 by strk, 12 years ago

Resolution: fixed
Status: assignedclosed

r8237 overides both GeometryType and ST_GeometryType. Next stop: ST_Dimension.

But I'd really love to see a function to return if it's Puntal, Lineal, Areal, Mixed (Empty would take some more thoughs)

Note: See TracTickets for help on using tickets.