What is desired forPublic Online Meteor Database

- Expected usage model

- What are necessary for us

- What embarrass us

- Social issue agreements

- Technical problems and suggestions

- Necessary application interface

- UFO series for VMO

Expected Usage Model

What we will do first

We would like to focus on the observation DB, and make it replace our CSV hub.

This part has comparatively fewer problems, can be established now.

What are necessary for us

Essentials

- Application interface

upload/update/delete/download of observations

- Social issue agreement

copyright/privacy/registration

- Data scheme that enables above

Seems not so difficult …..

What embarrass us, nowVMO data definitions seems having a lot of problems for real use, yet.

ex.1 cam_session_code does not exist on XML

It should be most important access key to DB. It should be able to decide objectively.

How can I update the observations? Unless this, even adding a link seems very difficult.

ex2. meteor_code

CAM_YYYYMMDD-N_SYSTEM_Mnnn

this force difficult handling when the last night observations begun in a same UTC day.

ex3. why orbit contains only height but not long/lat ?

Can we download orbits that happened near Japan?

…. Refer problem list for other points. They are many.

VMO registration seems not open to non-IMO members.

VMO seems violating the Japanese privacy law.

…… It is necessary to clear off all points !

Social issue agreements- Observers must not assert copyrights or other rights about numerical data.- Copyright of visual media in DB is basically held by the observer. VMO does

not concern it. It should be treated by the law of each observer’s country. - Users must provide true name or traceable Email address that will be

published by DB. Other private information is optional.

All registered information will be published.- Users must provide precise information of systems and the location of the

stations in required accuracy. - Users can use encrypted format for precise longitude and latitude of the

station. In this case, 0.01 degree rounded readable value should be added.

(ex. 139.66 [cniweISPjl24] ).

Decryption procedure will be distributed under special agreement. 1) Authorized people must keep the procedure in secret.

2) Program must not show or output precise location in human readable format.

- Registration of DB does not mean participation to any organization.

VMO prepares own code registration page (observer, system…)

Encryption Purpose : Just hide precise value from public eyes.

Sample : Simple secret key encryption, using bit exchange and EOR.

Technical problems and suggestions(comment for WGN38-1 Geert et al. , : essential points)

<vmo>

1. <vmo> seems containing two kinds of elements. One is code definitions and the other is data. Code definitions are useful to avoid duplications and fluctuations of description (like wat100N -- Watec Neptune 100). Currently only a part was defined. Code definition elements will be blow

<observer>, <location>, <cam_system>, <software_code>, <shower_cat_code>, <camera_code>, <prism_code>, <lens_code>, <intensifier_code>, <relay_lens_code>, <digitizer_code>, <video_format_code>, <time_keeper_code>

Where, <orbit_pipeline> is strange. Why combination only for orbits? Are those fixed combination now? So, software_code for each step in <orbit_set> may be proper.

It will be convenient enough to do code definition manually on VMO site. And almost all of them have no important information for computation. So online applications can be independent from these structures. It will make development of applications much easier.

2. Data part of <vmo> (online applications transaction units, <cam_session> and <orbit_set> ) should include all necessary data for computation in itself. This can be done only adding lon/lat/h to <cam_session>.

<observer>

3. In case of traceable Email address is provided, the name field should allow nickname or abbreviation

<location>

4. Encrypted lon/lat with round value should be allowed.

5. Geoidal height should be allowed. ( ex. G+23.4 )

<cam_system> : no comments

<cam_session>

6. cam_session_code like must exist. This should be client side decidable value. It should include session begin time ( hour and minute ). CAM_YYYYMMDD_hhmm_system ( “ –N “ suffix requires the management of last night observation )

7. longitude, latitude, height, e_location is needed here for data compactness.

8. capture_software_code, measure_software_code should be here

9. video_fomat_code (PAL/NTSC/DVSD/MPEG4/….) should be here.

10. gain seems ambiguous, should be divided cam_gain, auto iris, white_balance ….. ???

11. storage …. Compression should be treated independently

12. interlaced_order …. EVEN/ODD is ambiguous. Bottom field first?

13. exposure_time ….. How to express for NTSC ? 0.016688333 ?

14. effective_y …. Should be total y pixel even on interlaced video.

15. time_keeper_code, time_correction_interval should be here

16. e_time …. Should be e_time_abs

<period> : no comments

<meteor>

17. meteor_code should be CAM-YYYYMMDD-hhmm-SYSTEM-M9999

18. time … should be equal to the first pos time,

like 2010-01-03T11:59:59.12345

19. duration … = end pos time – begin pos time, right?

20. speed …. Average ?

21. e_*_ra, e_*_dec should be one as e_*_ra_dec

22. pole_ra, pole_dec, e_pole_ra_dec should be added

23. Elements below may be worth to add (UA: ?)

number_of_ref_stars, lm, e_astronomy, e_linearity, local_clip_name

<pos>

24. Time should be 5 digits below second for NTSC

25. pos_x, pos_y is raw value, does not have meaning without plate constants. How about pos_ra_raw, pos_dec_raw, e_pos_ra_dec instead.

26. saturation_flag -> staturated_pixels

27. light_sum ?

28. e_time …. e_time_abs?

29. e_pos_ra, e_pos_dec -> e_pos_ra_dec

30. e_pos_line (linearity error) will be useful

---- orbit section is not considered so deeply ------

<orbit_set>

This is good way to store multiple result of one actual meteor. But how to name the daily updated set? There will be thousands of set. So the keys to select sets will be important

<orbit> -orbit_code : why not exist? How to identify an orbit?-time : at 100km height seems not good idea. How to deal with that has no 100km point or having two 100km point ( like earth grazing meteor). -begin_lon, begin_lat, end_lon, end_lat is needed to search meteors on some region.-total_trajectory_length (km), total_duration will be useful.-entry_angle will be useful-solar_longitude will be very useful-z_avg : ???? Angle distance of observed radiant and modified radiant ? -state : at begin point? -e_e : AU?? -Some other quality measures such as Qd or Qr should be added.-Radiant error should be expressed by e_ellipse_azimus, e_ellipse_a, e_ellipse_b ??.

Necessary application layer interface

Login - observer_code, password, program_code and One Time Password

Upload observations - cam_session with cam_session_code

Update / Delete observations - cam_session with cam_session_code, More partial update ? ( - deleted mark for detection of partial download ? )

Download observations - Minimum query condition region, time span, ( first modified time for download the new ones only?). - Packaging? - Data size or date range limit? - What will be downloaded? cam_sessions with locations or over all CSV?

Note: We should allow free downloads, but should not allow free SQL queries to public! It is awfully dangerous. SQL has been causing many problems.

UFOSeries for VMOIf all problems are cleared, the products below may appear

UFOCaptueV2.5 : VMO code assignable

UFOAnalyzerV2.5 : upload observations to VMO

UFOAnalyzerV4 : accuracy computation

UFOOrbitV2.5 : download observations from VMO

UFOOrbitV3 : upload orbit to VMO

UFOOrbitV4 : accuracy computation, using SPICE

FireBallInspectorV4

UFORadiantV4