Is it possible to easily pull the file that creates the actual range outline on tar1090 and load it somewhere else (maybe google maps?) to do a comparison?
Going to move my antenna to the attic and see if it improves range. It would be really cool if I could compare before and after by grabbing that points file somehow before the move and then again a few days after to visualize the difference in range.
/tar1090/data/outline.json
You’ll have to convert the format to display it somewhere else.
With access to the json data you may find this tool useful for creating plots and layers.
An approach I use is to show the map full screen, position it in a specific, repeatable way which maximises the area of interest (for example the plot region), and then screenshot it. I can later compare the map, in the same configuration, with the screenshot and see if things have improved.
This stuff is slick! Thank you for the replies.
Pulled the outline.json files off each of my 2 feeders and dropped them on a single map to compare. (One has a much better antenna+airspy and a better view.) I’ll do the same later to compare the before/after range from my main feeder when I move it to the attic.
Here’s my code in case anyone else wants to try. Just put your outline/shape files in the same directory as this map.html file. Name them 1-outline.json and 2-outline.json
Start a simple web server with python3 -m http.server and browse to http://localhost:8000/map.html to view them compared.
<!DOCTYPE html>
<html>
<head>
<title>Flight Range Comparison Map</title>
<link rel="stylesheet" href="https://unpkg.com/leaflet@1.9.4/dist/leaflet.css" />
<style>
/* Reset default margins and make html/body take full height */
html, body {
margin: 0;
padding: 0;
height: 100%;
width: 100%;
}
/* Make map container fill the entire viewport */
#map {
height: 100vh;
width: 100%;
}
</style>
</head>
<body>
<div id="map"></div>
<script src="https://unpkg.com/leaflet@1.9.4/dist/leaflet.js"></script>
<script>
// Initialize the map
const map = L.map('map').setView([41.0, -77.0], 7);
// Add OpenStreetMap tiles
L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
attribution: '© OpenStreetMap contributors'
}).addTo(map);
// Fetch and process the first JSON data
fetch('1-outline.json')
.then(response => response.json())
.then(data => {
// Extract the points array
const points = data.actualRange.last24h.points;
// Create a polyline from all points
const coordinates = points.map(point => [point[0], point[1]]);
L.polyline(coordinates, {color: 'blue', weight: 2}).addTo(map);
});
// Fetch and process the second JSON data
fetch('2-outline.json')
.then(response => response.json())
.then(data => {
// Extract the points array
const points = data.actualRange.last24h.points;
// Create a polyline from all points
const coordinates = points.map(point => [point[0], point[1]]);
L.polyline(coordinates, {color: 'darkblue', weight: 2}).addTo(map);
});
</script>
</body>
</html>
Very slick, thaks for that code, it’s always handy to be able to do that, and that’s a nice, temporary self-contained solution that doesn’t interfere with the main setup.
Data is fun. Made a program to compare the area of the real range shape outlines.
Save it as shapeVolume.py and call it like this:
./shapeVolume.py outline.json
Or get “fancy”, haha
for shape in east-outline.json west-outline.json combined-outline.json ; do ./shapeVolume.py $shape ; done
Result -
Area: 27994 square miles (east-outline.json)
Area: 75356 square miles (west-outline.json)
Area: 75758 square miles (combined-outline.json)
In addition to the visual comparison, this gives a concrete way to compare results.
Here’s the shapeVolume.py code:
#!/usr/local/bin/python3
from shapely.geometry import Polygon
import pyproj
from functools import partial
from shapely.ops import transform
def ensure_polygon_is_closed(coordinates):
if coordinates[0] != coordinates[-1]:
return coordinates + [coordinates[0]]
return coordinates
def calculate_area_sq_miles(coordinates):
closed_coords = ensure_polygon_is_closed(coordinates)
poly = Polygon(closed_coords)
wgs84 = pyproj.CRS("EPSG:4326")
equal_area = pyproj.CRS("EPSG:6933")
project = pyproj.Transformer.from_crs(wgs84, equal_area, always_xy=True).transform
poly_equal_area = transform(project, poly)
area_sq_meters = poly_equal_area.area
area_sq_miles = area_sq_meters / (1609.344 * 1609.344)
return area_sq_miles
def process_file(filename):
coords = []
with open(filename) as f:
import json
data = json.load(f)
points = data["actualRange"]["last24h"]["points"]
coords = [(point[1], point[0]) for point in points]
area = calculate_area_sq_miles(coords)
print(f"Area: {round(area)} square miles ({filename})")
if __name__ == "__main__":
import sys
if len(sys.argv) != 2:
print("Usage: python script.py <filename>")
sys.exit(1)
process_file(sys.argv[1])
My impression was that this range outline only grows (unless reset), but the beginning of the outline.json file says last 24h:
$ head outline.json
{ "actualRange": { "last24h": { "points": [
[42.6574,-77.3469,45000],
[42.8021,-77.2947,45000],
[42.7669,-77.1807,38975],
...
Is that just formatting/formality in the json file or is just last 24 hours actually used for the outline?
Where does it say that it’s persistent?
On the other hand the last24h is hardcoded i think … which is unfortunate considering you can change that timeframe.
https://github.com/wiedehopf/readsb/blob/dev/help.h#L83C1-L84C1
Changing it now would break at least one user.
I guess i can add a new field that indicates the actually configured duration …
I don’t think it matters enough to make a breaking change (it would break my volume calculating program too, although easy to fix.)
It’s more that I just noticed it and wanted to understand whether or not to believe that label.
Where can we change how long the range is kept for? Whether or not the file format is changed, I’d probably like to set mine for 7d / 168h.
I understand ADSB.im isn’t tar1090, but in Maps → Options a checkbox allows resetting the range outline. That gave me the impression it only grows or becomes static overtime, otherwise the checkbox wouldn’t be necessary if points in the polygon recalculate every 24h).
People are impatient, so yes the checkbox is very necessary.
env vars for the various containers are documented with the containers: https://github.com/sdr-enthusiasts/docker-adsb-ultrafeeder
This is “advanced usage” as you know and the usual disclaimers apply.
A quick ctrl-F shows READSB_RANGE_OUTLINE_HOURS
Well, yes and no.
The range rings don’t display the distance that your system can detect an aircraft, it displays how far (in a given direction) your system does detect an aircraft.
As an example, say you have a day of perfect conditions, and on that day you happen to pick up a plane that’s flying an unusual route & it’s 50 miles farther than you normally get. Your range ring is going to show a big point on that side (and your area calculation will improve). Now, you make a change to your setup - new antenna or SDR, gain change, whatever. You may well have improved your receiver, but because that unicorn flight 50 miles out isn’t there anymore, your range ring could look worse.
Remember that you can only detect aircraft that are there.
Using my system as an example, I should be able to detect aircraft out to about 100 miles into the Pacific Ocean. But I never get any flights more than about 50 miles offshore. That’s because flights along my section of the coast don’t usually fly that far out. So, my ring is pretty flat on the west side. If there happened to be one at 75 miles one day I would record it, and it would appear to distort my range ring, but there is basically nothing that I could reasonably do with my setup to increase range in that direction because there aren’t planes to detect out there.
My point is that range rings are a tool. They help visualize the performance of your system. But they are far from the tool.
Sure. What tool(s) do you prefer?
Aircraft seen is wholly dependent on how many are flying. Messages, maybe, though high message count doesn’t translate to high number of planes spotted, it could just be long tracks.
Agree that there isn’t one tool to rule them all, but its the best metric I know of for the optimization I’m interested in, particularly if setting READSB_RANGE_OUTLINE_HOURS to a sufficiently high value, like 168 hours, to rule out day to day weather or flight volume variations. If my range ring goes appreciably up after raising the antenna, I will consider the new location a success.
I think by “compare results” @bmcent1 is referring to how well one setup did detect aircraft compared with how well a different setup did detect aircraft. If the data is collated over a timeframe it provides a useful and broad measure of whether the change in setup gave better or worse results.
For example I might record a range plot over the course of a week and see that I can generally reach certain parts of the UK. Then perhaps I add a cavity filter and reset the plot, and over the next week I see that range is significantly reduced in all directions. The visual comparison means I can reasonably conclude that the filter had an overall negative effect on the site. I could then return to the original setup and reset the plot and expect to see it return to something like the plot I had originally.
Capturing the data over a period increases the chances of capturing what you call unicorn flights, but also means that their overall effect is limited and can be ruled out by intuition and knowledge of the site’s behaviour and the changes made. In many cases I’d say there is value in comparing the areas, subject to the above, since that approach cannot interpret one-offs as you suggest. Personally I’d prefer to compare them visually as I think there’s more information available that way.
I’m not crapping on range rings, I just believe that they are one tool for assessment. I also look at percentage of strong messages, message rate, peak number of aircraft, total aircraft over day/week/month.
I guess my point is that the receiver is a system with inconsistent and unreliable inputs, and evaluating a change shouldn’t rely on just one data point.
But that’s just my opinion.
I captured an outline.json file and then did an area calculation using shapeVolumne.py. Waited a couple of minutes and repeated the process. The second area was smaller than the first area. How can that be? In my case I’m using the outline.json file at /run/adsbfi-feed/.
Why wouldn’t it be.
It’s by default taking into account the last 24h.
Oldest data are discarded. Time resolution of the data is duration / 64.
For each time slice the data only records the max.
I had just restarted adsbfi-feed so there wasn’t 24 hour old data. What is a time resolution of /64 ?
I guess I’m still not getting it.
24 hours divided by 64 in this case.
But as you can adjust the timeframe i wrote “duration / 64”.
Ok in this case you’d have to look at the polygon.
See if maybe your library for calculating it is having issues with it somehow?
Also to avoid having the exact receiver location in the file, the actual aircraft position in the angular bucket is used, not the angle / direction of the bucket itself.
I’m not exactly sure how that would make the area smaller but i wouldn’t want to exclude that possibility.
I don’t think it would be much.
Without having both outline.json files and that python script … you can’t really check this.
Not sure i want to i’ve never visually seen the outline get smaller.
So to be honest i’ll just assume you did a reset without knowing or the python script is mistaken?
I was thinking there might be a problem with the outline.json file being written to while I’m reading it. The file might be in an inconsistent state when I read it.
No it’s written to a temporary file and then atomically moved.
(that goes for pretty much all files written by readsb)
