Online asteroid data -> wish list?
Steffen Möller
steffen_moeller at gmx.de
Sun Mar 25 01:07:22 UTC 2018
Hello,
I had a look at the machine-readable flavour of
https://ssd-api.jpl.nasa.gov/doc/scout.html at
https://ssd-api.jpl.nasa.gov/scout.api which returns a bit of json
like this
{"count":"28",
"signature":{"source":"NASA/JPL Scout API","version":"1.2"},
"data":[
{"neo1kmScore":"0","lastRun":"2018-03-10 11:39","uncP1":"0.99",
"dec":"+62","neoScore":"100","rating":"0","rate":"1.0","unc":"0.95","phaScore":"0",
"ra":"15:06","elong":"109","nObs":"14","arc":"28.46","tEphem":"2018-03-25
00:15",
"objectName":"ZE9BC85","tisserandScore":"0","caDist":"7.8",
"vInf":"9.1","H":"27.4","rmsN":"0.97","ieoScore":"0","geocentricScore":"0","moid":"0.02",
"Vmag":"24.9"},
{"neo1kmScore":"0","lastRun":"2018-03-20 10:48","uncP1":"130",
"dec":"-18","neoScore":"100","rating":"0","rate":"5.6","unc":"120","phaScore":"0",
"ra":"12:04","elong":"164","nObs":"7","arc":"1.10","tEphem":"2018-03-25
00:15",
"objectName":"ZF2E18B","tisserandScore":"42","caDist":"6.2",
"vInf":"17.9","H":"26.4","rmsN":"1.24","ieoScore":"0","geocentricScore":"0","moid":"0.02",
"Vmag":"21.4"},
...
]}
Blanks and newlines were added by me to help with readability. In
analogy to the MPC NEOCP page I created a 'tool' to transform the
above into a kstars-catalog compatible format:
#catalog id longname RA Decl type magnitude
scout 0 ZE9BC85 15:06 +62 255 24.9
scout 1 ZF2E18B 12:04 -18 255 21.4
scout 2 P10H4MB 11:14 +08 255 22.0
...
The API also nicely supports the query for additional
information about individual objects. To retrieve information
on observations as stored by the MPC one retrieves from
https://ssd-api.jpl.nasa.gov/scout.api?tdes=ZFA47C1&file=mpc
additional json-formatted data
{"neo1kmScore":"0","lastRun":"2018-03-18 12:18","uncP1":"2600",
"dec":"+55",
"fileMPC":" ZFA47C1* C2018 03 18.44658 12 45 21.11 +09 39 21.7
19.8 GUNEOCPG96\n
ZFA47C1 C2018 03 18.45169 12 45 17.59 +09 42 22.9
19.5 GUNEOCPG96\n
ZFA47C1 C2018 03 18.45678 12 45 14.04 +09 45 23.8
20.1 GUNEOCPG96\n",
"neoScore":"100","rating":null,"rate":"8.1","unc":"2500","phaScore":"0",
"ra":"10:59","elong":"116","nObs":"3","arc":"0.24","tEphem":"2018-03-25
00:30",
"objectName":"ZFA47C1","tisserandScore":"32","caDist":"25","vInf":null,"H":"24.6","rmsN":"0.18","ieoScore":"0",
"signature":{"source":"NASA/JPL Scout API","version":"1.2"},
"geocentricScore":"0","moid":"0.05",
"Vmag":"22.3"}
which would then nicely serve an automated recomputation of ephemerides.
So, I put this as scout2kstars at http://functional.domains/kstars/ and
await further instructions.
Best,
Steffen
On 3/23/18 1:19 PM, Steffen Möller wrote:
> Hello again,
>
> I had asked my asteroidal mentor about his opinion. He said
>
> (1) there is a new JPL analogue to the MPL NEOCP that is called "scout"
> https://cneos.jpl.nasa.gov/scout/
> with an API outlined at https://ssd-api.jpl.nasa.gov/doc/scout.html
> (2) in particular for asteroids of a high magnitude one commonly
> recomputes oneself the ephemeres from the observations available with
> find_orb. That tool is open source and available in Debian already, so
> kstars could just add it as "suggested" and would not need to
> redistribute it.
> (3) JPL/MPL is all fine, no conflicts since one does not use either
> pre-computed data.
>
> The recomputation of ephemerides (2) I had not expected. Sounds like a
> nice feature for kstars to have, though. This could for instance look
> like a text area to which past observations are downloaded on demand.
> The user can then edit these data and add own observations. Then, the
> ephemeres could be computed.
>
> As an initial shot at (1) and (3), i.e. the initial selection of
> asteroids to inspect at a given evening, I will have a closer look at
> scout and also provide some C++ code to reformat it. If there is
> something else you want me to do then please tell me.
>
> Cheers,
>
> Steffen
>
> On 3/17/18 2:41 PM, Steffen Möller wrote:
>> On 3/17/18 1:13 PM, Jasem Mutlaq wrote:
>>> I think the asteroid component in KStars needs to be updated to
>>> incorporate different sources instead of a single source like now,
>>> then it could parse the different sources and resolves any conflicts
>>> before making it available to the user.
>>
>> While this is certainly useful and interesting, I tend to think that
>> for asteroids the user has already decided what source to trust for
>> what purpose. After all, the equipment the user brings e.g. for
>> asteroidal occultations is very different than for dealing with NEOs,
>> so the choice is already made when kstars is started and no consensus
>> between data sources is required. So, as a start I suggest to just
>> show the data from a particular source that is selected.
>>
>> I propose you ("we" if you allow) get some workflow established that
>> supports the communication of JPL/MPC resources with amateur
>> scientists and then talk back to those agencies. They are likely to
>> have more ideas and why not work towards a joint press release about it.
>>
>> The context from which I am bothering you about all is that I have
>> joint the Slooh.com community. They have an A(steroid)-Team and a
>> tutorial plus mentoring to guide noobs like me towards first
>> successes. Their official guide towards prioritising the many
>> potential targets is to enter their coordinates into kstars and its
>> alternatives to then get an idea about the elevation above the
>> horizon, the object-earth-moon angle, ... . That sounds worse than it
>> is since Slooh only has two sites and reducing to a magnitude of 19
>> limits the targets one wants to look at, but, still, it is 2018 and
>> one should not need to perform any such error-prone typing or limit
>> oneself to two sites of remote telescopes or to mag 19.
>>
>> So, I really think that kstars could make quite a difference.
>>
>> Best regards,
>>
>> Steffen
>>
>>> On Sat, Mar 17, 2018 at 5:25 AM, Steffen Möller
>>> <steffen_moeller at gmx.de <mailto:steffen_moeller at gmx.de>> wrote:
>>>
>>> Hello,
>>>
>>> On 3/16/18 3:07 PM, Jasem Mutlaq wrote:
>>>
>>> If you have a method to automate this process, we can include
>>> it in KStars.
>>>
>>> I now created a small to tool and tried
>>>
>>> wget -O -
>>> https://www.minorplanetcenter.net/Extended_Files/neocp.json
>>> <https://www.minorplanetcenter.net/Extended_Files/neocp.json> |
>>> ./neocp2kstars
>>>
>>> which gives me
>>>
>>> #catalog id longname RA Decl type magnitude
>>> neocp 0 A106yEM 9.8501 -37.3746 255 17.3
>>> neocp 1 ZFA1276 12.9752 19.5189 255 20.9
>>> neocp 2 ZFA142F 16.1963 17.7824 255 20.4
>>> neocp 3 ZFA13B2 15.2812 16.1363 255 20
>>> neocp 4 ZFA1343 14.0707 13.71 255 18.5
>>>
>>> .....
>>>
>>> Source code is at http://functional.domains/kstars/
>>> <http://functional.domains/kstars/> . There is apparently object
>>> type for asteroids since kstars knows the ephemerides, right? For
>>> this particular page, one does not really need to know much more
>>> than that the NEO is listed on it and thus help is needed, I tend
>>> to think. The magnitude is the most important parameter so the
>>> user can decide if the object is likely to be visible with the
>>> telescope and seing conditions. And then the user retrieves online
>>> the ephemerides for the objects of interest. For other lists, one
>>> may be tempted to want to know a bit morem i.e. more than the
>>> catalog is currently prepared for.
>>>
>>> But we're getting our astroid data from JPL and not MPC, so
>>> that's the problem here.
>>>
>>>
>>> To the best of my little understanding of the whole process, the
>>> neocp are not part of the catalogs, yet, so this should be fine
>>> wrt redundancy.
>>>
>>> I am too new with this all to make any judgement on how likely it
>>> is to expect differences/inconsistencies for numbered objects
>>> between the institutions' generated web sites and what kstars
>>> computes.
>>>
>>> Perhaps we can support more than one source of data.
>>>
>>>
>>> This would be nice. Another list that I would like to see is
>>>
>>> https://www.minorplanetcenter.net/iau/NEO/LastObsNEO.html
>>> <https://www.minorplanetcenter.net/iau/NEO/LastObsNEO.html>
>>>
>>> The MPC also offers a text file of that content which I happily
>>> also transform.
>>>
>>> Maybe it would help to introduce the concept of temporary validity
>>> of such star data. For any conflicting information the data in
>>> kstars should be superior I tend to think since it can determine
>>> the asteroidal positions for any time, right? Just for objects
>>> unknown to kstars one would like to see that data added. Extra
>>> information on the type of asteroid (hazardous or not, ...) and
>>> when it was last found would be nice to address, too.
>>>
>>> Many thanks and regards,
>>>
>>> Steffen
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 16, 2018 at 5:04 PM, Steffen Möller
>>> <steffen_moeller at gmx.de <mailto:steffen_moeller at gmx.de>
>>> <mailto:steffen_moeller at gmx.de
>>> <mailto:steffen_moeller at gmx.de>>> wrote:
>>>
>>> Hello again,
>>>
>>> On 3/13/18 9:50 AM, Steffen Möller wrote:
>>>
>>> Dear KStars-Team,
>>>
>>> There are multiple web sites out there that support
>>> amateur
>>> astronomers with the prioritization of their asteroidal
>>> observations. I mean, there is no chance for kstars to
>>> know
>>> this offline since only the MPC knows when a newly
>>> reported
>>> asteroid needs a confirmation. These are somewhat
>>> tricky at
>>> times in that even when you are granted the
>>> opportunity to
>>> specify the geographic location of your telescope,
>>> these do
>>> not necessarily state the exact time at which it is
>>> available
>>> (which you need to ask for the ephemerides in a second
>>> step)
>>> or the object is so low above the horizon that one
>>> would shy
>>> away from it. So, I'd very much like to see these
>>> dynamically
>>> created web sites auto-feed my wish list and fall back
>>> to the
>>> comfort of kstars.
>>>
>>> Would that be desirable? If so, then I propose to
>>> contact the
>>> provider(s) of these web sites about the degree they
>>> want to
>>> support any such project e.g. by a XML/JSON version of
>>> their
>>> output if they don't have it already or the parsing
>>> could be a
>>> first code contribution of mine. These sites also
>>> differ in
>>> the extra information these offer about the
>>> asteroid. Once
>>> could such also consider to extend the data model that
>>> represents asteroids in kstars with such dynamic
>>> information.
>>> To mind comes the date at which the asteroid was last
>>> observed.
>>>
>>> Please kindly instruct me about what I should do
>>> towards any
>>> such development.
>>>
>>>
>>> I received a reply by Valentin who suggested to import
>>> such files
>>> manually. I was not ultimately happy about that
>>> suggestion, I must
>>> admit, since to me it was important to see the workflow as
>>> a whole
>>> somehow represented from within kstars. But he may have a
>>> point.
>>> The MPC offers both XML and json files here
>>> https://minorplanetcenter.net/data
>>> <https://minorplanetcenter.net/data>
>>> <https://minorplanetcenter.net/data
>>> <https://minorplanetcenter.net/data>> and the
>>> http://www.minorplanetcenter.net/Extended_Files/neocp.json
>>> <http://www.minorplanetcenter.net/Extended_Files/neocp.json>
>>>
>>> <http://www.minorplanetcenter.net/Extended_Files/neocp.json
>>> <http://www.minorplanetcenter.net/Extended_Files/neocp.json>> in
>>> particular seems of interest to me.
>>>
>>> So, I'll then prepare a script to download that file, pimp
>>> it for
>>> an import to kstars and report about it here.
>>>
>>> Steffen
>>>
>>>
>>>
More information about the Kstars-devel
mailing list