[postgis-users] line simplication
craig at millerfam.net
Tue Jan 7 23:47:00 PST 2003
Rather than bloating the spatial database, perhaps a middle-tier (business
logic) should be introduced. OGIS has a number of specifications that would
make for a nice middle tier API that is language neutral, and would still
leverage the SF SQL spec that PostGIS implements.
----- Original Message -----
From: "Kevin Webb" <kpw at jump9.com>
To: <postgis-users at postgis.refractions.net>
Sent: Monday, January 06, 2003 3:34 PM
Subject: [postgis-users] line simplication
> Dear PostGIS folks,
> I know this has been talked about before (last spring I think) but I'd
> to reopen the discussion on implementing line simplification on the DB
> for applications like Mapserver.
> I would like to implement at a way to store multiple resolutions of data
> inside a geometry column such that client applications can requests a
> level of granularity without having to keep separate copies of the same
> all of the needed resolutions (or at least not make the client worry about
> the different copies). If done properly this would significantly reduce
> load on the DB server and the client in order process large datasets (e.g.
> viewing a map at full extent).
> My experimentation with PostGIS/Mapserver has led me to believe the
> slowdowns steam from throughput issues when dataset size starts
> Some of this gets solved with intelligent map design (making sure that
> unnecessary levels of detail get striped out as the scale increases) but
> there's a point where that no longer helps. For example if I'd like to
> create a map that can be viewed both at a city level and at a national
> I can't expect my road layer (even when striped down to just Interstates
> national highways) to work at both scales effectively. There's just too
> information in there at the national level.
> So I want to be able to strip some of it out when it's not needed.
> I think there are a two different ways this could be done:
> 1) Apply some sort of line simplification algorithm to the data at load
> (e.g. inside shp2pgsql) that adds a secondary index inside the geometry
> column which is then used by PostGIS to grab the relevant points prior to
> sending the data back to the client. For example you could run something
> like Douglas-Plucker, or another recursive simplification method on the
> and specify which of the n-levels of hierarchy is associated with each of
> the points. The client then request level they need and the DB masks out
> the points at a lower level of detail. The masking process is, of course,
> non-trivial and could be implemented in a variety of ways. But I think the
> benefits coudl be tremendous. The problem is that the internal structure
> the geometry object would change to inherently understand levels of
> 2) Have PostGIS transparently create (and synchronize) multiple copies of
> each geometry object at various resolutions. For example, you could
> in the AddGeometryColumn call how many different levels of resolutions you
> want to store and then PostGIS would internally manage multiple copies of
> the data applying simplification algorithms on the fly. Then, at request
> time the DB would simply choose the copy of the data that best meets the
> client's needs and return the geometry object just as it would now. This
> method has the advantage of not requiring internal changes to the geometry
> object format, but would also require more disk space as data would be
> replicated for each level of detail.
> I'm at a point where I would like to try and start implementing one of
> methods but I'd like to hear ideas from others, as I'm sure much thought
> already been put into this issue. Is it worth it? I am I headed down the
> right path?
> Any thoughts would be greatly appreciated!
> Kevin Webb
> e: kpw[at]jump9.com
> p: (919)260-8375
> w: kpw.jump9.com
> postgis-users mailing list
> postgis-users at postgis.refractions.net
More information about the postgis-users