<div dir="auto">Dear Paul<div dir="auto"><br></div><div dir="auto">As you may know in MobilityDB we deal with moving points (e.g. GPS tracks of cars or planes) in which types tgeompoint and tgeogpoint store a sequence of couples composed of a geometry, resp. geography 2D/3D point and a timestamptz. MobilityDB takes care of all the temporal processing and delegates all spatial processing to PostGIS.</div><div dir="auto"><br></div><div dir="auto">Given the algorithmic complexity of temporal processing we would benefit of a lightweigth 2D/3D point type that can be manipulated directly from the gserialized format without deserializing it to lwgeom.</div><div dir="auto"><br></div><div dir="auto">Is this the kind of application you are looking for testing the new PR you are working on ? FYI MobilityDB is open source and available in github, we are preparing our first alpha release.</div><div dir="auto"><br></div><div dir="auto">Regards </div><div dir="auto"><br></div><div dir="auto">Esteban </div><div dir="auto"><br></div><div dir="auto"><br style="font-family:sans-serif;font-size:12.8px"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 22 juin 2019 à 00:02, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, the PR finally builds and regresses, and includes the initial<br>
scaffolding on which new features using new flagging can be built.<br>
<br>
<a href="https://github.com/postgis/postgis/pull/421" rel="noreferrer noreferrer" target="_blank">https://github.com/postgis/postgis/pull/421</a><br>
<br>
In order to get there, you'll note some structural changes around the code base<br>
<br>
- All access to gserialized internals is now behind an API that lives<br>
in gserialized.c<br>
- The homology between gserialized->flags and lwgeom->flags is now<br>
broken -- gserialized2 has an 8-bit gflags member, and an optional<br>
64-bit xflags area managed behind the api, while lwgeom->flags has<br>
been expanded to 16 bits for now, with room potentially to get to 24<br>
with some extra contortions as necessary in the future<br>
- That means you can continue to call FLAGS_SET/GET macros on<br>
lwgeom->flags, but you should no longer assume you can do so on<br>
gserialized->gflags, you should instead call the relevant<br>
gserialized_get_*() functions from the API<br>
- (All the above changes have been cleaned out of the code base, so<br>
this in on a going forward basis, there is no work to be done by<br>
anyone to implement the above, it's already done)<br>
- lwgeom_from_gserialized() will magically work regardless of whether<br>
it's fed a v1 or v2 serialization, so this code all works fine when<br>
slapped on top of a database full of old geometries<br>
- gserialized_from_lwgeom() (and the two functions riding on top of<br>
it, geometry_serialize() and geography_serialize(), which are<br>
preferred when calling from inside ./postgis) will write out v2<br>
geometries, so databases will slowly get re-written with the new form<br>
over time<br>
<br>
So far all this deck chair rearranging has resulted in no net-new<br>
functionality. I'm looking at two potential areas where the new<br>
serialization could be put to use before postgis3:<br>
<br>
- The extra flag space on gflags that has been freed up by moving the<br>
IsSolid flag into the xflags area could be used of an IsPoint flag, to<br>
allow a lightweight point type. A lightweight x/y point could then be<br>
24 bytes (varsize + srid/flags + x + y) instead of 32 bytes (varsize +<br>
srid/flags + type + padding + x + y), for a 25% savings for simple<br>
points.<br>
- An extended flag and optional data area to hold a hash code could be<br>
used to accelerate the prepared geometry cache for those cases where<br>
the cached object is large, avoiding much of the current repetitive<br>
decompression overhead.<br>
- Some kind of validity caching could be put into place for larger<br>
objects using a ValidChecked/IsValid pair of flags in the extended<br>
area. open question for me would be -- when to set those flags, what<br>
triggers it? obviously ST_MakeValid() could set it, but what about<br>
automatically for any large polygons during serialization?<br>
<br>
I apologize in advance for the fundamental ugliness of the work, I'm<br>
not an artist, I'm a tradesman.<br>
<br>
ATB,<br>
P<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>