SimplifyPreserveTopology Tolerance

[Chris White]

Hello everyone,

Can someone perhaps explain what the appropriate range of values is for SimplifyPreserveTopology and what the general outcomes will be for the different values and the opposing ends of the spectrum range?

Thanks!

Chris

[a.fu...@lqt.it]

Hi Chris,

Simplify is based on the well known Douglas–Peucker algorithm;
you can learn more about this topic by reading:
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm

SimplifyPreserveTopology is a slightly modified version,
ensuring that no invalid polygon will be returned.

The appropriate tolerance value obviously depends on target
data; after all this simply represents a distance, and is
obviously expressed in map length units.

Just as an example: if the target geometry has lat/long coords
tolerance will be expressed in degrees, so 0.5 will intend a
very drastic simplification.
On the other side, if the target geometry has planar metric
coords tolerance will be measured in metres, so 0.5 will intend
a very bland simplification.

Please note: the actual nature of target geometries has a very
strong influence in choosing an appropriate tolerance value.
e.g. if you wish to simplify major rivers or national boundaries
on a worldwide map a tolerance as big as 1Km (or even bigger)
make perfectly sense.
but if you wish to simplify buildings on a cadastral map a tolerance
of 10m will probably be highly exaggerated.

bye Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[Chris White]

Hi Sandro,

Thanks so much!

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.

To post to this group, send email to spatialite-users@googlegroups.com.
To unsubscribe from this group, send email to spatialite-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spatialite-users?hl=en.

[Chris White]

Hi Sandro,

An additional question. I have a shape file set representing Parks. I am trying to use SimplifyPreserveTopology to reduce the number of points for the polygons, but no matter what value I use for the tolerance I always get the same number of total points for all of the polygons. I can confirm that the geometry type is a MULTIPOLYGON.

So let's say that I have a table called Parks and want to make a copy of it but with reduced points for the geometries and save it into a table entitled ParksModified. Would the following be correct usage?

spatialite Parks.sqlite "INSERT INTO ParksModified(PK_UID,ID,Name,Geometry) SELECT PK_UID,ID,Name,CastToMULTIPOLYGON(SimplifyPreserveTopology(Geometry, ${tolerance})) FROM Parks;"

Thanks so much. Sorry for all of the questions. Trying to wrap my head around this.

Chris

[a.fu...@lqt.it]

Hi Chris,

INSERT INTO ParksModified(PK_UID,ID,Name,Geometry)
SELECT PK_UID,ID,Name,
CastToMULTIPOLYGON(SimplifyPreserveTopology(Geometry, ?))
FROM Parks;

this SQL snippet seems to be absolutely valid; the most probable
cause explaining why you are experiencing that no simplification
happens at all is because *tolerance* has a ZERO value.

are you absolutely sure that ${tolerance} corresponds to the
valid syntax expected by your specific language binding for
argument substitution ?
second question: are you absolutely sure the $tolerance variable
is set to some useful value before executing the SQL query ?

(sorry, I only use the SQLite's own C APIs ... I'm unable
to help you if you are using some different language)

[Chris White]

Hi Sandro,

Thanks so much. I'm using a bash script on a Mac and have a spatialite binary that I'm using which was built from the C APIs. The value for tolerance is set earlier in the script. I have been trying to use various decimal values for the tolerance. 0.05 for example. Does that sound correct?

[a.fu...@lqt.it]

> I have been trying to use various decimal values for the tolerance.
> 0.05 for example. Does that sound correct?
>

I imagine that your Parks dataset has SRID=4326 (WGS84 long/lat).
if this assumption is true, 0.05 degrees corresponds to about
5 Km (along the equator). seems to be a reasonable value.

anyway, testing a SQL query from inside a shell script doesn't
seems a good approach, because you are testing *two* components
at the same time ... you can encounter some error on the shell
side, or you can encounter an error on the SQL side
... and you'll then completely unable to identify the real
failure cause.

I suggest you to hand-check this test query as a first step
(directly using the spatialite CLI tool):

INSERT INTO ParksModified(PK_UID,ID,Name,Geometry)
SELECT PK_UID,ID,Name,

CastToMULTIPOLYGON(SimplifyPreserveTopology(Geometry, 0.05))
FROM Parks;

- it works as expected ?
well, you surely have some error on the shell script

- it doesn't works ?
the 0.05 tolerance value isn't appropriate; increase it
(e.g. 0.5) and test yet again ... and so on ...

[Chris White]

OK great. Thanks again. Really appreciate it. I will try this approach.

[Chris White]

So when I run it from the command line, I don't get any errors. I get the following output:

SpatiaLite version ..: 2.4.0 Supported Extensions:

- 'VirtualShape' [direct Shapefile access]

- 'VirtualDbf' [direct DBF access]

- 'VirtualText' [direct CSV/TXT access]

- 'VirtualNetwork' [Dijkstra shortest path]

- 'RTree' [Spatial Index - R*Tree]

- 'MbrCache' [Spatial Index - MBR cache]

- 'VirtualFDO' [FDO-OGR interoperability]

- 'SpatiaLite' [Spatial SQL - OGC]

PROJ.4 version ......: Rel. 4.7.1, 23 September 2009

GEOS version ........: 3.2.2-CAPI-1.6.2

If I mangle part of the query it gives a failure so it seems like everything is in order. I cranked the tolerance way up to 100. Still nothing different in the results. Pretty stumped!

[Chris White]

Hi Sandro,

Some follow-up. Sorry for all of the messages. So apparently it IS working. What is throwing off things is my use of MbrCache. When I create an MbrCache for the table and use the MbrCache to do my query, I get a ton of points. If I just query the table as is without using the MbrCache I get a much more simplified set of polygons. Do you have any thoughts or insights on why the use of an MbrCache would generate so many extra points? 

Thanks!

[a.fu...@lqt.it]

> What is throwing off things is my use of MbrCache.
>

Chris,

a) MbrCache has been declared officially deprecated.
it's still supported simply to ensure backward compatibility; using
the R*Tree Spatial Index always is the suggested option.
b) version 2.4 too is now deprecated (really obsolete); upgrading to
version 3.0 is strongly suggested.

> When I create an MbrCache for the table and use the MbrCache to do my
> query,
> I get a ton of points. If I just query the table as is without using
> the MbrCache I get a much more simplified set of polygons. Do you
> have
> any thoughts or insights on why the use of an MbrCache would generate
> so many extra points? 
>

using MbrCache *and* ST_Simplify() at the same time isn't the
most obvious thing I was imagining :-)

- using MbrCache (or the R*Tree Spatial Index) is useful when
you absolutely have to "spatially select" very few features
from a densely populated dataset.
- ST_Simplify() on the other side looks exactly as the kind of
mass operation you'll wish to perform at once on every feature
of the same dataset.

please, could you kindly submit a complete sample of your SQL
query to be reviewed ?

[Majid Hojati]

Hi dear Sandro,

I notices that st_simplify only accepts curve not a geometry, so it means we can not apply it on polygon, lines and so on?

[a.fu...@lqt.it]

On Mon, 18 Sep 2017 00:43:22 -0700 (PDT), Majid Hojati wrote:
> Hi dear Sandro,
> I notices that st_simplify only accepts curve not a geometry, so it
> means we can not apply it on polygon, lines and so on?
>

Hi Majid,

a quick recall about the OGC SFS (simple feature specification)
foundations may probably help to understand better.

in OGC SFS there is an "abstract" Geometry class with 7 (seven)
children classes:
1. Point
2. Linestring
3. Polygon
4. MultiPoint
5. MultiLinestring
6. MultiPolygon
7. GeometryCollection

Both Linestrings and Polygon Rings depends on the same
"Curve" virtual class (any sequence of consecutive Vertices,
representing either an open or closed path):
- a Curve associated with a Linestring may indifferently be
Open or Closed.
- Curves associated with Polygon Rings _MUST_ be Closed.

so accordingly to the above premises, stating the ST_Simplify()
just accept "Curves" is a concise way to say that it accepts
both Linestrings and/or Polygons.

bye Sandro

[Majid Hojati]

Dear Sandro,

Thanks very much for your great detailed answer

On Friday, September 14, 2012 at 6:35:12 AM UTC+4:30, Chris White wrote: