Posted on

Hosting your own network map

If you’re a wireless internet service provider or an organisation who want to show an online coverage map there are different options available depending on your level of skill. The basic option is to do this with an arbitrary polygon on a free map like Google maps but if you want a beautiful and accurate physics based coverage map, at no extra cost read on…

Embed code

The easiest way to add a map to your website or blog is with the embed code function. This is a small code (HTML) snippet which you paste into your website, like WordPress, for example. It requires that your blog supports HTML content.

To use this first you must have a layer in your archive. This could be a single area calculation or a large network mesh created from lots of individual calculations. Select it and click the code icon.

You will then be shown your embed code and a notice.

Google Maps Key

The notice says “Replace ‘GOOGLEMAPSKEY’ with your Google Maps key“. This is necessary as you need a key to share an online map as it’s licensed, not a free-for-all. You can get a key at no cost from Google if you visit this link:

https://developers.google.com/maps/documentation/javascript/get-api-key

To test your key works visit a HTML online editor, paste in your embed code and replace GOOGLEMAPSKEY with your long random Google Maps key. If successful you will see your map and your embed code is ready to go on your website!

Self-hosted (Expert mode)

The downside to embed code is the layer must be fetched from a server from Europe. For most users this won’t be a problem but if you are in Australia and your layer is quite large this could result in a blank map for a second or two – not a great advert if you are a business.

To deliver a faster map to your local customers, host the layer yourself. To do this, take the previously described embed code and extract the long link starting https://api.cloudrf.com/…

Paste that into a browser to visit the page directly then view the source code. Here you will find a link to a .png image in your archive as well as the necessary Google Maps Javascript.

Copy that code to your own website and download the PNG image. Upload the PNG image to your server and edit the link so it points to the local copy eg. yourcompany.com/files/yourlayer.png

Copy the code between the html tags.

Terms and attribution

You can host as many of these maps as you like for no extra cost but unless you have written permission, attribution is required. This is already included as a small link on the map but we won’t object if you want to add your own label too.

We will host your data so long as your account is in credit. If your account is not in credit we will retain the data as per the plan limit which is two years in most cases.

If you need your image to be available for lots of website visitors or for longer than 2 years, we strongly recommend self-hosting your PNG layers.

Posted on

API 2.0

CloudRF API

We have a new API.

This long awaited update brings an OpenAPI 3.0 compliant REST implementation with a redesign of public facing architecture so all requests will go to https://api.cloudrf.com and documentation will be at https://docs.cloudrf.com

Human readable requests

The old API grew into an exhaustive list of +43 variables starting from only 10 when it was an Android app. That’s just the public ones. There’s more parameters relating to interfaces. We were adding about a dozen variables a year in the early years of the service and turned down many requests for protocol-specific parameters to keep the number manageable and keep the API signal and technology agnostic.

The new JSON body schema tidies these +40 variables into logical objects which not only align with the interface but can be dropped completely for example in the case of the optional environment object, and defaults used.

New endpoints

The CloudRF API is now at api.cloudrf.com

Documentation is at docs.cloudrf.com

We’ve got OpenAPI / Swagger documentation at https://api.cloudrf.com/swagger-ui/

Legacy ../API/ endpoints and old API documentation are still active and will be until October 2021.

OpenAPI

New functions

Some previously undocumented interface features are now in the new API. These are exporting user files into GIS formats and uploading GeoJSON features as private clutter. These are now documented in API2.0

New authentication

The days of sending your unique identifier ‘uid’ and your API key in the HTTP request as uid=…key=… and then scrubbing them out of presentations are thankfully finished!!!

Now you have one API key which you must put into a HTTP ‘key’ header. This keeps your sensitive credentials separate from your body which contains site parameters. This also means the path to offline JSON templates is now clear. We’ve offered templates for years but as rows in a private database, now that the private bits are out of the way you can confidently share an API request.

JSON site templates

A nice feature about this new API is because the sensitive authentication parameters have been removed, and the entire site/antenna/environment exists as a single JSON object, you can take this away and share it, save it, reuse it, publish it. We’re going to build on this concept to offer a new style of template system so as well as saving your settings for quick reuse as you can now, you can share your settings.

This will also enable novice API users to create valid requests by fetching a template eg. “VHF radio.json” from the library and dropping it into an API client, along with their ‘key’ to run that template through their account.

Legacy API sunset 1st October 2021

The legacy API will still run in parallel and will be retired on the 1st October 2021. Please move your projects over to the new API soon and see our documentation and client code examples on Postman to do this.

We are publishing more application specific examples to assist with this and will be on hand to help customers migrate.