RADAR
Contents
RADAR scheme in Flysafe database
Data model for Motion Analyses images collected with ROBIN-system
Originally Hans van Gasteren, May 2007
Introduction
Radar data are one of the most important measurements in Bird Avoidance System (BAS) and Fly Safe project. Until now data are archived in structured files instead of in a database. In this document data model for Motion Analysis images of the ROBIN4 system is designed, based on file structure of ROBIN4-MA images as defined in High Level Design Document of ROBIN4 (HLDD, TNO 2006). MA (Motion Analysis) images are summated images of ten radar antenna rotations and are recorded twice per hour, two radar beams per radar, 3 radars in total (equalling 12 images per hour). The data comprise all recorded radar echoes with summated intensities, plus rain clutter masks, land clutter masks and all separate objects of all recognised tracks. The huge amount of data per image (360°, 150km range, 10Mb) require a flexible database. Numbers of tracks can be as high as 15.000 tracks per image, with a mean about 1000 tracks. Per day we collect 48 images * 2 beams * 10Mb * 3 radars equipped with Robin 3Gb data. Because the database must be readily and speedily accessible, only aggregated data can be recorded in the database. Original data will have to be recorded in a file system. The level of aggregation is still under debate, as the database should also allow a certain level of reanalysis. It is not desirable to store all original recorded echoes and raw radar data, which are the bulk of the data, in the database. Because the number of tracks is rather low ( 1000) for most of the images, it may be sufficient to store summaries of each track. This will lead to an estimated data reduction of 90%. In the near future, already during precursor phase of FlySafe project, bird echo tracks will be recorded continuously. This means that if we want to store individual tracks, also positions of each antenna rotation is stored and database could be increasing much faster than it does now.
Data model for MA images collected by ROBIN4 system .
RADAR
The radar table contains details for the different radars.
| RADAR_ID | unique radar id |
| RADAR_NAME | logical name |
| LATITUDE | degrees |
| LONGITUDE | degrees |
| X_POSITION | in meters, rijksdriehoekmeting |
| Y_POSITION | in meters, rijksdriehoekmeting |
| Z_POSITION | In meters, rijksdriehoekmeting |
| ALTITUDE_ANTENNA | In meters with respect to sea level |
| Radar type: | |
| MIN_RANGE | In meters |
| MAX_RANGE | In meters |
| RANGE_RESOLUTION | In meters, normal MPR 30m |
| AZIMUTH_RESOLUTION | In radials azimuth if horizontal radar else elevation |
| REVOLUTION_TIME | In seconds, normal MPR 10s |
| Transmitter: | |
| MEAN_CARRIER_FREQUENCY | In GigaHz |
| PEAK_POWER | In dB |
| PULSE_LENGTH | In μS |
| PULSE_REPETITION_FREQUENCY | In Hz |
| Antenna: | |
| TYPE | circ, rectangular, omni |
| VERTICAL_ILLUMINATION | uniform, parabolic, parabolic², cosec² |
| POLARISATION | (horizontal, vertical, circular) |
| TRANSMITTER_GAIN | In dB |
COVERAGE_DIAGRAM
(for each azimuth horizontal elevation is given).
| COVDIAG_ID | Reference to RADAR_ID of table RADAR |
| AZIMUTH | Radians (0-2PI) |
| ELEVATION | Radians |
BEAM
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | |
| BEAM_NAME | |
| BEAM_ELEVATION | Elevation of beam (radians) |
| EL_BEAMWIDTH | Beam width (radians) in elevation |
| AZ_BEAMWIDTH | Beam width (radians) in azimuth |
IMAGE_REQUEST
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | Reference to BEAM_ID of table BEAM |
| IMAGE_REQUEST_ID | |
| WINDOW_MIN_RANGE | Measurement range (m) of window |
| WINDOW_MAX_RANGE | meters |
| WINDOW_MIN_AZIMUTH | radials |
| WINDOW_MAX_AZIMUTH | radials |
| Motion_analysis_parameters | Note: for CMA different |
| RAIN_CLUTTER_MODE | Automatic, off, on |
| LAND_CLUTTER_MODE | Automatic, off, on |
| DETECTION_METHOD | Peak detection, threshold |
| MIN_TRACK_MEMBERS | 2 ..10 |
| ALLOWED_INTERVAL | 0..9 |
| MIN_MEMBER_SIZE | 1..? |
| MIN_SPEED | 5..50 |
| MAX_SPEED | 5..50 |
| ALLOWED_SPEED_DEFLECTION | 5..50 |
| TANGENTIA_SPEED_DEVIATION | … part of score function |
| RADIAL_SPEED_DEVIATION | … part of score function |
| MASS_DEVIATION | … part of score function |
| BONUS_SCORE_PROBABILITY | … part of score function |
| PATH_FRACTION_THRESHOLD | … part of score function |
| RELAXATION_FACTOR | 0.0..1.0 … part of score function |
| RANGE_RESOLUTION | Correction with respect to default range resolution |
| AZIMUTH_RESOLUTION | Correction with respect to default azimuth resolution |
SUBWINDOW
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | Reference to BEAM_ID of table BEAM |
| IMAGE_REQUEST_ID | Reference to IMAGE_REQUEST_ID of table IMAGE_REQUEST |
| SUBWINDOW_ID | |
| SUBWINDOW_MIN_RANGE | meters |
| SUBWINDOW_MAX_RANGE | meters |
| SUBWINDOW_MIN_AZIMUTH | radials |
| SUBWINDOW_MAX_AZIMUTH | radials |
IMAGE_RESULT
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | Reference to BEAM_ID of table BEAM |
| IMAGE_REQUEST_ID | Reference to IMAGE_REQUEST_ID of table IMAGE_REQUEST |
| IMAGE_RESULT_ID | |
| ACQUISITION_TIME | Date and time of request |
| ERROR_STATUS | Status given back by Robin-system |
| CORRECTION_LEVEL | False alarm rate, FAR correction factor, important value, should have own graphical representation through out the year and correlate with the weather conditions |
| NR_OF_TRACKS | Number of tracks in image |
| RAIN_MASK | Rain clutter mask. Area were bird detection is switched off |
| LAND_MASK | Land clutter mask. No bird detection has been achieved in this area |
| IMAGE | Jpeg image of data (high resolution ) or georef TIFF |
SUBWINDOW_RESULT
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | Reference to BEAM_ID of table BEAM |
| IMAGE_REQUEST_ID | Reference to IMAGE_REQUEST_ID of table IMAGE_REQUEST |
| IMAGE_RESULT_ID | Reference to IMAGE_RESULT_ID of table IMAGE_RESULT |
| SUBWINDOW_ID | Reference to SUBWINDOW_ID of table SUBWINDOW |
| AREA | km² |
| LAND_CL_PERC | % land clutter in image |
| RAIN_CL_PERC | % rain clutter in image |
| CLUTTER_PERC | % land or rain clutter in image |
| TOTAL_MASS_DENSITY | Total mass density per km², before MA |
| LAND_MASS_DENSITY | Mass density per km², after MA in land clutter mask |
| RAIN_MASS_DENSITY | Mass density per km², after MA in rain clutter mask |
| CLUTTER_MASS_DENSITY | Mass density per km², after MA in rain or land clutter mask |
| BIRD_MASS_DENSITY | Mass density per km² of bird tracks |
| BIRD_ECHO_DENSITY | Mean bird echo density per km² |
| BIRD_MEAN_DIRECTION | Mean direction of all bird tracks in sub-window radians |
| BIRD_MEAN_SPEED | Mean speed of all bird tracks in sub-window m/s |
| Other params wrt quality assessment | For each sub-window, filled in during second pass or as software module (which can be modified) each time data is retrieved. |
TRACK_RESULT
The TRACK_RESULT table contains tracks of birds that have been detected by the ROBIN4 system. It also contains as arrays all the different points in a track data. That data used to be in the TRACK_OBJECT table. The TRACK_RESULT table is a master table and the real data is contained in the inherited tables TRACK_RESULT<YEAR><MONTH>. Otherwise the TRACK_RESULT table would become too big.
| RADAR_ID | Reference to RADAR_ID of table RADAR |
| BEAM_ID | Reference to BEAM_ID of table BEAM |
| IMAGE_REQUEST_ID | Reference to IMAGE_REQUEST_ID of table IMAGE_REQUEST |
| IMAGE_RESULT_ID | Reference to IMAGE_RESULT_ID of table IMAGE_RESULT |
| TRACK_RESULT_ID | |
| DATE_TIME | Starttime (date + time) of track (for MA equal to ACQUISITION TIME, for CMA different) |
| TRACK_RANGE | Start position of track (m) |
| TRACK_AZIMUTH | Start position of track (radians) |
| TRACK_MASS | Mean mass of bird track |
| TRACK_SPEED | Mean speed of bird track (m/s) |
| TRACK_DIRECTION | Mean direction of bird track (radians) |
| TRACK_OBJECTS | Number of objects in track (0 – 10) |
| TRACK_SOURCE | MA / CAM |
| OBJECT_LATITUDE | Array of latitude position of object |
| OBJECT_LONGITUDE | Array of longitude position of object |
| OBJECT_MASS | Array of mass (reflection) of object |
| OBJECT_SIZE | Array of size of object |
| OBJECT_RHO | Array of rho coordinate of object |
| OBJECT_PHI | Array of phi coordinate of object |
Quality parameters
Deze gelden voor elk subwindow opnieuw. Dat betekent inderdaad meerdere keren per beeld.
- Correction level wrt FAR. Dynamische range bepalen van een subwindow en vervolgens een kengetal tussen 0-100 of 0-1 uitrekenen met betrekking tot kwaliteit. Deze waarde geldt voor een heel beeld en niet voor elk subwindow
- Percentage landclutter in subwindow. Ook dit hoort constant te zijn, wanneer dit buiten marges valt zal dit de kwaliteit omlaag brengen. Via analyse bepalen wat relatie is met 100%.
- Te veel vogels. Dit valt af te leiden uit de samenvattende gegevens, volgens:
- LAND_MASS_DENSITY is ongeveer normaal, dan moet ook
- TOTAL_MASS_DENSITY - LAND_MASS_DENSITY ongeveer gelijk zijn aan BIRD_MASS_DENSITY. Is dit niet het geval (buiten marges), dan te veel vogels en kan nieuwe dichtheid en massa alsvolgt worden berekend:
- BIRD_MASS_DENSITY = TOTAL_MASS_DENSITY - LAND_MASS_DENSITY
- BIRD_ECHO_DENSITY kun je op twee manieren uitrekenen. Wanneer deze waarde 0 is moet dat via een van te voren bepaalde regressielijn, anders kun je dit uit de data zelf berekenen volgens TOTAL_MASS_DENSITY - LAND_MASS_DENSITY * (BIRD_ECHO_DENSITY / BIRD_MASS_DENSITY).
- Uiteraard moet de dichtheid en massa met een lagere kwaliteit in de database worden gemerkt.
- Dikke vogelecho’s worden als regen gezien. Dit valt af te leiden uit het regenfilter: (1) veel losse stukjes beeld en (2) oppervlak van deze stukjes is klein. Daarnaast moet de gemiddelde massa per echo ook groot zijn: BIRD_MASS_DENSITY/ BIRD_ECHO_DENSITY >> (Wier >700). In dat geval bereken je de nieuwe massa en vogeldichtheid volgens 3.2.1, respectievelijk 3.2.2 (versie 2). Nieuwe getallen moeten met een lagere kwaliteit worden gemerkt.
- Foute tracks aan de rand van regenbuien. Het gemiddeld aantal objecten in de tracks zal laag zijn.
- Aantal tracks wat bij laatste iteratieslag hoort in relatie tot totaal.
De vraag is of we deze berekeningen ook opslaan in de database, of dat de regels als software module bij het ophalen van de data worden meegegeven? En dan tot slot een correctie op detectie in afstand en zijaanzicht en de daarmee veranderende hoogte. Dit kan echter als een aparte software module in het hoogtemodel worden opgenomen en hoeft de punten 1 t/m 6 niet in de weg te staan.
