After the update of the node-red-contrib-turf repo I thought about re-writing the whole repo or creating a new repo where every turf function gets its own node. I have create a mockup repo here: node-red-contrib-turf-functions
The idea would be to write a script that parses all packages (maybe the index.ts typscript files) of all packages that make sense to have its own node and create the node dynamically based on the typescript definitions.
As some functions like @turf/difference have multiple inputs I thought about referencing incoming messages by the node name so we don't need to have an extra function and/or join node inbetween. Is there a better way to this? Multi inputs are not possible as I read in the forum.
Things I am currently thinking about implementing:
Custom Validation for every input based on the ts definition (Feature<Polygon | LineString>, Geojson, Coords etc.)
An additional third tab for the JSON Editor (Edit JSON, Visual Editor, Leaflet Editor) with a LeafletMap where the input feature can be drawn directly (only make leaflet draw handler available which the node accepts as input - e.g. the @turf/difference node would only allow to create a polygon feature or multipolygon features, the @turf/along node would only allow to create a linestring feature)
@dceejay - maybe you have some input on how this could be achieved and give some guidance based on the mockup repo.
I would possibly not create one node per function as there are so many of them it would swamp the left menu completely - and most people only really use a few. If you do feel the need then please do it as a separate repo - so the old one can still exist
I did wonder about making the functions a select list so only certain functions could be picked but again the list was rather long and again unless you go completely to town and start to add docs to each option then they are hard to understand... If you have to look at the turf manual anyway, then typing in the function name isn't too hard...
I'm not sure what the input editor would help achieve - as that wouldn't be available to users of the flow once in operation - and most things I can think of would need dynamic input - maybe a geofence ?
Yes multiple inputs are tricky - normally we tell things apart by being different properties of the input message - as that is the only way we can be sure they are part of the same operation. (You can use a property such a topic to indicate the contents of the message - but there is no guarantee that the next msg is to do with that one - or the next one in sequence etc.)
Regarding the input editor. One usecase I can think of is having a map (maybe with an address search - maybe with nominatem osm search or a config node where the user can set a google search key) to create a point feature which is the destination for a line of sight analysis. Or drawing a corridor around an airport for a no-flight-zone. While doing some prototyping it would be a nice way to generate sample data fast.
You are right about the amount of nodes that would be created. Dynamic inputs and a selection dropdown would be better.
Like in the sample repo I would create a special property called turfNodeName which is set if the node has a config.name property. If the current node uses a string Input (eg. bbox) rather than a json Input the node waits for an InputNode with the name bbox and uses the data in the msg.payload from this node.
I couldn't find any better way for the help information than a modal overlay with a help button. Is it possible to update the help section dynamically? I think this would be more the default "node-red way".
Empty json inputs are always highlighted with a red error outline. Is it possible to set a custom validation for the default json type?
I thought about having a custom type for the callback function inputs so the user could write the callback directly in the node without the need to use a function node before - any idea where to start?
