[postgis-devel] ST_SimplifyVW not touching Start and endpoint of polygon

Nicklas Avén nicklas.aven at jordogskog.no
Sun Oct 15 11:07:46 PDT 2017


Hello Tom
I see your point.The reason it is implemented this way is that I didn't
think about it and that it will be more complicated.
More complicated, both because it would need different handling of
linestrings and polygons. It will also add some extra complexity to
grab the second point in the polygon when calculating the last point of
the polygon. Also, if it shows that the start/end point should be
eliminated it means what is the start and end of the polygon. The
second point of the polygon or the second last point of the polygon.
Then that point shall be duplicated and put as first or last point.
It is of course doable, but will open some possibilities for problems.
I haven't looked at the code for some years so I cannot say how much
work it would mean.
Now it sets the first/last point and the 2 most valuable points in a
polygon to DBL_MAX to prevent collapse. If the start/end point is not
always used it also have to save another point as the third point to
avoid collapse.For linestrings it does the same with the first and last
point and that prevents collapse.
What you can do is open a ticket about it.I you have a patch it is
great, or it will be set as "PostGIS Fund Me"
I agree at first thought that what you suggest would make sense and
would be the right thing.
ATB
Nicklas Avén


On Sun, 2017-10-15 at 12:22 +0200, Tom van Tilburg wrote:
> I only just found this out and was wondering if it is intentional.
> When running ST_SetEffectiveArea it turns out that the triangle-area
> for points related to start and endpoint of a polygon are set to
> dbl_max (example below). While this is logical for linestrings (it
> would break your network), I think it could be implemented better for
> polygons by reconnecting the polygon when start/endpoint are throw
> out because of a small effective area. I have some polygons with
> spikes originating from the startpoint and it is unexpected behaviour
> to see some spikes not being removed this way.
> Is there a good reason to keep the start/endpoint of polygon intact?
> And if so, would it make sense to make it optional?
> 
> Tom
> 
> P.S. I have the idea that this point has been addressed on another
> list (maybe D3) but wasn't able to find it. 
> 
> ----------------------
> Example:
> 
> SELECT
>  ST_AsTExt(
>   (ST_DumpPoints(
>    ST_SetEffectiveArea(
>     ST_GeometryFromText(
> 'POLYGON((
> 0 0,
> 10 0,
> 20 0,
> 20 10,
> 10 10,
> 10 0,
> 0 0
> ))'
>     )
>    ,0.1)
> )).geom)
> 
> Result:
> "POINT M (0 0 3.40282346638529e+38)"
> "POINT M (20 0 3.40282346638529e+38)"
> "POINT M (20 10 3.40282346638529e+38)"
> "POINT M (10 10 50)"
> "POINT M (10 0 50)"
> "POINT M (0 0 3.40282346638529e+38)"
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171015/b11a1b3b/attachment.html>


More information about the postgis-devel mailing list