Daniela Czibener daniela.czibener at gmail.com writes:
In the common area, I'd like the resulting pixels values will be the maximum
or average value, not the value of the last image in the source image list.Is
there any option within the gdalwarp or I should use another GDAL tool?Thanks in
Eli, Matt,
I just rasterised some point data with GDAL 1.9dev from svn and can
confirm both observations:
a) points are lost at the edges
b) points and pixels do not line up correctly in qgis
I can align points and pixels by shifting the corner coordinates of the
resulting GeoTIFF by 0.5
Hi,
I have tested speed of random access to PostGIS features with simple
testing application.
// about 1e4 points
poLayer = poDS-GetLayerByName(bridges);
nfeatures = poLayer-GetFeatureCount();
for (int fid = 1; fid nfeatures; fid++)
poFeature = poLayer-GetFeature(fid);
Selon Martin Landa landa.mar...@gmail.com:
I'm not shoked at all by the performance you see. I would have even expected it
to be worse. Fetching 10 000 features in 5.6s, means 0.56 millisecond per
feature. Not so bad. You have to pay the cost for a client/server dialog for
each GetFeature() call
On 11-08-23 04:57 AM, Martin Landa wrote:
Hi,
I have tested speed of random access to PostGIS features with simple
testing application.
// about 1e4 points
poLayer = poDS-GetLayerByName(bridges);
nfeatures = poLayer-GetFeatureCount();
for (int fid = 1; fid nfeatures;
Just to finalize this thread, the underlying problem was that the
version of SWIG I was using was outdated. Installing version 2.0.5
corrected the issue.
Jim P.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
yes watch that because they also added test so you can do:
make test
and see if the swing is working
--Nikos Hatzopoulos
On Tue, Aug 23, 2011 at 8:53 AM, Jim Pendleton j...@ittvis.com wrote:
Just to finalize this thread, the underlying problem was that the
version of SWIG I was using was
Rodolfo,
I don't understand. I am building from a checkout of trunk from GDAL SVN,
which certainly appears to have the Geocentric support in it. Is this not
the latest code? Is there some separate 1.9 branch? My question is how the
geocentric support and vertical datums are supposed to work,
Le mardi 23 août 2011 19:28:49, Ben Discoe a écrit :
Rodolfo,
I don't understand. I am building from a checkout of trunk from GDAL SVN,
which certainly appears to have the Geocentric support in it. Is this not
the latest code? Is there some separate 1.9 branch?
There's no 1.9 branch (it
Jim,
The GDAL DTED driver is rather peculiar and only works for certain
very specific products. This is briefly addressed in the document at:
http://www.gdal.org/frmt_dted.html
But in brief, you should not depend on this driver for producing
files with arbitrary bounds, resolution and
GDALers:
I really like gdal.retile.py, but I'm now facing an issue where I want
to tile a file but have *overlap* between each tile. Is there a way
to do this using existing GDAL utilities? I want the outputs to be
geotiffs, and (ideally, but not required) I'd like a shapefile
generated of the
Even,
Thanks for pointing me to the API documentation (which i had seen) and the
python unit tests (which i had not - very interesting!) Unfortunately,
neither shows the SetVertCS method actually being called.
Thanksfully, this is the open source world :), so i am able to step through
OGR's
Hi folks,
The issues of geocentric CS and vertical CS are distinct, but they are related
in an important way: Geocentric coordinates are not very useful to the GIS
world unless they can be converted to orthometric (sea level) heights, which
involves a vertical CS.
Currently, the
13 matches
Mail list logo
