Frank Warmerdam wrote:
Stephen Woodbridge wrote:
Frank, anyone,
Thoughts on this issue?
Thoughts on how to better diagnose the issue?
I can talk to the client about making an image available to someone if
that would help.
I'm totally stuck on this one, converting 300+ images to tif first at
Stephen Woodbridge wrote:
Frank, anyone,
Thoughts on this issue?
Thoughts on how to better diagnose the issue?
I can talk to the client about making an image available to someone if
that would help.
I'm totally stuck on this one, converting 300+ images to tif first at
2-3 hours per image is
Hi,
I will reply myself once more (and the last time). I solved the problem with
setting the direct path to the bash instead of $(SHELL) in the line
LIBTOOL = $(SHELL) $(top_builddir)/libtool
This may help someone else too.
Sorry for reposting on the list,
Matej
[EMAIL PROTECTED]
Hello,
I have just realized that there is a problem with shell - I don't know why
/bin/sh is used instead of /bin/bash:
gmake[1]: Entering directory `/usr/home/matej/mapserver/gdal-1.5.3/apps'
/bin/sh /home/matej/mapserver/gdal-1.5.3/libtool --mode=linkg++ gdalinfo.o
\
/hom
I guess I found it, looks like the function
filled(c, 255)
does this.
Armin
On 12/11/2008 21:54, Armin Burger wrote:
Chris
thanks a lot for the quick and very helpful explanations. Is there a
possibility to reset the masked values '--' after the calculation to a
special value?
Best regards
Frank, anyone,
Thoughts on this issue?
Thoughts on how to better diagnose the issue?
I can talk to the client about making an image available to someone if
that would help.
I'm totally stuck on this one, converting 300+ images to tif first at
2-3 hours per image is not going to hack it.
Tha
Chris
thanks a lot for the quick and very helpful explanations. Is there a
possibility to reset the masked values '--' after the calculation to a
special value?
Best regards
Armin
On 12/11/2008 21:27, Christopher Barker wrote:
Armin Burger wrote:
maybe someone on this list has some experie
Oliver Eichler wrote:
Hi,
zooming out of a raster map is always a very resource hungry task as a large
area of points have to be read and reduced to the viewport size.
For a steady map RasterIO does the perfect job. However if the user zooms out
of a map very fast via mouse wheel RasterIO ea
Armin Burger wrote:
maybe someone on this list has some experience using numpy in
combination with GDAL/Python and could give me some advice.
For further questions about numpy, the numpy list is very helpful.
difference can be easily calculated after reading both images
into an array and sub
Hi everybody
maybe someone on this list has some experience using numpy in
combination with GDAL/Python and could give me some advice.
I wanted to try to use GDAL/Python/numpy to caculate the difference
between 2 images. The images are vegetation indexes for different dates.
The direct diffe
Hey Andrew,
Are your files in the same projection? I know gshhs is projected in wgs84
by default, and I see your raster is in British National Grid. AFAIK,
gdal_rasterize assumes the vector & raster data sets are in the same
projection.
-Jamie
On Mon, Nov 10, 2008 at 11:11 AM, Andrew Brooks <[
Roger,
On Mon, Nov 10, 2008 at 10:43 PM, Roger André <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> I believe your syntax is incorrect. Assuming that you are trying to exclude
> water from your image, it should be something like this:
> % gdal_rasterize -b 1 -b 2 -b 3 -i -burn 0 -burn 0 -burn 0 -l gshh
Hi,
zooming out of a raster map is always a very resource hungry task as a large
area of points have to be read and reduced to the viewport size.
For a steady map RasterIO does the perfect job. However if the user zooms out
of a map very fast via mouse wheel RasterIO eats up too much time to a
On Wednesday 12 November 2008, Even Rouault wrote:
> For those interested, I've commited code based on Ari's patch to support
> tables with multiple geometry columns. See ticket 1476 and/or updated PG
> driver documentation for the details
This would be a very useful addition for my work!
Thanks!
For those interested, I've commited code based on Ari's patch to support
tables with multiple geometry columns. See ticket 1476 and/or updated PG
driver documentation for the details
Le Wednesday 12 November 2008 10:38:28 Ari Jolma, vous avez écrit :
> Open ticket 1476 seems to be discussing th
The command line switch to use for GEOMETRY=AS_XYZ is -lco and not -nlt
ogr2ogr -f "CSV" SOUNDG.csv SOUNDG.shp -lco GEOMETRY=AS_XYZ
And it will only work with a version of GDAL built from very recent sources
(it will come in GDAL 1.6.0)
Le Friday 07 November 2008 18:39:35 Donnet, Sebastien, vou
Ok, I was looking through nithfile.c, am I correct in understanding
that the only TRE supported for saving is BLOCKA, and that each
additional TRE needs to be handled
individually?
I need to add support for the following TREs. But I don't really need
to add new SDE headers, but preserve
Andrew Brooks wrote:
On Mon, 10 Nov 2008 21:43:02 -, Roger André <[EMAIL PROTECTED]> wrote:
I believe your syntax is incorrect.
The manual implies that the -b and -burn options are optional but they appear
to be mandatory.
Andrew,
One of -3d, -burn or -a are required. I have not foun
Hi,
I have a problem with getting gdal to compile on FreeBSD 6.2. My problem is
exactly the same as the one described here
http://lists.osgeo.org/pipermail/gdal-dev/2007-November/014763.html.
I run configure with:./configure --with-pg=/usr/local/pgsql/bin/pg_config
My configure ouput is
...
G
Bruce,
I think what you see is due to an inappropriate use of OGR API rather than a
bug in OGR itself. I'd encourage you to browse that ticket
http://trac.osgeo.org/gdal/ticket/2653 which is about GPX, but I think you're
hitting the same scenario with KML as output.
Le Friday 07 November 2008
On Mon, 10 Nov 2008 21:43:02 -, Roger André <[EMAIL PROTECTED]> wrote:
>
> I believe your syntax is incorrect.
The manual implies that the -b and -burn options are optional but they appear
to be mandatory. Giving just a source and destination results in the usage
message. The only option not
Open ticket 1476 seems to be discussing this issue.
http://trac.osgeo.org/gdal/ticket/1476
Ari
Ari Jolma wrote:
The Pg driver consults geometry_columns for the list of layers in the
database and for the geometry type of a layer. But it does not consult
it for the geometry column itself. For
The Pg driver consults geometry_columns for the list of layers in the
database and for the geometry type of a layer. But it does not consult
it for the geometry column itself. For example:
I have a table "points", which is created with shp2psql and it is fine
with OGR. Then I decide to add ano
23 matches
Mail list logo
