On Mar 19th, 2024, we have deployed a newly developed service for the incoming LVK GW event alerts, providing sky maps and object lists of existing transients on the TNS that fall within event localizations.
Downloadable sky maps and lists are produced separately for transients that have been discovered BEFORE the exact GW alert time, and are thus not potential counterparts, and those that are streaming into the TNS with reported discovery dates after the GW event, thus potentially relevant.
The Rate-Limit handling does not effect the Bulk reports - there is no limitation on the rate at which discovery or classification reports are being reported to the system.
It will introduce limitations on the other calls (such as the Search/Get APIs, downloading of data, site usage) performed by users, bots and general scripted requests if surpassing the rate-limit per given minute - a running time-window.
Please refer to the revised API sample codes available for download from the Help Page, e.g. the Search/Get API Python code, for examples on possible ways to implement the Rate-Limit handling.
Do let us know if any questions arise, and a kind reminder to verify that your scripted TNS calls are managed efficiently, according to your scientific needs and without causing unnecessary load on the system.
*** Note that the new Requests Rate-Limit mechanism described below will be in effect on the real site from 2021-08-22!
1. General activity against the TNS
Over the last several months a lot of effort was put into adding security layers and mechanisms for reducing the load on the TNS.
Whereas we did manage to significantly reduce the activity of external (unwanted) bots, we noticed that there is significant load caused by "valid" requests of TNS users and bots who are hitting the TNS without enough caution and efficiency.
We contacted several Bot/Group managers in person in order to clarify the needs and propose improved use of the APIs and the offered tools (download of data etc...).
We found these correspondences to be very useful, and we encourage the Bot/Group managers to contact us and discuss with us their use cases, so that we can improve the processes for the benefit of both sides - the scientific needs and the load on the TNS servers/DB.
2. A new Requests Rate-Limit mechanism - Will be in effect from 2021-08-22.
As part of improving the control over the activity against the TNS, we've implemented a Rate-Limit ("quota") mechanism that will control the amount of requests that are allowed within a duration of X sec (a running window; currently of 60 sec), according to the type of action and the source (whether a logged-in user, anonymous user or a Bot).
The submission of bulk reports (discovery/classification) and the retrieval of the replies are excluded from the Rate-Limit mechanism; we clearly do not want to delay any submission of reports.
The main principles behind the decision on how many requests should be allowed per duration window are as follows:
Cone searches create heavier load, therefore a smaller number is allowed. (For a given specific source - User/Bot - there is a definition of the total allowed requests (per 60 sec), out of which a smaller number is allowed for performing a cone search.)
Bots receive a higher Rate-limit.
Anonymous users (not logged in) receive a small allowed Rate-limit.
Exceeding the Rate-limit will result in a "429 - Too Many Requests" error code.
The Rate-limit status per given set of requests can be tracked by the following "x-rate-limt" HTTP header keywords:
x-rate-limit-limit - Max no. of requests allowed in the time window
x-rate-limit-remaining - Remaining no. of requests available in the time window
x-rate-limit-reset - Time remaining to the end of the time window
Similarly, for the cone searches - a smaller allowed Rate-limit within the Total allowed Rate-limit (when response.headers.get('x-cone-rate-limit-limit') != None):
x-cone-rate-limit-limit - Max allowed cone-search requests
x-cone-rate-limit-reset - Time remaining to the end of the time window
Note that if there is a combination of cone search and other requests (from the same source during overlapping time windows), the total no. of allowed requests includes the cone searches. So each cone search request increments the counters of both the cone and the total limits.
So, e.g., for a python API call of the general form:
(where the headers contain a valid User-Agent tns_marker string)
It is possible to check the response status code and the Rate-limit status with: response.status_code and response.headers.get('x-rate-limit-limit').
So, printing of the end of a calling sequence may look like e.g.:
where the shown Limit value is obtained by: response.headers.get('x-rate-limit-limit');
the Remaining by: response.headers.get('x-rate-limit-remaining') and
the Reset by: response.headers.get('x-rate-limit-reset')
In the above example, when the limit was exceeded and status_code=429, the response.text JSON would show, e.g.:
{"id_code":429,"id_message":{"429":"Too Many Requests"},"data":{"total":{"limit":30,"reset":42,"remaining":"Exceeded"}}}
In such a case, if having more requests to submit, the script should wait till the end of the duration window (the x-rate-limit-reset value = 42 sec in the above example) before resuming to submit requests.
---
In the case of cone-search requests, the end of a calling sequence may look like e.g. (note the different Reset values for the Total & Cone):
response.text: {"id_code":429,"id_message":{"429":"Too Many Requests"},"data":{"total":{"limit":30,"reset":55,"remaining":19},"cone":{"limit":10,"reset":55,"remaining":"Exceeded"}}}
---
*** So, Best Practice: Check the x-rate-limit-remaining (or x-cone-rate-limit-remaining) header after each call, and when one of those reaches 0 (zero; even BEFORE receiving a 429 code), wait for x-rate-limit-reset (or x-cone-rate-limit-reset) sec before continuing to submit requests.
The Rate-limit mechanism is already active on the sandbox, and will be deployed on production on Sun, Aug 22nd, 2021.
Please make sure that your scripts (those that make use of the Search/Get APIs and/or downloading csv/tsv's using the Search page) are in place and are able to relate to the Rate-limit constraints.
In the coming days, the php & python sample codes, available for download from the Help Page, will include the general handling of the Rate-limit.
3. API replies - The HTTP response codes
For better performance and handling, the HTTP "true" response code will now be set in the HTTP header's "Status Code" and not only in the reply JSON.
To clarify the change: whereas beforehand an HTTP response code of 200 was set also in case of an error code in the JSON reply body (e.g. a 400-Bad Request), now the HTTP response code will also have a value of 400.
*** Best Practice: In order to make sure that your code complies with both the original and the new versions, simply make sure to parse the JSON in the reply's body (first line) regardless of the Status Code in the header. If the reply body is NOT a JSON, such as in the case of a 403-Forbidden error (that may originate from an external component), relate to the header's Status Code.
We'll be happy to answer any questions that may arise.
We've recently added a python sample code which you can use (or implement the relevant parts in your own scripts) for automatically downloading as CSV/TSV the resulting entries of a Search page query.
As mentioned at the bottom of the Quick query links on the Help page, a few example searches exist at the bottom of the script, and there's also a MERGE_TO_SINGLE_FILE flag for specifying whether you want to merge the retrieved entries into a single final CSV/TSV file or if to leave the downloaded files as they are.
Please feel free to use this script, and do let us know if any specific questions arise.
Build your scripted queries with caution, preferably against the sandbox first, so as not to create an unnecessary overload on the TNS servers/DB.
As part of the efforts to control the traffic and the external bots that communicate with the TNS,
we ask that you provide a specific User-Agent string to all request headers that are being submitted to the TNS.
This includes both the calls within your API scripts and any curl/wget commands you might be using to access the TNS.
The User-Agent string you should provide is a small json of the following format, with either a bot or user details:
The specific user or bot details you should specify are already available for copying/pasting on your My Account page or the Bots' edit pages (section "User-Agent Specification").
It is certainly possible and also encouraged to include your Browser's UA string, on top of the tns_marker json string.
The revised sample codes, both python and php, will be available on the help page, as well as the example curl commands for using the APIs or downloading csv's.
Please note that from May 23 30 (deadline extended by 1 week) onwards, the scripted requests to the TNS may return an https error if failing to provide a User-Agent string.
Feel free to contact us if you have any questions on this issue.
We are glad to announce a new feature we have deployed, to enable easier and quicker mass download of information about TNS public objects.
Staging the CSV files will fulfil requests by TNS users, as well as encourage performing time-consuming operations locally by users, reducing the load on the TNS servers.
For example, if you need to cross-match entire catalogs or long object lists, we request that this would be done locally, against the csv (or a locally managed DB), rather than by executing multiple cone-searches via the Search API.
Calling the APIs for a limited number of objects is clearly fine, but we ask that our users apply appropriate caution and sensibility when using the TNS resources, that serve a broad community.
1. tns_public_objects.csv.zip - holds the entire catalog of TNS public objects (AT/SN/FRB/... ~70,000 currently). This file is overwritten daily.
The date and time when the list of objects was created is specified in the first line; e.g. "2021-03-15 00:00:00"
2. tns_public_objects_YYYYMMDD.csv.zip - holds only those entries (objects) that were either added or modified during the specified day.
So, e.g. during Mar 15, 2021 it is possible to download this latest CSV for the previous day: tns_public_objects_20210314.csv.zip
The first line in the CSV will contain the exact duration covering the entries in the file; e.g. for the above example: "2021-03-14 00:00:00 - 23:59:59"
The separate daily files remain in place for 1 month backwards.
As the use of the AstroNotes is growing, we've added a new AstroNotes Stats page, displaying the released AstroNotes timeline and break down of the reporting groups when hovering on the data points.
You may find this useful, similar to the Discovery and Classification Reports Timeline as shown on the general TNS statistics page.
Note that besides specification of a date range and Daily/Monthly/Yearly visualization, it is possible to filter by the type of AstroNote - whether Object-discovery/classification, Object-data analysis, Announcement-Tool/Utility etc...
Feedbacks and comments are as always most welcome.
We're glad to update that the TNS has been migrated to the AWS cloud platform today, Sun Dec 27, 2020.
Having the TNS deployed in this environment will improve the high-availability and scalability of the system, across multiple servers and availability zones, as preparation for future increased activity.
Redirects will be in place during the coming several weeks, but do make sure to update by the end of January 2021 the TNS URLs in your links and scripts as follows:
As part of implementing some improvements to the Search & Get (object details) APIs, the following changes were deployed on the Sandbox environment, and they are due to be deployed on the real site on Mon, Aug 17.
*** The changes involve deletion of a few keywords, listed below, so please make sure to arrange your scripts so that they will not fail. ***
The following 5 keywords were removed from the reply JSON of the Get API:
name ("objname" remains in place instead, displaying the object name)
isTNS_AT (not needed; an indication if the object was reported to the TNS or if it is a "historical" one, ingested to the TNS.)
sourceid -> changed to "source", displaying if the discovery report was sent by a "bot" or a "user"
discovererid -> changed to "reporterid" - displaying the id of the bot or user who submitted the discovery report.
internal_name -> changed to "discoverer_internal_name". ("internal_names" (in plural) remains as is, showing all the internal_names reported for the object).
An "objid" (the unique id of the object on the TNS) entry was added to the reply JSONs of both the Search & Get APIs; and also as a query parameter in the input JSONs of both APIs.
The order of the resulting keywords was also arranged; not affecting the scripts, but so that it would be more convinient also for humans to review the retrieved entries/properties.
The reply JSON for the Get API now looks like this (e.g. for 2020qdo):
"reply": {
"objname": "2020qdo",
"name_prefix": "SN",
"objid": 64211,
"object_type": {
"name": "SN Ia",
"id": 3
},
"redshift": 0.011,
"ra": "02:09:12.776",
"dec": "+18:55:55.35",
"radeg": 32.3032316667,
"decdeg": 18.9320416667,
"hostname": null,
"host_redshift": null,
"internal_names": "ATLAS20ugw",
"discoverer_internal_name": "ATLAS20ugw",
"discoverydate": "2020-07-23 13:35:02.400",
"discoverer": "J. Tonry, L. Denneau, A. Heinze, H. Weiland, H. Flewelling (IfA, University of Hawaii), B. Stalder (LSST), A. Rest (STScI), C. Stubbs (Harvard University), K. W. Smith, S. J. Smartt, D. R. Young, S. Srivastav, O. McBrien, D. O'Neill, P. Clark, M. Fulton, J. Gillanders, M. Dobson (Queen's University Belfast), T.-W. Chen (MPE), D. E. Wright (University of Minnesota), J. Anderson (ESO), A. Townsend (University of Manchester)",
"reporter": "ATLAS_Bot1",
"reporterid": 35595,
"source": "bot",
"discoverymag": 19.038,
"discmagfilter": {
"id": 72,
"name": "orange",
"family": "ATLAS"
},
"reporting_group": {
"groupid": 18,
"group_name": "ATLAS"
},
"discovery_data_source": {
"groupid": 18,
"group_name": "ATLAS"
},
"public": 1,
"end_prop_period": null
}
}
followed by the photometry/spectra data if requested...
As mentioned, the new API JSONs will come into effect on the real site on Aug 17; it is possible to experiment with the new format against the Sandbox, also here on the API TEST FORM.
Following requests from the community, we now index (create official ADS bibcode for) all classification reports submitted to the TNS, not only for the "formal classifier" (the first classification made public).
This is useful especially for those cases where the first classification is later realized to be incorrect/uncertain, or either there is a true dilemma about the nature of an event, and it is necessary to be able to officially cite other reported classifications.
The bibcode for all classifications of an object is now shown in the last column (ADS Bibcode) of the Classification Reports sub-table on the Search/Object pages, linking to the ADS.
(For the formal classification report, the ADS bibcode also appears on the "Classification Certificate", as before.)
We've also created and updated on the ADS the indexes for all relevant past classification reports, from 2016 until now. All backlog ADS indexes can be reviewed here.
Do let us know if you encounter anything suspicious or if an entry you're looking for is missing.
As of March 2020 the TNS serves as the official name server and hub for distribution of FRB events. At the request of this community, the TNS now operates two engines for designation of names, the original 'YYYYabc' (currently serving AT/SN), and now also 'YYYYMMDDabc' for FRBs (and potential future communities requiring such a format). New pages and processes have been deployed, enabling the reporting, distribution and querying of FRB events using both interactive forms and APIs.
Please see AstroNote 2020-70 for additional details on the major newly added components and functionalities.
In order to adapt the TNS for both the present and future needs, and in particular to the activity of transient brokers as significant sources that report discoveries of transients that are observed and publicly released by the observing surveys/facilities, we have deployed today - Dec 1st, 2019 - the adjustments to the handling of the “discovery group/s”, by introducing instead two distinct group identifications: the Reporting group and the Discovery Data Source group.
The changes affect the AT Report JSON/TSV formats (and clearly the AT Report Form), the search page, the object page, the discovery certificate and the statistics pages.
Please refer to AstroNote 2019-136 for additional clarifications on the essence of the revised treatments.
As mentioned, even if you did not revise your JSONs to the new format, your AT reports should not fail until Jan 31st, 2020.
However, if sending AT Reports via TSV, you should have the correct revised columns in place (reporting_group_id, discovery_data_source_id - instead of the single groupid).
For the Get API, the reply now includes a new internal_names entry that lists (csv) all existing internal names of the object, where the first internal_name is that of the official discovery report.
The existing internal_name entry remains as is for backward compatability.
So, e.g., for 2018ibb, we get the following entries:
When creating a new AstroNote (Add AstroNote), it is now possible to assign up to 3 additional editors (registered TNS users), who will also be able to edit the draft AstroNote, besides the person who created the AstroNote.
This is especially useful when an AstroNote is submitted on behalf of a survey/group, and whenever its relevant for additional people to be able to update and release the Note.
The specification of the additional editors is not done on the level of a template definition but when adding (creating) a new AstroNote.
The editors fields are auto-complete on the first/last names.
In case a correction has to be performed for a submitted AT report (in most cases its the Internal Name or the Source Group):
If being the sender of an AT-report, or either an owner of the relevant Group/Bot, it is possible to click on the AT-rep id (in the AT reports sub-table) for updating whichever of the following AT-rep details:
The Reporters (authors list),
Source group,
Internal name,
Host name,
Host redshift,
The requested proprietary period (if a proprietary report).
A new query parameter was added to the Search page, at the top of the page (above the Obj. Name field): Reported Within the Last X Days/Months/Years.
So that the loading of the search page will not increase over time (as objects continue to accumulate), the default value of this parameter is set to 1 Month.
If willing to perform queries without any limitation on the discovery date range, this field can just be cleared (left empty) or set to 0 (zero).
Revision of the treatment of object coordinates (astrometric accuracies) was deployed on 2019-06-23 on the TNS.
Currently 9 groups have a defined astrometric accuracy (that is below the default value of 5 arcsec), and these are now shown on the Groups page.
Coordinates were updated backwards for a total of 3157 objects, not affecting the actual objects and existing AT reports, and without any merging or splitting of objects.
We have deployed several additional updates and functionalities on the AstroNotes.
Following requests for displaying additional meaningful text in the email notifications on AstroNotes, we've added a new Abstract field where it is possible to provide a summary of the AstroNote and emphasize/point to its highlights.
The Abstract will be displayed in the AstroNotes email notifications and will also be officially indexed on the ADS as part of the AstroNotes entries.
For it to be properly displayed in the emails, it should contain only simple text (no HTML tags etc...), and it is limited to 1000 characters.
Another revision is related to the reporting/displaying of the object properties in the Related Objects table.
When inserting a TNS object in the Related Objects table, its main properties are injected to the table (RA, DEC, Type, Redshift), and those fields are now editable.
Note that updating those fields does not replace a formal Discovery or Classification report, but these denote what has been reported in the AstroNote itself.
On the AstroNote page (of a specific AstroNote), those fields will be displayed as the "Reported" properties, and by clicking the "Show current TNS values" above the table, it is also possible to show what are the actual current values on the TNS.
Reported values that differ from the current TNS values are highlighted in red.
Please have a look on the help page for additional explanations/clarifications.
We're pleased to announce the deployment of a new AstroNotes utility - the ability to create and manage your own
templates with which standardized AstroNotes (usually on behalf of a group/survey) can be easily written and released.
On the new My Templates page, every registered TNS user can create and manage their own AstroNote templates, either a
private one (with Source group=None) or for the use of a group (in which he/she is a member of).
When creating a new AstroNote it is possible to use and load an existing template (of the group or a personal one) by
choosing it in the "Use Template" select field at the top. After loading a template all relevant fields can be edited
and adjusted.
Please see the help page, AstroNotes section, for additional details.
The Transient Name Server (TNS) has been serving since Jan 2016 as the official IAU mechanism to announce and name newly
discovered transients. A major goal of this activity is to allow the community to easily connect object names with
precise information about these objects, in particular, their coordinates. The TNS issues automatic discovery and
classification reports for objects that are distributed to registered users and are indexed on the ADS.
In recent months we have identified a need for an expanded service providing a channel to announce to the community
messages covering a broader range of subjects. To answer this need, we have launched the TNS AstroNotes service. This
service allows all registered users to distribute notifications regarding a broad range of astrophysical topics to those
TNS users that choose to subscribe to the AstroNotes service. These include in particular:
1. Notes about discovery or classification of objects that contain more elaborate information than the automated TNS
notifications, including in particular notifications about re-classification of objects.
2. Notes providing additional data or analysis of transients.
3. Notifications about new astrophysical tools and utilities.
4. Notifications about new surveys or new observing campaigns.
5. General notifications of interest to the community.
The AstroNotes system is built to automatically connect notes to the related objects, thus making it possible to search
for information about an object by coordinates, name, type and more.
All AstroNotes are public, are provided free of charge to post and to read and are indexed on the ADS and citable.
All registered TNS users can submit AstroNotes, as long as they comply with general ethical standards for scientific
publications (including proper credit via references), with applicable laws, and their contents are scientifically
relevant to the astronomical community.
We have initially subscribed all TNS users to this service in order to distribute this notification. If you would prefer
to not receive any additional AstroNotes, or to select which notifications to receive and how often, just login to the
TNS, go to "My Account", scroll down to the "AstroNotes notifications" box and change your preferences accordingly.
We hope you find this service useful, and please feel free to send us any comments or requests to tns AT weizmann.ac.il.
A new switch (query field) was added to the Search API -> "public_timestamp".
If specifying here a certain date-time, the query will retrieve all objects that received a (public) discovery or classification report after that time.
This can serve for querying and downloading object details (using the "Get object" API for the retrieved object names) according to what was added/changed on the TNS from a specified date-time.
This covers also situations where e.g. an already known/existing object receives new information such as spectra (classification reports) etc...
As you can see on the sandbox API TEST FORM, here are the current parameters of the Search API:
On Jan 28 we increased the (cone search) radius threshold for determining coinciding objects from 3 to 5 arcsec.
This should decrease the amount of situations in which a new object is created (the separation from an existing object exceeds the threshold), but then has to be united with an existing event.
The new threshold of 5" also serves as the default cone search radius on the home page and search page, whenever a query by coordinates is performed.
We are very glad to inform that all the TNS discovery & classification reports (those that are the formal
"discoverers"/"classifiers") are now officially indexed on the NASA ADS system.
The bibcodes of the TNS reports begin with either YYYYTNSTR... or YYYYTNSCR...; TR standing for Transient (discovery)
Report, CR standing for Classification Report. The reports are arranged as daily aggregates per the reporting group and
reporter name/s (author/s).
Querying the ADS by object name (e.g. 2016A) or author/s retrieves any relevant TNS reports, so they can be officially
related to and cited.
On the ADS - for an index of a single object, clicking the "Electronic On-line Article" directs to the
discovery/classification certificate on the TNS. If an aggregate report for multiple objects, clicking the "On-line
Data" directs to the aggregate report on the TNS, which includes links to all objects' pages and certificates.
A total of ~1800 ADS indexes are now (Jun 2017) in place for all TNS reports since the begining of operation in Jan 2016.
The TNS now manages LIGO GW events, creating for every newly detected event skymaps showing the known public TNS transients that are found to be within the localization contours.
The data of the new events are accessible only to members of groups that are part of the LV-EM MOU.
See the explanations of LIGO GW Events on our help page.
A mechanism for association of TNS transients with sources of external catalogs is now active on the TNS, with KEGS being the first such ext. catalog.
Whenever a new object is reported to the TNS, a cone search is performed vs sources of the active external catalogs.
Every registered TNS user can set on his "My Account" page if he/she wishes to receive immediate email notifications when a new association is found for any of the listed active catalogs.
In the search page, under "Advanced search", it's possible to list all objects associated with the selected catalog.
In the object page, there's a note for association of the object with ext. catalog/s - "Separated X arcsec from...".
Addition of 2 columns to the staged csv - tns_public_objects.csv
The following two columns were added to tns_public_objects.csv:
Discovery_ADS_bibcode - The ADS bibcode of the discovery report (the official discoverer)
Class_ADS_bibcodes - The ADS bibcode/s of the classification reports (comma-separated if multiple)
These two columns were added before the last two columns: "creationdate","lastmodified".
So the current columns (as listed in the header line of the csv) are:
"objid","name_prefix","name","ra","declination","redshift","typeid","type","reporting_groupid","reporting_group","source_groupid","source_group","discoverydate","discoverymag","discmagfilter","filter","reporters","time_received","internal_names","Discovery_ADS_bibcode","Class_ADS_bibcodes","creationdate","lastmodified"
Reactivation of the LVK Gravitational-Wave events tool
On Mar 19th, 2024, we have deployed a newly developed service for the incoming LVK GW event alerts, providing sky maps and object lists of existing transients on the TNS that fall within event localizations.
Downloadable sky maps and lists are produced separately for transients that have been discovered BEFORE the exact GW alert time, and are thus not potential counterparts, and those that are streaming into the TNS with reported discovery dates after the GW event, thus potentially relevant.
Please refer to AstroNote 2024-79 for a more detailed description and check the main LVK GW page here.
Requests Rate-Limit mechanism is now active
The TNS requests Rate-Limit mechanism was deployed today - 2021-08-22 - on the real site.
Please check again the detailed explanations that were provided in the previous NewsFeed, below: A new Requests Rate-Limit mechanism and revised HTTP responses
The Rate-Limit handling does not effect the Bulk reports - there is no limitation on the rate at which discovery or classification reports are being reported to the system.
It will introduce limitations on the other calls (such as the Search/Get APIs, downloading of data, site usage) performed by users, bots and general scripted requests if surpassing the rate-limit per given minute - a running time-window.
Please refer to the revised API sample codes available for download from the Help Page, e.g. the Search/Get API Python code, for examples on possible ways to implement the Rate-Limit handling.
Do let us know if any questions arise, and a kind reminder to verify that your scripted TNS calls are managed efficiently, according to your scientific needs and without causing unnecessary load on the system.
A new Requests Rate-Limit mechanism and revised HTTP responses
*** Note that the new Requests Rate-Limit mechanism described below will be in effect on the real site from 2021-08-22!
1. General activity against the TNS
Over the last several months a lot of effort was put into adding security layers and mechanisms for reducing the load on the TNS.
Whereas we did manage to significantly reduce the activity of external (unwanted) bots, we noticed that there is significant load caused by "valid" requests of TNS users and bots who are hitting the TNS without enough caution and efficiency.
We contacted several Bot/Group managers in person in order to clarify the needs and propose improved use of the APIs and the offered tools (download of data etc...).
We found these correspondences to be very useful, and we encourage the Bot/Group managers to contact us and discuss with us their use cases, so that we can improve the processes for the benefit of both sides - the scientific needs and the load on the TNS servers/DB.
2. A new Requests Rate-Limit mechanism - Will be in effect from 2021-08-22.
As part of improving the control over the activity against the TNS, we've implemented a Rate-Limit ("quota") mechanism that will control the amount of requests that are allowed within a duration of X sec (a running window; currently of 60 sec), according to the type of action and the source (whether a logged-in user, anonymous user or a Bot).
The submission of bulk reports (discovery/classification) and the retrieval of the replies are excluded from the Rate-Limit mechanism; we clearly do not want to delay any submission of reports.
The main principles behind the decision on how many requests should be allowed per duration window are as follows:
Exceeding the Rate-limit will result in a "429 - Too Many Requests" error code.
The Rate-limit status per given set of requests can be tracked by the following "x-rate-limt" HTTP header keywords:
Similarly, for the cone searches - a smaller allowed Rate-limit within the Total allowed Rate-limit (when response.headers.get('x-cone-rate-limit-limit') != None):
Note that if there is a combination of cone search and other requests (from the same source during overlapping time windows), the total no. of allowed requests includes the cone searches. So each cone search request increments the counters of both the cone and the total limits.
So, e.g., for a python API call of the general form:
response = requests.post(url, headers=headers, data=data)
(where the headers contain a valid User-Agent tns_marker string)
It is possible to check the response status code and the Rate-limit status with: response.status_code and response.headers.get('x-rate-limit-limit').
So, printing of the end of a calling sequence may look like e.g.:
Test #27 return code: 200 | Limit: 30 | Remaining: 3 | Reset: 44
Test #28 return code: 200 | Limit: 30 | Remaining: 2 | Reset: 44
Test #29 return code: 200 | Limit: 30 | Remaining: 1 | Reset: 43
Test #30 return code: 200 | Limit: 30 | Remaining: 0 | Reset: 42
Test #31 return code: 429 | Limit: 30 | Remaining: Exceeded | Reset: 42
where the shown Limit value is obtained by: response.headers.get('x-rate-limit-limit');
the Remaining by: response.headers.get('x-rate-limit-remaining') and
the Reset by: response.headers.get('x-rate-limit-reset')
In the above example, when the limit was exceeded and status_code=429, the response.text JSON would show, e.g.:
{"id_code":429,"id_message":{"429":"Too Many Requests"},"data":{"total":{"limit":30,"reset":42,"remaining":"Exceeded"}}}
In such a case, if having more requests to submit, the script should wait till the end of the duration window (the x-rate-limit-reset value = 42 sec in the above example) before resuming to submit requests.
---
In the case of cone-search requests, the end of a calling sequence may look like e.g. (note the different Reset values for the Total & Cone):
Test #9 return code: 200 | Limit: 30 | Remaining: 21 | Reset: 40 || Cone Limit: 10 | Cone Remaining: 1 | Cone Reset: 56
Test #10 return code: 200 | Limit: 30 | Remaining: 20 | Reset: 39 || Cone Limit: 10 | Cone Remaining: 0 | Cone Reset: 55
Test #11 return code: 429 | Limit: 30 | Remaining: 19 | Reset: 39 || Cone Limit: 10 | Cone Remaining: Exceeded | Cone Reset: 55
response.text: {"id_code":429,"id_message":{"429":"Too Many Requests"},"data":{"total":{"limit":30,"reset":55,"remaining":19},"cone":{"limit":10,"reset":55,"remaining":"Exceeded"}}}
---
*** So, Best Practice: Check the x-rate-limit-remaining (or x-cone-rate-limit-remaining) header after each call, and when one of those reaches 0 (zero; even BEFORE receiving a 429 code), wait for x-rate-limit-reset (or x-cone-rate-limit-reset) sec before continuing to submit requests.
The Rate-limit mechanism is already active on the sandbox, and will be deployed on production on Sun, Aug 22nd, 2021.
Please make sure that your scripts (those that make use of the Search/Get APIs and/or downloading csv/tsv's using the Search page) are in place and are able to relate to the Rate-limit constraints.
In the coming days, the php & python sample codes, available for download from the Help Page, will include the general handling of the Rate-limit.
3. API replies - The HTTP response codes
For better performance and handling, the HTTP "true" response code will now be set in the HTTP header's "Status Code" and not only in the reply JSON.
To clarify the change: whereas beforehand an HTTP response code of 200 was set also in case of an error code in the JSON reply body (e.g. a 400-Bad Request), now the HTTP response code will also have a value of 400.
*** Best Practice: In order to make sure that your code complies with both the original and the new versions, simply make sure to parse the JSON in the reply's body (first line) regardless of the Status Code in the header. If the reply body is NOT a JSON, such as in the case of a 403-Forbidden error (that may originate from an external component), relate to the header's Status Code.
We'll be happy to answer any questions that may arise.
A python sample code for Search Page automatic CSV/TSV downloads
We've recently added a python sample code which you can use (or implement the relevant parts in your own scripts) for automatically downloading as CSV/TSV the resulting entries of a Search page query.
As mentioned at the bottom of the Quick query links on the Help page, a few example searches exist at the bottom of the script, and there's also a MERGE_TO_SINGLE_FILE flag for specifying whether you want to merge the retrieved entries into a single final CSV/TSV file or if to leave the downloaded files as they are.
Please feel free to use this script, and do let us know if any specific questions arise.
Build your scripted queries with caution, preferably against the sandbox first, so as not to create an unnecessary overload on the TNS servers/DB.
User-Agent string must be provided to all scripted TNS requests
Today, May 30 2021, we deployed the planned additional security layer that requires a User-Agent string to be provided to ALL scripted TNS requests.
That includes all API calls, as well as any wget/curl/etc... cmds that you use to access the TNS.
Please make sure to have this in place, otherwise, as of today, your scripted calls will fail to access the TNS (403 error).
Please refer to the previous NewsFeed below for more details, as well as the example API codes that are downloadable from the Help page.
User-Agent string must be provided to all scripted TNS requests
Important notice: Please act before May 23rd!
As part of the efforts to control the traffic and the external bots that communicate with the TNS,
we ask that you provide a specific User-Agent string to all request headers that are being submitted to the TNS.
This includes both the calls within your API scripts and any curl/wget commands you might be using to access the TNS.
The User-Agent string you should provide is a small json of the following format, with either a bot or user details:
tns_marker{"tns_id":YOUR_BOT_ID, "type": "bot", "name":"YOUR_BOT_NAME"}
tns_marker{"tns_id":YOUR_USER_ID,"type": "bot", "name":"YOUR_USER_NAME"}
The specific user or bot details you should specify are already available for copying/pasting on your My Account page or the Bots' edit pages (section "User-Agent Specification").
It is certainly possible and also encouraged to include your Browser's UA string, on top of the tns_marker json string.
The revised sample codes, both python and php, will be available on the help page, as well as the example curl commands for using the APIs or downloading csv's.
e.g. for downloading the daily TNS objects csv:
curl -X POST -H 'user-agent: tns_marker{"tns_id":YOUR_BOT_ID,"type": "bot", "name":"YOUR_BOT_NAME"}' -d 'api_key=YOUR_API_KEY' https://www.wis-tns.org/system/files/tns_public_objects/tns_public_objec... > tns_public_objects_20210509.csv.zip
or with wget:
wget -U 'tns_marker{"tns_id":YOUR_BOT_ID,"type": "bot", "name":"YOUR_BOT_NAME"}' --post-data='api_key=YOUR_API_KEY' https://www.wis-tns.org/system/files/tns_public_objects/tns_public_objec...
Please note that from May
2330 (deadline extended by 1 week) onwards, the scripted requests to the TNS may return an https error if failing to provide a User-Agent string.Feel free to contact us if you have any questions on this issue.
The TNS team.
Daily staging of all TNS public objects as CSV text files
We are glad to announce a new feature we have deployed, to enable easier and quicker mass download of information about TNS public objects.
Staging the CSV files will fulfil requests by TNS users, as well as encourage performing time-consuming operations locally by users, reducing the load on the TNS servers.
For example, if you need to cross-match entire catalogs or long object lists, we request that this would be done locally, against the csv (or a locally managed DB), rather than by executing multiple cone-searches via the Search API.
Calling the APIs for a limited number of objects is clearly fine, but we ask that our users apply appropriate caution and sensibility when using the TNS resources, that serve a broad community.
Every day after UT midnight, two CSV files are created and are accessible for download under: https://www.wis-tns.org/system/files/tns_public_objects/
1. tns_public_objects.csv.zip - holds the entire catalog of TNS public objects (AT/SN/FRB/... ~70,000 currently). This file is overwritten daily.
The date and time when the list of objects was created is specified in the first line; e.g. "2021-03-15 00:00:00"
2. tns_public_objects_YYYYMMDD.csv.zip - holds only those entries (objects) that were either added or modified during the specified day.
So, e.g. during Mar 15, 2021 it is possible to download this latest CSV for the previous day: tns_public_objects_20210314.csv.zip
The first line in the CSV will contain the exact duration covering the entries in the file; e.g. for the above example: "2021-03-14 00:00:00 - 23:59:59"
The separate daily files remain in place for 1 month backwards.
The csv's contain the following columns:
"objid","name_prefix","name","ra","declination","redshift","typeid","type",
"reporting_groupid","reporting_group","source_groupid","source_group",
"discoverydate","discoverymag","discmagfilter","filter",
"reporters","time_received","internal_names","creationdate","lastmodified"
* If being logged in, you can download e.g. the full csv by going to this url: https://www.wis-tns.org/system/files/tns_public_objects/tns_public_objec...
* cURL usage examples for downloading (note that the api-key is required, and that the required User-Agent specification was added):
curl -X POST -H 'user-agent: tns_marker{"tns_id":YOUR_BOT_ID,"type": "bot", "name":"YOUR_BOT_NAME"}' -d 'api_key=YOUR-API-KEY' https://www.wis-tns.org/system/files/tns_public_objects/tns_public_objec... > tns_public_objects.csv.zip
curl -X POST -H 'user-agent: tns_marker{"tns_id":YOUR_BOT_ID,"type": "bot", "name":"YOUR_BOT_NAME"}' -d 'api_key=YOUR-API-KEY' https://www.wis-tns.org/system/files/tns_public_objects/tns_public_objec... > tns_public_objects_20210314.csv.zip
Please do let us know if any major properties are missing or if you have any questions.
New AstroNotes "Statistics" page
As the use of the AstroNotes is growing, we've added a new AstroNotes Stats page, displaying the released AstroNotes timeline and break down of the reporting groups when hovering on the data points.
You may find this useful, similar to the Discovery and Classification Reports Timeline as shown on the general TNS statistics page.
Note that besides specification of a date range and Daily/Monthly/Yearly visualization, it is possible to filter by the type of AstroNote - whether Object-discovery/classification, Object-data analysis, Announcement-Tool/Utility etc...
Feedbacks and comments are as always most welcome.
The TNS has been migrated to the AWS cloud platform
We're glad to update that the TNS has been migrated to the AWS cloud platform today, Sun Dec 27, 2020.
Having the TNS deployed in this environment will improve the high-availability and scalability of the system, across multiple servers and availability zones, as preparation for future increased activity.
Redirects will be in place during the coming several weeks, but do make sure to update by the end of January 2021 the TNS URLs in your links and scripts as follows:
Real site: https://www.wis-tns.org
Sandbox: https://sandbox.wis-tns.org
The APIs handbooks and sample codes (accesible from the help page) have been revised with the updated entries.
No additional changes are required; all data, including account credentials, group definitions etc have been migrated as they are.
We hope that everything will continue to run flawlessly and we'll appreciate if you notify us on any issues if encountered via the contact page.
The TNS team.
Changes of JSON keywords in the Search/Get APIs
As part of implementing some improvements to the Search & Get (object details) APIs, the following changes were deployed on the Sandbox environment, and they are due to be deployed on the real site on Mon, Aug 17.
*** The changes involve deletion of a few keywords, listed below, so please make sure to arrange your scripts so that they will not fail. ***
"reply": {
"objname": "2020qdo",
"name_prefix": "SN",
"objid": 64211,
"object_type": {
"name": "SN Ia",
"id": 3
},
"redshift": 0.011,
"ra": "02:09:12.776",
"dec": "+18:55:55.35",
"radeg": 32.3032316667,
"decdeg": 18.9320416667,
"hostname": null,
"host_redshift": null,
"internal_names": "ATLAS20ugw",
"discoverer_internal_name": "ATLAS20ugw",
"discoverydate": "2020-07-23 13:35:02.400",
"discoverer": "J. Tonry, L. Denneau, A. Heinze, H. Weiland, H. Flewelling (IfA, University of Hawaii), B. Stalder (LSST), A. Rest (STScI), C. Stubbs (Harvard University), K. W. Smith, S. J. Smartt, D. R. Young, S. Srivastav, O. McBrien, D. O'Neill, P. Clark, M. Fulton, J. Gillanders, M. Dobson (Queen's University Belfast), T.-W. Chen (MPE), D. E. Wright (University of Minnesota), J. Anderson (ESO), A. Townsend (University of Manchester)",
"reporter": "ATLAS_Bot1",
"reporterid": 35595,
"source": "bot",
"discoverymag": 19.038,
"discmagfilter": {
"id": 72,
"name": "orange",
"family": "ATLAS"
},
"reporting_group": {
"groupid": 18,
"group_name": "ATLAS"
},
"discovery_data_source": {
"groupid": 18,
"group_name": "ATLAS"
},
"public": 1,
"end_prop_period": null
}
}
followed by the photometry/spectra data if requested...
Comments and feedbacks are clearly welcome.
Kind regards,
The TNS Team.
ALL classification reports are now officially indexed on the ADS
Following requests from the community, we now index (create official ADS bibcode for) all classification reports submitted to the TNS, not only for the "formal classifier" (the first classification made public).
This is useful especially for those cases where the first classification is later realized to be incorrect/uncertain, or either there is a true dilemma about the nature of an event, and it is necessary to be able to officially cite other reported classifications.
The bibcode for all classifications of an object is now shown in the last column (ADS Bibcode) of the Classification Reports sub-table on the Search/Object pages, linking to the ADS.
(For the formal classification report, the ADS bibcode also appears on the "Classification Certificate", as before.)
We've also created and updated on the ADS the indexes for all relevant past classification reports, from 2016 until now. All backlog ADS indexes can be reviewed here.
Do let us know if you encounter anything suspicious or if an entry you're looking for is missing.
Fast Radio Bursts now reported to and distributed via the TNS
As of March 2020 the TNS serves as the official name server and hub for distribution of FRB events. At the request of this community, the TNS now operates two engines for designation of names, the original 'YYYYabc' (currently serving AT/SN), and now also 'YYYYMMDDabc' for FRBs (and potential future communities requiring such a format). New pages and processes have been deployed, enabling the reporting, distribution and querying of FRB events using both interactive forms and APIs.
Please see AstroNote 2020-70 for additional details on the major newly added components and functionalities.
Modifications to the treatment of the Discovery (Source) Group
In order to adapt the TNS for both the present and future needs, and in particular to the activity of transient brokers as significant sources that report discoveries of transients that are observed and publicly released by the observing surveys/facilities, we have deployed today - Dec 1st, 2019 - the adjustments to the handling of the “discovery group/s”, by introducing instead two distinct group identifications: the Reporting group and the Discovery Data Source group.
The changes affect the AT Report JSON/TSV formats (and clearly the AT Report Form), the search page, the object page, the discovery certificate and the statistics pages.
Please refer to AstroNote 2019-136 for additional clarifications on the essence of the revised treatments.
As mentioned, even if you did not revise your JSONs to the new format, your AT reports should not fail until Jan 31st, 2020.
However, if sending AT Reports via TSV, you should have the correct revised columns in place (reporting_group_id, discovery _data_source_id - instead of the single groupid).
Search/Get APIs internal names improvements
On the Search API, it is now possible to explicitly specify if we require exact matches or LIKE '...%' for both the objname and internal_name.
The default values are "0" - for non-exact matches. Note that any specified prefix (AT/SN...) is ignored, and we relate to only the unique objname.
{
"ra": "",
"dec": "",
"radius": "",
"units": "",
"objname": "",
"objname_exact_match": 0,
"internal_name": "",
"internal_name_exact_match": 0,
"public_timestamp": ""
}
For the Get API, the reply now includes a new internal_names entry that lists (csv) all existing internal names of the object, where the first internal_name is that of the official discovery report.
The existing internal_name entry remains as is for backward compatability.
So, e.g., for 2018ibb, we get the following entries:
"internal_name": "ATLAS18unu",
"internal_names": "ATLAS18unu, ZTF18acenqto, PS19crg, Gaia19cvo",
GUI improvements, also for mobile
We deployed today GUI improvements, also w.r.t. mobile behaviour, on the following pages:
We'll appreciate to receive feedback if any additional revisions/improvements are required.
AstroNotes - assigning additional editors (writers)
When creating a new AstroNote (Add AstroNote), it is now possible to assign up to 3 additional editors (registered TNS users), who will also be able to edit the draft AstroNote, besides the person who created the AstroNote.
This is especially useful when an AstroNote is submitted on behalf of a survey/group, and whenever its relevant for additional people to be able to update and release the Note.
The specification of the additional editors is not done on the level of a template definition but when adding (creating) a new AstroNote.
The editors fields are auto-complete on the first/last names.
Enabling correction of some AT-Report details by the senders
In case a correction has to be performed for a submitted AT report (in most cases its the Internal Name or the Source Group):
If being the sender of an AT-report, or either an owner of the relevant Group/Bot, it is possible to click on the AT-rep id (in the AT reports sub-table) for updating whichever of the following AT-rep details:
New query parameter on the Search page: Reported within...
A new query parameter was added to the Search page, at the top of the page (above the Obj. Name field): Reported Within the Last X Days/Months/Years.
So that the loading of the search page will not increase over time (as objects continue to accumulate), the default value of this parameter is set to 1 Month.
If willing to perform queries without any limitation on the discovery date range, this field can just be cleared (left empty) or set to 0 (zero).
The revised treatment of astrometric accuracies is now active
Revision of the treatment of object coordinates (astrometric accuracies) was deployed on 2019-06-23 on the TNS.
Currently 9 groups have a defined astrometric accuracy (that is below the default value of 5 arcsec), and these are now shown on the Groups page.
Coordinates were updated backwards for a total of 3157 objects, not affecting the actual objects and existing AT reports, and without any merging or splitting of objects.
Please refer to AstroNote 2019-37 for details.
Additional AstroNotes updates, incl. a new Abstract field
We have deployed several additional updates and functionalities on the AstroNotes.
The Abstract will be displayed in the AstroNotes email notifications and will also be officially indexed on the ADS as part of the AstroNotes entries.
For it to be properly displayed in the emails, it should contain only simple text (no HTML tags etc...), and it is limited to 1000 characters.
When inserting a TNS object in the Related Objects table, its main properties are injected to the table (RA, DEC, Type, Redshift), and those fields are now editable.
Note that updating those fields does not replace a formal Discovery or Classification report, but these denote what has been reported in the AstroNote itself.
On the AstroNote page (of a specific AstroNote), those fields will be displayed as the "Reported" properties, and by clicking the "Show current TNS values" above the table, it is also possible to show what are the actual current values on the TNS.
Reported values that differ from the current TNS values are highlighted in red.
Please have a look on the help page for additional explanations/clarifications.
Creating and managing your AstroNotes *TEMPLATES* - now online
We're pleased to announce the deployment of a new AstroNotes utility - the ability to create and manage your own
templates with which standardized AstroNotes (usually on behalf of a group/survey) can be easily written and released.
On the new My Templates page, every registered TNS user can create and manage their own AstroNote templates, either a
private one (with Source group=None) or for the use of a group (in which he/she is a member of).
When creating a new AstroNote it is possible to use and load an existing template (of the group or a personal one) by
choosing it in the "Use Template" select field at the top. After loading a template all relevant fields can be edited
and adjusted.
Please see the help page, AstroNotes section, for additional details.
Comments and suggestions are clearly welcome!
Releasing the new TNS AstroNotes service - March 25, 2019
The Transient Name Server (TNS) has been serving since Jan 2016 as the official IAU mechanism to announce and name newly
discovered transients. A major goal of this activity is to allow the community to easily connect object names with
precise information about these objects, in particular, their coordinates. The TNS issues automatic discovery and
classification reports for objects that are distributed to registered users and are indexed on the ADS.
In recent months we have identified a need for an expanded service providing a channel to announce to the community
messages covering a broader range of subjects. To answer this need, we have launched the TNS AstroNotes service. This
service allows all registered users to distribute notifications regarding a broad range of astrophysical topics to those
TNS users that choose to subscribe to the AstroNotes service. These include in particular:
1. Notes about discovery or classification of objects that contain more elaborate information than the automated TNS
notifications, including in particular notifications about re-classification of objects.
2. Notes providing additional data or analysis of transients.
3. Notifications about new astrophysical tools and utilities.
4. Notifications about new surveys or new observing campaigns.
5. General notifications of interest to the community.
The AstroNotes system is built to automatically connect notes to the related objects, thus making it possible to search
for information about an object by coordinates, name, type and more.
All AstroNotes are public, are provided free of charge to post and to read and are indexed on the ADS and citable.
All registered TNS users can submit AstroNotes, as long as they comply with general ethical standards for scientific
publications (including proper credit via references), with applicable laws, and their contents are scientifically
relevant to the astronomical community.
We have initially subscribed all TNS users to this service in order to distribute this notification. If you would prefer
to not receive any additional AstroNotes, or to select which notifications to receive and how often, just login to the
TNS, go to "My Account", scroll down to the "AstroNotes notifications" box and change your preferences accordingly.
We hope you find this service useful, and please feel free to send us any comments or requests to tns AT weizmann.ac.il.
A new "public_timestamp" query field for use in the "Search" API
Updated/improved spectra plots on the object pages
We have updated the interactive spectra plots.
The rest-frame wavelengths are now shown on the bottom x-axis (observed frame at the top);
the elements checkboxes (for over-plotting their lines) have been revised, now enabling to select separately the forbidden lines.
To view the spectra on separate plots, click the figure icons in the spectra list (below the aggregated plot).
External catalogs of the TESS pointings added to the TNS
The TESS FOVs are now maintained on the TNS, so that notifications can be received whenever a reported transient coincides with the current TESS FOV.
As with previous catalogs, on your "My Account" page, check the TESS-SectorX checkbox for receiving live notifications via email.
Every ~1 month there's a shift of sector and a new sector will become active (you may check the schedule here: https://tess.mit.edu/observations/#sched).
Please make sure to mark each new sector whenever it becomes available.
Radius threshold to determine coinciding objects updated to 5"
On Jan 28 we increased the (cone search) radius threshold for determining coinciding objects from 3 to 5 arcsec.
This should decrease the amount of situations in which a new object is created (the separation from an existing object exceeds the threshold), but then has to be united with an existing event.
The new threshold of 5" also serves as the default cone search radius on the home page and search page, whenever a query by coordinates is performed.
Python sample codes for using all existing APIs
We have added a full set of python sample codes, kindly written by Nikola Knezevic,
which can be used to help develop the required scripts to work with the TNS.
The codes cover all the existing APIs:
AT/Classification bulk reports (examples are provided for both JSON and TSV formats),
file uploads, update of proprietary end date, search and get object details.
The sample codes (PHP+Python) can be downloaded from the help page, under the relevant APIs sections.
TNS discovery & classification reports officially indexed on ADS
We are very glad to inform that all the TNS discovery & classification reports (those that are the formal
"discoverers"/"classifiers") are now officially indexed on the NASA ADS system.
The bibcodes of the TNS reports begin with either YYYYTNSTR... or YYYYTNSCR...; TR standing for Transient (discovery)
Report, CR standing for Classification Report. The reports are arranged as daily aggregates per the reporting group and
reporter name/s (author/s).
Querying the ADS by object name (e.g. 2016A) or author/s retrieves any relevant TNS reports, so they can be officially
related to and cited.
On the ADS - for an index of a single object, clicking the "Electronic On-line Article" directs to the
discovery/classification certificate on the TNS. If an aggregate report for multiple objects, clicking the "On-line
Data" directs to the aggregate report on the TNS, which includes links to all objects' pages and certificates.
A total of ~1800 ADS indexes are now (Jun 2017) in place for all TNS reports since the begining of operation in Jan 2016.
External catalog of the [K2 - Campaign 14] galaxies added
The KEGS-C14 catalog was added to the TNS, consisting of ~14500 galaxies (PI: Rest).
https://keplerscience.arc.nasa.gov/k2-approved-programs.html#campaign-14
If willing to receive email notifications whenever a newly reported transient is found to coincide with a galaxy of this catalog,
please remember to check the KEGS-C14 checkbox at the bottom of the MY ACCOUNT page.
Pan-Starrs1 thumbnails (stamps) now shown on the Object page
We added a display of the PS1 color stamp on the Object page, next to the SDSS thumbnail.
The PS1 stamp (if within the footprint) should become visible within ~1 hr after the appearance of a new object.
Improved cone searches
Improved cone search (on both the search page and in reporting of a new object) to handle computer truncation/rounding problems.
Corrected - object details when switching to public
Corrected update of object discoverymag & discmagfilter when object switches to being public.
LIGO GW events skymaps of TNS objects within localizations
Association of TNS objects with sources of external catalogs
The TNS Chrome Extention