Online asteroid data -> wish list?
Steffen Möller
steffen_moeller at gmx.de
Sun Mar 25 15:36:24 UTC 2018
On 3/25/18 10:19 AM, valentin at boettcher.cf wrote:
> Hidiho.
;)
> You want to use orbits of unconfirmed objects in kstars, as far as I
> understand.
This is a consequence of my frustration with the Slooh remote telescope
reservation system, I am afraid. Yes.
>
> The scout API seems rather suitable for that purpose. The catch of it
> all is, that the ephemeris of ordinary astroids are calculated
> directly in kstars and they don't expire nor do they provide any extra
> data and designation. One could add this functionality to the astroids
> but that would result in an ugly mess.
Understood. I don't want to cause any mess. Extra data however may be
nice to have also for other citizen-science-astronomical fields like the
observation of variable stars. Or the asteroidal occultation of stars.
Concerning the ephemerides of asteroids I tend to think they should
expire or at least have a date of their last computation with them. The
larger context to that could be the provisioning of
https://en.wikipedia.org/wiki/Provenance information for any data
offered in kstars, i.e. you know for every star/asteroid/.. shown why it
is reported at that position/brightness/... .
> Another skycomponent and skyobject pair can be implemented to suit
> that purpose. The most parts of it are already at hand, but this would
> be major work.
>
> The actual data parsing is no problem, as qt provides nice helpers for
> that. There is no need to worry about that now.
You guys who come up with kstars can certainly parse a json file :) It
was more about introducing me and those resources.
>
> My vague concept is, that this skycomponent could provide you with a
> list of objects from which you can choose those you're interested in.
Yes. Except I would like to add that these are the objects that the JPL
and the MPC are most interested in to see them observed again. And
because these experts declared those object as important it is that the
hobby astronomers are interested in them.
> These objects shall then be updated in regular intervals and destroyed
> if they disappear from the API.
Yes. As a start I am tempted to go as far as to use these objects only
to fill the wish-list, not affecting anything else in the kstar universe.
>
> Now you have to make clear if:
>
> 1. We have understood what you want.
Yes. I have complete confidence that you could with or without a
contribution of mine bring kstars to a state that it would import those
online wish-lists and also auto-remove these objects.
One particular challenge may be to ensure that any such new feature does
not impede the development of kstars you are planning. What I want in
the longer terms, i.e. after the dynamic wish-lists are working, is to
support a larger fraction of the workflow of the asteroidal researcher.
Most pressing may be the support of multiple telescope locations to add
remote scopes to the one in the backyard (also itelescope.net,
slooh.com, etc. both have multiple sites). Also I find that the
presentation of time zones could be helped for working with remote
telescopes but I need to make up my mind about it all a bit more.
> 2. You think one data source of unconfirmed asteroids is sufficient.
> (Otherwise I have an idea for a generic Backend)
I cannot really judge, but for the sake of simplicity and trusting the
JPL to have aggregated all data that is needed - yes. Do you have a
contact at JPL with whom to talk this through? I mean, they should be
excited about what effectively is a direct information flow from their
web site to backyard telescopes around the globe.
The generic backend would be nice to have, though, if possible then also
for other resources like those variable stars mentioned above and there
certainly is more out there. I don't know how modular kstars can be in
this respect, variable stars have their very own demands for being
observed/data displayed and a modular interface may help to attract
respective communities to kstars.
> Multiple data sources for ordinary asteroids are a different pair of
> shoes altogether.
The JPL is perfectly fine. It would just be nice if users have the
opportunity to
* add their own asteroids - like the ones from scout that are not in
the official JPL catalog you are using
* update the data of the asteroids you already show from the reported
(and self-performed) observations
What is admittedly a bit weird is that any such editing transforms
kstars from a passive tool towards an active research companion not only
for telescope control but also for the data management and interpretation.
Best,
Steffen
> On 25 March 2018 07:58:32 CEST, Jasem Mutlaq <mutlaqja at ikarustech.com>
> wrote:
>
> Steffen,
>
> Were you able to get KStars compiled on your system? I think
> that's the first thing you should try to get going.
>
> Valentin just submitted major enhancements to KStars
> asteroid-handling code to increase efficiency. But basically today
> we're relying one source of JPL data for asteroid/NEO/comets and
> KStars is computing the the mag & coordinates when necessary.
>
> It seems that scout2kstars is using the regular Catalog import
> feature, which treats such objects as stars/DSOs and not local
> solar system objects, so their positions will not be accurate. Now
> I'm not sure if you mentioned before that such objects have their
> ephemerides recomputed on the server itself? If that's the case,
> what's the time period required to run another update for the data
> to be valid again?
>
> Best Regards,
> Jasem Mutlaq
>
>
> On Sun, Mar 25, 2018 at 4:07 AM, Steffen Möller
> <steffen_moeller at gmx.de <mailto:steffen_moeller at gmx.de>> wrote:
>
> Hello,
>
> I had a look at the machine-readable flavour of
> https://ssd-api.jpl.nasa.gov/doc/scout.html
> <https://ssd-api.jpl.nasa.gov/doc/scout.html> at
> https://ssd-api.jpl.nasa.gov/scout.api
> <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
> <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/
> <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/
> <https://cneos.jpl.nasa.gov/scout/>
> with an API outlined at
> https://ssd-api.jpl.nasa.gov/doc/scout.html
> <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>
> <mailto: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>
> <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/>
> <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>
> <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>>
> <mailto: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>>
> <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>>
>
> <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
>
>
>
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Kstars-devel
mailing list