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 even.roua...@mines-paris.org Le jeudi 14

Re: [gdal-dev] Support USRP

2013-11-18 Thread Even Rouault
Selon xavier lhomme lhomme.xav...@gmail.com: 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

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 even.roua...@mines-paris.org Selon xavier lhomme lhomme.xav...@gmail.com: Hi What should be the return of gdalinfo after reading a TRANSH01.THF : I have

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:

[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

[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.

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

[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

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

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 directly

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 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] 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 alter

[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

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 =