Subject: [Thuban-list] arcview comparition and thuban.mo

From: "Fidel Serrano" <[email-masked]>
Date: Mon, 13 Oct 2003 12:05:10 -0400 (EDT)

i have been using thuban for six month or so, and im very hapy with the development, yesterday i intalled arcview from ESRI in my computer, and i noticed 2 things:

1   when you maximize the aplication window, the map (all the layers)
    resizes to cover the new size of the window aplication
    thuban does not do that, dont you think it would be nice.

2   the time of display for a layer or a raster image is like 1/10
    of the time it takes for thuban, is that becouse of python
    velocity? or becouse of the algoritm of displaing? 

and i have a cuestion:
how do i use the thuban.mo files to get thuban translated?

______________________________________________________________
Sponsored By:

The ByRegion Network 
http://www.HealerPages.info

SpiritCard Center 
http://www.spiritcardcenter.com

OmPlace - The Conscious Living Directory - FREE Email          
http://www.omplace.com

---

From: Bernhard Herzog <[email-masked]>
Date: Tue, 14 Oct 2003 20:46:55 +0200

>     thuban does not do that, dont you think it would be nice.

I'm not sure whether I would always want it but it's worth considering.
I've added a wish-list item in the request tracker fpr it:

https://intevation.de/rt/webrt?serial_num=2156

>     velocity? or becouse of the algoritm of displaing? 

Thuban's rendering speed definitely needs to be improved. 

The algorithm is probably not to blame. Thuban builds a quad-tree for
the shapes in shapefiles and uses it to more or less only draw shapes
that overlap the visible region. Beyond that there's not much you can do
besides iterating through those shapes and draw them.

Some common usage patterns could be speeded up by more intelligent
caching, though, and some classifications can be speeded up by using
python dictionaries instead of linear searches in some cases, I think.

While Python's speed is certainly an issue, I'm not sure how much impact
that still has on the rendering especially in the case of rendering from
shapefiles and without classifications. We already do the actual drawing
of a polygon or arc shape from a shapefile in C++ which means that the
code that reads the actual geometry, applies any necessary projection,
transforms it to window coordinates and passes the data to the wxDC is
written in C++.

Anyway, one of the things we want to for 1.0 is to look into ways to
increase rendering speed.

> and i have a cuestion: how do i use the thuban.mo files to get thuban
> translated?

Setting the environment variable LANG to a suitable value shuold be
enough. e.g. LANG=de_DE to get German translations. This works for me on
my GNU/Linux system anyway.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/

---

From: Bernhard Reiter <[email-masked]>
Date: Tue, 14 Oct 2003 21:01:23 +0200

> my GNU/Linux system anyway.

In case the question has been: How to I create a new translation?

Look into the "po" subdirectory and the README.
You need to end up with a new file for each language, like "pt.po".
To get that file you need to start from thuban.pot.
Copy that file and then use an po-file editor to do the translations.

A normal texteditor might be enough, but a tool
like poedit.sourceforge.net might still be interesting.

Please contribute a new translation if you make one. 

(Shouldn't be add something like this a the documentation
or the mentioned README somewhere?)

Bernhard

---

From: Jan-Oliver Wagner <[email-masked]>
Date: Tue, 14 Oct 2003 22:15:15 +0200

> https://intevation.de/rt/webrt?serial_num=2156

I must confess, that I still expect a behaviur as Fidel describes
when changing the window size though I use Thuban now for
quite some time.
Especially switching between a small window and full-screen is something
I want to increase the size of the map quickly.

Best

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/

Intevation GmbH	              	     http://intevation.de/
FreeGIS	                               http://freegis.org/

---

From: Andreas Rottmann <[email-masked]>
Date: Wed, 15 Oct 2003 00:11:10 +0200

> like poedit.sourceforge.net might still be interesting.
Or Emacs using po-mode, of course. [SCNR]

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | [email-masked]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

This reality is really just a fucked-up dream -- Papa Roach

---

From: Bernhard Herzog <[email-masked]>
Date: Mon, 20 Oct 2003 14:55:47 +0200

Bernhard Herzog <[email-masked]> writes:

> shapefiles and without classifications.

I did some simple timings last week. The test map was just the
roads-line.shp and political.shp from the iceland data, no
classifications, just a 1 pixel line for both layers plus a fill for the
"political" layer.

Normal rendering (with the low-level C++ accelerator) takes about 0.041
seconds on my machine. If I replace the low-level redering function with
a no-op so that basically everything but the low-level renderer is
executed it only takes 0.0115 seconds. So the low-level renderer takes
about 70% of the rendering time.

Some things to keep in mind here:

 - low-level renderer means that it uses shapelib to read the geometry
   of a shape, applies some coordinate transformations and produces an
   array of wxPoints to pass to a wxDC. On my system with wxGTK that
   array is then converted to an array of gdkpoints (which again
   involves some coordinate transformation) and passed to
   gdk_draw_polygon which hands the array over to the appropriate xlib
   function (with only a cast since GdkPoint has the same structure as
   an XPoint). Xlib then serializes this and sends it to the X server on
   the same computer. 

   Some more timing tests where the actual calls to the wxDC methods
   DrawPolygon and DrawLines were commented out in wxproj.cpp indicate
   that the wxWindows/gtk/xlib part takes about 0.015 seconds.
   
 - The timings only take the client side into account. This can be
   misleading when timing rendering speed on X because it can happen
   that the client is already finished while the server still processes
   the requests sent by the client. I don't think this is much of a
   problem here, though, and in any case it wouldn't change anything
   regarding the impact of Python (if anything the non-python parts take
   longer).

 - The timing results depend a lot on the whether there are layers with
   classifications, the data source (shapefile vs. postgis) and the type
   of shapes (currently there's no C++ low-level renderer for points for
   instance), among others. The percentage of time spent in the
   low-level renderer is largest for the case I looked at.

  Bernhard