On Tue, 20 Dec 2005, Daniel Calvelo wrote:
Dmitry,
If you are willing to program the whole rendering algorithm, there are
some optimizations you could use: you might want to use R-Trees for
storage of the polygon features, and check, after the data is
projected and before writing into the canvas, that the projected data
does fill more than one pixel before rendering the whole feature.
Also, if your objective is only to display data, you could
precalculate simplified versions of the polygon boundaries for the
less detailed scales, and switch to the original data as you zoom into
more detailed areas.
Google for R-Tree; a lot of research has been done on them, and
several implementations are available from free software projects. You
might want to ask in the freegis list
(http://www.intevation.de/mailman/listinfo/freegis-list) where people
are rather heplful.
A lightweight approach is to decimate the long-lat data first - I think
the code at:
ftp://gmt.soest.hawaii.edu/pub/pwessel/gshhs
is pretty informative (or was until I tried it now - seems to be down
temporarily - look for gshhs.h, gshhs.c, and especially gshhs_dp.c,
which contains the line simplification code - looks as though they are
copied in:
http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.3/gshhs_1.5_src.zip
).
In fact, my first cut on your task would have been to use GMT straight
off, pushing the projected output Postscript into gs or some such to
render to your window. Depending on the size of your window, the
pre-thinned coarse or low GSHHS datasets might be good enough, but I don't
know if you need more features than just shorelines.
Daniel.
On 12/20/05, Dmitry Suzdalev <dimsuz@mail.ru> wrote:
> Hi, dear GRASS developers :).
> Please, sorry for maybe offtopic, but I have one question.
> I'm learning my way into world of map projections and my task is to display
> all the world in a GUI window (QT-window, actually).
> I've already managed to do it, using libproj4 :).
> But... There is sooo much data to be displayed that it draws rather slow.
>
> And it's obvious, that it's not needed to draw EACH map data primitive,
> because some of them are so small, that they're represented by one pixel,
> when using large scales. And still, if I have 1000 primitives (polylines,
> regions etc) that are so small, that they fit in one concrete pixel, they'll
> all be drawn. In the same pixel. 1000 times. That's slow :).
>
> So the question is: is there any common algorithm to cope with this situation?
> Which helps to somehow "filter out" the primitives which are represented by a
> single pixel at the screen and draw that pixel only once?
> Or should i investigate that algorithm by myself? 
>
> Again, sorry if this is offtopic, I've googled for a few hours trying to find
> some kind of web-forum for such kind of questions, but I didn't find it :).
> Googling on "gis developers forum" pointed me to your mailing list, so I
> decided to give it a try :).
>
> Maybe at least, you can point me to the right place to ask such a question?
>
> Thanks in advance!
>
> And sorry for my maybe not very good English ;).
> Cheers, Dmitry.
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
--
-- Daniel Calvelo Aros
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no