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 m
On 24 June 2015 at 00:44, Marco Hugentobler
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 QgsGeometryEngine interf
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 QgsGeo
On 23 June 2015 at 20:07, Matthias Kuhn 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 component of
the API
On 23 June 2015 at 16:25, Werner Macho 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. releasing it wi
On 23 June 2015 at 16:15, Marco Hugentobler
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 map,
> you get a new one fr
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, should
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 howe
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!
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 probl
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,
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" wrote:
> Hi all,
>
> Unfortunately, we've become aware of a serious performance regression
> caused by the new geometry engine. Basically, the situation is t
+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 wrote:
> On 23 June 2015 at 13:42, Martin Dobias wrote:
>
> > One heretic idea at the end - what others
On 23 June 2015 at 13:42, Martin Dobias wrote:
> One heretic idea at the end - what others think about postponing the
> release of the new geometry architecture to 2.12 so that there is more
> time to address the current issues (fix performance, fix high memory
> consumption, clean up API, write
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].
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
16 matches
Mail list logo