Before I send any code to grass servers I ask how. At the moment this is a
subdir of ps/ and the only change in grass standard files is the Makefile of
the ps/ subdir adding ps3.map to SUBDIRS list.
I prefer rename this module as ps3.map because I try update poscript code
(many responsabilities has the ps code now) to level 3 (I have in mind
smoothing gradientes and this is only in PS3).
It is interesting the posibility of gradient legend in CELL map; it is easy to
program, I try it. The actual legend with gradient look as
ps_map_legend_float.jpg.
But the better improve (just run without problems) is merge two raster maps as
shown in ps3_map_raster.jpg (this was the mother of all changes :). Of course
without any cost in size of ps file, this work directly on the original
raster image, thus no more bytes of size to the file (option of second map is
color o gradient of one color -gray, blue, ....).
Those layouts are gorgeous. Once the SVN integration is done, would you
be willing to put some tutorial on the GRASS Wiki to show users how to
generate such maps with ps3.map?
Cheers,
Ben
E. Jorge Tizado wrote:
Thanks to all
Before I send any code to grass servers I ask how. At the moment this is a subdir of ps/ and the only change in grass standard files is the Makefile of the ps/ subdir adding ps3.map to SUBDIRS list.
I prefer rename this module as ps3.map because I try update poscript code (many responsabilities has the ps code now) to level 3 (I have in mind smoothing gradientes and this is only in PS3).
It is interesting the posibility of gradient legend in CELL map; it is easy to program, I try it. The actual legend with gradient look as ps_map_legend_float.jpg.
But the better improve (just run without problems) is merge two raster maps as shown in ps3_map_raster.jpg (this was the mother of all changes :). Of course without any cost in size of ps file, this work directly on the original raster image, thus no more bytes of size to the file (option of second map is color o gradient of one color -gray, blue, ....).
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
Before I send any code to grass servers I ask how. At the moment this is a
subdir of ps/ and the only change in grass standard files is the Makefile of
the ps/ subdir adding ps3.map to SUBDIRS list.
I'm assuming that ps3.map shares a great deal of code with ps.map. If
you make it a separate module, then any bugfixes or other changes made
to ps.map would probably also need to be made to ps3.map.
I prefer rename this module as ps3.map because I try update poscript code
(many responsabilities has the ps code now) to level 3 (I have in mind
smoothing gradientes and this is only in PS3).
The PostScript level should be decided via a program option, not
through a separate program.
While I appreciate that "cloning" is simpler, it isn't really an
acceptable practice.
If you want to maintain ps3.map as a separate module for the time
being, that's an option.
However: UNDER NO CIRCUMSTANCES should ps3.map be added to SVN as if
it is entirely new code. The relationship between the modified files
and their originals MUST be known to SVN. IOW, the files must be added
by first using "svn copy" on the exact version of ps.map on which
ps3.map is based, then modified from there.
Personally, I suggest creating an "enhancement" ticket in Trac for
ps3.map, creating a diff between ps3.map and the corresponding version
of ps.map, and attaching the diff to the ticket.
I'm assuming that ps3.map shares a great deal of code with ps.map. If
you make it a separate module, then any bugfixes or other changes made
to ps.map would probably also need to be made to ps3.map.
(which history shows never gets done completely leading to a divergent
mess)
> I prefer rename this module as ps3.map because I try update poscript
> code (many responsabilities has the ps code now) to level 3
(I have in mind smoothing gradientes and this is only in PS3).
The PostScript level should be decided via a program
option, not through a separate program.
e.g. in d.out.file (grass 6) there is a ps_level=1-3 option which limits
functionality.
Personally, I suggest creating an "enhancement" ticket in Trac for
ps3.map, creating a diff between ps3.map and the corresponding version
of ps.map, and attaching the diff to the ticket.
for me, the easiest would be 1 patch per ticket per item, ie split into
self-contained bite sized pieces. e.g. 1 ticket/patch for the RGBing of
colors. that way I can apply the straight forward paches quickly, and so
the more complicated things are not cluttered by a mix of changes in a 50k
uber-patch which I am likely to ignore until a big chuck of time opens
(probably a rather long time).
all this trouble to avoid clones & stray code is because there is only
a handful of us to maintain about a million lines of code. so we have to
be very efficient & disciplined in order to keep from being completely
overwhelmed by it.
