Viewing shapes on map

[Pierre M]

Daer node geofencers,

I added the ability to view shapes defined with the geofence node on a web-worldmap.

The dilemma is that we can either collect all shapes (regardless of the geofence node "action"), as long as they receive by at least one message, or we can only collect those areas that are affected by the "add inarea property" action, also as long as they receive a message. In the first case, shapes are collected in a flow-level variable (called shapes), in the latter case, shapes are collected into a message attribute (also called shapes).

In either case, shapes are sent to the web-worldmap thanks to a simple function node like this one (flow-level variable variant):

var shapes = flow.get('shapes');

if(shapes) {
    Object.keys(shapes).forEach(function(key,index) {
        msg.payload = {};
        msg.payload.name = key;
        if(shapes[key].points) {
            msg.payload.area = [];
            for(var i = 0; i < shapes[key].points.length; i++) {
                msg.payload.area.push([shapes[key].points[i].latitude, shapes[key].points[i].longitude])
            }
        } else if(shapes[key].radius) {
            msg.payload.radius = shapes[key].radius;
            msg.payload.lat = shapes[key].centre.latitude;
            msg.payload.lon = shapes[key].centre.longitude;
        }
        node.send(msg);
    });
}

return null;

Which of the two options do you find more useful?
Alternatively, they can both be set.

[Ben Hardill]

We should not be polluting the context with the shape objects they should only be attached to the messages that flow through the node

[Ben Hardill]

On further reflection I can possibly see some benefit to adding all the shapes to somewhere they can be read, but it should not be by default and should allow control of the name of the variable. If you add a checkbox and a textbox to take the name of the context variable (only active if the checkbox ticked) to the editor UI then I'll have another look

[Pierre M]

What’s wrong with the flow-level imposed ‘shapes’ variable name? (or any other name would do.) If the name of the variable has to be entered into each geofence node by the user, there is a risk the user enters different variable names, leading to numerous flow-level variables. Then the user has to make a little function call to display shapes for each variable where it stored shapes. That sounds confusing to me. P.

…

Le 7 mars 2017 à 14:56, Ben Hardill ***@***.***> a écrit : On further reflection I can possibly see some benefit to adding all the shapes to somewhere they can be read, but it should not be by default and should allow control of the name of the variable. If you add a checkbox and a textbox to take the name of the context variable (only active if the checkbox ticked) to the editor UI then I'll have another look — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFwDVxznb0I_k3irdRJ-K74VjSf8ql-rks5rjWH8gaJpZM4MOasv>.

[Ben Hardill]

It should be configurable to ensure it doesn't clash with something an existing user may already have in the context. It can have a default value already filled in but it should not be fix and it should not be on by default.