[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