gmane.comp.gis.gdal.devel

MapInfo Geometry Precision Issues

Murali Krishna — 2012-05-26T03:54:41

I'm trying to create a MapInfo file using gdal ogr java bindings (version
1.9.0) with some point geometries.
However the geometries in the created MapInfo file doesn't actually match
with the values which i have used in creation.

For example, I create a MapInfo feature with a point geometry and with the
following coordinates:
X = 196153.123
Y= 272453.6789

When i read the same feature back, GDAL gives the following as coordinates
for the same feature:
X = 196153.12630125193
Y = 272453.67830354505

Any reason why MapInfo driver changes these coordinates?

Thanks in advance
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Heads-up re: poppler/pdf on Windows

Jeff McKenna — 2012-05-25T13:40:06

Hopefully this helps someone else down the road...

- the latest version of Poppler that I am able to get working with GDAL
(1.9.1 now) on MSVC (2008) is 0.16.4
- 0.20.0 or git master gives errors
- example of errors: http://pastebin.com/4YSnSJkn

So, stick with 0.16.4 and save yourself a day of testing newer versions.

Have a good weekend everyone.

-jeff

georeference and project a jpeg

jdmorgan — 2012-05-25T01:47:24

Hello,

I am attempting to georeference and project a jpeg image using only gdal 
tool.I have georeferenced the jpeg using the following command:

gdal_translate -a_srs EPSG:102719-of HFA -gcp 0.0 0.0 -82.5586187839508 
35.59414007259327 -gcp 0.0 410.0 -82.55858659744263 35.5937998255945 
-gcp 520.0 0.0 -82.55741715431213 35.594340730401775 -gcp 520.0 410.0 
-82.55728840827942 35.5940266570877NCDCLogo.jpg NCDCLogo.img

The command run fine and produces a img file however it does not line up 
with similarly project layer per the gcp's.When I check the projection 
information the file shows to be unprojected. Further, when I attempt to 
project the resulting raster with gdalwarp I get the following errors:

"There is no affine transformation and no GCPs."

Any pointers here would be greatly appreciated.

Thanks,

Derek

_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

memory leak in GRIB reader (with Python bindings)

Chris Barker — 2012-05-24T19:55:15

Hi folks,

I"m finding what appears to be a memory leak, using the GRIB reader,
with the python bindings.

What I'm trying to do is read the data one band at a time, then throw
it away and read the next band -- there are 1129 bands in the file at
hand, and I can't hold it all in memory (32 bit still...)

However, when I do this, memory use just keeps climbing.

Should the memory be freed? I would expect so.

I'm using RasterBand.ReadAsArray()

Is this a leak? or is supposed to keep it around in memory?

Either way, is there a way to force it to release that memory (I"m
already doing and exlicite del and gc.collect call, so I dont think
it's a python reference counting issue)

I've enclosed a simpel test script -- watch the memory climb.

The data file is to big (186MB) to enclose here, you can get it here:

http://nomads.ncep.noaa.gov/pub/data/nccf/com/cfs/prod/cfs/cfs.20120522/18/time_grib_01/ocnu5.01.2012052218.daily.grb2

If you want to give this a try.


(note -- Grib giving some pretty good compression -- this climbs to
2.3GB when I read it)

I could actually live with the 2.3GB -- but in my real use case, I'm
reading two of these at the same time, so I max out what I can do with
32 bit python...

GDAL 1.8.1
Python 2.7 (32 bit Intel)
OS-X 10.6
I think it's the Kyng Chaos build of GDAL.

Thanks,
   -Chris

libKml driver in 64 bit

Livneh Yehiyam — 2012-05-24T11:28:49

Hi
Has anyone managed to build the libKML driver win 64 bit for windows 7?
I'm having problems getting all of the third-parties compiled.

Thanks
Yehiyam Livneh

**********************************************************************************************
This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. 
(hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may 
constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not 
the intended recipient, you should contact us immediately and thereafter delete this message from your 
system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this 
message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, 
please notify us immediately by e-mail mailto:lawraf< at >rafael.co.il and completely delete or destroy any and all 
electronic or other copies of the original message and any attachments thereof.
**********************************************************************************************_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

ogr2ogr shapefile to mapinfo tab: no SRS.

Frans Knibbe | Geodan — 2012-05-24T11:05:47

Hello,

I wonder if someone can help me with a nasty problem with using ogr2ogr 
to convert shapefile to Mapinfo tab format. Whatever I try, I can not 
get the output to have a correct definition of the SRS. Ogrinfo always 
reports the output having a NonEarth SRS.

The input shapefile has a *.prj file. It seems to be ignored by ogr2ogr. 
Using the -a_srs option to specify the SRS, either as an EPSG code or as 
the name of a file containing the WKT of the projection also fails.

I have tested this with several versions of ogr2ogr. I do not notice any 
difference between versions. The latest version of ogr2ogr that I could 
find is "GDAL 2.0dev, released 2011/12/29".

A web search on this subject leads to several similar problem 
descriptions, but I have not been able to find a solution or even a 
workaround.

Regards,
Frans

GDAL/OGR 1.9.1 Released

Frank Warmerdam — 2012-05-22T21:18:01

On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.9.1 bug fix release.  This
release contains many bug fixes since the December 1.9.0 release.

The source is available at:

  http://download.osgeo.org/gdal/gdal191.zip
  http://download.osgeo.org/gdal/gdal-1.9.1.tar.gz

Details on the the fixes in this release are available at:
  http://trac.osgeo.org/gdal/wiki/Release/1.9.1-News

Best regards,

troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Margherita Di Leo — 2012-05-22T19:01:26

Hi folks,

looks like this bug ticket [1] finds its roots into the gdal code. From a
discussion [2] in the gfoss.it [3] ML (the italian OSGeo local chapter)
emerged that gdal 1.8.0 introduced a further option named
OVERRIDE_PROJ_DATUM_WITH_TOWGS84, allowing to replace the +datum definition
with a corresponding +towgs84.
Such option is not supposed to be the default behavior when generating the
standard EPSG file for Proj4:

epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 -skip
-list gcs.csv > epsg

Anyway, from direct testing emerged that setting the above mentioned option
to YES, NO, TRUE or FALSE has absolutely no effect at all; the +datum
definitions are unconditionally overwritten by +towgs84 in all cases. And,
accordindgly to this, the EPSG file distributed by the most recent Proj4
4.8.0 introduces many unexpected changes (e.g. affecting the Italian Rome
1940 SRS), thus causing many troubles due to this abrupt compatibility
break.

Could anyone please verify that, and, in case, I'll open a ticket.
Thanks!

madi


[1] http://trac.osgeo.org/proj/ticket/122
[2] http://lists.gfoss.it/pipermail/gfoss/2012-May/023071.html
[3] www.gfoss.it

SV: Microsoft VS 2010 - build of GDAL 1.9 does not work

James Farrell — 2012-05-21T14:41:37

Not sure I'm doing this correctly, I don't see how to respond to a particular thread in this forum...

I'm wrestling with the same problem as the thread in the subject line:
error LNK2019: unresolved external symbol "public: int __thiscall CPLStringList::Count(void)const "

GDAL itself builds perfectly when I build according to the instructions.  Then I attempt to build one of our projects that uses cpl_string.h and .cpp, and when I attempt to link I get the above error.

I've looked at cpl_string.h and found a class declaration for CPLStringList that was not there in the previous version we used (we skipped a few versions).  Within the class declaration is
...
  public:
    CPLStringList();
    CPLStringList( char **papszList, int bTakeOwnership=TRUE );
    CPLStringList( const CPLStringList& oOther );
    ~CPLStringList();

    CPLStringList &Clear();

    int    size() const { return Count(); }
    int    Count() const;
...

I cannot find a definition for Count() anywhere.

We are not using CPLStringList in our code, but there is other code within GDAL that uses it.  Are we supposed to make our own Count() function?  Where is this supposed to live?

Thanks
James Farrell
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Policy for C/C++ API for GDAL 2.0 ?

Even Rouault — 2012-05-20T17:23:08

Hi GDAL developers and users (actually, developers of other projects using 
GDAL ;-)),

This issue was raised incidently in the "[gdal-dev] VRTComplexSource with a 
LUT, proposal" thread at http://lists.osgeo.org/pipermail/gdal-dev/2012-
May/032872.html . 

I think it is good time to discuss now what we want to allow, or not, for GDAL 
2.0, as far as the C/C++ API is concerned.

---------
C API
---------

Up to now, the signature of functions added in the GDAL/OGR C API has never 
changed, once they have been added.

What should be the rule for GDAL 2.0 ?

1) do not change the signature of any function already present in the C API. 
If breaking changes are necessary, then introduce "FooEx", or "Foo2" versions 
of those functions as done in the past. The drawback of that approach is that 
the API becomes cluttered.

2) do not change the signature of any commonly used functions, but allow 
changes in marginally used functions. The definition of commonly functions 
w.r.t marginally used ones is a bit arbitrary. Looking at the symbols used by 
popular Open Source software using GDAL C API could give a clue in case of 
doubt (MapServer, QGIS, GRASS, PostGIS, or in-tree GDAL utilities using C API  
...). 

3) allow changes even in commonly used functions.

Options 2) or 3) would likely require other projects to have #if GDAL_VERSION 
they plan to update their dependency requirements when they release a newer 
version of their project (Project XX version < 1.Y depends on GDAL < 2.0. 
Version >= 1.Y depends on GDAL >= 2.0).

-------------
C++ API
-------------

As far as the C++ API is concerned, the policy up to now was that minor 
changes between GDAL 1.X version and GDAL 1.(X+1) were OK. Generally, the 
changes have been the addition of new optional arguments, that only required 
recompilation to solve the change of ABI, but did not require code changes.

For GDAL 2.0, I believe that most major changes could occur, especially if the 
OGR "grand unification" occurs, but for now, I don't know the impact that that 
might cause.

-------------------------------------------------
Syntax of command line utilities
-------------------------------------------------

A bit out of topic, since it is about UI and not API. But a lot of scripts in 
the wild call popular GDAL command line utilities. Changes in their syntax 
would cause potentially more headaches, given the larger number of users 
w.r.t. developers using GDAL ;-) The page at 
http://trac.osgeo.org/gdal/wiki/GDAL20Changes lists a few changes that have 
been proposed (just as a reminder : nothing listed there is officially vetted).

The same question also arise with the API of the various bindings languages.

Feedback welcome !

Best regards,

Even

Java gdal.jar in mvn repo?

Billy Newman — 2012-05-20T15:40:46

Is the java bindings jar and hopefully javadoc jar in a mvn repo somewhere?

Thanks 

Sent from my iPhone

Java binding gdal.AutoCreateWarpedVRT question

Billy Newman — 2012-05-20T01:09:27

When get a Dataset Object back from the gdal.AutoCreateWarpedVRT(dataset)
call do I need to call delete on the warped dataset and the original
dataset, or just the original when I am done using the warped dataset?
Sorry I did not understand the javadocs.

Ex

Dataset origDataset= gdal.Open("imagefile.ntf");
Dataset warpedDataset = gdal.AutoCreateWarpedVRT(origDataset, wkt);

// do some stuff with the wrapped dataset
// .....

//should i delete both?
origDataset.delete();
warpedDataset.delete();

Thanks!
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

VRTComplexSource with a LUT, proposal

Saâd HESSANE — 2012-05-19T14:58:07

Hi,

In wanting to add programmatically a LUT to a VRTComplexSource, I read the
VRT driver source code.
VRTComplexSource have three public attributes : *double
*padfLUTInputs*, *double
*padfLUTOutputs* and *int nLUTItemCount.*
*
*
To set the LUT we have to affect directly two pointers and set the number
of elements. There's no other method to set the LUT.
Maybe in other langage like Python it can be useful. But in C++, I think
it's wrong for encapsulation.

But the worst think in my opinion is the VRTComplexSource destructor :

VRTComplexSource::~VRTComplexSource()


The destructor frees the two pointer. This can be an issue if I do that :


double padfLUTOutputs[] = {4,5,6};

complexSource->padfLUTInputs = padfLUTInputs


And what happens if I want to change the LUT?

I suggest to add a method VRTComplexSource::setLUT (const double *, const
double *, int), and to make the public attributes protected.
The setLUT method frees the pointers, and clones the tables.

Best regards
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Roadmap to 2.0?

Ari Jolma — 2012-05-18T17:35:58

Folks,

The deadline for 2.0 is at the end of this year: 
http://trac.osgeo.org/gdal/milestone/2.0.0

Is the RFC list the best source for what new features are planned for it?

This page is about smaller issues for 2.0: 
http://trac.osgeo.org/gdal/wiki/GDAL20Changes

I have an old wish to have full XYZM support in GDAL and it would be a 
good candidate to the plan for 2.0 - see also 
http://www.mail-archive.com/gdal-dev< at >lists.osgeo.org/msg13470.html
Is anybody doing a review of what it would take?

Best regards,

Ari

Reprojecting a tiled dataset

Oyvind Idland — 2012-05-18T08:34:08

Hello,

i have a set of GeoTIFF tiles, that I want to reproject into a new set of
tiles.

So far I have the following strategy:
1) create a VRT from the existing tiles
2) make a script that creates new tiles, one by one using gdalwarp.


Is there a better way of doing this ?


- Oyvind
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

VRT with attribute filter?

Tyler Mitchell — 2012-05-18T05:12:03

I've done my best to comb through the code but can't see how to use an attribute filter in a (OGR) VRT definition.  Yet, I see an old ticket from Bart that was asking for it and seemed to be implemented.  Or am I reading too much into this?  Any one using it?

http://trac.osgeo.org/gdal/ticket/900

Tyler

Motion: Promote GDAL 1.9.1RC2 to Final Release

Frank Warmerdam — 2012-05-17T20:36:36

Motion: The GDAL/OGR 1.9.1RC2 release candidate is hearby
declared the final GDAL/OGR 1.9.1 release.

--

+1 Frank

JPEG 2000 layers GDAL

Jayesh Chaudhary — 2012-05-17T18:04:30

Folks,

I have written a GDAl based reader and I am trying to read JPEG 2000
images. When I ran gdalinfo on one of the samples images from here:
http://www.openjpeg.org/index.php?menu=samples, it does not list subdataset
or overviews ( I was expecting overviews ).

I am wondering what I am missing.  It would be nice if someone can provide
some input on this.

Thanks
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Effeciency of "ReadRaster" in different storage format of mulit-band image

hitweiran — 2012-05-17T07:01:32

Hello, everyone.
There are two methods to extract data from a mulit-band remote sensing image
in GDAL.
1. Dataset.ReadRatser, that can read all data in mulit-band image.
2. Band.ReadRaster, that can read only one band of mulit-band image.
Actually, there are three formats used to storage mulit-band image, BIL
(Band Interleaved by Line format),BIP(Band Interleaved by Pixel format) and
BSQ(Band Sequential format).  
Based on my test , the runtime of read whole mulit-band data is quite
sensitive to the format of mulit-band image.
For example, when I used "Band.ReadRatser" to read mulit-band image band by
band. The total runtime is 285.93s, 13.48s and 19.51s for BIL, BSQ and BIP
respectively; (the size of image: width*height*bands=501*1004*125). BSQ
formate is the most effective.  However, the actual data can be storaged in
any format, so,how can I solve this problem? 

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Effeciency-of-ReadRaster-in-different-storage-format-of-mulit-band-image-tp4975285.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.

GDAL/OGR 1.9.1RC2 Available to Test

Frank Warmerdam — 2012-05-17T03:38:21

Folks,

I have corrected two issues Even identified in RC1 and produced a new
release candidate for the 1.9.1 release.  They were:

 * Perl bindings version info now updated for 1.9.1
 * tiff_srs.py - EPSG:2066 test failed.

Get the code at:

  http://download.osgeo.org/gdal/gdal-1.9.1RC2.tar.gz
  http://download.osgeo.org/gdal/gdal191RC2.zip

I'll make a motion to adopt this as 1.9.1 fairly soon if it looks
promising.

Best regards,

Can OGR WFS driver take advantage of WFS Serverstreaming?

Yingqi Tang — 2012-05-16T21:58:29

Hi all,

I am communicating against a WFS server which supports data (GML)
streaming, which means that once I send a GetFeature quest for a big GML
(2.0GB+), server will take only seconds to start streaming GML back to
client while at the same time it's still preparing the rest of the big GML.

Now I wonder if GDAL/OGR WFS client can take advantage of that? Will I be
able to access the first few features while the streaming is still going
on? It seems to me that it doesn't because it always waiting the whole big
GML response is loaded in memory.

Thanks
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev