wonder.sk at gmail.com
Wed Sep 12 04:39:59 EDT 2007
On 9/12/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> > In this approach, splitGeometry() would be also just another virtual
> > function in QgsGeometry which would be implemented properly in child
> > classes.
> Yes, true. It may make sense to switch to such a scheme in the middle term
> (maybe after merging of advanced editing branch).
> There could be several possibilities to do so:
> -The qgis classes could be derived from geos classes and from QgsGeometry
> interface class.
> -Or an approache similar to OGR which has their own representation of geometry
> and does geos conversion when needed for topological operations.
Yesterday I've took a look at GEOS library and found out that there is
some kind of support for custom geometry classes - we could make our
own CoordinateSequence class which would use QVector, our own
CoordinateSequenceFactory for creation of these sequences and
GeometryFactory from creation of our custom geometries. The only
problem is that we still would need to use Coordinate class for the
coordinates, but that's not that big problem. It comes with three
member variables: x,y,z and some functions. I can imagine that we
would derive e.g. QgsCoord class from it that will add some more
functions for us if needed - in fact this class (QgsCoord) should
replace QgsPoint, as QgsPoint should be in the new scheme derived from
After all, we would get a common representation for QGIS where we
could avoid any further conversions, I'm just a bit affraid if others
would be okay with this as it's a rather radical change...
More information about the Qgis-developer