2010/1/12 Frank Warmerdam
> maven apache wrote:
>
>>
>>
>> 2010/1/12 Frank Warmerdam > warmer...@pobox.com>>
>>
>>
>>maven apache wrote:
>>
>> It suggests that GDAL is not recognising the georeferencing
>>of the
>> data. The actual pixel values will hopefully stil
maven apache wrote:
2010/1/12 Frank Warmerdam mailto:warmer...@pobox.com>>
maven apache wrote:
It suggests that GDAL is not recognising the georeferencing
of the
data. The actual pixel values will hopefully still be accessed
properly.
2010/1/12 Frank Warmerdam
> maven apache wrote:
>
>>It suggests that GDAL is not recognising the georeferencing of the
>>data. The actual pixel values will hopefully still be accessed
>>properly.
>>
>>I would actually need to see the whole gdalinfo report on the
>> subdataset
>>
maven apache wrote:
It suggests that GDAL is not recognising the georeferencing of the
data. The actual pixel values will hopefully still be accessed
properly.
I would actually need to see the whole gdalinfo report on the subdataset
to be certain that GDAL is not finding ano
2010/1/12 Frank Warmerdam
> maven apache wrote:
>
>> Then I got its coordinate is :
>> ---
>> Upper Left (0.0,0.0)
>> Lower Left (0.0, 720.0)
>> Upper Right ( 1440.0,0.0)
>> Lower Right ( 1440.0, 720.0)
>> Center ( 720.0, 360.0)
>> --
maven apache wrote:
Then I got its coordinate is :
---
Upper Left (0.0,0.0)
Lower Left (0.0, 720.0)
Upper Right ( 1440.0,0.0)
Lower Right ( 1440.0, 720.0)
Center ( 720.0, 360.0)
---
Does that mean the gdal can not handle
2010/1/12 Frank Warmerdam
> maven apache wrote:
> > the gdal.tif is :
> >
> > Corner Coordinates:
> > Upper Left (0.0,0.0)
> > Lower Left (0.0, 720.0)
> > Upper Right ( 1440.0,0.0)
> > Lower Right ( 1440.0, 720.0)
> > Center ( 720.0, 360.0)
> >
maven apache wrote:
> the gdal.tif is :
>
> Corner Coordinates:
> Upper Left (0.0,0.0)
> Lower Left (0.0, 720.0)
> Upper Right ( 1440.0,0.0)
> Lower Right ( 1440.0, 720.0)
> Center ( 720.0, 360.0)
>
> It seems that the bbox is def
Hi:
I have some hdf5 data and I want to change the subdataset to geotiff, and I
use gdalinfo to get the subdataset name and then I use "gdal_translate
subdatasetname result.tif".
However I found that the crs of the generated tif is not recognized by the
arcgis,then I want to know why so I create a
Jason Roberts wrote:
Dear geospatial software experts,
By integrating with GEOS, OGR can perform various spatial operations on
individual geometries, such as buffer, intersection, union, and so on.
Is there a library that efficiently performs these kinds of operations
on entire OGRLayers?
Dear geospatial software experts,
By integrating with GEOS, OGR can perform various spatial operations on
individual geometries, such as buffer, intersection, union, and so on. Is
there a library that efficiently performs these kinds of operations on
entire OGRLayers? For example, this library
Hi!
Frank Warmerdam wrote:
>
> NopMap wrote:
>> Is this also true for -projwin? From the documentation I got the
>> impression
>> that -srcwin requires meters while -projwin accepted the coordinates in
>> lat/lon??
>
> -srcwin takes the locations in pixel/line coordinate system. -projwin
> t
Hello
I am using OGR to open "ESRI Shapefiles" and show the content of the .dbf
file. If the file is already open by other application(ie: Excel) and I ask
for the number of fields:
int fieldcount = layer->GetLayerDefn()->GetFieldCount();
I get 'fieldcount == 0'.
I`d like to know if there i
Hello,
I have a question about writing a function which uses OGR and I am
hoping someone can point me in the right direction.
I am trying to write a function that takes a few OGRFeatures as
arguments. However I want one of them to be optional. I was hoping
to do something like the following but
NopMap wrote:
Hi!
Frank Warmerdam wrote:
You need to specify the corners in the coordinate system of the
image. So the values should be the meter based projected coordinates
like 1102062,6818226.
Is this also true for -projwin? From the documentation I got the impression
that -srcwin requ
Hi!
Frank Warmerdam wrote:
>
> You need to specify the corners in the coordinate system of the
> image. So the values should be the meter based projected coordinates
> like 1102062,6818226.
>
Is this also true for -projwin? From the documentation I got the impression
that -srcwin requires m
NopMap wrote:
Hi!
I am trying to make a GeoTiff a little bit smaller with gdal_translate.
Gdalinfo shows that the TIF has the following size:
Upper Left ( 1102062.959, 6818226.972) ( 9d54'0.00"E, 52d 6'0.00"N)
Lower Right ( 1692080.162, 6257943.762) ( 15d12'0.77"E, 48d54'0.71"N)
I call
gdal
Hi!
I am trying to make a GeoTiff a little bit smaller with gdal_translate.
Gdalinfo shows that the TIF has the following size:
Upper Left ( 1102062.959, 6818226.972) ( 9d54'0.00"E, 52d 6'0.00"N)
Lower Right ( 1692080.162, 6257943.762) ( 15d12'0.77"E, 48d54'0.71"N)
I call
gdal_translate -pro
Well, part of the problem seems to be that I was addressing a symbolic
link to the file and not the actual file itself.
Now that I'm addressing the file directly, BOTH files manage to create
the geo transform BUT NEITHER can generate the coordinate transformation
object (OGRCoordinateTransformatio
Hi,
How do I compute distance between 2 points in a GeoTiff Image using GDAL. To be
more specific I have a GeoTiff image file and 2 points (x, y position which
tell about the image position points). Can I get the distance between the 2
points (for the given projection of input file) using GDAL
20 matches
Mail list logo
