On May 26, 2012, at 8:56 AM, Nicolas Ribot <nicolas.ri...@gmail.com> wrote:
> Hi Puneet, > > Concerning the first point, you will be able to control the column you > want to load with the GDAL/OGR suite (gdal.org). > ogr2ogr allows changing the structure of datasets during conversion. This is handy information. For now, I wrote a Perl script that loaded each file into its own table, copied the common columns only to a master table, then dropped the individual tables. Was all done in a couple of minutes. Although, would be handy to have a switch to either include "named columns" or exclude "named columns in the shp2pgsql utility. That would make it analogous to the -n or -N switches in pg_dump/pg_restore. > > The -S switch is very handy when you are sure the input shapefile > contains only simple objects (points, linestrings, polygons) and you > don't want your geom column to be a MULTI type: > The shapefile format specifications allow to store both simple and > multi objects in the same shapefile. Shp2pgsql generates multi objects > layers by default, as it does not scan the shapefile to see if > multiobjects exist, prior to loading it. Thanks again for this great info, but this still begs the question: why would I want MULTI over SIMPLE features or vice versa? Performance, integrity, querying, what? > > Nicolas > > On 26 May 2012 04:29, Mr. Puneet Kishor <punk.k...@gmail.com> wrote: >> I have US states shape files that are mostly identical, except for those >> silly legacy columns that have the state code prefix. Is there a way I can >> import these shapefiles via `shp2pgsql` specifying to *not* load a >> particular column? As is, the loader croaks because the '-c' switch creates >> the table on the first state load creating a column starting with that >> state's code, and then the second state can't find that column. >> >> An additional question -- the '-S' switch promises to "Generate simple >> geometries instead of MULTI geometries." Why would I want to do that? Please >> educate me. >> >> >> >> -- >> Puneet Kishor >> _______________________________________________ >> postgis-users mailing list >> postgis-users@postgis.refractions.net >> http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
