<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020 at 9:35 AM <<a href="mailto:rmrodriguez@carto.com">rmrodriguez@carto.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I wanted a way to ensure there would be no loss of information when<br>
doing storage1 > wkt/geojson -> storage2 as not having this has caused<br>
issues where the stored geometry was valid, but after moving it using<br>
GeoJSON it wasn't valid anymore.<br>
The solution option there was to ask for more resolution, but since<br>
the function isn't working as announced I wouldn't get it.  Yes,<br>
ideally the end system should be able to read WKB, but that's not<br>
always the case.<br></blockquote><div><br></div><div>So if you specify say 20 decimal digits, you aren't getting them?  It seems like this at least should be made to work.  It doesn't sound like a bad thing, as long as it doesn't cause *unspecified* precision output to get a lot longer.</div><div><br></div><div>I'm wondering whether it is actually possible to have no-loss round-tripping with binary -> text -> binary?  And if so, how many digits are required to guarantee this?</div><div><br></div><div>I know it's not possible to round-trip text -> binary -> text, since there are decimal numbers which aren't finitely representable in binary (e.g 1.3). </div></div></div>