<div dir="ltr">funny, the EWKB is exactly half the size of the "PostGIS binary notation", in all cases i tested.<br>there is a small performance impact, which fluctuates somewhat. The internal format was a factor 1.01 to 1.07 faster (94 to 99% of the time needed). <br>
<br>cheers,<br><br>WBL<br><br><div class="gmail_quote">On Tue, Jul 29, 2008 at 6:48 PM, Willy-Bas Loos <span dir="ltr"><<a href="mailto:willybas@gmail.com">willybas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">thanks.<br>yes it helps :)<br><br><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Tue, Jul 29, 2008 at 4:46 PM, Obe, Regina <span dir="ltr"><<a href="mailto:robe.dnd@cityofboston.gov" target="_blank">robe.dnd@cityofboston.gov</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">Haven't done any benchmarks, but I know the
following</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">the ::text display you get is basically the string
representation of the native binary format that PostGIS actually stores the
geometries.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">It is not WKB nor WKT. Its a PostGIS proprietary
format if you will. I would guess casting from that format is the most
efficient since in theory there is very little processing that PostgreSQL needs
to do to reconstitute from that format.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">Keep in mind EWKT and WKT also may result in floating point
errors since they will round the decimals so be careful using those.
</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">So your best formats to maintain precision (and not have
lossiness) are EWKB and the ::text representation (which I shall dubb the native
PostGIS binary notation (which I guess we can call light-weight something or
other)).</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">Hope that helps,</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" size="2" face="Arial">Regina</font></span></div><br>
<div dir="ltr" align="left" lang="en-us">
<hr>
<font size="2" face="Tahoma"><b>From:</b>
<a href="mailto:postgis-users-bounces@postgis.refractions.net" target="_blank">postgis-users-bounces@postgis.refractions.net</a>
[mailto:<a href="mailto:postgis-users-bounces@postgis.refractions.net" target="_blank">postgis-users-bounces@postgis.refractions.net</a>] <b>On Behalf Of
</b>Willy-Bas Loos<br><b>Sent:</b> Tuesday, July 29, 2008 8:43 AM<br><b>To:</b>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br><b>Subject:</b> [postgis-users] optimal
textbased geometry format<br></font><br></div><div><div></div><div>
<div></div>
<div dir="ltr">Sometimes i build queries inside plpgsql scripts, that i then run
using EXECUTE.<br>Is there a preferred way to include geometries in
those?<br><br>I use postgis 1.1 (for now). Are there are any changes in later
versions that influence this aspect of PostGIS?<br>The SRID is a factor for me,
so asText(the_geom) is no option.<br>I eiter use asEWKT(the_geom), or just
the_geom::text .<br>Just casting the geometry directly into text results in a
very long text value (what is the name of this format?). The length of the
string might be a network transfer drawback.<br>asEWKT results in human readable
format, possibly shorter, but it might require more processing power (back and
forth!). <br><br>I've tested both difference in length and performance, all on a
limited dataset.<br>LENGTH:<br>The difference in length varies greatly. I use
SRID 28992, which is a national grid that has coordinates in meters, so it is
possible to have coordinates with 0 decimal places (1 meter precision). Simple
geometries seem to benefit most from the WKT format. The EWKT is 40% of the
number of characters for some cases (square polygons from coordinates without
decimals). Most polygons score 50-60% of length, but in some cases the WKT
representation is up to 10% longer than the direct cast
(geom::text).<br>code:<br> --select length(the_geom::text),
length(asewkt(the_geom)),
round(((length(asewkt(the_geom))::float)/(length(the_geom::text))::float)*100)
as perc<br> select
avg(((length(asewkt(the_geom))::float)/(length(the_geom::text))::float)*100) as
perc<br> from atable<br> order by perc<br><br>PERFORMANCE:<br>I've
tested these "warm" (not the first run), and averaged the scores from 3
measurements each. The fluctuations were minimal.<br>The diference in
performance is small for converting from geometries to a text representation.
Casting directly is a factor 1.1 faster (90% of the time needed)<br>The other
way around is a diferent story. Converting a directly casted geometry back to a
geometry is a factor 6 faster than a EWKT string (16% of the time needed)!<br>I
hope my method (code below) is adequate?<br><br>code:<br> select
area(the_geom::text::geometry)<br> --select
area(asewkt(the_geom)::geometry)<br> from atable<br><br>Regarding my
tests, i would say that the format that results from a direct cast is the better
string representation for intra-application communication. Are there any
drawbacks?<br>Of course my test was limited to a small dataset on a windows pc
(mem 2GB, athlon 64 3200+) with postgis 1.1. Does anyone else have different
results/ideas about
this?<br><br>Cheers,<br><br>WBL<br><br><br></div></div></div></div>
<div><p></p><hr size="1">
<p><b>
The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.
</b></p></div>
<p></p><hr size="1">
<p><b><font color="#339900" size="2"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </font></b></p> <p> </p>
<br></div></div>_______________________________________________<br>
postgis-users mailing list<div class="Ih2E3d"><br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br>
</div><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>