[Qgis-developer] QgsGeometry

[Martin Dobias]

On 9/10/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin,
>
> Sorry for my long mail. In my opinion it is a really interesting topic.

Yes, it surely is :-)

> I tested with a database that had 3s to draw without extra geos conversion and
> 4s with. The effect might be different with other data.
> However, in my opinion that seems acceptable, since it's only for postgres
> provider.

Actually, wkbBuffer() gets called at least two times (as also
wkbType() calls it), but this is still quite a lot of time. I'll look
into it.


> > Maybe I'm wrong but the real bottleneck is always data fetching from
> > the providers as they have to read the data from some media. Any
> > conversions happening in RAM are very quick in comparison.
>
> You can test the performance effect of reading from disk by comparing ogr
> layers in qgis with wfs layers for the same dataset. Afaik ogr reads from
> disk while wfs provider reads the features into memory when loading the
> layer. There is indeed some difference, but the difference is not so high as
> I expected. What is your opinion?
>
> check the following example:
>
> wfs:
> http://karlinapp.ethz.ch/cgi-bin/mapserv?map=/home/marco/mapfiles/mapfile.map&
>
> shape:
>
> http://karlinapp.ethz.ch/various/lake24k_nhd.zip

Ok, but I won't be able to compare with your WFS server (still no
internet at home). Maybe the difference is lower as the data gets
cached by the operating system?
I'd like to look at the performance of the conversions.

> LineString::getPointN(size_t n) returns just a copy of the point:
> [...]
> Maybe there are other possibilities that I have missed?

Ah, you're right. But there are still GeometryFilter classes which I
think could be subclassed to change the geometry without the need to
reconstruct it.


> There could e.g. be a class that splits a geometry into two parts by a line
> (just to get the code for geometry splitting out of QgsGeometry):
>
> class QgsSplitGeometry
> {
>        public:
>                int splitGeometry(QList<points> splitLine, QgsGeometry** newGeometry);
>        private:
>                QgsGeometry* mGeometry
> }

Now I'm starting to think that we should rather start to use a scheme
as e.g. OGR and GEOS use. They have a base Geometry class and derived
classes which can do operations with the specific type of geometry
(point, polyline, ...). What leads me to this: when you look to
QgsGeometry source, it's full of long switches for different types of
geometry. In a book about refactoring I've read that long switches are
a "bad smell" which should be better implemented with virtual
functions with different implementations in derived classes. Does this
make a sense to you?
In this approach, splitGeometry() would be also just another virtual
function in QgsGeometry which would be implemented properly in child
classes.

Cheers
Martin