I am a design master's student and I'm making a prototype service that plays back geo-tagged audio clips that are nearby to the user, based on the user's live location. I am interested in using Node-RED as a prototyping tool to build a basic browser application for use with both iOS and Android mobile devices.
In order to make this work I need to get the user's live GPS location, ideally every 10-20 seconds. I tried installing the node-red-contrib-gpsd GPSd node, but for some reason it wouldn't install in my palette (not sure why). From my understanding, it's also not quite right for my application.
I am therefore looking to use existing Geolocation APIs to build a new Node and would like to ask if anyone can help, or has done this before? Some of the APIs I came across and was considering using are the HTML Geolocation API, Mozilla's Geolocation API and the W3C Geolocation API.
As you may be able to tell, I am pretty new to Node-RED, so any help would be greatly appreciated!
Where is node-red going to be running? i.e. on what device and where will that be located? The iOS or Andriod device will have to send it's location to the device running Node-RED
One other issue you may run into is that that node ( node-red-contrib-gpsd) hasn't been updated in 3 1/2 years and may not work at all anymore. And if it did, I wluod imagine it would be picking up the location of the device that node--red is running on, not the phone the user is using.
Have you had a look at using https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API ? @Colin's suggestion makes use of this in the mobile device browser, which you can send back to a host/cloud-based node-red instance via web-sockets, or a pub/sub protocol like mqtt.
If you want to build a new node, check out node-red-contrib-web-components as a basis -- it might help to make it straightforward to wrap the browser geolocation data into server-side node-red events
@zenofmud we plan to use Node-RED to build a browser-based web app that is linked directly to the cloud-based server, so most of the processing will take place on the server side. We've been in touch with @ibmrcruicks and will be trying the web-socket approach he suggested