[postgis-devel] Inconsistencies in text output

[rmrodriguez at carto.com]

> Wouldn't it be less disruptive to change the documentation?

That was the other proposal. If we consider the precision passed as
number of total digits (decimal or not) most of the output is the
same, and there are only some small changes when removing extra limits
that ST_AsGeoJSON, ST_AsSVG and so on handled differently (the idea is
that now everything is handled the same and using liblwgeom).

I'm updating both PRs with the minimal changes so it's more clear the
impact that this has:
- Precision = number of decimal digits:
https://github.com/postgis/postgis/pull/554
- Precision = number of total digits:
https://github.com/postgis/postgis/pull/555/

On Fri, Apr 17, 2020 at 6:53 PM Martin Davis <mtnclimb at gmail.com> wrote:
> 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.

No, I wasn't getting them. The problem, as I mentioned in Github, is
that we don't have a way to distinguish "give me 15 decimal digits" to
"I used the default, which is give me 15 decimal digits", so fixing it
produced many new unexpected digits.

On Fri, Apr 17, 2020 at 6:58 PM Martin Davis <mtnclimb at gmail.com> wrote:
> That's assuming that the C FP output works in the correct way. If not, I guess we could implement that Burger's algorithm mentioned - which is what Python does, apparently.  Although is it really worth the complexity?

For 3.1 I replaced the C FP with ryu printf
(https://github.com/ulfjack/ryu) so that's already there. No need to
do anything extra, just remove the differences between functions and
maybe tweak some defaults if necessary.



On Fri, Apr 17, 2020 at 6:42 PM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>
>
>
> > On Apr 17, 2020, at 9:35 AM, rmrodriguez at carto.com wrote:
> >
> > On Fri, Apr 17, 2020 at 6:20 PM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> >> This seems like a change that most users would regard as a net reduction in functionality.
> >>
> >> What's the win we are getting that makes this worthwhile?
> >
> > Consistency and working according to the documentation.
>
> Wouldn't it be less disruptive to change the documentation?
>
> > I wanted a way to ensure there would be no loss of information when
> > doing storage1 > wkt/geojson -> storage2 as not having this has caused
> > issues where the stored geometry was valid, but after moving it using
> > GeoJSON it wasn't valid anymore.
> > The solution option there was to ask for more resolution, but since
> > the function isn't working as announced I wouldn't get it.  Yes,
> > ideally the end system should be able to read WKB, but that's not
> > always the case.
>
> I'm happy to see "changing the knobs" work more consistently and match the documentation, but I have very large misgivings about producing twice-as-long-text-by-default as an acceptable side-effect of that change. Can you achieve your goals without radically altering the default outputs?
>
> P
>
> >
> >
> > --
> > Raúl Marín Rodríguez
> > carto.com
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > 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



--
Raúl Marín Rodríguez
carto.com