Sign up ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I've downloaded a map from (limited to San Francisco census tracts), and I'd like to convert it to KML format. However, after unzipping the shapefile .zip file and running

$ ogr2ogr -f KML pop_by_census_tract.kml 140_00.shp

I get the following error message:

ERROR 6: No translation for Mercator_Auxiliary_Sphere to PROJ.4 format is known.
Warning 1: Failed to create coordinate transformation between the
input coordinate system and WGS84.  This may be because they
are not transformable, or because projection services
(PROJ.4 DLL/.so) could not be loaded.
KML geometries may not render correctly.
This message will not be issued any more. 


ERROR 1: Latitude 4553026.920500 is invalid. Valid range is [-90,90]. This warning will not be issued any more
Warning 1: Longitude -13627851.842700 has been modified to fit into range [-180,180]. This warning will not be issued any more

When I open the resulting KML file in Google Earth, I get randomly scattered lines across the entire planet. The example at works fine, so the installation of GDAL (1.8.0 from macports) isn't totally broken. seems related, but I'm not sure if it's saying that Mercator_Auxiliary_Sphere is just not supported by GDAL, or if it's implying I should pass another command line option to make it work.

Edit: I wound up accomplishing my goal by downloading, which contains shapefiles that ogr2ogr and shp2pgsql can understand, and joining it with the pure table data from factfinder2. I'm still curious about the format factfinder2 is using, but it's no longer blocking progress for me.

share|improve this question
Could it actually be in some strange UTM projection? Latitude 4553026 would be in the ballpark, but -13627851 is kinda wacky. –  neuhausr Dec 5 '11 at 15:33

3 Answers 3

up vote 1 down vote accepted
$ ogr2ogr -f KML -s_srs EPSG:3857 -t_srs EPSG:3857 pop_by_census_tract.kml 140_00.shp

creates a KML file with the boundaries in the right places. It needs both of those options. Just -s_srs EPSG:3857 produces the same error as in the initial question, while -t_srs produces one like

ERROR 6: No translation for Mercator_Auxiliary_Sphere to PROJ.4 format is known.
Failed to create coordinate transformation between the
following coordinate systems.  This may be because they
are not transformable, or because projection services
(PROJ.4 DLL/.so) could not be loaded.
    ... # Same as 140_00.prj
PROJCS["WGS 84 / Pseudo-Mercator",
    ... # Same as in the gdal ticket

Thanks for the pointers, everyone.

share|improve this answer

Try uploading the shapefile to Google Fusion Tables. That will let you download the data as KML:

share|improve this answer
Unfortunately, shpescape seems as confused as ogr2ogr when trying to upload the census data. The upload button just redirects straight back to the home page. It does fine at the data from, but ogr2ogr could also handle that. –  Jeffrey Yasskin Dec 4 '11 at 8:09
It looks like shpescape is actually using OGR under the covers ( so it's not surprising that it's no more powerful than the default options to the command-line tool. Still, it's more convenient than converting before the upload. Thanks for the pointer, for other files. –  Jeffrey Yasskin Dec 4 '11 at 8:17

You could try loading the shapefile into GeoServer and doing a WMS request with KML as the output format.

share|improve this answer
GeoServer's loading interface is remarkably complicated. When I load the problematic shapefile as a "store" into GeoServer (2.1.2), and then try to add a "layer" for it, it doesn't pick up either a native SRS or a declared SRS, and won't finish the import without them. Even when I create a store and layer from one of the working shapefiles (, it wants me to guess a "Declared SRS", and the find button won't let me actually search (it just reloads the page). So ... can you be more precise? –  Jeffrey Yasskin Dec 6 '11 at 4:57
1 will convert ESRI non-standard projections to a form the rest of the world uses. –  iant Dec 6 '11 at 8:42
That told me that the gz_2010 data was in EPSG:4269, which worked, but the closest it got to the problematic data was EPSG:32663, which still put it north of Redding (when it should cover San Francisco). I'm going to try searching the whole PostGIS spatial_ref_sys table to see if I can find something that matches. –  Jeffrey Yasskin Dec 7 '11 at 6:48
EPSG:3857 gets it. And ... I probably should have guessed this from the gdal ticket, which also mentioned 3857. Thanks for the pointers. –  Jeffrey Yasskin Dec 7 '11 at 8:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.