Re: GMT output Format
Paul Wessel <[email protected]>
| Newsgroups | gmane.comp.gis.gmt.user |
|---|---|
| Message-ID | <[email protected]> |
Good point, of course. My quick test of making a RAM disk under OSX, place a copy of etopo1m.nc there (890 Mb) and run time grdinfo etopo1m.nc was disappointing; it took about the same 8 seconds to finish as it does on the HD.... -p On Jan 21, 2014, at 4:43 AM, walter harms <[email protected]> wrote: > regards, > > Not to mention the first step ... > 1) figure out where the time is spend. > > re, > wh > > > Am 21.01.2014 15:16, schrieb Eduardo A. Suárez: >> just guessing... >> >> Perhaps it is possible to have pre-computed layers of the map (ie. base >> map, coast, etc.) and to use cat to append it. >> >> Or to use GNU parallel/sem to run gmt commands in parallel whenever >> possible. >> >> Eduardo.- >> >> Quoting "J.J. Green" <[email protected]>: >> >>> Mark, >>> >>>> Now accepting donations toward a 12-core Mac Pro!! ;-) >>> >>> While gs supports multi-threading >>> >>> http://freecode.com/projects/ghostscript/releases/282470 >>> >>> with -dNumRenderingThreads=n since version 8.63, I see a number >>> of reports of it not speeding things up, but might be worth a >>> try. >>> >>> One possible workaround if your app can display SVG is to convert >>> to that with pstoedit, I would guess (but have not tested) that >>> a vector -> vector conversion may be quicker that rasterisation. >>> >>> Cheers >>> >>> Jim >>> >>> To unsubscribe, send the message "signoff gmt-help" to >>> [email protected] >>> >> >> >> > > To unsubscribe, send the message "signoff gmt-help" to [email protected] To unsubscribe, send the message "signoff gmt-help" to [email protected]