Casting Polygons As Multipolygons?

[markb]

Just to start off, thanks so much to Sandro. This little 8 mb
executable (i.e. 'spatialite-gui.exe') has fundamentally changed my
workflows, things are sooooo much cleaner, they way they should be.
Your tool realizes the following statement (something I've sort of
made my GIS/Db Mantra), not mine, but as quoted from (http://
www.palladiumconsulting.com/blog/sebastian/2007/06/shapes-dont-have-attributes-they-are.html):

"Shapes don't have attributes, they ARE attributes"


Finally My Question (I might be missing something obvious though):

Is their any SQL way to CAST a Polygon GeometryType to a Multipolygon
GeometryType?

My imported shapefiles are by default being imported as MultiPolys,
this is good, correct and needed. So I think something analogous to a
CAST is occurring during load operations. But when Buffering (e.g.),
geoms are converted back to their simplest datatype. I understand
this, this is all quite fine. But from that point on (if I want fully
enabled geometry columns), the output geometries can't live in the
same table together (I can't count geomcollections, since I need to
easily get back to a polygon shapefile). After Buffering, I need to
do further processing (or dump to a single shapefile), but much of it
requires aggregate queries (both tabular & spatial with GUnion), not
exactly great from separate tables. This occurs for several datasets,
that are then Unioned to a new table. But the geom field(s) can't be
recovered, since they have type mismatches. Because of this no export
to shapefile is possible.

I was hoping the MultiPolygonFromWKB fx would accept a Polygon proper
WKB as a way to CAST, but I was out of luck. I could probably see
similar things happening with MultiLineStrings & MultiPoints also. So
I will likely export to a shapefile prematurely, then merge the
datatypes, then re-import (maybe several times) to continue forward.

Thanks for any help SL Users
-Mark

[NiceDogE]

I'm a little unclear on your process you are needing, but I don't
think you are restricted in having multiple geometries per table.

It is one of the small advantages of SpatiaLite (like Oracle et al.)
that you CAN have multiple geometry columns per table. You could
simply create a new Geometry column in your table, populate it with
Buffer() using UPDATE and then .dump the new Geometry column to a SHP.

On Aug 20, 8:13 am, markb <brad.markf...@gmail.com> wrote:
> Just to start off, thanks so much to Sandro.  This little 8 mb
> executable (i.e. 'spatialite-gui.exe') has fundamentally changed my
> workflows, things are sooooo much cleaner, they way they should be.
> Your tool realizes the following statement (something I've sort of

> made my GIS/Db Mantra), not mine, but as quoted from (http://www.palladiumconsulting.com/blog/sebastian/2007/06/shapes-dont-have-a...

[markb]

My problem isn't multiple geom columns per table, it's that the Buffer
operation can produce either Polys or Multipolys from the same source
Geometry column (i.e. from a Multipoly GeomType). Meaning that the
output from a spatial operation couldn't be contained within one
registered geometry field (due to a GeomType violation). Say you load
a shapefile, and then create a new table from a Select statement
resulting in some buffer output for each record. If more than one
type results, then there is no way to recover the geometry field, due
to the 'type-mismatch'. You also can't store the output in a single
predefined geom field, since you can you only pick one of the Poly
types. This ultimately means that you can't have what was once in one
table, still in one table. It forces one to split the output between
two tables, in order to have a fully enabled geometry column, which is
required to export to shapefiles. Using this as a solution creates
two shapefiles instead of one, even though the two combined would be a
perfectly valid input. All these difficulties equally apply to
spatial aggregate queries. You can imagine how several buffering
operations in a chain of spatial queries could possibly require
successive output splitting, requiring numerous tables, when far less
could have done the job. Being able to CAST a single part type to a
multipart type could completely eliminate this problem, making spatial
queries and shapefile input/output a much smoother and seamless
process. This 'casting' appears to be taking place during shapefile
loading? Thanks for replying & being so active NiceDogE.

[Yves Daemen]

I'va had the same problem a while ago.

Casting as you call it can be achieved using the C API (you could also
extend the
SQL interface in a similar manner) by changing the declaredtype of
simple polygons
to the type GAIA_MULTIPOLYGON. Then, if you declare a column of type
multipolygon,
you can have both simple and multipolygons in the same column.

Good luck!

[markb]

Thanks for your response, nice to know I'm not out of my mind (at
least in that way). I only borrowed from the 'casting' terminology
because SQLite has a Cast function, that conceptually approximates
what I'm after.

[a.fu...@lqt.it]

Hi,
what do you think about the following proposal ?

I can introduce in the next SpatiaLite release
some few new SQL functions:

------
CastToMultiPoint(Geometry)
CastToMultiLinestring(Geometry)
CastToMultiPolygon(Geometry)

1) if the arg already is a MultiPolygon
it will be returned unchanged
2) if the arg is a Polygon, then the
corresponding MultiPolygon will be
returned
3) if the arg is a GeometryCollection
[actually containing only one Polygon
or a MultiPolygon], then a MultiPolygon
will be returned
4) under any other circumstance, NULL
will be returned
5) obviously, the same applies for Points
and Linestrings as well

----
CastToGeometryCollection(Geometry)

1) if the arg is a valid geometry (any type)
a GeometryCollection will be returned
2) under any other circumstance, NULL
will be returned

----
CastToPoint(Geometry)
CastToLinestring(Geometry)
CastToPolygon(Geometry)

1) if the arg already is a Polygon
it will be returned unchanged
2) if the arg is a GeometryCollection or a
MultiPolygon [actually containing only
one Polygon], the corresponding Polygon
will be returned
3) under any other circumstance, NULL
will be returned
4) obviously, the same applies for Points
and Linestrings as well

----
any further suggestion will be warmly welcome

bye Sandro

[markb]

That completely covers the spatial equivalent of tabular casting.
Excellent is what I think!

[NiceDogE]

Ah that is clearer!

Well, I'm learning all the time here too, I thought MULTIPOLYGON was
supported since I seem to be able to import multipolygon shp OK! It
sounds like this is not the case though....

[Andrea P.]

I think is better a
single casting:

CastToMulti()

That return the valid MultiGeometry (MultiLine, MultiPoly or
MultiPoint)
otherwise is necessary to know before the results of the operations :)

When you intersect 2 polygons
It can return 1 or more Polygons, 1 or more Lines or even 1 or more
Points.

So a cast as CastMulty(..)
is always correct.

> 3) if the arg is a GeometryCollection
> [actually containing only one Polygon
> or a MultiPolygon], then a MultiPolygon
> will be returned

I don't understand why a collection with a casting Multi must became a
MultiPolygon.
If your collection is with some arcs, you can't returna Polygon.
I think is better return always collection unchanged.
Otherwise when the collection is complex (polygon + arcs + points)
it lost the arcs and points.


Regards,

Andrea P.

[Richard Greenwood]

On Thu, Aug 20, 2009 at 10:37 AM, <a.fu...@lqt.it> wrote:
>
> Hi,
> what do you think about the following proposal ?
>
> I can introduce in the next SpatiaLite release
> some few new SQL functions:
>
> ------
> CastToMultiPoint(Geometry)
> CastToMultiLinestring(Geometry)
> CastToMultiPolygon(Geometry)

PostGIS uses a single ST_Multi(Geometry) function for all geometry types.

--
Richard Greenwood
richard....@gmail.com
www.greenwoodmap.com