How do I get my data from Garmin devices to ArcGIS online through Garmin's inReach Portal Connect?
Many users have implemented a solution using Geoevent Server. You set up an input using the 'Receive JSON on a REST Endpoint' input connector. Upon saving that input it will generate a url (the REST endpoint) that you can copy to your system clipboard.
Then navigate to the Garmin portal (https://explore.garmin.com/ ) > Settings tab > Portal Connect subtab (or go here: https://explore.garmin.com/IPC/). On the Configuration tab under Outbound Settings click the button to turn the Outbound Settings on and paste the url to the geoevent input in URL text box. Click Test to verify the Garmin Portal can reach your input. Then click Save at the bottom of the page.
Then all messages sent from your inReach (outbound messages) when they reach the Garmin portal, will be forwarded to your Geoevent Server.
We do not currently have a GeoEvent Server built, and will not have one for some time. Is there another way?
Absolutely. And in perspective if all you need to do is log inReach data to ArcGIS, Geoevent Server is serious overkill - way more than what is needed. However, you will need something to receive the inReach data, reformat it to to Esri json and send it to your feature service.
One method I have used in the past is a custom http handler. The Garmin Portal is equipped to send to any REST endpoint so you could write a simple http handler and host it on a web server. The web server would provide the REST endpoint to which Garmin could send the inReach messages. As they are received the http handler could reformat them into feature json and POST them to the addFeatures method of a feature service in your ArcGIS portal. This is a relatively simple task for a web developer.
Also there are cloud based ETL (extract, transform, load) platforms that you might be able to leverage. Do an internet search on 'cloud etl arcgis' and see what you can find. I have not used any of these so I have no perspective as to the cost effectiveness, ease of use, reliability etc of these.
Ken Gorton Rebekah Jones
We are going through this same process - attempting to figure out how we could write the HTTP handler code to fit with our potential asset tracking systems (Verizon and Garmin inReach). I have found that both solutions involve an HTTP handler code but I haven't found a sample of what that might look like. Do either of you have a sample code or any information that would help our IT department develop it?
I looked through my old files for the HttpHandler I wrote but it's been quite a while so I'm afraid I have nothing to send. However, in the interest of keeping it modern you can certainly do this on any of the major cloud platforms using serverless compute such as Amazon Web Services Lambda, Azure Functions, or whatever Google calls their incarnation of this. This tutorial walks you through setting up a serverless compute resource on Azure (for free): Create your first function in Azure using Visual Studio Code | Microsoft Docs .
Following this tutorial I was able to set up a function to receive GET or POST requests and return a response. You could then modify the code to receive inReach messages, reformat them to feature service json and send them via http POST requests to the ArcGIS feature service of your choice. Again, some internet searches turned up examples of how to make http POST requests from within Azure Functions.
Sorry I cannot provide actual code examples of my old HttpHandler. But if I were to set out to recreate such a capability I would leverage AWS, Google or Azure serverless compute resources instead. Good luck.
Thank you so much for the information! You will have to forgive me because I am just learning about how to utilize API's and rest services for streaming, but what do I do on my end in ArcGIS Online map applications to get their code to work? I just started looking for trainings or sites that would help me understand doing that just as a general practice in the online mapping world.
No problem. There is nothing you need to do in map applications for this. It's simply a matter of sending features to your feature layers. To add features programmatically via web requests, your code should send features in json arrays to the addFeatures REST endpoint of the feature service in question. See this doc: Add Features—ArcGIS REST API: Services Directory | ArcGIS for Developers for more details and examples.
Thus the inReach Portal would forward messages from inReach devices to the rest endpoint of your Azure Function, which will reformat the inReach json into ArcGIS feature json and POST it to your feature layer.
Well, I got ambitious and decided to check out writing a utility to send inReach messages to an ArcGIS feature layer.
I ended up creating a serverless compute function in Azure Portal that receives POST requests containing inReach JSON in the same schema that the inReach Portal sends. Then it reformats the messages into Esri feature JSON and sends them to a feature layer.
When this function receives a POST request containing inReach data, the function reformats the inReach json into Esri feature json and submits the data to the following feature layer:
If you have the proper credentials on inreach.garmin.com and wish to test this, feel free. Just log in to inreach.garmin.com go to Settings > Portal Connect, toggle Outbound Settings to ‘On’ and paste the ‘inReach2ArcGIS’ url below into the URL line. Click Test and Save.
inReach2ArcGIS’ url: https://inreachfuntions.azurewebsites.net/api/inReach2ArcGIS
Assuming the test message is successful, you will see new output in the feature layer. Then start your inReach device(s) and verify that their data arrive in the same feature layer. Keep in mind there is no security on the feature layer so anyone who accesses it can see all the data.
If you would like to implement this in your own space you may get the C# code from this Github repo:
GitHub - kengorton/inReach2ArcGIS: An azure serverless compute function to receive Garmin inReach event messages, conver…
If you do try this out I would be happy to hear any feedback.
i have hosted your function on my Azure portal and tested on inReach portal and test successful. i have replaced with my own feature service with same structure of fields, but i am getting below error, any idea ?
Hi Surenderreddy Konatham,
This may happen if your Azure function's Authorization level is set to Function or Admin which would require inReach Portal Connect to send authentication credentials with each request. If this is required it may be possible for you to implement that but I do not know what would be required to do so.
Switch auth level to Anonymous by going to Integrate settings in your Azure function:
then set Authorization level to Anonymous:
and click save.
Also, I found and corrected an error in my code so please update your function. While verifying this behavior this morning I noticed I had left off a rather important element to the feature json that gets sent to the feature layer - spatialReference (DOH!!!). InReach sends data in WGS84 (wkid 4326) while ArcGIS Online feature layers use, by default, web mercator (wkid 102100). If incoming features include spatialReference info other than web merc, the feature layer will project them correctly to web merc and store them. Otherwise it assumes the features are already in web merc and does nothing to the geometries resulting in incorrect placement for inReach features.
I have updated my code on GitHub.
I got your latest code updates from GitHub.
I tried using both the Authorization level options (Anonymous and Function), but no luck, Please refer below snapshot. but i got success with your feature service, is there any security configurations or any other settings i need to look on my feature service?
The example on the right makes perfect sense. You get a 401 (Unauthorized) error because the Azure function has an authorization level of 'Function' meaning it restricts requesting clients to only those sending proper credentials. inReach Portal sends no such credentials so the request fails. This is why you must set the function's Auth level to 'Anonymous'.
Regarding the left example, is your feature layer shared with everyone? The code I shared assumes an unprotected destination feature layer. Thus it does not send a token or any other kind of credentials. This is entirely possible to enable. To do so follow guides and examples for our .Net developer API. That being said, I suspect the issue is something else given the error returned. When I unshared my feature layer and attempted to send a test message from Portal Connect, the error returned was a 400 (Bad request).
Can you confirm the destination feature layer is of the correct schema? If not you can create a new one in your portal by using mine as a template.
Can you share the url to your feature layer? If you are reluctant to post it in this public forum thread but are willing and able to share your feature layer with me you may email me directly at email@example.com. I will be happy to have a look.
I got success with my new feature service, thank you so much.
I really appreciate your support on this issue.
Retrieving data ...