Re: [gdal-dev] Problem with black edges to DOQQs using JPEG in Tiff compression

[Brian Case]

steve and all

after reading my reply  I noticed a major error

"first, if your data is non lossy you need to nearblack -nb 0 -near 15"



this should read "nearblack -nb 0 -near 0"


Brian



On Sun, 2017-02-12 at 13:16 -0800, Brian Case wrote:
> Steve,
> 
> first, if your data is non lossy you need to nearblack -nb 0 -near 15
> 
> however your DOQQ's dont have a collar so there is no reason to
> nearblack
> 
> gdalwarp -dstalpha will crate an alpha band to mask out the collar after
> gdalwarp rotates the image. no nead to nearblack the output of gdal
> warp.
> 
> when using gdal_translate to create a tiff with a mask band, and you
> warped file has a alpha band, gdal_translate -b 1 -b 2 -b 3 -mask 4
> this will crate a mask band from the alpha band
> 
> brian
> 
> On Sat, 2017-02-11 at 18:18 -0500, Stephen Woodbridge wrote:
> > Hi All,
> > 
> > I need your wisdom. I'm downloading NAIP DOQQs in GTiff format and I 
> > have a processing chain something like the following:
> > 
> > gdalwarp -t_srs EPSG:4326 -dstalpha -r "bilinear -multi -co TILED=YES 
> > -dstnodata '0 0 0' srctiff tmpfile
> > 
> > nearblack -nb 15 -q tmpfile
> > 
> > gdal_translate -co TILED=YES -co JPEG_QUALITY=90 -co COMPRESS=JPEG -co 
> > PHOTOMETRIC=YCBCR -b 1 -b 2 -b 3 -mask auto --config 
> > GDAL_TIFF_INTERNAL_MASK YES  tmpfile, target
> > 
> > nearblack -nb 5 -q target
> > 
> > gdaladdo -clean -r bilinear  target 2 4 8 16 32 64 128 512
> > 
> > And create a tileindex for mapserver of all the tiffs
> > 
> > If I skip the gdal_translate (ie: JPEG compression) and the 2nd 
> > nearblack, the doqq tiles are perfect with no nearblack edges between 
> > the doqq tiles. But when a JPEG compress them, I get edges between the 
> > doqqs like this:
> > 
> > http://imaptools.com:8080/dl/doqq-issue.jpg
> > 
> > I've never used the JPEG in tiff compression and I'm very impressed by 
> > the amount of size reduction there and how good the image remains, but I 
> > have not been able to figure out the magic trick to clearing the edge 
> > artifacts.
> > 
> > Any help would be appreciated.
> > 
> > Thanks,
> >-Steve
> > 
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> > 
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem with black edges to DOQQs using JPEG in Tiff compression

[Brian Case]

Steve,

first, if your data is non lossy you need to nearblack -nb 0 -near 15

however your DOQQ's dont have a collar so there is no reason to
nearblack

gdalwarp -dstalpha will crate an alpha band to mask out the collar after
gdalwarp rotates the image. no nead to nearblack the output of gdal
warp.

when using gdal_translate to create a tiff with a mask band, and you
warped file has a alpha band, gdal_translate -b 1 -b 2 -b 3 -mask 4
this will crate a mask band from the alpha band

brian

On Sat, 2017-02-11 at 18:18 -0500, Stephen Woodbridge wrote:
> Hi All,
> 
> I need your wisdom. I'm downloading NAIP DOQQs in GTiff format and I 
> have a processing chain something like the following:
> 
> gdalwarp -t_srs EPSG:4326 -dstalpha -r "bilinear -multi -co TILED=YES 
> -dstnodata '0 0 0' srctiff tmpfile
> 
> nearblack -nb 15 -q tmpfile
> 
> gdal_translate -co TILED=YES -co JPEG_QUALITY=90 -co COMPRESS=JPEG -co 
> PHOTOMETRIC=YCBCR -b 1 -b 2 -b 3 -mask auto --config 
> GDAL_TIFF_INTERNAL_MASK YES  tmpfile, target
> 
> nearblack -nb 5 -q target
> 
> gdaladdo -clean -r bilinear  target 2 4 8 16 32 64 128 512
> 
> And create a tileindex for mapserver of all the tiffs
> 
> If I skip the gdal_translate (ie: JPEG compression) and the 2nd 
> nearblack, the doqq tiles are perfect with no nearblack edges between 
> the doqq tiles. But when a JPEG compress them, I get edges between the 
> doqqs like this:
> 
> http://imaptools.com:8080/dl/doqq-issue.jpg
> 
> I've never used the JPEG in tiff compression and I'm very impressed by 
> the amount of size reduction there and how good the image remains, but I 
> have not been able to figure out the magic trick to clearing the edge 
> artifacts.
> 
> Any help would be appreciated.
> 
> Thanks,
>-Steve
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] how to create just the msk file from a rgba vrt file

[Brian Case]

Duarte


gdaltranslate -of outfrmt -b 1 -b 2 -b 3 -mask 4 infile outfile 

brian

you can output to vrt's
just dont try to mosaic masked or aphad files with vrts

brian

On Thu, 2014-02-06 at 13:20 +, Duarte Carreira wrote:
> Hi there.
> 
>  
> 
> Continuing with trying to cut processing times, I am trying to get a
> msk file from a vrt mosaic, without converting the entire vrt to tif
> just to get the msk file.
> 
>  
> 
> In other words, how can we create a msk file from the alpha band
> without rewriting the whole image?
> 
>  
> 
> Thanks again.
> 
> Duarte
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> Duarte Carreira
> Diretor | Dep. Informação Geográfica e Cartografia
> 
> 
> www.edia.pt
> 
> www.alqueva.com.pt
> Tel. +351 284315100
> 
> 
> 
> 
> ___
> 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] Fast Pixel Access

[Brian Case]

-Jukka

tileindex, mapserver, and the gdal wms driver



On Mon, 2014-02-03 at 17:20 +, Jukka Rahkonen wrote:
> Luke Roth  gmail.com> writes:
> 
> > 
> > Another thing that might speed up access is setting the config
> option GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment
> variable or on the command line.  That should help with GDAL reading the
> directory each time it opens a dataset.  I have an application which reads
> one value from each of a large number of datasets and setting this option
> made it run about 3 times faster.
> 
> 
> Hi,
> 
> You are right. This config option makes GDAL to skip the reading of the
> remote directory and saves a lot of bandwidth:
> 
> VRT case: 
> Bytes Received:  4 244 509 (of which the vrt file: 4 192 577)
> Sequence (clock) duration:00:00:09.9996000
> Was:
> Bytes Received:  6 459 443
> Sequence (clock) duration:00:00:37.813
> 
> BigTIFF case: 
> Bytes Received:  2 158 917
> Sequence (clock) duration:00:00:04.4368000
> Was:
> Bytes Received:  4 374 137
> Sequence (clock) duration:00:00:30.9192000
> 
> 
> Conclusion:
> Both options are unsuitable for serious use while amusing to play with.
> Reading the BigTIFF tile offset index (or whatever it is) seems to mean
> about 2 MB of compultory payload traffic. Reading the VRT file means in this
> example 4 MB of payload. If this sort of net access to a large directory of
> raster files should be important for someone there should be a way to find
> the right raster file and righ data range in that file with minimum amount
> of bytes. Perhaps some kind of rtree indexed vrt file? First aid might be to
> keep the vrt file on the client side.
> 
> -Jukka Rahkonen- 
> 
> 
> ___
> 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] Fast Pixel Access

[Brian Case]

evenr


what about the use of a tileindex? seems an intersection with a set of
polys first would be quick

brian





On Fri, 2014-01-31 at 19:30 +0100, Even Rouault wrote:
> Le vendredi 31 janvier 2014 17:15:53, David Baker (Geoscience) a écrit :
> > Dev's,
> > 
> > I have a set of 55,501 bil files in a single directory.  They are DEMS data
> > that cover the US in 7.5 minute tiles.  I would like to randomly access
> > elevations at a given lat/lon's from the whole dataset.  I created a vrt
> > file from the directory of bil files, and have been able to access the
> > elevation at a given lat/lon using gdallocationinfo, but because of the
> > size of the dataset, this operation is somewhat slow.  Can the vrt be
> > indexed?
> 
> No, it isn't currently, although I think it could be improved to have a in-
> memory index with moderate effort.
> 
> But are you sure the slowness is due to the lack of index ? 55,000 is a big 
> number, but not that big. Maybe the slowness just comes from the opening time 
> (XML parsing) of such a big VRT. That would need to be profiled to be sure 
> where the bottleneck is.
> 
> > Or, is there a faster, better way to access the pixels?  I would
> > first like to do this with the utilities before diving into code (C#). 
> > The files are regularly named base on their location within a 1 arc-second
> > grid.
> > 
> > Thanks,
> > David
> > 
> > David M. Baker
> > Senior Advisor - Geoscience Technology
> > Chesapeake Energy Corporation
> > david.m.ba...@chk.com
> > 
> > 
> > 
> > 
> > This email (and attachments if any) is intended only for the use of the
> > individual or entity to which it is addressed, and may contain information
> > that is confidential or privileged and exempt from disclosure under
> > applicable law. If the reader of this email is not the intended recipient,
> > or the employee or agent responsible for delivering this message to the
> > intended recipient, you are hereby notified that any dissemination,
> > distribution or copying of this communication is strictly prohibited. If
> > you have received this communication in error, please notify the sender
> > immediately by return email and destroy all copies of the email (and
> > attachments if any).
> 
> -- 
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> ___
> 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] Can gdal_rasterize utilize OGR_STYLE?

[Brian Case]

Jukka

you could use mapserver to create your image. it will make use of
ogrstyle

shp2img or if that is an issue use mapserver and the wms driver in gdal

brian

On Thu, 2014-01-30 at 15:51 +, Jukka Rahkonen wrote:
> Hi,
> 
> By reading the manual page and after doing some experiments I guess that the
> answer is no. Is there any hidden parameter for burning lines with a wider
> pen than what is the default?
> 
> -Jukka Rahkonen-
> 
> ___
> 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] Question about gdaladdo and raster mosaicking

[Brian Case]

Ammar


you want to turn on internal masks in the shell, gdaladdo will not use
them otherwise. also you will need to turn this on if you use mapserver.
gdal will need to have this turned on for any further operations.

gdaladdo should use the correct image options without specifying them

export GDAL_TIFF_INTERNAL_MASK=YES

gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha \
 -input_file_list tiff_list.txt \
 mosaic02.vrt


gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 \
   -co TILED=yes -co photometric=ycbcr \
   -co compress=jpeg -co jpeg_quality=80 \
   -co blockxsize=512 -co blockysize=512 \
   -mosaic02.vrt \
   -mosaic02.tif

gdaladdo mosaic02.tif -r average 2 4 8 16 32 64 128 256 512



and you should end up with a 



On Thu, 2014-01-23 at 06:28 -0800, Ammar wrote:
> Etienne,
> 
> I tried the following:
> 
> gdalbuildvrt -srcnodata 255 -vrtnodata 255 -addalpha -input_file_list
> tiff_list.txt mosaic02.vrt
> 
> gdal_translate -of GTiff -b 1 -b 2 -b 3 -mask 4 -a_srs EPSG:3011 -co
> TILED=yes -co compress=jpeg -co jpeg_quality=80 -co blockxsize=512 -co
> blockysize=512 -co photometric=ycbcr --config gdal_tiff_internal_mask
> yes mosaic02.vrt mosaic02.tif
> 
> gdaladdo mosaic02.tif -r average --config COMPRESS_OVERVIEW JPEG
> --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL
> --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512
> 
> Did I implement the mask the right way? The results I got were similar
> to the JPEG compression with no mask, in other words I got white lines
> too!
> 
> 
> 
> 
> 
> 
> 
> 
> __
> From: Etienne Tourigny 
> To: Ammar  
> Cc: Chaitanya kumar CH ; gdal dev
>  
> Sent: Thursday, January 23, 2014 12:25 PM
> Subject: Re: [gdal-dev] Question about gdaladdo and raster mosaicking
> 
> 
> As was suggested, you could try using a mask instead.
> 
> 
> On Thu, Jan 23, 2014 at 7:52 AM, Ammar  wrote:
> Chaitanya,
> 
> Thank you very much for your reply and suggestion. I have used
> LZW with predictor 2 compression and added external overviews
> compressed in LZW too and the image came perfect. The only
> downside is the size of each of the images has expanded from
> approx. 2 GB to 18-20 GB. So now I have to choose between
> quality and size!
> 
> Attached are two screen shots showing the difference.
> 
> Thanks again!
> 
> Regards,
> Ammar
> 
> 
> 
> 
> 
> 
> __
> From: Chaitanya kumar CH 
> To: ammar8...@yahoo.com 
> Cc: gdal dev  
> Sent: Tuesday, January 21, 2014 6:27 PM
> Subject: Re: Question about gdaladdo and raster mosaicking
> 
> 
> Ammar,
> You are using lossy JPEG compression. I'm guessing that the
> white lines are are actually pixels with values near but not
> equal to 255. So, they are not treated as nodata pixels.
> My suggestion is to use another format with lossless
> compression for the 21 images or use a mask band if you
> prefer.
> Let me know how it goes.
> --
> Best regards,
> Chaitanya Kumar CH
> On 21-Jan-2014 5:31 pm,  wrote:
> Hello Chaitanya,
> 
> I was looking online for solutions to my problem and I
> cam across some of your posts so I thought you might
> help me with my problem.
> 
> I have 10,000+ TIFF files that I want to merge into
> one big Image and serve using GeoServer. I merged
> every 500 images at a time creating using gdalbuildvrt
> and gdal_translate along with JPEG compression
> creating 21 TIFF files. I added overviews then to each
> of the new 21 files. When adding the images together,
> once directly as files using QGIS and another time as
> WMSs using GeoServer, I got white lines/gaps precisely
> at the border of ever 2 images. I thought the problem
> is with no data values but I decided to take another
> approach and merged all the 10,000 files into one huge
> image and this time I got one perfect image with no
> lines or gaps. I failed to create overviews for the
> big image because the process took days or gdaladdo
> running with no progress. I tested then on smaller
> images with and without overviews and the ones with no
> overview came perfect while the one with gdaladdo
> ove

Re: [gdal-dev] Reading CurveString and CurvePolygon Geometries from FGF Data

[Brian Case]

bob,

if you decide to go the mask band route you wont be able to use a vrt.
you will need to use gdalwarp or mapserver

Brian


On Tue, 2014-01-21 at 09:04 -0800, Bob Cave wrote:
> Even Rouault wrote
> > Le vendredi 17 janvier 2014 17:08:38, Bob Cave a écrit :
> >> Hello,
> >> 
> >> I am using the OGR Spatialite driver to read a database that has FGF
> >> geometries.  Some of the geometries are CurvePolygons, which are not
> >> currently supported in OGRGeometryFactory::createFromFgfInternal() as of
> >> GDAL 1.10.1.
> >> 
> >> Is support for FGF CurveString and CurvePolygon geometries currently in
> >> development?
> > 
> > Not that I'm aware of.
> > 
> > There's not yet support in OGR core for curve geometries, so that would be
> > a 
> > preliminary step to implement support for the FGF curve geometries. This
> > is 
> > something that could be part of the big changes for OGR 2.0 
> > (http://trac.osgeo.org/gdal/wiki/GDAL20Changes). A few years ago I had
> > started 
> > preliminary work in a sandbox but didn't pursue.
> > 
> > Another annoying thing for implementation is that the link in 
> > http://trac.osgeo.org/fdo/wiki/FDORfc16 to the FGF binary spec seems to
> > have 
> > disappeared.
> > 
> > Do people actually use FDO SQLite databases ?
> 
> Apparently, one of our customers uses an FDO SQLite database.  
> 
> I have seen that the OGR core does not currently support curve geometries,
> so these objects could not be handled that way.  I was thinking that perhaps
> someone might be working on producing a polyline or polygon representation
> of an FGF curve object.
> 
> I found the FGF Binary Specification  here
> 
>  
> .
> 
> Thanks,
> 
> Bob
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Reading-CurveString-and-CurvePolygon-Geometries-from-FGF-Data-tp5098667p5099296.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] gdalwarp producing rgb 0 0 0 for input nodata areas

[Brian Case]

rick

you cannot preserve the nodata areas with jpeg output. you will have a
line around your image that is not quite your nodata values.

leave your files as geotiff until you merge them.

you did preserve the nodata with your gdalwarp just in the form of an
alpha band

you can merge your files with gdalwarp in1.tif in2.tif in3.tif out.tif

Brian

On Wed, 2013-02-20 at 10:33 -0800, Rick wrote:
> Hi all,
> I have a set of ecw files that I wish to gdalwarp to a new coordinate system
> and convert to jpg.
> 
> I have been using these commands:
> gdal_translate in.ecw out_gt.tif -a_nodata none -of GTiff -co TFW=YES
> gdalwarp -s_srs EPSG:26909 -t_srs EPSG:3005 -of GTiff -co TFW=YES -dstalpha
> out_gt.tif out_warp.tif
> gdal_translate -of JPEG -co "WORLDFILE=YES" out_warp.tif out.jpg
> 
> The first translate works as expected and the nodata values are preserved.
> The gdalwarp command converts the nodata areas to 0,0,0.
> The second translate works as expected and the nodata values are preserved.
> 
> I am using ArcGIS 10.1 to view the results.
> 
> How does one preserve nodata areas via gdalwarp?
> 
> My eventual goal is to merge these data sets but have a need for the interim
> products to have the nodata areas.
> 
> Thanks
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/gdalwarp-producing-rgb-0-0-0-for-input-nodata-areas-tp5035602.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Brian Case
KF7WPK
r...@winkey.org


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_polygonize and polygon edges

[Brian Case]

a few years ago someone had posted some perl code for making polys from
the contour output.

the idea was to sort the lines into an m-way tree by contains with the
root node being the extent of the data then each node would be outer
ring and a copy of the children being the inner rings

i have done this myself and it works

Brian


On Tue, 2013-02-19 at 14:28 -0500, Jeff Lacoste wrote:
> Hi Frank,
> 
> 
> Thanks for your quick response. Following the edges of the pixels
> seems a perfect solution for non continuous grid (ex. land use, etc.)
> as
> the boundary between the class is important to keep when constructing
> the polygon. However for continuous grid (.ex elevations), the
> boundaries are
> a bit not clear and not clear cut. When following the pixels edges,
> the created polygons appear to have the stairs effect and are
> less visually attractive.
> 
> 
> I thought of a smoothing the polygons to not have *rough* edges using
> the current gdal_polygonize by trying to not follow the pixels edges
> and use instead of the
> pixel centers. Basically do something similar to what contour
> generator does by treating the raster values as continuous.
> 
> 
> Thanks
> 
> 
> On Tue, Feb 19, 2013 at 1:44 PM, Frank Warmerdam 
> wrote:
> On Tue, Feb 19, 2013 at 10:29 AM, Jeff Lacoste
>  wrote:
> > Hi,
> >
> > I'm using gdal_polygonize.py to create polygon from a grid
> and the output
> > polygons seems to follow the edges
> > of the grid pixels. I was wondering if there is any way to
> change/edit the
> > code to instead of following the edges
> > of the pixels, use the center of the pixels as the nodes of
> the created
> > polygons ?
> >
> > So instead of a polygon following the edges of the pixels,
> it will instead
> > be passing through the center of the connected
> > pixels... This is to avoid having a scale effect of
> following the pixels
> > edges.
> 
> 
> Jeff,
> 
> With the current algorithm, this is not really possible.
> 
> I am also not clear what it would mean to go from pixel center
> to
> pixel center.  The algorithm attempts to identify the borders
> between
> regions of different pixel values and turn them into
> polygons.  What
> does it mean to make a polygon boundary that goes through the
> center
> of a pixel with a particular value?
> 
> Another algorithm you might want to keep in mind is the
> contour
> generator.  It treats the the raster values as a continuous
> field, and
> builds edges based on linear interpolation between pixel
> centers.
> This gives a result that could pass through a pixel center if
> it
> happens to be an exact contour level.
> 
> 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 Software
> Developer
> 
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Brian Case
KF7WPK
r...@winkey.org


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] substitute pixel values

[Brian Case]

hey Michael

i have done this with a vrt.

you can use a 

The ComplexSource supports adding a custom lookup table to transform the
source values to the destination. The LUT can be specified using the
following form:

[src value 1]:[dest value 1],[src value 2]:[dest value
2],...


http://www.gdal.org/gdal_vrttut.html


you should also keep in mind gdal will not know the difference between -
values in death valley and - values in the ocean

Brian

On Wed, 2013-01-09 at 16:33 +, Smith, Michael wrote:
> I have some DEMs that are created from lidar.  For reasons related to
> seeing currents and wind effect, we did not ask for the water to be
> flattened, but rather it shows waves.  This is cool, and what we
> wanted.  BUT of course now we want to create a second set of DEMs with
> a  nice flat ocean.
> 
>  
> 
> I have numerous pixels out in the ocean which are slightly less than
> 0.  So how does one select out all pixels < 0 and substitute them with
> 0 with GDAL?  
> 
>  
> 
> ===
> Michael Smith MS GISP
> State GIS Manager, Maine Office of GIS
> State of Maine, Office of Information Technology
> michael.smith _at_ maine.gov
> 207-215-5530
> 
> Board Member, Maine GeoLibrary
> Education Chair, Maine GIS Users Group
> State Rep, National States Geographic Information Council
> icons
> 
> ***NOTE NEW ADDRESS***
> 
> State House Station 145
> 51 Commerce Drive
> Augusta, ME 04333-0145
> 69o 47' 58.9"W  44o 21' 54.8"N
> 
> 
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Brian Case
KF7WPK
r...@winkey.org


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Multiple pens in OGR feature style

[Brian Case]

i never considered this possibility when writing the libkml driver.

perhaps check what mapserver does?.

there is not a lot that uses featurestyle. perhaps a clarification of
this in the spec is in order?

brian

On Mon, 2012-12-10 at 09:34 -0700, David Strip wrote:
> On 12/10/2012 7:29 AM, Even Rouault wrote:
> > Looking at addstylestring2kml() in 
> > ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I
> > can see that only one PEN instance will be taken into account (looking at 
> > the
> > coulde, I would have said that it would be the last occurence...). And it 
> > seems
> > that it is a limitation of LIBKML itself, since the Style class seems to 
> > accept
> > only one line style.
> If I'm reading the docs right, KML doesn't support multi-pen lines. 
> Google Earth extensions to KML, however, do allow a two-color line, so 
> it makes sense that LIBKML would not allow this.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Brian Case
KF7WPK
r...@winkey.org


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unable to open GRIB file

[Brian Case]

On Wed, 2012-02-15 at 09:10 +0300, SupportLists wrote:

Carlos

is it raster or vector data?

can you make the file accessible some place? 

Brian

> Hi,
> 
> I am trying to open a grib file (meteorological data) with GDAL 1.8.1 
> but i get the following error:
> 
> ./2011.grib is a grib file, but no raster dataset was successfully 
> identified.
> gdalinfo failed - unable to open './2011.grib'
> 
> Other tools like wgrib successfully opens the same file.
> 
> Any idea what is wrong?
> 
> Thanks,
> Carlos.
> 
> ___
> 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] building geotransform with lower left and upper right coordinates

[Brian Case]

Brice,

After some thought your image might not be bottom up. if thats the case
calc the origin the way you did before, but don't convert back to lat
lon

Brian

On Mon, 2012-02-13 at 05:40 -0700, la...@ucar.edu wrote:
> Hello,
> 
> I have a raster where I know the projection and the lower left and upper
> right coordinates and pixel size but I don't know the upper left
> coordinate.  It is a lambert conformal conic projection:
> 
> "+proj=lcc +lon_0=95W +lat_0=25N +lat_1=25N"
> 
> where the lower left is -113.1333, 16.3691
> upper right is -49.385, 57.289
> dx/dy is 1015.875 (m)
> width/height is 5120
> 
> I've tried transforming the lower left lat/lon to lcc projection, adding
> dy*height and then converting back to lat/lon (and a few variations of
> this) but I can't seem to get a proper answer for what the upper left
> should be so I can build a proper geotransform for this dataset.  I've
> tried adding two GCPs for these points but gdalwarp says it doesn't have
> enough points to complete the warp.
> 
> How can I find the upper left with the given information so I can build
> the geotransform?
> 
> Any help is greatly appreciated!
> 
> Brice
> 
> 
> 
> 
> ___
> 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] building geotransform with lower left and upper right coordinates

[Brian Case]

Brice,

with that projection the origin should be in meters. convert the ll to
meters and try setting dy to dy * -1

Brian

On Mon, 2012-02-13 at 05:40 -0700, la...@ucar.edu wrote:
> Hello,
> 
> I have a raster where I know the projection and the lower left and upper
> right coordinates and pixel size but I don't know the upper left
> coordinate.  It is a lambert conformal conic projection:
> 
> "+proj=lcc +lon_0=95W +lat_0=25N +lat_1=25N"
> 
> where the lower left is -113.1333, 16.3691
> upper right is -49.385, 57.289
> dx/dy is 1015.875 (m)
> width/height is 5120
> 
> I've tried transforming the lower left lat/lon to lcc projection, adding
> dy*height and then converting back to lat/lon (and a few variations of
> this) but I can't seem to get a proper answer for what the upper left
> should be so I can build a proper geotransform for this dataset.  I've
> tried adding two GCPs for these points but gdalwarp says it doesn't have
> enough points to complete the warp.
> 
> How can I find the upper left with the given information so I can build
> the geotransform?
> 
> Any help is greatly appreciated!
> 
> Brice
> 
> 
> 
> 
> ___
> 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] Geolocation Arrays ??

[Brian Case]

Etienne

the algorithm that finds the target extent is not in the transformer

Brian

On Sun, 2012-02-12 at 13:17 -0200, Etienne Tourigny wrote:
> Brian,
> 
> I'm not sure I understand your point - I probably don't understand the
> algorithm enough. Are both the forward and reverse transformations
> necessary in all cases?
> 
> My point is that, if (manually) adding the -te option to gdalwarp is
> necessary in most cases, why not (automatically) setting the extents
> from the min/max of the geolocation arrays instead of trying to
> calculate them?
> This could fix when the algorithm fails or generates an extent that is
> too large.
> 
> Etienne
> 
> On Sun, Feb 12, 2012 at 12:38 PM, Brian Case  wrote:
> > the forward transform is pretty strait forwards, however the reverse is
> > not, it creates back-mask (a geo-referenced image that contains the x/y 
> > locations
> > in the source image). the points that the warper tries to transform to
> > figure out the target extent are no-data in the back-mask.
> >
> > Brian
> >
> > On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:
> >> Brian, thanks fot the info.
> >>
> >> I have seen that on all tests I made (without -te option).  Sometimes
> >> it fails completely, and sometimes it creates an extent that is too
> >> large.
> >>
> >> Would it make sense, if the geolocation SRS and target are SRS are the
> >> same (e.g. WGS84), to calculate the target extents from the min/max of
> >> the geolocation arrays?
> >> Current extent detection code seems to try many transformations with
> >> proj4, and either fails or creates an extent that is too large.
> >>
> >> regards,
> >> Etienne
> >>
> >>
> >> On Tue, Feb 7, 2012 at 8:46 PM, Brian Case  wrote:
> >> > Etienne
> >> > with the transformer the way it sits now, in most cases you will need to
> >> > specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
> >> >
> >> > Brian
> >> >
> >> >
> >> > On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
> >> >> Even, Frank,
> >> >>
> >> >> thanks for your answers.  I have run into a problem with using
> >> >> gdalwarp with geoloc transform.
> >> >>
> >> >> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> >> >> GEOLOCATION metadata.
> >> >>
> >> >> Trying gdalwarp on it gives an error, and the result transform is
> >> >> incorrect.  Am I doing something wrong, or is this a bug?
> >> >>
> >> >> command is : gdalwarp -geoloc -t_srs EPSG:4326
> >> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> >> more info below:
> >> >>
> >> >> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> >> >> Driver: HDF4Image/HDF4 Dataset
> >> >> Files: A2006005182000.L2_LAC_SST.x.hdf
> >> >> Size is 389, 602
> >> >> Coordinate System is `'
> >> >> Metadata:
> >> >> [...]
> >> >> Geolocation:
> >> >>   LINE_OFFSET=0
> >> >>   LINE_STEP=1
> >> >>   PIXEL_OFFSET=0
> >> >>   PIXEL_STEP=1
> >> >>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> >> >> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
> >> >>   X_BAND=1
> >> >>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
> >> >>   Y_BAND=1
> >> >>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> >> >> Corner Coordinates:
> >> >> [...]
> >> >>
> >> >> $ gdalwarp -geoloc -t_srs EPSG:4326
> >> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> >> Creating output file that is 31119P x 5864L.
> >> >> Processing input file 
> >> >> HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> >> >> ERROR 1: Too many points (441 out of 441) failed to transform,
&

Re: [gdal-dev] Geolocation Arrays ??

[Brian Case]

the forward transform is pretty strait forwards, however the reverse is
not, it creates back-mask (a geo-referenced image that contains the x/y 
locations
in the source image). the points that the warper tries to transform to
figure out the target extent are no-data in the back-mask.

Brian

On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:
> Brian, thanks fot the info.
> 
> I have seen that on all tests I made (without -te option).  Sometimes
> it fails completely, and sometimes it creates an extent that is too
> large.
> 
> Would it make sense, if the geolocation SRS and target are SRS are the
> same (e.g. WGS84), to calculate the target extents from the min/max of
> the geolocation arrays?
> Current extent detection code seems to try many transformations with
> proj4, and either fails or creates an extent that is too large.
> 
> regards,
> Etienne
> 
> 
> On Tue, Feb 7, 2012 at 8:46 PM, Brian Case  wrote:
> > Etienne
> > with the transformer the way it sits now, in most cases you will need to
> > specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
> >
> > Brian
> >
> >
> > On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
> >> Even, Frank,
> >>
> >> thanks for your answers.  I have run into a problem with using
> >> gdalwarp with geoloc transform.
> >>
> >> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> >> GEOLOCATION metadata.
> >>
> >> Trying gdalwarp on it gives an error, and the result transform is
> >> incorrect.  Am I doing something wrong, or is this a bug?
> >>
> >> command is : gdalwarp -geoloc -t_srs EPSG:4326
> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> more info below:
> >>
> >> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> >> Driver: HDF4Image/HDF4 Dataset
> >> Files: A2006005182000.L2_LAC_SST.x.hdf
> >> Size is 389, 602
> >> Coordinate System is `'
> >> Metadata:
> >> [...]
> >> Geolocation:
> >>   LINE_OFFSET=0
> >>   LINE_STEP=1
> >>   PIXEL_OFFSET=0
> >>   PIXEL_STEP=1
> >>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> >> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
> >>   X_BAND=1
> >>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
> >>   Y_BAND=1
> >>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> >> Corner Coordinates:
> >> [...]
> >>
> >> $ gdalwarp -geoloc -t_srs EPSG:4326
> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> Creating output file that is 31119P x 5864L.
> >> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> >> ERROR 1: Too many points (441 out of 441) failed to transform,
> >> unable to compute output bounds.
> >> 0...10...20...30...40...50...60...70...80...90...100 - done.
> >>
> >> $ gdalinfo tmp1.tif
> >> Driver: GTiff/GeoTIFF
> >> Files: tmp1.tif
> >> Size is 31119, 5864
> >> Coordinate System is:
> >> GEOGCS["WGS 84",
> >> DATUM["WGS_1984",
> >> SPHEROID["WGS 84",6378137,298.257223563,
> >> AUTHORITY["EPSG","7030"]],
> >> AUTHORITY["EPSG","6326"]],
> >> PRIMEM["Greenwich",0],
> >> UNIT["degree",0.0174532925199433],
> >> AUTHORITY["EPSG","4326"]]
> >> Origin = (-90.198287963867188,90.311)
> >> Pixel Size = (0.015398926739995,-0.015398926739995)
> >> Metadata:
> >>   AREA_OR_POINT=Area
> >> Image Structure Metadata:
> >>   INTERLEAVE=BAND
> >> Corner Coordinates:
> >> Upper Left  ( -90.1982880,  90.300) ( 90d11'53.84"W, 90d18' 0.00"N)
> >> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> >> Upper Right ( 389.001,  90.300) (Invalid angle, 90d18' 0.00"N

Re: [gdal-dev] Geolocation Arrays ??

[Brian Case]

Etienne
with the transformer the way it sits now, in most cases you will need to
specify -te xmin ymin xmax ymax with gdalwarp to avoid that error

Brian


On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
> Even, Frank,
> 
> thanks for your answers.  I have run into a problem with using
> gdalwarp with geoloc transform.
> 
> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> GEOLOCATION metadata.
> 
> Trying gdalwarp on it gives an error, and the result transform is
> incorrect.  Am I doing something wrong, or is this a bug?
> 
> command is : gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> more info below:
> 
> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> Driver: HDF4Image/HDF4 Dataset
> Files: A2006005182000.L2_LAC_SST.x.hdf
> Size is 389, 602
> Coordinate System is `'
> Metadata:
> [...]
> Geolocation:
>   LINE_OFFSET=0
>   LINE_STEP=1
>   PIXEL_OFFSET=0
>   PIXEL_STEP=1
>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>   X_BAND=1
>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>   Y_BAND=1
>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> Corner Coordinates:
> [...]
> 
> $ gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> Creating output file that is 31119P x 5864L.
> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> ERROR 1: Too many points (441 out of 441) failed to transform,
> unable to compute output bounds.
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> 
> $ gdalinfo tmp1.tif
> Driver: GTiff/GeoTIFF
> Files: tmp1.tif
> Size is 31119, 5864
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (-90.198287963867188,90.311)
> Pixel Size = (0.015398926739995,-0.015398926739995)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( -90.1982880,  90.300) ( 90d11'53.84"W, 90d18' 0.00"N)
> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> Upper Right ( 389.001,  90.300) (Invalid angle, 90d18' 0.00"N)
> Lower Right ( 389.001,   0.001) (Invalid angle,  0d 0' 2.50"N)
> Center  ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
> 
> 
> Regards,
> Etienne
> 
> 
> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam  wrote:
> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
> >  wrote:
> >> Hi all,
> >>
> >> I would like to have information on the status of geolocation array
> >> support in GDAL.
> >>
> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> >> still "under development", and the information there is that
> >> GDALCreateGeoLocTransformer "is currently partially implemented".
> >
> > Etienne,
> >
> > I think the geoloc transformer received some fixes from someone
> > other than myself and now is working reasonable well.  It would
> > be desirable to freshen up the RFC and get it passed but it isn't
> > particularly a priority of mine so I'm not likely to drive it in the
> > very near future.
> >
> > 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 Software Developer
> ___
> 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] End User Questions :( KML Raster to Shapefile

[Brian Case]

Dennis

gdal does not have any code for reading raster files in kml/kmz like
that. can you make the files you have available so i can look?

Brian


On Mon, 2012-01-16 at 17:11 -0600, Dennis Burgess wrote:
> I have a .KML File and .PNG file or a .TIF along with a .GEO file that
> my application exports.
> 
>  
> 
> Once there, I need to convert these to a shape file for mailing lists,
> but so far I have only found several application extensions that do
> this, but nothing command line.  I believe that the gdaltindex could
> work, but it shoots me back a no georeferencing is avail for the
> getotif.tif files ..
> 
>  
> 
>  
> 
> Any suggestions would be great.
> 
>  
> 
> Dennis
> 
> 
> ___
> 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] Warping onto an image with only GCPs with Python

[Brian Case]

Anton,

you can get the extents of the modis swath file from the metadata.

you have to use the the geolocation arrays to create a grid from the
swath file. the further left and right from the center of the image the
more area the single pixel in the swath file covers. also modis is a
pushbroom sensor. every 10 lines in the 1k file (20 in the 500m and 40
in the 250m) overlap the previous and next set. this is called the
bowtie effect. as it is right now gdal cannot properly deal with this.

short term I would use swath2grid to create tiffs of your data.


see http://trac.osgeo.org/gdal/ticket/4193
http://trac.osgeo.org/gdal/ticket/4192
http://trac.osgeo.org/gdal/ticket/4188

if you have any additional information or issues please add them


Brian



On Fri, 2012-01-13 at 10:33 +0100, Anton Korosov wrote:
> Dear Brian,
> 
> thank you very much for your reply!
> 
> The '-geoloc' switch does produce the error about points failing to 
> transform but the principal limitation is that I cannot use the '-te' 
> switch because I cannot know the extent in advance.
> 
> My task is to overlay one image (either projected like e.g. Europe map 
> or unprojected like e.g. L1B MERIS or MODIS image) onto another 
> UNprojected image (MODIS or MERIS image with GCPs or geolocation 
> arrays). And GDAL cannot do that correctly neither with gdalwarp (no 
> matter which options I use) nor with Python bindings. It produces an 
> output where the source image is place in the top left corner of the 
> destination image.
> 
> Obviously this problem arises from a bug in the GDAL code and I will try 
> to issue a descriptive bug report.
> 
> All the best!
> Anton
> 
>  > Anton
>  >
>  > EOS_SWATH has 2 geolocation arrays, you might try the -geoloc switch to
>  > gdalwarp, otherwise it creates a handfull of gcps from the arrays, if
>  > you get a error about points failing to transform, set the output extent
>  > with the -te switch.
>  >
>  > also you could try the swath2grid application in
>  > https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath
>  >
>  > Brian
>  >
>  >
>  > On Thu, 2012-01-12 at 09:23 +0100, Anton Korosov wrote:
>  >> Hello everyone!
>  >>
>  >> Some time ago I've asked about problems with gdalwarp  (the e-mails
>  >> below). I tried to utilize Python binding instead but got the same
>  >> results. This brief script overlays the Europe map (GeoTIFF with
>  >> geotransform) onto a MERIS images (PDS file with GCPs). But the result
>  >> looks wrong again - the map is very small and apperas in the upper left
>  >> corner (attached file).
>  >>
>  >> GCPfile='MER_RR__2PNPDK20030809_100609_22512018_00466_07534_3898.N1'
>  >> geotransformfile = 'europe.tif'
>  >> outfile = 'colocated.tif'
>  >>
>  >> # open input datasets
>  >> src_ds = gdal.Open(geotransformfile)
>  >> dst_ds = gdal.Open(GCPfile)
>  >>
>  >> # create writable copy of the destination image
>  >> driver = gdal.GetDriverByName( "GTiff" )
>  >> out_ds = driver.CreateCopy(outfile, dst_ds, 0 )
>  >>
>  >> # reproject onto destination image with GCPs
>  >> gdal.ReprojectImage(src_ds, out_ds)
>  >>
>  >> Can you please confirm that this is a bug in GDAL? If so I will issue a
>  >> bug report.
>  >>
>  >> Thank you in advance!
>  >> Anton
>  >>
>  >> PS. If the GCPs in the destination image are replaced with a
>  >> GeoTransfrom generated using the gdal.GCPsToGeoTransform() function, the
>  >> result looks much better but the image is still rather distorted. Which
>  >> is understandable because curvature of a MERIS images (given by GCPs)
>  >> cannot be fully explained by few numbers in the geotransform.
>  >>
>  >>
>  >>
>  >>
>  >> On 12/16/2011 03:56 PM, Anton Korosov wrote:
>  >>> Hi!
>  >>>
>  >>> I'm not sure but probably my question is related to the one below.
>  >>> I'm trying to mosaic one MODIS images onto another with GDAL:
>  >>>
>  >>> gdal_translate
>  >>> 
> HDF4_EOS:EOS_SWATH:"/Data/sat/GDAL_test/MYD021KM.A2011228.0925.005.2011229003113.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
>  >>> -b 1 /data/modis1.tif
>  >>>
>  >>> gdal_translate
>  >>> 
> HDF4_EOS:EOS_SWATH:"/Data/sat/GDAL_test/MOD021KM.A2011229.1125.005.2011229195243.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
>  >>> -b 1 /data/modis2.tif
>  >>>
>  >>> gdalwarp modis1.tif modis2.tif
>  >>>
>  >>> Bu the results looks weird - the first image is on top of the 
> second one
>  >>> but it is very small, distorted and in the top-left corner (though they
>  >>> cover approximately the same area).
>  >>>
>  >>> Do I understand right that such operation would work only when the
>  >>> target image georeference is defined by GeoTransform and not by GCPs?
>  >>>
>  >>> Can I also ask if it is a big work to include ability of GDAL to warp
>  >>> onto grid with GCPs (or RPC or geolocation array) ? And if it is 
> planned
>  >>> in some future?
>  >>>
>  >>> Thank you!
>  >>> Anton
>  >>>
>  >>> On 12/15/2011 03:47 PM, Knut-Frode Dagestad wrote:
>   Hi,
>  
>   Hróbjartur Þorsteinsso

Re: [gdal-dev] Warping onto an image with only GCPs with Python

[Brian Case]

Anton

EOS_SWATH has 2 geolocation arrays, you might try the -geoloc switch to
gdalwarp, otherwise it creates a handfull of gcps from the arrays, if
you get a error about points failing to transform, set the output extent
with the -te switch.

also you could try the swath2grid application in
https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath

Brian


On Thu, 2012-01-12 at 09:23 +0100, Anton Korosov wrote:
> Hello everyone!
> 
> Some time ago I've asked about problems with gdalwarp  (the e-mails 
> below). I tried to utilize Python binding instead but got the same 
> results. This brief script overlays the Europe map (GeoTIFF with 
> geotransform) onto a MERIS images (PDS file with GCPs). But the result 
> looks wrong again - the map is very small and apperas in the upper left 
> corner (attached file).
> 
> GCPfile='MER_RR__2PNPDK20030809_100609_22512018_00466_07534_3898.N1'
> geotransformfile = 'europe.tif'
> outfile = 'colocated.tif'
> 
> # open input datasets
> src_ds = gdal.Open(geotransformfile)
> dst_ds = gdal.Open(GCPfile)
> 
> # create writable copy of the destination image
> driver = gdal.GetDriverByName( "GTiff" )
> out_ds = driver.CreateCopy(outfile, dst_ds, 0 )
> 
> # reproject onto destination image with GCPs
> gdal.ReprojectImage(src_ds, out_ds)
> 
> Can you please confirm that this is a bug in GDAL? If so I will issue a 
> bug report.
> 
> Thank you in advance!
> Anton
> 
> PS. If the GCPs in the destination image are replaced with a 
> GeoTransfrom generated using the gdal.GCPsToGeoTransform() function, the 
> result looks much better but the image is still rather distorted. Which 
> is understandable because curvature of a MERIS images (given by GCPs) 
> cannot be fully explained by few numbers in the geotransform.
> 
> 
> 
> 
> On 12/16/2011 03:56 PM, Anton Korosov wrote:
> > Hi!
> >
> > I'm not sure but probably my question is related to the one below.
> > I'm trying to mosaic one MODIS images onto another with GDAL:
> >
> > gdal_translate
> > HDF4_EOS:EOS_SWATH:"/Data/sat/GDAL_test/MYD021KM.A2011228.0925.005.2011229003113.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > -b 1 /data/modis1.tif
> >
> > gdal_translate
> > HDF4_EOS:EOS_SWATH:"/Data/sat/GDAL_test/MOD021KM.A2011229.1125.005.2011229195243.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > -b 1 /data/modis2.tif
> >
> > gdalwarp modis1.tif modis2.tif
> >
> > Bu the results looks weird - the first image is on top of the second one
> > but it is very small, distorted and in the top-left corner (though they
> > cover approximately the same area).
> >
> > Do I understand right that such operation would work only when the
> > target image georeference is defined by GeoTransform and not by GCPs?
> >
> > Can I also ask if it is a big work to include ability of GDAL to warp
> > onto grid with GCPs (or RPC or geolocation array) ? And if it is planned
> > in some future?
> >
> > Thank you!
> > Anton
> >
> > On 12/15/2011 03:47 PM, Knut-Frode Dagestad wrote:
> >> Hi,
> >>
> >> Hróbjartur Þorsteinsson explained to me a near-hidden feature of GDAL,
> >> namely to reproject one image onto the coverage of another.
> >>
> >> Given two images:
> >> imageA.tiff
> >> imageB.tiff
> >>
> >> Then an empty image can be created from image A with e.g.
> >> $ gdal_translate -ot Float32 -scale 0 0 999 999 -a_nodata 999
> >> imageA.tiff domainA.tiff
> >>
> >> And then imageB can be warped onto the extent of this image simply with:
> >> $ gdalwarp imageB.tiff domainA.tiff
> >>
> >> domainA.tiff will then contain the data from imageB, exactly co-located
> >> with imageA.
> >>
> >> The problem is that this only works when imageA contains a geotransform,
> >> and not when it contains only GCPs.
> >>
> >>
> >> So my question is:
> >> Is there any workaround to warp data from one image onto another image
> >> which is geolocated by GCPs only?
> >>
> >>
> >>
> >> With the -to option of gdalwarp it is possible to pass some parameters
> >> to GDALCreateGenImgProjTransformer2(). In the documentation of this
> >> function I find the following option:
> >>
> >> "METHOD: may have a value which is one of GEOTRANSFORM, GCP_POLYNOMIAL,
> >> GCP_TPS, GEOLOC_ARRAY, RPC to force only one geolocation method to be
> >> considered on the source dataset."
> >> http://www.gdal.org/gdal__alg_8h.html#94cd172f78dbc41d6f407d662914f2e3
> >>
> >> But there is no corresponding option to force use of GCP_POLYNOMIAL for
> >> the *destination* dataset. I guess this is a bad sign?
> >>
> >>
> >> Thank you for any help!
> >> Knut-Frode
> >>
> >> ___
> >> 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
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/lis

Re: [gdal-dev] Motion: Authorize Islandwood Funding for Brian Case

[Brian Case]

hey people

Thanks for the support.
looking forwards to the sprint.

Brian



On Tue, 2012-01-03 at 10:01 -0800, Frank Warmerdam wrote:
> On Tue, Dec 13, 2011 at 11:03 PM, Frank Warmerdam  wrote:
> > Motion: The GDAL PSC authorizes funding up to US$525 to pay entrance fees
> > to the Islandwood Code Sprint for Brian Case.
> 
> Folks,
> 
> I declare this motion passed with support from Tamas, Even,
> Frank, Daniel and Howard.   If there is any other GDAL contributors
> interested in attending the sprint under similar arrangements let me
> know.  There are still openings available as I understand it.
> 
> Best regards,


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reading OGRStyle information using C++

[Brian Case]

Aneesh

i believe the only driver that supports layer andf dataset style tables
is the libkml driver

Brian


On Thu, 2012-01-05 at 18:06 +0530, Aneesh Muralidharan wrote:
> Chaithanya,
> 
> Ahhh that explains it ! Thanks a lot. By the way where do I find out
> these information (like DXF driver doesn't support style table), as in
> where is it documented ?
> 
> And can you suggest me some other vector format that OGR loads by
> default, which has style information ? I was using SHP till now, but
> then it doesn't have the style information at all right. Also it will
> be great if you can point me to some place where I can find some free
> samples as well.
> 
> On Thu, Jan 5, 2012 at 5:51 PM, Chaitanya kumar CH
>  wrote:
> Aneesh,
> 
> I don't know if the DXF format maintains a default style or a
> style table but OGR's DXF driver doesn't support layer's style
> table.
> 
> 
> On Thu, Jan 5, 2012 at 5:30 PM, Aneesh Muralidharan
>  wrote:
> Hi Chaithanya,
> 
> Thanks for the quick reply
> 
> About the style table, I did try to use the layer
> style table, but I'm getting an empty table :(
> 
> By the way I'm trying to read a simple DXF file. 
> 
> On Thu, Jan 5, 2012 at 4:57 PM, Chaitanya kumar CH
>  wrote:
> A layer's style table can be accessed using
> OGRLayer::GetStyleTable() [1].
> 
> [1]:
> http://www.gdal.org/ogr/classOGRLayer.html
> 
> 
> On Thu, Jan 5, 2012 at 4:55 PM, Chaitanya
> kumar CH  wrote:
> Aneesh,
> 
> A layer can have a style table that
> stores a set of styles that can be
> referred by individual features.
> Usually the style table has a default
> style.
> 
> Its usage is explained in the same
> page as the OGR Feature Style
> Specification.
> 
> On Thu, Jan 5, 2012 at 3:45 PM, Aneesh
> Muralidharan 
> wrote:
> 
> Hi,
> 
> I'm new to OGR/GDAL and I'm
> trying to read style
> information of vectors using
> the OGR C++ API. I followed
> the documentation available
> here
> 
> http://www.gdal.org/ogr/ogr_feature_style.html. I have managed to get the pen 
> information of the glyphs' in vector file successfully.
> 
> The problem is that, it is
> unclear that from where can I
> figure out the layer style
> specification. i.e the global
> style for the layer ( assuming
> each glyph's pen can be either
> one of its own or dependent on
> the layer ). The
> OGRFeatureDefn for the
> OGRLayer doesn't seem to have
> this information.
> 
> Also is there any detailed
> explanation of the API
> somewhere with some sample
> code snippets ? (for the
> feature-style api. For
> read/write I know there is
> 
> http://www.gdal.org/ogr/ogr_apitut.html)
> 
> Hoping for a quick response
> 
> Thanks and regards,
> Aneesh

Re: [gdal-dev] Writing Pixel Functions with VRT

[Brian Case]

Yves,

You need to be write a custom application to make use of


If you are looking for a command line utility solution you should use
gdal_calc.py


if your end goal is to serve this data via a wms you could try the
thredds server
http://www.unidata.ucar.edu/projects/THREDDS/tech/TDS.html 

http://atmos.telascience.org:8080/thredds/wms/ncom_fukushima_agg/Fukushima_best.ncd?LAYERS=sea_water_velocity&ELEVATION=0&TIME=2011-12-17T00%3A00%3A00.000Z&TRANSPARENT=true&STYLES=vector%2Frainbow&CRS=EPSG%3A4326&COLORSCALERANGE=0%2C1&NUMCOLORBANDS=64&LOGSCALE=false&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&EXCEPTIONS=XML&FORMAT=image%2Fpng&BBOX=135.74485290527,32.501498222351,147.25334655761,41.49250245&WIDTH=768&HEIGHT=600

On Wed, 2011-12-21 at 20:41 +0100, Yves Jacolin (free) wrote:
> Hello,
> 
> I have some question about writing pixel functions with vrt files. I have a 
> netcdf file with two subset named U and V.
> 
> How can I process sqrt(U^2 + V^2) using this feature with vrt file?
> 
> * do I need to create a C file and build GADL with it?
> * do I need to create a C file and locate it close to vrt file?
> 
> Thanks,
> 
> Y.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] re-gridding to a coarser grid

[Brian Case]

Andreas

I think thats referring to my suggestion of GMT to do part of the work






On Thu, 2011-12-15 at 14:00 +0100, Andreas H. wrote:
> Joaquim,
> 
> > nearneighbor is not really a good thing to use. Grid it with surface.
> 
> What do you mean by "grid it with surface"? In my GDAL (1.8.1), I only
> have the following choices:
> 
>Available resampling methods:
>near (default), bilinear, cubic, cubicspline, lanczos.
> 
> thanks for your insight,
> 
> Andreas.
> 
> >
> > Joaquim
> >
> > Sent from my iPadiola
> >
> > On 14/12/2011, at 18:32, "Andreas H."  wrote:
> >
> >> Travis,
> >>
> >> yes, thanks, I had already found that in the documentation. I'm just
> >> wondering what e.g. 'bilinear' means when I go from a fine to a coarse
> >> grid? If GDAL works in terms of "nodes", then I would assume 'bilinear'
> >> means interpolation, which in turn would be a very different result from
> >> working in terms of "cells" and then taking e.g. the average of all
> >> "old" cells in the "new" grid.
> >>
> >> I hope you see my problem / question.
> >>
> >> Thanks for you insight,
> >> Andreas.
> >>
> >> Am 14.12.2011 16:35, schrieb Travis Kirstine:
> >>> Andreas,
> >>>
> >>> Yes gdalwarp support various resampling methods
> >>>
> >>> To use different resampling methods use the -r flag followed by the
> >>> method
> >>>
> >>> eg
> >>>
> >>> gdalwarp -r near ..
> >>> gdalwarp -r bilinear .
> >>>
> >>> etc...
> >>>
> >>>
> >>>
> >>>
> >>> On 14 December 2011 08:26, Andreas H.  wrote:
>  Travis,
> 
>  thanks for your answer!
> 
>  Regarding the resampling methods: Do they all just interpolate the
>  data? I
>  mean, when downsampling, usually I would use mean() or something
>  similar
>  to fill the new (coarser) grid cells. Doas gdalwarp actually do this
>  and
>  I'm not able to understand the documentation, or is it different?
> 
>  Thanks again!
>  Andreas.
> 
> 
> > Andreas,
> >
> > gdalwarp can be used to resample images using the -tr flag or -ts
> > flag.
> >
> > For example resample 1m image to 10m using cubic resampling and
> > "target resolution'
> >
> > gdalwarp -r cubic -tr 10 10 input_1m.tif output_10m.tif
> >
> > You may have an issue determining the output resolution as I believe
> > the resolution will be in decimal degrees rather than arc-seconds.
> >
> > Regards
> >
> > On 13 December 2011 14:52, Andreas H.  wrote:
> >> Hi,
> >>
> >> let's say I have a GeoTIFF file with a global grid in a 30
> >> arc-second
> >> resolution. Which would be the appropriate GDAL command to spatially
> >> down-sample this file to say 0.125°?
> >>
> >> Thanks for your insight,
> >> Andreas.
> >> ___
> >> 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
> >>
> >> ___
> >> 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


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Which is the way to handle altitude layers within one file?

[Brian Case]

Andreas,

you can use gdal to read grib, hdf, and netcdf files built this way.
take a look at the format pages for those formats.
http://www.gdal.org/formats_list.html

note: gdal requires all the "bands" or subdatasets to be the same size

if you find yourself needing to put multiple files together use
gdalbuildvrt -separate then gdal_translate

On Wed, 2011-12-14 at 13:37 +0100, Andreas H. wrote:
> 
> the subject basically says it. What would be the way to go if I want
> to
> store multiple altitude layers within a file? The grid contains 64
> latitudes, 128 longitudes, and 60 altitude levels. How do I need to
> create
> the file in order to be able to use tools like gdalwarp to modify the
> data/grid? 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Newbie question about gdal_grid for 3d data

[Brian Case]

Andreas,

There are no vector drivers for hdf and nc. take a look here
http://www.gdal.org/ogr/ogr_formats.html

As an alternative to gdal_grid you can use GMT's blockmean, blockmedian,
or blockmode. then use GMT's surface http://www.soest.hawaii.edu/gmt5/


On Wed, 2011-12-14 at 15:03 +0100, Andreas H. wrote:
> Hi again,
> 
> another question which shows I'm just starting to see if GDAL can actually
> make my life easier :)
> 
> I'm working with atmospheric trace gas profiles, so one data"point"
> consists of latitude, longitude (point or polygon, whichever is easier)
> and many vertical layers, say 60 floating point values. I ultimately want
> to create a global 1°x1° grid where all data"points" are put into and
> averaged.
> 
> While I can see that gdal_grid will probably do the job, I cannot see a)
> how exactly and, more importantly, b) in which format I should prepare the
> input files. I'm preparing the data with some home-grown Python scripts,
> and I'm quite familiar with HDF and NC formats ...
> 
> Thanks for your insight!
> Andreas.
> 
> ___
> 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] how to combine overlapping rasters?

[Brian Case]

Etienne

you can gdal_rasterise the polys into a alpha band, then add your alpha
band to your image in a vrt.

Brian


On Tue, 2011-12-06 at 19:59 -0200, Etienne Tourigny wrote:
> 
> A related question: How can I effectively mask (mark as nodata) raster
> pixels inside a polygon?  For example, I would like to set the pixels
> of the South American map to nodata inside the political boundaries of
> Brazil, from a shapefile. 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] how to combine overlapping rasters?

[Brian Case]

Etienne

if they overlap your limited to one of 2 options to mosaic

gdalwarp or mapserver

to get what ones are on top with gdalwarp i would imagine you would just
need to play with the order on the command line.

Brian


On Tue, 2011-12-06 at 19:59 -0200, Etienne Tourigny wrote:
> Hi all.
> 
> I am trying to combine 2 overlapping rasters into a single raster.
> Specifically, I have a raster for land cover types covering South
> America and another one for Brazil.
> 
> I want the values from the Brazil map to overlap the values from the
> South American map.
> To complicate things further, the Brazil map has some holes (no data
> inside the map), which I would like to be set from the South America
> map.
> 
> Can this be done with gdal utilities or Gis, or do I need to write a
> python script?
> I thought of doing some tricks to the Brazil map and create a band
> from which I could set nodata values in South America map, and
> then using gdalwarp (combining the modified South America map and the
> Brazil map), does that make sense?
> 
> Posted sample jpg+jpw files at
> http://www.openclimgeo.org/pub/maps/
> 
> A related question: How can I effectively mask (mark as nodata) raster
> pixels inside a polygon?  For example, I would like to set the pixels
> of the South American map to nodata inside the political boundaries of
> Brazil, from a shapefile.
> This is the *reverse* of clipping a raster based on a a polygon (like
> gdalwarp -cutline -crop_to_cutline  does)
> 
> Thanks,
> Etienne
> ___
> 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] Editing KML files using ogr_csharp.dll

[Brian Case]

Chris,

Have you tried the libkml driver?

http://www.gdal.org/ogr/drv_libkml.html


Brian


On Mon, 2011-12-05 at 14:50 +, Pouliot, Christopher (DNR) wrote:
> Hello All,
> 
>  
> 
> I have a C# application that uses OGR_CSHARP.DLL to read/write KML
> files.  I’m able to read from KML files fine.  I’m able to create a
> new KML file and write to it fine.  I am unable, however, to open a
> KML file to edit.  I’d like to be able to append a new layer (folder)
> onto an existing KML file.  I’ve tried both of the following code
> snippets:
> 
>  
> 
> //This returns NULL
> 
> OSGeo.OGR.Driver drv = Ogr.GetDriverByName(“KML”);
> 
> DataSource ds = drv.Open(“c:\\temp\\mykml.kml”, 1);
> 
>  
> 
>  
> 
> //This returns NULL
> 
> DataSource ds = Ogr.Open(“c:\\temp\\mykml.kml”, 1);
> 
>  
> 
>  
> 
> I’m able to use this code to edit File Geodatabases and Shapefiles but
> not KML.
> 
>  
> 
>  
> 
>  
> 
> Also, when creating a KML file from scratch is there a way to map the
> Name and Description fields to my existing fields so that the Name and
> Description appear in Google Earth?
> 
>  
> 
>  
> 
> Thanks,
> 
>
> 
> Chris
> 
>  
> 
> Chris Pouliot
> GIS Application Developer
> Minnesota Department of Natural Resources
> christopher.poul...@state.mn.us
> (651) 259-5491
> 
>  
> 
> 
> ___
> 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] Re: Gdal_translate, question from an amateur.

[Brian Case]

Joolek,


gdal_translate cannot look at 3 bands at a time, -scale 0 255 1 254 will
scale each band separately, therefore 0 255 0 would become 1 254 1.

At one point I thought perhaps you were trying to get rid of a border,
but now I don't think thats the issue.

Brian



On Sun, 2011-10-23 at 11:53 -0700, joolek wrote:
> Hmm...  So what the following does : 
> gdal_translate -scale 0 254 0 255 
> 
> 
> 
> Thank you
> J
> 
> 
> 23 Oct 2011, at 19:20, "Jay L. [via OSGeo.org]" <[hidden email]>
> wrote:
> 
> 
> 
> > I do not believe that a GDAL command line tool to perform that
> > function exists.  The task is achievable using GDAL and Numpy masked
> > arrays in python.
> > 
> > 
> > Perhaps someone else knows of a GDAL tool to perform this
> > functionality though.
> > 
> > 
> > J
> > 
> > On Sun, Oct 23, 2011 at 12:59 PM, joolek <[hidden email]> wrote:
> > Hi
> > I need to convert all the 255 255 255 into 254 254 254. Is
> > this possible?
> > PS. Do appologize for lack of my language. 
> > 
> > 
> > Thanks
> > J
> > 
> > On 23 Oct 2011, at 15:26, "Jay L. [via OSGeo.org]" <[hidden
> > email]> wrote:
> > 
> > 
> > 
> > > Or are you trying to convert only some of the pixels to
> > > white?
> > > 
> > > 
> > > On Sun, Oct 23, 2011 at 10:02 AM, Brian Case <[hidden
> > > email]> wrote:
> > > 
> > > joolek,
> > > 
> > > I noticed you used the word "strip". Are you
> > > trying to remove portions
> > > of the image that are all black or white?
> > > 
> > > 
> > > 
> > > 
> > > On Sun, 2011-10-23 at 03:01 -0700, joolek wrote:
> > > > Basically - I have an imagery with RGB 0-255,
> > > but I would like to strip it to
> > > > 1-254.
> > > > So i want to get rid off two extremes (0 and
> > > 255) - is this possible?
> > > > Thank you
> > > > J
> > > >
> > > > --
> > > > View this message in context:
> > > 
> > http://osgeo-org.1803224.n2.nabble.com/Gdal-translate-question-from-an-amateur-tp6921127p6921730.html
> > > > Sent from the GDAL - Dev mailing list archive at
> > > Nabble.com.
> > > > ___
> > > > gdal-dev mailing list
> > > 
> > > > [hidden email]
> > > 
> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > > 
> > > 
> > > ___
> > > gdal-dev mailing list
> > > 
> > > [hidden email]
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > > 
> > > 
> > > 
> > > ___ 
> > > gdal-dev mailing list 
> > > [hidden email] 
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev 
> > > 
> > > 
> > > __
> > > If you reply to this email, your message will be added to
> > > the discussion below:
> > > 
> > http://osgeo-org.1803224.n2.nabble.com/Gdal-translate-question-from-an-amateur-tp6921127p6922091.html
> >  
> > > To unsubscribe from Gdal_translate, question from an
> > > amateur., click here. 
> > 
> > 
> > 
> > View this message in context: Re: Gdal_translate, question
> > from an amateur.
> > 
> > 
> > Sent from the GDAL - Dev mailing list archive at Nabble.com.
> >

Re: [gdal-dev] Re: Gdal_translate, question from an amateur.

[Brian Case]

joolek,

I noticed you used the word "strip". Are you trying to remove portions
of the image that are all black or white?


On Sun, 2011-10-23 at 03:01 -0700, joolek wrote:
> Basically - I have an imagery with RGB 0-255, but I would like to strip it to
> 1-254.
> So i want to get rid off two extremes (0 and 255) - is this possible?
> Thank you
> J
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/Gdal-translate-question-from-an-amateur-tp6921127p6921730.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] gdal_fillnodata.py filling interior holes in RGB images

[Brian Case]

Travis,

you have to run gdal_fillnodata on each band, then splice the outputs
back together.

if the nodata areas on the inside do not connect to the outside area you
could create an alpha band

### -color 0,0,0 assumes odata value of 0
nearblack -dstalpha -near 0 -nb 0 -setalpha -color 0,0,0 \
  myfile.tif -o mytmpfile.tif
gdal_translate -b 4 -of VRT mytmpfile.tif a.vrt

gdal_fillnodata.py -md 1 -b 1 myfile.tif r_filled.tif
gdal_fillnodata.py -md 1 -b 2 myfile.tif g_filled.tif
gdal_fillnodata.py -md 1 -b 3 myfile.tif b_filled.tif

gdalbuildvrt -resolution highest -separate filled.vrt \
 r_filled.tif g_filled.tif b_filled.tif a.vrt

if you want an rgba image use
gdal_translate filled.vrt filled.tif

otherwise for rgb with nodata use

### INIT_DEST=0 assumes nodata value of 0
gdalwarp -wo INIT_DEST=0 filled.vrt filled.tif

if your interior nodata areas connect to the outside nodata areas. I
don't know howto deal with that other than to just live with the extra
pixel around the outside of the valid data.

Brian


On Wed, 2011-10-12 at 08:46 -0400, Travis Kirstine wrote:
> I have some RGB orthophotos that have interior holes, typically 1
> pixel.  Most of the images have "valid" nodata around the edges.  I
> would like to fill the interior holes while maintaining the valid
> nodata around the edges.  I have tried gdal_fillnodata.py but cannot
> get the utility to return a multiband image and / or interpolate only
> interior holes.
> 
> Any help would be much appreciated
> ___
> 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] Re: KML's extendedData not visible

[Brian Case]

joss,

you should try the libkml driver.
http://www.gdal.org/ogr/drv_libkml.html

ogr2ogr -f CSV test.csv test.kml

cat test.csv
Name,description,timestamp,begin,end,altitudeMode,tessellate,extrude,visibility,holeNumber,holeYardage,holePar
Club house,,-1,-1,-1,1,234,4
By the lake,,-1,-1,-1,5,523,5


Brian



On Tue, 2011-10-11 at 03:21 -0700, jarmstrong wrote:
> I have a similar question regarding KML and OGR.
> When trying to import the example extended data as given at 
> http://code.google.com/apis/kml/documentation/extendeddata.html
> http://code.google.com/apis/kml/documentation/extendeddata.html 
> The extended data is not present in the created tables in the PG database
> when imported from KML file using ogr2ogr command.
> The database is created according to the template_postgis and the geometry
> data is imported correctly.
> Please let me know if this extended data should be present in the database
> tables and if so what is required to do this.
> 
> Thanks
> J Armstrong 
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/gdal-dev-KML-s-extendedData-not-visible-tp5454623p6880389.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] Resquest for comments (RFC 36)

[Brian Case]

Ivan

Makes me wonder what kind of performance gain you could see with
mapserver on a layer with a large number of images to open.

Seems to me that a tileindex would be a good application of this.

Brian




On Mon, 2011-10-03 at 19:02 -0500, Ivan Lucena wrote:
> Hi All,
> 
> RFC 36: http://trac.osgeo.org/gdal/wiki/rfc36_open_by_drivername
> 
> The goal of RFC 36 is to save processing time by telling GDALOpen what driver 
> to use, avoiding the driver-probing mechanism (Where all drivers are asked to 
> checked if they recognize the file).
> 
> It works by adding the driver name before the file-name as in 
> GDALOpen("hfa:example_file.img").
> 
> *It is optional*. It does not invalidate the current simple filename entry 
> that most of the drivers use nor the more complex "filename" string formats 
> used by a few drivers (with things like server-name, port-number, table-name).
> 
> It is intended to speed up applications or scripts that need to process a 
> large number of datasets when it already knows what driver to use.
> 
> Command line use should not be affect considerably in terms of speed but it 
> adds the option to avoid the wrong driver from taking precedence from the 
> intended one (#3043), ex.:
> 
> $ gdalinfo ntif:/autotest/gdrivers/data/rgb.ntf"
> 
> If you want to try it, a patch that implements this proposed change is 
> available on ticket 3043 http://trac.osgeo.org/gdal/ticket/3043
> 
> Please take a look and send us your comments.
> 
> Regards,
> 
> Ivan
> ___
> 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] Re: Can't get gdalwarp to create a raster in Mercator-2SP projection?

[Brian Case]

Patrick

from http://remotesensing.org/geotiff/proj_list/mercator_2sp.html

"The difference between 1SP and 2SP formulations is that the initial
parameters are different: in 1SP you start from the longitude of natural
origin and the scale factor, while in 2SP you start from the longitude
of natural origin and the latitude of one of the standard parallels (the
other is symmetrical in relation to the equator). So, the formulas of
2SP are just those for 1SP after calculating the scale factor from the
absolute value of the latitude of the standard parallels and the "e"
parameter of the datum."


I noticed your scale factor is 1 so isn't that the same thing?

"The Mercator projection is a special case of the Lambert Conic
Conformal projection with the equator as the single standard parallel.
All other parallels of latitude are straight lines and the meridians are
also straight lines at right angles to the equator, equally spaced. It
is little used for land mapping purposes but is in universal use for
navigation charts and is the basis for the transverse and oblique forms
of the Mercator. As well as being conformal, it has the particular
property that straight lines drawn on it are lines of constant bearing.
Thus navigators may derive their course from the angle the straight
course line makes with the meridians.

In the few cases in which the Mercator projection is used for
terrestrial applications or land mapping, such as in Indonesia prior to
the introduction of the Universal Transverse Mercator, a scale factor
may be applied to the projection. This has the same effect as choosing
two standard parallels on which the true scale is maintained at equal
north and south latitudes either side of the equator."

from http://remotesensing.org/geotiff/proj_list/mercator_1sp.html

"I believe the formula (EPSG) notes are exactly the same for Mercator
(1SP) and Mercator (2SP). There is only one projection in GeoTIFF for
straight Mercator."



hope this helps

Brian



On Thu, 2011-09-29 at 11:42 +1000, Patrick Sunter wrote:
> Oops, sorry sent message accidentally without last bit of text output,
> pls see below ...
> 
> On Thu, Sep 29, 2011 at 11:38 AM, Patrick Sunter  wrote:
> > Hi,
> >
> > As part of testing GDAL's NetCDF drivers projections, I've been trying
> > to gdalwarp a Geotiff file from a UTM projection to Mercator-2SP
> > (http://geotiff.maptools.org/proj_list/mercator_2sp.html).
> >
> > Thinking I should file this as a ticket? But thought I'd post here first.
> >
> > I've tried 2 approaches to specifying the target SRS as Mercator-2SP,
> > and in both cases the resulting files comes out as Mercator-1SP:
> >
> > 1) Specifying using Proj4 (the 'lat_ts' paramater specifies a std
> > parallel and differentiates from Mercator-1SP
> > gdalwarp -t_srs '+proj=merc +lat_ts=-45 +lon_0=145 +x_0=0 +y_0=0
> > +ellps=WGS84 +datum=WGS84 +units=m +no_defs' melb-small.tif
> > savedResults/Melb_USGS/refactored_gdal/melb-small_M-2SP.tif
> >
> PROJCS["unnamed",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Mercator_1SP"],
> PARAMETER["central_meridian",145],
> PARAMETER["scale_factor",1],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]]]
> 
> 
> >
> > 2) Specifying the full requested OGC WKT:
> > gdalwarp -t_srs 'PROJCS["unnamed", GEOGCS["WGS 84", DATUM["WGS_1984",
> > SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]],
> > AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0],
> > UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]],
> > PROJECTION["Mercator_2SP"], PARAMETER["central_meridian",146],
> > PARAMETER["standard_parallel_1",-45],
> > PARAMETER["latitude_of_origin",0], PARAMETER["false_easting",0],
> > PARAMETER["false_northing",0], UNIT["metre",1,
> > AUTHORITY["EPSG","9001"]]]' melb-small.tif
> > savedResults/Melb_USGS/refactored_gdal/melb-small_M-2SP.tif
> >
> > Resulting gdalinfo projection section:
> >
> PROJCS["unnamed",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Mercator_1SP"],
> PARAMETER["central_meridian",146],
> PARAMETER["scale_factor",1],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]]]
> 
> So it seems GDAL is falsely converting both requested translates to
> Mercator-1SP?
> 
> thanks, Patrick.
> ___
> gdal-dev maili

Re: [gdal-dev] Can't find a way of properly warping into a buffer

[Brian Case]

Daniele

a simple solution could be warp your image to an in memory raster
http://www.gdal.org/frmt_mem.html

Brian


On Mon, 2011-09-12 at 19:24 +0200, Daniele Tessaro wrote:
> Hello everybody,
> I'm really sorry if this post will be very long, but I swear I've
> spent a lot of time (days!)
> in trying to exactly understand this, also reading the sourcecode, but
> I'm a little bit stuck!
> 
> In my application I need to read data from a srtm90 tif file
> of extension 5 lat * 5 lon put in a raster of 6000x6000
> pixels, 2 bytes per pixel. This data will then be used as a heightmap
> texture for terrain rendering.
> 
> I have no problems in reading data using RasterIO function, I can also
> keep 72mb of raster data in system memory performing only
> one IO operation (so that I don't have to mess with async operations) but:
> 
> 1. I can't keep a 72MB texture in video memory (but the whole terrain
> extension should be
> rendered if the viewer is high enough), so I have to read a resampled
> lower resolution versions of the full terrain.
> (Actually more than one depending on the height of the viewpoint),
> and a full resolution version of a small piece of terrain that must be
> updated fast(only for small rectangular chunks)
> almost every time the user moves on the terrain.
> 
> 2. I'll map my terrain on a plane. This means that I need to transform
> data to some
> projected coordinate system. Suppose UTM, with the proper zone (I don't mind 
> the
> deformations at the borders...).
> 
> Calling RasterIO in the proper way would solve problem 1, as it is
> exposing exactly the interface I need.
> The big issue is that it would be performing IO operations all the
> time, while I want to perform
> 1 single IO operation and then resample on that data.
> So first question: Is there a way of telling RasterIO to completely
> cache data and never access disk?
> 
> RasterIO would not solve problem 2, as I would get unprojected data as result,
> unless I get unprojected data and then I execute the projection.
> I don't think it's the correct approach, also because RasterIO only
> allows me only to read unprojected rectangular data,
> while I want to read projected rectangular data that would become
> trapezoidal if unprojected.
> 
> 
> I've also spent time with the Warping functions, but I can't figure
> out how to perform what I need.
> For what I've seen I should initialize a GDALWarpOperation with
> GDALWarpOptions so that:
> - hSrcDS is my source dataset
> - hDstDS is NULL, cause I want to warp to a buffer
> - pfnTransformer must be set so that it can map from pixel / line
> unprojected to pixel / line projected. I can use
>  GDALCreateGenImgProjTransformer but I have no destination dataset so
> I can't figure out how to set it up.
> 
> Then I can't exactly understand the WarpRegionToBuffer API.
> Suppose I need to sample in an output buffer of size W x H a region
> that in the projected coordinate system (so after the transform)
> is of size A x B. How should I set nDstXSize and nDstYSize? I would
> expect being able to specify both those couples of params because
> I should be able to get any region and to put it in any buffer
> performing the appropriate resampling. But that function is a little
> bit confusing
> me.
> 
> can anyone help me?:-)
> 
> thanks
> 
> ___
> 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] Re: discussion on improvements to the NetCDF driver and CF-1 convention

[Brian Case]

Etienne

I can read it with ogr. I am wondering if others have interest too

http://svn.osgeo.org/gdal/sandbox/winkey/ogr-netcdf/ogrsf_frmts/netcdf/


Brian

On Fri, 2011-09-02 at 10:57 -0300, Etienne Tourigny wrote:
> There has been recent work on incorporating netcdf support for point
> and trajectory data with Talend, maybe that can help?
> 
> 
> http://www.neogeo-online.net/blog/archives/1350/
> http://talendforge.org/svn/sdi/trunk/org.talend.sdi.designer.components.sandbox/components/sNetCDFInput/
> 
> 
> Etienne
> 
> On Tue, Aug 30, 2011 at 10:18 AM, Etienne Tourigny
>  wrote:
> Brian,
> 
> I am not familiar with madis data.  I assume that it is
> point-data for meteorological stations?
> 
> If you like, please post your ideas and a short description in
> a new topic in the wiki entry at
> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements .
> 
> Etienne
> 
> 
>     
> 
> - Original Message -
> From: Brian Case 
> To: Etienne Tourigny 
> Cc: "gdal-dev@lists.osgeo.org" 
> Sent: Sunday, August 28, 2011 7:54:13 PM
> Subject: Re: [gdal-dev] Re: discussion on improvements to the
> NetCDF driver and CF-1 convention
> 
> any thoughts on a ogr netcdf driver? I have a simple one for
> madis data
> that needs work in my sandbox
> 
> Brian
> 
> 
> 
> On Sun, 2011-08-28 at 14:56 -0700, Etienne Tourigny wrote:
> > I have created a new wiki page at
> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements ,
> following Even's suggestion (Thanks Even).
> >
> > The following topics have been included:
> >
> >
> > Topics:
> >
> > 1 - UNIDATA NetCDF Conventions
> >
> > 2 - Metadata
> > 3 - Datum issues
> > 4 - Dimension issues
> > 5 - Compatibility with other software
> > 6 - Test files
> > 7 - Contribution
> > Discussion
> >
> > I encourage interested parties in participating in this
> discussion in the wiki and in the mailing list.
> >
> >
> > In particular, it would be useful to collect information on
> contributors and obtain test files with issues and the
> expected outcome.
> >
> > regards, Etienne
> >
> >
> > - Original Message -
> > From: Even Rouault 
> > To: gdal-dev@lists.osgeo.org; Etienne Tourigny
> 
> > Cc:
> > Sent: Friday, August 26, 2011 4:20:06 PM
> > Subject: Re: [gdal-dev] Re: discussion on improvements to
> the NetCDF driver and CF-1 convention
> >
> > Le vendredi 26 août 2011 17:15:47, Etienne Tourigny a
> écrit :
> >
> > My thoughts, just from a process point of view, not being
> myself deeply
> > involved in the NetCDF format :
> >
> > * A wiki page (I'd suggest either a new page -
> > http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements - or at
> least a clearly
> > identified section in the current page, to avoid confusion
> for outsiders about
> > what is currently implemented and what is not) can be a
> convenient way of
> > structuring and editing the content by anyone with a osgeo
> id. But discussions
> > on the mailing list are also OK, at least to notify new
> content has been added
> > (provided that it doesn't cause flooding on the mailing
> list ;-))
> >
> > * A http://download.osgeo.org/gdal/data/netcdf directory
> would be the right
> > place to store NetCDF sample files, provided they are free
> under the terms of
> > http://download.osgeo.org/gdal/data/COPYING . As write
> access to it is
> > restricted to people with appropriate rights, having those
> rights, I can help
> > uploading files over there. Having small (typically < or ~
> 10 KB ) sample files
> > is also good so they can be directly included in SVN under
> the
> > autotest/gdrivers/data directory and thus easily used by
> regression tests.
> >
&

Re: [gdal-dev] RE: GDALWARP Chunk Problem (Tiling Effect)

[Brian Case]

Chris

have you tryed other kernels? cubic, etc..

read this too
http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08

perhaps someone else may have other ideas.

Brian


On Wed, 2011-08-31 at 23:58 -0700, heng.feng wrote:
> Tried the "-et 0.0" option with no luck :(
> 
> Any other idea about how to get rid of this tiling effect?
> 
> Thanks,
> Chris
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/GDALWARP-Chunk-Problem-Tiling-Effect-tp6749055p6749118.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] GDALWARP Chunk Problem (Tiling Effect)

[Brian Case]

Chris,

Try passing gdalwarp -et 0.0

I am also suspicious of doing compression with the warp. you might want
to do that as a second step

Brian

On Wed, 2011-08-31 at 23:16 -0700, heng.feng wrote:
> Hi,
> 
> I have used the (OSGeo4W) GDALWARP command to warp some height data image
> files (NTv2 transformation). When displaying one warped height data in our
> own application, there appear to be visible tiles on the image and some
> misalignments exist between those square tiles (chunks). 
> 
> After warping, I did make some conversion on the height data from the
> original format (ERDAS Imagine) to another format, which can be accepted by
> our own application. However, I think this tiling effect is not caused by
> the format conversion, but most likely by something in the GDALWARP command.
> The reason for saying this is that I have done the same format conversion on
> the original height data without warping and there are no tiling effects at
> all for the converted height data when shown in our application. As
> attached, please see the two screenshots for the same area of the height
> data being displayed in our application. One is with warping while the other
> is without warping.
> 
> I seem to remember that the GDALWAP command does the chunk warping. Could
> this be the reason why? 
> 
> The GDALWARP command I have been using is something like this:
> 
> gdalwarp --config GDAL_CACHEMAX 250 -wm 250 -co COMPRESS=LZW -co BIGTIFF=YES
> -co TILED=YES -multi -overwrite -s_srs "+proj=tmerc +lat_0=0 +lon_0=12
> +k=1.00 +x_0=450 +y_0=0 +ellps=bessel +datum=potsdam
> +nadgrids=c:\height \BETA2007.gsb,null +units=m +wktext" -t_srs "+proj=utm
> +datum=WGS84 +zone=32" "c:\height\test.img" "c:\height\test.tif"
> 
> I have tried the GDALWARP command on the same height data by taking away all
> the above command options and got the same tiling effect. Also I have
> managed to open the warped height map data (tif format) in another GIS
> application and could see the tiling effects as well although the effect is
> not as visible as seen in our own application. I think this is because the
> color interpretation type is gray in that warped height tif file. 
> 
> The other thing worth mentioning is: with the same warping and conversion
> process, lower resolution height data (or much smaller height data) do not
> seem to have such visible tiling effects.
> 
> Anyway, does anyone here have any clue about this? And is there any way to
> get rid of the tiling effects in the warped height data?
> 
> Many thanks & BR,
> Chris Feng
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/GDALWARP-Chunk-Problem-Tiling-Effect-tp6749055p6749055.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] Re: discussion on improvements to the NetCDF driver and CF-1 convention

[Brian Case]

any thoughts on a ogr netcdf driver? I have a simple one for madis data
that needs work in my sandbox

Brian



On Sun, 2011-08-28 at 14:56 -0700, Etienne Tourigny wrote:
> I have created a new wiki page at 
> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements , following Even's 
> suggestion (Thanks Even).
> 
> The following topics have been included:
> 
> 
> Topics:
> 
> 1 - UNIDATA NetCDF Conventions
> 
> 2 - Metadata
> 3 - Datum issues
> 4 - Dimension issues
> 5 - Compatibility with other software
> 6 - Test files
> 7 - Contribution
> Discussion
> 
> I encourage interested parties in participating in this discussion in the 
> wiki and in the mailing list. 
> 
> 
> In particular, it would be useful to collect information on contributors and 
> obtain test files with issues and the expected outcome. 
> 
> regards, Etienne
> 
> 
> - Original Message -
> From: Even Rouault 
> To: gdal-dev@lists.osgeo.org; Etienne Tourigny 
> Cc: 
> Sent: Friday, August 26, 2011 4:20:06 PM
> Subject: Re: [gdal-dev] Re: discussion on improvements to the NetCDF driver 
> and CF-1 convention
> 
> Le vendredi 26 août 2011 17:15:47, Etienne Tourigny a écrit :
> 
> My thoughts, just from a process point of view, not being myself deeply 
> involved in the NetCDF format :
> 
> * A wiki page (I'd suggest either a new page - 
> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements - or at least a clearly 
> identified section in the current page, to avoid confusion for outsiders 
> about 
> what is currently implemented and what is not) can be a convenient way of 
> structuring and editing the content by anyone with a osgeo id. But 
> discussions 
> on the mailing list are also OK, at least to notify new content has been 
> added 
> (provided that it doesn't cause flooding on the mailing list ;-))
> 
> * A http://download.osgeo.org/gdal/data/netcdf directory would be the right 
> place to store NetCDF sample files, provided they are free under the terms of 
> http://download.osgeo.org/gdal/data/COPYING . As write access to it is 
> restricted to people with appropriate rights, having those rights, I can help 
> uploading files over there. Having small (typically < or ~ 10 KB ) sample 
> files 
> is also good so they can be directly included in SVN under the 
> autotest/gdrivers/data directory and thus easily used by regression tests.
> 
> * Tickets can be used to track the implementation of specific items and 
> bugfixes. But I've found they are not generally suitable for brainstorming 
> when 
> the discussion is lasting, as you cannot edit already posted content. Wiki is 
> clearly better for this.
> 
> * Looking at past history, I see we haven't yet used the RFC formalism for 
> work specific to one driver, while it doesn't require changes or extensions 
> to 
> the GDAL API. But it wouldn't hurt to create one if the need arises. Anyway, 
> a 
> point that might require care and some consensus among the interested parties 
> is about how backward compatibility issues, in particular with respect to 
> files 
> produced by older GDAL versions, are adressed. 
> http://trac.osgeo.org/gdal/wiki/rfc1_pmc details when a vote is required.
> 
> Best regards,
> 
> Even
> 
> > Hi all,
> > 
> > Since a few people have shown an interest in helping out, I would suggest
> > to set up space where we can post ideas, goals and test files.  This could
> > take the form of one of the following:
> > 
> > - a new wiki entry in trac, or the existing one at
> > http://trac.osgeo.org/gdal/wiki/NetCDF - a file repository at
> > http://download.osgeo.org/gdal/data/netcdf as suggested some time ago by
> > warmerdam
> > 
> > and/or
> > 
> > - a new ticket in trac (which allows to post files)
> > 
> > What are you thoughts about this?  Would it make sense to eventually
> > prepare an RFC?
> > 
> > 
> > 
> > I would suggest that each group identify the problems with the current
> > driver in terms of importing and exporting, post the files that they would
> > like to be supported, which other software they use with the netcdf files,
> > and their proposed contribution (code, test, ideas, etc.).
> > 
> > Those that cannot participate in code development can help out in testing
> > and discussion. Personally, I can write and test code, given example files
> > and expected outcome. 
> > 
> > 
> > Now to your specific comments, Knut-Frode:
> > 
> > 1) Yes CF-1.5 should be the goal, although I'm not sure we need to support
> > upgrading/downgrading.
> > 
> > 5) The WGS84 issue needs further research. Weather and ocean data are in
> > lat/lon, but what is the sphere radius assumed by the various data
> > providers and  the models which output/import netcdf files? I agree that a
> > small error does not make a difference with low-resolution dataset, but
> > I'd like to be sure in any case. We also need a means to translate the
> > CF-1.x datum information into EPSG/Proj.4 values.
> > 
> > 
> > 7) There is some support of a z-axis right now, in fact they driver 

Re: [gdal-dev] pruge images

[Brian Case]

Jan

you can skip that step and cut it up directly but it will take quite a
bit longer. the wms driver will download the entire area each time you
run gdal_translate -scrwin n n n n mywms.xml myouttile.tif

also if your running into wms performance issues have you built
overviews on your images? http://www.gdal.org/gdaladdo.html

Brian




On Fri, 2011-08-26 at 15:53 +0200, Jan Tappenbeck wrote:
> 
>   Am 26.08.2011 15:48, schrieb Brian Case:
> > Jan
> >
> > if you already have a wms setup with your data you could use the wms
> > driver to read it. gdal_translate to a bigtiff.
> hi !
> 
> thanks for response - but merge the image first into a large image will 
> be kill the maschine ! win7 64 bit - 4 gb workspace.
> 
> 1500 files with total 1 gb !
> 
> regards Jan :-)
> 
> 
> > then cut it up into
> > tiles with gdal_translate -srcwin
> >
> > Brian
> >
> >
> > On Fri, 2011-08-26 at 15:17 +0200, Jan Tappenbeck wrote:
> >>hi!
> >>
> >> i have following problem. openstreetmap could be download images by
> >> aerowest for drawing elementes. the download had to taken manuell and so
> >> it is not possible to create leaf cut off images.
> >>
> >> know i want to clean my gallery in hope to get more performance in my
> >> local wms-service.
> >>
> >> did anybody had a idea to merge all the images (georef!) distributed
> >> over the hole town and cut then regualar without overlap?!?!?
> >>
> >> regards Jan :-)
> >>
> >> ___
> >> 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] pruge images

[Brian Case]

Jan

if you already have a wms setup with your data you could use the wms
driver to read it. gdal_translate to a bigtiff. then cut it up into
tiles with gdal_translate -srcwin

Brian


On Fri, 2011-08-26 at 15:17 +0200, Jan Tappenbeck wrote:
> 
>   hi!
> 
> i have following problem. openstreetmap could be download images by 
> aerowest for drawing elementes. the download had to taken manuell and so 
> it is not possible to create leaf cut off images.
> 
> know i want to clean my gallery in hope to get more performance in my 
> local wms-service.
> 
> did anybody had a idea to merge all the images (georef!) distributed 
> over the hole town and cut then regualar without overlap?!?!?
> 
> regards Jan :-)
> 
> ___
> 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] Modis L1B SWATH: georef problem hdf to geotiff

[Brian Case]

Nikolaos,

I believe the only limitations will be ones imposed by the shell/os on
the number of arguments that can be passed to an app (2^15?), and the
cpu and memory resources available.

Brian

On Tue, 2011-07-26 at 09:38 -0700, Nikolaos Hatzopoulos wrote:
> cool!
> 
> does it works with 150 files?
> 
> --Nikos
> 
> On Tue, Jul 26, 2011 at 9:17 AM, Brian Case  wrote:
> Nikolaos
> 
> I have warped modis with swath2grid and mosaicked it with
> mapserver, I
> have not seen that issue.
> 
> also you don't need to use a vrt to mosaic, this can be done
> with one
> gdalwarp call.
> 
> gdalwarp file1 file2 file3 outfile
> 
> 
> Brian
> 
> 
> On Mon, 2011-07-25 at 17:20 -0700, Nikolaos Hatzopoulos wrote:
> > It seems interesting I'll keep a note on this :)
> >
> > The question is how you can build a VRT mosaic directly from
> MODIS hdf
> > files, because
> > the problem is that you have to mosaic first and after that
> to
> > transform them to the
> > EPSG:4326 projection. If you transform them first and mosaic
> them
> > after you might have
> > white lines.
> >
> > --Nikos
> >
> > 2011/7/25 Brian Case 
> > anna, Nikolaos,
> >
> > after much experimentation I found something that
> seems to
> > work.
> >
> > gdalwarp --config GEOL_AS_GCPS FULL \
> > -tps -geoloc -t_srs EPSG:4326 \
> > -te -119.88004906118 13.5092548294379 \
> > -92.6036641645677 34.7070050511582 \
> >
> 
> HDF4_EOS:EOS_SWATH:"MOD02HKM.A2011169.1750.005.NRT.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB
>  \ MOD02HKM.A2011169.1750.005.NRT.tif
> >
> > note i tried to escape the newlines to make it easy
> to read
> > but the
> > email may mess that up.
> >
> > there is about 2.7 million gcp's in a normal 5min
> modis swath
> > file, by
> > default gdal only reads every 10th row and column of
> gcp's
> > this is not
> > enough to handle the bowtie effect.
> >
> >
> > Brian
> >
> > On Tue, 2011-01-18 at 16:33 -0800, Nikolaos
> Hatzopoulos wrote:
> > > You are right, I notice that there isn't any
> difference from
> > the
> > > band_1.tiff and band_1_warp.tiff
> > >
> > > --Nikos Hatzopoulos
> > >
> > > On Mon, Jan 17, 2011 at 8:15 AM, anna auge
> 
> > wrote:
> > > Hi all,
> > >
> > > I am trying to convert modis level 1B data
> (type
> > SWATH) to
> > > geotiff following these steps.
> > >
> > > 1) Examining the HDF
> > > gdalinfo d:\modis\1b
> > >
> \MOD021KM.A2011008.0850.005.2011008195744.hdf
> > > gdalinfo HDF4_EOS:EOS_SWATH:"d:\modis\1b
> > >
> >
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > > 2) Extracting the 1. band of the
> subdataset
> > > MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > > gdal_translate -of GTiff -b 1
> HDF4_EOS:EOS_SWATH:"d:
> > \modis\1b
> > >
> >
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
>  d:\modis\1b\band_1.tiff
> > > 4) Warping the image to WGS84
> > > gdalwarp -t_srs EPSG:4326 d:\modis\1b
> \band_1.tiff d:
> > \modis\1b
> > > \band_1_warp.tiff
> > >
> > >

Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff

[Brian Case]

Nikolaos

I have warped modis with swath2grid and mosaicked it with mapserver, I
have not seen that issue.

also you don't need to use a vrt to mosaic, this can be done with one
gdalwarp call.

gdalwarp file1 file2 file3 outfile


Brian

On Mon, 2011-07-25 at 17:20 -0700, Nikolaos Hatzopoulos wrote:
> It seems interesting I'll keep a note on this :)
> 
> The question is how you can build a VRT mosaic directly from MODIS hdf
> files, because
> the problem is that you have to mosaic first and after that to
> transform them to the
> EPSG:4326 projection. If you transform them first and mosaic them
> after you might have
> white lines.
> 
> --Nikos
> 
> 2011/7/25 Brian Case 
> anna, Nikolaos,
> 
> after much experimentation I found something that seems to
> work.
> 
> gdalwarp --config GEOL_AS_GCPS FULL \
> -tps -geoloc -t_srs EPSG:4326 \
> -te -119.88004906118 13.5092548294379 \
> -92.6036641645677 34.7070050511582 \
> 
> HDF4_EOS:EOS_SWATH:"MOD02HKM.A2011169.1750.005.NRT.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB
>  \ MOD02HKM.A2011169.1750.005.NRT.tif
> 
> note i tried to escape the newlines to make it easy to read
> but the
> email may mess that up.
> 
> there is about 2.7 million gcp's in a normal 5min modis swath
> file, by
> default gdal only reads every 10th row and column of gcp's
> this is not
> enough to handle the bowtie effect.
> 
> 
> Brian
> 
> On Tue, 2011-01-18 at 16:33 -0800, Nikolaos Hatzopoulos wrote:
> > You are right, I notice that there isn't any difference from
> the
> > band_1.tiff and band_1_warp.tiff
> >
> > --Nikos Hatzopoulos
> >
> > On Mon, Jan 17, 2011 at 8:15 AM, anna auge 
> wrote:
> > Hi all,
> >
> > I am trying to convert modis level 1B data (type
> SWATH) to
> > geotiff following these steps.
> >
> > 1) Examining the HDF
> > gdalinfo d:\modis\1b
> > \MOD021KM.A2011008.0850.005.2011008195744.hdf
> > gdalinfo HDF4_EOS:EOS_SWATH:"d:\modis\1b
> >
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > 2) Extracting the 1. band of the subdataset
> > MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> > gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:"d:
> \modis\1b
> >
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
>  d:\modis\1b\band_1.tiff
> > 4) Warping the image to WGS84
> > gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:
> \modis\1b
> > \band_1_warp.tiff
> >
> > The example dataset, which i am using, can be
> downloaded here
> >
> 
> ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf
> >
> > And now to my problem: I get always an certain shift
> >
> 
> (http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which 
> is avoided if i am using the "Georeference MODIS" option in ENVI 
> (http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/).
> > I also tried a few workarounds, f.g.
> >
> http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but
> > nothing worked properly.
> > As far as I understand gdal supports Modis L1B
> SWATH, so what
> > I am doing wrong? Any help is appreciated.
> >
> > Regards Anna
> >
> > P.S. I am using FWTools 2.4.7 on Windows
> >
> >
> >
> > WEB.DE DSL Doppel-Flat ab 19,99 ¤/mtl.! Jetzt mit
> > gratis Handy-Flat!
> > http://produkte.web.de/go/DSL_Doppel_Flatrate/2
> >
> > ___
> > 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
> 
> 
> 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff

[Brian Case]

anna, Nikolaos,

after much experimentation I found something that seems to work.

gdalwarp --config GEOL_AS_GCPS FULL \
 -tps -geoloc -t_srs EPSG:4326 \
 -te -119.88004906118 13.5092548294379 \
 -92.6036641645677 34.7070050511582 \
HDF4_EOS:EOS_SWATH:"MOD02HKM.A2011169.1750.005.NRT.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB
 \ MOD02HKM.A2011169.1750.005.NRT.tif

note i tried to escape the newlines to make it easy to read but the
email may mess that up.

there is about 2.7 million gcp's in a normal 5min modis swath file, by
default gdal only reads every 10th row and column of gcp's this is not
enough to handle the bowtie effect.


Brian

On Tue, 2011-01-18 at 16:33 -0800, Nikolaos Hatzopoulos wrote:
> You are right, I notice that there isn't any difference from the
> band_1.tiff and band_1_warp.tiff
> 
> --Nikos Hatzopoulos
> 
> On Mon, Jan 17, 2011 at 8:15 AM, anna auge  wrote:
> Hi all,
> 
> I am trying to convert modis level 1B data (type SWATH) to
> geotiff following these steps.
> 
> 1) Examining the HDF
> gdalinfo d:\modis\1b
> \MOD021KM.A2011008.0850.005.2011008195744.hdf
> gdalinfo HDF4_EOS:EOS_SWATH:"d:\modis\1b
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> 2) Extracting the 1. band of the subdataset
> MODIS_SWATH_Type_L1B:EV_1KM_RefSB
> gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:"d:\modis\1b
> 
> \MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
>  d:\modis\1b\band_1.tiff
> 4) Warping the image to WGS84
> gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:\modis\1b
> \band_1_warp.tiff
> 
> The example dataset, which i am using, can be downloaded here
> 
> ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf
> 
> And now to my problem: I get always an certain shift
> 
> (http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which 
> is avoided if i am using the "Georeference MODIS" option in ENVI 
> (http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/).
> I also tried a few workarounds, f.g.
> http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but
> nothing worked properly.
> As far as I understand gdal supports Modis L1B SWATH, so what
> I am doing wrong? Any help is appreciated.
> 
> Regards Anna
> 
> P.S. I am using FWTools 2.4.7 on Windows
>   
> 
> 
> WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit
> gratis Handy-Flat!
> http://produkte.web.de/go/DSL_Doppel_Flatrate/2
> 
> ___
> 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


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Draw map in Visual C++

[Brian Case]

mark

That is a pretty general question so difficult to give you an answer.

I would like to point out that gdal will not draw the maps in your
application but will let you read the data from many different formats
with a single api.

Here is the urls to the tutorials.

raster data: http://gdal.org/gdal_tutorial.html

vector data: http://gdal.org/ogr/ogr_apitut.html

Brian




On Fri, 2011-07-22 at 11:47 -0700, mark wrote:
> Hi 
> I am a beginner to OSGEO, I am using GDAL/OGR. 
> What is the fastest way , to draw maps / layers  in my application. 
> 
> I am using C++. 
> Thanks in advance
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/Draw-map-in-Visual-C-tp6611483p6611483.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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] [gdal-1.8.0] Get new Coordinates from Geotiff avoiding black area

[Brian Case]

Luiz,

do you have a url handy for the source code of that plugin?

Brian

On Tue, 2011-07-12 at 14:53 -0300, Luiz Motta wrote:
> Met,
> 
> I made a QGIS's plugin where calculate the 4 corners of polygon with
> the real pixels inside. Maybe is useful for you.
> The name of plugin is "Image Boundary", The source is Python and use
> only GDAL library for process.
> 
> Best regards,
> Luiz Motta
> 
> 2011/7/12 Chaitanya kumar CH :
> > Mett,
> >
> > If I understand correctly, you need to remove the black borders of geotiff
> > and reset the corner coordinates. GDAL's nearblack utility[1] might be of
> > help to you.
> >
> > [1]: http://www.gdal.org/nearblack.html
> >
> > On Tue, Jul 12, 2011 at 9:37 PM, mett  wrote:
> >>
> >> Hello Everybody!
> >> Does somebody know if there is a smart way to get the coordinates of a
> >> GeoTiff of the real data (avoinding the black background)? I mean, I have
> >> the geocoordinates of the image, but they are not referred to the "Real"
> >> data of the image but just to its corners. I know that I can use gdalwarp
> >> to
> >> set trasparency of black area, but I think it is not suitable to re-set
> >> the
> >> coordinates.
> >>
> >> Thank you for any help!
> >> Mett
> >>
> >> --
> >> View this message in context:
> >> http://osgeo-org.1803224.n2.nabble.com/gdal-1-8-0-Get-new-Coordinates-from-Geotiff-avoiding-black-area-tp6575681p6575681.html
> >> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> >> ___
> >> gdal-dev mailing list
> >> gdal-dev@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> > --
> > Best regards,
> > Chaitanya kumar CH.
> >
> > +91-9494447584
> > 17.2416N 80.1426E
> >
> > ___
> > 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


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unwanted partial transparency when clipping

[Brian Case]

Michael,

another option is to use gdalwarp to merge images together.

Brian

On Thu, 2011-07-07 at 09:47 -0700, Michael Corey wrote:
> Thanks for your responses, Chaitanya and Eli. The semitransparency isn't 
> really noticeable until you put the image on top of something else (in 
> Photoshop or another program).
> 
> It looks like the problem is actually in my gdal_merge.py command. 
> That's where the semitransparency is getting introduced.
> 
> gdal_merge.py -init "255" -o diablo-combined-utm10.tif file file file
> 
> What I'm trying to get is a merged image where no data = transparent. 
> Would this be correct in that case?
> 
> gdal_merge.py -n "255" -ul_lr 380309.272908 4653610.244134 
> 1317796.950998 3614484.073320 -o test-combined.tif file file file
> 
> Michael Corey
> Digital Innovations Editor
> Center for Investigative Reporting
> 510.809.3178
> 
> 
> On 7/7/11 7:13 AM, Eli Adam wrote:
> > Michael,
> >
>  On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org>, Michael
> > Corey  wrote:
> >> Sure, I've uploaded samples here.
> >>
> >> http://www.mikejcorey.com/spatial/diablo-box-sample.tif
> >> http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
> > I don't notice the semi-transparency in these scaled down images.  Perhaps 
> > it is the way your viewer reads the mask?
> >
> >> These are the same as the images created by the process I described (but
> >> scaled down).
> >>
> >> To your point about specifying size in the first step -- will that make
> >> the process run faster, or does it do the scaling down after it builds
> >> the full-resolution image?
> >>
> >> Also, I notice that my filesize always gets significantly bigger when I
> >> do the cutout step, which seems counter-intuitive to me since in theory
> >> shouldn't there be less information present once the cutout is done?
> > -cutline does not 'discard' any data.  The extent of the data remains the 
> > same unless you reset those extents.  You can do that with 
> > -crop_to_cutline.  Here are some details from the gdalwarp page, 
> > http://gdal.org/gdalwarp.html :
> >
> > -crop_to_cutline:
> >  (GDAL>= 1.8.0) Crop the extent of the target dataset to the extent of 
> > the cutline.
> >
> > Polygon cutlines may be used as a mask to restrict the area of the 
> > destination file that may be updated, including blending. If the OGR layer 
> > containing the cutline features has no explicit SRS, the cutline features 
> > must be in the georeferenced units of the destination file. When outputing 
> > to a not yet existing target dataset, its extent will be the one of the 
> > original raster unless -te or -crop_to_cutline are specified.
> >
> > Best Regards, Eli
> >
> >> Thanks for your help!
> >>
> >> Michael Corey
> >>
> >>
> >> On 7/6/11 5:01 PM, Chaitanya kumar CH wrote:
> >>> Michael,
> >>>
> >>> Can you provide screenshots of
> >>> diablo-combined-center-utm10-70pct-box.tif and
> >>> diablo-combined-center-utm10-70pct-cutout.tif for comparison?
> >>>
> >>> By the way, you can perform the actions of the two gdal_translate
> >>> commands in the first step with the gdal_merge.py script itself unless
> >>> you want to use a specific resampling algorithm.
> >>>
> >>> On Thu, Jul 7, 2011 at 4:28 AM, Michael Corey >>> >  wrote:
> >>>
> >>>  Hi all:
> >>>
> >>>  I'm using a shapefile as a clipping mask to cut out the shoreline
> >>>  from some DOQ files that I have merged together. But when I do the
> >>>  clipping step, I end up with unwanted semitransparency in the
> >>>  non-clipped areas.
> >>>
> >>>  I'm pretty sure the problem is only with my gdalwarp step at the end.
> >>>
> >>>  Here's my process:
> >>>
> >>>  gdal_merge.py -init "255" -o diablo-combined-center-utm10.tif file
> >>>  file file file
> >>>
> >>>  gdal_translate -outsize 70% 70% diablo-combined-center-utm10.tif
> >>>  diablo-combined-center-utm10-70pct.tif
> >>>
> >>>  ogrinfo -al ./diablo_canyon_detail_clipper.shp
> >>>  //Extent: (, ) - (, )
> >>>
> >>>  gdal_translate -projwin    
> >>>  diablo-combined-center-utm10-70pct.tif
> >>>  diablo-combined-center-utm10-70pct-box.tif
> >>>
> >>>  gdalwarp -co COMPRESS=DEFLATE -cutline
> >>>  ./diablo_canyon_detail_clipper.shp
> >>>  diablo-combined-center-utm10-70pct-box.tif
> >>>  diablo-combined-center-utm10-70pct-cutout.tif
> >>>
> >>>  Can anyone help?
> >>>
> >>>  Thanks!
> >>>
> >>>  --
> >>>  Michael Corey
> >>>
> >>>  ___
> >>>  gdal-dev mailing list
> >>>  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 m

Re: [gdal-dev] KML 2 SHP with attributes

[Brian Case]

Patrick,

Can you give an example of what tags your loosing?
are you using the kml or the libkml driver?

Brian

On Thu, 2011-06-30 at 15:30 -0600, Patrick Wild wrote:
> I am converting KML to .shp with OGR2ORG, however, due to the KML tags
> I am loosing my attributes. Does anyone have any experience with this?
> 
> ___
> 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] jpeg in tiff artifacts

[Brian Case]

matt,

jpeg is a lossy format. the nodata is ignored because those pixels are
no longer the same value as the nodata value.

You can add a mask band to the tiff but unfortunately aside from
gdalwarp and mapserver I don't think there is any other way to read it.

see http://docs.oam.osgeo.org/storage/creating.html

Brian





On Thu, 2011-06-16 at 10:20 -0700, Matt Wilkie wrote:
> Hello,
> 
> When I convert with gdal_translate and use jpeg compression in geotiff 
> format there is artifacting on the edges. It looks like nodata is being 
> ignored. Is there any way to avoid this? (and still use jpeg or 
> equivalent space-saving compression)
> 
> 
> 
> see attached.
> 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

[Brian Case]

Nikos

143, and 721

Brian

On Thu, 2011-06-09 at 16:49 -0700, Nikolaos Hatzopoulos wrote:
> for modis truecolor images?
> 
> --Nikos
> 
> On Thu, Jun 9, 2011 at 4:44 PM, Brian Case  wrote:
> Jonathan
> 
> I don't know about worldview, but with modis I wound up using
> multiple
> ranges
> 
> 0:0,750:110,1500:160,3000:210,4750:240,6375:255
> 
> see   in the vrt tutorial
> 
> Brian
> 
> 
> 
> 
> 
> 
> 
> On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote:
> > Brian:
> >
> >
> > Thanks!  Great solution, definitely saved me some time.  The
> main
> > issue (in terms of doing this entirely within GDAL) is
> getting the
> > right scaling to make the image look good.  I was able to
> figure out
> > the correct scale range within ENVI, and then apply the
> scales as you
> > suggested below.  Nikos' suggestion to use rgb2pct makes me
> wonder if
> > there is some way to figure out the optimal scale (which,
> AFAIK, is
> > part of how rgb2pct is functioning) to apply to this image.
> >
> >
> > Incidentally, what I'm trying to do is load Worldview-2 data
> onto an
> > iPad 2 for use with the GISRoam mobile mapping app.
>  Worldview-2 is
> > 16-bit per band, 8 band data, with a very high dynamic range
> (we have
> > snow in our image, so we have lots of VERY bright pixels
> which throw
> > off the adjustment if using -scale without any parameters).
>  99%
> > (100%?) of mobile mapping applications need 3-band data,
> usually with
> > only 8 bits per band.
> >
> >
> > Pushing forward, but if someone knows how to figure out an
> optimal set
> > of scale values to use within GDAL, please post the
> solution.
> >
> >
> > --j
> >
> > On Wed, Jun 8, 2011 at 9:45 PM, Brian Case 
> wrote:
> > Jonathan
> >
> > you can do scaling on individual bands.
> >
> > gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT
> infile
> > outfile1.vrt
> > gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT
> infile
> > outfile2.vrt
> > gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT
> infile
> > outfile3.vrt
> >
> > gdalbuildvrt -separate output.vrt outfile1.vrt
> outfile2.vrt
> > outfile3.vrt
> >
> > gdal_translate -of gtiff output.vrt output.tif
> >
> >
> >
> > for more complicated scaling you may need to hand
> write a vrt
> >
> > http://www.gdal.org/gdal_vrttut.html
> >
> > Brian
> >
> >
> > On Wed, 2011-06-08 at 19:31 -0700, Jonathan
> Greenberg wrote:
> > > Nikos and GDALers:
> > >
> > >
> > > This is CLOSE to what I'm looking to do, but I'm
> having a
> > hard time
> > > getting it working properly.  Here's my input
> dataset
> > gdalinfo dump:
> > >
> > >
> > > ***
> > >
> > >
> > > Driver: ENVI/ENVI .hdr Labelled
> > > Files:
> >
> 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi
> > >
> >
>  10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr
> > > Size is 42255, 51712
> > > Coordinate System is:
> > > GEOGCS["WGS 84",
> > > DATUM["WGS_1984",
> > > SPHEROID["WGS 84",6378137,298.257223563,
> > > AUTHORITY["EPSG","7030&qu

Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

[Brian Case]

Jonathan

I don't know about worldview, but with modis I wound up using multiple
ranges

0:0,750:110,1500:160,3000:210,4750:240,6375:255

see   in the vrt tutorial

Brian






On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote:
> Brian:
> 
> 
> Thanks!  Great solution, definitely saved me some time.  The main
> issue (in terms of doing this entirely within GDAL) is getting the
> right scaling to make the image look good.  I was able to figure out
> the correct scale range within ENVI, and then apply the scales as you
> suggested below.  Nikos' suggestion to use rgb2pct makes me wonder if
> there is some way to figure out the optimal scale (which, AFAIK, is
> part of how rgb2pct is functioning) to apply to this image.
> 
> 
> Incidentally, what I'm trying to do is load Worldview-2 data onto an
> iPad 2 for use with the GISRoam mobile mapping app.  Worldview-2 is
> 16-bit per band, 8 band data, with a very high dynamic range (we have
> snow in our image, so we have lots of VERY bright pixels which throw
> off the adjustment if using -scale without any parameters).  99%
> (100%?) of mobile mapping applications need 3-band data, usually with
> only 8 bits per band.
> 
> 
> Pushing forward, but if someone knows how to figure out an optimal set
> of scale values to use within GDAL, please post the solution.  
> 
> 
> --j
> 
> On Wed, Jun 8, 2011 at 9:45 PM, Brian Case  wrote:
> Jonathan
> 
> you can do scaling on individual bands.
> 
> gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile
> outfile1.vrt
> gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile
> outfile2.vrt
> gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile
> outfile3.vrt
> 
> gdalbuildvrt -separate output.vrt outfile1.vrt outfile2.vrt
> outfile3.vrt
> 
> gdal_translate -of gtiff output.vrt output.tif
> 
> 
> 
> for more complicated scaling you may need to hand write a vrt
> 
> http://www.gdal.org/gdal_vrttut.html
> 
> Brian
> 
> 
> On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote:
> > Nikos and GDALers:
> >
> >
> > This is CLOSE to what I'm looking to do, but I'm having a
> hard time
> > getting it working properly.  Here's my input dataset
> gdalinfo dump:
> >
> >
> > ***
> >
> >
> > Driver: ENVI/ENVI .hdr Labelled
> > Files:
> 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi
> >
>  10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr
> > Size is 42255, 51712
> > Coordinate System is:
> > GEOGCS["WGS 84",
> > DATUM["WGS_1984",
> > SPHEROID["WGS 84",6378137,298.257223563,
> > AUTHORITY["EPSG","7030"]],
> > TOWGS84[0,0,0,0,0,0,0],
> > AUTHORITY["EPSG","6326"]],
> > PRIMEM["Greenwich",0,
> > AUTHORITY["EPSG","8901"]],
> > UNIT["degree",0.0174532925199433,
> > AUTHORITY["EPSG","9108"]],
> > AUTHORITY["EPSG","4326"]]
> > Origin = (-120.0664799,39.2715542)
> > Pixel Size = (0.0450005,-0.0450005)
> > Image Structure Metadata:
> >   INTERLEAVE=BAND
> > Corner Coordinates:
> > Upper Left  (-120.0664800,  39.2715540) (120d 3'59.33"W,
> > 39d16'17.59"N)
> > Lower Left  (-120.0664800,  39.0388500) (120d 3'59.33"W, 39d
> > 2'19.86"N)
> > Upper Right (-119.8763325,  39.2715540) (119d52'34.80"W,
> > 39d16'17.59"N)
> > Lower Right (-119.8763325,  39.0388500) (119d52'34.80"W, 39d
> > 2'19.86"N)
> > Center  (-119.9714062,  39.1552020) (119d58'17.06"W, 39d
> > 9'18.73"N)
> > Band 1 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> > Band 2 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> > Band 3 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> >
> >
> >

Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

[Brian Case]

Jonathan

you can do scaling on individual bands.

gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile outfile1.vrt
gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile outfile2.vrt
gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile outfile3.vrt

gdalbuildvrt -separate output.vrt outfile1.vrt outfile2.vrt outfile3.vrt

gdal_translate -of gtiff output.vrt output.tif



for more complicated scaling you may need to hand write a vrt

http://www.gdal.org/gdal_vrttut.html

Brian

On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote:
> Nikos and GDALers:
> 
> 
> This is CLOSE to what I'm looking to do, but I'm having a hard time
> getting it working properly.  Here's my input dataset gdalinfo dump:
> 
> 
> ***
> 
> 
> Driver: ENVI/ENVI .hdr Labelled
> Files: 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi
>10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr
> Size is 42255, 51712
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9108"]],
> AUTHORITY["EPSG","4326"]]
> Origin = (-120.0664799,39.2715542)
> Pixel Size = (0.0450005,-0.0450005)
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (-120.0664800,  39.2715540) (120d 3'59.33"W,
> 39d16'17.59"N)
> Lower Left  (-120.0664800,  39.0388500) (120d 3'59.33"W, 39d
> 2'19.86"N)
> Upper Right (-119.8763325,  39.2715540) (119d52'34.80"W,
> 39d16'17.59"N)
> Lower Right (-119.8763325,  39.0388500) (119d52'34.80"W, 39d
> 2'19.86"N)
> Center  (-119.9714062,  39.1552020) (119d58'17.06"W, 39d
> 9'18.73"N)
> Band 1 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> Band 2 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> Band 3 Block=42255x1 Type=UInt16, ColorInterp=Undefined
> 
> 
> ***
> 
> 
> I need to end up with a Byte TIF image with good color balance from
> this input.  Running rgb2pct.py on this dataset just outputted a
> "blank" (grey) image.  Running gdal_translate -of GTiff -ot Byte
> -scale [min] [max] worked somewhat, but its near impossible to get
> this looking right, since the scaling I want to do differs from band
> to band (e.g. if there any way to use -scale to adjust each band
> separately)?  Alternatively, how would I get rgb2pct.py working on the
> above image correctly?  Thanks!
> 
> 
> --j
> 
> 
> 
> On Wed, Jun 8, 2011 at 4:10 PM, Nikolaos Hatzopoulos
>  wrote:
> why you don't try rgb2pct http://www.gdal.org/rgb2pct.html?
> 
> --Nikos Hatzopoulos
> 
> 
> On Wed, Jun 8, 2011 at 2:20 PM, Jonathan Greenberg
>  wrote:
> 
> 
> Folks:
> 
> 
> I am using a piece of software which is relying on an
> older version of GDAL that doesn't have the "fix" to
> deal with > 8 bit geotiffs (it is trying to make a
> jpeg overlay but can't from a 16 bit image.  I think
> this is the issue:
> http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG), but
> when I do a straight convert (-ot Byte) the output
> image looks really washed out.  Any hints for getting
> the best quality output from a 16 bit to to an 8 bit
> conversion of a Geotiff?   
> 
> 
> --j
> 
> -- 
> Jonathan A. Greenberg, PhD
> Assistant Project Scientist
> Center for Spatial Technologies and Remote Sensing
> (CSTARS)
> Department of Land, Air and Water Resources
> University of California, Davis
> One Shields Avenue
> Davis, CA 95616
> Phone: 415-763-5476
> AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307
> 
> 
> 
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> 
> 
> -- 
> Jonathan A. Greenberg, PhD
> Assistant Project Scientist
> Center for Spatial Technologies and Remote Sensing (CSTARS)
> Department of Land, Air and Water Resources
> University of California, Davis
> One Shields Avenue
> Davis, CA 95616
> Phone: 415-763-5476
> AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307
> 
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailma

Re: [gdal-dev] Adding libKML

[Brian Case]

Paul

You need libkml 1.3.0. this was only svn but i do not know if they have
released since i last looked.\

Brian

On Wed, 2011-05-18 at 11:35 +0200, Paul Meems wrote:
> Hi list,
> 
> I'm still struggling enabling new (at least for us) support for
> certain file formats.
> I'm working on Win7 with VS2008Pro
> 
> I'm now struggling with libKML.
> I did as suggested at http://trac.osgeo.org/gdal/wiki/LibKML, but
> downloaded the tar ball (v1.2.0)
> I found the vs2008 files and modified the boost config file.
> I can compile libKML, it seems to give me the necessary lib files.
> 
> I've enable libKML in nmake.opt of gdalv1.8 but when I compile I get
> this error:
> error C2039: 'DeleteFeatureAt' : is not a member of
> 'kmldom::Container'  in ogrlibkmldatasource.cpp
> 
> Now I got the trunk version and am able to compile libkml again.
> But now the error in GDAL is
> error LNK2001: unresolved external symbol "private: __thiscall
> kmldom::XalAddressDetails::XalAddressDetails(void)" 
> (??0XalAddressDetails@kmldom@@AAE@XZ) in  libkmldom.lib
> 
> I have no idea how to continue.
> 
> Can anybody point me in the right direction?
> 
> Thanks,
> 
> Paul
> 
> 
> Paul Meems 
> Release manager, configuration manager
> and forum moderator of MapWindow GIS.
> www.mapwindow.org
> 
> Owner of MapWindow.nl - Support for
> Dutch speaking users.
> www.mapwindow.nl
> 
> 
> 
> 
> 
> ___
> 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

[gdal-dev] gdal internal vrs external libs and gdal-config

[Brian Case]

hi,


This week I ran into an issue building OTB against a gdal with internal
libtiff and libgeotiff. After spending a bit of time trying to figure
out why i had a problem I thought it might be useful if gdal-config
could report on internal libs and if they are hidden.

What came up with is a gdal-config switch for each lib that has an
internal option that will return "external" if gdal used the external
lib. "internal", or "hidden" if it uses the internal lib and gdal was
configured with --with-hide-internal-symbols=yes

Attached is a diff. Does anyone have any opinions on this or alternate
ideas?

Brian


Index: /home/rush/Projects/gdal-trunk/apps/gdal-config.in
===
--- /home/rush/Projects/gdal-trunk/apps/gdal-config.in	(revision 22359)
+++ /home/rush/Projects/gdal-trunk/apps/gdal-config.in	(working copy)
@@ -11,6 +11,14 @@
 	[--version]
 	[--ogr-enabled]
 	[--formats]
+	[--libz-setting]
+	[--pcraster-setting]
+	[--png-setting]
+	[--pcidsk-setting]
+	[--tiff-setting]
+	[--geotiff-setting]
+	[--jpeg-setting]
+	[--gif-setting]
 EOF
 	exit $1
 }
@@ -52,6 +60,84 @@
 echo $CONFIG_FORMATS
 ;;
 
+  --libz-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_LIBZ_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_LIBZ_SETTING"
+fi
+
+;;
+
+  --pcraster-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_PCRASTER_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_PCRASTER_SETTING"
+fi
+
+;;
+
+  --png-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_PNG_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_PNG_SETTING"
+fi
+
+;;
+
+  --pcidsk-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_PCIDSK_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_PCIDSK_SETTING"
+fi
+
+;;
+
+  --tiff-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_TIFF_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_TIFF_SETTING"
+fi
+
+;;
+
+  --geotiff-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_GEOTIFF_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_GEOTIFF_SETTING"
+fi
+
+;;
+
+  --jpeg-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_JPEG_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_JPEG_SETTING"
+fi
+
+;;
+
+  --gif-setting)
+if test "$CONFIG_HIDE_INTERNAL_SYMBOLS" = "yes" && test "$CONFIG_GIF_SETTING" = "internal"
+then
+echo "hidden"
+else
+echo "$CONFIG_GIF_SETTING"
+fi
+;;
   *)
 usage 1 1>&2
 ;;
Index: /home/rush/Projects/gdal-trunk/apps/GNUmakefile
===
--- /home/rush/Projects/gdal-trunk/apps/GNUmakefile	(revision 22359)
+++ /home/rush/Projects/gdal-trunk/apps/GNUmakefile	(working copy)
@@ -138,6 +138,15 @@
 	echo 'CONFIG_VERSION="'`cat ../VERSION`'"' >> gdal-config
 	echo 'CONFIG_OGR_ENABLED=$(OGR_ENABLED)' >> gdal-config
 	echo 'CONFIG_FORMATS="$(GDAL_FORMATS)"' >> gdal-config
+	echo 'CONFIG_LIBZ_SETTING="$(LIBZ_SETTING)"' >> gdal-config
+	echo 'CONFIG_PCRASTER_SETTING="$(PCRASTER_SETTING)"' >> gdal-config
+	echo 'CONFIG_PNG_SETTING="$(PNG_SETTING)"' >> gdal-config
+	echo 'CONFIG_PCIDSK_SETTING="$(PCIDSK_SETTING)"' >> gdal-config
+	echo 'CONFIG_TIFF_SETTING="$(TIFF_SETTING)"' >> gdal-config
+	echo 'CONFIG_GEOTIFF_SETTING="$(GEOTIFF_SETTING)"' >> gdal-config
+	echo 'CONFIG_JPEG_SETTING="$(JPEG_SETTING)"' >> gdal-config
+	echo 'CONFIG_GIF_SETTING="$(GIF_SETTING)"' >> gdal-config
+	echo 'CONFIG_HIDE_INTERNAL_SYMBOLS="$(HAVE_HIDE_INTERNAL_SYMBOLS)"' >> gdal-config
 	cat gdal-config.in >> gdal-config
 	chmod a+x gdal-config
 
@@ -152,6 +161,15 @@
 	echo 'CONFIG_VERSION="'`cat ../VERSION`'"' >> gdal-config-inst
 	echo 'CONFIG_OGR_ENABLED=$(OGR_ENABLED)' >> gdal-config-inst
 	echo 'CONFIG_FORMATS="$(GDAL_FORMATS)"' >> gdal-config-inst
+	echo 'CONFIG_LIBZ_SETTING="$(LIBZ_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_PCRASTER_SETTING="$(PCRASTER_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_PNG_SETTING="$(PNG_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_PCIDSK_SETTING="$(PCIDSK_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_TIFF_SETTING="$(TIFF_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_GEOTIFF_SETTING="$(GEOTIFF_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_JPEG_SETTING="$(JPEG_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_GIF_SETTING="$(GIF_SETTING)"' >> gdal-config-inst
+	echo 'CONFIG_HIDE_INTERNAL_SYMBOLS="$(HAVE_HIDE_INTERNAL_SYMBOLS)"' >> gdal-config-inst
 	cat gdal-config.in >> gdal-config-inst
 	chmod a+x gdal-config-inst
 
Index: 

Re: [gdal-dev] gdal reading in grib values in awrong state?

[Brian Case]

Bill

gdal uses degrib to read grib files, best I can tell is it does whatever
degrib does by default

Brian


On Thu, 2011-05-05 at 22:33 +, Cassanova, Bill wrote:
> I have noticed the same thing.  My question is why would gdal do a conversion 
> that you had not asked for?  We create some of our own grib2 files that may 
> at times have unitless values.  For some odd reason they are being converted 
> to Celsius as well.  
> 
> Sent from my iPad
> 
> On May 5, 2011, at 5:09 PM, "Brian Case"  wrote:
> 
> > Matt,
> > 
> > At a quick glance I would say pygrib is outputting in kelvin and gdal
> > Celsius. also it looks like there not in the same order.
> > 
> > Brian
> > 
> > 
> > 
> > On Thu, 2011-05-05 at 14:57 -0600, maf...@nmsu.edu wrote:
> >> Hi,
> >> i am a little confused. I am using the gdal/python and trying to read
> >> values from a grib file (i can email the file if needed). I am using
> >> pygrib to compare against. I do this with the following code:
> >> 
> >> import struct
> >> 
> >> import pygrib
> >> 
> >> from osgeo import gdal
> >> from osgeo import ogr
> >> from osgeo import osr
> >> from osgeo import gdal_array
> >> from osgeo import gdalconst
> >> from osgeo.gdalconst import *
> >> 
> >> import numpy as np
> >> from numpy import *
> >> 
> >> #path = "../Data"
> >> #filename = "%s/ds.temp.bin" % (path)
> >> filename = "ds.temp.bin"
> >> 
> >> print "\n\nTesting with pygrib, opening file: %s\n" % (filename)
> >> grbs = pygrib.open(filename)
> >> rows = -1
> >> cols = -1
> >> grbs.seek(0)
> >> for grb in grbs:
> >>print "grb:"
> >>grb
> >>print "grb.keys():"
> >>print grb.keys()
> >>for key in grb.keys():
> >>print "\nKey: " + key
> >>print "data:"
> >>print grb[key]
> >> 
> >> 
> >> 
> >>#print "grb['values']"
> >>#print grb['values']
> >>#print "grb['codedValues']"
> >>#print grb['codedValues']
> >> 
> >>(pg_lats,pg_lons) = grb.latlons()
> >>pg_rows = pg_lats.shape[0]
> >>pg_cols = pg_lats.shape[1]
> >>#print test
> >>#print lats.shape, lats.min(), lats.max(), lons.shape,
> >> lons.min(), lons.max()
> >>#lat_pygrib_arr = []
> >>print size(pg_lats)
> >> print "\n\n"
> >> 
> >> 
> >> ## open with gdal
> >> ds = gdal.Open(filename)
> >> band = ds.GetRasterBand(1)
> >> data = band.ReadAsArray(0,0,band.XSize,band.YSize)#.flatten()
> >> print "data:"
> >> print data
> >> 
> >> 
> >> The data values i get from pygrib are:
> >> data:
> >> [[ 294.5   294.5   294.5  ...,  298.31  298.32  298.32]
> >> [ 294.5   294.5   294.5  ...,  298.32  298.22  298.22]
> >> [ 294.4   294.4   294.4  ...,  298.22  298.22  298.22]
> >> ...,
> >> [ 280.91  280.91  280.81 ...,  264.2   264.3   264.5 ]
> >> [ 280.81  280.81  280.81 ...,  263.5   263.7   263.9 ]
> >> [ 280.81  280.81  280.81 ...,  262.8   263.263.3 ]]
> >> 
> >> The values i get from gdal are:
> >> data:
> >> [[  7.65999756   7.65999756   7.65999756 ..., -10.35001221 -10.15
> >>   -9.85001221]
> >> [  7.65999756   7.65999756   7.65999756 ...,  -9.65-9.45001831
> >>   -9.2500061 ]
> >> [  7.76000366   7.76000366   7.65999756 ...,  -8.95001831  -8.85001221
> >>   -8.65  ]
> >> ...,
> >> [ 21.2499939   21.2499939   21.2499939  ...,  25.07000122  25.07000122
> >>   25.07000122]
> >> [ 21.3521.3521.35   ...,  25.17000732  25.07000122
> >>   25.07000122]
> >> [ 21.3521.3521.35   ...,  25.15999756  25.17000732
> >>   25.17000732]]
> >> 
> >> Is there anything obvious that i am doing wrong?
> >> 
> >> thanks
> >> matt
> >> 
> >> 
> >> ___
> >> 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


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal reading in grib values in awrong state?

[Brian Case]

Matt,

At a quick glance I would say pygrib is outputting in kelvin and gdal
Celsius. also it looks like there not in the same order.

Brian



On Thu, 2011-05-05 at 14:57 -0600, maf...@nmsu.edu wrote:
> Hi,
> i am a little confused. I am using the gdal/python and trying to read
> values from a grib file (i can email the file if needed). I am using
> pygrib to compare against. I do this with the following code:
> 
> import struct
> 
> import pygrib
> 
> from osgeo import gdal
> from osgeo import ogr
> from osgeo import osr
> from osgeo import gdal_array
> from osgeo import gdalconst
> from osgeo.gdalconst import *
> 
> import numpy as np
> from numpy import *
> 
> #path = "../Data"
> #filename = "%s/ds.temp.bin" % (path)
> filename = "ds.temp.bin"
> 
> print "\n\nTesting with pygrib, opening file: %s\n" % (filename)
> grbs = pygrib.open(filename)
> rows = -1
> cols = -1
> grbs.seek(0)
> for grb in grbs:
> print "grb:"
> grb
> print "grb.keys():"
> print grb.keys()
> for key in grb.keys():
> print "\nKey: " + key
> print "data:"
> print grb[key]
> 
> 
> 
> #print "grb['values']"
> #print grb['values']
> #print "grb['codedValues']"
> #print grb['codedValues']
> 
> (pg_lats,pg_lons) = grb.latlons()
> pg_rows = pg_lats.shape[0]
> pg_cols = pg_lats.shape[1]
> #print test
> #print lats.shape, lats.min(), lats.max(), lons.shape,
> lons.min(), lons.max()
> #lat_pygrib_arr = []
> print size(pg_lats)
> print "\n\n"
> 
> 
> ## open with gdal
> ds = gdal.Open(filename)
> band = ds.GetRasterBand(1)
> data = band.ReadAsArray(0,0,band.XSize,band.YSize)#.flatten()
> print "data:"
> print data
> 
> 
> The data values i get from pygrib are:
> data:
> [[ 294.5   294.5   294.5  ...,  298.31  298.32  298.32]
>  [ 294.5   294.5   294.5  ...,  298.32  298.22  298.22]
>  [ 294.4   294.4   294.4  ...,  298.22  298.22  298.22]
>  ...,
>  [ 280.91  280.91  280.81 ...,  264.2   264.3   264.5 ]
>  [ 280.81  280.81  280.81 ...,  263.5   263.7   263.9 ]
>  [ 280.81  280.81  280.81 ...,  262.8   263.263.3 ]]
> 
> The values i get from gdal are:
> data:
> [[  7.65999756   7.65999756   7.65999756 ..., -10.35001221 -10.15
>-9.85001221]
>  [  7.65999756   7.65999756   7.65999756 ...,  -9.65-9.45001831
>-9.2500061 ]
>  [  7.76000366   7.76000366   7.65999756 ...,  -8.95001831  -8.85001221
>-8.65  ]
>  ...,
>  [ 21.2499939   21.2499939   21.2499939  ...,  25.07000122  25.07000122
>25.07000122]
>  [ 21.3521.3521.35   ...,  25.17000732  25.07000122
>25.07000122]
>  [ 21.3521.3521.35   ...,  25.15999756  25.17000732
>25.17000732]]
> 
> Is there anything obvious that i am doing wrong?
> 
> thanks
> matt
> 
> 
> ___
> 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] Re: cropping a tif with lat/lon

[Brian Case]

Dan

use nearblack to add a alpha or mask band, and collar the image

Brian


On Wed, 2011-04-20 at 19:15 -0700, spalt wrote:
> Hi Brian-
> Thanks so much for your help.  That works, though I feel a little silly now
> because I am realizing the lat/lon the FAA provides with these is the
> corners of the entire map image, not the map itself (these maps have a lot
> of white borders around them, which is what I am trying to crop).  I guess
> it is back to the drawing board.  Anyway, thanks again.
> -Dan
> 
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/cropping-a-tif-with-lat-lon-tp6292065p6293047.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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