Re: [gdal-dev] How to implement tile read / write to gdal supported format file?

2013-11-18 Thread Luke
You could do something like the following: (code modified from the gdal_calculations library - http://code.google.com/p/gdal-calculations) from osgeo import gdal class Block(object): def __init__(self, dataset, band, xoff, yoff, xsize, ysize): self.xoff = xoff self.yoff = yof

[gdal-dev] set authenticate set delivery off

2013-11-18 Thread Kyle Sletmoe
set authenticate set delivery off -- *Information contained herein is subject to the Code of Federal Regulations Chapter 22 International Traffic in Arms Regulations. This data may not be resold, diverted, transferred, transshipped, made available to a foreign national within the United States

Re: [gdal-dev] ogr2og / forcing a +-180 system

2013-11-18 Thread Even Rouault
Le lundi 18 novembre 2013 20:29:07, Robb K. Wright a écrit : > I haven't been able to get either -wrapdateline or -datelineoffset to > alter the coords. As far as I can figure out, the -wrapdateline option > only operates on features that actually intersect the 180 line, so using > it doesn't alte

Re: [gdal-dev] Generated KML incorrectly formated and image reflected in X axis

2013-11-18 Thread JSz
Perfect, that solved the projection issue. Have you any ideas why the KMZ file isn't able to open in google earth but if I remove the individual parts ( 0.kml and 0.png ) and open all is ok? Alternativly is there a way to just generate the KML file directly rather than with : gdal_translate.exe

Re: [gdal-dev] building gdal on windows -- how to hide internal libtiff symbols

2013-11-18 Thread kyle.sletmoe
Even, Oh, OK I was not aware of this. Thanks for the help. Regards, Kyle -- View this message in context: http://osgeo-org.1560.x6.nabble.com/building-gdal-on-windows-how-to-hide-internal-libtiff-symbols-tp5089510p5089742.html Sent from the GDAL - Dev mailing list archive at Nabble.com. _

Re: [gdal-dev] Generated KML incorrectly formated and image reflected in X axis

2013-11-18 Thread Even Rouault
Le lundi 18 novembre 2013 19:14:15, JSz a écrit : > Good evening, > > I have generated an KMZ file using : > gdal_translate.exe -of KMLSUPEROVERLAY EM_RESULTS.tiff EM_RESULTS.kmz -co > FORMAT=JPEG > > Opening the KMZ on its own with GoogleEarth doesnt display anything, if I > extract the tiles di

Re: [gdal-dev] ogr2og / forcing a +-180 system

2013-11-18 Thread Robb K. Wright
I haven't been able to get either -wrapdateline or -datelineoffset to alter the coords. As far as I can figure out, the -wrapdateline option only operates on features that actually intersect the 180 line, so using it doesn't alter my coords since mine are only on either side. I'm just tryin

[gdal-dev] Generated KML incorrectly formated and image reflected in X axis

2013-11-18 Thread JSz
Good evening, I have generated an KMZ file using : gdal_translate.exe -of KMLSUPEROVERLAY EM_RESULTS.tiff EM_RESULTS.kmz -co FORMAT=JPEG Opening the KMZ on its own with GoogleEarth doesnt display anything, if I extract the tiles directly out the KML and extract to Desktop and drill down I can ope

Re: [gdal-dev] ogr2og / forcing a +-180 system

2013-11-18 Thread Frank Warmerdam
Robb, Have you tried the -wrapdateline switch? I do not believe geometries that cross the dateline will be handled ideally (they aren't split as one might hope), but if you don't have them then the rest of the geometries should be wrapped. I see there is even now a -datelineoffset switch if some

[gdal-dev] ogr2og / forcing a +-180 system

2013-11-18 Thread Robb K. Wright
I need to use ogr2ogr (or any other command line) to convert a shapefile with longitudes spanning from -220 to -60, forcing it into a +-180 scheme, so the -220 coordinate would come out as +140 and the -60 stays as -60. I don't need to worry about the polys that actually cross the 180 line.

[gdal-dev] Patch: Improvements to the rasdaman driver

2013-11-18 Thread Fabian Schindler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Devs, I implemented a couple of improvements of the GDAL rasdaman driver. Ticket with a detailed description of the changes and patch are available here: http://trac.osgeo.org/gdal/ticket/5298 Of course, I appreciate any feedback and I hope the patc

Re: [gdal-dev] [PATCH v2] Support Mercator_2SP in GeoTIFF

2013-11-18 Thread Antti Castrén
Hi Trent, The chart opens in ArcMap (ArcGIS 10.0) well, and it is in right location (Seattle). Relevant properties of the file as seen by ArcGIS: Cell Size: 240.003787, 240.003787 Extent Top:4143530.20898 Left: -9278434.53415 Right: -9165872.75807 Bottom: 3984167.69444 Spatial Reference: Globa

Re: [gdal-dev] Support USRP

2013-11-18 Thread xavier lhomme
Hi I've submitted a ticket #5297 and attached a new version of the usrp/asrp driver. Best Regards 2013/11/18 Even Rouault > Selon xavier lhomme : > > > Hi > > > > What should be the return of gdalinfo after reading a TRANSH01.THF : > >I have added all IMG in subdatasets. But should I se

Re: [gdal-dev] Support USRP

2013-11-18 Thread Even Rouault
Selon xavier lhomme : > Hi > > What should be the return of gdalinfo after reading a TRANSH01.THF : >I have added all IMG in subdatasets. But should I set a SpatialReference > and Extent for the main dataset (by merging all Extent in one ) ? Datasets that only report subdatasets generally d

Re: [gdal-dev] Support USRP

2013-11-18 Thread xavier lhomme
Hi What should be the return of gdalinfo after reading a TRANSH01.THF : I have added all IMG in subdatasets. But should I set a SpatialReference and Extent for the main dataset (by merging all Extent in one ) ? xav 2013/11/15 Even Rouault > Le jeudi 14 novembre 2013 10:35:35, xavier lhom