<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" data-hsystem="true"></head>
<body><style>p{margin: 0;padding: 0;}
</style>
<div id="html-message">
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;">initial thoughts
:<br></span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> * a dedicated schema is
good, but not the name 'postgis'</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> * cached validity flag(s)
for polygons</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> * a chance to update all
build requirements.. "clean slate" </span></p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;">general:</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> * how to tease/pull/force
more parallelism, really</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> trivial example.. while
pulling the OSM polys for buildings, </span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> I routinely make a
POINT version with PtOnSurface.</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> With 4.6 million polys,
making a POINT out of each..</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> one core used on a 32
core beast.. <br></span></p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> * Search Engine? fast,
fast, fast cached results.. </span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> if things are
invariant,</span></p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;"> look for it, use the
RAM, pre-calc or saved.. something.. </span></p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"><span style="font-family: none; font-size:
14pt; color: #000000; background-color: #ffffff;">best regards from Berkeley
--Brian</span></p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"><br><br>On Wed, 17 Jan 2018 09:44:23 -0800,
Paul Ramsey <pramsey@cleverelephant.ca> wrote:</p>
<blockquote style="border-left: 2px solid #000000; padding-right: 0px;
padding-left: 5px; margin-left: 5px; margin-right: 0px;">What else is on
everyone's wish list? Preferably things you'd do if<br> you didn't think
everyone would shoot you down for being too<br> disruptive.<br><br>
https://trac.osgeo.org/postgis/wiki/PostGIS3<br><br> * Break out a
postgis_raster extension with a postgis dependency, so<br> raster support
becomes optional.<br> * Require installation in a 'postgis' schema, always and
for ever<br><br> * Yet another serialization, this time changing to use
external<br> storage type, and adding our own compression scheme for
coordinates.<br> * An uncompressed header, so header info can always be
efficiently<br> "sliced" and read, even for very large objects<br> * A hash key
for use in fast and small equality comparisons (for use<br> in cached comparison
code)<br> * A compression format optimized for doubles<br> * Other compression
formats with other tradeoffs (?) like TWKB for<br> higher ratio with precision
loss<br> * Implies indirection in coordinate access again: smaller, more<br>
efficient must be balanced against direct access to coordinates<br><br> * Move
up to "modern" C and use whatever cool features we like from that<br> * Modern
GEOS version requirement?<br> * Some major GEOS surgery to allow memory
management by palloc?<br> * Some major GEOS surgery to build coordinateSequence
directly on top<br> of PostGIS pointlists?<br>
_______________________________________________<br> postgis-devel mailing
list<br> postgis-devel@lists.osgeo.org<br>
https://lists.osgeo.org/mailman/listinfo/postgis-devel</blockquote>
<p style="margin: 0; padding: 0;"><br><br></p>
<p><br> --<br>Brian M Hamlin<br> OSGeo California<br> blog.light42.com</p>
<p style="margin: 0; padding: 0;"> </p>
</div>
</body>
</html>