LizardTech has released MG4 LiDAR Decode SDK 1.0.1
when will GDAL support this library?
Thanks,
Paul
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi list,
I've been trying to debug my problem which I originally posted on
mapserver-users here:
http://lists.osgeo.org/pipermail/mapserver-users/2009-November/063706.html
I've debugged the problem to the following part of
frmts/sde/sderasterband.cpp:
if (bits_per_pixel >= 8) {
memc
Hi Cor,
in ArcMap I see negative values, in GDAL all values seem to have a shift
of 256, so -21 becomes 235. Nodata values are also off with 256, so -256
in ArcMap becomes 0 in GDAL.
Best regards,
Bart
> Hi Bart,
>
> On Tuesday 08 December 2009 10:45:25 bart...@osgis.nl wrote:
>> I've debugged t
Sorry I meant Kor ofcourse :-)
Btw, the GByte *p = reinterpret_cast(pImage); line was a paste
error from my debugging, it's also not in 1.6.1 which I am using.
Best regards,
Bart
> Hi Cor,
>
> in ArcMap I see negative values, in GDAL all values seem to have a shift
> of 256, so -21 becomes 235.
bart...@osgis.nl wrote:
Hi list,
I've been trying to debug my problem which I originally posted on
mapserver-users here:
http://lists.osgeo.org/pipermail/mapserver-users/2009-November/063706.html
I've debugged the problem to the following part of
frmts/sde/sderasterband.cpp:
if (bits_per_
Hi Ivan,
unfortunately that's not an option yet, since we use ArcSDE 9.1 which is
not compatible with GeoRaster. We need to wait until our 9.3.1 or 9.4
upgrade.
Best regards,
Bart
> bart...@osgis.nl wrote:
>> Hi list,
>>
>> I've been trying to debug my problem which I originally posted on
>> map
Hi Bart,
On Tuesday 08 December 2009 10:45:25 bart...@osgis.nl wrote:
> I've debugged the problem to the following part of
> frmts/sde/sderasterband.cpp:
>
> if (bits_per_pixel >= 8) {
> memcpy(pImage, pixels, block_size);
> GByte *p = reinterpret_cast(pImage);
> } else {
>
Hi Bart,
On Tuesday 08 December 2009 12:33:10 bart...@osgis.nl wrote:
> in ArcMap I see negative values, in GDAL all values seem to have a shift
> of 256, so -21 becomes 235. Nodata values are also off with 256, so -256
> in ArcMap becomes 0 in GDAL.
The pixel type of your input is char (signed 8
Hi Kor,
I tried this change but with strange results. Also in Mapserver it seems
that a GByte * is used for the buffer:
LoadGDALImage( GDALRasterBandH hBand, int iColorIndex,
layerObj *layer,
int src_xoff, int src_yoff, int src_xsize, int src_ysize,
GB
Hi Bart,
On Tuesday 08 December 2009 13:53:07 bart...@osgis.nl wrote:
> I tried this change but with strange results. Also in Mapserver it seems
> that a GByte * is used for the buffer:
>
> LoadGDALImage( GDALRasterBandH hBand, int iColorIndex,
>layerObj *layer,
>in
Hi,
I was searching fro a good sample how I can import a file called
'LINE5001.shp' (linear feature class) into a predefined schema of an SDO
layer in 'USER1' schema into the 'LINE1' table? TNS name is 'ORCL'.
Geometry field is called 'GEOM' and the SRID for the SDO layer is set to the
value '50
On Dec 8, 2009, at 3:41 AM, Paul Meems wrote:
> LizardTech has released MG4 LiDAR Decode SDK 1.0.1
> when will GDAL support this library?
It most likely won't, at least not without a giant update to support some sort
of point patch or lidar data model within either GDAL or OGR. And even then,
On Dec 8, 2009, at 6:21 AM, Kor de Jong wrote:
> Hi Bart,
>
> On Tuesday 08 December 2009 12:33:10 bart...@osgis.nl wrote:
>> in ArcMap I see negative values, in GDAL all values seem to have a shift
>> of 256, so -21 becomes 235. Nodata values are also off with 256, so -256
>> in ArcMap becomes
Dejan Gregor GMAIL.COM> writes:
> Hi,
>
> I was searching fro a good sample how I can import a file called
> 'LINE5001.shp' (linear feature class) into a predefined schema of an SDO
> layer in 'USER1' schema into the 'LINE1' table? TNS name is 'ORCL'.
>
> Geometry field is called 'GEOM' and the
Hello.
Is there no gap or noises in image data generated by this
method?
Regards.
--- doug_newc...@fws.gov wrote:
>
>
>
>
> >Hi Doug,
>
> >I finally tried your parameters and they did work
> fine for me also. I
> >had something like hundred geotiffs, 400 MB each,
> and I was pushing
1.3.39 produces code that does not compile on x64 Windows (at least with MSVC).
See: http://trac.osgeo.org/gdal/ticket/2928. The ticket mentions c# bindings
but the same is true for the Java bindings. Rolling back to 1.3.38 fixes the
problem.
--
Ben
> -Original Message-
> From: gd
Benjamin,
Ticket #2928 was fixed for 1.6.1 release. Are the compilation problems
you mention still current with latest SVN trunk ? If so, you should
consider open a new ticket and mention the exact error log you get from
the compiler. But this is a bit surprising as one of our slavebots is a
Hi all,
I'm trying a simple python script to calculate the polygon areas. Are
the swig bindings for python working because is returning the geometry
type as -2147483645 the dimension and 2 for a 3d feature and the
get_Area returns a error?
#!/usr/bin/env python
from osgeo import ogr
import sys
18 matches
Mail list logo
