When speaking about fuzzyness and tolerance we really have to
distinguish different use cases, like
1 is it about storing geometries/numbers in finite data types (like
float) => integer geometry,
2 is it about geometry representation of polygons (as geometry or topology),
3 is it about representation of uncertainty of boundaries of real-world objects,
4 or is it about handling artefacts from analysis (like in intersection).
2016-09-16 17:20 GMT+02:00 Willy-Bas Loos <willy...@gmail.com>:
> On Thu, Sep 15, 2016 at 1:58 PM, Daniel Baston <dbas...@gmail.com> wrote:
>> > Any words of warning about using a trigger and storing the data on a 10
>> > cm
>> > grid like i suggest?
> Wow, thanks for the great responses. Lars Opsahl, nice to see you in the
> mailing list :D
> So what i gather from this is that it is not ideal to use st_snaptogrid. It
> solves some problems, but it creates some new ones too.
> Maybe a second geometry column would be a better idea, so that the original
> is still there (and will consume your server's memory &hdd space :/ )
> Anyway, there is no automatic way to solve the problem right now.
> So how big are the problems that arise from this?
> For me i have to say that we often have problems with errors in overlays,
> and we have to keep using st_makevalid after every step of a process.
> Decreasing the supersmall artifacts in the geometries would probably help
> with that.
> @Lars Opsahl, you describe a lot of problems or very reasonable wishes in
> your presentation (link to abstract in previous mail). Do you think those
> could be solved with a concept similar to fuzzy tolerance?
> @Daniel Baston could you describe some of the problems that the hyperprecise
> coordinates cause for you?
> Willy-Bas Loos
> postgis-users mailing list
postgis-users mailing list