Override GeometryType for TopoGeometry

[strk]

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

[strk]

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…

[robe]

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

[strk]

@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().

[robe]

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.

[strk]

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 ?

[strk]

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?

[strk]

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

[strk]

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

[strk]

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.

[strk]

… 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)

[strk]

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

[strk]

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)