[postgis-devel] filter by m-value and effective area

[Nicklas Avén]

I have written the skeleton for this ST_FilterM-function. It works for
points, linestrings and polygons now.

I realize that a generic filter function have some issues. The main
issue is how to control collapses of polygons and linestrings.

In the case of effective area, that is taken care of when the effective
area is set. It always saves the 4 most valuable points n polygons and
the 2 most valuable points in linestrings by setting the effective area
of those to FLT_MAX. 

But in a generic filter function there is no way to know what the user
mean is the most valuable points. Should collapsed geometries generate
an error? Or how to handle that? Any ideas?

/Nicklas


On Sun, 2017-09-24 at 10:56 +0200, Nicklas Avén wrote:
> 
> I agree, I think about something like ST_FilterM
> 
> But it can be even more general. Would it make sense to filtering
> other dims too?
> 
> Could it be usefull to get only points with x or y or z-values above
> or under some value?
> 
> I can't really see any use of it. Maybe in some sort of tiling
> situation to just filter out the vertex points in a tile?
> 
> The second question is about semantics. First I thought about text to
> describe the operator, like "more then", less than", "between" and so
> on.
> 
> But this function will be used where it is high performance demands
> and this would require strcmp, right? Or is there some other smart
> solution?
> Another option is to define integers for the operators.
> 
> A third option is to have ST_Filter_M(geom, max, min);
> 
> if max is null then it should be above the min value, if min is NULL
> it should be below max-value. If both are used it is between.
> 
> The last option I see is to say that this should be very optimized so
> we have separate functions (ST_FilterMabove, ST_FilterMbelow).
> 
> But for the simplification uscase it should be enought with
> ST_FilterMabove. You never wants the vertex-points with lower values,
> without the ones with higher values unless you are building something
> that can add points to geometry to optimize on size per zoom level.
> (I tried that and it worked quite well)
> 
> 
> /Nicklas
> 
> On Sat, 2017-09-23 at 08:50 -0700, Paul Ramsey wrote:
> > I think a more general M-filter is appropriate. There may be other
> > ways of usefully populating an M for filtering than just VW.
> > P.
> > 
> > On Sat, Sep 23, 2017 at 4:05 AM, Sandro Santilli <strk at kbt.io>
> > wrote:
> > > On Sat, Sep 23, 2017 at 12:39:16AM +0200, Nicklas Avén wrote:
> > > 
> > > > Today we have no function doing this "removing of vertecies".
> > > But it
> > > > would be quite simple to write a function that just filters by
> > > the m-
> > > > value, and the simplification will be very fast.
> > > >
> > > > It will be a 2.5 function, but what do you think?
> > > >
> > > > Is this worth another function in the crowd?
> > > 
> > > Of course !
> > > Actually, I thought you already added that function
> > > as part of the Visvalingam-Whyatt algorithm work.
> > > Should it be a ST_SimplifyVWPrepared() or are you
> > > thinking of a more general "filter by M" one ?
> > > 
> > > --strk;
> > > _______________________________________________
> > > 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
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel