Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#2271 closed enhancement (invalid)

Add built in reprojection support to KML driver

Reported by: springmeyer Owned by: condit
Priority: low Milestone: 1.6.0
Component: OGR_SRS Version: svn-trunk
Severity: minor Keywords: ogr2ogr, kml, srs, automatic reprojection
Cc:

Description

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.

Change History (13)

comment:1 Changed 12 years ago by condit

Status: newassigned

comment:2 Changed 12 years ago by 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

comment:3 Changed 12 years ago by 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

comment:4 Changed 12 years ago by springmeyer

That's slick, thanks rouault.

comment:5 Changed 12 years ago by condit

Version: unspecifiedsvn-trunk

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

comment:6 Changed 12 years ago by 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!

comment:7 Changed 12 years ago by condit

Resolution: fixed
Status: assignedclosed

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

comment:8 in reply to:  3 Changed 10 years ago by micahalcorn

Resolution: fixed
Status: closedreopened

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.

comment:9 Changed 10 years ago by 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...

comment:10 Changed 10 years ago by Even Rouault

Resolution: invalid
Status: reopenedclosed

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.

comment:11 in reply to:  10 Changed 10 years ago by 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!

comment:12 Changed 10 years ago by 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)

comment:13 in reply to:  12 Changed 10 years ago by 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?

Note: See TracTickets for help on using tickets.