This has fewer cells than the source raster DEM covering a larger region
(18,724 rows, 24,657 columns, 461,677,668 cells).
Should I change the nsres and ewres to 10.0? Should I change the number of
rows and columns? Your advice is needed to produce high quality output at
reasonable .pdf size.
I use ps.map only to export vectors to postscript. I then use v.in.region to create a box to show the region for any raster data (which is what takes up all the room in your postscript output), then use r.out.tif or whatever to dump the raster as a separate tif file; then merge the two in Adobe Illustrator (which is what I use for final map composition). An extra step, but gives lots of control.
Nick Cahill
On Jan 4, 2010, at 1:26 PM, Rich Shepard wrote:
The output files from ps.map are huge: the .ps is about 665M and the .pdf
is 9.9M. Way too large!
The DEM is at 10m cell size. 'g.region -p' produces:
This has fewer cells than the source raster DEM covering a larger region
(18,724 rows, 24,657 columns, 461,677,668 cells).
Should I change the nsres and ewres to 10.0? Should I change the number of
rows and columns? Your advice is needed to produce high quality output at
reasonable .pdf size.
I use ps.map only to export vectors to postscript. I then use v.in.region
to create a box to show the region for any raster data (which is what
takes up all the room in your postscript output), then use r.out.tif or
whatever to dump the raster as a separate tif file; then merge the two in
Adobe Illustrator (which is what I use for final map composition). An
extra step, but gives lots of control.
Nick,
The only Adobe product that runs on linux is acroread. Once I get the
system down I'll output to .eps for inclusion in LaTeX. That's the tool I
use for 99% of my writing. It's only when I have to send processed word
documents to colleagues or agencies running Microsoft that I use
OpenOffice.org's Writer.
Running 'g.region -m' revealed that the resolutions were much too fine:
about 2m each direction. I changed that to 10m for both nsres and ewres and
the final .pdf is about 2.8M. I suppose that for printed output purposes
(separate from analytical purposes), I can make the resolution even more
coarse.
I suppose that for printed output purposes (separate from analytical
purposes), I can make the resolution even more coarse.
Sure enough. 20m resolution makes a 0.5M pdf and the page looks just as
good as it did before.
...
Running 'g.region -m' revealed that the resolutions were much too fine:
about 2m each direction. I changed that to 10m for both nsres and ewres and
the final .pdf is about 2.8M. I suppose that for printed output purposes
(separate from analytical purposes), I can make the resolution even more
coarse.
you might calculate what resolution gives you 300dpi by measuring the
width of the printed map box in inches and multiplying by the desired
dpi. any thing more than that is wasted disk space, anything less causes
a cruddier printout. be aware that many ps->pdf converters silently
convert your image to a 72dpi jpeg or so; if you want higher quality
you have to pass ghostscript/whatever some extra flags:
Once I get the system down I'll output to .eps for inclusion in LaTeX.
beware that if you use .eps instead of .ps that any SCALE 1:xx,xxx written
on your map will become invalid. (with .ps we can guarantee that 1" is 1"
when printed)
A have made major update with r.stream.order and r.stream.basins:
r.stream.order new functionality:
- it can now create table to store drainage network topology. This table can be added to r.stream.extract vector file. For more details see description.html
r.stream.basins new functionality:
- much easier stream selection: now we can type only stream categories to create basins. No map algebra is necessary
- r.water.outlet functionality added to r.stream.basins (define outlet by coordinates)
- definition of outlets by vector point file
r.stream.pos
this is a helper module for linear geostatistics and local stream properties analysis. Nothing exciting
PS.
I have a problems with svn repository. If there are some problems with downloading or compiling please let me know, I will try to update as soon as possible.
you might calculate what resolution gives you 300dpi by measuring the
width of the printed map box in inches and multiplying by the desired
dpi. any thing more than that is wasted disk space,
Hamish
Well, in the context of high quality press output it's a bit more
delicate ; depends on what image you produce (b&w, grayscale, color),
what printing device it is (inkjet printer, laser printer, offset
press... each having different lineature values and different frame
types), and paper quality.
Then, as you say, 300 dpi :
* is most often enough for common color map printing
* should be increased to 600 dpi for b&w images e.g. text+thin black
contour lines on a white bg to be sent on a laser printer,
andbut should be considered the least acceptable resolution for high
quality paper production.
I agree that it's useless beyond 600 dpi.
Great updates to already great modules. Thanks for the contribution.
I will likely be compiling these in the upcoming week(s).
Mark
2010/1/5 Jarosław Jasiewicz <jarekj@amu.edu.pl>:
Hi all!
A have made major update with r.stream.order and r.stream.basins:
r.stream.order new functionality:
- it can now create table to store drainage network topology. This table can
be added to r.stream.extract vector file. For more details see
description.html
r.stream.basins new functionality:
- much easier stream selection: now we can type only stream categories to
create basins. No map algebra is necessary
- r.water.outlet functionality added to r.stream.basins (define outlet by
coordinates)
- definition of outlets by vector point file
r.stream.pos
this is a helper module for linear geostatistics and local stream properties
analysis. Nothing exciting
PS.
I have a problems with svn repository. If there are some problems with
downloading or compiling please let me know, I will try to update as soon as
possible.