Yilmaz,
I'll leave the GEOS / Windows compilation bit to those who know! However, I
can help on the nearest neighbour issue as I have done some research in this
area. To do it properly is non-trivial: indeed, it is effectively a Dirichlet /
Voronoi tessellation problem. For an outline an
Bump to avoid the issue from remaining unsolved.
-
Using 1.6.0 on Vista. All answers must be in DOS batch file format.
--
View this message in context:
http://n2.nabble.com/GDAL-ignores-explicitly-defined-nodata-value-tp3720196p3753058.html
Sent from the GDAL - Dev mailing list archive at N
Hi Paul,
I'm using pretty much the same preproc definitions
WIN64;WIN32;NDEBUG;_WINDOWS;_USRDLL;UNICODE;_MBCS;LIBECWJ2;QT_DLL;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE
However I'm not sure exactly what else have been done in order to get
it to run smoothly. As far as I remember we've got
Tamas, Mateusz and Rob,
Thanks for all your help.
It seems I can now successfully build to 64Bit.
In my first attempt I replaced Win32 with Win64 in the Preprocessor
Definitions.
That gave me the "unknown machine type will require custom 64 bit variables"
error.
When I restored Win32 I got the __a
Yilmaz Arslanoglu wrote:
If you specify a point to OGRLayer::SetSpatialFilter() you should only
get back features that intersect that point.
Then do you have an idea how the "intersect" would behave between
a line string and a point? (I would expect TRUE if the point lies on
any of the line str
Hi Frank;
> Make sure you do a "nmake /f makefile.vc clean" after any change to
Thank you very much, actually I should have already thought this before :)
Now it runs quite OK.
> If you specify a point to OGRLayer::SetSpatialFilter() you should only
> get back features that intersect that point.
Hi Tamas and Mateusz
Your time on helping us much appreciated. I am working with Paul in the
MapWindow team and I implemented the macro fix to libecwj2 a few months ago
(by strange coincidence I also chose NCS_ as the prefix).
libecwj2.dll compiles fine in VS2008 in WIN32, but we are experiencin
Yilmaz Arslanoglu wrote:
Hi;
I am trying to build and install the GDAL library on Windows XP
using the following commands:
nmake /f makefile.vc
nmake /f makefile.vc install
nmake /f makefile.vc devinstall
In order to build with GEOS support, I uncommented the lines
in the "nmake.opt"
Hi;
I am trying to build and install the GDAL library on Windows XP
using the following commands:
nmake /f makefile.vc
nmake /f makefile.vc install
nmake /f makefile.vc devinstall
In order to build with GEOS support, I uncommented the lines
in the "nmake.opt" as follows:
GEOS_DIR=C:\ge
2009/10/1 Mateusz Loskot :
>
> A side note, I'm not sure it's legal to publish this source code.
>
I don't intend to publish that, just for tracking this issue down, it
will be removed soon.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists
Tamas Szekeres wrote:
> Mateusz,
>
> I don't remember if I had to patch ecw this way to compile on Win64.
The problem does not seem to be related to 32 vs 64-bit.
It is related to scope-less Windows API macros as identified here:
http://lists.osgeo.org/pipermail/gdal-dev/2009-July/021393.html
A
Mateusz,
I don't remember if I had to patch ecw this way to compile on Win64.
I've uploaded the package I'm using which compiles well with VS2008
http://vbkto.dyndns.org/tests/libecwj2-3.3-VC9.rar
Just open the solution file in Source\NCSBuildQmake and rebuild.
You could diff it to your version
Chris Emberson wrote:
Thanks for the reply.
Do you have any idea when 1.7.0 will be released?
Or can you advise the procedure for backporting?
IIRC, I didn't do anything special, just:
svn checkout http://svn.osgeo.org/gdal/trunk/gdal gdal
cd gdal
./configure
make
cd $HOME/bin
ln -s path
Mateusz Loskot wrote:
> Paul Meems wrote:
>> GDAL is compiling great, except when using libecwj2.dll. Because I can
>> 't compile the libecwj2 library for Win-64Bit.
>> In some of the header files is stated when compiling to a 64-Bit
>> version raise an error.
>
> What errors?
>
> It's said to sa
Thanks for the reply.
Do you have any idea when 1.7.0 will be released?
Or can you advise the procedure for backporting?
> Date: Tue, 29 Sep 2009 20:09:23 +0200
> From: pei...@gmx.eu
> To: even.roua...@mines-paris.org
> CC: chrisember...@hotmail.com; gdal-dev@lists.osgeo.org
> Subject: Re: [gda
Jukka,
it depends upon what your desired result is. If you just want to replicate
maps, the answer might differ from seeking to work with the information
contained within the maps. Either way, if your data is going to exceed 6GB, you
probably ought to be looking to one of the DBMS soluti
Hi list
Craig Leat:
> I need to investigate further, but I am suspecting that this issue may
> be specific to the MrSid format.
I have tested further and can report as follows:
1. I have 24 MrSid files with overview levels 2 4 8 16 32 64 128
2. I can point QGIS to the directory and load all these
Hi,
I am combining some GIS data where each layer is divided to around thousand
separare shapefiles by mapsheets. Now I would like to store all the 35000
shapefiles to something that is more easy to handle. At first pushing each layer
to own Spatialite database feeled perfect, but I have problems
18 matches
Mail list logo
