An LPE to measure area (square) of a closed path

[Alexandre Prokoudine]

We want a live path effect that will calculate and display area of a closed path (a shape), optionally with scale factor (e.g. 1:100)

We don't mean "now!", but we'd be grateful :-)

[Maximilian Albert (cilix)]

Assigning to myself since similar things are on my to-do list anyway (although I'm not saying "now" either ;-)).

The question is: Should the area be a "real" text object which can be be edited in the usual way and which is stored in SVG just as any other text? Or should it be a "temporary" item that is displayed only in Inkscape (much like helper paths for LPEs) and doesn't show up in SVG? What would be a good UI for either of them? Any further options you'd need?

In any case, I'm not sure if this feature should be implemented as a LPE at all. The reason is that LPEs take a path as input and should only return pure paths, too. In particular, they shouldn't create text objects or temporary items (that's why the path-length LPEs will also be reimplemented in another way).

[Alexandre Prokoudine (alexandre-prokoudine)]

Well, I was actually thinking about something in the lines of the current measure path LPE. As for option, scale factor and type of unit should suffice, imo. But I would never mind some extra options you might come up with :-)

In fact, I would even not mind just an extension :-)

[LimCore (limcore)]

Hi,
such function would be useful also for me;
In fact I hoped it already exists...

Btw other information about object / selection (total length, etc) would be also nice.

[Alexandre Prokoudine (alexandre-prokoudine)]

@LimCore

Measure Path extension does exist :)

[LimCore (limcore)]

How to use that?
But will it also measure area?

[Alexandre Prokoudine (alexandre-prokoudine)]

@LimCore

You mean how to select a path and call this effect from Effects menu? :)

Not, it won't measure areas. Just the length.

[kamrog (kamilrogalinski)]

Hi, I would also like to see that feature. If you can fill the shape then possibly you can also count the total number of pixels filled. Then you can check the shape area/total area ratio and you can see how much space you have used.
It would be great to see it on the screen when moving, rotating, scaling shapes.

I am trying to add this feature by myself but to be honest - I don't know where to start really :(

[Tom Rottler (tom-bitfit)]

Hi! I needed this function to measure area on a map (imported PDF bitmap map).
I have written a small extension that calculates the area of a closed polygon (only straight lines between points).

Select any closed polygon (but only one), then start Extensions -> Visualize Path -> Calculate polygon area. The result will be displayed as px^2 and mm^2.

[jazzynico (jazzynico)]

Hi Tom,

Thanks for your extension! It's not exactly what Alexandre suggested, but it could be a nice addition.

I've tested it on Windows XP, and it works well with polygons. But I also notice some limitations:
1. It doesn't work with curves (as you wrote, only straight lines).
2. It doesn't take the transform attribute into account (only uses the path attribute).

Did you take a look at the Measure Path extension (measure.inx and py)? There are lots of things (value written on the path, options dialog...) that you could reuse in your extension.

It makes me wonder whether it's possible to merge both extensions in one...

[su_v (suv-lp)]

@Tom - I compared the results of your extension to the actual area of a square and a triangle and seem to get wrong results. I also tested the polygonarea extension from <https://code.launchpad.net/~ted/inkscape/polygonarea> and got correct results. Do you know what could cause the difference?

tested with Inkscape 0.47 and 0.47+devel r9125 with Python 2.5.1 and Python 2.6.4 on OS X 10.5.8

[Alvin Penner (apenner)]

    Attached is a proposed modification of the "Measure Path" extension. I've added a new option called "Measurement Type" which can be switched between length and area. I believe the area calculation will successfully handle the same situations as the original length calculation did: namely, any combination of lines, cubic Bezier curves and elliptical arc segments; and of course no scaling transformations.

As usual, any feedback would be appreciated...

[Alvin Penner (apenner)]

and the .inx file

[jazzynico (jazzynico)]

Tested with some very simple paths:
1. Square (10cm): 100 cm² (correct).
2. Circle (r=5cm): 78.56 cm² (should be 78.54 cm²).
3. Isosceles triangle (b=h=10cm): 49.98 cm² (should be 50 cm²).
4. Right rectangle (b=h=10cm): 50 cm² (correct).

2 and 3 accuracy errors are less than 0.1%, almost the same as what we get when using the length measurement type.

Commit?

[LucaDC (lucadc)]

> 1. Square (10cm): 100 cm² (correct).
It's 10x10 = 100. Good.

> 4. Right rectangle (b=h=10cm): 50 cm² (correct).
It's 10x10/2 = 50. Good. (well, I suppose it was a right triangle...)

> 3. Isosceles triangle (b=h=10cm): 49.98 cm² (should be 50 cm²).
It's 10x10/2, i.e. 100/2: why is the calculation correct for the rectangle and not for the isosceles?

> 2. Circle (r=5cm): 78.56 cm² (should be 78.54 cm²).
It's 5*5*pi, i.e. 25*pi: so is 3,1424 the internal representation of pi (12 bits)?

I understand that the problem lies in the internal management of measures in cm, so round "external" numbers are not internally round.
I feel that the precision is low given the simplicity of the path involved: what will happen with much more complex ones? (well, if they are too complex it's also very hard to calculate the correct number by hand so who will ever try to show that results are incorrect? ;).
Jokes apart, it seems that you are not evaluating the precision of the extension, but rather Inkscape's precision (which is too low to me).

Regards.

[Alvin Penner (apenner)]

just a couple of quick comments on precision:

- for any type of arc shapes or circles, if they are convex, then the area calculated will be slightly too high. This routine uses the helper routine cubicsuperpath.py which converts arcs into cubic Bezier curves before performing the calculations, and there is a bit of systematic error in doing this conversion. The worst case scenario, I believe, is the case of a 90 degree closed arc. In this case I did a theoretical calculation that indicates that the calculated area may be too high by 0.03 %, which is roughly compatible with the error quoted above.

- for the case of a polygon, I have not been able to detect any errors, could you attach a sample svg file?

[Alvin Penner (apenner)]

any objections if I commit this?

[jazzynico (jazzynico)]

Maybe a short note about precision in the help tab?

[su_v (suv-lp)]

Could the location for the inserted area measurement string be changed to use the center of the selected object?

(my reference for this is, as mentioned in comment #10, the extension 'Polygon Area' <http://bazaar.launchpad.net/~ted/inkscape/polygonarea/revision/8980> in the branch <https://code.launchpad.net/~ted/inkscape/polygonarea>)

[Alvin Penner (apenner)]

thanks for the ideas, I'll see what I can do, during the next week or so...

[Alvin Penner (apenner)]

attached is a modified version

[Alvin Penner (apenner)]

I've added some notes on numerical precision, and relocated the text to roughly the center of the object, just for the case of an area calculation.

[jazzynico (jazzynico)]

Thanks for these improvements, Alvin!
Could you please xlink the area text to the shape (the same way it's done for the length text)?

Attached is an help tab suggestion (just a layout change).

[Alvin Penner (apenner)]

- yes, I like the style of the new help text, it is easier to read.

- attached is a new version of the python file. I have added the xlink:href element and made the style of this text as close as possible to the original length measurement text.

[Alvin Penner (apenner)]

attached is an edited version of the isosceles error.svg file. It appears that the problem with the green triangle is that the upper right corner is slightly lower than the upper left corner. This does not affect the width or the height but it does affect the area. I copied and pasted the object and edited the new object to fix it. The upper left in the new object had a y value of -1.562 cm and the upper right had a y value of -1.604 cm. I edited the upper right to be the same as the left. Now the width and height are the same at 10 cm, but the area has the correct calculated value.

[su_v (suv-lp)]

> Could you please xlink the area text to the shape (the
> same way it's done for the length text)?

This doesn't work (r9361): the text is not really linked to the shape.

AFAIU the syntax used for the length measurement string ('Text on Path') cannot be reused to place an upright text in the center of the measured path that is linked to and moves with the path e.g. when dragging the measured object (see <http://www.w3.org/TR/SVG11/text.html#TextOnAPath>). The area measurement could be either inserted the same way as the length measurement (overwriting each other if used both?) or placed as regular text object (not linked to, but possibly grouped with the path) in the computed center.

[Alvin Penner (apenner)]

    yes, I saw that the xlink:href was not having the desired effect, but was not sure what to do about it. I am not a big fan of text-on-path because it very often leads to text that is unreadable because it is wrapped around a sharp 90 degree corner. I would prefer to see text in a straight line. Currently the position of the text is calculated by taking a numerical average of all the vertices in the polygon that is used, ignoring the Bezier control arms. This average may be offset a bit towards the origin of the path because of the fact that quite often the start point and end point of the path are duplicated. This does not affect the area calculation but will affect the calculation of the text position. I don't think the effect is serious enough to be concerned about, but that's because I care only about numbers, nothing else matters to me.
     any suggestions as to how to proceed?

[Alvin Penner (apenner)]

okay, one last kick at the can, hopefully. I have modified the calculation of the position of the text so that it will ignore duplicate points if they occur. The text is now properly centered in the middle, as it was intended to be.

[Alvin Penner (apenner)]

committed to bzr rev 9374