New satellite information in ssc form

[Chuft-Captain]

A few comments about my earlier posts...

.... if you're generating definitions for 1100 spacecraft, the default mesh should have as few polygons as possible. Celestia *generally* tries to render every polygon in the field-of-view. (with some culling I think)

It looks like this is not an issue as these satellites are all far enough apart that Celestia's culling takes care of any possible performance issues. ie. There's never more than one satellite in the FOV large enough to require rendering (when they're far enough away, they're just rendered as dots).

1. Modified your noradsatellites.ssc as follows:

Code: Select all

""GLOBALSTAR M001" "Sol/Earth" {
 Class "Invisible"
 #Mesh
 Radius 0.010   #0.004999999888241291
...
...

There is one issue with this ... Invisible's don't get labelled (which was a fairly recent change made by Chris to avoid screen clutter). Unfortunately, a spacecraft which is a child of an Invisible location (eg. "GLOBALSTAR M001 Body", etc) also doesn't get labeled.

I consider this to be a bug in Celestia. If spacecraft labeling is switched on, imo ALL spacecraft should be labeled, whether they are children of an Invisible, or not.

CC

[BobHegwood]

I consider this to be a bug in Celestia. If spacecraft labeling is switched on, imo ALL spacecraft should be labeled, whether they are children of an Invisible, or not.

If I may, I agree with Chuft-Captain here...
I believe that all spacecraft should be labeled. This way,
spacecraft on the surface of the Moon could be located
easily, and without having to use ENTER-TYPE NAME-ENTER
method to locate them.
The spacecraft I'm talking about here depend on an
invisible barycenter.

Just my two cents worth.
Thanks, Bob

[Chuft-Captain]

FYI,

Related bug report I logged a while ago: https://sourceforge.net/tracker/?func=d ... tid=371302

CC

[Chuft-Captain]

Jeff,

I don't know if you've found a solution for the problem of all the FENGYUN debris saving the same NAME.
I've discovered another problem with this...it's not possible to create usable celURL's if these objects are involved.
eg. The following URL won't work

Code: Select all

cel://SyncOrbit/Sol:Earth:IRIDIUM 10 [+]/2009-01-22T10:43:51.14866?x=QWmWyi0&y=2rmMEbj//////////////w&z=4rK8vFY&ow=-0.847687&ox=0.439803&oy=0.0260162&oz=0.295506&select=Sol:Earth:FENGYUN 1C DEB&fov=36.2777&ts=1&ltd=0&p=1&rf=121495&lm=32768&tsrc=0&ver=3

(the embedded spaces are also an issue but that's solvable by substituting '%20', however the "&select=Sol:Earth:FENGYUN 1C DEB" part causes problems, I would guess because the celURL can't decide which of the 2000 odd objects to use.

I don't know what the solution to this is -- you might have to discuss with Chris. One possible solution could be to use the NORAD-ID as the primary identifier for these particular objects in order to ensure that each object has a unique ID (There seems to be a number of issues caused by non-unique ID''s).

CC

[Chuft-Captain]

Jeff,

I don't know if you've found a solution for the problem of all the FENGYUN debris saving the same NAME.
I've discovered another problem with this...it's not possible to create usable celURL's if these objects are involved.
eg. The following URL won't work

Code: Select all

cel://SyncOrbit/Sol:Earth:IRIDIUM 10 [+]/2009-01-22T10:43:51.14866?x=QWmWyi0&y=2rmMEbj//////////////w&z=4rK8vFY&ow=-0.847687&ox=0.439803&oy=0.0260162&oz=0.295506&select=Sol:Earth:FENGYUN 1C DEB&fov=36.2777&ts=1&ltd=0&p=1&rf=121495&lm=32768&tsrc=0&ver=3

(the embedded spaces are also an issue but that's solvable by substituting '%20', however the "&select=Sol:Earth:FENGYUN 1C DEB" part causes problems, I would guess because the celURL can't decide which of the 2000 odd objects to use.

I don't know what the solution to this is -- you might have to discuss with Chris. One possible solution could be to use the NORAD-ID as the primary identifier for these particular objects in order to ensure that each object has a unique ID (There seems to be a number of issues caused by non-unique ID''s).

CC

[Chuft-Captain]

Thanks Chuft,
I am removing some duplictaes already. These are slipping through because the names "CO-55" and "CO-55 [+]" are not exactly the same. I take it that I should ignore the [+] and [-] text decorations in the names. Can you tell me what they mean though? I also see [P], [B], [S], [TETHERED] and [TOOLBAG].

- Jeff

I forgot to mention that some or all of these 4 characters: [+]- also cause celURL's to fail. (FYI: I note that these three characters are also meaningful tokens in the SSC parser -- Whether that's the reason I leave as an exercise for you ).

[LordFerret]

About [TETHERED], there were a number of tethered satellite experiments. Most notable I think would be the TSS-1 and TSS-1R projects carried out on shuttle missions (STS-46 and STS-75), although the only existing "tether" currently still in orbit belongs to the MAST nano-satellite experiment... which is confusing when trying to research it because MAST also stands for the Mass Spectrometer Telescope onboard the (SAMPEX) satellite.

Some information on the MAST nano-satellite experiment: http://www.tethers.com/papers/MASTJPC2003Paper.pdf

[jdavies]

Thanks for the updates, Chuft and Lord Ferret. The TETHERED thing is interesting. I do remember hearing a bit about it in the late 70's but I'd forgotten all about it since then.

I have improved the code so that it now uses the NORAD ID to ensure the uniqueness of each satellite record. I have also updated the SSC file that I distribute (for those of you that aren't running the StarBridge code yourselves) at http://jeffdavies.org/starbridge. You can get the information in SSC form and as a comma-separated value file for use in Excel if you like.

As for the troubles with the Celestia URL, I'll look into that. Is it acceptable to just get rid of the [+] (and releated) notation? Would removing that in turn "break" the satellite data for anyone else? Since Chuft is the primary consumer of this information at the moment (at least he's the only one talking with me about it) I'm inclined to make modifications that he asks for. I just want to double-check and ensure that this wont be a problem for anyone else first.

If you ARE using the StarBridge application, note that I have not released the version that fixes the problems found in v0.6.0 yet. The next release (v0.7.0) will occur this coming week or on the weekend at the latest. Chuft has been working with me to help ensure that the data generated is as accurate as possible (Thanks Chuft!). After this release, I'm going to focus more on improving the graphical user interface of the application and adding similar update support for exo-planets (i.e. StarBridge will search the net to find information on new exoplanets for you).

- Jeff

[Chuft-Captain]

I have improved the code so that it now uses the NORAD ID to ensure the uniqueness of each satellite record.

I assume you mean to do this for the FENGYUN Debris only???
eg. "FENGYUN 1C : NORAD 25730..."
--> "FENGYUN-1C-25730 : NORAD 25730..."
Note that I have substituted "-" for whitespace as well.

As for the troubles with the Celestia URL, I'll look into that. Is it acceptable to just get rid of the [+] (and releated) notation?

FWIW, I've done quick test by modifying:
1. IRIDIUM 10 [+] satellite - removed the "[+]" and substituted hyphens for whitespace so that it is now: "IRIDIUM-10".
2. FENGYUN 1C : NORAD 25730 becomes "FENGYUN-1C-25730 : NORAD 25730..." (as above)

The following celURL was then captured and works perfectly:
cel://PhaseLock/Sol:Earth:IRIDIUM-10/So ... rc=0&ver=3

[jdavies]

Chuft,
I'll make the name changes for the FENGYUN 1C DEB entries for the next release. I'll let you know when I have updated the sample SSC file on the website. As for removing the [+] and related symbols, can you tell me why you want them removed? Is it purely for creating the cel: URL? I have the same question about the whitespace change to dashes. If you are trying to create a URL friendly string, I might have other suggestions for you. How are you creating these URLs now? Are you using a scripting language?

- Jeff

[Chuft-Captain]

...As for removing the [+] and related symbols, can you tell me why you want them removed? Is it purely for creating the cel: URL? I have the same question about the whitespace change to dashes. If you are trying to create a URL friendly string, I might have other suggestions for you. How are you creating these URLs now? Are you using a scripting language?

- Jeff

Jeff,
Sorry, I'm not creating celURL strings. I assumed you were familiar with the concept of a celURL in Celestia: http://en.wikibooks.org/wiki/Celestia/Bookmarks

[+] and related symbols appear to invalidate celURL's created in Celestia (using ctrl-C or ctrl-INSERT) in the same way that whitespace does (the whitespace issue has been around forever). Try yourself by following one of these satellites, and then hitting ctrl-C. Paste into a draft post or a basic webpage and then click on it. You'll see that it's broken wherever these characters occur.

As I've explained in PM to you, I believe this is to do with the way Celestia creates celURL's which contain references to objects containing these literals.
I suspect that the code responsible for creating the celURL is possibly making use of some SSC-parser methods, and as some of these characters are meaningful as tokens to the SSC-parser this is the source of the problem. That's just a guess though, as I haven't examined the code.
This is possibly something that could be improved in the relevant Celestia C++ code, and it's probably an easy fix, but in the absence of a fix, in the short term it might be prudent to avoid using problematic literals in object names, so that users creating celURL's with your addons don't have these issues with celURL's. That's all I was suggesting.

Of course the better solution is to fix Celestia's celURL creation code to handle both whitespace and special characters in a better fashion.

I hope this makes sense.

CC

[chris]

The following patch should fix the problem with encoding of cel URLs:

http://www.celestiaproject.net/~claurel/celest ... code.patch

And an encoded URL example:

cel://Follow/Milky%20Way/2009-03-17T01: ... rc=0&ver=3

--Chris

[Chuft-Captain]

Thanks Chris,

I can test this, but unfortunately I'm not set up to make my own builds.
Does anyone have a recent build including this patch? I'm not sure if this was fixed prior to Cartrite's last build.

Cheers
CC

[selden]

Guillermo Abramson is now providing v1.6 executables for Windows. See
viewtopic.php?f=2&t=13601&p=113694#p113694

[duds26]

CC,
Wow, give me some time to get my head wrapped around all of that. It looks very interesting.

Duds,
As for creating custom groups I was thinking of defining them in an XML file so we get an easy way to manage hierarchies of groups. Ultimately I could provide a GUI editor for those grouping files, but to start it would be manual. However, I think the structure of the file is pretty simple. Here is the format I'm thinking of. Please let me know what you think about it.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<SatGroup name="My Custom Group" xmlns="http://jeffdavies.org/starbridge/satgroup">
   <group name="Favorites">
      <selector name="GPS" expression="^GEOS" />
      <selector name="Intl. Space Station" expression="^ISS" />
   </group>
   <group name="Debris">
      <selector name="All debris" expression="[.]*DEB[.]*" />
      <group name="COSMOS">
         <selector name="COSMOS Debris" expression="^COSMOS[.]*DEB[.]*" />
      </group>
   </group>
</SatGroup>

This would be presented to the user in the GUI using a Tree control of checkboxes. You could then select the everything, any of the lower level group names or even specific selectors. I hope my description is adequate. I haven't taken the time to write any sample code for a screenshot yet.

- Jeff

This is a really nice way to be able to write stuff.
It would be nice to see some parameters like:
heavier than 1Tons,
further than 1000km
further than 4000km
further than 200000km:
Something like this it would become I think:

Code: Select all

<SatGroup name = "physical ordering example">
<group name = "physical ordering">
       <group name = "weight ordering">
       <selector name = "heavier than 1 Ton" parameter name ="weight" parameter value = "> 1000kg">
       </group>

       <group name = "distance from body">
               <selector name = "further than 1000km" parameter name ="distance from body" parameter expression =
               "> 1000km">
               <selector name = "further than 4000km" parameter name ="distance from body" parameter expression =
               "> 4000km">
               <selector name = "further than 200000km" parameter name ="distance from body" parameter expression =
               "> 200000km">
       </group>
</SatGroup>