Dear colleagues,<br><br>[Executive summary: A standard format for 
recording light-at-night data has been developed, and you are being 
asked to endorse the format and make comments if you notice something 
that needs improvement.]<br>


<br>The introduction of the SQM and the IYA Lightmeter have led to a 
large number of permanent skyglow monitoring stations coming 
online. At the same time, a number of individuals and groups have 
developed their own non-commercial devices (e.g. NSBM from the IDA, and 
DigiLum from Henk Spoelstra).  While these developments are excellent 
news for those interested in monitoring light pollution, there exists no
 common standard for recording measurements from the devices.  This has 
greatly hampered efforts to compare measurements from different 
locations, and to develop databases containing long term measurements 
from around the world.<br><br>At the recent Cabauw Lightmeter InterComparison (CLIC) workshop, a
 group of light pollution researchers defined a proposal for a new, 
standard format to be used for recording skyglow measurements 
(attached).  The goal of the standardization is to make comparisons of 
future measurements easier, regardless of whether the measurements were 
taken by currently available detectors, or by new, future detectors.  
For this reason, we have attempted to define a format that anticipates 
the needs of potential future devices (e.g. multiple channels with 
different filters or opening angles), but without making the format so 
open as to not actually be helpful.<br>


<br>In addition to the attached definition of the format, two example 
data files written in the new format (for the SQM and Lightmeter) are 
included.  The rational for various decisions is included at the bottom 
of this email.<br>


<br>The participants at the CLIC workshop reached a consensus on this 
data format after an extremely long discussion.  It does not match the 
format currently used by any of the workshop participants, and is not 
the way any of us would choose to do things if left to our own devices. 
 Regardless of this, we were all in agreement that the benefits of an 
agreed upon common light pollution data format vastly outweigh the one 
time inconvenience of developing a converter to transfer such data into 
our favorite format for data analysis.  (The one place we could not 
reach consensus was on the nature of the data delimiter.  If you care 
about this, please indicate your preference when you endorse the 
format.  If one delimiter is chosen by over 50% of endorsers it will be 
used, otherwise an online poll will be held to make the final decision.  The 
most popular delimiters at the CLIC workshop were space and semicolon.)<br>


<br>We now invite you, as a member of the light pollution research 
community, to comment on the proposed format, and hopefully to endorse 
it.  We ask that you respond with your comments by May 29 (if you need 
more time than that please let us know as soon as possible).  After that
 date, the format will be finalized, and we will issue a final call for 
endorsements.  We will then officially announce the new format in a letter to an 
astronomy journal, including in the appendix a list of those who endorsed it.  We will also provide Unihedron with a new perl script that writes out data in this format.  The makers of the popular SQM Reader programs have also indicated that they will provide an updated version at some point after the format is finalized.<br>



<br>To endorse the proposed standard light at night data format, please send an email to Dorien Lolkema &lt;<a href="mailto:dorien.lolkema@rivm.nl" target="_blank">dorien.lolkema@rivm.nl</a>&gt;, including your name and institution (if applicable).<br>



<br>If you have comments or suggestions regarding the format, you can either let us know by email privately, or post a public comment on one of the <a href="mailto:sqm@unihedron.com" target="_blank">sqm@unihedron.com</a> or <a href="mailto:LPResearch@yahoogroups.com" target="_blank">LPResearch@yahoogroups.com</a> lists.<br>



<br>Best regards,<br><br>Christopher Kyba and Dorien Lolkema<br><br><br><br><br>General principles guiding the design of the format<br>====================================<br>


<br>Anyone is free to write out two data files (e.g. in old and new 
format) if they so choose.  It should therefore be a simple matter to adopt this format 
without disrupting any current analysis program.<br><br>This is 
is a &quot;level0&quot; data format.  This means reporting of the raw values that came 
from the device, and not calibrated values.  The level0 data file should
 never be changed after it is written.  (This means that you should not 
subtract off the 0.11 mag/arcsec^2 from an SQM when writing the file, 
you should write out what the SQM actually reported.)<br><br>New files should be opened once per 24 hour period.  The decision of
 what local or UTC time to open a new file is left up to the users, 
because some devices also record data in the daytime.<br><br>The header 
should only appear once in each data file.  If the acquisition program 
is restarted for some reason a new file should be opened.<br>


<br>The data must include both a universal and a local time.  Local time 
is useful because there are occasionally events that occur repeatedly at
 a particular local time (e.g. stadium lights going off), and because it
 makes it easier for the user to examine the raw data.<br>


<br>UTC time was chosen over other options (e.g. JD, unix time) due to 
its improved human readability and ease in handling leap seconds.<br><br>The
 data format is for stationary monitors only.  An almost equivalent 
format will be announced for GLOBE at Night data (or for future devices 
in which the output of the device contains a location).  If you take 
moving data with an SQM, your acquisition program should still write out
 the SQM data in this format, since it&#39;s the raw SQM data.<br>


<br>There should never be &quot;blank&quot; entries.  If a value is not applicable
 for your device, then -9999 should be written.  If the device does not 
report a value, or if the value is corrupted, then -9998 should be 
written.<br>


<br>Users are free to decide whether or not to release their data under the ODbL (or other license).  We encourage everyone to use ODbL, but understand
 that some researchers may have a need to embargo their initial data 
before joining a present or future global network.<br>