[gdal-dev] Call for discussion on RFC 92 text: WKB Only geometries
Even Rouault
even.rouault at spatialys.com
Mon Feb 6 17:25:57 PST 2023
Hi Dan,
| And only construct an OGRGeometry when it's asked for? Such as when
GetGeometryRef is called?
> I'm wondering about a more broad application of this. Would it be
> helpful to have the ability to lazy-initialize an OGRGeometry from
> multiple source types such as WKB and GEOS, initially storing only a
> reference to the external data in WKB/GEOS/etc and actually
> materializing the geometry when required?
That's definitely something doable. At a minimum, you would have to
inspect the top geometry type to instantiate the appropriate OGRGeometry
subclass, and then its members could be lazy initialized, but that means
that all methods of OGRGeometry and its subclasses would have to do a
check whether the object has been fully initialized. There might be
performance implications for people doing for example
lineString->getX(idx) to iterate on big geometries, although branch
predictors of modern CPUs are probably very good at repeatedly
evaluating stuff like "if (!materialized) materialize();". The main
drawback is that is a substantial & risky change that requires to
revisit *all* methods of the geometry classes. For setters, you would
also have to make sure to invalidate the potentially initial WKB / GEOS
source.
PS: I believe I joked some time ago that it was a pity that GDAL, GEOS,
QGIS, PostGIS, ... didn't share the same geometry classes given that
they all implement the same Single Features/ ISO SQL MM Part 3 model (it
is kind of crazy that we have all to implement WKB, WKT, etc etc), but
it really looks like this is completely what the RFC works around. But
I'm afraid this "libgeom" is a pipe dream
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230207/3535a0fa/attachment.htm>
More information about the gdal-dev
mailing list