I’d like to have a grid of “square” zones for my home area. Just like the old school maps, where you have A1-N26 or some such. Is this possible? If not, how about a grid of overlapping circles? I’d like to be able to track users across the map and have automations based upon which grids they trigger.
Zones can only be defined by a centre location and radius. So you would have to use a grid of circles with either overlap or gaps.
Is there a reason why zones are circles, other than it just being easier to implement? I’m assuming the circle implementation takes a x,y point and runs that through each zone to see if it falls within the area of the circle defined by the zone and returns true or false. Is this correct?
I was thinking about this for a while and my Swokowski Calculus came back to me and if the above is true it should be simple to use an integral to see if the x,y point falls under the area of a curve defined by a definite integral, which would allow you to create zones of any shape by adding the definite integral tests together.
But if that’s possible, then you could define a square zone by a single point x1, and x2 = 2x1, y1=x, y2=2y1 and then check to see if x,y is within the borders.
It’s an interesting problem. For now I’ll see if I can write a function to create a zone file with overlapping circles or circles with gaps and use a smaller circle to fill the gaps and keep track of which circle was “last entered”.
I’m guessing yes, ease of implementation. Rather than having to perform a complex operation to determine if you are within a bounding box all you have to do is measure your location’s (x2, y2) distance from the centre (x1, y1), an easy calculation , sqrt( (x1-x2)^2 + (y1-y2)^2 ) and see if it is smaller than the zone radius.
I looked up a method for determining if a point was in a box. While it still relies on plain (plane) geometry it is far more complicated.
Acceptably this approach needs substantial amount of computation. This approach can be employed to any irregular polygon, too.
Yes, the irregular polygon algorithms simply use the rectangle function for a shape composed of many rectangles. But it also has to use a function for triangles as well. While the resources required for the computations are higher than circles, it’s not that much higher that it burdens a modern CPU. IIRC in my CS course we developed the algorithms that had little problem running on an 8088 processor.
Of for sure. It’s the lack of developer resources that cause the simple solution.
You may find useful the Geofences, in node-red, where you can specify areas like retangles.
1 Like
I’m no Python guru, and it seems there are no interfaces, but let’s say I wanted to create my own “zone” implementation which would define a zone as two x,y points, what would this class look like? Basically I’m looking for a stub where I can get running then integrate the calculus into at my leisure.
If anyone could help me with this stub, that would help me immensely.
Not sure but a zone would require at least three points. Two points just gives you a line.
Two points gives you rectangle.
Two points give you a line. Four points give you a rectangle. You can calculate four points from two if you assume the two points are at opposing corners of the rectangle.
That was my assumption. But I don’t know how grids would work with different definitions. How could a circle grid with one point and a radius determine if a location is in it vs 2 points?
Would you use something like location.isInGridRectangle (p1, p2)
The circle pattern is easy. Is the distance from your location to the centre of the circle smaller than the radius of the circle? If yes, you’re in it.
The rectangular grid is a whole different kettle of fish. As I linked to above.
My question revolves around if python allows interfaces, which if allowed would make this really simple.
A very good discussion - and it ‘should’ be relatively easy to do.
But it is a fundamental change to the way things are currently done (and that ALWAYS encounters resistance from those entrenched or just unwilling) There’s also the effort/benefit calculation 
I suspect the origins were that the fundamental (and only) use was to determine whether your home was occupied or not (for automation purposes). Things have moved on since then.
@pnbruckner may have some insights as he does a lot with location tracking. (Phil, sorry for the tag but you may find this interesting)
I would point out : -
- Some people’s properties (ie most) do not lie on cardinal orientations
- It would not be a true rectangle as it would instead be bound by lines of latitude and longitude (ie curves on 4 sides) unless of course you are a flat earther.
(but you’d have to be a real hairsplitter to be actually bothered by this) 
- I have previously used Google earth to get co-ords and then use them for zones - they (50%) often don’t line up and need subsequent tweaking. I don’t know why because GPS is GPS is GPS; but then again why are GPS coords 100m off (or is it 110m?) from Greenwich Meriden coords ???
Edit: the calculation SHOULD be a lot simpler. Is this coordinate bound by these latitudes and by these longitudes? Done.
In fact given this you could do it yourself in sensors / automations and scripts - but you couldn’t display it on the map 
Edit2: Also, if you watch a device tracker for a while, you will see that it sometimes jumps around (its entered party mode ) then it will settle down again, but maybe 17m to the left (or whatever) of its previous position.
Radii are much more forgiving of this behaviour than strict interpretations of ‘rectangles’ would be. Margins may thus be required and they are harder to calculate, as though latitude has a direct relation to distance. Longitude does not. (Small offset in Greenland is a large offset in Mexico)
I’ve only been involved with this project for a little over a year, so I don’t know all that much about the history of how things evolved.
What I can say is determining whether a device tracker is in a zone involves comparing its location to that of all defined zones. For each zone it first determines if the tracker is in the zone, and it does this by effectively comparing the zone’s circle (location & radius) to the tracker’s circle (location & “accuracy” radius.) If they overlap then the tracker is considered in the zone. Then for all zones it is in, it finds the zone which is the closest (i.e., just using the distances determined by the locations, without using the radii.) If there’s more than one that is closest, then it uses the zone with the smallest radius. You can see the implementation here.
Calculating the distances is a bit involved. You can see the implementation of the distance() function in this module. Pay particular attention to the vincenty() function that it calls.
Not having looked at how Python interfaces works yet, and assuming you do know (presumption of me, yes) how difficult/how much work would it be to create an interface and then apply that to the existing zone class?
I would be more than willing to setup a rectangular zone class. I’d avoid “party mode” at first but only using larger zones.
2 points always make a line. A 3d plane can be reduced to a single point, 2 vectors, a length, and a width.
If the math is assumed to be in the xy plane, a rectangle would be 2 points and a vector, where the vector describes the orientation of the limbs. Even then, you can get into invalid cases where your result has zero area, i.e a line or single point.
Eh ?
Sorry but to my pea sized brain this is not an issue.
Lets ignore latitude (say) and just deal with longtitude (though the same criteria apply, I’m just making the example easier)
so my zone is 170° to -170° degrees longtitude
my first test is : -
- Is the start greater or lesser than the end then apply either :
a) start < device < end or
b) device < start or device > end
if either is true the device is in the zone (rinse and repeat for lattitude)
if I’m an idiot and entered 220° then I get what I deserve
If I enetered a single point twice, I again, get what I deserve
In either case I’ll get a ‘Not In Zone’ (or whatever) response
Edit: IF I’m REALLY stupid (that is actually sometimes the case) and I put the top left coords in place of the bottom right coords (and visa versa) then I get a huge zone covering the whole earth, apart from my ‘house’