nice to learn something new.
Yours
Tomas
Jürgen E. Fischer skrev 2010-07-21 13:05:
Hi Tomas,
On Wed, 21. Jul 2010 at 12:50:31 +0200, Tomas R wrote:
is that really as it should be? Should really the result depend on files
from the environment it was compiled in? Must I go back to VSE2008 and
environment it was compiled in? Must I go back to VSE2008 and
recompile Gdal to make it work on all machines or is there a setting
somewhere...
Yours
Tomas
Tomas R skrev 2010-07-21 09:25:
I have a Gdal-plugin for the eminent program SportTracks. This plugin
gives access to the Gdal libraries for other
I have a Gdal-plugin for the eminent program SportTracks. This plugin
gives access to the Gdal libraries for other plugins of the program.
Works great, normally.
But on some, or possibly all, WinXP computers it fails. It fails setting
up the environment for the plugin, the path.
The plugin i
se in your
application if that is going to be helpful for you.
-F
On 8 July 2010 16:53, Tomas R wrote:
You mean
area_of_use_code="2847"
which gives
http://www.lm.se/geodesi/refsys/rt/rt_projections.html"; data_source="EPSG"
revision_date="2003-06-27" deprecated=
u.
-F
On 8 July 2010 16:53, Tomas R wrote:
You mean
area_of_use_code="2847"
which gives
http://www.lm.se/geodesi/refsys/rt/rt_projections.html"; data_source="EPSG"
revision_date="2003-06-27" deprecated="0"/>
Or is it from this line
<302
plan is to switch to WGS84 which seems to
work even though results can be interesting in the boundary between the
coordinate systems.
But still, if the info already exists somewhere why not use it but I do
not know if that info exist in the data I have available.
Thanks anyway
Tomas
Francis
?
Yours
Tomas
Tomas R skrev 2010-07-05 09:05:
Attacking GDAL via the C# interface and I have a question
Have set up two (Osr) SpatialReferences and transformations to and
form both. One system is WGS84 and the other is unknown.
To get a consistent behaviour I need to retrieve the boundary, in
and it works, as expected, as it should.
Thanks.
Tomas R skrev 2010-07-07 20:29:
nice :)
thanks.
Even Rouault skrev 2010-07-07 19:52:
Le Wednesday 07 July 2010 18:58:45 Tomas R, vous avez écrit :
The fix in
http://trac.osgeo.org/gdal/changeset/19985
I can download and replace the file
nice :)
thanks.
Even Rouault skrev 2010-07-07 19:52:
Le Wednesday 07 July 2010 18:58:45 Tomas R, vous avez écrit :
The fix in
http://trac.osgeo.org/gdal/changeset/19985
I can download and replace the file in the 1.7.2 version of gdal I have
and compile gdal again and it will work?
Yes it
The fix in
http://trac.osgeo.org/gdal/changeset/19985
I can download and replace the file in the 1.7.2 version of gdal I have
and compile gdal again and it will work?
Or should I wait for 1.7.3?
Yours
Tomas
Tomas R skrev 2010-07-06 20:02:
So a solution/a fix is available when 1.7.3 is
data loss as i does fit in a
GByte...
Best regards,
Even
Le Tuesday 06 July 2010 19:18:56 Tomas R, vous avez écrit :
The reason for the out of memory exception was because the RIK-map I
tested with i wasfar to big to be read into a bitmap. I have now created
a smaller sample.
With the
se
a ticket at http://trac.osgeo.org/gdal/newticket
On Tue, Jul 6, 2010 at 6:43 PM, Tomas R <mailto:mon...@home.se>> wrote:
I add - perhaps a problem with my comilation of Gdal. Note when
I compile the GdalReadDirect.cs as it is and run it the result
differs from the
hangs and I have to abort it.
What have I done wrong this time?
Will try to recompile gdal and see if anything changes.
Tomas R skrev 2010-07-06 14:16:
I have a problem with RIK-maps and Gdal 1.7.2.
If I use Gdal 1.6.1 I have no problem reading the map but doing the
same with Gdal 1.7.2 my
I have a problem with RIK-maps and Gdal 1.7.2.
If I use Gdal 1.6.1 I have no problem reading the map but doing the same
with Gdal 1.7.2 my whole plugin/software hangs.
I have identified that Gdal stops at the line
band.ReadRaster(x, y, width, height, r, width, height, 0, 0);
where x, y, wi
Attacking GDAL via the C# interface and I have a question
Have set up two (Osr) SpatialReferences and transformations to and form
both. One system is WGS84 and the other is unknown.
To get a consistent behaviour I need to retrieve the boundary, in WGS84
coordinates, of the unknown system. I
Set
@SET FrameworkVersion=v2.0.50727
in vcvars32.bat seems to work...
Yours
Tomas
Tomas R skrev 2010-07-01 13:01:
Ok, will download that version done... and it compiled ok. As
simple as that :)
How about the target platform? Should be easy to set it to .Net2 but
how? Now it compiles
12:41:
Tomas,
You should use SWIG 1.3.39. The bindings haven't been tested with SWIG
2.0.0. Upgrading SWIG always cause much of pain...
Best regards,
Tamas
2010/7/1 Tomas R mailto:mon...@home.se>>
Back again trying to compile gdal and the C# interface. This time
wi
Back again trying to compile gdal and the C# interface. This time with
VSE 2010, Gdal 1.7.2 and Swig 2.0.0 on a Vista32 machine
Gdal compiles fine, no problems, but the C# bindings fail with the
following error when using nmake:
csc /platform:x86 /target:library /out:gdal_csharp.dll
Installed .Net2 SDK on my Vista machine and compiled it via that
installation and it worked. But should it not be doable on a .net3.5
installation? From GUI editor (VSE 2008) it is, should also be via the
command line.
Yours
Tomas
Tamas Szekeres skrev:
2009/8/18 Tomas R mailto:mon
fine, but to .Net 3.5.
An environment setting? or?
Tamas Szekeres skrev:
2009/7/17 Tomas R mailto:mon...@home.se>>
Hi again
Seems like I have solved the problem... the line
such as preprocessing the grid shift file into binary form.
gave me (finally) the hint I
the binary files from FWTools and
finally I got it working.
Compiling the shift files on Windows? How? Well, not at big issue at the
moment.
Yours
Tomas
Frank Warmerdam skrev:
Tomas R wrote:
Hi again,
New problems arises as the world of Gdal is quite complex to grasp.
Have understood that
compiling also the nadshift
files? Nope, do not work.
Well, one option that always works, I grabbed them from FWTools...
Yours
Tomas
Frank Warmerdam skrev:
Tomas R wrote:
Hi again,
New problems arises as the world of Gdal is quite complex to grasp.
Have understood that the transformation of
no one?
To bad, well, I will see what I can do on my own.
/Tomas
Tomas R skrev:
I have no luck
Downloaded compiled package form http://vbkto.dyndns.org:1280/sdk/
(MSVC2008 (Win32) -stable, v 1500).
I set the path as described before, that is:
nadPath =
Path.Combine(Path.GetDirectoryName
ode above be enough?
A friend did a test in Python and he could do the transform, but that is
no big help for me.
Any ideas what I miss or what I should test?
/Tomas
Frank Warmerdam skrev:
Tomas R wrote:
Hi again,
New problems arises as the world of Gdal is quite complex to grasp.
Have underst
Note, the previous used (unknown version at this time) do not throw that
error, any error than the erroneous result that is.
Thank for the, as always, quick and informative reply.
Yours
Tomas
Frank Warmerdam skrev:
Tomas R wrote:
Hi again,
New problems arises as the world of Gdal is qu
Hi again,
New problems arises as the world of Gdal is quite complex to grasp.
Have understood that the transformation of coordinates from Nad 27 datum
to WGS 84 requires some look up tables to be done correctly, tables that
differ with the are the Nad 27 is valid in.
Simple question is, how
s I should give
up compiling gdal myself?
Thanks for the quick and very good answers both of you.
Yours
Tomas
Tamas Szekeres skrev:
2009/6/30 Tomas R mailto:mon...@home.se>>
Trying to update my plugin to SportTracks that makes it possible
for other plugins to the great progra
Hi again, time for a new question
First of, Q is regarding the C# environment.
Trying to update my plugin to SportTracks that makes it possible for
other plugins to the great program to make use of Gdal. Currently the
plugin uses Gdal 1.5.1 and the plan is to move to 1.6.1
There seem to not b
p.dll and recompile the project.
Best regards,
Tamas
2009/3/7 Tomas R mailto:mon...@home.se>>
Thanks, it works. Just set the path.
Proj4 I think I will grab from your compilation. Should work good
enough. I will compile GDAL myself to keep it minimal. Only need
the Proj4
Thanks, it works. Just set the path.
Proj4 I think I will grab from your compilation. Should work good
enough. I will compile GDAL myself to keep it minimal. Only need the
Proj4 library as far as I know.
Sadly, it seems a straight upgrade from, 1.5 is not possible. That is,
my use of GDAL is
running in x86 mode by default.
Best regards,
Tamas
2009/3/6 Tomas R mailto:mon...@home.se>>
Tamas, remember the detective work done last year.
32 bit C# interface won't mix at all with 64 bit runtime
environment. or have you found a way around that? have not
foll
orkDir%\%FrameworkVersion%;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIBPATH%
Best regards,
Tamas
PS: You could also download the recent SDKs or precompiled binary
packages for various compiler versions from this lo
Tamas, remember the detective work done last year.
32 bit C# interface won't mix at all with 64 bit runtime environment. or
have you found a way around that? have not followed the list for some
time, just now trying to create a 64-bit version of gdal.
Yes, I have a problem too, and yes a q ha
Trying to build a 64 bit version of GDAL on a Vista 32 bit installation
using Visual Studie Express C++ 2008.
So how do I do, and how does it go.
I start up the Visual Studio 2008 x64 Cross Tools Command Prompt. I set
in nmake.opt WIN64= YES
With this GDAL seems to compile ok, no errors and al
34 matches
Mail list logo
