[gdal-dev] Re: [GRASS-user] create a workplace (location mapset etc)_
hi. you can make the raster (and vector) data accessable via UMN MapServer directly, without any export need. UMN MapServer can read the data (via gdal/ogr) and display the via WMS. There is also another project, called pywms, which provides automatic WMS Service based on GRASS Database. The Capabilities document for WMS is created from GRASS Database on-the-fly, as well as maps. So, only r.in.gdal would be need, r.out.gdal is actually no necessary. Jachym [1] http://mapserver.org/ [2] http://pywms.wald.intevation.org On Fri, Mar 27, 2009 at 03:25:21PM +0800, apachemaven wrote: I want to handle some hdf data through a web service,and in the web service I handle the data by grass, so the problem comes out.The following is my setps: 1)translate the hdf4 to a tif by a FWTools2.2.8 which call the gdal command actually) for example I use the command gdal_translate [the subset] d:\aa.tif , 2)import the tif r.in.gdal input=D:/aaa6.tif output=ggg 3)process the ggg data of grass format for example r.buffer map=ggg distance=30 output=temp 4)convert the temp to tif r.out.gdal input=temp format=GTiff output=d:/dd.tif Then in the web service I return the url of the dd.tif to client. I want to know the above setps right or not? and in the step of 2 and 4 problems always come out..,a common problem is the data is blank even I reset the region use g.region rast=... My god,I am crazying@@! ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp Key fingerprint: 0C6D 0EAE 76BD 506C F299 ED8A C8AB 74B8 08D4 E08F signature.asc Description: Digital signature ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: [GRASS-user] creat a temp workplace
hi, On Fri, Mar 27, 2009 at 03:33:09PM +0800, apachemaven wrote: And in the step 2, I want to creat a temp location and mapset,beacuse my current location is the spanish example data... My god,I am crazying@@! basically, any location can be considered as temp, because of after deleting the whole directory, it is gone (uninstalled). if you want to create temp location in a batch script, just prepare some template location (with PERMANENT mapset and DEFULT_WIND and other files) than you can just copy this template under new name and so the temporary location is created. if you set the GRASS_BATCH_JOB env. variable, (shell script to be processed as batch job), the script will be performed automatically. jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp Key fingerprint: 0C6D 0EAE 76BD 506C F299 ED8A C8AB 74B8 08D4 E08F signature.asc Description: Digital signature ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library
Well... Have you checked your path to your include files ? Could I see the part of the code where the errors occured ? Thx Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com - Original Message - From: Ajmeri Iqbal To: b...@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 3:22 PM Subject: Re :Re: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library Hi, Thanks Benoît Andrieubea for your reply. you are right, there is no need any cpp file. but when i build the same code given in GDAL tutorial with QT Creator popups the following error. g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o debugImageRW.exe debug/main.o -Ld:Qt2009.01qtlib gdal_i.lib -lQtCored4 mingw32-make[1]: Leaving directory `D:/QT_Projects/ImageRW' mingw32-make: Leaving directory `D:/QT_Projects/ImageRW' debug/main.o: In function `main': D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterCount()' D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterYSize()' D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterXSize()' collect2: ld returned 1 exit status mingw32-make[1]: *** [debugImageRW.exe] Error 1 mingw32-make: *** [debug] Error 2 Exited with code 2. but the same code i builded with VC++ 2005, its working fine. unfortunatly i want to link GDAL library in QT. the bellow is my QT .pro file setting QT -= gui TARGET = ImageRW CONFIG += console CONFIG -= app_bundle TEMPLATE = app SOURCES += main.cpp LIBS += gdal_i.lib thanks in advance. On Mon, 30 Mar 2009 14:42:07 +0200 Benoît Andrieu wrote Hi ! You won't need any cpp files. Personally, I am using the FWTools package which bundles dll, libs and headers files. You just have to compile using gdal_priv.h Then link to gdal_i.lib Then provide with your runtime all the dlls which gdal_fw.dll is depending to. You will find which dlls it is depending to by using Dependency Walker (http://www.dependencywalker.com/). Then your runtime will be able to use all of the image formats drivers that GDAL was compiled to support. I hope this will help. Regards, Benoît andrieu...@ixsea.combenoit.andrieu@gmail.com - Original Message - From: Ajmeri Iqbal To: b...@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 11:06 AM Subject: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library Hi,Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code. i have downloded gdal_i.lib, gdal.dll and its include .h files..h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files. can u please give me broad idea or step by step procedure about how do i link these library to c++ code. thanks in advanceRegards,IqbalOn Fri, 27 Mar 2009 18:54:01 +0100 Benoît Andrieu wroteHi, I am using FWTools 2.2.9So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with :gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Benoît andrieu...@ixsea.combenoit.andrieu@gmail.com- Original Message - From: Ajmeri Iqbal To: b...@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PMSubject: Re :Re: [gdal-dev] How to use GDAL LibraryHi Benoît Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Benoît Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Benoît andrieu...@ixsea.combenoit.andrieu@gmail.com- Original Message - From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance___gdal-dev mailing listgdal-...@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev
[gdal-dev] How to use GDAL Library
Hi, On Mon, 30. Mar 2009 at 13:22:46 -, Ajmeri Iqbal wrote: D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterCount()' Are you using the C++ API directly? That won't work from MinGW unless GDAL is also built with MinGW. The C-API will work. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] utm projection in gdal_translate
Luca Fasano wrote: Hi, I want to create a GTiff copy to a data with projection overridden to *utm* using gdal_translate and its a_srs parameter. If I try to do this I obtain a wrongly located data. Command I use is like following: $ gdal_translate -of GTiff -a_srs +proj=utm +datum=WGS84 +zone=corrected utm zone starting from src coordinates src dst.tiff If I try to georeference the same data with gdal_warp and the same parameters I obtain a correctly located data, so I think the problem doesn't come from datas neither from parameters. What's wrong? Have I skipped some parameters? Luca, Are you aware that gdal_translate's -a_srs just overrides the coordinate system definition but does not in any way adjust the geotransform? It is only suitable for use to override an improperly described dataset, not to transform a dataset into a new coordinate system. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 4: `AOI.tif' not recognised as a supported file format.
Oz,
See the hereafter a correction to insert in your code that will hopefully fix
your issue.
Le Monday 30 March 2009 17:25:13 Oz Nahum, vous avez écrit :
Hi,
I have encountered a weired problem with gdal_rasterize.
when I run the script from here
http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedona
vectorfilesextentsforusewithgdal_rasterize
When I run:
#!/usr/bin/env python
from osgeo import gdal
from osgeo import osr
from osgeo import ogr
import numpy
#from numpy import ones
import stat, sys, os, string, commands
shp = 'AOI'
tiff = 'AOI.tif'
px = 1
tiff_width = 80
tiff_height = 80
# Import vector shapefile
vector = ogr.GetDriverByName('ESRI Shapefile')
src_ds = vector.Open(shp +'.shp')
src_lyr = src_ds.GetLayerByIndex(index=0)
src_extent = src_lyr.GetExtent()
# Create new raster layer with 4 bands
raster = gdal.GetDriverByName('GTiff')
dst_ds = raster.Create( tiff, tiff_width, tiff_height, 1, gdal.GDT_Byte)
# Create raster GeoTransform based on upper left corner and pixel
resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3], 0.0,
-px] dst_ds.SetGeoTransform( raster_transform )
# Get projection of shapefile and assigned to raster
srs = osr.SpatialReference()
srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__())
dst_ds.SetProjection( srs.ExportToWkt() )
# Create blank raster with fully opaque alpha band
zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 )
dst_ds.GetRasterBand(1).WriteArray( zeros )
# Properly close the dataset before calling gdal_rasterize, so that the TIF
# file is properly written.
dst_ds = None
commandString = 'gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif'
commandOutput = commands.getoutput(commandString)
print commandOutput
#end of code
I get the error this error:
augmented to the gdal_rasterize command I see this error. When I run it via
a shell script, I don't see the error:
ERROR 4: `AOI.tif' not recognised as a supported file format.
#!/bin/sh
python create_empty_raster.py
gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif
Runs ok.
-- This runs ok as at the end of the create_empty_raster.py script, the GDAL
dataset is automatically closed.
So I am confused, why I can't call gdal_rasterize from python ?
Thanks, for any help
Oz Nahum
Universtät Tuebingen
Applied Environmental Sciences
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Benoît Andrieu wrote: Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? Benoît, The overview builder and warper use quite different mechanisms so there is no close relationship between the resampling options available in each case. The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. In theory it should be possible to programatically connect warpers to overview levels in cases where overview band objects have proper dataset parents - which is the case with GeoTIFF hosted overviews. For instance, this C entry point could likely be used with hSrcDS being the base datset, and hDstDS being the dataset for the overviews. One problem with this plan is that it is likely that overview datasets do not have proper geotransforms or coordinate systems. So you might need to push a geotransform onto the overview dataset (with GDALSetGeoTransform()) before calling GDALReprojectImage(). CPLErr CPL_DLL CPL_STDCALL GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, GDALDatasetH hDstDS, const char *pszDstWKT, GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit, double dfMaxError, GDALProgressFunc pfnProgress, void *pProgressArg, GDALWarpOptions *psOptions ); Generally the warp api resamplers are not suitable for with a destination dataset with a radically lower resolution than the source. So I'd suggest doing it such that each overview is generated from the next higher resolution overview rather than always building from the base level. Note that the overview levels still need to be pre-created using normal mechanisms. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 4: `AOI.tif' not recognised as a supported file format.
thanks,
That does the trick.
Oz.
On Mon, Mar 30, 2009 at 7:02 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Oz,
See the hereafter a correction to insert in your code that will hopefully
fix
your issue.
Le Monday 30 March 2009 17:25:13 Oz Nahum, vous avez écrit :
Hi,
I have encountered a weired problem with gdal_rasterize.
when I run the script from here
http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedona
vectorfilesextentsforusewithgdal_rasterize
When I run:
#!/usr/bin/env python
from osgeo import gdal
from osgeo import osr
from osgeo import ogr
import numpy
#from numpy import ones
import stat, sys, os, string, commands
shp = 'AOI'
tiff = 'AOI.tif'
px = 1
tiff_width = 80
tiff_height = 80
# Import vector shapefile
vector = ogr.GetDriverByName('ESRI Shapefile')
src_ds = vector.Open(shp +'.shp')
src_lyr = src_ds.GetLayerByIndex(index=0)
src_extent = src_lyr.GetExtent()
# Create new raster layer with 4 bands
raster = gdal.GetDriverByName('GTiff')
dst_ds = raster.Create( tiff, tiff_width, tiff_height, 1, gdal.GDT_Byte)
# Create raster GeoTransform based on upper left corner and pixel
resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3],
0.0,
-px] dst_ds.SetGeoTransform( raster_transform )
# Get projection of shapefile and assigned to raster
srs = osr.SpatialReference()
srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__())
dst_ds.SetProjection( srs.ExportToWkt() )
# Create blank raster with fully opaque alpha band
zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 )
dst_ds.GetRasterBand(1).WriteArray( zeros )
# Properly close the dataset before calling gdal_rasterize, so that the TIF
# file is properly written.
dst_ds = None
commandString = 'gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif'
commandOutput = commands.getoutput(commandString)
print commandOutput
#end of code
I get the error this error:
augmented to the gdal_rasterize command I see this error. When I run it
via
a shell script, I don't see the error:
ERROR 4: `AOI.tif' not recognised as a supported file format.
#!/bin/sh
python create_empty_raster.py
gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif
Runs ok.
-- This runs ok as at the end of the create_empty_raster.py script, the
GDAL
dataset is automatically closed.
So I am confused, why I can't call gdal_rasterize from python ?
Thanks, for any help
Oz Nahum
Universtät Tuebingen
Applied Environmental Sciences
--
Imagine there's no countries
It isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
You all must read 'The God Delusion'
http://en.wikipedia.org/wiki/The_God_Delusion
---
when one person suffers from a delusion it is called insanity. When many
people suffer from a delusion it is called religion.
Robert Pirsig, Zen and the Art of Motorcycle Maintenance
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Thanks for the answer, Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? Benoît, The overview builder and warper use quite different mechanisms so there is no close relationship between the resampling options available in each case. Ok, I think the best thing to do for me is to look at the source code... The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. In theory it should be possible to programatically connect warpers to overview levels in cases where overview band objects have proper dataset parents - which is the case with GeoTIFF hosted overviews. For instance, this C entry point could likely be used with hSrcDS being the base datset, and hDstDS being the dataset for the overviews. One problem with this plan is that it is likely that overview datasets do not have proper geotransforms or coordinate systems. So you might need to push a geotransform onto the overview dataset (with GDALSetGeoTransform()) before calling GDALReprojectImage(). CPLErr CPL_DLL CPL_STDCALL GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, GDALDatasetH hDstDS, const char *pszDstWKT, GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit, double dfMaxError, GDALProgressFunc pfnProgress, void *pProgressArg, GDALWarpOptions *psOptions ); Generally the warp api resamplers are not suitable for with a destination dataset with a radically lower resolution than the source. So I'd suggest doing it such that each overview is generated from the next higher resolution overview rather than always building from the base level. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a library callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) Note that the overview levels still need to be pre-created using normal mechanisms. Ok. Have to look. I'll take a look in the next days and will come back for help !! :) Regards, Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] using gcp's without giving coordinates
Hello, I'm trying to convert a map from OziExplorer Map file fromat to Geotiff. FOr this i'm using the calibration points in the Map file as Ground Control Points. I do the following: gdal_translate \ -gcp 203 52 529000 4191000 \ -gcp 5174 3096 544000 4182000 \ -gcp 5201 99 544000 4191000 \ -gcp 176 3051 529000 4182000 \ -gcp 1861 1067 534000 4188000 \ -gcp 3517 2081 539000 4185000 \ -gcp 3526 1083 539000 4188000 \ -gcp 1851 2066 534000 4185000 \ -gcp 2844 2742 537000 4183000 \ -a_srs +proj=utm +ellps=intl +k=0.999600 +x_0=50.0 +y_0=0.0 +zone=30 +units=m +towgs84=-125.098545,-76.54,-156.198703,0.0,0.0,-1.129,8.30463103 +no_defs \ map.bmp \ map.tif However doing this still gives the maps upper left corner start at 0-0. I was wondering if there was a way to make gdal infer the correct corners of the map from the gcp's without specifying them directly. Or is there another way to achieve this without specifying the coord corners? (The calibration points are not corner-based) One solution would be to calculate the corners myself programmatically (from the pixels), but this would be the least good solution. Many thanks, Erik ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
I actually hope to be addressing performance in my GSoC project. I'm interested in rewriting the GDAL resampling code to CUDA, so the graphics card does the hard work. For example, instead of processing one pixel at a time, the latest GeForce GTX 260 would be able to process 216. I'm hoping for CUDA to be 50 to 100 times faster. Make sure you're using GDAL 1.6 or later, I recently rewrote the regular Lanczos/cubicspline warping code to be much faster. ~Seth On Mon, March 30, 2009 3:16 pm, Benoit Andrieu wrote: Sounds interesting ! I am curious to know what you will try to do in your project ! I am very interested in producing high quality images resulting for mapserving and image merging. We are using GDAL / Mapserver in our software suite. I made a try with GeoServer and I found the results were very nice comparing to Mapserver. We did not try to use GeoServer after that because there were others artifacts. But now that I have seen Lanczos and cubicspline results on our images using GDAL, I am convinced that there is something to do about Mapserver to challenge GeoServer !! ;) Of course, performance is a really big problem with Lanczos/cubicspline... I'll take a look at the code. Regards, Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com -Message reçu- De: Seth Price s...@pricepages.org Ã: Benoît Andrieu b...@ixsea.com Cc: gdal-dev@lists.osgeo.org Date: 30/03/2009 20:38 Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo The resampling code between gdal_warp and gdaladdo is completely separate, thus it is basically two different projects. For the Google Summer of Code application I'm about to submit I will be working on the resampling code in GDAL's warper and GRASS. If I have time (and my application is accepted!) I'll try to look into gdaladdo also. ~Seth On Mon, March 30, 2009 12:27 pm, Benoît Andrieu wrote: Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about projects of GSoC 2009
Mateusz Loskot wrote: Jorge Arévalo wrote: The entire process could be improved by several ways: - I would like to have an enhaced PNG driver, to reduce the size of the tiles. For this reason, I had a theoretical approach to NeuQuant algorithm and I used pngnq. I discovered the relation between this algorithm and Kohonen Neural Networks, that I studied during my degree, and I liked a lot. Basically, for these reasons I'm interested in the project about PNG Driver Nice idea. By the way, here is project developed by a friend of mine C++ Kohonen Neural Network Library http://knnl.sourceforge.net/ Perhaps you will find it useful in your work. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about projects of GSoC 2009
Hello, Thanks for the link, and for your opinion! I'll apply for the three projects. Best regards Jorge 2009/3/30 Mateusz Loskot mate...@loskot.net Mateusz Loskot wrote: Jorge Arévalo wrote: The entire process could be improved by several ways: - I would like to have an enhaced PNG driver, to reduce the size of the tiles. For this reason, I had a theoretical approach to NeuQuant algorithm and I used pngnq. I discovered the relation between this algorithm and Kohonen Neural Networks, that I studied during my degree, and I liked a lot. Basically, for these reasons I'm interested in the project about PNG Driver Nice idea. By the way, here is project developed by a friend of mine C++ Kohonen Neural Network Library http://knnl.sourceforge.net/ Perhaps you will find it useful in your work. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about projects of GSoC 2009
Jorge Arévalo wrote: Hello, Thanks for the link Mateusz. OK, I need your opinion. I've been working during 1 year (still working) in a project that uses gdal library (developing some code), and Postgis, to transform vectorial data (MIF files) on PNG tiles to show over google maps. I use Postgis to perform a previous merge of some vectorial data. Then, I transform the vectorial data in raster files, and burn the polygons over them using given colors. Finally, I transform these raster files in PNG tiles with gdal2tiles. Guys, Maybe this interests you. The GMT tool ps2raster (CVS version) is now able to create KML code from any -- GMT-complicate-as-much-as-you-want -- images. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Benoit Andrieu wrote: The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. Benoit, I personally would prefer not to further complicate the overview code with additional resampling types. However, I have an insistent client who will pay, and who might become grumpy if I did not oblige. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? In this case things might not be too bad, but these resampling kernels basically have at most 4x4 kernels, so if you are doing 20:1 downsampling only a small fraction of the pixels are having any influence. On the other hand in them more typical 1:1 resampling case you get nice results as a small window of pixels in the area gets considered in the resampling. For 1 step radical downsampling something like average may give better results than 4x4 kernel resamplers. However, if downsampling is done stepwise (by powers of 2 for instance) then the 4x4 kernel resamplers may give good results all the way. There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. I am suggesting writing a small C application that would first generate normal overviews, and the use the warper to overwrite them with nicely downsampled imagery. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a library callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) This would be messy. I am trying to avoid overcomplicating the overview code which is already very complicated. In fact it is already so complicated that I'm mortified about extending it with cubic resampling. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Seth Price wrote: I actually hope to be addressing performance in my GSoC project. I'm interested in rewriting the GDAL resampling code to CUDA, so the graphics card does the hard work. For example, instead of processing one pixel at a time, the latest GeForce GTX 260 would be able to process 216. I'm hoping for CUDA to be 50 to 100 times faster. Make sure you're using GDAL 1.6 or later, I recently rewrote the regular Lanczos/cubicspline warping code to be much faster. ~Seth You can achieve pretty amazing speeds on the CPU alone. I have a SSE3 (would be trivial to rewrite as plain old SSE, probably a bit slower) Lanczos sampler with 4x4 kernel that runs at ~70 000 000 samples per second with float data type on a 2.33GHz Intel Xeon E5410 (one thread). I was considering porting the sampler to GDAL but found that I would have to rewrite the whole warping code to get any useful speed boost, including heavily optimizing coordinate transformations. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Thanks for the answer Frank ! So in a first time I'll be looking at making a gdaladdo bis. By the way, do you know why Mapserver does only support nearest, average, bilinear, bicubic ? I thought it was using GDAL to do warping, but then it would natively support cubicspline and lanczos. I know that speed is a concern... ^^ By the way bis, I forgot to mention that we had some artifacts with gdalwarp yesterday. We are using FWTools 2.3.1. We wanted to merge several pictures at 20cm x 20cm resolution and make a 1m x 1m and a 4m x 4m. The pictures could be quite big : 3 x 3 pixels. First, we used gdalwarp to do all operations in a single one : merging and downsizing. But the resulting picture contained artifacts. In some areas, it is as if a nearest method was used instead of lanczos. Because of this, we then asked gdalwarp to make the downsizing. In a second call, we made the merging. There we did not find artifacts and it is ok for us to do like this. But I fear to have the same problems with bigger pictures. I will not be able to provide the pictures (sources or results) because of confidentiality agreements. But I could provide screenshots. Or try to reproduce on differents datasets. Regards, Benoît Andrieu -Message reçu- De: Frank Warmerdam warmer...@pobox.com À: Benoit Andrieu b...@ixsea.com Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org Date: 30/03/2009 23:48 Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Benoit Andrieu wrote: The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. Benoit, I personally would prefer not to further complicate the overview code with additional resampling types. However, I have an insistent client who will pay, and who might become grumpy if I did not oblige. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? In this case things might not be too bad, but these resampling kernels basically have at most 4x4 kernels, so if you are doing 20:1 downsampling only a small fraction of the pixels are having any influence. On the other hand in them more typical 1:1 resampling case you get nice results as a small window of pixels in the area gets considered in the resampling. For 1 step radical downsampling something like average may give better results than 4x4 kernel resamplers. However, if downsampling is done stepwise (by powers of 2 for instance) then the 4x4 kernel resamplers may give good results all the way. There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. I am suggesting writing a small C application that would first generate normal overviews, and the use the warper to overwrite them with nicely downsampled imagery. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a library callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) This would be messy. I am trying to avoid overcomplicating the overview code which is already very complicated. In fact it is already so complicated that I'm mortified about extending it with cubic resampling. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
That sounds like bad news for my dreams ! :( I was planning to make a try with IPP on some parts of GDAL (warping, geometry rasterization). Did you make some profiling ? I would be interested to know the results ! Regards, Benoît Andrieu -Message reçu- De: Adam Nowacki no...@xpam.de À: gdal-dev@lists.osgeo.org Gdal-Dev gdal-dev@lists.osgeo.org Date: 31/03/2009 00:06 Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Seth Price wrote: I actually hope to be addressing performance in my GSoC project. I'm interested in rewriting the GDAL resampling code to CUDA, so the graphics card does the hard work. For example, instead of processing one pixel at a time, the latest GeForce GTX 260 would be able to process 216. I'm hoping for CUDA to be 50 to 100 times faster. Make sure you're using GDAL 1.6 or later, I recently rewrote the regular Lanczos/cubicspline warping code to be much faster. ~Seth You can achieve pretty amazing speeds on the CPU alone. I have a SSE3 (would be trivial to rewrite as plain old SSE, probably a bit slower) Lanczos sampler with 4x4 kernel that runs at ~70 000 000 samples per second with float data type on a 2.33GHz Intel Xeon E5410 (one thread). I was considering porting the sampler to GDAL but found that I would have to rewrite the whole warping code to get any useful speed boost, including heavily optimizing coordinate transformations. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
