LiveCode Forums.

hello to everybody,
i am mario an italian Revolution user.
i have a
2 questions for you:
i would to know how and if is possible calculate the area of an irregular polygon in Revolution, cause i use it for manage farm maps.
and if is possible calulate the number of pixels inside a geometric plan form


i wish someone of you could help me

bye,
Mario

The normal way to get the area of
a polygon is to draw a rectangle
around it which goes through
the top, bottom, left and right points
of the polygon.

Then canculate the areas of the
triangles outside the polygon
(but inside the rectangle) and
subtract them from the area of
the rectangle.

Needs some knowledge of using
sin,cos,tan etc. and some known
dimensions and angles.

Hope this helps.

Hi Mario,

bjb007 is probably right in what he said regarding the math, but since I am not good at math myself I figured why not let revolution let it do another way

It is a little more involved than I thought but here it is, a solution for someone avoiding the math...

the recipe:

start out with a new stack all white and shiny
make a polygon graphic that you name "AreaOfInterest" in the inspector
make a field you name "f1" in the inspector
make a button the name is not important

set the script of the button to the following script:

---------------------

on mouseUp
if not (there is a graphic "AreaOfInterest") then
answer "couldnt find graphic to analyze"
exit mouseUp
end if

if there is a image "ImageForArea" then delete image "ImageForArea"
put the milliseconds into start

-- set up the graphic for black
put the opaque of graphic "AreaOfInterest" into tOldOpaque
put the backgroundcolor of graphic "AreaOfInterest" into tOldBackground
set the opaque of graphic "AreaOfInterest" to true
set the backgroundcolor of graphic "AreaOfInterest" to black
------
-- here you could move the graphic to a part of the card that is white
-- since if you have overlapping areas in the graphic then
-- this script will return incorrect results
------

-- turn the local coordinates of the graphic into global coordinates
-- since snapshot will not directly take a picture of the graphic
-- because snapshot ignores the opaque property of the graphic
-- and the imageData all black
put the rect of graphic "AreaOfInterest" into myRect
put item 1 to 2 of myRect into tTopLeft
put item 3 to 4 of myRect into tBottomRight
put globalloc(tTopLeft) into item 1 to 2 of myRect
put globalloc(tBottomRight) into item 3 to 4 of myRect

import snapshot from rect myRect -- ( the rect of graphic "AreaOfInterest" in global Coord)
set the name of last image to "ImageForArea"
set the loc of image "ImageForArea" to the loc of graphic "AreaOfInterest"

-- now calculate the area
put the width of image "imageForArea" into tWidth
put the height of image "imageForArea" into tHeight
put tWidth * tHeight into tSoManyPixels

-- now get the imageData -> Documentation
-- each pixel has four bytes
-- the first for the alpha channel which does not interest us
-- the second for red
-- the third for green
-- the fourth for blue
-- each byte has a value between 0 and 255
-- if you do a charToNum of the byte ->Documentation
-- if the color bytes are all 0 then the pixel is black, that is what we are looking for

-- since each pixel has four bytes the number of bytes is pixel times 4
put tSoManyPixels * 4 into tSoLong

put the imagedata of image "ImageForArea" into tImageData

put 0 into tB -- for the numtochar = 0
put 0 into tBlack -- counter for black pixels
put 0 into tOther -- counter for non-black pixels

repeat with i = 1 to tSoLong - 4 step 4
if the chartonum of char i +1 of tImageData is tb and \
the chartonum of char i +2 of tImageData is tb and \
the chartonum of char i + 3 of tImageData is tb then
-- only if all three bytes are 0 then the pixel is black
add 1 to tBlack
else
add 1 to tOther
end if
end repeat

-- get rid of the image that was analyzed
delete image "ImageForArea"

-- restore the graphic
set the opaque of graphic "AreaOfInterest" to tOldOpaque
set the backgroundcolor of graphic "AreaOfInterest" to tOldBackground

put the milliseconds - start into tTime
put "The image has " & tSoManyPixels & " pixels of which " & tBlack & " are black and " & tOther & " are not black" \
& return & "black and non-black pixels add up to " & tBlack + tOther & return \
& tTime & " milliseconds" into field "F1"

end mouseUp

---------------------


read the comments in the script

the basic idea is to make the polygon filled black then make a snapshot of the polygon and you get an image
the image is analyzed for black pixels
the number of black bixels is displayed in the field

so the number of black pixels is the area of the polygon in pixel

(maybe it is easier to learn the math???)

obviously you have to be careful to 'isolate' the polygon from adjacent objects, you could move it temporarily to a white spot on the card, or you could hide temporarily the adjacent objects.

hope this helps

Bernd

Bernd
An interesting approach and I'm going to
play around with it!

The problem with pixels is that you can't
have half a pixel so to use it accurately
you'd need to scale it to suit whatever
measurements you have for the area.

With modern land surveying equipment (GPS etc)
I expect this could be to a high accuracy
-possibly less than ten mm- so one pixel would have to
represent at most ten mm.

For even a small plot of land this would
probably mean a lot of pixels!

Thanks for all the interesting ideas you've
given me.

bjb007,

agreed, the accurracy is a problem and I wouldnt buy land based on this, especially since the square mm is expensive nowadays.....

for accuracy you should probably do the math (which as you know I cant)

And in the pixel approach one one has to account for the border of the polygon, do you want it to be part of the area or not.

Having said that, I figured that Mario has some sort of image of a map which he overlays with a irregular polygon to mark different areas. So the inaccuracy is in the scale of the map and the inaccuracy of the irregular polygon in the first place. And if you just want to have a pretty close idea of the area, say for seed use, fertilizer use, water use or whatever you use on a farm, the pixels could be all you need.

I'm glad you liked the approach

all the best

Bernd

The code at the following link is an approach that will handle the area of irregular polygons of various shapes. It does a good job of explaining the concept, complete with pictures. No Rev code, though. Anybody who wants to implement this and share their code is welcome to do so. I might give it a shot in a month or so when I have some time.

http://alienryderflex.com/polygon_area/

hi bern tnks for your reply, cause you solve all my prblms
stay in touch by
Mario

Hi Mario, bjb, TEDennis,

well, the link provided by TEDennis to a website explaining polygons
http://alienryderflex.com/polygon_area/

helped me in doing some math on the area,

I looked at the part with the simple polygons i.e. polygons that dont intersect themselves.
I tested the algorithm on fairly simple polygons and the area it returned was ok.
no guarantee, though
but for Mario it should be ok since tracing the outline of a map should not intersect on itself.

make a new stack
create a polygon called "AreaOfInterest"
create a button
set the script of the button to:

-----------------------------------
-- for simple polygons with
-- as many points as you like but that
-- dont intersect themselves

on mouseUp
if not (there is a graphic "AreaOfInterest") then
answer "couldnt find graphic to analyze"
exit mouseUp
end if
-- this closes the polygon in case there was a gap
put the opaque of graphic "AreaOfInterest" into tOldOpaque
set the opaque of graphic "AreaOfInterest" to true
set the opaque of graphic "AreaOfInterest" to tOldOpaque

put the points of graphic "AreaOfInterest" into tpoints
put 0 into tarea
repeat with i = 1 to the number of lines of tpoints -1
-- the verbose version, easier to debug
put item 1 of line i of tpoints into x0
put item 1 of line i + 1 of tpoints into x1
put item 2 of line i of tpoints into y0
put item 2 of line i + 1 of tpoints into y1
put ((x0 + x1)*(y0-y1)) into tpeekArea
add tpeekArea to tarea

-- the oneliner version
-- add ((item 1 of line i of tpoints + item 1 of line i+1 of tpoints)\
-- * (item 2 of line i of tpoints - item 2 of line i+1 of tpoints))\
-- to tarea
end repeat
put abs (tarea * .5) into tall
put return & "the area in pixels is " & tall
end mouseUp
-------------------------------

this takes the points of the polygon, closes the polygon if it is not closed
and calculates the area.

Advantage compared to my hack with the snapshot and then counting black pixels:

the border is not counted in, it is faster hopefully more reliable,
if the polygon is very small the snapshot returns erroneous values.

any feedback on this most wellcome

bernd

Hi Mario,

Just to add to the fun, since you are talking about managing farm land area:

See

http://www.robertcailliau.eu/Alphabetic ... ta-en.html

In 1969 I bought that calculator and the algorithm for computing areas that is discussed on this forum is already in the booklet as a standard way for geometers to compute land area! It is a very old algorithm and is normally part of high-school maths...

I also have a stack that uses the same and allows you to trace a polygon over a picture of a map and then calculates the area to scale. It's not a very good stack, but I can send it to you if you want.

Robert.