Thanks to both Frank and Chaitanya this is now resolved.
Adding in the coordinate system to my GeoJSON solved the issue in the
latest versions of GDAL.
Leaving this out did not produce errors using ogrinfo, but it did not
display the feature as WKT until the CRS was added in.
{
"type": "Polygon",
* "crs": {
"type": "EPSG",
"properties": {
"code": 29902
}
},*
"coordinates": [
[
[
123608.61199436858,
206164.3985653462
],
[
On 21/11/2010 15:38, Chaitanya kumar CH wrote:
Seth,
You can obtain the WKT of the geometries in a vector data source by
using ogrinfo with the -al option.
(http://www.gdal.org/ogrinfo.html)
On Sun, Nov 21, 2010 at 6:20 PM, geographika <geograph...@gmail.com
<mailto:geograph...@gmail.com>> wrote:
On 19/11/2010 18:04, Frank Warmerdam wrote:
geographika wrote:
Hi,
I have upgraded from GDAL 1.6 (32bit Windows) to 1.7 (64
bit Windows) and the following command no longer works:
C:\mapserver\bin\gdal\apps\gdalwarp
C:\Data\Rasters\MiscSuit.tif C:\RasterClips\mytest.tif
-cutline c:\RasterClips\hello.json -te 118008.672141
177232.164284 138695.761666 206164.398565 -dstnodata -9999
I get the following message in the command prompt:
Creating output file that is 414P x 579L.
Processing input file C:\Data\Rasters\MiscSuit.tif.
for band 1, destination nodata value has been clamped
to 0, the original value being out of range.
ERROR 1: Failed to parse CUTLINE geometry wkt.
The CUTLINE is valid GeoJSON (but would clearly be invalid
WKT) and produces the correct results in 1.6.
The ogr formats lists GeoJSON as read/write.
I am using 64-bit builds of GDAL taken from
http://vbkto.dyndns.org/sdk/
I have also tried using the development version of GDAL
1.8dev but get the same message. If I do not use a CUTLINE
the gdalwarp completes successfully but the new image does
not contain any data from my original image (all cells are
NoData).
Seth,
Can you make the .json file available? Does it work with OGR?
Try
ogrinfo on it.
Hmm, tracking through the code the LoadCutline() function in
gdalwarp.cpp
will read from the OGR datasource and convert the geometry to
WKT which is
attached to the cutline property of the warp. Later
GDALWarpOperation::
Initialize() turns that into a polygon object and that is
where the message
is coming from. So I am *suspecting* improper WKT of some
type is getting
produced somehow. We will really need to see the WKT that is
causing the
error to know more.
If you are comfortable rebuilding things then try changing:
const char *pszCutlineWKT =
CSLFetchNameValue( psOptions->papszWarpOptions,
"CUTLINE" );
if( pszCutlineWKT )
{
in the file gdal/alg/gdalwarpoperation.cpp to something like:
const char *pszCutlineWKT =
CSLFetchNameValue( psOptions->papszWarpOptions,
"CUTLINE" );
if( pszCutlineWKT )
{
printf( "WKT = %s\n", pszCutlineWKT );
Best regards,
Thanks very much for your reply Frank.
I have uploaded the GeoJSON to
http://geographika.co.uk/downloads/test.json
Running ogrinfo C:\test.json on the file produces the following
results:
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `C:\RasterClips\hello.json'
using driver `GeoJSON' successful.
1: OGRGeoJSON (Polygon)
Is it possible to use the ogr2ogr to convert GeoJSON to WKT to
check if this is successful? WKT is not in the list of formats at
http://www.gdal.org/ogr/ogr_formats.html
Compiling a 64bit version of GDAL is on my list of things to
learn, so I will try your second suggestion then.
The gdalwarp with the same GeoJSON works in 1.6 but it does throw
up the warning that:
"the source raster dataset and the input vector layer do not have
the same SRS. Results will be probably incorrect."
Regards,
Seth
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
