[Qgis-developer] QgsGeometry

[Marco Hugentobler]

Hi Martin,

Sorry for my long mail. In my opinion it is a really interesting topic.

> In case of OGR this is not true - we can use derived classes of
> OGRGeometry for geometry retreival instead of WKB export.

Ok, this is a clever solution. So postgis is the only provider that would have 
a performance loss with internal switch to geos? I'm inclined to think that 
this is a low price for the benefit of cleaner code with geos instead of wkb.

>Postgis -> wkb conversion
> in fact should be costless since AFAIK postgis stores the geometries
> in extended wkb, which is a superset of OGC wkb.

Yes, but wkb -> geos afterwards not. You can test the effect by forcing a wkb 
to geos conversion for every feature. In QgsGeometry::wkbBuffer() insert the 
following two lines.

 unsigned char * QgsGeometry::wkbBuffer()
{
  if (mDirtyWkb)
  {
    // convert from GEOS
    exportGeosToWkb();
  }

+  mDirtyGeos = true;
+ exportWkbToGeos();

  return mGeometry;
}

(and outcomment the debugging output in the geos conversion routine)

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.

> 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



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

LineString::getPointN(size_t n) returns just a copy of the point:

Point*
LineString::getPointN(size_t n) const
{
	assert(getFactory());
	assert(points.get());
	return getFactory()->createPoint(points->getAt(n));
}

Maybe there are other possibilities that I have missed?

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

Yes, I meant those typedefs. My point was just that some modification 
operations may have less code with the QVectors than with geos classes 
directly.  

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

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
}

and then implementation something like:

int QgsSplitGeometry::splitGeometry(QList<points> splitLine, QgsGeometry** 
newGeometry)
{
	//switch over geometry type
	...
	case QGis::WKBLineString:
	{
		QgsPolyline thisLine = mGeometry->asPolyline();
		QgsPolyline newLine;
		//...then code to change line
		mGeometry->fromPolyline(thisLine);
		//...and to create new line
		(*newGeometry) = QgsGeometry::fromPolyline(newLine);
		return 0;
	}
}

But ok, maybe it can be done better by getting and setting geos geometry from 
QgsGeometry (and converting to QVector based structures inside 
QgsSplitGeometry if needed there).

Regards,
Marco





-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee
marco.hugentobler at karto.baug.ethz.ch