Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a large set of data points that essentially represent the coastline of the world. I don't know the exact resolution but I'd say it's in the neighbourhood of 5-10m.

Imagine a set of points which represent a jagged coastline. At a 1m resolution, we see all the detail and need 50 data points to correctly represent the coast, however, at 10km resolution the coast looks like a straight line and we would only need 2 points.

I'm writing a mapping application that will require the data to scale from "full-planet" resolutions to "street" resolutions. I need some help reducing the resolution of my data points, and subsequently the amount of data for wider resolutions.

I've been reading about Vector-Tiling and think this will be the best solution (I'm doing something like this already), however, at the low resolutions, my dataset it still huge meaning that rending it takes a [relatively] long time, where as the high resolutions are fast because the 'effective' dataset it small (subset of the whole).

I'm trying to determine how to take my large dataset and reduce the scale of it so that my 'full-planet' view's tile data is a manageable size. How do I create the tile sub-datasets from the larger complete dataset?

I'm happy to use a tool but I'd rather do it myself in an effort to learn how it's done.

share|improve this question
Have you checked the answers to…? Please elaborate if you think your question is different. – underdark Aug 31 '11 at 6:31
Seems like the question should be about coastlines instead of "points". As resolution gets lower, should small islands disappear? is it ok for coastlines around skinny serpentine islands to cross? – Kirk Kuykendall Aug 31 '11 at 17:04
If you just want to do a passable job and move on, @R Thiede's answer is probably the best place to start. If you want to work on the real challenge, simplifying linework without losing the meaning of the shapes, see the related questions… and…. – matt wilkie Sep 1 '11 at 15:59

How you'll go about solving this problem really depends on the case, and how important the actual topology is to you (versus just the visuals/rendering time). Since your final goal is to generalize coastlines, you may find some ideas on generalization useful.

One approach uses buffering, as seen here. I also had a similar problem a while ago and detailed my solution here.

In short, you can make use of separate vector datasets (or at least separate geometries), generalized to different levels. This addresses your basic problem although it doesn't make use of tiles, but of course you can still use those if you like. Of course, if you're going to split your dataset into tiles based on a grid, be sure to generalize first, or you'll end up with gaps between tiles.

share|improve this answer
+1 for a thoughtful reply. Welcome to our site, Rüdiger! – whuber Sep 1 '11 at 14:23

You should prepare different generalized versions of your data set for "full planet" zoom levels down to close-up zoom.

A classic generalization algorithm is Douglas-Peucker algorithm. You'll have to connect the points to coast lines first if you haven't done that already.

share|improve this answer
The GEOS library has Douglas-Peucker algorithms built-in that you could use, if you want to code this yourself. You might wish to consider topology though, in which case the GRASS v.generalize tool can help as well. – lagerratrobe Aug 31 '11 at 16:12
Hi @lagerratrobe. I made this answer community wiki, so you should be able to edit it directly and add both GEOS and GRASS solutions to it. – underdark Aug 31 '11 at 18:01

Have you investigated Tilemill for producing your tilesets? It automagically will reduce nodes at different zoom levels.

share|improve this answer

Probably not answering your question, but it's quite related - this is how Google encodes polylines including the generalization information:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.