Add built in reprojection support to KML driver

[springmeyer]

Currently the KML driver will accept source files in a SRS other than WGS 84 but does not handle the reprojection of the coordinates. Therefore to correctly use the KML driver a user must first reproject the data into EPSG 4326 and then convert to KML with ogr2ogr. Otherwise invalid KML with be produced by ogr2ogr along with an error warning about coordinates that do not fall within the correct bounds for WGS 84:

$ ogr2ogr -f KML test.kml lk/lk.shp # a shapefile in NAD_1983_StatePlane_Washington_North_FIPS_4601_Feet
ERROR 1: Latitude 584194.370017 is invalid. Valid range is [-90,90]. This warning will not be issued any more
Warning 1: Longitude 1113244.200378 has been modified to fit into range [-180,180]. This warning will not be issued any more

It would be ideal to build in automatic reprojection support for the KML driver such that when ogr2ogr is called to create KML from data in a projection other than WGS84, this processing in done in a single step. This would match the convenience of the ST_AsKML() function in postgis that can effectively be called on any projected geometry as long as a valid srid is set.

[springmeyer]

Perhaps it might be slightly useful to peek into the posgis ST_AsKML() code, and if so it can be found here:

​http://svn.refractions.net/postgis/trunk/lwgeom/lwgeom_kml.c

[Even Rouault]

In fact, as a work-around, you don't have to do 2 steps. Just one is enough. Adding the destination SRS makes it work as expected (provided that the shapefile is accompanied with the appropriate .prj file)

ogr2ogr -t_srs EPSG:4326 -f KML test.kml lk/lk.shp

[springmeyer]

That's slick, thanks rouault.

[condit]

Just checked in support to automatically transform. Please have a look at the SVN head... let me know if it meets your needs.

[springmeyer]

Great, just rebuilt from svn and have tested the revised KML driver on a variety of shapefiles. All of them converted to KML swiftly with automatic transformation. I even ran ogr2ogr on a continental watersheds layer with a custom projection (​http://spatialreference.org/ref/user/north-pacific-albers-conic-equal-area/) which created a 50MB in around 7 sec and opened perfectly in the new GE 4.3.7191.6508 (beta).

Thank Chris!

[condit]

I'm going to go ahead and close this. If you find problems, please reopen as a defect.

[micahalcorn]

Replying to rouault:

In fact, as a work-around, you don't have to do 2 steps. Just one is enough. Adding the destination SRS makes it work as expected (provided that the shapefile is accompanied with the appropriate .prj file)

ogr2ogr -t_srs EPSG:4326 -f KML test.kml lk/lk.shp

What if I don't have the appropriate .prj file? I tried -t_srs and had to first run -a_srs to define the source coordinate system. Now I am getting Error 6 when I run -t_srs (unable to load proj.4). Thanks so much.

[condit]

Are you using the new libkml driver or the kml driver? The newer driver should offer you more flexibility but I'm not sure if it's been released yet. I know it's in SVN...

[Even Rouault]

micahalcorn, yes, if you don't have the .prj file, OGR cannot guess the source projection, so -s_srs is needed.

And "unable to load proj.4" error just means that you've not correctly configured your setup so that it can find the proj4 shared library. Make sure that the libproj.so / proj.dll is in the path.

[micahalcorn]

Replying to rouault:

micahalcorn, yes, if you don't have the .prj file, OGR cannot guess the source projection, so -s_srs is needed.

And "unable to load proj.4" error just means that you've not correctly configured your setup so that it can find the proj4 shared library. Make sure that the libproj.so / proj.dll is in the path.

Thanks for your help and patience. I am new to GIS entirely. For the record, my path is configured to successfully run a simple -t_srs. However, the only files I see in my BIN or DATA with "lib" or "proj" in the filename are libcurl.dll, libeay32.dll, and projop_wparm.csv. Am I missing something? My download came from ​http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip. Thanks!

[Even Rouault]

Yes, this build only includes GDAL with the very strict minimum number of dependencies. PROJ4 is not a compulsory dependency, but it is *very very* recommanded to have it, because it is the underlying reprojection engine used by GDAL/OGR.

You could try with other binary distributions of GDAL that include PROJ4 as well such as : FWTools (​http://fwtools.maptools.org/), OSGEO4W (​http://trac.osgeo.org/osgeo4w/) or Tamas Szekeres' daily builds (​http://vbkto.dyndns.org:1280/sdk/Default.aspx)

[micahalcorn]

Replying to rouault:

Yes, this build only includes GDAL with the very strict minimum number of dependencies. PROJ4 is not a compulsory dependency, but it is *very very* recommanded to have it, because it is the underlying reprojection engine used by GDAL/OGR.

You could try with other binary distributions of GDAL that include PROJ4 as well such as : FWTools (​http://fwtools.maptools.org/), OSGEO4W (​http://trac.osgeo.org/osgeo4w/) or Tamas Szekeres' daily builds (​http://vbkto.dyndns.org:1280/sdk/Default.aspx)

OK, so apparently my data is State Plane. I guess I am out of luck getting to KML?