[gdal-dev] Gdal and solaris compile question
Hello, I was wondering if I should include all of the binary files in my LD_LIBRARY path. For example, the .a files, or the .la files? Or should I just include the .so files? I also noticed that there are soft links to libgdal.so-libgdal.so.1.14.3 should I include the soft links too? The same question for the swig directory, which also has .lo and .o files in it. Much appreciated Thanks, George ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How files are handled in OGR / GDAL
Hello List, I could probably figure it out from the source, but I would apprecaite if someone could point me in the right direction. The question is: does GDAL / OGR loads the file in the memory when it opens in or it just keeps reference to the actual file Say if I open it, process it etc hDS =OGROpen http://www.gdal.org/ogr/ogr__api_8h.html#123bb02ac8c5cfe143e132f627531125(point.shp, FALSE, NULL ); and then do (without closing) poLayer-ResetReading http://www.gdal.org/ogr/classOGRLayer.html#ad0f2cd7f0587584b8f382c6a913583c(); and process again would it actually trigger re-reading file from the disk or not? In other words does OGR creates complete memory image for the file or just reads actual file when it needs something? Thank you Mikhail html body FONT face= Arial size= -1 PLEASE NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any dissemination, distribution or copy of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Information provided via electronic media is not guaranteed against defects including translation and transmission errors. The company accepts no liability for any damage caused by any virus transmitted by this email. Geometrics Inc. 2190 Fortune Drive San Jose, CA 95131 USA /FONT /body /html___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How files are handled in OGR / GDAL
On 11-03-01 12:29 PM, Mikhail Tchernychev wrote: Hello List, I could probably figure it out from the source, but I would apprecaite if someone could point me in the right direction. The question is: does GDAL / OGR loads the file in the memory when it opens in or it just keeps reference to the actual file Say if I open it, process it etc hDS =OGROpen http://www.gdal.org/ogr/ogr__api_8h.html#123bb02ac8c5cfe143e132f627531125(point.shp, FALSE, NULL ); and then do (without closing) poLayer-ResetReading http://www.gdal.org/ogr/classOGRLayer.html#ad0f2cd7f0587584b8f382c6a913583c(); and process again would it actually trigger re-reading file from the disk or not? In other words does OGR creates complete memory image for the file or just reads actual file when it needs something? Mikhail, These is driver dependent. But we try to avoid holding too much of the underlying file in memory. In the case of the shapefile driver the .shx index contents are loaded into RAM and kept there but the .shp and .dbf records are read as-needed. 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 Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] windows 7 64 bit
Hi We will start soon to move our product to 64 bit on windows 7, and I'm starting to check all of our dependencies. As far as I can see, gdal has a 64 bit version. Are there any issues specific to this version? Do the c# binding work without a problem? Thanks Yehiyam Livneh Sent from my mobile ** 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:law...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Mike,
Hello again,
I think I stumbled upon the part that was tripping up the methods I was
using with the php_osr.so library. Posted at http://pastebin.com/SXKKfe6v
is a patch that should work on both 1.8.0, and the trunk svn. It adds the
missing CSL typemap, and corrects the OGRErr related typemaps to ensure
that it only returns results for non-zero error responses.
I'm not sure if/when someone will act on this, but you should perhaps open a
GDAL Trac ticket and attach your patch there so it is kept in a safer place
than a pastebin that will be lost in a few days/weeks.
The patch also includes changes to the GNUmakefile in the swig/php folder
to make sure that the gdal libs are linked, and that all of the php
modules are compiles instead of just php_gdal.so (not sure if this is
fully necessary, but I was having trouble with linking before).
In addition to this, I had to substitute all instances of
'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with
'zend_error'...I don't know if this is just specific to my environment, but
the best I could determine from searching online is that more recent
versions of PHP no longer define zend_error_noreturn, yet swig still uses
it. It seems that zend_error is a sufficient substitute (without this, I
would find that when the module raised errors, it would cause a segfault
instead of actually producing a descriptive error in Apache/PHP).
Perhaps something to share with the swig mailing list ?
If this patch is applied and gdal is configured/compiled with the
'--with-php' option, then when swig/php/php_osr.so is installed and loaded
into the PHP environment, the following PHP script will work as expected:
?php
include(/path/to/gdal/swig/php/osr.php);
$sr = new SpatialReference();
$sr-ImportFromProj4('+init=epsg:4326');
echo $sr-ExportToProj4();
?
This is about as far as I can get for now - looking through typemaps_php.i,
I think I see plenty of stuff that still needs fixing/updating. There are
also function name conflicts if I try to load php_gdal.so and/or
php_ogr.so. I think that's out of my league, however. Hopefully this is
enough to peak the interest of someone who has a little more familarity
with c/swig/php, and we could get a more fully-supported set of PHP
bindings.
Best regards,
Mike
On Thursday, February 24, 2011 19:45:16 Mike Leahy wrote:
Hello all,
To keep this topic somewhat alive, I might note that I can identify that
at the very least, php_osr.so works in some ways, but not how I would
expect compared with the same bindings in other languages.
I also found that at least one typemap was needed in typemaps_php.i:
/* Almost same as %typemap(out) char **options */
/* but we CSLDestroy the char** pointer at the end */
%typemap(out) char **CSL
{
/* %typemap(out) char ** - ( string ) */
char **stringarray = $1;
if ( stringarray == NULL ) {
RETVAL_NULL();
}
else {
int len = CSLCount( stringarray );
array_init($result);
for ( int i = 0; i len; ++i, ++stringarray ) {
add_next_index_string( $result, *stringarray, 1 );
}
}
CSLDestroy($1);
}
This seems to have removed the warnings about that being missing when I
compile the osr library (I'm continuing to focus just on this binding as
a simple case).
In terms of actually using php_osr.so, I can successfully import a proj4
string, and export that to WKT using the '__str__' method:
?php
$sr = new_SpatialReference();
SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
echo SpatialReference___str__($sr);
?
I would expect that the last line would be equivalent to
SpatialReference_ExportToWkt($sr);, but that isn't the case...I'm still
getting zero, which I think stems from the fact that the data type for
the ExportToWkt (and similar functions) in osr.i is of the type
'OGRErr', and this is what is getting returned in PHP instead of the
desired wkt output.
I'm guessing that there's a difference in how swig interprets these
functions when compiling in PHP versus the other languages. In osr.i, I
added an extra declaration that mimics how the __str__ function works,
but returns proj4 strings. It looks like this:
%newobject ExportToProj4Test;
char *ExportToProj4Test() {
char *buf = 0;
OSRExportToProj4( self, buf );
return buf;
}
After compiling that, the following code will successfully return a Proj4
string:
?php
$sr = new_SpatialReference();
SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
echo SpatialReference_ExportToProj4Test($sr);
?
So...with this in mind, does this suggest that PHP will essentially need
an entirely rewritten list of functions? I would hope that there's a
more effective way to go about it this, and that I'm just looking at
this with my relatively
Re: [gdal-dev] windows 7 64 bit
On 11-03-01 2:42 PM, Livneh Yehiyam wrote: Hi We will start soon to move our product to 64 bit on windows 7, and I'm starting to check all of our dependencies. As far as I can see, gdal has a 64 bit version. Are there any issues specific to this version? Do the c# binding work without a problem? I have compiled and tested recently GDAL 1.8.0 and MapServer 5.6.6 on Windows x64 with C# mapscript, if that helps you. I can tell you that it is not an easy process to compile. If you need more information please contact me directly. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] windows 7 64 bit
Hi, I'm not aware of any issue related to x64 specifically. You can obtain compiled binaries from http://vbkto.dyndns.org/sdk/ (including the csharp bindings) Best regards, Tamas 2011/3/1 Livneh Yehiyam ye...@rafael.co.il Hi We will start soon to move our product to 64 bit on windows 7, and I'm starting to check all of our dependencies. As far as I can see, gdal has a 64 bit version. Are there any issues specific to this version? Do the c# binding work without a problem? Thanks Yehiyam Livneh Sent from my mobile -- * 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:law...@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@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] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N )
I am trying to convert a file in WGS format to Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), comman line input is C:\Program Files (x86)\FWTools2.4.7gdalwarp -t_srs EPSG:26912 G:\TestData\dem43m.tif G:\TestData\opt.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. I am giving above stated error. gdalinfo of the input file is given below Size is 1201, 1201 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 = (74.9995834,36.0004166) Pixel Size = (0.0008333,-0.0008333) Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 74.9995833, 36.0004167) ( 74d59'58.50E, 36d 0'1.50N) Lower Left ( 74.9995833, 34.9995833) ( 74d59'58.50E, 34d59'58.50N) Upper Right ( 76.0004167, 36.0004167) ( 76d 0'1.50E, 36d 0'1.50N) Lower Right ( 76.0004167, 34.9995833) ( 76d 0'1.50E, 34d59'58.50N) Center ( 75.500, 35.500) ( 75d30'0.00E, 35d30'0.00N) Band 1 Block=64x64 Type=Int16, ColorInterp=Gray Am i doing anything wrong? Thanks Sumit Pandey -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Conversion-from-WGS84-to-NAD83-EPSG-26912-NAD83-UTM-zone-12N-tp6078961p6078961.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
Re: [gdal-dev] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N )
Sumit, Looking at EPSG:26912 on spatial reference, http://spatialreference.org/ref/epsg/26912/ and your longitude coordinates (74-76 East, no less) makes it questionable if 26912 is an appropriate projection. That projection looks valid for western Mexico, and midwestern US/CA. You data looks to be roughly in Asia. I think that error says that it is not in a valid area of the target projection. Bests, Eli On 3/1/2011 at 2:28 PM, in message 1299018481319-6078961.p...@n2.nabble.com, Delirious sumitpande...@gmail.com wrote: I am trying to convert a file in WGS format to Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), comman line input is C:\Program Files (x86)\FWTools2.4.7gdalwarp -t_srs EPSG:26912 G:\TestData\dem43m.tif G:\TestData\opt.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. I am giving above stated error. gdalinfo of the input file is given below Size is 1201, 1201 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 = (74.9995834,36.0004166) Pixel Size = (0.0008333,-0.0008333) Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 74.9995833, 36.0004167) ( 74d59'58.50E, 36d 0'1.50N) Lower Left ( 74.9995833, 34.9995833) ( 74d59'58.50E, 34d59'58.50N) Upper Right ( 76.0004167, 36.0004167) ( 76d 0'1.50E, 36d 0'1.50N) Lower Right ( 76.0004167, 34.9995833) ( 76d 0'1.50E, 34d59'58.50N) Center ( 75.500, 35.500) ( 75d30'0.00E, 35d30'0.00N) Band 1 Block=64x64 Type=Int16, ColorInterp=Gray Am i doing anything wrong? Thanks Sumit Pandey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N )
Thanks adam, I am novice to this field. So my question might seem trivial or vague - Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors might be high, but it should be convertible. If i want to convert this data in NAD83 datum and UTM projection what should i do? Cheers Sumit Pandey -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Conversion-from-WGS84-to-NAD83-EPSG-26912-NAD83-UTM-zone-12N-tp6078961p6079096.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] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 /UTMzone 12N )
Sumit, There are a lot of NAD83 UTM projection zones. You need to chose the proper one. Without learning a fair amount about datums, projections, and the area where you are working, you may be best looking on wikipedia and spatial reference to guess a UTM zone that matches your general area. NAD83 is the North American Datum of 1983, you may want a different datum for your area. A rough guess that may be a decent starting place might be WGS84 UTM 45N. Datums, projections, etc are incredibly complex. USGS gives an overview here, http://egsc.usgs.gov/isb/pubs/MapProjections/projections.html I don't have any advice for any easy or quick way to select a proper datum and projection. If you know someone working with similar data in the same area, ask them. You may be best leaving the data in EPSG:4326, I don't know. HTH, Eli On 3/1/2011 at 3:21 PM, in message 1299021669799-6079096.p...@n2.nabble.com, Delirious sumitpande...@gmail.com wrote: Thanks adam, I am novice to this field. So my question might seem trivial or vague - Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors might be high, but it should be convertible. If i want to convert this data in NAD83 datum and UTM projection what should i do? Cheers Sumit Pandey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Even/all,
As you recommended, I've created a ticket for this
(http://trac.osgeo.org/gdal/ticket/3984). I was able to resolve the function
name conflicts (I think) that were blocking the gdal/ogr modules. After this,
I find that I can get some partial functionality out of the php_ogr.so
module...though some functions will also produce segfaults. However,
php_gdal.so causes PHP to segfault immediately on startup if the module is
loaded. I've posted some debug info in the ticket...I think it's something
to do with null pointers, which I'm guessing may need to be accounted for in
some way through the php typemaps.
Regards,
Mike
Date: Tue, 1 Mar 2011 19:59:48 +0100
From: Even Rouault even.roua...@mines-paris.org
Subject: Re: [gdal-dev] Re: PHP bindings
To: gdal-dev@lists.osgeo.org, mgle...@alumni.uwaterloo.ca
Message-ID: 201103011959.48700.even.roua...@mines-paris.org
Content-Type: Text/Plain; charset=utf-8
Mike,
Hello again,
I think I stumbled upon the part that was tripping up the methods I was
using with the php_osr.so library. Posted at
http://pastebin.com/SXKKfe6v is a patch that should work on both 1.8.0,
and the trunk svn. It adds the missing CSL typemap, and corrects the
OGRErr related typemaps to ensure that it only returns results for
non-zero error responses.
I'm not sure if/when someone will act on this, but you should perhaps open
a GDAL Trac ticket and attach your patch there so it is kept in a safer
place than a pastebin that will be lost in a few days/weeks.
The patch also includes changes to the GNUmakefile in the swig/php folder
to make sure that the gdal libs are linked, and that all of the php
modules are compiles instead of just php_gdal.so (not sure if this is
fully necessary, but I was having trouble with linking before).
In addition to this, I had to substitute all instances of
'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with
'zend_error'...I don't know if this is just specific to my environment,
but the best I could determine from searching online is that more recent
versions of PHP no longer define zend_error_noreturn, yet swig still
uses it. It seems that zend_error is a sufficient substitute (without
this, I would find that when the module raised errors, it would cause a
segfault instead of actually producing a descriptive error in
Apache/PHP).
Perhaps something to share with the swig mailing list ?
If this patch is applied and gdal is configured/compiled with the
'--with-php' option, then when swig/php/php_osr.so is installed and
loaded into the PHP environment, the following PHP script will work as
expected:
?php
include(/path/to/gdal/swig/php/osr.php);
$sr = new SpatialReference();
$sr-ImportFromProj4('+init=epsg:4326');
echo $sr-ExportToProj4();
?
This is about as far as I can get for now - looking through
typemaps_php.i, I think I see plenty of stuff that still needs
fixing/updating. There are also function name conflicts if I try to
load php_gdal.so and/or php_ogr.so. I think that's out of my league,
however. Hopefully this is enough to peak the interest of someone who
has a little more familarity with c/swig/php, and we could get a more
fully-supported set of PHP bindings.
Best regards,
Mike
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
