[Qgis-developer] QgsGeometry

[Martin Dobias]

On 9/8/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> > In my opinion, we should
> > only support WKB import and export, but represent the geometries as a
> > GEOS geometry
>
> I think that with data sources that provide only wkb geometries (e.g. ogr or
> postgis), there will be some overhead for drawing if we store geometries only
> in geos format internally.
> Currently, it is:
> postgis -> wkb -> drawing in vectorlayer
> and with internal storage as geos:
> postgis -> wkb -> geos -> drawing in vectorlayer

In case of OGR this is not true - we can use derived classes of
OGRGeometry for geometry retreival instead of WKB export.
I'm going to take a look at the conversion routines, but IMHO
conversion WKB -> GEOS should be quite fast. Postgis -> wkb conversion
in fact should be costless since AFAIK postgis stores the geometries
in extended wkb, which is a superset of OGC wkb.
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.

> >My big
> > wish about it is to stop completely doing the operations on geometries
> > with WKB and start fully using GEOS for geometry manipulations
>
> You are right that they shouldn't be done in WKB. But my experience with geos
> is that manipulation code can have similar length as with WKB, in some cases
> even more. In my opinion, the classes QgsPoint, QgsLinestring & co. are very
> well suited for manipulations. It is possible to just change one coordinate
> value, e.g. for a vertex move, without the need to do the whole geometry
> construction again (as in geos).

In GEOS you can also do vertex moves without the need of
reconstructing the geometry, e.g. LineString::getPointN(size_t n)

I just think that since we already have GEOS as a dependency, we
should use it more thoroughly.

> It may not be very performant to convert QgsPolyline to geos and than geos to
> wkb, as it is currently done with asPolyline(). But, unlike the drawing code,
> the manipulation methods are not performance critical at all since only few
> features are manipulated at once.

That's just temporary routine, once it's all in geos representation we
can convert it directly from that.

> So my preferred solution would be to move manipulations into separate classes
> which get and set geometry from QgsGeometry with
> QgsPoint/QgsLinestring/QgsPolygon & co.
> Would that make sense?

So far QgsPolyline, QgsPolygon are just typedefs for arrays of
points... what methods would they receive?

>
> > If the class would be still too huge, I'm for splitting
> > it into some smaller ones.
>
> I think it would still be too huge only with geos representation. Splitting
> sounds good.

Could you please post how could the splitted classes look like? I
still don't get an idea in what would that result...

Bye,
Martin