[gdal-dev] Contour Line Thinning

[Even Rouault]

On vendredi 1 janvier 2021 22:09:47 CET Stephen Woodbridge wrote:
> On 1/1/2021 9:47 PM, Richard Greenwood wrote:
> > On Fri, Jan 1, 2021 at 2:36 PM Stephen Woodbridge
> > <stephenwoodbridge37 at gmail.com <mailto:stephenwoodbridge37 at gmail.com>>
> > 
> > wrote:
> >     Hi all,
> >     
> >     I'm contouring bathemetry data using gdal_contour and it works really
> >     great. The problem I have is that when depth falls off rapidly
> >     like at
> >     the continental shelf or into a canyon, I get too many contour lines
> >     that all bunch up. If I change the contour step size to fix this,
> >     then
> >     the flatter areas don't get enough lines.
> >     
> >     I wonder if anyone has any ideas on someway to thin these lines or
> >     some
> >     way to do adaptive contouring based on maybe something like
> >     scanning the
> >     image first to build a masks that represent these rapid changes in
> >     depth
> >     and then change the contour levels in these masked areas.
> >     
> >     I currently contour into a postgis database, the render them using
> >     mapserver into a tile cache since they are static once they are
> >     computed.
> >     
> >     I would be interested in any ideas you might have on how to tackle
> >     this
> >     problem.
> >     
> >     -Steve W
> > 
> > Hey Steve,
> > 
> > Interesting problem and this isn't an answer, just my opinion. I live
> > and play in a mountainous area and frequently use USGS topo maps with
> > contour intervals of 20, 40 and 80 feet. Each map's contour interval
> > was chosen with criteria like yours - flatter land needs smaller
> > contour intervals, but steeper land can become too cluttered with a
> > small contour interval. But as a map user it drives me crazy when I
> > stitch together adjoining maps with different intervals and try to get
> > a sense of the landscape. Like this for example
> > <https://greenwoodmap.com/tetonwy/mapserver/map#zcr=7.279815109511815/2448
> > 564.5062904786/1516712.6778719614/0&lyrs=DRG,Roads,ownership> where 20
> > foot contours adjoin 80 foot. The western half of the map is much steeper
> > than the eastern, but that's not obvious from a quick look. I'd just let
> > the bunched up contours tell the reader that hey, it's really steep here!
> > 
> > Best regards,
> > Rich
> 
> Hi Rich,
> 
> Yeah, I get your point. And the engineer in me agrees but users of the
> map have complained so I have to at least look into the issue.
> 
> One thought I had that might work because I'm dealing with ocean bottom
> contours is to do something like:
> 
> a) take all contours above X
> b) take all contours below Y
> c) take every Nth contour between X and Y
> 
> This would probably work OK for the drop off on the continental shelf at
> least for the East coast, I'd have to look at other areas since this is
> a global map, but 98% of the users are on the East coast currently but
> that is expanding.
> 
> Anyway, it is an interesting problem, I'd like to find a simple solution
> that I can build into the postGIS database where I have all the contour
> lines stored. Or find a solution that handles the generation of the
> contour lines with some kind of adaptive thinning. My guess is that it
> will not be easy to do it at the generation level, so I'll probably only
> be able to do the thinning during the rendering of the tiles.

A potential approach would be to use a ST_Buffer() on the generated lines, 
let's say, with 10m interval that are not multiple of 50 or 100 and see if 
they intersect other lines to eliminate them. You might need to do that on 
small bounding boxes to avoid evicting lines in areas where the density is 
low.

The GDAL countour generator could potentially be modified as well to avoid 
generating too many lines. For example if the difference between 2 adjacent 
nodes would be >= 100 m, it would only generate a level multiple of 50 m (the 
setting could be a limitation to the number of contours per raster cell). That 
could be done without performance impact. That wouldn't work if the resolution 
of the terrain is too high and that the difference of elevation between 
consecutive node is not big enough in average to generate a contour line. 
Perhaps a criterion based on slope rather than the number of contour per 
raster cell would work better.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com