Do you see page file activity? If you look at /proc/pid/smaps, you
should be able to see the actual status of the mapping of your data
file. Probably it is consuming a large number of pages of RAM, but
also there should be zero pages written to swap. All clean private or
clean shared, zero anony
Le jeudi 19 décembre 2013 00:50:06, Paul Ramsey a écrit :
> I've updated my working branch to match your intent more closely, I hope
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> the iso enumeration is no longer there, and access to iso geometry
> types is via a protected method only.
Yes,
I've updated my working branch to match your intent more closely, I hope
https://github.com/pramsey/gdal/tree/isowkb
the iso enumeration is no longer there, and access to iso geometry
types is via a protected method only.
The reason I asked about GDAL2 is that some of the stuff in OGR seemed
new
Le mercredi 18 décembre 2013 21:09:48, Trent Piepho a écrit :
> On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault
>
> wrote:
> > Le mercredi 18 décembre 2013 19:53:37, Frank Warmerdam a écrit :
> >> I imagined an available virtual method on the band which could be
> >> implemented - primarily by the
On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault
wrote:
> Le mercredi 18 décembre 2013 19:53:37, Frank Warmerdam a écrit :
>>
>> I imagined an available virtual method on the band which could be
>> implemented - primarily by the RawBand class to try and mmap() the data and
>> return the layout. But
On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault wrote:
> > I'm wondering if there would be
> > ways of making what you propose work with Python Numpy in such a way
> that a
> > numpy array could be requested which is of this virtual memory. That
> would
> > also be a nice extension.
>
> Hum, how
On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault wrote:
> Le mercredi 18 décembre 2013 19:53:37, Frank Warmerdam a écrit :
> > Even,
> >
> > Sorry, I was thinking of mmap() directly to the file, and having
> something
> > like:
> >
> > CPLVirtualMem CPL_DLL* GDALBandGetVirtualMemAuto( GDALRasterBan
Le mercredi 18 décembre 2013 19:53:37, Frank Warmerdam a écrit :
> Even,
>
> Sorry, I was thinking of mmap() directly to the file, and having something
> like:
>
> CPLVirtualMem CPL_DLL* GDALBandGetVirtualMemAuto( GDALRasterBandH hBand,
> int *pnPixelSpace
Even,
Sorry, I was thinking of mmap() directly to the file, and having something
like:
CPLVirtualMem CPL_DLL* GDALBandGetVirtualMemAuto( GDALRasterBandH hBand,
int *pnPixelSpace,
GIntBig *pnLineSpace,
Hi Dennis,
I'd like to take up your offer. This looks like a small enough job. I can
use the gdal_polygonize algorithm to process all the areas with a value
other than nodata value.
Please email me the details and sample data if you would like me to work on
it.
--
Best regards,
Chaitanya Kumar C
I have a python script that I need to convert existing geotiffs to poly
KML files. The existing files are multi-colored, and all I want is any
colored area, vs the background color.
If you are interested, we can pay via paypal, send me your hourly rate
and when you are free via e-mail! We
Le mercredi 18 décembre 2013 06:55:50, Frank Warmerdam a écrit :
> Even,
>
> Very impressive work, I am supportive.
>
> IMHO it would be wonderful if there was also an mmap() based mechanism
> where you could ask for the virtual memory chunk and you get it back (if it
> works) along with stride v
Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
> I don't think we should expose the ISO geometry types to the world,
> they're just for WKB really, so I'll keep that part hidden away. It's
> a shame we can't get rid of the 25d type variants for gdal2... if not
> then, when?
Ah, I did
13 matches
Mail list logo
