Hello,
Found out answer to question 1 it seems.
By naming the object for each action, then deleting it at the end of
the loop, it seems that the file is being written properly.
geot=result.SetGeoTransform( geoT )
proj=result.SetProjection( proJ )
output=driver.CreateCopy(
You should provide further info about your environment:
1. Did you test your app by running from an IDE like VS2005 for example?
2. What version of OS/IIS you intend to use when deploying the application.
You appdir and platform configuration (32/64) may be different depending on
your environment
Tamas,
I'm creating web services. This is first go on 64 bit machine - plenty of
32 bit web services to fall back on. The problem is I was using FDO which
as far as I know has only 32 bit compiled code. So I set the 'Enable 32 Bit
Application' to true, published the application, then tried to
What kind of application you develop Console/WinForms/ASP.NET ?
Wouldn't it be sufficient to use 32 bit binaries and compile your app with
the /platform:x86 option?
Best regards,
Tamas
2009/2/12 Tri
>
> Hi Tamas and others - thanks for the help.
>
> By application executing directory - I'v
Hi Tamas and others - thanks for the help.
By application executing directory - I've copied the files to both the bin
directory under the project and the obj, Debug directory under the project.
When I run the application in debug mode, the same problem occurs:
System.TypeInitializationException
Tyler Mitchell had a follow-up post to that original post, that's also
very relevant:
http://spatialguru.com/ideas/data_cataloguing_background
And there were some related discussions last May in the GeoNetwork list:
http://n2.nabble.com/SMET-(Spatial-Metadata-Extraction-Tool)-td2020014.html
But t
Here's a post which may help: http://spatialguru.com/code/xml_catalogue_format
..Tom
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org on behalf of Jonathan Greenberg
Sent: Wed 11-Feb-09 16:50
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Open source GIS cataloging software?
Jonathan,
Provided that you have some basic scripting/coding abilities, GDAL/OGR would
certainly be able to solve your need. Python might be a good choice, as you
can use the GDAL/OGR bindings. Or just use the C API.
For retrieving the boundings boxes:
Key API for raster part : gdal.Open(), Dat
Jan,
I concur with Jukka's analysis. Your need is rather uncommon, and I also
thinks it shouldn't be a default behaviour. However, adding that capability
to gdal_translate is quite easy. I've attached a patch for gdal_translate.cpp
that adds the capability of adding the 4 corners as 4 additiona
Sorry for the cross-posting. I was wondering if anyone has a unix (preferably)
or windows program that can spider a directory, recursively searching for
raster and vector data, and create bounding box polygons for each raster/vector
it finds, with attributes indicating the path-to-file.
--
J
Konstantin,
My understanding of the current state of GDAL 1.6.0 regarding those 2 RFCs
is :
- RFC #5 has never been implemented, not even proposed to vote. The meaning of
the terms 'development', 'adopted', etc is given at the bottom of the RfcList
page
- RFC #23 has been implemented, at leas
Matthew,
For the record, I just commited yesterday in GDAL SVN trunk a substantial
update to the java bindings I was mentionning. Now all necessary typemaps
have been created, so it looks rather good (no more SWIGTYPE_p_* classes). I
would be interested in having early feedback from people alre
Thanks Evan. It turned out the problem had to do with including HDF4 and
HDF5 support. Once I removed those the binding worked.
I had used the instructions at
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions and will
update them for the newer program versions.
Matt
Even Rouault
Jan Hartmann uva.nl> writes:
>
> Sorry to keep moaning about this, but I need an indication what's going
> on here. Mind, I don't need an immediate solution: for the time being I
> have a workaround. Just an idea whether this a real problem, a dumb
> question, something that can be handled in
Hi,
You might have to copy all of the dll-s (*_csharp.dll, *_wrap.dll,
gdal16.dll, proj.dll etc.) to the application executing directory.
Best regards,
Tamas
2009/2/11 Tri
>
> Can't get GDAL / OGR to work with CSharp. Using the CSharp dlls, I keep
> getting exceptions like:
>
> OgrPINVOKE,
What is the full message of the exception ?
Did you copy all the dll of GDAL ? The C# dlls are just wrappers around the
GDAL dlls.
Regards,
Benoît Andrieu
b...@ixsea.com
benoit.andr...@gmail.com
- Original Message -
From: "Tri"
To:
Sent: Wednesday, February 11, 2009 2:41 PM
Subjec
Can't get GDAL / OGR to work with CSharp. Using the CSharp dlls, I keep
getting exceptions like:
OgrPINVOKE, threw an exception.
TO TRY TO GET TO WORK I DID:
- Copied the csharp dlls into project,
- Created a reference to the dlls.
What am I doing wrong?
--
View this message in context:
Sorry to keep moaning about this, but I need an indication what's going
on here. Mind, I don't need an immediate solution: for the time being I
have a workaround. Just an idea whether this a real problem, a dumb
question, something that can be handled in the foreseeable future (or
not), perhaps
Hi!
There are two RFCs regarding the Unicode issues:
RFC #5: http://trac.osgeo.org/gdal/wiki/rfc5_unicode
RFC #23: http://trac.osgeo.org/gdal/wiki/rfc23_ogr_unicode
RFC #23 seems to be adopted for GDAL 1.6. But to me it is not that clear,
which functions/me
Joaquim Luis wrote:
>
>
>
> gdalwarp EarthMap_2500x1250.jpg -s_srs +proj=latlong -t_srs +proj=laea
> EarthMap_2500x1250.jpg dest.jpg
>
> Which will show ... another manifestation of the gdalwarp bug
> (http://trac.osgeo.org/gdal/ticket/2305)
> when dealing with global files
>
> Joaquim Lui
20 matches
Mail list logo
