Re: [gdal-dev] Issue with SetConfigOption
What is the exception message specifically? Best regards, Tamas 2012/3/19 Pouliot, Christopher (DNR) christopher.poul...@state.mn.us Hello, The App I'm using GDAL in is a C# (Visual Studio 2010, .NET 4.0) executable and is distributed to a couple thousand people. For 95% of those people it is running great. For the other 5% we're having trouble with the GDAL piece. The error we get: The type initialize for 'OSGEO.GDAL.GdalPINVOKE' threw an exception I've narrowed it down and it occurs the very first command I try using GDAL: OSGeo.GDAL.Gdal.SetConfigOption(GDAL_DATA, GDAL_DATA); I've read in previous threads that it may be related to needing the proper Microsoft Visual C++ Redistributables installed but we've got machines that have 2005, 2008, and 2010 redistributables installed and still no luck. I've also included the msvcp100.dll and msvcr100.dll files in my install package. I think we have the problem narrowed down to older machines running XP or Vista. Beyond that I'm not sure. Does anyone know of other dependencies I should be trying? Thanks, Chris Chris Pouliot GIS Application Developer Minnesota Department of Natural Resources christopher.poul...@state.mn.us (651) 259-5491 ___ 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] Re: Mapinfo driver does not recognise certain datums properly
Hi Devs, Got no answer, so I call up this thread for discussion again. In fact the approach of identifying datums by the mapinfo driver (by using the WKT name) is quite fragile causing problems for me and for others in the past as well, for example with the issues described in: http://trac.osgeo.org/gdal/ticket/481 http://trac.osgeo.org/gdal/ticket/3187 In 3187 the problem was attempted to be solved by extending the lookup table by using multiple entries for the same datum having different names. However this approach is quite insufficient since there's no official list of the valid WKT datum names (which may also be vendor specific) and the datum names are also altered by gdal ie. by replacing spaces with underscores. The patchhttp://trac.osgeo.org/gdal/attachment/ticket/481/gdal-mitab-datum-2.patchattached to #481 http://trac.osgeo.org/gdal/ticket/481 looks more compelling to me as it seems more trivial to identify the datums by EPSG code (where exists) and not only by the datum name. Any objections to apply such change in gdal (mitab) at last? Best regards, Tamas 2012/3/15 Tamas Szekeres szeker...@gmail.com Hi Devs, I have run into a problem when assigning a spatial reference to a mapinfo file using ogr2ogr when using -a_srs EPSG:28350. The mapinfo driver doesn't seem to recognise the datum (Geocentric_Datum_of_Australia_1994) and assigns WGS84 to the output file which is a fairly inconvenient approach. This problem is due to the incorrect entries in asDatumInfoList (mitab_spatialref.cpp) since the entry for Geocentric_Datum_of_Australia_1994 is missing, though it contains an entry for the projection name GDA94 (and not for the datum name). As far as I know the WKT datum names are vendor specific, therefore it's not quite sufficient to use as a lookop key for the datum entries. But if we use this approach even so, why don't we include the datum names from gcs.csv for being compatible with the projections constructed by GDAL itself? Would that be reasonable to add multiple entries in asDatumInfoList or placing this information in an external file? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Mapinfo driver does not recognise certain datums properly
Hi Devs, I have run into a problem when assigning a spatial reference to a mapinfo file using ogr2ogr when using -a_srs EPSG:28350. The mapinfo driver doesn't seem to recognise the datum (Geocentric_Datum_of_Australia_1994) and assigns WGS84 to the output file which is a fairly inconvenient approach. This problem is due to the incorrect entries in asDatumInfoList (mitab_spatialref.cpp) since the entry for Geocentric_Datum_of_Australia_1994 is missing, though it contains an entry for the projection name GDA94 (and not for the datum name). As far as I know the WKT datum names are vendor specific, therefore it's not quite sufficient to use as a lookop key for the datum entries. But if we use this approach even so, why don't we include the datum names from gcs.csv for being compatible with the projections constructed by GDAL itself? Would that be reasonable to add multiple entries in asDatumInfoList or placing this information in an external file? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion:Commit rights for David Zwarg
+1 Tamas 2012/3/13 Jorge Arevalo jorgearev...@libregis.org Motion: GDAL/OGR Commit rights are extended to David Zwarg Hello, David Zwarg has been working over the last few weeks in submitting patches to improve and fix the PostGIS Raster driver. I have integrated them until now, but I think it would be easier to give him commit access. David is a committer to PostGIS, and have been working with the Raster developers for a couple years. He has commit access to an OpenLayers sandbox, and is the author of the ArcIMS Layer and ArcXML Format, which are now in the OpenLayers core. In addition, he has contributed patches to fix bugs in OpenLayers via trac. His company also develops some Open Source geoprocessing platforms, like GeoTrellis: https://github.com/azavea/geotrellis I think he's doing an excellent job with the PostGIS Raster driver. So, he has my complete support +1 -- Jorge Arevalo http://www.libregis.org ___ 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
Re: [gdal-dev] HDF4 support for gdal 1.8
If you have a compiled version of the HDF4 libraries, you could probably use the SDK from gisinternals http://www.gisinternals.com/sdk/ to include that in the build (Makefile should be edited). I have never tried it by myself, but I'll give it a try as my time permits. Best regards, Tamas 2012/2/1 singnage sing...@gmail.com I recently installed GDAL 1.8.1 from gisinternals.com/sdk on Windows 7, I was previously using 1.6 from FW Tools, this newer version does not support HDF4 but supports HDF5, can anyone point how can I install the HDF4 support for version 1.8.1. thanks NS -- View this message in context: http://osgeo-org.1560.n6.nabble.com/HDF4-support-for-gdal-1-8-tp4356589p4356589.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Rights for Robert Coup
+1 Tamas 2012/2/1 Even Rouault even.roua...@mines-paris.org Motion: GDAL/OGR Commit rights are extended to Robert Coup --- Folks, Robert Coup has been working over the last few weeks in submitting patches to improve and fix the new FileGDB driver. I have integrated them until now, but I think it would make the process smoother to give him commit access. Robert is testing with ESRI software such as ArcMap, which should help making sure output datasources produced by the FileGDB driver are interoperable with other software. Robert is a core committer on Mapnik and a committer on Dojo. He has also been a GSoC mentor for Mapnik Dojo over the last few years Robert, could you publically reply to this message indicating your willingness to follow RFC3? http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with my support. +1 Even ___ 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
Re: [gdal-dev] Motion: Commit Rights for Dmitry Barishnikov (aka bishop)
+1 Tamas 2012/1/24 Frank Warmerdam warmer...@pobox.com Motion: GDAL/OGR Commit rights are extended to Dmitry Barishnikov /Дмитрий Барышников (userid: bishop). --- Folks, Dmitry has been providing patches for GDAL/OGR for several years now and has, in my opinion, demonstrated good understanding of the GDAL code base, and norms. I think it would be helpful for him to have commit access. You can see some of his past contributions at: http://trac.osgeo.org/gdal/search?q=bishop Dmitry, could you publically reply to this message indicating your willingness to follow RFC3? http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with my support. +1 Frank -- ---+-- 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 Software Developer ___ 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
Re: [gdal-dev] Loading data in MSSQL using ogr2ogr
Jeremy,
This seems to be a reasonable requirement. You should create a ticket for
this issue at:
http://trac.osgeo.org/gdal/newticket
Best regards,
Tamas
2012/1/12 Jeremy Palmer jpal...@linz.govt.nz
Hi,
I'm trying to load a CSV file into an existing MSSQL 2008 table using
ogr2ogr:
ogr2ogr -preserve_fid --debug on -append -skip
failures -f MSSQLSpatial MSSQL:server=\SQL_SERVER_2008;Integrated
Security=true;database=;tables=test_csv_table_1(shape) test1.vrt -nln
test_csv
_table_1 -s_srs epsg:4167
The schema I've got is:
CREATE TABLE [dbo].[test_csv_table_1](
[id] [int] NOT NULL,
[appellation] [text] NULL,
[affected_surveys] [text] NULL,
[parcel_intent] [text] NOT NULL,
[topology_type] [varchar](100) NOT NULL,
[statutory_actions] [text] NULL,
[land_district] [varchar](100) NOT NULL,
[titles] [text] NULL,
[survey_area] [numeric](20, 4) NULL,
[calc_area] [numeric](20, 4) NOT NULL,
[shape] [geometry] NULL,
PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
This currently fails. The reason being that the SQL generated by ogr2ogr
is:
SET IDENTITY_INSERT [dbo].[test_csv_table_1] ON;
INSERT INTO [dbo].[test_csv_table_1] (shape, [id], [appellation],
[affected_surveys], [parcel_intent], [topology_type], [statutory_actions],
[land_district], [titles], [survey_area], [calc_area]) VALUES
(geometry::STGeomFromText('POLYGON ((172.7825528
-41.4211097333,172.78229796670001 -41.42127,172.7823694333
-41.4212575333,172.7825528 -41.4211097333))',4167).MakeValid(), 3621203,
'Sec 8 SO 14436', 'SO 14436', 'DCDB', 'Primary', '[Referenced] Stopped Road
to be Amalgamated [Tadmor Valley Road, Nelson] New Zealand Gazette 2009 p
186 Stopped and Amalgamated with Land in CT NL72/70', 'Nelson', '464435',
50., 38.3921);SET IDENTITY_INSERT
[dbo].[test_csv_table_1] OFF;
The issue can be resolved if I change my table schema so the id field is
an identity column, but I don't want to do this.
Is it possible to configure (or fix a bug) so the SET IDENTITY_INSERT
SQL is not executed if the -preserve_fid option is used and the existing
table does not have an identity field?
Cheers,
Jeremy
#
This message contains information, which is confidential and may be
subject to legal privilege.
If you are not the intended recipient, you must not peruse, use,
disseminate, distribute or copy this message.
If you have received this message in error, please notify us immediately
(Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original
message.
LINZ accepts no responsibility for changes to this email, or for any
attachments, after its transmission from LINZ.
Thank You.
#
___
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
Re: [gdal-dev] Motion: Promote GDAL 1.9.0RC1 as GDAL 1.9.0 Final
GDAL autotests are looking good on Win64. Futher tests are welcome. Best regards, Tamas 2012/1/2 Etienne Tourigny etourigny@gmail.com What is the status of Windows 32-bit and 64-bit ? Have they been tested outside of Tamas' build bot? best wishes for 2012, Etienne On Sun, Jan 1, 2012 at 1:30 PM, Even Rouault even.roua...@mines-paris.org wrote: Le dimanche 01 janvier 2012 02:38:00, Frank Warmerdam a écrit : Motion: To promote the GDAL/OGR 1.9.0RC1 release candidate as the final GDAL/OGR 1.9.0 release. I've managed to compile it (or the betas) on a variety of Unixes (CentOS 6.2, Ubuntu 11.10, FreeBSD 8.0, NetBSD 5, OpenBSD 4.5, Solaris 10 and 11, Debian Lenny on a big-endian host) and things seem to be in good shape. Has anyone tested on MacOS X ? The only regression I've found so far is in the Rasterlite driver ( fixed in http://trac.osgeo.org/gdal/ticket/4413 ). It was hidden by another problem in the lastest libspatialite3.0.0 that was exhibited by the GDAL autotests. But I don't think it justifies another RC per se. *Last minute* : I've just tested with CentOS 4.7 and CentOS 5.6 and I've found a compilation problem with the sqlite driver (and in the GML driver when sqlite3 support is available). Those 2 OS ship with sqlite 3.3.6, but we now use various methods that weren't yet available. This is now fixed in trunk and 1.9 branch (see http://trac.osgeo.org/gdal/ticket/4418 for details ). Not sure if it is worth a RC2. Best regards, Even ___ 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Authorize Islandwood Funding for Brian Case
+1 Tamas 2011/12/14 Frank Warmerdam warmer...@pobox.com Motion: The GDAL PSC authorizes funding up to US$525 to pay entrance fees to the Islandwood Code Sprint for Brian Case. - Brian (aka winkey) has done lots of work in recent years on and with GDAL/OGR. Most notably he has developed the libkml based OGR KML driver. Brian lives relatively near the Islandwood sprint and would arrange to get himself there and other ancillary costs. We would just be paying the entrace fees (which also implicitly covers housing and food). Information on the Islandwood Sprint (successor to the Toronto, NYC and Montreal sprints of recent years) is available at: http://wiki.osgeo.org/wiki/**IslandWood_Code_Sprint_2012http://wiki.osgeo.org/wiki/IslandWood_Code_Sprint_2012 I'm afraid I haven't done a detailed financial review of GDAL/OGR project funds but I think we have in excess of $10K in reserve so this is a modest expenditure, and I think can serve the community building goals of the project well. I think we should also be open to similar support for other substantial contributors to GDAL/OGR who don't have corporate travel support, who would like to attend the sprint, and who would be able to get themselves there. However, that is not explicitly covered by this motion. -- I'll start with +1 Frank. PS. I'd love to make a new batch of GDAL project tshirts in the coming year if someone is up to organizing. Best regards, -- --**-+** -- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/warmerda and watch the world go round - Rush| Geospatial Software Developer __**_ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/gdal-devhttp://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] NuGet package for GDAL C# bindings
Felix, Not sure I clearly understand the benefit, though it may be due to my lack of knowledge in NuGet. Is this just another way how to deploy the compiled binaries or something to be incorporated in the GDAL build process? Best regards, Tamas 2011/11/3 Felix Obermaier o...@ivv-aachen.de Hello, are there any plans to supply a NuGet (www.nuget.org) package for the C# Bindings? Or is there an interest in me setting one up? Thanks Felix Obermaier -- Ingenieurgruppe IVV GmbH Co. KG Dipl.-Ing. Felix Obermaier Oppenhoffallee 171 52066 Aachen Telefon: +49 (241) 94691-39 Telefax: +49 (241) 531622 eMail: o...@ivv-aachen.de Internet: http://www.ivv-aachen.de Sitz der Gesellschaft: Aachen Amtsgericht Aachen HRA 6212 GF: Bauassessor Dr.-Ing. Dieter Hölsken IVV-Management GmbH Amtsgericht Aachen HRB 12453 ___ 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
Re: [gdal-dev] Kakadu Jpeg2000 driver
This sounds like a driver specific problem. Do you have some test data to reproduce this? Best regards, Tamas 2011/11/2 Livneh Yehiyam ye...@rafael.co.il Hi I'm trying to use the Kakadu Jpeg2000 (JP2KAK) driver to read raster data. I'm working on windows7 64 bit with gdal source version 1.8.1 ** ** I've compiled the Kakadu SDK version v6.0 (v6_0-00828N), and compiled Gdal with the driver enabled. I'm using the c# binding. ** ** I can open the dataset, and everything looks ok (size, number of overviews, band count etc.). When I read data from one of the bands at the base resolution (lets say it is 512x512) I get the correct data. Band mainBand = dataset.GetRasterBand(1); mainBand.ReadRaster(0,0,512,512,buffer,512,512,DataType.GDT_Byte,4,2048);* *** ** ** If I get one of the overview bands: Band overviewBand = mainBand.GetOverview(0); ** ** And I try to read the entire band (lets say it is 256x256): overviewBand.ReadRaster(0,0,256,256,buffer,256,256,DataType.GDT_Byte,4,1024); What I get in the buffer are the first 256x256 pixels of the mainBand. This is contrary to the behavior I'm used to get when reading GTiff files, or even JPEG2000 with the JP2ECW driver. ** ** Is this behavior by design, or is there another way to achieve what I want. ** ** Thanks Yehiyam ** ** -- * 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
Re: [gdal-dev] Kakadu Jpeg2000 driver
It seems kakadu SDK has an extraordinary license which would call for to compile this driver as a plugin. I have been asked to compile gdal against this dependency but I'm hesitant to think I could technically distribute the gdal binaries in such form without adding the related binaries from the kakadu SDK. +1 to modify the makefile to compile as a plugin Best regards, Tamas 2011/11/1 Even Rouault even.roua...@mines-paris.org Selon Livneh Yehiyam ye...@rafael.co.il: Hi Is it possible to build the JP2KAK driver as a plugin? You didn't mention on which OS you want to build it, but I have had a look at both makefiles, and I don't see any existing support for building as a plugin. However, I don't foresee any obvious reason why you this would not doable, provided that you can tweak the makefile. Thanks Yehiyam ___ 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
Re: [gdal-dev] Auto-selection of geometry column for MS SQL Server is not restrictive enough
Dan, You can specify the geometry column name along with the table name in the connection string, something like: MSSQL:server=servername;database=dbname;tables=schemaname.tablename(geomcolumnname) for more information see: http://www.gdal.org/ogr/drv_mssqlspatial.html Best regards, Tamas 2011/10/26 Dan Homerick danhomer...@gmail.com The current logic for detecting the geometry or geography column will accept a column of type image (a subset of binary string[1]) as the GeomColumn. Furthermore, the logic checks the column types sequentially, and will accept an image column as the GeomColumn, even if there is a geometry or geography later in the list of columns. I came across this by trying to do queries on a table which does not have any spatial data, but which does have column of type image. The image column was incorrectly assumed to be a geometry column, which naturally led to errors. This was despite NOT using OGRSQL as the dialect. There doesn't appear to be any interface to specify which, if any, column should be used as the GeomColumn -- am I (hopefully!) just overlooking something? [1] http://msdn.microsoft.com/en-us/library/ms187752.aspx - Dan ___ 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
Re: [gdal-dev] Motion: Approve RFC 37: User context data in CPLErrorHandler callbacks
+1 Tamas 2011/10/26 Howard Butler hobu@gmail.com Folks, Motion: To approve RFC 37: User context data in CPLErrorHandler callbacks http://trac.osgeo.org/gdal/wiki/rfc37_cplerror_userdata Having responded to input and updated the document accordingly, I would like now formally move to adopt RFC 37. Howard___ 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
Re: [gdal-dev] deploying with GDAL libraries
2011/10/18 Pouliot, Christopher (DNR) christopher.poul...@state.mn.us 1) **What is the best way to incorporate PROJ.4? Can I simply set the PROJ_LIB environment variable in my application to point to my PROJ.dll location? In the default gdal build proj4 is loaded dynamically. Your responsibility is to deploy proj.dll into a location available in the common Windows dll search locations. (probably into the same directory of where the gdal dll resides) PROJ_LIB should point to the folder containing the epsg file etc. ** **2) **What are the bare minimum files I need to incorporate into my application for deployment? ** It depends on your compilation. You may use the Dependency Walker to make sure which dlls your build depends on. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Question regarding GDAL .dll files for C#
Hi Zhenyu Lu, You need not install the plugin dll-s if you don't require the corresponding functionality. With regards to the dependent dll-s, you can use the -dev packages from http://www.gisinternals.com/sdk/ to compile your own versions using the following steps: 1. Download the -dev package according to your compiler version. 2. Extract the SDK files in a specific directory (like C:\builds) 3. Check out the gdal sources into this directory. 4. Edit makefile and comment out the unwanted dependecies, like: #GDAL_POSTGIS = YES 5. Open a Visual studio command prompt, and type: nmake gdal GDAL_DIR=[your gdal directory] Best regards, Tamas 2011/10/3 Zhenyu Lu luzhenyu1...@gmail.com Hi Tamas, Sorry for sending you email so late at night. I noticed that you're in charge of maintaining the GDAL binary and SDK packages. I would say that you've done a fatastic job so far for making so many GDAL binary and SDK packages. I've downloaded two .msi files which worked great. So I'm thinking that your knowledge might offer huge help for me. I would like to ask you several questions regarding the binary and SDK packages you've released. I used to use the .dll files of GDAL 1.5.2 before, which were compiled by myself using VS2005. Now I wrote a tool for students to use for their labs. I suddenly realized that all the computers of my uniersity have installed Windows 7 64bit operating system, and my previous compiled .dll files do not work anymore. So I downloaded the gdal-18-1400-x64-core.msi and installed it on my computer. Compared with the previous .dll files, the newly created .dll files has much larger size (maybe much more functions). I think it is mainly because I must include some other .dll files (hdf5dll, geos_c, libmysql, pdflib, and xerces-c_2_8.dll) to make it work. However, using my previously compiled .dll file, I only need to include the gdal1.5.dll itself. So my previous implementation has the file size of 5 MB, but now the implementation grows to more than 20 MB which make it hard to distribute. Now I would like to ask is it possible for you to create .dll files or the installation file to only include the gdal18.dll file without the other plugin .dll files? Or is there a way for me to create such .dll files? Hopefully I have made my questions straightforward. Thank you so much if you could offer me some suggestions. -- Zhenyu Lu SUNY-ESF ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: OGR SQL expression parser overflow
Just an update to this, I've created a ticket for this problem, and attached a patch which seems to be working in my local set-up. http://trac.osgeo.org/gdal/ticket/4262 Due to the lack of my knowledge about bison let me know if one have a more appropriate solution to this problem. Any objection to update such change in the stable branch? Best regards, Tamas 2011/9/25 Tamas Szekeres szeker...@gmail.com Hi Devs, I've run into a memory exhausted error in the OGR SQL parser when the token count exceeds 200. This is related to the YYINITDEPTH setting in swq_parser.cpp Does anyone know how to enable the built in stack extension mechanism which can automatically extend the stack size up to YYMAXDEPTH (1)? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR SQL implicit conversions
Hi Even,
Thanks for the valuable comments, I've modified the patch in accordance with
your suggestions.
http://trac.osgeo.org/gdal/attachment/ticket/4259/swq_op_general.cpp.patch
Let me know if you find something else that can be changed. I've just added
a warning if the conversion fails, but I'm not quite sure if we can easily
generate errors at this state of the processing.
Best regards,
Tamas
2011/9/23 Even Rouault even.roua...@mines-paris.org
Le mercredi 21 septembre 2011 19:20:17, Tamas Szekeres a écrit :
Hi Devs,
We have some problems due to the recent changes in the SQL expression
parser which is related to the change in the implicit type conversion
behaviour.
Formerly we could safely use the following statement:
select * from mytable where ogr_fid in ('1100','1101','1102')
If the data type of ogr_fid is an integer or float then the expression
evaluator has converted the string constants to numeric values
implicitly.
As of 1.8 the parser reports an error due to the incompatible types in
the
expression.
I've added a ticket #4259 http://trac.osgeo.org/gdal/ticket/4259
related
to this problem including a patch to handle these string to numeric
conversions.
You didn't mention that the patch only applies to the comparison operators
(
, =, , =, =, , IN and BETWEEN ), which I think is an appropriate
restriction. I was a bit skeptical at the beginning if it would also apply
to
+, - operators for example where it is not obvious in which way the
conversion
should be done.
I have done a bit of testing with PostgreSQL, MySQL and SQLite and, and
they
indeed do the conversions you suggest.
I've noticed that PostgreSQL issues an error when the conversion fails
because
the string constant isn't a numeric value.
$ ogrinfo pg:dbname=autotest -sql select * from poly where eas_id = 'a'
INFO: Open of `pg:dbname=autotest'
using driver `PostgreSQL' successful.
ERROR 1: ERROR: invalid input syntax for double precision type : « a »
LINE 1: ...cuteSQLCursor CURSOR for select * from poly where eas_id =
'a'...
MySQL is much more silent about failed conversions however. With the MySQL
OGR
driver, nothing is emitted, but in the mysql console client, I could see a
difference :
mysql select * from poly where eas_id = 'a';
Empty set, 10 warnings (0.00 sec)
sqlite is completely silent in similar situations.
Personnaly, I think it would be appropriate for the OGR SQL engine to also
emit an error/warning for failed conversions (or perhaps just a CPLDebug()
if
we feel that there's no reason to be too verbose in such situations), but
obviously there doesn't seem to be a consensus on that among SQL vendors.
I believe this can be detected with something like :
val = strtod(pszVal, endptr);
if (endptr != pszVal + strlen(pszVal))
{
CPLError(...)
}
As far as the proposed patch is concerned, a bit of comment in the new
function to explain shortly that it converts string constants to float
constants when there is a mix of arguments of type numeric and string. In
which case, integer constants will also be promoted to float. But that last
part happens to be what SWQAutoPromoteIntegerToFloat() does already, so
perhaps you could drop that part and just call
SWQAutoConvertStringToNumeric()
before SWQAutoPromoteIntegerToFloat(), so that
SWQAutoConvertStringToNumeric() only does what its name suggests (perhaps
renaming it to SWQAutoConvertStringToFloat() would be more consistant by
the
way) ? I have tested that quickly and it seems to work, but more extensive
testing would be welcome.
On a stylistic note, I've had a hard time figuring out the operator
precedence
when reading the test :
if( (eArgType == SWQ_STRING
(poSubNode-field_type == SWQ_INTEGER
|| poSubNode-field_type == SWQ_FLOAT)) ||
(eArgType == SWQ_INTEGER || eArgType == SWQ_FLOAT)
(poSubNode-field_type == SWQ_STRING) )
So, I'd suggest to move the ( parenthesis of the last line on the line
before
(please check that it was indeed your intent) :
if( (eArgType == SWQ_STRING
(poSubNode-field_type == SWQ_INTEGER
|| poSubNode-field_type == SWQ_FLOAT)) ||
((eArgType == SWQ_INTEGER || eArgType == SWQ_FLOAT)
poSubNode-field_type == SWQ_STRING) )
Extending ogr_sql_rfc28.py with a new test for the new behaviour would also
be
great.
So, all in all, I'm in favor of your approach and I'd suggest you should go
ahead with it
However I'm a bit uncertain whether some other conversions should also be
supported or not. Having a larger number of conversion rules we might
probably think about rewriting the current approach by using a more
generic
implementation.
Any ideas?
Not really...
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org
[gdal-dev] OGR SQL implicit conversions
Hi Devs,
We have some problems due to the recent changes in the SQL expression parser
which is related to the change in the implicit type conversion behaviour.
Formerly we could safely use the following statement:
select * from mytable where ogr_fid in ('1100','1101','1102')
If the data type of ogr_fid is an integer or float then the expression
evaluator has converted the string constants to numeric values implicitly.
As of 1.8 the parser reports an error due to the incompatible types in the
expression.
I've added a ticket #4259 http://trac.osgeo.org/gdal/ticket/4259 related
to this problem including a patch to handle these string to numeric
conversions.
However I'm a bit uncertain whether some other conversions should also be
supported or not. Having a larger number of conversion rules we might
probably think about rewriting the current approach by using a more generic
implementation.
Any ideas?
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny
+1 Tamas 2011/9/2 Even Rouault even.roua...@mines-paris.org Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny --- Hi, Kyle Shannon and I would like to propose Etienne Tourigny for commit access to GDAL subversion repository. Etienne has recently contributed in the developement of the netCDF driver. He has submitted many ideas for fixes and improvements in the driver ( see this thread http://lists.osgeo.org/pipermail/gdal-dev/2011-August/029865.html), that he has organized in this wiki page : http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements He has also proposed various patches to tickets in Trac, or engaged discussion with their reporters : http://trac.osgeo.org/gdal/ticket/2129 http://trac.osgeo.org/gdal/ticket/2893 http://trac.osgeo.org/gdal/ticket/3957 Etienne has graduated in Computer Science at Université de Montréal and Master's in Atmospheric Science at UQAM. He's currently working on his PhD in Meteorology at INPE/CPTEC/CCST in Brazil. His interest in GDAL has arisen because he's working with burned area and land cover maps at high (Landsat) and medium (MODIS) resolutions and he has a need for fixing and improving the driver so as to be able to produce files in netcdf format. He has also been involved in the CDO operators, and started a discussion with the devs on incorporating geotiff and full Proj.4 support. He has also submitted minor bug reports and enhancements for QGIS. Etienne, could you reply to this message indicating your agreement to the guidelines listed in: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with my support: +1 Best regards, Even ___ 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
Re: [gdal-dev] The problem when using ReadRaster(C#) method
You should make sure about the actual representation of the raster image, whether it represents the pixel as floats as you have used float arrays in the code. The last 2 parameters are used to define the byte offset of the pixels and lines in the image ( for more info see the RasterIOhttp://www.gdal.org/classGDALRasterBand.html#5497e8d29e743ee9177202cb3f61c3c7documentation). Further C# related samples can be found here: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.cs http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALReadDirect.cs Best regards, Tamas 2011/8/31 hitweiran hitwei...@sina.com I want to read a multiband image(in format of .img) by using method ReadRaster, however, I encount some problems. I just can't understand why the data loaded to memory is wrong? the code is like this OSGeo.GDAL.Dataset dataSet = OSGeo.GDAL.Gdal.Open(@G:\building.img,OSGeo.GDAL.Access.GA_ReadOnly); int width = dataSet.RasterXSize; int height = dataSet.RasterYSize; int Band_Numbers = dataSet.RasterCount; float [] buffer_first = new float [width * height]; OSGeo.GDAL.Band One_Band = dataSet.GetRasterBand(1); One_Band.ReadRaster(0, 0, width, height,buffer_first, width, height, 0,0); However, the output is wrong! I watch the variable buffer_first in watch window, and discoverse that the data is quite terrible-some data is such as 2.818478E+21,5.065476E+32, or -6.131138E-11 and so on; So I suspect my datatype is mismatch to data in img file, or the last two arguments in ReadRaster is mistake, because I don't know the meaning of last two parameters. Thanks a lot for your answer! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/The-problem-when-using-ReadRaster-C-method-tp6745826p6745826.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to register ArcSDE driver
Hi, Make sure to place the ogr_SDE.dll into the /gdalplugins subdirectory from where your application is running. Alternatively you can set the GDAL_DRIVER_PATH environment setting to point to the directory of the plugin dll-s Best regards, Tamas 2011/8/9 L.M Tan konglon...@gmail.com hi, I am interested in using *OGR *to read data from an ArcSDE (9.2-9.3) database. I have built ogr_SDE.dll,but i can not open the SDE database. This is the csharp code : Ogr.RegisterAll(); Driver sdedr = Ogr.GetDriverByName(SDE); // sdedr = null /* */ /* Open data source. */ /* */ DataSource ds = Ogr.Open(SDE:192.168.1.123,5151,sde,sde,sde, 0); // ds=null I want to know how to register ArcSDE driver. TIA for any advice you might give and have a great day! ___ 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
Re: [gdal-dev] New PHP bindings - php5-gdal
2011/8/9 Jean-François Gigand j...@geonef.fr I decided to write this library when I got limited at using OGR/PHP (segfault crash) and noticed the latter has not been maintained for years. After trying to compile the SWIG bindings with no success, I thought a good robust C++ code would be the best deal for providing OOP interfaces to PHP. Hi Jean, I just wanted to mention, there have been some efforts recently by Mike Leahy to resurrect the php bindings, the corresponding ticket can be found here: http://trac.osgeo.org/gdal/ticket/3984 However I'm not sure about the current status of this work and how the bindings work with the attached patches. Do you have experiences? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] .NET and OGR writing to stream
Maksim, You can refer to the example http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.csto see how to read data into a byte array and then you can write this array directly to the memory stream. Best regards, Tamas 2011/7/31 Maksim Sestic m...@geoinova.com Hi all, ** ** Is there any example of OGR driver writing to memory stream (instead of file stream), in .NET? ** ** Regards, Maksim Sestic __ Information from ESET NOD32 Antivirus, version of virus signature database 6338 (20110731) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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] Re: Motion: Commit Access for Paul Ramsey
+1 Best regards, Tamas 2011/7/20 Even Rouault even.roua...@mines-paris.org Motion: Extend GDAL/OGR Commit Access to Paul Ramsey --- Hi, Paul, who has been involved for many years in the developement of various OSGeo projects like PostGIS or MapServer, has recently contributed in the developement of the OGR FileGDB driver. I have applied on his behalf various patches he has submitted to Trac (*). His area of interest would also cover the OGR PG driver for which he has also contributed an enhancement recently. It would be convenient to give him direct commit access to subversion. Paul, could you reply to this message indicating your agreement to the guidelines listed in: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with my support: +1 Best regards, Even (*) See http://trac.osgeo.org/gdal/search?q=FGDBnoquickjump=1ticket=on ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve GDAL/OGR 1.8.1RC2 for release
+1 Tamas 2011/7/12 Frank Warmerdam warmer...@pobox.com Motion: GDAL/OGR 1.8.1RC2 is approved as the official 1.8.1 release. +1 Frank -- ---+-- 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 Software Developer ___ 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
Re: [gdal-dev] gdalnumeric problems with Python 3.2 Windows 7 64 bit
Isaac, I've took a chance to install the numpy-amd64 packages from the site you mentioned. If the things are going well the tomorrow builds will contain the numpy enabled gdal win64 packages. I should however mention that I have some negative experiences with the numpy enabled GDAL (WIN64) packages since the GDAL python tests were crashing with this option, when I was trying to include this this last time. So in case if the tests are not working well, I must revert this addition and remove numpy from the Win64 setup. (The Win32 GDALpackages already contain numpy at http://www.gisinternals.com/sdk) Best regards, Tamas 2011/7/11 Isaac Gerg isaac.g...@gergltd.com Im not sure I understood your original message. In any case, I have it working now though I used a different GDAL build than the one down by Tamas. I uninstalled Tamas' build (had to delete a few files in the site-packages directory) and then install the GDAL libs from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ GDAL-1.8.1.win-amd64-py3.2.exehttp://www.lfd.uci.edu/%7Egohlke/pythonlibs/ [6.6 MB] [Python 3.2] [64 bit] [Jul 08, 2011] My code now works! Isaac On Mon, Jul 11, 2011 at 2:47 PM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 11 juillet 2011 20:40:56, Isaac Gerg a écrit : Hmmm.. I just downloaded numpy from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ the 64bit windows one without MKL. I installed it successfully and then reran the code. Same error. Any ideas? Yes, as I said in my previous answer, you need numpy at your side, but that's not enough. The GDAL python bindings need to be rebuilt against a python with numpy installed. So some extra work would be needed on Tamas side. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit
GDAL Python 3.2 packages has now been added to the builds at
http://www.gisinternals.com/sdk/
Best regards,
Tamas
2011/7/9 Isaac Gerg isaac.g...@gergltd.com
This sounds great. Thanks so much Tamas.
Isaac
On Sat, Jul 9, 2011 at 5:07 PM, Tamas Szekeres szeker...@gmail.comwrote:
I'm just working on to include that in the builds at
http://www.gisinternals.com/sdk/
Unfortunately I always have to patch the python-distutils stuff from
versions to versions so as to make it work with all the supported
compilers...
Best regards,
Tamas
2011/7/9 Isaac Gerg isaac.g...@gergltd.com
Do you guys know when 3.2 will be supported? How do I build from 3.2
currently using the patches you mentioned -- are there instructions
anywhere?
Thanks in advance,
Isaac
On Sat, Jul 9, 2011 at 8:28 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Le samedi 09 juillet 2011 13:56:54, Tamas Szekeres a écrit :
2011/7/8 Even Rouault even.roua...@mines-paris.org
http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and
3.1.
Perhaps
Tamas would want to add support for 3.2 ?
How do we stand with the Python 3.2 support in GDAL? Do we still
require to
patch the gererated interface files so as to compile the bindings
successfully?
I'm a bit hesitant to include a patching step as part of the build
execution sequence.
I've just downloaded the latest swig version 2.0.4 and the good news is
that
it now generates binding files compatible with Python 3.2 (as well as
with
previous Python versions). I also tested quickly with Java and Perl and
the
generated files are good enough to enable make test to run
successfully.
However, with CSharp, the generated cpp files have the following
duplicate
declaration
static OsrPINVOKE() {
}
static OsrPINVOKE() {
}
which causes the following error :
mcs /debug:full /target:library /out:osr_csharp.dll osr/*.cs
AssemblyInfo.cs
osr/OsrPINVOKE.cs(192,10): error CS0111: A member
`OSGeo.OSR.OsrPINVOKE.OsrPINVOKE()' is already defined. Rename this
member or
use different parameter types
osr/OsrPINVOKE.cs(188,10): (Location of the symbol related to previous
error)
whereas it is ok with swig 1.3.40
I couldn't find a relevant ticket in their bug tracker about this
duplicate
PINVOKE.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit
2011/7/8 Even Rouault even.roua...@mines-paris.org http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and 3.1. Perhaps Tamas would want to add support for 3.2 ? How do we stand with the Python 3.2 support in GDAL? Do we still require to patch the gererated interface files so as to compile the bindings successfully? I'm a bit hesitant to include a patching step as part of the build execution sequence. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit
I'm just working on to include that in the builds at
http://www.gisinternals.com/sdk/
Unfortunately I always have to patch the python-distutils stuff from
versions to versions so as to make it work with all the supported
compilers...
Best regards,
Tamas
2011/7/9 Isaac Gerg isaac.g...@gergltd.com
Do you guys know when 3.2 will be supported? How do I build from 3.2
currently using the patches you mentioned -- are there instructions
anywhere?
Thanks in advance,
Isaac
On Sat, Jul 9, 2011 at 8:28 AM, Even Rouault even.roua...@mines-paris.org
wrote:
Le samedi 09 juillet 2011 13:56:54, Tamas Szekeres a écrit :
2011/7/8 Even Rouault even.roua...@mines-paris.org
http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and 3.1.
Perhaps
Tamas would want to add support for 3.2 ?
How do we stand with the Python 3.2 support in GDAL? Do we still require
to
patch the gererated interface files so as to compile the bindings
successfully?
I'm a bit hesitant to include a patching step as part of the build
execution sequence.
I've just downloaded the latest swig version 2.0.4 and the good news is
that
it now generates binding files compatible with Python 3.2 (as well as with
previous Python versions). I also tested quickly with Java and Perl and
the
generated files are good enough to enable make test to run successfully.
However, with CSharp, the generated cpp files have the following duplicate
declaration
static OsrPINVOKE() {
}
static OsrPINVOKE() {
}
which causes the following error :
mcs /debug:full /target:library /out:osr_csharp.dll osr/*.cs
AssemblyInfo.cs
osr/OsrPINVOKE.cs(192,10): error CS0111: A member
`OSGeo.OSR.OsrPINVOKE.OsrPINVOKE()' is already defined. Rename this member
or
use different parameter types
osr/OsrPINVOKE.cs(188,10): (Location of the symbol related to previous
error)
whereas it is ok with swig 1.3.40
I couldn't find a relevant ticket in their bug tracker about this
duplicate
PINVOKE.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Accept GDAL/OGR 1.8.1RC1 as final release
Frank, I have found 2 issues related to the mssql spatial and the mapinfo tab driver. http://trac.osgeo.org/gdal/ticket/4149 http://trac.osgeo.org/gdal/ticket/4150 Committed the fix for each and it would be great to have these changes in 1.8.1 Best regards, Tamas 2011/7/7 Frank Warmerdam warmer...@pobox.com Folks, Motion: That we accept the GDAL/OGR 1.8.1RC1 package as the final GDAL/OGR 1.8.1 release. -- PSC members, please vote after at least some sort of testing. Non-PSC members please let us know if you discover problems! -- +1 Frank -- ---+-- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank going to Google and it is not mentionned once on the list!
Congrats for the new job, Frank! Best regards, Tamas 2011/7/7 Frank Warmerdam warmer...@pobox.com Sylvain, Consider it mentioned now! I had my first day today (lots to take in). I discussed this on my blog at: http://fwarmerdam.blogspot.com/2011/06/joining-google.html The short summary is that while I intend to remain active working on GDAL it won't be as much as before, and I won't be available for paid consulting on GDAL due to the nature of my US work visa. Best regards, On Wed, Jul 6, 2011 at 1:50 PM, s duclos sylvain_duc...@yahoo.com wrote: A quick search for frank warmerdam google on Google return 53,200 results The same search on Bing return 16,400 results But then Bing tell us that Related Search: .. Frank Sinatra, .. Frank Zappa, .. Anna Frank Some guys at Google are going to have a chuckle Congrat! Sylvain. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Commit Access for Antonio Valentino
+1 Tamas 2011/6/29 Even Rouault even.roua...@mines-paris.org Motion: Extend GDAL/OGR Commit Access to Antonio Valentino --- Hi, Antonio, a regular contributor to discussions on the mailing list, has submitted quite a few good quality patches, mainly related to SAR formats, over the last few months whose several have already been applied. See the following for a non-exhaustive list of his contributions : http://trac.osgeo.org/gdal/ticket/3160 http://trac.osgeo.org/gdal/ticket/3367 http://trac.osgeo.org/gdal/ticket/4105 http://trac.osgeo.org/gdal/ticket/4136 http://trac.osgeo.org/gdal/ticket/2412 It would be convenient to give him direct commit access to subversion. Antonio, could you reply to this message indicating your agreement to the guidelines listed in: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with my support: +1 Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gisinternals GDAL builds
Hi Elijah, With regards to the CRT dependency I would always recommend to use that version which corresponds to the CRT dep. of the application. You might use the Dependency Walker tool to identify which CRT dll the application depends on. For example the official python (python.org) windows builds (python.exe) use the following dependencies: Python 2.5 MSVC71 (1310) Pyrton 2.6 MSVC90 (1500) Python 2.7 MSVC90 (1500) Python 3.1 MSVC90 (1500) Best regards, Tamas 2011/6/13 Elijah Robison eli...@villagis.com Hi Tamas and GDAL devs, I recently used Tamas' Win binaries (http://www.gisinternals.com/sdk/) to install Gdal 1.8 for Python 2.7, and everything is working fine---*Tamas, thanks so much for providing those*. However, I do have a question about selecting the correct release, and want to confirm if I got lucky on my first shot, or if there is something more I should know were I to pass advice along to others. Under Compiler (Platform), I chose MSVC2010 (Win32), which corresponds to release-1600-gdal-1-8-0-mapserver-6-0-0http://PackageList.aspx?file=release-1600-gdal-1-8-0-mapserver-6-0-0.zip. But I am unclear as to what CRT dependencies are, as well as the MSVC acronym and the 1600-value prepended to the package name (as opposed to 1310, 1400, 1500). Would someone mind summarizing these for me? The various Win binaries include the same array of MSIs, so matching the correct Python version is obvious, as well as the 32/64 splitbut, would my install have worked if I used a different MSVC/number combo? Thanks in advance for your time, Elijah Robison ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need some help adding libCurl to GDAL
Hi Paul, You may have to set up a certificate file (containing the trusted domains) to make curl + SSL work properly. I've already wrote a blogpost about this at: http://szekerest.blogspot.com/2010/12/daily-built-binary-packages-for.html Hope that helps, Tamas 2011/5/20 Paul Meems bontepaar...@gmail.com Thanks Even, I've been mailing with Tamas already. I want to build GDAL myself because we want to add additional libraries as libKML, SpatiaLite and PostGIS. When I do curl.exe -V I get curl 7.21.6 (i386-pc-win32) libcurl/7.21.6 OpenSSL/1.0.0d libssh2/1.2.8 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp s ftp smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL When I do curl https://my.server.com I get curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed When I do curl *-k* https://my.server.com I get the result I want. So curl is properly configured. Do I need to change something in my nmake.opt of GDAL or do I need to use ogrinfo and ogr2ogr in a different way so I can pass the -k option? Thanks, Paul *Paul Meems * Release manager, configuration manager and forum moderator of MapWindow GIS. www.mapwindow.org Owner of MapWindow.nl - Support for Dutch speaking users. www.mapwindow.nl * * 2011/5/19 Even Rouault even.roua...@mines-paris.org Le jeudi 19 mai 2011 10:22:08, Paul Meems a écrit : Hi List, I'm still working on Win7 with VS2008 and I try to add libcurl to GDAL so we can use the new WFS driver. Two days ago I already succeeded in compile just libcurl and add it to GDAL. But then the WFS driver doesn't work with https links. So yesterday I've been trying for almost 10 hours to get libcurl, openssl and libssh to compile together. I'm using http://curl.haxx.se/libcurl/c/Using-libcurl-with-SSH-support-in-Visual-Stud io-2008.pdfas a guide and downloaded and installed: * ActivePerl * OpenSSL * libSSH2 * Netwide Assembler Did you try Tamas' builds ? It seems they have SSL support according to his blog entry : http://szekerest.blogspot.com/2010/12/daily-built-binary-packages-for.html I've got the necessary files now. I also did what was suggested in Appendix A of the PDF. But when I do ogrinfo -ro WFS:https://my.testserver.com I get this response: Error returned by server : Protocol https not supported or disabled in libcurl Today I tried checking if libcurl is configured properly, but I'm lost in the non-windows makefile and perl files. But because I followed the guide I assume libcurl is correctly build. Most likely I need to make additional changes to my nmake.opt for GDAL. Currently I have this: CURL_DIR =$(GDAL_HOME)\..\cUrl CURL_INC = -I$(CURL_DIR)/include CURL_LIB = $(CURL_DIR)/lib/DLL-Release/libcurl_imp.lib wsock32.lib wldap32.lib winmm.lib I'm also not aware what is best: using a dynamic or static library, but that is a more general question ;) So please advice me how to enable https. Thanks, Paul *Paul Meems * Release manager, configuration manager and forum moderator of MapWindow GIS. www.mapwindow.org Owner of MapWindow.nl - Support for Dutch speaking users. www.mapwindow.nl * * ___ 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
Re: [gdal-dev] Registering GDAL 1.8 64-bit with Python 2.7 on Windows 7
Have you added C:\Program Files\GDAL to the *PATH* environment variable?
Best regards,
Tamas
2011/5/4 Gregory Yetman gyet...@ciesin.columbia.edu
Hi,
I'm pulling my hair out over what should be a simple problem. I'm trying to
use the pre-compiled GDAL library and bindings published here:
http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1400-x64-gdal-1-8-mapserver-5-6.zip
To implement a pure 64-bit Python and GDAL combo (I already have numpy
64-bit working with python 2.7 64-bit).
GDAL is working on on the system, gdalinfo --version returns:
GDAL 1.8.0, released 2011/01/12
and python works fine as well. I installed the bindings with no error
messages and rebooted, but if I try and import gdal I get:
from osgeo import gdal
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python27\Lib\site-packages\osgeo\__init__.py, line 21, in
module
_gdal = swig_import_helper()
File C:\Python27\Lib\site-packages\osgeo\__init__.py, line 17, in
swig_import_helper
_mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
I created a PYTHONPATH system variable and set it to:
C:\Python27\Lib\site-packages;C:\Python27\Lib\site-packages\osgeo;C:\Program
Files\GDAL
to no avail.
Any suggestions?
I'm trying to get the 64 bit versions working because when I try and open a
large raster as an array using
DatasetReadAsArray I get an error; suggestions on another mailing list were
that this was because the 32 bit library can only handle rasters up to 2GB
and the ones I am working with are larger than that.
TIA,
Greg
--
Gregory Yetman
CIESIN, Columbia University
+1-845-365-8982
http://www.ciesin.columbia.edu
___
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
Re: [gdal-dev] Problem with GDALDatasetRasterIO.cs and ECW files
2011/4/19 Francisco José Reyes Peralta gistd...@hotmail.es Dear friends, I'm vieweing the *GDALDatasetRasterIO.cs* from the Csharp samples of GDAL and I'm getting an error in the following line *Bitmap bitmap = new Bitmap(imageWidth, imageHeight, pixelFormat);* In the * pixelFormat* argument. Hi, What is the error message specifically? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Windows SDK support (at vbkto.dyndns.org) site has been relocated
Looks like my account on dyndns has been lost :-( Since I'm getting tired to update the account in every month, I've already registered a domain to point to this location which is: http://www.gisinternals.com/sdk/ If you have any links or bookmarks to point to the support site then update them to refer to this new location. The old URL is considered to be deprecated from now. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with GDALDatasetRasterIO.cs and ECW files
Not sure what is the actual value of 'pixelFormat__1' in your program. Best regards, Tamas 2011/4/19 Francisco José Reyes Peralta gistd...@hotmail.es The parameter is not valid is the error that I get. I use an adaptation of the source .cs code in VB.NET. Here is part of the code: Dim pixelFormat As PixelFormat Dim dataType As DataType Dim pixelSpace As Integer If isIndexed Then pixelFormat = PixelFormat.Format8bppIndexed dataType = DataType.GDT_Byte pixelSpace = 1 Else If channelCount = 1 Then If channelSize 8 Then pixelFormat = PixelFormat.Format16bppGrayScale dataType = DataType.GDT_Int16 pixelSpace = 2 Else pixelFormat = PixelFormat.Format24bppRgb channelCount = 3 dataType = DataType.GDT_Byte pixelSpace = 3 End If Else If hasAlpha Then If channelSize 8 Then pixelFormat = PixelFormat.Format64bppArgb dataType = DataType.GDT_UInt16 pixelSpace = 8 Else pixelFormat = PixelFormat.Format32bppArgb dataType = DataType.GDT_Byte pixelSpace = 4 End If channelCount = 4 Else If channelSize 8 Then pixelFormat = PixelFormat.Format48bppRgb dataType = DataType.GDT_UInt16 pixelSpace = 6 Else pixelFormat = PixelFormat.Format24bppRgb dataType = DataType.GDT_Byte pixelSpace = 3 End If channelCount = 3 End If End If End If * And the Error is in the following line: * Dim bitmap As New Bitmap(imageWidth, imageHeight, pixelFormat__1) Is possible to read the dataset and write to a bitmap or picturebox without save as file? Thanks for your reply. Francisco J. 2011/4/19 Francisco José Reyes Peralta gistdt08 at hotmail.es http://lists.osgeo.org/mailman/listinfo/gdal-dev * Dear friends, I'm vieweing the *GDALDatasetRasterIO.cs* from the Csharp** samples of GDAL and I'm getting an error in the following line *Bitmap** bitmap = new Bitmap(imageWidth, imageHeight, pixelFormat);* In the *** pixelFormat* argument.*** Hi, What is the error message specifically? Best regards, Tamas -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110419/cc8baab2/attachment-0001.html ___ 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
Re: [gdal-dev] Windows link issue with Poppler/PDF
You may require to set: 'ENABLE_RELOCATABLE:BOOL=OFF' in CMakeCache.txt Best regards, Tamas 2011/4/10 Joaquim Luis jl...@ualg.pt On 10-04-2011 19:03, Jeff McKenna wrote: Hello Joaquim, Oh ok thanks, I will try with poppler 0.14.x as you recommend. (I can add to the GDAL linker flags /FORCE:MULTIPLE and it will compile, but that is not good practice I imagine) Should I file this issue in GDAL Trac? Perhaps, but maybe Tamas has something to say about this. Joaquim -jeff On 11-04-10 2:52 PM, Joaquim Luis wrote: Jeff, I get the same thing (VS2010 ). I could only link the 0.14 built for 32 bits. For 64 there were some other problems that I don't remember anymore. Joaquim Hello, On windows using Visual Studio 2008 I have compiled poppler.lib (from poppler-0.16.4, using cmake), excellent, and if I cd to /frmts/pdf and 'nmake /f makefile.vc' there are no problems; however during GDAL's link I get the following error: *** poppler.lib(GlobalParams.obj) : error LNK2005: _DllMain@12 already defined in gdaldllmain. obj Creating library gdal_i.lib and object gdal_i.exp gdal19dev.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.EXE ' : return code '0x491' Stop. *** (I have tried both GDAL-1.8.0 and trunk, same error) Anyone see what I am doing wrong, or give me some hints as to how to solve this DLLMain already defined problem? Thanks. -jeff ___ 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
Re: RE : [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64
2011/3/28 Kirk McKelvey kmckel...@lizardtech.com Tamas, I believe this was happening because of a known issue allocating DLL objects on the heap. I have made the stream objects into member variables to work around this problem on the trunk (r22052). Let me know if your tests continue to fail. Kirk, Thanks for your efforts, the problem appears to be fixed by now. Best regards Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: RE : [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64
I did some investigations related to the Win64 problem, but I have no clues how to get further with this problem. I've used Unified_DSDK_8.0_win64-vc9 and the MSVC 2008x64 compiler and even the following code is causing heap corruption when running the mrsid autotest: LTIOFileStream *ltiofs = new LTIOFileStream(); if ( ltiofs ) delete ltiofs; // heap corruption here HEAP[python.exe]: Invalid Address specified to RtlFreeHeap( 025E, 01E97610 ) Windows has triggered a breakpoint in python.exe. This issue seems to be related to the changes r21974http://trac.osgeo.org/gdal/changeset/21974 Best regards, Tamas 2011/3/23 Kirk McKelvey kmckel...@lizardtech.com Strange, nothing happened to the driver code in that range. I will bring up a 64-bit build and see if I can debug it. Am I correct that your 32-bit builds are passing this test? De : gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] de la part de Tamas Szekeres [szeker...@gmail.com] Date d'envoi : mercredi 23 mars 2011 08:36 À : Even Rouault Cc : gdal-dev Objet : Re: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 Even, According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was still OK, and r21988 was already wrong. Best regards, Tamas 2011/3/23 Even Rouault even.roua...@mines-paris.orgmailto: even.roua...@mines-paris.org Selon Tamas Szekeres szeker...@gmail.commailto:szeker...@gmail.com: Tamas, Indeed there have been recent changes. You might want to drop a note about that to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest fixes from Kirk and me, I no longer see problems under Linux however. I don't know which version of the GeoDSDK you are using. But, at least under Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff (due to the addition of new fields in geo_normalize.h) that cause crashes. But the libgeotiff change is a bit older than the MrSID driver one, so it would be surprising that Kirk changes have an impact on that. Under Linux, using version 8 solves that issue. If you revert only the changes of the MrSID driver (to what it was before r21974), what happens ? Best regards, Even Hi All, I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent change (in 2-3 days). Any ideas about the reason? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL autotest (mrsid_1) crashing on Win64
Hi All, I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent change (in 2-3 days). Any ideas about the reason? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64
Even, According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was still OK, and r21988 was already wrong. Best regards, Tamas 2011/3/23 Even Rouault even.roua...@mines-paris.org Selon Tamas Szekeres szeker...@gmail.com: Tamas, Indeed there have been recent changes. You might want to drop a note about that to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest fixes from Kirk and me, I no longer see problems under Linux however. I don't know which version of the GeoDSDK you are using. But, at least under Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff (due to the addition of new fields in geo_normalize.h) that cause crashes. But the libgeotiff change is a bit older than the MrSID driver one, so it would be surprising that Kirk changes have an impact on that. Under Linux, using version 8 solves that issue. If you revert only the changes of the MrSID driver (to what it was before r21974), what happens ? Best regards, Even Hi All, I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent change (in 2-3 days). Any ideas about the reason? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: RE : [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64
2011/3/23 Kirk McKelvey kmckel...@lizardtech.com Am I correct that your 32-bit builds are passing this test? Yes, that is the case. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fail to build with OpenJpeg
Hi Joaquim. You can download http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1600-x64-dev.zipto obtain the libs/includes. Best regards, Tamas 2011/3/9 Joaquim Luis jl...@ualg.pt On 09-03-2011 16:28, Tamas Szekeres wrote: I had to do the following tweaks in order to compile openjpegv2 from SVN. Index: CMakeLists.txt === --- CMakeLists.txt(revision 660) +++ CMakeLists.txt(working copy) @@ -50,6 +50,7 @@ IF(WIN32) IF(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_EXPORTS) +ADD_DEFINITIONS(-DUSE_OPJ_DEPRECATED) ELSE(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_STATIC) ENDIF(BUILD_SHARED_LIBS) Index: openjpeg.h === --- openjpeg.h(revision 660) +++ openjpeg.h(working copy) @@ -37,7 +37,7 @@ #define OPJ_API #define OPJ_CALLCONV #else -#define OPJ_CALLCONV __stdcall +#define OPJ_CALLCONV //__stdcall #ifdef OPJ_EXPORTS #define OPJ_API __declspec(dllexport) #else BTW: The compiled binaries/libs/headers (including x64) are available to download from: http://vbkto.dyndns.org/sdk/ Thank you very much Tamas. I guess that to build the X64 you had to point it to a X64 libtiff.lib that you have build yourself as well? And, sorry, which one of your files has the libs and includes? Not this one: release-1600-x64-gdal-mapserver.ziphttp://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver.zip perhaps this? gdal-19dev-1600-x64-core.msihttp://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver%5Cgdal-19dev-1600-x64-core.msi I confess that I don't like the .msi installers because i never know what else the they do besides installing the package. Joaquim Best regards, Tamas 2011/3/9 Joaquim Luis jl...@ualg.pt On 09-03-2011 02:59, Angelos Tzotsos wrote: Hi Joaquim, In order to build with OpenJpeg, you must use the unreleased version 2.0 of OpenJpeg. Try the following: http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip Thanks Angelos, but with this version I'm not even able to build OpenJpeg as it hangs on CMake with this error Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) Easy to fix the above by pointing into its local libtiff directory but compilation hangs latter on with (only first of many) Error1error C2373: 'opj_stream_create' : redefinition; different type modifiers C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c 2281openjpeg Also, since it comes with a libtif.lib it would not likely compile for Win64 which is may main goal to try this. Regards Joaquim Regards, Angelos On 03/09/2011 03:23 AM, Joaquim Luis wrote: Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f makefile.vc cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim ___ 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 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
Re: [gdal-dev] Windows builds and wildcard usage for gdaltindex gdalbuildvrt
Hi Armin, I've just added wildcard support to the builds at http://vbkto.dyndns.org/sdk/ according to Frank's suggestion. The corresponding binaries should be available with the next daily builds. Best regards, Tamas 2011/2/24 Armin Burger armin.bur...@gmx.net Hi all I wanted to use a more recent Windows build than the latest FW Tools which are a bit old now. I used the binaries from http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1310-gdal-1-8-0-mapserver-5-6-6.zip All works fine, just the usage of wildcards in tools like gdaltindex or gdalbuildvrt does not work any more. If I run eg gdaltindex tileindex.shp *.tif I just get the error that the file *.tif could not be found. Same happens for gdalbuildvrt.exe. So the wildcard resolution seems not to work any more (it still did work in the last FWTools 2.4.7). For gdaltindex I can use a for loop command because it adds every tif to the same shape, but I don't think this workaround works for the gdalbuildvrt. On Linux builds the wildcards usage still works fine with GDAL 1.8. Any ideas if this will be fixed for Windows? Armin ___ 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
Re: [gdal-dev] nmake.local on windows builds
Looks good. Tamas 2011/2/12 Frank Warmerdam warmer...@pobox.com On 11-02-11 06:56 PM, Tamas Szekeres wrote: Frank, While I'm not sure about what changes you intend to do here, I would emphatically disagree removing the current approach with the ability of setting the full path to the external configuration file from the nmake command line. My build system is higly depend on this setting and if we don't have any compelling reason I would like to avoid relocating this custom file (which is anyway generated dynamically) into the gdal source tree. Tamas, I did not remove the support for EXT_NMAKE_OPT - the first stuff in nmake.opt now looks like: ### # For convenience, user may put custom settings in a local settings file # named nmake.local, or a name defined by the EXT_NMAKE_OPT option. !IF EXIST($(GDAL_ROOT)\nmake.local) !INCLUDE $(GDAL_ROOT)\nmake.local !ENDIF # nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt !IFDEF EXT_NMAKE_OPT !INCLUDE $(EXT_NMAKE_OPT) !ENDIF I believe this will serve both needs smoothly, albeit with a little extra complication in the nmake.opt. 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
Re: [gdal-dev] nmake.local on windows builds
Frank, While I'm not sure about what changes you intend to do here, I would emphatically disagree removing the current approach with the ability of setting the full path to the external configuration file from the nmake command line. My build system is higly depend on this setting and if we don't have any compelling reason I would like to avoid relocating this custom file (which is anyway generated dynamically) into the gdal source tree. Best regards, Tamas 2011/2/11 Frank Warmerdam warmer...@pobox.com Folks, Some time ago Tamas added a mechanism to nmake.opt (the central include file for windows MSVC nmake based makefiles) so that you could provide an extra definition file on the commandline. eg. nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt While this is useful, expecially in cases where it is desirable to have several build configurations out of one tree, I never used it. I always just adding !INCLUDE nmake.osgeo4w or !INCLUDE nmake.frank at the beginning of nmake.opt and put my definitions in that new file. With Kirk's recent introduction of a complicated nmake.opt file for the MrSID driver, I've learned that you can check for the existance of a file in an nmake !IF EXISTS directive, and I have incorporated use of this in nmake.opt to pull in nmake.local if it exists. So going forward, I'm hoping the default way of tailoring windows builds will be to create an nmake.local file overriding definitions from nmake.opt. 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Mike, Actually the PHP bindings are not maintained at all, so any improvements in this topic would be welcomed. You might also want to regenerate the bindings with SWIG since the committed version may be outdated. You should also make sure the corresponding gdal core is available load (proably by setting LD_LIBRARY_PATH). Best regards, Tamas 2011/2/8 Mike Leahy mgle...@alumni.uwaterloo.ca Hi again, I recognize this perhaps isn't a popular topic. However, I thought I'd give the PHP bingings a try with the latest 1.8.0 release. It's somewhat promising to see that enabling the php bindings in the ./configure options and compiling will succesfully produce a php_gdal.so library. After finding this, I ran make install for gdal, then copied the php_gdal.so to the PHP modules folder and configured PHP to load it. Unfortunately, I get the following output in the Apache error logs when I attempt to load the module in PHP: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/php_gdal.so' - /usr/lib/php5/20090626+lfs/php_gdal.so: undefined symbol: CPLLoggingErrorHandler in Unknown on line 0 I'm not really sure where to look next. Could it be a compatibility issue with PHP 5.3.3, or maybe for some reason the php module isn't able to access the installed gdal libraries? Any suggestions would be welcome. I'm testing this in a minimal 64-bit Ubuntu 10.11 VM. Regards, Mike On Sunday, February 06, 2011 14:50:34 Mike Leahy wrote: Hello List, Does anyone have an idea if there is any likelihood for a revival of php bindings for GDAL/OGR. I know if these were available, I'd be making use of them...although, I have no experience creating/maintaining SWIG libraries. So I'm curious to know what someone would need to know to get started on this, and how big of a job would it likely be? Regards, Mike ___ 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
Re: [gdal-dev] MSSQL2008 Driver and OGR/Python
2011/2/7 geographika geograph...@gmail.com
Hi,
When working with the SQL Server 2008 OGR driver I presume it is necessary
to create the following metadata tables?
geometry_columns
spatial_ref_sys
There appears to be no way to do this automatically in Python, but if I
import a single dataset into the database it is created automatically. I can
then use:
conn_string = MSSQL:server=W08-SQL08;database=dbname;Integrated
Security=true;
ds = ogr.Open(conn_string)
lyr = ds.GetLayerByName('testdata')
Hi Seth,
Those metadata tables are required since MSSQL2008 doesn't have a builtin
way to store all of these information. When importing the first table it
should indeed be created from scratch. With regards to spatial_ref_sys it
could also be populated by using the corresponding postgis script.
It would be nice to be able to connect to a layer without having to
register it with the geometry_columns table using a connection string such
as:
MSSQL:server=W08-SQL08;database=dbname;Integrated
Security=true;tables=myschema.testdata(GEOMFIELD)
As this is not currently possible I manually added a record to
geometry_columns for an existing spatial table in my database. This is in a
separate schema so I used the following SQL:
INSERT INTO [geometry_columns] ([f_table_catalog], [f_table_schema]
,[f_table_name],
[f_geometry_column],[coord_dimension],[srid],[geometry_type])
VALUES ('DbName', '*myschema*', 'testdata', 'GEOMFIELD', 2, 32768,
'MULTIPOLYGON')
However using SQL Profiler when trying to connect to the layer it always
tries to find this layer in *dbo*.
exec DbName..sp_columns N'testdata',N'*dbo*',N'DbName',NULL
As it does not exist in dbo the connection never succeeds, and I cannot
connect to any of the layers in the database.
I can add this to trac if it is an issue - I just want to first make sure
I've not made any obvious errors.
Specifying the schema in geometry_columns should be working and
myschema.mytable(GEOMFIELD) should also be a working option. So please file
a ticket with this issue if you encounter problems here.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MSSQL2008 Driver and OGR/Python
I think the second one should also work, so this problem may however be
fixed.
Best regards,
Tamas
2011/2/7 geographika geograph...@gmail.com
Thanks Tamas for the quick reply.
I've been trying a few more combinations, and I now have it working.
In the geometry_columns table the first record works - when I duplicate the
schema name in the the f_table_schema and f_table_name fields. The second
does not.
In fact I can put any entry in the f_table_schema field - it appears to be
ignored.
[f_table_catalog], [f_table_schema] ,[f_table_name],
[f_geometry_column],[coord_dimension],[srid],[geometry_type]
DbName any value can be put here
schemaname.mytable GEOMFIELD 2 32768 MULTIPOLYGON DbName schemaname
mytable GEOMFIELD 2 32768 MULTIPOLYGON
The following now works (with the first record - not the second):
conn_string = MSSQL:server=W08-SQL08;database=DbName;Integrated
Security=true;
ds = ogr.Open(conn_string)
lyr = ds.GetLayerByName('schemaname.mytable') #schema name always has to be
passed here
If this is not the intended behaviour I can create a ticket, otherwise
thanks for your time (and drivers!).
Regards,
Seth
--
web: http://geographika.co.uk
twitter: @geographika
On 07/02/2011 13:26, Tamas Szekeres wrote:
2011/2/7 geographika geograph...@gmail.com
Hi,
When working with the SQL Server 2008 OGR driver I presume it is necessary
to create the following metadata tables?
geometry_columns
spatial_ref_sys
There appears to be no way to do this automatically in Python, but if I
import a single dataset into the database it is created automatically. I can
then use:
conn_string = MSSQL:server=W08-SQL08;database=dbname;Integrated
Security=true;
ds = ogr.Open(conn_string)
lyr = ds.GetLayerByName('testdata')
Hi Seth,
Those metadata tables are required since MSSQL2008 doesn't have a builtin
way to store all of these information. When importing the first table it
should indeed be created from scratch. With regards to spatial_ref_sys it
could also be populated by using the corresponding postgis script.
It would be nice to be able to connect to a layer without having to
register it with the geometry_columns table using a connection string such
as:
MSSQL:server=W08-SQL08;database=dbname;Integrated
Security=true;tables=myschema.testdata(GEOMFIELD)
As this is not currently possible I manually added a record to
geometry_columns for an existing spatial table in my database. This is in a
separate schema so I used the following SQL:
INSERT INTO [geometry_columns] ([f_table_catalog], [f_table_schema]
,[f_table_name],
[f_geometry_column],[coord_dimension],[srid],[geometry_type])
VALUES ('DbName', '*myschema*', 'testdata', 'GEOMFIELD', 2, 32768,
'MULTIPOLYGON')
However using SQL Profiler when trying to connect to the layer it always
tries to find this layer in *dbo*.
exec DbName..sp_columns N'testdata',N'*dbo*',N'DbName',NULL
As it does not exist in dbo the connection never succeeds, and I cannot
connect to any of the layers in the database.
I can add this to trac if it is an issue - I just want to first make sure
I've not made any obvious errors.
Specifying the schema in geometry_columns should be working and
myschema.mytable(GEOMFIELD) should also be a working option. So please file
a ticket with this issue if you encounter problems here.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Packaging GDAL in OSGeo4w
Folks, I'd be curious to know what would be the desired process to package specific parts of GDAL (like the various plugins or bindings) in OSGeo4w. Currently the only reasonable approach I have in my mind is that all of the parts are generated from a single compilation (provided to use the same compiler and dependencies) In this regard would that be reasonable to include the actions in the corresponding makefile.vc in the GDAL source tree. For example I would be happy to maintain the csharp part in the csharp makefile.vc. We could also store the common settings (like the version information in the package names, location of the OSGeo4w installation etc.) in nmake.opt. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
Frank, I've reviewed the document and it looks good to me, though it seems better to enforce these constraints rather at deployment time and not at run-time. However I would have some further questions: 1. With regards to GDAL_APPLICATION_LICENSE_POLICY=DEFAULT does this mean that GDAL will provide an error if a licensing violation is happening at run-time? For example when MapServer attempts to display an ECW and a MySQL layer at the same time? If this is not the case, I would prefer changing 'DEFAULT' to 'NONRECIPROCAL' and it would prevent from loading the GPL drivers during the default operation. Having GDAL_APPLICATION_LICENSE_POLICY=NONRECIPROCAL would provide better match with the licensing policy of GDAL itself which intends to be MIT/X. 2. In my opinion the user shouldn't override any specific settings (like RECIPROCAL or PROPRIETARY) being enforced by the application. In this regard the user is allowed to violate the GPL like loading proprietary drivers in QGIS. I don't think if USE_ALL should be a valid environment setting either. This should only be allowed by a compilation flag which is not intended to be used for distribution purposes. 3. I think the user should only be allowed to override GDAL_APPLICATION_LICENSE_POLICY=DEFAULT either by the environment settings or in the SWIG interface. 4. I don't really understand the rationale behind the PREFER_PROPRIETARY and PREFER_RECIPROCAL settings. Shouldn't we raise an error if a licence violation is detected? I think we might have to decide which kind of the licensing enforcement should be applied in GDAL, like: Version 1, The actual licensing mode is predefined within the scope of the execution (either by the applevel or environment setting) and GDAL should avoid to load any incompatible drivers. Version 2, The actual licensing mode may be controlled by the drivers loaded and provide an error if an incompatible driver is about to be used. I'm a bit hesitant to think Version 2 would be sufficient which allows to change the licensing mode of the application at run-time. I think we should enforce the same licensing mode at least during the scope of the execution or the within a single deployment if possible. Best regards, Tamas 2011/1/29 Frank Warmerdam warmer...@pobox.com Folks, I have been thinking about how to adjust OSGeo4W in particular, and GDAL in general to make it easier to distribute software in a way that complies with the conflict between GPLed software and proprietary software. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. To that end, I have prepared an RFC which attempts to address this at the GDAL driver registration level. I'd appreciate feedback: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 1.8 - Switch Thrown
Ari, Assuming you did mention to compile the Perl bindings with MinGW could you describe the steps of the compilation in more detail? (by using the files downloaded from http://vbkto.dyndns.org/sdk.) Which packages should be installed as the prerequisites of the compilation? I admit I'm not an expert in MinGW but it would be quite helpful on my side to be able to reproduce the issue you are talking about. I would also be curious to know how the perl tests are executed in this case. Best regards, Tamas 2011/1/30 Ari Jolma ari.jo...@gmail.com 29.1.2011 20:43, Tamas Szekeres kirjoitti: Ari, I would be eager to know the exact use case you have. Did you have some errors provided by the linker in this case? For the stdcall functions I added entries like this _CPLDefaultErrorHandler@12 CPLDefaultErrorHandler = _CPLDefaultErrorHandler@12 to the .def file. I create the .dll.a, which is the import library, with dlltool from the .def. There are no errors from the linker. If I leave the stdcall entries as they are from pexports, i.e., just _CPLDefaultErrorHandler@12 The linker complains about undefined reference to `CPLDefaultErrorHandler' However, running the Perl tests fail with The procedure entry point CPLDefaultErrorHandler could not be located in the dynamic link library gdal17.dll. This is no wonder since the Perl bindings GDAL.dll imports CPLDefaultErrorHandler from gdal17.dll. I believe this because I'm misusing the .def file or dlltool does not understand that CPLDefaultErrorHandler is an alias to _CPLDefaultErrorHandler@12. I saw a web page which seemed to say that this is a known problem in dlltool and it had a small hack for dlltool.c to fix the problem, but I don't find the page just now and I've not yet tried hacking the dlltool.c (it seems quite possible). I think the cdecl functions work ok. If I compile GDAL in MSYS, all functions are exported cdecl. Ari It would indeed be a problem how the various compilers decorate their export functions in a different way. It looks like the __declspec(dllexport) option (this is what is used in GDAL) provides different names with MSVC and MinGW by default. If we want to compile the dlls in a portable way we should probably get back to an alternative method like .def file or #pragma comment( linker, /export:FuncName ) when exporting the functions. The article you are referring to describes another way of providing a portable version that is: 1. Compile the dll as it is now (the functions exported with__declspec(dllexport)) 2. Extract the export functions in a .def file by using pexports 3. Replace the function names with their undecorated names in the .def file 4. Recompile the dll with this new export definition file. I'm keen to give it a try if I get some further info about how to test this on the other side. Best regards, Tamas 2011/1/29 Ari Jolma ari.jo...@gmail.com Did anybody else try to use the now standard Visual Studio built GDAL DLL (which was much discussed some time ago here and is now available from Tamas' site) in a MinGW environment? I spent some time a week or two ago on the issue, but I had a hard time, which AFAIK is because the DLL mixes two function export methods and thus using the standard tools seems difficult if not impossible (I already downloaded the sources for latest GNU dlltool and considered hacking it...) The best page about the issue I found so far is this: http://wyw.dcweb.cn/stdcall.htm Anybody have any ideas? Is my observation about the two export methods correct and why is that? Ari On 01/29/2011 04:59 AM, Frank Warmerdam wrote: Folks, I have had good success with the GDAL 1.8 upgrade and I have now thrown the switch migrating it into the production version of OSGeo4W. I have upgraded gdal, gdal-python, gdal-mrsid and gdal-autotest. I have yet to upgrade the ecw, and sde related drivers, and I have not upgraded the java bindings. I will try to work on them tomorrow. The gdal15dll package was created for backward compatability and should be automatically pulled in. It seems to be working fine for OpenEV. I would encourage folks building packages to update, and rebuild them using the current GDAL. The GDAL include files in C:\OSGeo4W\include and libraries in C:\OSGeo4w\lib should now be for 1.8. Note that the new GDAL package is built using Visual Studio 2008 Express instead of 2003. If you are using the C++ API this may cause issues but if you use the C API it should be invisible. Let me know of problems. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
2011/1/30 Even Rouault even.roua...@mines-paris.org On Windows, I think that the actual license of the odbc library doesn't really count as people won't distribute the windows odbc system library right ? Otherwise it would make it impossible to distribute GPL software on Windows since the system windows libraries cannot comply with the GPL. A bit confused here... Even, I would somewhat make the distiction of the term system library and 3rd party libraries which makes some difference with regards how GPL is applied. There can be found some additional explanation at http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs with the conclusion of: quote Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them. The criteria for what counts as a system library vary between different versions of the GPL. GPLv3 explicitly defines System Libraries in section 1, to exclude it from the definition of Corresponding Source. GPLv2 says the following, near the end of section 3: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. /quote Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 1.8 - Switch Thrown
Ari, I would be eager to know the exact use case you have. Did you have some errors provided by the linker in this case? It would indeed be a problem how the various compilers decorate their export functions in a different way. It looks like the __declspec(dllexport) option (this is what is used in GDAL) provides different names with MSVC and MinGW by default. If we want to compile the dlls in a portable way we should probably get back to an alternative method like .def file or #pragma comment( linker, /export:FuncName ) when exporting the functions. The article you are referring to describes another way of providing a portable version that is: 1. Compile the dll as it is now (the functions exported with__declspec(dllexport)) 2. Extract the export functions in a .def file by using pexports 3. Replace the function names with their undecorated names in the .def file 4. Recompile the dll with this new export definition file. I'm keen to give it a try if I get some further info about how to test this on the other side. Best regards, Tamas 2011/1/29 Ari Jolma ari.jo...@gmail.com Did anybody else try to use the now standard Visual Studio built GDAL DLL (which was much discussed some time ago here and is now available from Tamas' site) in a MinGW environment? I spent some time a week or two ago on the issue, but I had a hard time, which AFAIK is because the DLL mixes two function export methods and thus using the standard tools seems difficult if not impossible (I already downloaded the sources for latest GNU dlltool and considered hacking it...) The best page about the issue I found so far is this: http://wyw.dcweb.cn/stdcall.htm Anybody have any ideas? Is my observation about the two export methods correct and why is that? Ari On 01/29/2011 04:59 AM, Frank Warmerdam wrote: Folks, I have had good success with the GDAL 1.8 upgrade and I have now thrown the switch migrating it into the production version of OSGeo4W. I have upgraded gdal, gdal-python, gdal-mrsid and gdal-autotest. I have yet to upgrade the ecw, and sde related drivers, and I have not upgraded the java bindings. I will try to work on them tomorrow. The gdal15dll package was created for backward compatability and should be automatically pulled in. It seems to be working fine for OpenEV. I would encourage folks building packages to update, and rebuild them using the current GDAL. The GDAL include files in C:\OSGeo4W\include and libraries in C:\OSGeo4w\lib should now be for 1.8. Note that the new GDAL package is built using Visual Studio 2008 Express instead of 2003. If you are using the C++ API this may cause issues but if you use the C API it should be invisible. Let me know of problems. Best regards, ___ 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
Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows
2011/1/25 Jason Roberts jason.robe...@duke.edu Tamas, Could you improve the Windows GDAL installer, so that it automatically sets the environment variables (GDAL_DATA and GDAL_DRIVER_PATH), and adds the GDAL binaries path to the PATH environment variable ? I will do some improvements in the installers to make the things easier. Modifying the environment should only be happen upon the user's request and shouldn't be done automatically in my opinion. I would create a custom dialog in the installer where the user can allow this setting to be happen. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows
2011/1/25 Jason Roberts jason.robe...@duke.edu Tamas, Are you still planning to implement the registry-based approach? I ask because you seemed in favor of avoiding modifying PATH, if at all possible (a position I agree with), and the registry approach would eliminate that need while still making GDAL + bindings “just work”. Jason, As the time permits, I'll do some tests in this regard. Since not only the PATH, but other environment settings should also be applied, I consider a bootstrap dll to be implemented for all bindings. The only issue is that where to place this dll file to make it available for all for all bindings to load. May be into the system directory (?) Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MSSQL GDAL 1.8.0 Feature problem
Yes, it seems the ODBC SQL driver doesn't support the 'Initial Catalog' parameter. I've modified the driver documentation accordingly. Best regards, Tamas 2011/1/24 Matthew Blackler m...@mattblackler.com Thanks for you prompt response Tamas! Well, after having used the ogrinfo tool (thanks for the hint - first time user of ogr/gdal you see), I tested the connection string mutliple times - and it turns out it was because I was using Initial Catalog parameter, instead of the Database parameter. So - handy hint for the day - Don't use the Initial Catalog parameter in your SQL Server 2008 connection string with OGR. Use the Database parameter. Cheers Tamas! On Sun, Jan 23, 2011 at 11:05 PM, Tamas Szekeres szeker...@gmail.comwrote: Matthew, Could you provide a sample data to reproduce this problem? How the layer and the features are displayed by the ogrinfo command tool? Best regards, Tamas 2011/1/23 Matthew Blackler m...@mattblackler.com Dear all, I have downloaded v1.8.0 and am using .net CSharp bindings to connect into MSSQL such: MSSQL:SERVER=MATT-ACERPC\\SQLExpress;tables=categ(geom);Initial Catalog=Crown_GIS;Integrated Security=True; I am able to connect and retrieve the driver ok. I am able to get the Layer Categ from the datasource, no problem. However, the extent of the layer, feature counts, and even the get of features using the nextfeature cursor fails to retrieve any features or information for me. Any obvious pointers as to why iterating through a layer with a known number of features (4,000 ish) would result in returning nothing (i.e. no feature back from the getnextfeature), or why the extent of a layer would be reported as being 0,0,0,0? Any help would be much appreciated. Looking forward to leveraging OGR to making our apps datasource independant, and throwing away the shackles of ArcObjects! Thanks in advance, Matthew Blackler -- Email: m...@mattblackler.com Homepage: http://www.mattblackler.com Twitter: @mattblacklercom ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Email: m...@mattblackler.com Homepage: http://www.mattblackler.com Twitter: @mattblacklercom ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MSSQL GDAL 1.8.0 Feature problem
Matthew, Could you provide a sample data to reproduce this problem? How the layer and the features are displayed by the ogrinfo command tool? Best regards, Tamas 2011/1/23 Matthew Blackler m...@mattblackler.com Dear all, I have downloaded v1.8.0 and am using .net CSharp bindings to connect into MSSQL such: MSSQL:SERVER=MATT-ACERPC\\SQLExpress;tables=categ(geom);Initial Catalog=Crown_GIS;Integrated Security=True; I am able to connect and retrieve the driver ok. I am able to get the Layer Categ from the datasource, no problem. However, the extent of the layer, feature counts, and even the get of features using the nextfeature cursor fails to retrieve any features or information for me. Any obvious pointers as to why iterating through a layer with a known number of features (4,000 ish) would result in returning nothing (i.e. no feature back from the getnextfeature), or why the extent of a layer would be reported as being 0,0,0,0? Any help would be much appreciated. Looking forward to leveraging OGR to making our apps datasource independant, and throwing away the shackles of ArcObjects! Thanks in advance, Matthew Blackler -- Email: m...@mattblackler.com Homepage: http://www.mattblackler.com Twitter: @mattblacklercom ___ 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
Re: [gdal-dev] mrsid nmake.opt
2011/1/13 Kirk McKelvey kmckel...@lizardtech.com 3. Do we have a reason to include geotiff in the mrsid makefile? Yes – though the reason is obscure. It is to build the mrsid driver as a plugin when linking against the MrSID SDK statically (e.g., older SDKs). Most of the GDAL symbols referenced from the MrSID SDK are satisfied by gdal18.dll on the plugin link line, but two symbols that it needs are not exported from gdal18.dll, namely _TIFFmemcpy and __geotiff_size. The alternative to bringing in these symbols manually from the GDAL build or configured TIFF/GeoTIFF would be to link in gdal.lib statically, but that seemed heavy-handed. If you have any better ideas, I am open to suggestion. Kirk, I don't think we will forcibly insist on linking to MrSID statically it could probably be phased out in the future versions. 3. I would also require the dll names to be detected (MRSID_DLL, LIDAR_DLL) Yes I think this is a good addition – I am guessing it is to be able to install those DLLs? It would also be a good thing to detect the dll versions first if MRSID_RDLLBUILD and MRSID_LDLLBUILD are not specified. This doesn't seem to work according to the spec at the beginning of nmake.opt (with a preference for the DLL if both are found) I will double-check my logic in that section. What specific MrSID DSDK version are you using? I'm now woking with a modified version of your nmake.opt locally (thanks again for providing that) so I'm not in sore need of committing this back in GDAL. I'm using this option to compile and create an installer for the mrsid part of GDAL and in this regard I require both the full path to the dll-s and the name of the dll-s (since the names are changing between SDK versions) I'm compiling binaries with several compiler versions from MSVC2003 up to MSVC2010 (Win32 and Win64). In this regard I'm using the following versions of the SDKs: for compiling with gdal 1.8: Unified_DSDK_8.0_win64-vs10 Unified_DSDK_8.0_win32-vs10 Unified_DSDK_8.0_win64-vc9 Unified_DSDK_8.0_win32-vc9 Raster_DSDK_8.0_win64-vc8 Raster_DSDK_8.0_win32-vc8 Geo_DSDK-7.0.0.2167.win32-vc7 for compiling with gdal 1.7: Geo_DSDK-7.0.0.2181.win64-vc9 Geo_DSDK-7.0.0.2181.win32-vc9 Geo_DSDK-7.0.0.2167.win64-vc8 Geo_DSDK-7.0.0.2167.win32-vc8 Geo_DSDK-7.0.0.2167.win32-vc7 Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] mrsid nmake.opt
2011/1/11 Kirk McKelvey kmckel...@lizardtech.com Tamas, from what I understand you have tweaked the layout of the MrSID SDK used in your daily windows builds. Depending on the details this might work for you anyway; if it doesn’t, let me know. Kirk, The changed were breaking, I'm about to fix that in some way. I would have the following questions: 1. Do we officially drop support for the older dsdk-s for example: Geo_DSDK-7.0.0.2167.win32-vc7 which use a different directory layout as expected by the new nmake.opt. For example the recent SDK is no available for MSVC2003 and therefore we should probably use this older version. 2. Am I right that all the magic in the new nmake.opt is related how to set MSRID_LIB, MRSID_INCLUDE and MRSID_FLAGS dynamically which I could also set manually by not specifying MRSID_DIR in the builds? 3. Do we have a reason to include geotiff in the mrsid makefile? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] mrsid nmake.opt
Kirk, I've finally managed to get my builds fixed. I wanted to rely on your detection logic in nmake.opt but it seems I'd require some minor modifications (the patch attached): 1. I've found a syntax error in the line: !ELSE IF EXIST($(R700)), It may be due to the content of $(R700) probably. 2. Auto detection of MRSID_JP2 is not working. Need to comment out MRSID_JP2 = NO at the beginning 3. I would also require the dll names to be detected (MRSID_DLL, LIDAR_DLL) It would also be a good thing to detect the dll versions first if MRSID_RDLLBUILD and MRSID_LDLLBUILD are not specified. This doesn't seem to work according to the spec at the beginning of nmake.opt (with a preference for the DLL if both are found) This detection logic appears to be a cool addition in GDAL, though. Best regards, Tamas 2011/1/11 Tamas Szekeres szeker...@gmail.com 2011/1/11 Kirk McKelvey kmckel...@lizardtech.com Tamas, from what I understand you have tweaked the layout of the MrSID SDK used in your daily windows builds. Depending on the details this might work for you anyway; if it doesn’t, let me know. Kirk, The changed were breaking, I'm about to fix that in some way. I would have the following questions: 1. Do we officially drop support for the older dsdk-s for example: Geo_DSDK-7.0.0.2167.win32-vc7 which use a different directory layout as expected by the new nmake.opt. For example the recent SDK is no available for MSVC2003 and therefore we should probably use this older version. 2. Am I right that all the magic in the new nmake.opt is related how to set MSRID_LIB, MRSID_INCLUDE and MRSID_FLAGS dynamically which I could also set manually by not specifying MRSID_DIR in the builds? 3. Do we have a reason to include geotiff in the mrsid makefile? Best regards, Tamas nmake.opt.patch Description: Binary data ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL windows installers available
2011/1/10 Jason Roberts jason.robe...@duke.edu Nice job getting something out so quickly. You remind me of this Dilbert cartoonhttp://dilbert.com/dyn/str_strip/0//000/00/1/8000/400/18402/18402.strip.zoom.giffrom back in the day. :-) Due to various deadlines I won’t be able to look at this until Wednesday but hope to get you some comments by that time. We should probably follow through on Frank’s request for an RFC, so the design can be reviewed and approved according to the normal procedure. No problem, I will only be able to implement any modifications by the end of this week, probably. This is something to be let alone for a while before outlining the best solution to be written. I'm also thinking about how this approach could provide the same installers from the osgeo4w bundle by using the same wix configuration file. The windows makefile in GDAL could also be extended with the targets of creating the installer as part of the GDAL build process. I do have one request/requirement: unattended install. It would be really great if I could include eventually include or dynamically download a copy of the GDAL msi in my own software, and then invoke msiexec to install it automatically. Can you make sure this is possible with your msi package? Good idea, I will also include a shortcut to perform update directly from web in passive mode. It would be a convenient way to keep the installation up to date with the frequent changes provided by the buildsystem. It would however be reasonable to get some file hosting capabilities at some other servers to be able to provide the number of downloads are happening this way. BTW, when we get to the Python bindings installer, this is another reason to build the Python bindings installer as a .msi rather than a .exe. That is possible with Python 2.5 and later. I didn't find this option working with my Python installation (2.5 and 2.6), is that something which have been added in a recent point release? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL windows installers available
Folks, Upon the inspiration on the recent conversation in this topic I've put some efforts to automate the creation of a generic GDAL installer derived from the distributions available at http://vbkto.dyndns.org/sdk/. Currently the following options are available from this site to install and use GDAL: 1. Download the .zip package extract it in some location and run SDKShell.bat to run the commandline tools (this is the former approach) 2. Use the core msi installer to install GDAL and use the installed shortcut to run the command line tools. Python users should install the python bindings installer as well. In order to have the bindings work the location of the core files should be added to the PATH manually (this requirement will probably be removed in the future when the automatic loader approach is implemented at the bindings) The core installer places an entry in the registry (currently in HKCU) containing the install location which will allow the loader to find the required components. This task is not yet complete, the following issues are to be handled or reviewed in some way. 1. Side by side installation of the multiple versions is not yet supported. 2. Must review the license agreement (currently taken from the GDAL site) 3. Must review the product name 4. Must review the installer design 5. Must review the selectable features 6. Loader approach to be implemented for the bindings 7. Versioning rules should be clarified (should synchronize the registry entries among the versions) 8. Further fixes The core installer is provided as a single wix http://wix.sourceforge.net/project file the build process is executed by the command line apps (candle.exe and light.exe). I will make the whole approach public as part to the -dev packages at http://vbkto.dyndns.org/sdk/. By using this addition one can easily rebuild the installer after creating a customized GDAL build. The wix project file could also be included in GDAL source tree and a new target could be added in the gdal makefile for creating the installer (the CRT redistributable merge modules and the dependent dlls must be available during the build). Having the locations of the OSGeo4w files in place, this approach could easily generate the same installer for the OSGeo4w bundle. Any testing efforts / comments / wishes are graciously accepted. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL windows installers available
Michael, You probably did a full install which is not recommended if the Oracle environment is not in place. Try removing the OCI plugin by the add/remove option. Best regards, Tamas 2011/1/9 Michael Sumner mdsum...@gmail.com Awesome, thanks for this - I've really enjoyed the discussion too, a great deal of good information there. I downloaded and ran http://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver\gdal-18dev-1600-x64-core.msihttp://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver%5Cgdal-18dev-1600-x64-core.msi on Windows 7 64-bit. I removed an existing path reference to a build from your site, then started the installed GDAL 18dev (MSVC 2010 Win64) Command Prompt shortcut. On running gdalinfo I get two repeated popup errors: --- gdalinfo.exe - System Error --- The program can't start because OCI.dll is missing from your computer. Try reinstalling the program to fix this problem. --- OK --- and this in the command window: C:\Program Files\GDALgdalinfo ERROR 1: Can't load requested DLL: C:\Program Files\GDAL\gdalplugins\gdal_GEOR.dll 126: The specified module could not be found. ERROR 1: Can't load requested DLL: C:\Program Files\GDAL\gdalplugins\gdal_GEOR.dll 126: The specified module could not be found. Usage: gdalinfo [--help-general] [-mm] [-stats] [-hist] [-nogcp] [-nomd] [-norat] [-noct] [-checksum] [-mdd domain]* datasetname Otherwise it reports fine on a basic GeoTIFF. Thanks again, and I hope that small detail is of some use. Cheers, Mike. On Sun, Jan 9, 2011 at 11:51 PM, Tamas Szekeres szeker...@gmail.com wrote: Folks, Upon the inspiration on the recent conversation in this topic I've put some efforts to automate the creation of a generic GDAL installer derived from the distributions available at http://vbkto.dyndns.org/sdk/. Currently the following options are available from this site to install and use GDAL: 1. Download the .zip package extract it in some location and run SDKShell.bat to run the commandline tools (this is the former approach) 2. Use the core msi installer to install GDAL and use the installed shortcut to run the command line tools. Python users should install the python bindings installer as well. In order to have the bindings work the location of the core files should be added to the PATH manually (this requirement will probably be removed in the future when the automatic loader approach is implemented at the bindings) The core installer places an entry in the registry (currently in HKCU) containing the install location which will allow the loader to find the required components. This task is not yet complete, the following issues are to be handled or reviewed in some way. 1. Side by side installation of the multiple versions is not yet supported. 2. Must review the license agreement (currently taken from the GDAL site) 3. Must review the product name 4. Must review the installer design 5. Must review the selectable features 6. Loader approach to be implemented for the bindings 7. Versioning rules should be clarified (should synchronize the registry entries among the versions) 8. Further fixes The core installer is provided as a single wix project file the build process is executed by the command line apps (candle.exe and light.exe). I will make the whole approach public as part to the -dev packages at http://vbkto.dyndns.org/sdk/. By using this addition one can easily rebuild the installer after creating a customized GDAL build. The wix project file could also be included in GDAL source tree and a new target could be added in the gdal makefile for creating the installer (the CRT redistributable merge modules and the dependent dlls must be available during the build). Having the locations of the OSGeo4w files in place, this approach could easily generate the same installer for the OSGeo4w bundle. Any testing efforts / comments / wishes are graciously accepted. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/7 Jason Roberts jason.robe...@duke.edu Thanks for your thoughts. Based on them, I'd recommend the following two things be created. 1. GDAL windows installation program, or at minimum, a wiki page that says how to install the GDAL libraries and utilities (executables and Python scripts) to \Program Files\GDAL\... Perhaps a quick compromise would be for Tamas's build system to produce a .zip that would have everything in a suitable directory structure and for wiki page to instruct the user just unzip this to \Program Files\GDAL\ Jason, What would be the suitable directory structure? I'm keen to provide an installer which could place the files to the right location. By using WIXhttp://wix.sourceforge.net/it's could be generated automatically by the command line tools candle.exe and light.exe during the build process easily. However naming the install root folder to GDAL doesn't seem to be a right thing as we provide other packages like mapserver as well. For the sake of simplicitly I could imagine to place everything in a common folder (like SDKBuilds) and add a shortcut for invoking a command prompt (for starting the commandline tools) and a shortcut to uninstall the package. I would also mention OSGeo as the root, but I'm not sure how it will violate the files if a similar installer will ever derived from an OSGeo4W bundle. (We may probably warn the user not to install both versions side by side) I may also be mention that by default referring to the programsfolder in the installation process may select different folders depending on the architecture (Win32/Win64) or the OS version. I don't think it would be a good way to force everything to be in C:\Program Files which contains the x64 binaries on x64 platforms for example or it may reside in various logical drives on a particular system. It would probably be reasonable to use something like SHGetSpecialFolderLocationhttp://msdn.microsoft.com/en-us/library/bb762203%28v=vs.85%29.aspxto retrieve the current location in the loader program. 2. GDAL Python bindings installation program. This could be easily created using the standard Python distutils stuff I've been mentioning, and would install the bindings to the normal Python place. The bindings would ideally be modified to check for and explicitly load libraries from \Program Files\GDAL\... This would eliminate the need to modify the PATH variable. That's ok with me as a separate installer provided by distutils. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/7 Jason Roberts jason.robe...@duke.edu WIX looks like a great technology for building the installation package. I’ve never used it but I took a quick look and it seems to provide what is needed. Jason, I've already used WIX many times and I'm very satisfied with it. As I understand it, you are pondering whether it would be better to have GDAL in Program Files\OSGeo\GDAL or in Program Files\GDAL. Is it simply a question aesthetics or principle, in which it seems proper to put all OSgeo projects under Program Files\OSGeo, but there could be problems coordinating the efforts of multiple projects to adhere to that carefully and not mash each other’s files? If that summarizes the issue, then I’d recommend going with the more practical, less principled approach: put GDAL in Program Files\GDAL, and OSGeo4W in Program Files\OSGeo4W. It could get messy if both installers have to be able to create the Program Files\OSGeo directory but not necessarily delete it when they are uninstalled, because there could be another OSGeo project in there. Along those lines, I would suggest that if GDAL plans to support side-by-side installations of GDAL itself, then we need to contemplate carefully whether to use Program Files\GDAL\GDAL-X.Y or Program Files\GDAL-X.Y. I think either one would be ok, so long as whoever writes the installer thinks out all the side-by-side installation/uninstallation scenarios. Just by thinking about the details if we implement a smart dll loader which could in fact work with any locations to load the dll-s why do we require to use a specific folder as the install location? The installer may create a registry entry or a config file in a specific place where the necessary dependencies are installed actually. The loader would be responsible to query for a compatible entry and use that location when loading the dependent dll-s. If no entries found the loader would provide an error that a dependent setup should also be executed. Another question, also already raised, is whether to have just two or all three version numbers in the installation directory. I think that question depends on whether you ever need to support bugfix releases installed side-by-side (e.g. 1.8.0 and 1.8.1), and also whether the bindings and other integrators will need to bind to specific bugfix releases or not. For example, if you guarantee that all 1.8.x releases will have compatible ABIs—that you will never introduce a change that will break the binary interface without increasing the minor build number—then it would be ok to just use X.Y in the directory name. But if that cannot be guaranteed, then you need to support X.Y.Z so that bindings and other integrators can locate the specific bugfix release that they are compatible with. It would not be a problem in the scope of my comments above. The user could install multiple versions anywhere and the loader would be responsible to find out the corresponding version at run time. Regarding x86 vs. x64. The GDAL installer should follow the standard Microsoft convention. On an x64 machine, the x64 GDAL utils/libs should go in \Program Files and the x86 utils/libs should go in \Program Files (x86). The bindings and other integrators must be aware of x86 vs. x64 and locate libs from the correct directory. I agree that calling SHGetSpecialFolderLocation with an appropriate CSIDL is an appropriate way to find the Program Files directory (addressing issue noted by Joaquim and others that Program Files is localized). It is probably ok to use the ProgramFiles and ProgramFiles(x86) environment variables if calling the Win32 API is not easy for particular bindings. We could probably implement the loader in C an use SWIG to map the functions to the various languages. The implementation would be the same for all languages in this regard. The only issue here is that where to place the loader.dll (providing the core implementation) which would also rely on the Windows dll search rules. For python you could easily say to create a pyd installed along with the python files, but in may not be so trivial for the other languages. I'm tending to think that this part should probably be implemented in a generic way (which doesn't change frequently) and be installed in a common folder available in the PATH. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Ari Jolma ari.jo...@gmail.com GDAL is available but again typically as MS compiler builds - which should not be a problem in theory because the bindings use it through the C API. I've tried to use those a couple of times without luck (compiling the bindings in MinGW was the problem). Maybe I should try again using binaries from Tamas' site. I agree that there could be a one main site for GDAL Windows binaries (something like http://www.gtk.org/download-windows.html). Tamas' site looks good but I'd like to have dev packages also (the SDK packages there look old) - just the header files should be enough. Ari, The SDK packages from http://vbkto.dyndns.org/sdk/ are exactly the same which have been used to compile the daily builds, so it should be up to date. The only thing may have to be done is to download the required version of the gdal sources in the root folder, because not all of the versions included in the package in order to keep the size as small as possible. BTW: What is the desired practice to install the gdal files + bindings along with a pre-installed perl runtime on Windows? Something like we have been discussing for python in this thread, do we have some desired install locations, environment settings or packaging conventions? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
Jason, I appreciate the expertise for all of you along with this thread, I could already gather quite some useful information from here for this reason. I must mention that my programming practice in Python can be considered as zero, this is the main reason that my issues may have trivial solutions for the hardcore pythonists but not trivial to me. Apologies for this inconvenience :-) Getting back to the original topic, you mention that the gdal binaries should be installed somewhere an set PATH, GDAL_DATA, PROJ_LIB and GDAL_DRIVER_PATH as a systemwide setting. This is where the problems of mine are starting. Modifying the PATH globally is a bad practice in 99% of the cases. The only case I'm aware of which may not be a problem when we make sure that only one version of such files (dll-s and executables) will ever be installed to a particular system. But this is not the case with the gdal binaries as I would expect at least a development or a stable version (and their x86/x64 variants) to coexist which should be used by the same user. The same problem may arise when we would like to install multiple versions to the site packages directory, how the versions of the files are maintained by the python runtime? In this regard I could mention something like what have been done with the .NET framework with the multiple versions of the packages installed simultaneously in the global assembly cache. The individual packages may specify the required minimum version of the referred packages loaded by the .NET runtime. Is this something that can be done with the python environment as well? (As opposed to this, the dumb solution of having a starting script to open a command prompt (and setting PYTHONPATH properly) would ensure multiple versions to be used at the same time, since those settings are applyed to the cmd process solely.) Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Ari Jolma ari.jo...@gmail.com By the age I meant that the SDK packages are old releases (from 1310 to 1600 and not trunk for example - do I understand the release names correctly?) Ari, Those numbers are MSVC compiler numbers (according to http://trac.osgeo.org/gdal/browser/trunk/gdal/nmake.opt) not gdal version numbers. CPAN has only sources, thus cpan application which is the standard to download and install perl modules expects you to have a compiler. ActivePerl (in fact ActiveState, the company) maintains a repository of perl modules in binary versions, from where they can be simply downloaded and installed with another program. ActivePerl has tools for developing those binary packages. That's very similar to what Python has. I think ActiveState maintains its repository by itself - so if I just make the CPAN module intelligent enough it may end up there eventually. I think my Geo::Shapelib module was/is there. I think it would not make sense to include GDAL into such a binary perl module package. Thus GDAL would need to be separately installable - the module installer could probably be made to offer install it for the user if it existed somewhere. This is also the case with python and the other bindings: the gdal dll-s and dependencies should also be installed somewhere. Assuming we install the gdal-perl modules in a standard location (not sure where it is), do we have a common mechanism in the perl runtime to find the dependent dlls without having to violate system wide settings (like the PATH environment variable)? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
Ari
The only wokaround which is satisfactory to me is to set the required
enviroment at run time before the gdal bindings are used. In csharp we can
do something like:
string path =
Environment.GetEnvironmentVariable(PATH);
if (!path.Contains(gdal_bin_path))
{
Environment.SetEnvironmentVariable(PATH,
gdal_bin_path + ; + path);
}
Gdal.SetConfigOption(GDAL_DRIVER_PATH,
gdal_driver_path);
But it requires that loading the gdal dll is happening when the interface is
used actually (in Gdal.SetConfigOption with the code above). This is the
case with the .NET runtime, but I'm not sure how do we stand with the other
bindings in this regard.
Futher problem with this solution is that this startup code should be placed
in the user's script and not sure how this could be implemented in the gdal
bindings itself.
Best regards,
Tamas
2011/1/6 Ari Jolma ari.jo...@gmail.com
On 01/06/2011 03:25 PM, Tamas Szekeres wrote:
Assuming we install the gdal-perl modules in a standard location (not sure
where it is), do we have a common mechanism in the perl runtime to find the
dependent dlls without having to violate system wide settings (like the PATH
environment variable)?
:) I'm not completely satisfied (I'm also not sure I really understand the
whole f* issue) with how Perl searches for dll's - especially dll import
libs - in Windows.
But that's configure/compile time issue. In compile time a Perl GDAL dll
(for the bindings) is created and put into some location, which is known to
Perl and Perl knows how to find it in runtime.
Assuming I've built the binaries, then in runtime (when the GDAL module is
called for) I think somebody (because the Perl GDAL module dll has a link to
GDAL dll that was put there in compile time) asks for the GDAL dll's and
they simply need to be available. Thus, if there is GDAL in the system (for
example in c:\Program Files\Share\GDAL\bin) then that path needs to be in
the PATH - I don't think there is a way around that. The PATH may be a
temporary PATH set by somebody for Perl programs, but I think the policy
should be that when you run GDAL.msi, the system default PATH is modified to
have the path to the GDAL binaries.
Best regards,
Ari
___
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
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Jason Roberts jason.robe...@duke.edu 2.Build an installation package as above. Have it install the GDAL DLLs as a subdirectory of the osgeo directory, e.g. C:\PythonXY\Lib\site-packages\osgeo\bin. Modify gdal.py to set os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir to modify the PATH to include that directory prior to importing _gdal.pyd. The PATH will be modified for the running process only, for the duration of that process. 3.Same as #2 but rather than modifying gdal.py to set the PATH variable, instead create a new Python extension module called _gdal_dll_helper.pyd. The job of this C extension module is simply to get gdal.dll and other DLLs loaded without resorting to modifying the system PATH which can sometimes have weird consequences (I can explain more if needed). The extension module would call the Windows SetDllDirectoryhttp://msdn.microsoft.com/en-us/library/ms686203%28v=vs.85%29.aspxfunction, call LoadLibrary to explicitly load gdal17.dll into the current process, then call SetDllDirectory again to set the DLL directory back to what it was previously. Then, when gdal.py wants to load _gdal.pyd, gdal17.dll is already loaded and the binding succeeds. I know #2 and #3 sound scary but they can be done cleanly. I currently use a variation of #3 in my own project that embeds GDAL and its Python bindings. Jason, Good writeup, thanks for that. You mention #2 and #3 which is exactly the same I have in my mind. Already posted a code for #2 related to the csharp bindings to demonstrate this option. #2 would be fairly transparent for the user (no additional modules imported), the only thing we could add is how gdal.py would find out the install location of the gdal files. This may probably set in the registry added by the installer. Not sure how this addition would affect the gdal binding on other platforms (if we implement this in gdal) #3 seems to be better for gdal (doesn't require to modify the bindings) however the user will require to use an additional module (which is not required normally when using gdal.py) I would personally vote on having an extension (like #3) which is imported by gdal.py in case if it is installed. If this extension is not installed, gdal.py would work as before. This extension would scan the registry to find out the install location of the corresponding files (probably based on an unique key) and perform the required actions to make the dll-s loadable. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Christopher Barker chris.bar...@noaa.gov I notice on my system, the dll is gdal17.dll That is, the version is part of the file name, so there shouldn't be a problem with different versions installed in the PATH. WE could even use a longer filename, like *nix systems, we're not restricted to 8.3 anymore, are we? gdal-1.7.1-a.dll Chris, This is where a typical dll hell problem is starting. The application is happy to load a common dll let's say a gdal17.dll, zlib1.dll, libcurl.dll whatever, but is not the same at it is expected to be (for example it depends on different CRT libraries). The issue is that you rarely get a clear error message what the problem is, but your application is failing with access violations in certain conditions. To make sure about the issue I did a quick test on my devserver with a whereis.bat containing the following script, trying to find the location of some common dlls (used by gdal): @for %%e in (%PATHEXT%;.dll) do @for %%i in (%1%%e) do @if NOT %%~$PATH:i== echo %%~$PATH:i E:\buildswhereis zlib1 C:\Program Files (x86)\Mono-1.2.6\bin\zlib1.dll E:\buildswhereis ssleay32 C:\Program Files (x86)\Subversion\ssleay32.dll Depending on the location of my entry in the PATH may break both applications or these files may break mine. Not sure this causes an issue in this particular case but, it makes the things fragile well enough. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Christopher Barker chris.bar...@noaa.gov yup -- it seems long, descriptive file names would help, but that doesn't seem to be the Windows way... It would be true, but it's not a common practice of the libraries currently (assuming we keep the original dll name of each dependency). However we could probably rename our custom dlls with a random name during the build process. Pretty odd, but workable. so your gdal depends on Mono's zlib and Subversion's ssleay? that does seem fragile! Or do you mean that you have these somewhere for gdal, and they are ALSO in those other locations? I must say a common gdal build (either FWTools, OSGeo4w, ms4w whatever) may use dll-s with the same names as many other libraries a user may install. In my particular case mono and subversion is just a live example. but we could find many others that use zlib libpng libcurl whatever (these are widely used libraries in the world). I don't actually suffer from this problem because I never rely on the PATH environment to load the GDAL dependencies and I would evangelize against this practice when trying to find out a reasonable setup approach here also. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Jason Roberts jason.robe...@duke.edu So #3 is not better by virtue of not having to modify the bindings; it does have to modify the bindings. But #3 is appealing because setting the PATH from Python code sometimes has weird issues. For example, when I tried it in my code, it produced a weird problem when I tried to use the “nose” Python testing framework to run test cases that involved calling Python modules from GDAL and ArcGIS. The problem there may ultimately be a Microsoft issue in which the environment settings for a process are maintained by the Microsoft C runtime library (msvcrt*.dll) and Python, ArcGIS, and GDAL may use different versions of that library. I do not want to digress into this here, but suffice to say, I prefer #3 to #2 because it did not have this problem. This is quite a common issue the getenv/_putenv CRT functions operate only on the data structures accessible to the run-time library (CRT) and not on the environment segment created for the process by the operating system. In this regard the libraries work only on a snapshot of the variables that have been set during the CRT startup. In this case we should probably find a function that invokes the SetEnvironmentVariablehttp://msdn.microsoft.com/en-us/library/ms686206%28v=vs.85%29.aspxAPI instead. 1.Modify the makefiles for your SDK so that it runs release--dev\gdal\swig\python\setup.py with the “bdist --formats=wininst” option. This will produce an installation program such as gdal-1.7.3.win32-py2.5.exe. This is what the user will run to install the Python bindings together with a private copy of the GDAL DLLs used just by those bindings. On Python 2.6 and later, we probably want “bdist --formats=msi” to produce a .msi file rather than a .exe, because Windows likes .msi files much better than .exes for security purposes. IIRC, Python 2.5 and earlier do not have the msi option. This can be done fairly easily. Does this mean we would require each build for multiple python versions? 2.Modify release--dev\gdal\swig\python\setup.py to include the GDAL DLLs and data files in the data_files list that is passed to the setup() function. Make sure it is only done for Windows (Python code can check that). The goal is to have the installation program create the following kind of installation: Hmmm. I'm keen to avoid any local modifications in the compiled files throughout the build system. Do we have some option to load this infromation from an external file (which is probably loaded by setup.py if exists)? Or I must write a custom setup2.py containing this customization. 3.Introduce a new file release--dev\gdal\swig\python\extensions\_gdal_dll_loader.cpp. This file will call GetDllDirectory to find the current DLL directory setting, call SetDllDirectory to C:\PythonXX\Lib\site-packages\osgeo\bin (or wherever the Python instance is installed), call LoadLibrary(gdal17.dll), and call SetDllDirectory back to what it was before. There are more details to consider. For example, we might want to have it call LoadLibrary first to see if it can load the GDAL DLL from the PATH, allowing the user to use their own GDAL DLLs without having to overwrite the ones in the Python directory. Or we might *not* want to do that, with the idea that the GDAL Python bindings must be tightly coupled to a particular version of GDAL’s DLLs. That seems to be quite complicated, not sure it that's working for those libraries using LoadLibrary binding at run time. Wouldn't that be better getting back to add the location to the PATH of the process in a loader.py (using SetEnvironmentVariable). 5.Modify gdal.py, osr.py, and so on to do something like this: import sys if sys.platform == 'win32': # TODO: add check for Windows x64 as well try: import osgeo._gdal_dll_loader # As part of this, Python will call an “init” function inside. That function will do the SetDllDirectory, etc. except: pass Such changes can be done in the SWIG interface files easily. 6.Do whatever is necessary to ensure the GDAL_DATA etc are properly set up inside GDAL. I can’t remember if this will “just work” using directories named gdal-data, gdal-plugins, or if it is necessary for the _gdal_dll_loader.pyd to call some GDAL functions to make it happen. I guess this could also be set form a python script (probably from loader.py) Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Livneh Yehiyam ye...@rafael.co.il I personally will be happy to see FWTOOLS updated at least for major Gdal releases. I find it to be a much simpler way to distribute Gdal to my end users. I agree that OSGeo4W is more complete, but I think that for many users the simplicity of FWTOOLS wins. What do you mean by 'simplicity'? Is this related to the installer which is simpler to use? In this regard would it be much simpler to pick up the required files and distribute that to the end used in a single .zip package? As far as I know FWTools is based on the development version while OSGeo4W and ms4w are mostly compiled against the stable branches (OSGeo4W may also contain -dev packages though). This may strongly define which one is more suitable for a particual use case. A development version contains the recent features up to the time when the package has been built, but it may also contain a high number of bugs temporarily, which should be fixed until the next stable release. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Christopher Barker chris.bar...@noaa.gov However, for simplicity, a one-click installer for just GDAL/OGR for Windows, complete with command line tools and ready for use with the python bindings (and others language bindings?) would be great. I've found it painful to find appropriate Windows executables every time I've need to upgrade to the latest. Supporting multiple vesions (development/stable branches/releases, x32/x64, multiple MSVC CRT dependencies) is quite a difficult task in a single installer. With regards to the development version it would also be reasonable to provide a build quite frequently to be in sync with the latest changes in trunk. These are the main reasons I've originally set up http://vbkto.dyndns.org/sdk/ to provide most of the resonable combinations as daily built packages. I also wanted to include these files in an installer (or multiple installers) but at the moment I don't see the real benefit of this over extracting a single zip package, since these libraries don't require significant preparation (like regkey entries) during the deployment. Any further consideration in this topic would be helpful, as I may have missed something that would also be important by a windows user. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Christopher Barker chris.bar...@noaa.gov 1) It would be nice to have binaries for the latest release front and center at the main GDAL site -- having to poke around to find Tamas's site is not a big deal, but not always obvious. Chris, With regards to the comment above, while I'm not sure about the objectives but I don't think the GDAL site would intend to be a hosting provider of various binary packages, the most reasonable thing is to put the references pointing the user to the correct locations which has already been done, see the Downloads section at http://www.gdal.org/ 2) A standard install location would be good. As I've messed with this each time, I never know where stuff should go -- maybe installers would help with that This doesn't seem to be decisive requirement to me. We may also create a definite location in the hard drive to host such files (which can be remembered later). Or some other folks may prefer installing these files along with their applications or keep such files in separate - project specific - directories. We may also have a requirement to deploy and run these applications from portable locations (ie. from CD or a flash drive). Another issue of an installer may be due to a single product key along with the setup which would prevent from installing multiple versions side by side in the same environment. 3) If there is a standard install location, then easy_install gdal (or setup.py build, or...) could work for the python bindings. I admit I don't have enough knowledge about the 'magic' tricks related to python-ish way installing applications. I expect that most 'magic' are implemented by copying the files at certain locations, setting some environment variables or regkey entries. However I might also consider running a custom application with gdal not necessarily be the responsibility of a GDAL package. You might also want to install python from a separate installer (either ActivePython, python.org whatever) and run the application direcly from a command prompt where the environments are set to run the gdal applications properly. Most of these packages provide the required .bat file to setup the environment this way. Another option is to have a binary installer for the python bindings that includes gdal and the gdal utilities -- that would be great for users like me, but I don't know how common my use case is. In that case, you'd want to support a few recent pythons versions, the python.org binaries: 2.6, 2.7, 3.1 (maybe 2.5 too). I don't know much about this either. This may however be doable for those guys who know the Python packaging approach well enough. I don't think eiter of the packages referred at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support this feature though. One of the tricks here is which numpy to support, etc. numpy has been pretty good with binary compatibility lately (except for one mistake recently that was corrected) Not sure how this be related to a GDAL binary distribution, as far as I remember numpy can be installed to the Python deployment directly. However, I DON'T want gdal to give me Python -- I use Python for too many other things for that. Yes, adding more runtime environments to a simple GDAL package makes it more heavy weighted. Would also be reasonable to include the Perl environment or a .NET framework installer for example to make it more complete. However, in many cases it's more reasonable to let the application (using the GDAL binaries) decide how to make a proper installer to run their application smoothly. 4) it might be nice if the install location for the utilities got put on the user's PATH -- I don't know how hard that is in an installer -- Windows really sucks in that regard. I don't think it would be beneficial in most cases. This could easily break other applications (using the dll-s with the same names) to fail unexpectedly. I would prefer to keep the applications isolated (setting the environment variables specifically to the process and not the user/system) as much as possible. An installer would better enforce a standard install location. You could also have a custom DOS box with a menu entry that set up the environment for the command line tools (maybe only PATH?), provide an uninstaller, and of course, give the Windows users a nice warm and fuzzy feeling. The 'nice warm and fuzzy feeling' is a good objective indeed, setting up an entry on the start menu instead of a running the batch file directly may also be an advantage. While I'm not sure starting a DOS prompt would validate an installer by it's own, I can see this requirement to be valid in most cases. With regard to Python, an installer could see what Python the user has and install the bindings for that version. Not that I have any idea how to build that! Agreed, but I have no idea either. Inno Setup is a very nice free installer, by the way. I would also add Wix
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Daniel Morissette dmorisse...@mapgears.com I agree with you, but it seems that an [OK] button (even if it doesn't do anything) makes Windows users feel so much better. :) Daniel, :-) And sometimes we wonder what a heck is being done behind an OK button on Windows which takes so long (or lasts forever ;-) Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Jason Roberts jason.robe...@duke.edu Right now, to install the latest GDAL for Python on Windows, the user has to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into find the GDAL binaries and related files, copy them to a directory such as C:\GDAL, set the PATH and GDAL environment variables, and so on. And there are no obvious instructions anywhere about how to do this. Python programmers are programmers after all, so they can generally figure that out and accomplish it. But it is not what they are used to doing if they are a Windows programmer. This is why Chris basically says that he has to remember / relearn how to do it every time he upgrades GDAL. It would be really helpful to Windows Python programmers who want to use GDAL—probably a large number of potential GDAL users—for the GDAL team to offer installation via one or both of the mechanisms I mentioned above. Jason, Maybe this is due to my lack of knowledge in Python, but why is it a requirement to place the files to such specific locations to run a python app with gdal on Windows? As far as I remember setting up the following environment variables properly (in a command prompt) does the right thing from arbitrary locations (at least when running the autotest suite for GDAL): PROJ_LIB GDAL_DRIVER_PATH GDAL_DATA PYTHONPATH PATH Certainly one should find out the location of the python.exe which might also be included in PATH for convenience. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
Chris, Good points below, but having the compiled gdal binaries (and the binaries of the dependent libraries) in hand, which is the right way to install those files on Windows? (Assuming we don't provide python.exe and the related files in the package)? I mean which install actions should be done in detail? Best regards, Tamas 2011/1/5 Christopher Barker chris.bar...@noaa.gov It may well be that GDAL has too many different use cases to even have a standard install, but... On 1/5/11 1:37 PM, Tamas Szekeres wrote: 2011/1/5 Christopher Barker chris.bar...@noaa.gov 1) It would be nice to have binaries for the latest release front and center at the main GDAL site -- having to poke around to find Tamas's site is not a big deal, but not always obvious. With regards to the comment above, while I'm not sure about the objectives but I don't think the GDAL site would intend to be a hosting provider of various binary packages, Well, many (most?) open source packages have official binaries hosted on its site. It's pretty common to go to a project's site and expect to find a way to download binaries right then and there. 2) A standard install location would be good. As I've messed with this each time, I never know where stuff should go -- maybe installers would help with that This doesn't seem to be decisive requirement to me. It's not a strong requirement, but standard defaults do make things easier for everyone. Or some other folks may prefer installing these files along with their applications or keep such files in separate - project specific - directories. Well, users should certainly be able to do something custom if they want. This is all about use-cases -- if you are building a custom app linked against GDAL, then you probably want to control where you put things. However, if you are interested in the command line tools, and using GDAL via Python or Perl or ??, then it makes it easier to have a standard location. Another issue of an installer may be due to a single product key along with the setup which would prevent from installing multiple versions side by side in the same environment. Surely there are ways to accommodate that? though dll hell is in the lexicon for a reason! 3) If there is a standard install location, then easy_install gdal (or setup.py build, or...) could work for the python bindings. I admit I don't have enough knowledge about the 'magic' tricks related to python-ish way installing applications. That's the thing -- there is no magic here. If you are building a python extension, you need to tell the build system where its dependencies lie. If you are installing a pre-built python extension, then the dependencies need to be in a known place (or maybe on the right PATHS -- Windows is pretty ugly this way). Which is why a standard install location would be a good idea. I might also consider running a custom application with gdal not necessarily be the responsibility of a GDAL package. well, that depends on whether you consider Python bindings a custom application. In any case, I think it helps third party packages to have standard default install locations. Oh for *nix -- this would be easier if we just could just put stuff in /usr/local/... You might also want to install python from a separate installer (either ActivePython, python.org http://python.org whatever) True -- but it is very much a standard for third party packages to provide binaries for the python.org python build. Again, I'm not suggesting that folks should be prevented (or even discouraged) from doing various sorts of custom installs, just that there should be defaults, so that it's clear an easy for a newbie to know what to to to get things to just work. Another option is to have a binary installer for the python bindings that includes gdal and the gdal utilities -- that would be great for users like me, but I don't know how common my use case is. In that case, you'd want to support a few recent pythons versions, the python.org http://python.org binaries: 2.6, 2.7, 3.1 (maybe 2.5 too). I don't know much about this either. This may however be doable for those guys who know the Python packaging approach well enough. It's not that hard (at lest once GDAL is built), but it is work. I don't think eiter of the packages referred at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support this feature though. Agreed -- that's my point! One of the tricks here is which numpy to support, etc. numpy has been pretty good with binary compatibility lately (except for one mistake recently that was corrected) Not sure how this be related to a GDAL binary distribution, as far as I remember numpy can be installed to the Python deployment directly. yes, but the Python bindings are built against a particular numpy. That's OK for version so
Re: [gdal-dev] C# Binding ForceToMultiPolygon
Hi, What is the detailed error message you get? Could you provide some test data to reproduce this problem? Have you tried with ogr2ogr to convert this data source from shapefile to postgis? Best regards, Tamas 2010/12/27 Edi.Karadumi edikarad...@gmail.com Hi everyone, im a new user to ogr and i have used c# binding and then converted them to use to my application in vb.net. Im making an application to import shape files to postgres. I have made the connection, imported the data, but i need to know the progress so i have used a loop to transfer the data. Also i have imported them to an existing layer in postgres, but its type is multipolygon and sometimes i have poligon so it throws an exception. I have read that exists some function forcetopolygon and forcetomultipolygon but i cant find them i c# bindings. can anyone help me? here is the code: Ogr.RegisterAll() inputDs = Ogr.Open(filePath, 0) If inputDs IsNot Nothing Then If inputDs.GetLayerCount 0 Then oInputLayer = inputDs.GetLayerByIndex(0) drv = Ogr.GetDriverByName(PostgreSQL) outputDs = drv.Open(ServerConnection, 1) '*** 'the postgre table has multiple geometry columns '* oOutputLayer = outputDs.GetLayerByName(CadastralZoneImportTable + (polygon)) Dim i As Long oInputLayer.ResetReading() If oInputLayer.GetFeatureCount(1) 0 Then Dim MaxFeaturesCount = oInputLayer.GetFeatureCount(1) Dim j As Long = 0 oOutputLayer.StartTransaction() For i = 0 To MaxFeaturesCount - 1 oOutputFeature = New OSGeo.OGR.Feature(oOutputLayer.GetLayerDefn) oInputFeature = oInputLayer.GetNextFeature If oInputFeature.GetFieldIndex(cze_number) = 0 Then oOutputFeature.SetField(cze_number, oInputFeature.GetFieldAsInteger(cze_number)) End If If oInputFeature.GetFieldIndex(cze_name) = 0 Then oOutputFeature.SetField(cze_name, oInputFeature.GetFieldAsString(cze_name)) End If If oInputFeature.GetFieldIndex(bau_total) = 0 Then oOutputFeature.SetField(bau_total, oInputFeature.GetFieldAsString(bau_total)) End If If oInputFeature.GetGeometryRef IsNot Nothing Then oOutputFeature.SetGeometryDirectly(oInputFeature.GetGeometryRef) End If 'here throws the exception about the multipolygon oOutputLayer.CreateFeature(oOutputFeature) oOutputFeature.Dispose() oInputFeature.Dispose() Next If i = MaxFeaturesCount Then oOutputLayer.CommitTransaction() Else oOutputLayer.RollbackTransaction() End If End If End If Else MsgBox(error importing file: + filePath, MsgBoxStyle.SystemModal + MsgBoxStyle.Information) End If -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/C-Binding-ForceToMultiPolygon-tp5869504p5869504.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] mrsid_lidar - mrsid
Kirk, Would it be a big deal to provide support for DSDK 8 in gdal? At the first sight the only issue is the missing getVersion function in MrSIDImageReader referenced in mrsiddataset.cpp. line 1448. We could probably extract the same information from a different API function call. Best regards, Tamas 2010/12/23 Kirk McKelvey kmckel...@lizardtech.com I would like to fold the mrsid_lidar driver (submitted earlier this year) into the mrsid raster driver. I plan to keep lidar and raster support separately-configurable in the build, but think it makes sense to present a single driver for MrSID files. MrSID/LiDAR is still a pretty recent format, but I wanted to give fair warning to anyone who might be using this driver. Does anyone have any objections to this? Kirk ___ 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
Re: [gdal-dev] Motion: Commit Access for Kirk McKelvey
+1 Tamas 2010/12/18 Frank Warmerdam warmer...@pobox.com Folks, Motion: Extend Commit Priveledges for Kirk McKelvey. Kirk is a software developer at Lizardtech and has been workin with GDAL for a number of years. He has proposed some patches to upgrade to version 8 of the MrSID SDK and to fix up a few other things: http://trac.osgeo.org/gdal/attachment/ticket/3839/mrsid-v8.patch He has offered to become a commiter in order to better maintain the MrSID driver in GDAL on an ongoing basis and I'd love that. He might also assist with other fixes of value to Lizardtech. I'll start the motion with: +1 Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: how can I compile GDAL 1.7.3 with ecw 4.1 in Virsual Studio 2010
BTW: Do you have any compelling reason to use ECW 4.1 instead of an older version, like the 3.3 povided for example at: http://vbkto.dyndns.org/sdk/These packages also contain the required C# bindigs for gdal and mapserver. You can download the -dev packages so as to compile your own versions of gdal and mapserver if you need to so do. You may also set the GDAL_DRIVER_PATH programmatically by using the Gdal.SetConfigOption method. Best regards, Tamas 2010/11/25 GeoJoda joseph4...@hotmail.com Hi again Finally I managed to compile ecw dll as part of gdal. This means I do not need to declare a system variable to tell where ecw gdal plugin is located. I ran gdalinfo - format: Bingo found *Supported Formats: ECW (ro): ERMapper Compressed Wavelet JP2ECW (ro): ERMapper JPEG2000* But when I try to run gdal17.dll with MapServer, I get this error message: *load output format (): General error message. OUTPUT FORMAT clause references driver GDAL / ECW, men this driver isn't Configured.; msInitGDALOutputFormat (): General error message. GDAL `ECW` driver ikke support output.* I get this error message only when I include. Ecw file in mapFile. This means that solution with the new gdal thrived without ecw. So question is am I missing some configurations for MapServer or what? I will attach this time the new gdal17.dll, gdalinfo.exe and MapServer. So maybe can someone tell me what's going on? the rest Iam using mapscript_csharp.dll. thanks gdal17.ziphttp://osgeo-org.1803224.n2.nabble.com/file/n5774457/gdal17.zip -- View this message in context: Re: how can I compile GDAL 1.7.3 with ecw 4.1 in Virsual Studio 2010http://osgeo-org.1803224.n2.nabble.com/how-can-I-compile-GDAL-1-7-3-with-ecw-4-1-in-Virsual-Studio-2010-tp5765934p5774457.html Sent from the GDAL - Dev mailing list archivehttp://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.htmlat Nabble.com. ___ 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
Re: [gdal-dev] Gdal driver not working in windows 7
2010/11/22 Ram prasad ramprasa...@gmail.com Following is repost, because the message appeared garbled in the mailing list. I could not compile my code along with other formats in frmts due to my insufficient experience in using nmake projects. http://www.gdal.org/gdal_drivertut.html gives information on writing a driver. Is there a document on compiling the driver? I need to be able to specify the search path for include files for the compiler and input files for the linker. If you download the -dev package from http://vbkto.dyndns.org/sdk/ it should contain all the required libs and headers to compile the plugin. Make sure to compile with the /MD setting to use the same CRT dependency for the plugin and the gdal dll. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: UnsatisfiedLinkError with gdal14
Do you have any compelling reason to use gdal14 instead of a newer version? You may download working binaries (along with the java bindings) from here: http://vbkto.dyndns.org/sdk/ Best regards, Tamas 2010/11/22 MarvinCO marvin.off...@googlemail.com I'm sorry, nothing has helped so far. I found out via Dependency Walker, that obviously there are a few DLLs that gdal14 depends on: ieframe.dll shlwapi.dll urlmon.dll I found all of them and placed them into my jre\bin directory. However, that still doesn't solve my problem. Still getting the same error message. I hope this output of Dependency Walker is of any help? Look at the tree of ieframe.dll. Does this mean that there are some functions not implemented in the ieframe.dll that gdal14 wants to use? http://osgeo-org.1803224.n2.nabble.com/file/n5763694/gdal14.png -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/UnsatisfiedLinkError-with-gdal14-tp5759026p5763694.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: UnsatisfiedLinkError with gdal14
2010/11/21 MarvinCO marvin.off...@googlemail.com Which are the common DLL search locations? Eclipse doesn't give me any clue about how its starts the JVM, and which additional locations it may ask the JVM to search automatically. Process monitor also doesn't really give me any clue, it shows me mainly files from the System32 folder, which should already be part of the PATH. For further info refer to the following document: http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx What do you mean by setting the PATH environment of the javaw process? Is there any VM argument to set that? I admit I'm not an expert in java. With C# we could probably use Environment.SetEnvironmentVariable for this purpose. Have you managed to use Process Monitor I have mentioned before? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] UnsatisfiedLinkError with gdal14
Hi,
While I'm not sure about the layout of the files throughout the application,
I may suppose some of the dependent libraries are not available in the
common dll search locations. You may probably inspect this with a file
monitoring tool (like process
monitorhttp://technet.microsoft.com/en-us/sysinternals/bb896645.aspx)
and see the expected locations of the files. You may probably set the PATH
environment for the process to point to the direcory where those dll-s
reside.
Best regards,
Tamas
2010/11/20 MarvinCO marvin.off...@googlemail.com
Hey,
I am trying to write a Java application that uses GDAL on Windows 7. I am
using the Java bindings of GDAL together with the gdal DLLs from the GDAL
download page.
I hope you are familiar with the distributions I'm using:
GDAL DLLs:
imageio-ext-1.0.5-windows32-dlls/*
GDAL Java bindings:
imageio-ext-1.0.8-libraries/*
I have copied all the DLLs into my jre/bin directory of my Java Runtime
environment.
Everything works fine if I run the program via the Eclilpse run
configuration. GDAL libraries are properly loaded, and are able to read a
shapefile that my program opens and display its contents.
My program starts like this:
package mapillustrator;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import mapillustrator.controller.Controller;
import mapillustrator.view.MainWindow;
import org.gdal.ogr.ogr;
/*
* To change this template, choose Tools | Templates and open the template
in
* the editor.
*/
/**
*
* @author marvin
*/
public class MapIllustrator {
public static Controller controller;
public static MainWindow mainWindow;
public static void main(String[] args) throws Exception {
try {
System.loadLibrary(gdal14);
ogr.RegisterAll();
controller = new Controller(args[0]);
mainWindow = new MainWindow(null, true);
} catch (Exception e) {
JOptionPane.showMessageDialog(new JLabel(),
e.getMessage());
e.printStackTrace();
}
}
}
So, as I said, all this works fine.
However, I now want to have the main method launched via a python script
for
some reason, so here's my python script (the script is located at
C:\Program Files\Inkscape\share\extensions):
import os, sys, subprocess, time
dir = os.getcwd().replace(\\, /) + /share/extensions/MapIllustrator/
libdir = dir + lib/
subprocess.Popen(java -verbose -classpath \.;C:/Program
Files/Java/jre6/lib/ext/QTJava.zip; + dir + build/classes; + libdir +
*; + libdir + SuperCSV-1.52/*; + libdir + batik-1.7/*; + libdir +
batik-1.7/lib/*; + libdir + batik-1.7/extensions/*; + libdir +
imageio-ext-1.0.8-libraries/*; + \ mapillustrator.MapIllustrator \ +
sys.argv[-1] + \, stdout=True)
But everytime I launch my application via the script I get an
UnsatisfiedLinkError of the kind
gdal14.dll: Can't find dependent libraries
I'm really wondering why I am not getting this error if I launch my program
via Eclipse. No such error occurs there and GDAL manages to load all the
libraries and does not complain about any dependencies.
Obviously, the gdal14.dll is found. I'm using the JDK1.6.0.22 with Eclipse.
Its JRE is also configured as the default JRE in my windows registry:
C:\Program Files\Java\jdk1.6.0_21\jre
As I said, I have also copied all files from the
imageio-ext-1.0.5-windows32-dlls/* into the C:\Program
Files\Java\jdk1.6.0_21\jre\bin. I have also tried copying them to
C:\Program Files\Java\jdk1.6.0_21\bin instead. The all Java bindings for
GDAL are also included in the Java classpath in my Eclipse project
settings.
As you can see in the Python script, I am also doing that above.
So obviously, there has to be a difference in how Eclipse launches my Java
program and in how the python script does. I don't see any other
explanation, and I also don't know what on earth Eclipse does different to
have it run without a problem. There isn't a single argument set in my run
configuration. I don't know how Eclipse actually transfers the classpath
arguments of the project settings into the program launch (probably adds
the
-classpath ... argument on its own), but other than that I'd really like
to know what I am doing wrong.
The only difference between running from Eclipse and running via my python
script seems to be that my python script is that both are calling java from
a different current working directory: The project home in Eclipse VS
C:\Program Files\Inkscape in the script. The script is being launched as
an Inkscape extension. I don't know why Inkscape sets the CWD to
C:\Program Files\Inkscape, although it is located at C:\Program
Files\Inkscape\share\extensions
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/UnsatisfiedLinkError-with-gdal14-tp5759026p5759026.html
Sent
Re: [gdal-dev] Gdal driver not working in windows 7
Did you compile GDAL and the plugin with the same CRT setting (ie. /MD), what kind of subsequent libraries have been compiled in GDAL? You may probably use http://vbkto.dyndns.org/sdk/release-1500-dev.zip for compiling both GDAL and your plugin to create a consistent build by using the same compiler for each. Best regards, Tamas 2010/11/18 Ram prasad ramprasa...@gmail.com Thank you Frank, I had upgraded the MSVC 2005 sln to 2008 sln without changing the MSVC_VER in the NMAKE properties page. Now the gdal executables and the driver are compiled are by MSVC 2008 (MSVC_VER =1500) in the release mode, but the problem still continues to exist. In fact in the GDALRegister_test function if I add the following lines of code GDALDriver *poDriver_temp = new GDALDriver(); printf(about to delete\n); delete poDriver_temp; printf(delete ok\n); The code crashes at line 3 [?] But i am sure that there is something wrong in my code because the drivers in http://vbkto.dyndns.org/sdk/release-1500-gdal-1-7-mapserver-5-6.zip seem to be working correctly Let me briefly explain what i am doing. I 've created an empty win32 console project in dll configuration have created a folder called gdal_1_6_0_files which contains the .h files from gcore and port directories and the gdal_i.lib, gdal16.dll and the exes in apps add the testDataset.cpp and makethe include and linker settings after compilation I set the GDAL_DRIVER_PATH accordingly and run gdal_translate.exe This works in WindowsXP but the same does not work in windows7 I don't know what to do? On Fri, Nov 19, 2010 at 12:38 AM, Frank Warmerdam warmer...@pobox.comwrote: Ram prasad wrote: The gdal driver for my format is working perfectly in windows XP but not in windows7. It is crashing when I run gdalinfo gdal_translate.exe with or without parameters. so i wrote a dummy gdal driver (the following code), which also is crashing in GDALDriverManager::~GDALDriverManager() at the line delete poDriver;. This also happens in windows server 2008. The gdal versions i tested are 1.6.0, 1.6.1. and 1.7.3 I am using visual studio 2008 The error message from debugger is /Unhandled exception at 0x773f61e9 in gdal_translate.exe: 0xC005: Access violation reading location 0x7e7fd537./ Ram, Are you building GDAL itself with visual studio 2008 and similar compiler options as used for your plugin? It has been my experience that it is not safe to build plugins with significantly different compiler version or flags. Also, I found that Vista and Win7 are much more sensitive to the problems caused by mixing versions compared to WinXP. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Programmer for Rent -- Love all serve all - ..::Sri Sathya Sai::.. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev 361.gif___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 32: gdallocationinfo utility
2010/11/15 Frank Warmerdam warmer...@pobox.com I have made a couple changes to gdallocationinfo based on feedback I received when bringing it up for discussion. I am not motioning to adopt RFC 32, making gdallocationinfo an official GDAL utility, installed by default, documented and supported: +1 (Assuming you've meant to say I am now motioning to adopt... ;-) Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] status of the OGR Norwegian SOSI support
Hi, I need to clarify the things a little bit. Actually the compiled binaries for the FYBA library are downloadable from here: http://www.statkart.no/nor/SOSI/Program/ However this version depends on the Visual Studio 2005 Win32 CRT libraries (msvcr80.dll) which would provide at the most to include this in release-1400-gdal-mapserver.ziphttp://vbkto.dyndns.org/sdk/release-1400-gdal-mapserver.zip but in my preference all of the packages should support each drivers for gdal equally well. I would also continue to avoid mixed CRT dependencies in the packages which is unsupported by Microsoft, and therefore I would require either of the following options to be provided by the author of the library: 1. Compiled binaries for all platforms x32/x64 from MSVC2003 up to MSVC2010 2. The source files which can be compiled by myself with these compilers Currently none of the options above are available as far as I know. Further issue may be due to my limited knowledge about the licensing terms of this library, I can see a .txt file in the package but it's not in that language which I can easily understand. Best regards, Tamas 2010/11/4 lucvanlinden luc.vanlin...@gmail.com Does anyone know the status of the OGR Norwegian SOSI support? Tamas Szekeres, confirmed it is not being included in the daily built binaries as the SOSI support depends on a missing FYBA binaries, which seems to be the last reference in this ticket: http://trac.osgeo.org/gdal/ticket/3638#comment:1 tx Luc -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/status-of-the-OGR-Norwegian-SOSI-support-tp5705081p5705081.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: RFC 7 - Use VSILFILE for VSI*L Functions
+1 Tamas 2010/10/26 Even Rouault even.roua...@mines-paris.org Folks, Motion: I move to adopt RFC 7: Use VSILFILE for VSI*L Functions. http://trac.osgeo.org/gdal/wiki/rfc7_vsilapi Starting with my +1 Best regards, Even ___ 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
Re: [gdal-dev] About new GDAL/OGR drivers
Hi All, FYI: I've added the required dependencies for the OpenJPEG and GeoPDF drivers to all the development packages available at: http://vbkto.dyndns.org/sdk/ so all the new drivers mentioned below can now be tested against the recent GDAL SVN daily builds. If you encounter any issues feel free to provide a feedback. Best regards, Tamas 2010/9/6 Even Rouault even.roua...@mines-paris.org Hi all, I've neglected to mention a few of the GDAL/OGR drivers that I have recently added into trunk since 1.7 release. For those that like doing early testing and write useful bug reports so that those new drivers are in shape for the 1.8.0 release, here's a summary : GDAL drivers : * HF2/HFZ ( http://gdal.org/frmt_hf2.html ) : heightfield raster datasets that can be compressed. Read/write support. * JP2OpenJPEG ( http://gdal.org/frmt_jp2openjpeg.html ) : another (the 5th!) JPEG2000 driver, based on the open-source OpenJpeg library (BSD-licenced). More potential than Jasper with big images, but depends on an (yet) unreleased development branch of OpenJpeg. Read/write support. * XYZ ( http://gdal.org/frmt_xyz.html ) : to access simple gridded ASCII files. Read/write support. * GeoPDF ( http://gdal.org/frmt_geopdf.html ) : to extract both georeferencing and rasterize PDF documents, that have georeferencing encoded in either of the 2 current existing ways : the OGC GeoPDF encoding best practice (promoted by TerraGo), or according to the Adobe Supplement to ISO 32000. Read-only, based on poppler library (GPL-licenced) OGR drivers : * GPSBabel ( http://gdal.org/ogr/drv_gpsbabel.html ) : leverages the capabilities of the GPSBabel utility (GPL-licenced) to read/write many GPS file formats. * OpenAir ( http://gdal.org/ogr/drv_openair.html ) and SUA ( http://gdal.org/ogr/drv_sua.html ) : 2 fairly equivalent and special-purpose drivers to read text files describing Special Use Airspaces. * PDS ( http://gdal.org/ogr/drv_pds.html ) : another fairly specialized driver to extract tabular information from NASA PDS (Planetary Data Systems) files * PGDump ( http://gdal.org/ogr/drv_pgdump.html ) : I believe I alrealdy mentionned that one. A write-only driver to generate SQL dump files that can be later injected into a live PostgreSQL instance. More or less similar to PostGIS shp2pgsql utility * WFS ( http://gdal.org/ogr/drv_wfs.html ) : a WFS/WFS-T client that can read and write OGC WFS 1.0.0 and 1.1.0 services. The GML driver was also significantly upgraded, in particular to support more GML3 geometries, more complex documents with non-flat structures and various tweaks that help reading some GML application schemas (CityGML, AIXM) etc... For more details about that... and the work done by all the others GDAL contributors, you can have a look at the preliminary NEWS : http://trac.osgeo.org/gdal/browser/trunk/gdal/NEWS How testing those new stuff ? - Unix/Linux users : checkout GDAL svn trunk (or daily snapshot from http://gdal.org/daily/ ), configure, make, make install ;-) - Windows users : build from source, or use for example Tamas Szekeres' daily builds at http://vbkto.dyndns.org/sdk/ (Note that those builds don't currently include JP2OpenJPEG and GeoPDF due to the external dependencies). I believe that gdal-dev in osgeo4w has also been recently updated with a 1.8.0dev snapshot. Have fun, Even ___ 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
Re: [gdal-dev] building with PDF driver on Windows + ?
Hi poppler gurus, I've also compiled poppler.lib (version 0.14.4) with various versions of MSVC, but it seems to generate double free memory corruptions in gdal. A single run of pdf.py (from the autotest suite) seems to complete successfully, however running the script multiple times (in a batch) could eventually generate a crash. Has anyone run into the same issue? Best regards, Tamas 2010/10/17 Joaquim Luis jl...@ualg.pt On 17-10-2010 19:24, Brent Fraser wrote: Joaquim, Many thanks for the info. I may go the kde-win32 route for now to skip the building of poppler.lib, but I expect that eventually I may need to build it from source, especially for mapserver. Right, and From memory, as I don't find the CMake cash with exact details. obviously I meant cache not cash ___ 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] OGR SQL for insert/update/delete operations
Hi All, Do we have any plan to extend OGR SQL for insert/update/delete operations? Would this idea be reasonable to implement? I would think something about mapping those commands to the corresponding CreateFeature/SetFeature/DeleteFeature methods of the OGR layers. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
