Re: filter by m-value and effective area

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: filter by m-value and effective area

Paul Ramsey
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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: filter by m-value and effective area

nicklas

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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: filter by m-value and effective area

nicklas
In reply to this post by Paul Ramsey
The ST_SimplifyVW does that filtering, but I didn't open any way to do
the filtering on already computed m-values. But I also added
ST_SetEffectiveArea, which is kind of ST_SimplifyVWPrepare()
but not ST_SimplifyVWPrepared() in the meaning that it works on already
prepared VW.

ST_SimplifyVW shortcits when the requested effective area is found so
it is a little slower to run ST_Seteffectivearea.

That is an interesting difference between ST_Simplify and
ST_SimplifyVW, that ST_Simplify gets faster the fewer points it shall
filter away, and ST_SimplifyVW is faster the fewer points it shall
return.

They attack the problem from different ends.

/Nicklas


On Sat, 2017-09-23 at 13:05 +0200, Sandro Santilli 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel