Hi,
sorry for a new bug report: It seems that d.vect.area does not work properly
with the HTMLMAP driver (d.area was fine).
Please update:
cvs up src/scripts/contrib/grassmirrorsmap
then
cd src/scripts/contrib/grassmirrorsmap
mkgrassmap.sh
The resulting 'grass_sites.gif' is fine, but the 'grass_sites.htmlmap' does
not contain the expected polygon definitions. Using the old d.area the
procedure went fine.
I need that to generate the mirrors world map:
http://grass.itc.it/index.html
Eric, could you please check for a difference between the old and the
new implementation which may concern the HTMLMAP driver?
Thanks,
Markus
Markus Neteler wrote:
sorry for a new bug report: It seems that d.vect.area does not work properly
with the HTMLMAP driver (d.area was fine).
Please update:
cvs up src/scripts/contrib/grassmirrorsmap
then
cd src/scripts/contrib/grassmirrorsmap
mkgrassmap.sh
The resulting 'grass_sites.gif' is fine, but the 'grass_sites.htmlmap' does
not contain the expected polygon definitions. Using the old d.area the
procedure went fine.
I need that to generate the mirrors world map:
http://grass.itc.it/index.html
Eric, could you please check for a difference between the old and the
new implementation which may concern the HTMLMAP driver?
The HTMLMAP driver only implements two drawing operations, R_text()
and R_polygon_abs(). d.area uses R_polygon_abs(), while d.vect.area
uses G_plot_area().
Eric added G_plot_area() for this purpose. It is based upon
G_plot_polygon(), but it handles areas containing holes. Both of these
functions "scan convert" the shape, drawing a series of horizontal
lines using application-defined functions. For d.vect.area, the
functions are D_move_abs() and D_cont_abs().
The bottom line is that the HTMLMAP driver can't realistically
"reverse" the scan conversion to obtain the original polygons (the
original shape may not even be a polygon, in the usual sense of the
word), and re-writing d.vect.area to use R_polygon_abs() isn't
feasible (that would involve a tesellation algorithm, which is far
from trivial).
So, it seems that we will need to maintain d.area for use with the
HTMLMAP driver. I'll re-enable it in src/CMD/lists/GRASS.
--
Glynn Clements <glynn.clements@virgin.net>
On Tue, Apr 16, 2002 at 06:35:38PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> sorry for a new bug report: It seems that d.vect.area does not work properly
> with the HTMLMAP driver (d.area was fine).
>
> Please update:
> cvs up src/scripts/contrib/grassmirrorsmap
> then
> cd src/scripts/contrib/grassmirrorsmap
> mkgrassmap.sh
>
> The resulting 'grass_sites.gif' is fine, but the 'grass_sites.htmlmap' does
> not contain the expected polygon definitions. Using the old d.area the
> procedure went fine.
>
> I need that to generate the mirrors world map:
> http://grass.itc.it/index.html
>
> Eric, could you please check for a difference between the old and the
> new implementation which may concern the HTMLMAP driver?
The HTMLMAP driver only implements two drawing operations, R_text()
and R_polygon_abs(). d.area uses R_polygon_abs(), while d.vect.area
uses G_plot_area().
Eric added G_plot_area() for this purpose. It is based upon
G_plot_polygon(), but it handles areas containing holes. Both of these
functions "scan convert" the shape, drawing a series of horizontal
lines using application-defined functions. For d.vect.area, the
functions are D_move_abs() and D_cont_abs().
The bottom line is that the HTMLMAP driver can't realistically
"reverse" the scan conversion to obtain the original polygons (the
original shape may not even be a polygon, in the usual sense of the
word), and re-writing d.vect.area to use R_polygon_abs() isn't
feasible (that would involve a tesellation algorithm, which is far
from trivial).
So, it seems that we will need to maintain d.area for use with the
HTMLMAP driver. I'll re-enable it in src/CMD/lists/GRASS.
O.k. - I have reverted my changes in the mkgrass.sh script to use
d.area, now the new mirror map is uploaded.
Markus