Changing brightness of a background image???

[Egil]

Larry:

If you by data point means, planes plotted, I have experienced 100 to 150 individual planes per received channel at any instant, and was planning to use a maximum of 8 channels (max four internally on the same pc as  this program, and receive the rest via UDP).

I plan to update the plot once a minute.

The planes send their position reports at approximately 10 minutes intervalls, and the ground stations poll if the reports has not been received.
Every now and then the planes and the ground stations lose contact. When this happens the planes log into another ground station. And since the new channel often is not monitored here, I was thinking of making some kind of simple database to take care of this, and make a provision to delete planes that have gone out of range 15 minutes after it was last heard. (maybe this ought to be user defined)

Brian:

flightradar.com and their competitor planefinder.net ( to which I am a contributor ), collect data from enthusiasts all over the world decoding transmissions from the secondary radar systems on the planes, and the ACARS system. Both are "short range" systems. And though it may look similar to the HFDL system, it is quite different. The HFDL system is a "long range" system.

Most newer planes today use CPDLC, which is a mix of satellite links and VDLM2 ( a "short rangne" VHF system, which is going to take over from the old ACARS system). Both these systems are very expensive, and  since all international planes are requested to have at least two such systems, many of them use HFDL (which is a relatively inexpensive system) for backup. And since a listener never will be able to hear shortwave transmissions from all over the world at the same time, I am not afraid of overloading the program.

Sitting in my shack monitoring, amongst others, chinese domestic fights, is at least to me, a challenge.


Egil

[Egil]

I created a little plane pic and  used a random num generator for pos
It puts a 1,000 and 10,000 on there instantaneously.

I was not planning to use plane drawing in this program, they cover a much too large area of the map to give a sensible position. Instead I was thinking of a very small colored square indicating the position, with a short line, drawn from the center of this square, indicating the direction of the flight. And let the user chose the colors).
This is what the "professionals" use on their radar screens.

I realize that to others this project may seem insane, but for me it is a hobby, and what can be more important than that? And doing it, I learn a lot of programming...


Regards,
Egil.

[LarryMc]

The 10 minute update will allow you to to process an unlimited amount of datapoints.  I'd say, based upon what I see right now 60-70,000 points would be no problem what so ever to locate and display a symbol.
multiple colored/sized planes and other symbols will be no problem.

You mentioned other maps like google maps - that's a problem

The only way I can make this work so you can have have more than two layers like you have now(full earth and one level of zoom) is for you to have a hi res image larger than your current 3600x1800 jpg you have now.

Having a square instead of a plane is no problem. I'll have to play around with the line to indicate heading since we're talking small and pixels. every 45 degrees is easy but in between is tough to show with just a few pixels.  I'll see if I can do it by rotating an image with a pointer on it.
As for allowing the user pick the color, it will have to be from a predefined set. The symbols will have to be pre-built in each available color. But that not really a problem.

Any other specific details you can give about how you envision this working(looking) will help as I proceed with the DeVil coding.  And this id encouraging me to learn what all  I can do with DeVil

[LarryMc]

I made a litle square with aline

[LarryMc]

run this

[Egil]

The example map I have used so far is showing the whole world, but on Google Maps and on Open Streetmap you can download regional maps, with an attached calibration file (.clb). How such calibration files are suuposed to be used, you can see here: http://www.sailwx.info/maps/shipplotter.phtml?width=1200&height=600&lat=63.1&lon=7.5&radius=50&airports=2&cities=0
That page more or less explains itself.

Have not studied the Google Maps API, but since they limit the width of the maps you can download to 1268 pixels, I do not want to use them.
On OpenStreetmap it is possible to download regional maps similar to the maps in the supplied links, but with greater details in the maps. I have not yet studied how to download them. The size restrictions here, is max 4048 x 4048 pixels.

I reckon that if I enlarge a world map so only a small region of the world is shown, it should be an easy task to calculate the border positions for use in downloading a more "tailormade" regional map.
But for this HFDL application I think the way I'm doing it already has all the resolution needed.

It seems like the site I downloaded the map from, no longer exists. But the maps are based on NASA's Blue Marble Eart Maps (http://visibleearth.nasa.gov/view_cat.php?categoryID=1484).

[Egil]

run this

Something along that line was what I was thinking of, but maybe with a color not as dominant as red...

[Egil]

Maybe something like this.... (4x4 pixels with tail 5 pixels long).
And the same size on the full world map.

It planned to draw these "on the run" when updating the plots. Have noticed that this can be done very fast by using ordinary drawing commands and draw wiith transparent background.

[LarryMc]

What about when you position and draw 3000 of them?
Also in your picture example it looks real neat with the line at a 45 degree angle and will look the same at 4 cardinal headings.
But when you start drawing a line at other angles it starts looking ragged

There's no calculation for the line with DeVil once you settle on a symbol; you just give it the angle and it rotates the symbol but the same problem with ragged lines is there.  I see that as an issue to be solved.

Note: I was using red because it shows what the symbol will look like so well.

I tried this one with a tear dropped shaped imaged but it still distorts it at some headings.
But look at the small subroutine that is generating all those.

[LarryMc]

I think you are right Egil; drawing the symbol with the regular command.
But I think a circle will look better than a circle so that the line will be from the center of the circle
Se below(and run attached

[LarryMc]

I guess what I need to do now is figure out how to mix GDI+ graphic commands with the DeVil commands.
GDI+ (which I used in my custom control tutorial has an ANTIALIASING mode for drawing that makes those ragged lines appear smooth to your eyes.

[Egil]

Seeing your example immediately convinced me. Circles are better.
I was planning to use RECT and LINE, but guess CIRCLE and LINETO will work faster as I expect that LINETO then shares the startposition with the CIRCLE center.

For two days now, I have decoded traffic from Shannon - Ireland, collecting all traffic to a logfile. The shortwave radio conditions has been rather poor, due to heavy solar activity resulting in a lot of northern lights.  Now I am going to analyze the logfiles, to figure out what information to look for and retreive.

When I come to think of it, I have all sorts of plans in my head, but maybe it now is time to put these plans in a textfile, just to organize them properly. Guess this will ease the coding as well.

In a few hours I have to go to Trondheim. Going for an examination of my right hip, so the doctors can plan the upcoming surgery, and, to quote my good neighbour (who also is a doctor), " It's just like changing the brakes of a car, they have to order new spareparts before they can change the old ..."


Regards,
Egil

[LarryMc]

The attached symbols are drawn with GDI+.  Now I just have to remember how to make them stay on the screen when you move another screen over them or minimize the sceen then open it back up.  And do that without without messing yp the background image.  This old brain of mine is getting old and tired,

[LarryMc]

okay, the attached displays symbols for planes, ground stations, and base.
the symbols don't go away when the window is covered with something else.

Egil: now you've got a lot of work to do in writing code to read your database of 3 different types of data points
then converting the lat and long coordinates to scaled x/y to match the x/y of your 2 different image sizes so the point plot at the proper relative locations on both maps especially when scrolling.

But the core of the program is there for putting the stuff on the screen.

[Egil]

Thanks Larry!

Things going "slow ahead" only here at the moment. Have problems typing because of the broken arm. But have used the time to set up the decoding software to log everything it decodes, and then looking through these logs every day. Till now I have only used the HFDL position reports, but have discoverred that there are lots of other information in there as well.

They have set me up for a hip replacement april 15th, and hope to get rid of the plaster before that.
But as you mentioned, I have lots of coding to plan and do now.

Thanks again Larry. I really appreciate the work you have done to help me with the graphics. And though the usual easter visitors have arrived (you know, children grandchildren etc), I thinkl I'll get around to study your  code.  


Regards,
Egil.

[LarryMc]

Egil:
To satisfy my curiosity could you send me a sample of one of your data files for me to look at?

If it's not a problem.

[Egil]

Egil:
To satisfy my curiosity could you send me a sample of one of your data files for me to look at?

If it's not a problem.

Done

[Egil]

When testing how to convert positions given in degrees, minutes and seconds into decimal degrees, I discoverred that the scaling factor of the maps, came out faulty.
Redefining the variable sfactor to float did not rectify the problem. Changing the line:

Code Select Expand

sfactor = mapwidth/pw   ' Calculate scale factor
to this,:

Code Select Expand

sfactor = float(mapwidth)/float(pw)    ' Calculate scale factor
made the calculation correct.

Also realized why positioning of the mouse was not quite correct when enlarging the map. After correcting the scaling factor calulation, I had to change the lines:

Code Select Expand

mapleft = -(mx*sfactor) + (mx/2) 
maptop  = -(my*sfactor) + (my/2)

to  this:

Code Select Expand

mapleft = -(mx*sfactor) + mx
maptop  = -(my*sfactor) + my

The result is that the mouse now is positioned "right on" when the map is enlarged.

During the weekend I also made some routines for log file handling, collecting data from different files and put them in a new file for later manipulation by the map program and/or make a written log in a kind of grid.
The routines  was tested using a console mode program, but that turned out to be a real "CPU-hog". Therefore I made gui for the  routines, and compiled as windows program, and then the CPU use was just a small fraction of what it was before.
This was quite an eye opener to me.

I decided to make a somewhat better GUI for it, and compiled it as an independent program. And  since I am part of a group ofm decoding "freaks", where the other do pretty much the same way of decoding as myself, I sent copies to a  couple of them. They were quite happy with the tool, and have already been asked to expand the number of "channels" the program can collect data from.

Regards,
Egil

[LarryMc]

Egil
Just before I started trying to help Andy with his compile time problem I believe I stumbled across the secret to your positioning calculation and it doesn't even require that you use your sfactor variable.

Later today I'll try to prove it works and if it does I'll post the code.

[Egil]

That's great Larry!

I plan to prepare the code it such a way that it can use "calibration" files (ending with .clb). Such files are used by most suppliers of free to download maps.
Here is the content of the clb file describing the Google map below:

Point00,xy,0,0,in,deg,6,5.784068,N,0,0.175912,E
Point01,xy,1280,0,in,deg,6,5.784068,N,14,4.523948,E
Point02,xy,0,950,in,deg,4,20.807448,S,0,0.175912,E
Point03,xy,1280,950,in,deg,4,20.807448,S,14,4.523948,E

Larger maps often use 24 "calibration points" placed in a grid like pattern all over the map.

[LarryMc]

Well, that blows my code out of the water.
my work was based upon the text file that had records like this:

[HFNPDU PERFORMANCE]
11:35:56  UTC  Flight ID = RJA121  LAT 49 4 49  N  LON 17 26 45  E

so I worked with

LAT 49 4 49  N  LON 17 26 45  E

or more precisely

49 4 49  N  17 26 45  E

and passed those values as parameters to a subroutine.
The key to the whole thing is your map.
your map goes from 180W to 180E and from 90N to 90S
so all you have to do is convert the degrees to 0-100% of the image width
for the full map no further adjust is required
for zoomed in you have to adjust for the image offset

I set in 3 fixed points
0 degrees lat and lon
Abilene,Texas where I live
Oslo, Norway
I offset the 5 pixel square box by 3 so the center of the box is centered on the point

If you can explain
Point00,xy,0,0,in,deg,6,5.784068,N,0,0.175912,E
Point01,xy,1280,0,in,deg,6,5.784068,N,14,4.523948,E
Point02,xy,0,950,in,deg,4,20.807448,S,0,0.175912,E
Point03,xy,1280,950,in,deg,4,20.807448,S,14,4.523948,E
or tell me where to find the explaination

to me I'll see if I can make the adjustment

[Egil]

I did not remember the fact that others maybe never have heard of such calibrated maps, sorry about that.

The key is as follows:

Point00,xy,0,0,in,deg,6,5.784068,N,0,0.175912,E     =  Upper left corner of map, and position of that point in degrees and minutes with decimals. ( 6 degrees 5.784068 minutes North, and 0 degrees 0.175912 East )

Point01,xy,1280,0,in,deg,6,5.784068,N,14,4.523948,E = Upper right corner

Point02,xy,0,950,in,deg,4,20.807448,S,0,0.175912,E   =  Lower left corner

Point03,xy,1280,950,in,deg,4,20.807448,S,14,4.523948,E = Lower right  corner

So this describes a map with size 1280x950 pixels, with positions in Google's format.

Other such files do not use N,S,E and W for the directions. They use positive values for North latitudes and East longitudes, and negative values for South latitudes and and West longitudes. And to add to  the confusion these files often  use degrees and decimals of degrees instead. Such as maps from OpenStreetMaps and Mapquest. In all cases we need to obtain a licence key before we are alowed to download any maps with "taylormade" dimensions. Otherwise the largest  dimensions is 1280 x 950 pixels as in the Google example.
I have sent an email to MapQuest (OpenStreetMap) asking if it is possible obtain a free licence key to be included in a freeware program. If they accept such an arrangement, it will be an wasy matter to download maps at will from inside the program.
We can start from a calibrated small size worldmap and enlarge it, and let the present clientarea in the program set the size of the map. Then it also should be an easy matter calculating the position of the map boundaries, and if the map provider do not supply the calibration file, we can make it ourself using the information sent to download the map.

In Texas I only have been along the coast. Corpus Christi, Freeport, Galveston, Texas City, Baytown, Houston and also think that Port Arthur is in Texas. Was several times in each place during the time i did servicing and calibration all kinds of sensors and load computers onboard chemical tankers. One of my best visit over there was when I had to wat four days for a tanker to arrive. I leased a car in Texas City and went visiting a friend working at the Norwegian Seamans Church in Houston, and the day after we went down to Pasadena (??) and was lucky to get a guided tour at the NASA Space Center. I do not remember which year, but must be 30 - 35 years ago....


Regards,
Egil


Edit: forgot to ut in descrition of the positions, just in case....... 

[Egil]

Well, that blows my code out of the water.

Don't panic!

You have calulated the positions using the format the planes are transmitting them, which is very good. That was the part i was going to look at next. But you have solved that in a very nice way!

The other format is just needed when downloading a map from one of the mapservers, and only has to be recalculated into the format you have used once for every new map, as long as we use the calibration files, with filename paired with each jpg.
( World.jpg and World.clb)

Making  such code should be a walk in the park...

Just compiled your last masterpiece, and I like the way you have done it. Exactly what I was thinking of.
But I am unable to scroll the map south of equator.

It is close to midnight here, and I have been up since 0500 this morning, so think I'll better hit the bed, and study your code more thoroughly tomorrow.


Regards,
Egil.

[Egil]

Forgot to say that it's best to stick to the present map until a licence key is obtained from one oof the mapservers. If that key is not free, I think I drop it, and use the present map.
For the dealing with airplane positions this is more thas sufficient.
I was planning to use the same code for ship positions (AIS decoding), but for that application the calibrated maps supplied by SailWx. Here is an example:
http://www.sailwx.info/maps/shipplotter.phtml?width=700&height=350&lat=63.13&lon=7.65&radius=30&airports=0&cities=0
The shown map is based on the area around me.

[LarryMc]

Two things:
Pt. Arthur is in Texas and is 17 miles from Beaumont Texas where I grew up in the swamps of Texas.

You couldn't move south of the equator because I improperly corrected your find edge calculation.
In your original calc you were using the width to limit the height.
It is now fixed correctly in the attached.

BTW, I have a scheme in mind of how to handle updates from planes to make them move across the map as you receive updates.
I'll see if I can dummy up an example for you in the next few days or so.