Hi all
I also think dynamic scale-dependent simplification would be very nice but
for me ONLY if we can preserve topology when simplifying. If not, it would
lead to very uggly results
cf http://strk.keybit.net/blog/ for example
+1 for optionnaly remove small feature though, this will be good
Hi,
We just discussed this and concluded, that the safest solution would be
to only simplify for rendering and only when the resolution is small
enough, that only points which will be painted on top of each other
will be simplified away. (And then we should make some tests and see if
it's
Hi,
I have been following Vincent's solution since I funded #4819 resolution.
Pruning all vertexes under screen resolution is really a nice idea. I wasn't
sure that pruning vertex was less cpu consuming than rendering them, and now
it's proved. just use a very large object, and do a identify on
Hi,
As I understand, the feature to suppress small/large features would be
optional.
Another interesting thing would be to simplify features when you zoom
out. Maybe simplifying would be quicker than rendering thousands of
unnecessary vertices. Optionally this could also be outsourced to the
On Thu, Sep 12, 2013 at 8:51 AM, Andreas Neumann a.neum...@carto.netwrote:
[...] I don't know if it would really speed up things. One would have to
test.
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
Hi,
How would you define small? I guess something can already be done with
scale based visibility, but that needs preprocessing of the data and
assigning some kind of size class.
On Don 12 Sep 2013 08:51:43 CEST, Andreas Neumann wrote:
Hi,
Another interesting thing would be to simplify
Could this be done using a rule-based expression through the creation of a
variable that returns the pixel-size area of a polygon / pixel-size length
of a line?
On Thu, Sep 12, 2013 at 3:28 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
Hi,
How would you define small? I guess something can
Hi Matthias,
Thank you for your preliminary results. I think they are encouraging to
further look into this issue.
Andreas
Am 12.09.2013 10:28, schrieb Matthias Kuhn:
Hi,
How would you define small? I guess something can already be done with
scale based visibility, but that needs
This is possible using the Rule-Rendering
also is possible to use the rule-rendering to define a rule that in a
scale interval and with a dimension interval the feature is render using
a point rendering and change in a polygon rendering when the scale grow.
While it is possible to set up
Hi,
I raised similar question about year ago, but instead hiding small features
I propose to do simplification. I also implemented some test code and
results were pretty good — redraw is quicker in several times. But my code
still hacky and not optimal.
Also there were GSoC project, but it was
On Thu, Sep 12, 2013 at 08:51:43AM +0200, Andreas Neumann wrote:
Hi,
As I understand, the feature to suppress small/large features would be
optional.
Another interesting thing would be to simplify features when you zoom
out. Maybe simplifying would be quicker than rendering thousands of
Hi,
I did something somewhat similar to solve #4819 in Jully (Identify Features
tool is slow with complex/big features) and Matthias asked me to do the
same thing for the rubber-band.
In polygon contours, points that are less than a pixel apart from the
previous point are not drawn.
That
Hi all,
I've been chatting with Nathan about adding a feature to QGIS which would
allow suppression of rendering features smaller than a set threshold for
vector layers. (There's already a similar function in the labelling engine
Suppress labeling of features smaller than). This feature would
Not always is preferrable to suppress the small features.
Often in our rendering we prefere to substitute a small rendering of
kind polygon with a point rendering at lowest scales.
This is possible using the Rule-Rendering
also is possible to use the rule-rendering to define a rule that in a
14 matches
Mail list logo
