[Mapserver-users] rubber sheeting

woodbri at swoodbridge.com woodbri at swoodbridge.com
Sat Jul 19 09:10:11 EDT 2003


Jan,

I think section 3.3 is the algorithm you want at:
  http://www.hammerhead.com/thad/morph.html

It is based on lines not points, but when you read the algorithm it 
will make sense.

-Steve W.

On 19 Jul 2003 at 12:51, Jan Hartmann wrote:

> Yes, that is the answer. I hadn't realized that it was done by 
> triangulation and that morphing is just another name for rubber 
> sheeting. Both are very well known technologies, I just hadn't made
> the link to GIS terminology. Gives me quite a lot of good technical
> pointers. If anyone knows free software or source code in these two
> areas that could be easily transferred to GIS, please let me know. I
> could try to implement it in GRASS or GDAL
> 
> Thanks Franck, Norman
> 
> Jan
> 
> Franck Martin wrote:
> > Many raster software offer polynomial rectification which highly
> > inadequate in most of cases today. Rubber Sheeting is the answer and
> > the correct term in GIS, and as described below it is based on a
> > triangulation of the map to be modified..
> > 
> > The difference between polynomial and rubber sheeting is that rubber
> > sheeting needs more ground control points.
> > 
> > GRASS does not offer rubber sheeting, it is a pity as I don't know
> > any free software that offers it.
> > 
> > I guess the algorithm for rubber sheeting is well known or known
> > also under the name morphing.. A google search should give some
> > results here...
> > 
> > Cheers
> > 
> > 
> > 
> > On Sat, 2003-07-19 at 04:43, Norman Vine wrote:
> > 
> >>/Jan Hartmann writes:
> >>> 
> >>> 
> >>> The problem is that AFAIK all these rectifying routines are
> >>> computed globally. You can use of course a higher order
> >>> polynomial, but even so the placement of every control point will
> >>> affect the whole map. Moreover, you can't use very high
> >>> polynomials and too many control points. What I am looking for is
> >>> something that will do *local* transformations based on nearby
> >>> control points, and stretch the results together some way. Those
> >>> old maps are generally correct on small subregions, but the
> >>> subregions fit in no way together. There is certainly no numerical
> >>> soluton for it.
> >>
> >>Good question, 
> >>I don't think I have ever thought about 'locally adaptive' rubber
> >>sheeting.
> >>
> >>Probably easiest to do by separating out the U and V correction
> >>
> >>A 'simplistic' method might be to make two countour 'grids', for
> >>testing purposes you could use simple triangulated surfaces, where
> >>'Z'  was the displacement in X or Y respectively of each control
> >>point.  Then by queryng the grids by the original {X,Y} you would
> >>get a {U,V} offset by interpolation, that can be used to determine
> >>the new coordinates.  One trick here is that the new image wants to
> >>be constructed by triangles and not points, think texture mapping
> >>
> >>< tough todo with ASCII >
> >>*  *   *   *
> >>| \ | \ | \ |
> >>*  *  *   *
> >>| \ | \ | \ |
> >>*  *   *   *
> >>
> >>HTH
> >>
> >>Norman
> >>_______________________________________________/
> >>
> > 
> > -- 
> > Franck Martin <franck at sopac.org <mailto:franck at sopac.org>>
> > SOPAC
> > 
> > 
> 
> _______________________________________________
> Mapserver-users mailing list
> Mapserver-users at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
> 





More information about the mapserver-users mailing list