Mateusz Loskot
Thanks!! I'll keep this in mind. It's really important to good performance.
2009/3/29 Joaquim Luis
> Thankx
>
> I'll keep this in mind if I ever one day start practicing C++
> For the time being, only good old C.
>
> Joaquim
>
> Joaquim Luis wrote:
>>
>>> Mateusz Loskot wrote:
>>
Hi,
> Perhaps, the problem is with the colon (:) in the path. There may be
If that is the case, I filed that ticket two months ago and Even has
fixed it already http://trac.osgeo.org/gdal/ticket/2823 but maybe it is
not on that build.
Ivan
Chaitanya kumar CH wrote:
apachemaven,
2009/3/27
Mike,
That's a good idea, but not really well accepted in many cases...
In my particular case I ended up changing my tables to varchar2...
We'll have to wait for unicode support in ogr.
Thanks,
Duarte
De: Michael Smith [michael.sm...@usace.army.mil]
Envi
Joaquim Luis wrote:
> Thankx
>
> I'll keep this in mind if I ever one day start practicing C++ For the
> time being, only good old C.
You are welcome.
Simply, best thing is to always use pre-increment, regardless
if working with pointers, integers or iterators.
Then there is no need to remember
Hi,
I'm a bit off-topic, but is this new driver the jpip driver described in
RFC_24 (http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support)? If so,
that's great news, does it use Kakadu for its implementation ?
Best regards.
Norman Barker wrote:
> Hi,
>
>
> I have written a gdal
Thankx
I'll keep this in mind if I ever one day start practicing C++
For the time being, only good old C.
Joaquim
Joaquim Luis wrote:
Mateusz Loskot wrote:
for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw !=
_roadwayArr.end();itrw++)
++itrw;
if you care about performa
Joaquim Luis wrote:
> Mateusz Loskot wrote:
>
>>> for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw !=
>>> _roadwayArr.end();itrw++)
>>
>> ++itrw;
>>
>> if you care about performance.
>
> Mateusz,
>
> Just curious. Why should that impact on performance?
The itrw here is most
mohwawang wrote:
> If you know that the technical problem can not be resolved easily
> (for example, if the deep part of the algorithm is based on 8bit and
> it needs a new algorithm for 16bit) then you have little incentive to
> negotiate the license.
In order to be sure if something is feasible
Norman Barker wrote:
Hi,
I have written a gdal driver and would like to hook this into an
existing viewer (public domain) to demonstrate the code. The driver
makes a fair few changes to the GDAL API so it isn’t as simple as just
adding to the format list.
Would I be better to use openev
Even,
Thank you for telling me the reason why GDAL does not support Jasper for
reading a NITF file and how to hack that. How about writing (instead of
reading) a Jasper compressed image into NITF?
I want to be able to write out not read in a JPG2000 compressed NITF file. (My
input image is a
If you know that the technical problem can not be resolved easily (for example,
if the deep part of the algorithm is based on 8bit and it needs a new algorithm
for 16bit) then you have little incentive to negotiate the license.
Mo
--- On Sat, 3/28/09, Mateusz Loskot wrote:
> From: Mateusz Lo
Mateusz Loskot wrote:
for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw !=
_roadwayArr.end();itrw++)
++itrw;
if you care about performance.
Mateusz,
Just curious. Why should that impact on performance?
Joaquim Luis
___
gdal-d
apachemaven,
2009/3/27 apachemaven :
> I want to translate the hdf4 to tif ,and use the grass to conert this tif to
> its own format, then I can contiune my next work, I use the FWTools2.2.8
> (which is installed in the F disk.)to handle this,after config the
> environment ,I run the command "gdal
Thanks Tamas,
I have a ton of info, and logs, from the various combinations of things I've
tried. I can provide the output .so libraries if you think it will help.
I did one interesting experiment where I included gdal_wrap.cc in the
compilation of "libgdal.so". This exposed the bindings dir
legeochen wrote:
> Hi All
> I try to create some multipolygons with OGR. After creating them, but
> when I want view them in arcscene, it just make arcscene crash! Then I
> tried osgviewer with ESRI Shapefile, I was warned:
> ESRIShape loader: .dbf file containe different record number that .shp
>
mohwawang wrote:
> Mateusz,
>
> License issue can be resolved through negotiation.
Then try to solve it first, before digging the source code.
Otherwise, you will waste your time.
> Then back to the
> technique issue: Is it a big thing to change ECW to support 16-bit
> imagery?
IMHO, unless the
Mo,
NITF driver cannot use Jasper for reading JPEG2000 compressed NITF images,
because Jasper doesn't support decoding an image that is located at an
arbitrary offset inside a file. (At least, that's the first reason why it
can't work.). I imagine that if you badly want to use Japser, you could
Ivan,
It seems that both you and me guess that it is a big thing to change the source
code of ECW SDK to support 16bit imagery.
So, forget about ECW. How about another jpeg2000 package, Jasper, which
(1)supports 8bit and 16bit and (2)is an open source. GDAL has a driver for
Jasper jpeg2000.
Hi Frank,
I've got your build outputs but I still didn't have the chance to inspect
the issue in more detail. I'll get back to you with further information
shortly.
I just wanted to mention thet the buildbot didn't require to have elevated
privileges to build gdal and the SWIG bindings, however so
19 matches
Mail list logo
