[GIS] Can PostGIS constrain a column to multipolygons and polygons

postgis

I'm currently using PostGIS 1.5.3, but I will be upgrading to 2.0 soon. So please note any differences between the two versions that are relevant to the following questions.

Is it possible to create a column of the PostGIS geometry type that allows insertion of polygons and multipolygons but restricts insertion of other geometry types without manually modifying the constraint PostGIS generates when calling AddGeometryColumn?
Are there reasons not to do this? In particular, does PostGIS store any metadata that manually modifying the constraint might negatively impact? (I'm very new to PostGIS, so forgive me if the idea of PostGIS storing metadata is absurd.)
How significant is any overhead incurred by using multipolygons for everything?

I'm already aware of using ST_Multi to convert polygons into multipolygons before insertion, so if it's not possible or not a good idea, I'll do that.

Best Answer

For each of your questions...

Not without manually modifying the constraint.
There is some metadata stored in the PostGIS geometry. Technically, there is no reason not to do this. If you want a column to hold polygon or multipolygon, that is up to you. The general reason for sticking with one geometry type per column is simplicity as the table grows and/or if the table is massive.
A multipolygon comprised of only one polygon will be larger than just the polygon, but not significantly. The speed of spatially querying (with the appropriate index) the multipolygon with one polygon vs just one polygon would be the same though.

For my data, if the column is to contain polygons, I have the column be a multipolygon as it allows for the eventuality that a multipolygon will be inserted in the column. Just run ST_Multi as you're inserting.

Related Solutions

[GIS] Should I split MultiPolygons into Polygons

I'd be inclined to say not to worry about the size of your T1 table; indexes (and triggers of course) are what affect performance for the most part.

In addition to having one fewer joins, the translation of WKB to the internal PostGIS/GEOS representation I would imagine would be slightly more optimal than doing it for several polygons individually.

The only need for having a separate geometry table would be if one polygon was associated to more than one record. Multipolygons should be considered a single entity for the purposes of database design, and only if the relationship is more complex should you consider a separate table. And there would be a slight physical space saving with fewer tables.

Try it with both setups, and running the query in pgadmin which gives you the timings for each part of the query.

GeoDjango – Generalizing Polygons to MultiPolygons

The SQL to drop the constraint:

ALTER TABLE myapp_mymodel DROP CONSTRAINT enforce_geotype_mygeom;

Or to alter it to allow both Polygons & MultiPolygons:

ALTER TABLE myapp_mymodel DROP CONSTRAINT enforce_geotype_mygeom;
ALTER TABLE myapp_mymodel ADD CONSTRAINT enforce_geotype_mygeom CHECK (geometrytype(mygeom) = 'POLYGON'::text OR geometrytype(mygeom) = 'MULTIPOLYGON'::text OR mygeom IS NULL);

These SQL statements could be run from a South migration or an initial-data SQL script.

Another option is to make it a GeometryField in your Django model definition - this will allow it to store any geometry type.

Or, override the save() method on your model to force everything to be a MultiPolygon:

from django.contrib.gis.db import models
from django.contrib.gis import geos

class MyModel(models.Model):
  mygeom = models.MultiPolygonField()
  ... other fields....

  def save(self, *args, **kwargs):
    # if mygeom ends up as a Polgon, make it into a MultiPolygon
    if self.mygeom and isinstance(self.mygeom, geos.Polygon):
      self.mygeom = geos.MultiPolygon(self.mygeom)

    super(MyModel).save(*args, **kwargs)

Best Answer

Related Solutions

[GIS] Should I split MultiPolygons into Polygons

GeoDjango – Generalizing Polygons to MultiPolygons

Related Question