[postgis-devel] gserialized-v2

[Paul Ramsey]

Hey E,
This won’t be a "lightweigth 2D/3D point type that can be manipulated directly from the gserialized format without deserializing it to lwgeom.” because we are deliberately hiding the serialization implementation from userland. You’ll find the built-in pgsql ‘point’ type does what you want, as a simple struct of doubles. Because we have a ‘geometry’ type, and not a ‘point’ type, we end up with a varlena type, which immediate complicates things immensely compared to a simple type, particularly for points. If I were re-writing PostGIS I’d probably have a typology that looked a lot like shape files (point, multipoint, multilinestring, multipolygon), and distinct types for each, specifically to allow things like points to be truly minimalist, at the price of some extra code points and casting magic.
ATB,
P

> On Jun 23, 2019, at 12:52 AM, Esteban Zimanyi <ezimanyi at ulb.ac.be> wrote:
> 
> Dear Paul
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Regards 
> 
> Esteban 
> 
> 
> 
> Le sam. 22 juin 2019 à 00:02, Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca>> a écrit :
> So, the PR finally builds and regresses, and includes the initial
> scaffolding on which new features using new flagging can be built.
> 
> https://github.com/postgis/postgis/pull/421 <https://github.com/postgis/postgis/pull/421>
> 
> In order to get there, you'll note some structural changes around the code base
> 
> - All access to gserialized internals is now behind an API that lives
> in gserialized.c
> - The homology between gserialized->flags and lwgeom->flags is now
> broken -- gserialized2 has an 8-bit gflags member, and an optional
> 64-bit xflags area managed behind the api, while lwgeom->flags has
> been expanded to 16 bits for now, with room potentially to get to 24
> with some extra contortions as necessary in the future
> - That means you can continue to call FLAGS_SET/GET macros on
> lwgeom->flags, but you should no longer assume you can do so on
> gserialized->gflags, you should instead call the relevant
> gserialized_get_*() functions from the API
> - (All the above changes have been cleaned out of the code base, so
> this in on a going forward basis, there is no work to be done by
> anyone to implement the above, it's already done)
> - lwgeom_from_gserialized() will magically work regardless of whether
> it's fed a v1 or v2 serialization, so this code all works fine when
> slapped on top of a database full of old geometries
> - gserialized_from_lwgeom() (and the two functions riding on top of
> it, geometry_serialize() and geography_serialize(), which are
> preferred when calling from inside ./postgis) will write out v2
> geometries, so databases will slowly get re-written with the new form
> over time
> 
> So far all this deck chair rearranging has resulted in no net-new
> functionality. I'm looking at two potential areas where the new
> serialization could be put to use before postgis3:
> 
> - The extra flag space on gflags that has been freed up by moving the
> IsSolid flag into the xflags area could be used of an IsPoint flag, to
> allow a lightweight point type. A lightweight x/y point could then be
> 24 bytes (varsize + srid/flags + x + y) instead of 32 bytes (varsize +
> srid/flags + type + padding + x + y), for a 25% savings for simple
> points.
> - An extended flag and optional data area to hold a hash code could be
> used to accelerate the prepared geometry cache for those cases where
> the cached object is large, avoiding much of the current repetitive
> decompression overhead.
> - Some kind of validity caching could be put into place for larger
> objects using a ValidChecked/IsValid pair of flags in the extended
> area. open question for me would be -- when to set those flags, what
> triggers it? obviously ST_MakeValid() could set it, but what about
> automatically for any large polygons during serialization?
> 
> I apologize in advance for the fundamental ugliness of the work, I'm
> not an artist, I'm a tradesman.
> 
> ATB,
> P
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/postgis-devel <https://lists.osgeo.org/mailman/listinfo/postgis-devel>_______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190624/e0dcb376/attachment.html>