Hi Nyall
- For methods which don't have a geos implementation (eg,
QgsGeometry::smooth ), should they just be implemented in the
QgsGeometryEngine base class?
They can stay in QgsGeometry as they don't require conversion to a
different format and they would not benefit from prepare().
It
Hi Nyall
I'm still a bit unclear as to where
you are taking these classes though. Is the intention that eventually
ALL operations will be done using QgsGeos?
In the end, yes, everything should go through QgsGeometryEngine
interface. There are two possibilities:
1. client code creates
On 23 June 2015 at 16:15, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Nyall
This potentially has huge impacts on the performance of common tasks such
as selecting all features which intersect a geometry.
Are you really sure the impact is huge? If you select features on the
On 23 June 2015 at 16:25, Werner Macho werner.ma...@gmail.com wrote:
Hi!
I would be in favor of releasing it as is.
1. This is not the _LTS_ release (I thought this is exactly why we
introduced LTS) - so people should know that there are new features
which sometimes can cause something
2.
On 23 June 2015 at 20:07, Matthias Kuhn matth...@opengis.ch wrote:
So the question is, is this something that we can fix later on, or would
fixing it require an API break and therefore we need to wait for 3.0 if
we don't fix it now?
As I mentioned in an earlier reply, could we mark this
Hi Martin
The new geometries uses more memory for backward compatibility. In the
mid/long term, the cached wkb will be removed, so QgsAbstractGeometry
will be the only represention. The provider can feed wkb (e.g. database
providers) or construct the geometry by feeding QgsPointV2s.
I'm
Hi Marco,
On Tue, 23. Jun 2015 at 08:15:27 +0200, Marco Hugentobler wrote:
Are you really sure the impact is huge?
Well, if you have to ask and Nyall apparently is the first to notice - the
impact can't be huge.
I think reverting is no option - there have been numerous things that were
adapted
Hi Nyall
This potentially has huge impacts on the performance of common tasks
such as selecting all features which intersect a geometry.
Are you really sure the impact is huge? If you select features on the
map, you get a new one from provider each time. So also with the old
geometry class,
Hi!
I would be in favor of releasing it as is.
1. This is not the _LTS_ release (I thought this is exactly why we
introduced LTS) - so people should know that there are new features
which sometimes can cause something
2. releasing it with the changes means more feedback if this is really
a
Hi,
I don't think reverting the geometry work is an option.
It works well in general and offers really nice new possibilities with z
and m values and circular arcs despite it was merged a bit late, did not
receive a lot of attention in the freeze period and lacks some unit tests.
But then,
On 24 June 2015 at 00:44, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Nyall
I'm still a bit unclear as to where
you are taking these classes though. Is the intention that eventually
ALL operations will be done using QgsGeos?
In the end, yes, everything should go through
Hi all,
Unfortunately, we've become aware of a serious performance regression
caused by the new geometry engine. Basically, the situation is that for all
geometry operations which rely on geos (think buffers, splits, spatial
relation operations such as intersects and within,... ) the geometry now
Hi
Agreed with Nyall. Apart from the above mentioned problems, there are
newly introduced performance regressions with snapping: the cached
geometries in 2.10 take double the amount of memory they used in 2.8,
and snapping got much slower with more complex layers (compared to
2.8) - e.g. with
+1 to full postpone for me. I don't like the idea of shipping something
that is slower and snapping is slow. Those are core features of a GIS.
Nathan
On Tue, 23 Jun 2015 3:22 pm Nyall Dawson nyall.daw...@gmail.com wrote:
On 23 June 2015 at 13:42, Martin Dobias wonder...@gmail.com wrote:
One
Out of curiosity, how long of a delay do you estimate would be needed to
fix things? 4 weeks, 8 weeks?
On 23 Jun 2015 09:09, Nyall Dawson nyall.daw...@gmail.com wrote:
Hi all,
Unfortunately, we've become aware of a serious performance regression
caused by the new geometry engine. Basically,
15 matches
Mail list logo
