[gdal-dev] Re: Gdal2tiles in Gdal18 and creating KMZ files

[Vadim Shlyakhov]

brian  winkey.org> writes:

> the problem is in /12/1211/2558.kml line 26
> 
> 2558.png
> 
> this should be a relative path from the root of the zipfile not from
> 2558.kml
> 

Hello Brian, 

I've made another tile cutter (http://code.google.com/p/tilers-tools/). It
produces a directory tree in a manner which is very similar to gdal2tiles.py. So
I had a look into this problem. 

I must say it didn't work for me either: GE shows KML just fine, but if I zip a
dir tree into KMZ it fails altogether. I've tried relative paths to PNGs, to
internal KMLs. All these were to no avail. 

I think that the problem actually lies in '' things and I still
cannot get a clue on these.

I wonder if you have (or can produce manually) a sample of working KMZ with
superoverlays, so I'd be able to have a look

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

Re: [gdal-dev] Mosaicking Orthos

[Zoltan Szecsei]

Hi Chaitanya (& all),
I tried your nearblack comment, and got:

 nearblack -white -o 0394w.tif 0394.tif
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "GeoASCIIParams" does
not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitati
ERROR 4: Creation of file 0394w.tif failed.


I think I am having trouble understanding the setting/using of nodata
values.
I have now also downloaded and compiled gdal 1.8.0 (but nearblack
remained on v1.7.3) on ubuntu 10.04 LTS, and recreated my vrt, to no
improvement.

To recap: I have 179 3*8bit RGB band aerial images that have been
orthorectified. The resulting skewness in the images has created white
slivers in the corners, and I am presuming that these white slivers are
recognised as "nodata". (My first mistake?)

I use the following to create a vrt: 
gdalbuildvrt -addalpha -hidenodata -srcnodata "255 255 255" -vrtnodata
"0 0 0" -input_file_list files 177_untiled_orthos_nodata_180.vrt

Thinking that the above will tell gdalbuildvrt that, for the input
orthos, white should be recognised as 'nodata', and in the VRT, those
white pixels should be converted to black, as nodata.
Well, as you've guessed, it didn't happen this way, and I still have
the white bits after mosaicking my VRT thus:
gdal_translate -projwin -16000 -3520650 -13000 -3525650
177_untiled_orthos_nodata.vrt try1.tif

I tried re-running gdalbuildvrt specifying -vrtnodata "255 255 255" (to
match the input ortho files) and the outside border of my vrt turned
white, but the slivers between the mosaicked orthos were still present.

Please can someone show me the correct way to address this problem.

I have included gdalinfo results for both an individual ortho, and for
the vrt itself.

Thanks & regards,
Zoltan






**  GDALINFO
on indicidual ORTHO 
geograph@gs0:~/vrt_177$ gdalinfo --version
GDAL 1.8.0, released 2011/01/12
geograph@gs0:~/vrt_177$ 
geograph@gs0:~/vrt_177$ 
geograph@gs0:~/vrt_177$ 
geograph@gs0:~/vrt_177$ gdalinfo
/mnt/geo_lvm0/ngi_jobs/orthos_8bit/NGI_177_untiled_orthos/0003.tif
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitations
Warning 1: TIFFFetchNormalTag:ASCII value for tag "GeoASCIIParams" does
not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementation limitations
Warning 1: TIFFFetchNormalTag:ASCII value for tag "ImageDescription"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Software" contains
null byte in value; value incorrectly truncated during reading due to
implementatio

Re: [gdal-dev] Mosaicking Orthos

[Marius Jigmond]

Hi Zoltan,

Are you sure that the white you see is a pure 255/255/255? Albeit, the
nearblack with its near default of 15 would have likely taken care of
that.

If you load two othophotos in QGIS and specify the transparent pixels,
does the collar between the orthophotos disappear?

Regarding the warnings see:
http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg06960.html

-marius



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

[gdal-dev] OGR VRT ODBC connection problem

[pcreso]

Hi,

Apologies for the cross posting, but I figure there are experts on both lists.

I'm trying to get a ogr virtual connection working from a Linux host to a 
remote Oracle DB to use mapserver for a WFS service providing the required 
data..

ODBC is working, eg:

sqlplus user/user@metp
select count(*) from land_station;
8338

etc...

However, when testing with ogr2ogr, I get:

ogrinfo ODBC:user/user@metp land_station

libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No 
such file or directory

and the terminal window hangs, I'm unable to get any response, & have to kill 
the connection to continue.


Any suggestions?


Thanks,

  Brent Wood




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

[gdal-dev] Re: [mapserver-users] OGR VRT ODBC connection problem

[Stephen Woodbridge]

Hi Brent,

I'm certainly not an expert on this, but I think the issue might be that 
sqlplus does not use an ODBC connection it uses some proprietary Oracle 
socket protocol to connect.


Do you have ODBC services setup, configured and running on the Linux 
host? How have you verified this?


If not then this is likely the issue. Sorry I don't use ODBC, so I can't 
help much more then this.


-Steve W

On 2/20/2011 7:12 PM, pcr...@pcreso.com wrote:


Hi,

Apologies for the cross posting, but I figure there are experts on both
lists.

I'm trying to get a ogr virtual connection working from a Linux host to
a remote Oracle DB to use mapserver for a WFS service providing the
required data..

ODBC is working, eg:

sqlplus user/user@metp 
select count(*) from land_station;
8338

etc...

However, when testing with ogr2ogr, I get:

ogrinfo ODBC:user/user@metp land_station

libnuma: Warning: /sys not mounted or no numa system. Assuming one node:
No such file or directory

and the terminal window hangs, I'm unable to get any response, & have to
kill the connection to continue.


Any suggestions?


Thanks,

Brent Wood






___
mapserver-users mailing list
mapserver-us...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


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

[gdal-dev] Re: [mapserver-users] OGR VRT ODBC connection problem

[pcreso]

Thanks Stephen, 

I should have included this in my first msg, apologies, but thanks for the 
reply.

I'm running GDAL v1.6.1, from
ogrinfo --version
GDAL 1.6.1, released 2009/05/11
 

And, running isql (from unixodbc) also works.

isql --help
unixODBC 2.2.12

isql -v metp niwatest niwatest
libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No 
such file or directory
+---+
| Connected!    |
|   |
| sql-statement |
| help [tablename]  |
| quit  |
|   |
+---+
SQL> select count(*) from land_station;
+-+
| COUNT(*)    |
+-+
| 8338    |
+-+    


So isql succeeds, and is definately using ODBC.

ogrinfo just hangs. Both have the /sys warning msg, which I am ignoring.


I'm still lost with respect to this


Thanks,

   Brent



--- On Mon, 2/21/11, Stephen Woodbridge  wrote:

From: Stephen Woodbridge 
Subject: Re: [mapserver-users] OGR VRT ODBC connection problem
To: pcr...@pcreso.com
Cc: mapserver-us...@lists.osgeo.org, gdal-dev@lists.osgeo.org
Date: Monday, February 21, 2011, 2:12 PM

Hi Brent,

I'm certainly not an expert on this, but I think the issue might be that 
sqlplus does not use an ODBC connection it uses some proprietary Oracle 
socket protocol to connect.

Do you have ODBC services setup, configured and running on the Linux 
host? How have you verified this?

If not then this is likely the issue. Sorry I don't use ODBC, so I can't 
help much more then this.

-Steve W

On 2/20/2011 7:12 PM, pcr...@pcreso.com wrote:
>
> Hi,
>
> Apologies for the cross posting, but I figure there are experts on both
> lists.
>
> I'm trying to get a ogr virtual connection working from a Linux host to
> a remote Oracle DB to use mapserver for a WFS service providing the
> required data..
>
> ODBC is working, eg:
>
> sqlplus user/user@metp 
> select count(*) from land_station;
> 8338
>
> etc...
>
> However, when testing with ogr2ogr, I get:
>
> ogrinfo ODBC:user/user@metp land_station
>
> libnuma: Warning: /sys not mounted or no numa system. Assuming one node:
> No such file or directory
>
> and the terminal window hangs, I'm unable to get any response, & have to
> kill the connection to continue.
>
>
> Any suggestions?
>
>
> Thanks,
>
> Brent Wood
>
>
>
>
>
>
> ___
> mapserver-users mailing list
> mapserver-us...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users

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

Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0

[Chaitanya kumar CH]

Derrick,

I tested your sample data on ubuntu with gdal trunk and 1.8 versions.

Check if you are linking to the right gdal library. Just run the command
"gdalinfo --version".

Since the error is coming up only on your system, you have to help me
perform the testing.

Build with the "--enable-debug" configure option and run the program after
setting the environment variable "CPL_DEBUG" to YES. If that doesn't show
any info before segfaulting, run it under the gdb debugger.

On Mon, Feb 21, 2011 at 9:28 AM,  wrote:

> Hi Chaitanya
>
>
>
> I have downloaded and unpacked the tar.gz and compiled it in on a standard
> Debian box.
>
>
>
> Please find attached the config log for the installation.
>
>
>
> I have downloaded a precompiled windows executable (1.8.0) for comparison,
> and I am not having any issues with it though.
>
>
>
> Am I missing an include or something during my build/compile process?
>
>
>
> Please assist.
>
>
>
> Thanks.
>
>
>
> *Derrick Wong** *
> Software Engineer *|* Spatial Information Services Stack (SISS) Project *|
> *CSIRO
>
> Phone: +61 8 6436 8945
> derrick.w...@csiro.au *|* www.csiro.au
> Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue,
> Kensington WA 6151, Australia
>
> *PLEASE NOTE**
> *The information contained in this email may be confidential or
> privileged. Any unauthorised use or disclosure is prohibited. If you have
> received this email in error, please delete it immediately and notify the
> sender by return email. Thank you. To the extent permitted by law, CSIRO
> does not represent, warrant and/or guarantee that the integrity of this
> communication has been maintained or that the communication is free of
> errors, virus, interception or interference.
>
> *Please consider the environment before printing this email.*
>
>
>
> *From:* Chaitanya kumar CH [mailto:chaitanya...@gmail.com]
> *Sent:* Friday, 18 February 2011 7:56 PM
>
> *To:* Wong, Derrick (CESRE, Kensington)
> *Cc:* ksshan...@gmail.com; gdal-dev@lists.osgeo.org; Fraser, Ryan (CESRE,
> Kensington)
>
> *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
>
>
>
> Derrick,
>
> I was able to run gdalinfo and gdal_translate on your sample dataset
> without any error.
> Can you provide some more details like your platform and the settings you
> used to compile GDAL?
>
> On Fri, Feb 18, 2011 at 9:57 AM,  wrote:
>
> Hi Kyle,
>
>
>
> Thanks for the reply.
>
>
>
> Gdalinfo on 1.8.0 gives me the same “Segmentation fault” error.
>
>
>
> Attached is the dump using 1.7.3
>
>
>
> I have included a sample file and you can download it here:
>
>
>
> ftp://ftp.csiro.au/DerrickWong/sample/sample.nc
>
>
>
>
>
>
>
> *Derrick Wong *
> Software Engineer *|* Spatial Information Services Stack (SISS) Project *|
> *CSIRO
>
> Phone: +61 8 6436 8945
> derrick.w...@csiro.au *|* www.csiro.au
> Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue,
> Kensington WA 6151, Australia
>
> *PLEASE NOTE**
> *The information contained in this email may be confidential or
> privileged. Any unauthorised use or disclosure is prohibited. If you have
> received this email in error, please delete it immediately and notify the
> sender by return email. Thank you. To the extent permitted by law, CSIRO
> does not represent, warrant and/or guarantee that the integrity of this
> communication has been maintained or that the communication is free of
> errors, virus, interception or interference.
>
> *Please consider the environment before printing this email.*
>
>
>
> *From:* Kyle Shannon [mailto:ksshan...@gmail.com]
> *Sent:* Friday, 18 February 2011 11:32 AM
> *To:* Wong, Derrick (CESRE, Kensington)
> *Cc:* gdal-dev@lists.osgeo.org
> *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
>
>
>
> Derrick,
> Can you file a ticket and attach a sample data set?  Do you have any other
> details?  A gdalinfo of the netcdf file and another of one of the variables
> would be great.  Thanks.
>
> kss
>
>
> # 
> Kyle Shannon
> Physical Science Technician
> RMRS Fire Sciences Lab
> Fire, Fuels & Smoke - RWU 4405
> 5775 Highway 10 W.
> Missoula, MT 59808
> (406)829-6954
> kshan...@fs.fed.us
> # 
>
> On Thu, Feb 17, 2011 at 19:54,  wrote:
>
> Hi all,
>
>
>
> I have updated to use GDAL 1.8 and I am having problems using
> gdal_translate to convert netCDF files to Geotiff or ERS. I am getting
> “Segmentation fault” errors only occurring in 1.8.0. I was using 1.7.3
> previously.
>
>
>
> Could someone kindly advise?
>
>
>
> Thank you for your time.
>
> *Derrick Wong *
> Software Engineer *|* Spatial Information Services Stack (SISS) Project *|
> *CSIRO
>
> Phone: +61 8 6436 8945
> derrick.w...@csiro.au *|* www.csiro.au
> Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue,
> Kensington WA 6151, Australia
>
> *PLEASE NOTE**
> *The information contained in this email may be confidential or
> privileged. Any unauthorised 

[gdal-dev] Re: [Live-demo] Image for the GDAL overview

[Hamish]

Hi,

A gdal overview image for the live DVD is now uploaded. the GDAL/OGR list
of formats is a bit out of date (it's a slide from a talk I gave a few
years ago), but the oldies but goodies will all be there. Not sure how
well the words will scale down, but we can always rerender from source at
the target image size, and increase the fontsize of bolded words as needed.

 http://adhoc.osgeo.osuosl.org/livedvd/docs/en/overview/gdal_overview.html

(due to a sphinx 1.0.4 bug*, image scaling isn't working at all on the 
nightly adhoc server doc build, but we use the old version on the disc
so not a problem for the final cut. For now just imagine that the image
only covers 60% of the frame)
 [*] https://bitbucket.org/birkenfeld/sphinx/issue/557/

PROJ.4 is mentioned in passing here as it otherwise doesn't get any due
props on the disc, and it surely deserves some.


enjoy,
Hamish



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

Re: [gdal-dev] Mosaicking Orthos

[Zoltan Szecsei]

Hi Marius,
Thanks for the response. See below:

On 2011-02-20 21:16, Marius Jigmond wrote:

  Are you sure that the white you see is a pure 255/255/255? Albeit, the
nearblack with its near default of 15 would have likely taken care of
that.
  

except that when I run nearblack (v1.7.3), it doesn't create the output
tiff file.
nearblack -white -o 0394w.tif 0394.tif
ERROR 4: Creation of file 0394w.tif failed.


  
If you load two othophotos in QGIS and specify the transparent pixels,
does the collar between the orthophotos disappear?
  

when I manually add to the Transparent Pixel List, then it works (in
Qgis), so how can I update all the ortho images to reflect their nodata
values?
(meaning, using nearblack should/would work, but my nearblack crashes)





Thanks,
Zoltan

-- 

===
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
P.O. Box 7, Muizenberg 7950, South Africa.

65 Main Road, Muizenberg 7945
Western Cape, South Africa.  

34° 6'16.35"S 18°28'5.62"E 

Tel: +27-21-7884897  Mobile: +27-83-6004028
Fax: +27-86-6115323 www.geograph.co.za
===

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3455 - Release Date: 02/20/11
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev