Re: [gdal-dev] Generating Lat, long Cordinates with bearing line and angle
Selon Phil Scadden p.scad...@gns.cri.nz: I have a *lat, lon* coordinate with a known projection system I assume it a initial point. I want to generate a next Position with the an *angle* with (horizontal/vertical) and *bearing length* in lat,lon coordinates and complete it with angles and bearing lengths to form a polygon Try http://www.movable-type.co.uk/scripts/latlong.html#destPoint However, you need to be very careful with this as calculations are being done assuming a spherical earth. Fine is distances arent large enough for the ellipsoidal effects to affect accuracy. For large distances, you need to use Vincent' s_formula - http://en.wikipedia.org/wiki/Vincenty%27s_formulae which require iteration. http://geographiclib.sourceforge.net/ has an implementation of it. Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
git-svn can be used to bridge the 2 worlds, but in my recent experience it has
been painful to use. So generating a patch and applying it is probably easier.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
--
Mateusz Łoskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
In this case, the
getXXXGeometryType()
is more logic, than
int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
Best regards,
Dmitry
18.12.2013 0:32, Even Rouault пишет:
Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported formats).
I think all ISO specific things should be internal and driver specific.
So, we will get single GDAL enum of geom types.
I don't see it a problem if we have different getXXXGeometryType() or
exportTo() methods in OGRGeometry, provided that they document well the
standard/document they implement. The ISO WKB encoding is a standard, so it
can be a legitimate interface of OGRGeometry, and could potentially be used in
several drivers ( actually if you look at OGRSpatialReference class it has a
lot of import / export methods to various exotic formats, only used by one
driver ).
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org
wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve a
RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
a getIsoGeometryType() method that returns it, and the exportToWkb()
methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported formats).
I think all ISO specific things should be internal and driver specific.
So, we will get single GDAL enum of geom types.
I don't see it a problem if we have different getXXXGeometryType() or
exportTo() methods in OGRGeometry, provided that they document well the
standard/document they implement. The ISO WKB encoding is a standard, so it
can be a legitimate interface of OGRGeometry, and could potentially be used in
several drivers ( actually if you look at OGRSpatialReference class it has a
lot of import / export methods to various exotic formats, only used by one
driver ).
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org
wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve a
RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
a getIsoGeometryType() method that returns it, and the exportToWkb()
methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 21:38:44, Dmitriy Baryshnikov a écrit :
In this case, the
getXXXGeometryType()
is more logic, than
int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
ah ok, I see your point. The idea was just a proposal to offer an helper method
to avoid typing in the exportToWkb() of each geometry subclass :
(eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
That getGeometryType(OGRwkbVariant eVariant) could be a protected method of
OGRGeometry class, so that it remains an internal implementation detail.
Best regards,
Dmitry
18.12.2013 0:32, Even Rouault пишет:
Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported
formats). I think all ISO specific things should be internal and driver
specific. So, we will get single GDAL enum of geom types.
I don't see it a problem if we have different getXXXGeometryType() or
exportTo() methods in OGRGeometry, provided that they document well
the standard/document they implement. The ISO WKB encoding is a
standard, so it can be a legitimate interface of OGRGeometry, and could
potentially be used in several drivers ( actually if you look at
OGRSpatialReference class it has a lot of import / export methods to
various exotic formats, only used by one driver ).
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org
wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve
a RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso,
... wkbGeometryCollectionIso, wkbPointIsoZ, ...
wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
returns it, and the exportToWkb() methods that calls int
getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Call for discussion on RFC 45: GDAL datasets and raster bands as virtual memory mappings
Hi, This is a call for discussion for RFC 45: GDAL datasets and raster bands as virtual memory mappings Beginning of the RFC inline (the full RFC includes a few colorful schemas !) : == Summary == This document proposes additions to GDAL so that image data of GDAL datasets and raster bands can be seen as virtual memory mappings, for hopefully simpler usage. == Rationale == When one wants to read or write image data from/into a GDAL dataset or raster band, one must use the RasterIO() interface for the regions of interest that are read or written. For small images, the most convenient solution is usually to read/write the whole image in a single request where the region of interest is the full raster extent. For larger images, particularly when they do not fit entirely in RAM, this is not possible, and if one wants to operate on the whole image, one must use a windowing strategy to avoid memory issues : typically by proceeding scanline (or group of scanlines) by scanline, or by blocks for tiled images. This can make the writing of algorithms more complicated when they need to access a neighbourhoud of pixels around each pixel of interest, since the size of this extra window must be taken into account, leading to overlapping regions of interests. Nothing that cannot be solved, but that requires some additional thinking that distracts from the followed main purpose. The proposed addition of this RFC is to make the image data appear as a single array accessed with a pointer, without being limited by the size of RAM with respect to the size of the dataset (excepted limitations imposed by the CPU architecture and the operating system) Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported formats).
I think all ISO specific things should be internal and driver specific.
So, we will get single GDAL enum of geom types.
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 45: GDAL datasets and raster bands as virtual memory mappings
Le mardi 17 décembre 2013 21:54:31, Even Rouault a écrit : Hi, This is a call for discussion for RFC 45: GDAL datasets and raster bands as virtual memory mappings Here's the link to the RFC : http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Produce noData Masks When Warping Datasets
Hi List, I am using GDALAutoCreateWarpedVRT() to warp datasets which then get transformed to bitmaps. When warping images sometimes they get rotated leaving black around the edges of the resulting image (especially when warping to another UTM zone). How can I produce images without the black edges? As far as I can tell, GDAL won't probuce bitmaps with alpha layering. I have read about GDAL's noData masks but am having trouble figuring out how to produce them. They would work well because I don't need opacity I just want to mask out the black edges when I display the bitmaps. Thanks, Jeremy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
P.
On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }
I'd be happy to hear about other GDAL developers opinion on this.
How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
git-svn can be used to bridge the 2 worlds, but in my recent experience it has
been painful to use. So generating a patch and applying it is probably easier.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
For exportToWkb(), it is just a matter of taste whether to add an optional
parameter or to have a dedicated method.
For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add an
optional parameter to return values other than OGRwkbGeometryType.
My latest proposal was to have a - protected - int
getGeometryType(wkbVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); } and a public OGRwkbIsoGeometryType
getIsoGeometryType().
P.
On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve a
RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
a getIsoGeometryType() method that returns it, and the exportToWkb()
methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
}
I'd be happy to hear about other GDAL developers opinion on this.
How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
git-svn can be used to bridge the 2 worlds, but in my recent experience
it has been painful to use. So generating a patch and applying it is
probably easier.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 17 December 2013 20:16, Dmitriy Baryshnikov bishop@gmail.com wrote: Hi, I afraid that we come to situation where: getGeometryType() getIsoGeometryType() getRFCGeometryType() ... getBlahBlahGeometryType() Why not have only one method and only one enum (as GDAL origin - single abstract data model to the calling application for all supported formats). I think all ISO specific things should be internal and driver specific. So, we will get single GDAL enum of geom types. I agree with you, in principle, that it's best if abstraction layer actually makes a common denominator, but it is in this particular case it is too late (AFAIU what Even says) and single enumeration would gather plain codes as well as bit flags, leading to further confusion in interpretation. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
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?
Incidentally, is there going to be a GDAL 1.11?
P.
On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
For exportToWkb(), it is just a matter of taste whether to add an optional
parameter or to have a dedicated method.
For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add an
optional parameter to return values other than OGRwkbGeometryType.
My latest proposal was to have a - protected - int
getGeometryType(wkbVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); } and a public OGRwkbIsoGeometryType
getIsoGeometryType().
P.
On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve a
RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
a getIsoGeometryType() method that returns it, and the exportToWkb()
methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
}
I'd be happy to hear about other GDAL developers opinion on this.
How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
git-svn can be used to bridge the 2 worlds, but in my recent experience
it has been painful to use. So generating a patch and applying it is
probably easier.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 45: GDAL datasets and raster bands as virtual memory mappings
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 values to access in it. This could likely be made to work for most raw based formats and a few others too. It might also allow non-mmap() based files to return an organization based more on their actual organization for efficiency. Best regards, Frank On Tue, Dec 17, 2013 at 1:01 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le mardi 17 décembre 2013 21:54:31, Even Rouault a écrit : Hi, This is a call for discussion for RFC 45: GDAL datasets and raster bands as virtual memory mappings Here's the link to the RFC : http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
