Using Command-Line Tools - Desktop GIS: Mapping the Planet with Open Source Tools - page 181

Let's load the GML file we created into PostgreSQL:
$ ogr2ogr -f PostgreSQL -a_srs EPSG:4326 "PG:dbname=gis_data host=madison"\
cities.gml
$ ogrinfo -so -al "PG:dbname=gis_data host=madison" cities
INFO: Open of `PG:dbname=gis_data host=madison'
using driver `PostgreSQL' successful.
Layer name: cities
Geometry: Unknown (any)
Feature Count: 606
Extent: (-165.270004, -53.150002) - (177.130188, 78.199997)
Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
FID Column = ogc_fid
Geometry Column = wkb_geometry
capital: String (1.0)
country: String (12.0)
name: String (25.0)
population: Integer (0.0)
Well, that worked—the GML file was successfully loaded into Postgre-
SQL. Using ogrinfo , we confirmed that it was loaded and had the proper
coordinate system. If you look at the load command, you will notice we
specified the coordinate system with the -a_srs switch using an EPSG
code of 4326 (WGS 84, latitude/longitude). We did this because the
GML file contains no projection information, even though the shapefile
we created it from did. This allows our newly created PostGIS layer
to play nicely with other WGS 84 layers in our database. Note that by
specifying -a_srs , we aren't reprojecting or changing the data in any way.
All we are doing is assigning the coordinate system to the PostGIS layer
when it is created.
As you suspected, we can also unload data from PostGIS to a supported
format. For example, we'll unload one of our layers to GML:
$ ogr2ogr -f GML volcanoes.gml "PG:dbname=gis_data host=madison" volcanoes