Thread: [Celestia-developers] Long/Lat
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Grant H. <gra...@bl...> - 2003-06-18 00:13:06
|
Chris: > (Didn't mean to leave you out Grant, but I don't know what your hometown > is :) ) Location "Dundee" "Sol/Earth" { LongLat [ -3.0 56.5 0 ] } > I tried to add a location for Tycho on > the Moon and could not properly place it. That's odd - I can easily position myself above it with Goto Object. Should be longitude -11.1, latitude -43.4. > ... as the > IAU has been inconsistent in defining longitude and latitude within the > solar system. Not sure why you should think that - they're very keen on a consistent approach, though others involved in planetary mapping seem to play fast and loose with the rules. East and west longitude up to 180 degrees are used together on *only* the Earth and the Moon.Otherwise direct rotators use west longitude to 360 degrees, and retrograde rotators use east longitude to 360 degrees - all north poles defined as being to the rotation pole lying north of the ecliptic plane. (Unfortunately, the USGS recently instituted an east longitude system for Mars, and the IAU have grudgingly produced a second feature listing using this system, although the west longitude system is still in use, and for consistency with what goes below might be the dataset to choose.) The IAU convention has to be translated into Celestia bearing in mind that: 1) The north pole definition in Celestia is rotational, rather than ecliptic 2) There is an inconsistency in Celestia's treatment of 3ds objects - the longitude is 180 degrees out of alignment. I've taken this into account when setting RotationOffsets, but it becomes evident when using Goto Object, and I assume will be evident when setting locations. So for Celestia the rules of interpretation of IAU coordinates should work like this: On the Earth and Moon: East longitude is positive, west is negative. North is positive, south is negative. Elsewhere in the Solar System 1) If the object is a 3ds object add 180 degrees to longitude (whether E or W) and then make it negative else make the longitude (whether E or W) negative 2) If longitude is given in degrees west make north latitude positive, south negative. elseif longitude is given in degrees east make north latitude negative, south positive. I've checked this algorithm against IAU coordinates and westgrid/eastgrid textures, with examples of various kinds of body. It seems to work fine with all four combinations: simple direct rotators (Mercury), simple retrograde rotators (Venus), 3ds direct rotators (Phobos) and 3ds retrograde rotators (Ida). Further thoughts: 1) It would be nice if the 3ds inconsistency could be rooted out at some deeper level (without disturbing the way the 3ds models accept textures, which is nicely consistent!) - I'd then run through solarsys.ssc and remove the jigger factors on the various RotationOffsets. 2) It would also be nice if Goto Object required a specification of east or west longitude, rather than defaulting to the rather Terra-centric east-positive convention. This would also allow the algorithm above to run in the background in Goto Object, appropriately flipping the north and south coordinates to make them consistent with Celestia's rotational north convention. Grant |
From: Chris L. <cl...@ww...> - 2003-06-18 18:30:03
Attachments:
locations.ssc
|
On Wed, 18 Jun 2003, Grant Hutchison wrote: > Chris: > > (Didn't mean to leave you out Grant, but I don't know what your hometown > > is :) ) > > Location "Dundee" "Sol/Earth" > { > LongLat [ -3.0 56.5 0 ] > } > > > I tried to add a location for Tycho on > > the Moon and could not properly place it. > That's odd - I can easily position myself above it with Goto Object. Should > be longitude -11.1, latitude -43.4. It turned out that I had the longitude and latitude swapped . . . When I switched them, the label was in the correct place. Oops. > > > ... as the > > IAU has been inconsistent in defining longitude and latitude within the > > solar system. > Not sure why you should think that - they're very keen on a consistent > approach, though others involved in planetary mapping seem to play fast and > loose with the rules. > East and west longitude up to 180 degrees are used together on *only* the > Earth and the Moon.Otherwise direct rotators use west longitude to 360 > degrees, and retrograde rotators use east longitude to 360 degrees - all > north poles defined as being to the rotation pole lying north of the > ecliptic plane. (Unfortunately, the USGS recently instituted an east > longitude system for Mars, and the IAU have grudgingly produced a second > feature listing using this system, although the west longitude system is > still in use, and for consistency with what goes below might be the dataset > to choose.) So why did the USGS institude the east longitude system for Mars? I recall something about that being the system used for the MOLA data. > The IAU convention has to be translated into Celestia bearing in mind that: > 1) The north pole definition in Celestia is rotational, rather than ecliptic > 2) There is an inconsistency in Celestia's treatment of 3ds objects - the > longitude is 180 degrees out of alignment. I've taken this into account when > setting RotationOffsets, but it becomes evident when using Goto Object, and > I assume will be evident when setting locations. Are 3DS models in Celestia actually getting rotated 180 degrees? Or is it just that the asteroid models were created in the wrong orientation? > > So for Celestia the rules of interpretation of IAU coordinates should work > like this: > On the Earth and Moon: > East longitude is positive, west is negative. North is positive, south is > negative. > > Elsewhere in the Solar System > 1) If the object is a 3ds object > add 180 degrees to longitude (whether E or W) and then make it > negative > else > make the longitude (whether E or W) negative > > 2) If longitude is given in degrees west > make north latitude positive, south negative. > elseif longitude is given in degrees east > make north latitude negative, south positive. > > I've checked this algorithm against IAU coordinates and westgrid/eastgrid > textures, with examples of various kinds of body. It seems to work fine with > all four combinations: simple direct rotators (Mercury), simple retrograde > rotators (Venus), 3ds direct rotators (Phobos) and 3ds retrograde rotators > (Ida). > > Further thoughts: > 1) It would be nice if the 3ds inconsistency could be rooted out at some > deeper level (without disturbing the way the 3ds models accept textures, > which is nicely consistent!) - I'd then run through solarsys.ssc and remove > the jigger factors on the various RotationOffsets. I'll take a look at the 3DS code and try to figure out what's going on, though I still think that it may be the models themselves that need to be corrected. > 2) It would also be nice if Goto Object required a specification of east or > west longitude, rather than defaulting to the rather Terra-centric > east-positive convention. This would also allow the algorithm above to run > in the background in Goto Object, appropriately flipping the north and south > coordinates to make them consistent with Celestia's rotational north > convention. I look into doing this . . . It would also be a good idea to support east and west longitudes in .ssc files, e.g. LongLat "102E -32S" Such a syntax would have prevented me from making the longitude/latitude swapping error I mentioned before. I've added two additional fields to locations: Size and Importance. Size is the diameter of the feature. Importance is the effective diameter of the feature used when deciding whether or not to render a label. By default, importance is -1, meaning that the real size should be used. Importance should be used for things like major cities that might be physically quite small but should be labelled anyhow. The renderer now has methods to get and set the minimum feature size. The minimum size is the width in pixels that a feature must cover before its label is rendered. By defult it's set to 10, and there's currently no way to adjust it from the UI. I bound & to toggle location labels--no it's not mnemonic [insert usual rant about needing to figure out a better system for key bindings] Finer grained control over which feature types to render will require some GUI work. Grant, if you're interested in playing with locations, I built a new EXE: http://www.shatters.net/~claurel/celestia/files/celestia-win32-1.3.1pre5-exe.zip The attached .ssc file contains some more sample locations. --Chris |
From: Grant H. <gra...@bl...> - 2003-06-18 23:52:47
|
Chris: > Are 3DS models in Celestia actually getting rotated 180 degrees? Or is it > just that the asteroid models were created in the wrong orientation? Yes, you're right, this is the nub of the problem - it so happens that the majority of models have been created with an orientation that is misaligned in longitude for our purposes. Adjusting Orientation in the ssc seems like the best solution - the model is imported, Orientation is used to fix latitude and longitude, and then we can use consistent rules to seek particular coordinates or to position prime meridians, provided that the damn things aren't overtly inside-out. I'm keen to make a minor rewrite of solarsys.ssc to implement this, if everyone's happy. That would reduce the problem of latitude/longitude-finding to simply spotting the pole orientation, and would allow r a consistent algorithm for the calculation of RotationOffset. I'm still distinctly hazy on what happens to axes when 3ds models are imported to Celestia. I've just been writing some code to help Selden and others get their dsc billboards correctly orientated using Axis and Angle, without their current trial-and-error approach. The rotation matrices have come out right in the end, but it required some experimentation to find out what the axes are. What Selden calls the z-axis in his models seems to be the negative y-axis in Celestia ... > So why did the USGS institude the east longitude system for Mars? It dates to 2002 and MOLA. I can imagine a very large amount of data being compiled in an office at the USGS before anyone noticed the mismatch. It's just another "are these foot-pounds or newtons, oops where's the satellite?" sort of problem. Grant |
From: Hank R. <hr...@qw...> - 2003-06-19 00:54:32
|
On Wednesday, June 18, 2003, at 04:52 PM, Grant Hutchison wrote: > >> So why did the USGS institude the east longitude system for Mars? > It dates to 2002 and MOLA. I can imagine a very large amount of data > being > compiled in an office at the USGS before anyone noticed the mismatch. > It's > just another "are these foot-pounds or newtons, oops where's the > satellite?" > sort of problem. > > Grant > My impression is that the preference for planetocentric coordinates has more to do with the latitude definition than with the longitude direction. Technically, planetocentric coordinates define latitude as the angle between the equatorial plane and a line thru the center of the body, whereas planetographic coordinates define latitude as the angle between the equatorial plane and a line normal to the ellipsoid. The maximum difference between the two types of latitude on Mars is about 0.3 degree. Here's a link to a discussion of the issue in a letter from Randy Kirk of the USGS Astrogeology Team: http://www.msss.com/mgcwg/mgm/kirk_letter.html#a And here's a link to a dissenting opinion from Mike Malin, Principal Investigator for the Mars Orbiter Camera (MOC) on the Mars Global Surveyor (MGS) spacecraft: http://www.msss.com/mgcwg/mgm/letter.txt Also, note that planetographic coordinates use west longitude only for objects with direct rotation. East longitude is used for objects with retrograde rotation. - Hank |
From: Grant H. <gra...@bl...> - 2003-06-19 08:55:41
|
Hank: > My impression is that the preference for planetocentric coordinates has > more to do with the latitude definition than with the longitude > direction. Thanks for the links. The odd thing is that there's no particular reason to link planetocentric/planetographic latitude with a particular choice of longitude measurement. Seems like the east/centric west/graphic divide started life as some sort of mnemonic convention, which is now messing with the east/retrograde west/direct convention of the IAU. But it's nice to see that at least some communication took place between advocates of the two systems. (Me, I'd prefer centric-west, but introducing a third system would be just plain crazy ...) Grant |
From: Hank R. <hr...@qw...> - 2003-06-19 15:40:37
|
Grant, I think the key here is that the planetocentric coordinate system is simply a right-handed spherical-polar coordinate system. So it's consistent with the standard for 3-D coordinate geometry calculations. The right-hand rule dictates that since latitude is positive North (a Eurocentric convention, of course), then longitude is positive East. The planetographic coordinate system seems to be oriented toward convenience in observation. Latitude is based on the local vertical rather than the body center because that's what can be easily measured (on Earth). Longitude direction is based on the principle that its value always increases with time (for a fixed observer), which simplifies the determination of the observed central meridian for a planet as viewed from Earth. - Hank On Thursday, June 19, 2003, at 01:55 AM, Grant Hutchison wrote: > Hank: >> My impression is that the preference for planetocentric coordinates >> has >> more to do with the latitude definition than with the longitude >> direction. > Thanks for the links. The odd thing is that there's no particular > reason to > link planetocentric/planetographic latitude with a particular choice of > longitude measurement. Seems like the east/centric west/graphic divide > started life as some sort of mnemonic convention, which is now messing > with > the east/retrograde west/direct convention of the IAU. But it's nice > to see > that at least some communication took place between advocates of the > two > systems. > (Me, I'd prefer centric-west, but introducing a third system would be > just > plain crazy ...) > > Grant > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting > Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly > Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Fridger S. <t0...@ma...> - 2003-06-19 18:58:15
|
Grant: just a few "non-serious" remarks related to "locations;-) > Location "Dundee" "Sol/Earth" > { > LongLat [ -3.0 56.5 0 ] > } 1) Note the remarkable triangle configuration: Dundee-Hamburg-Lyon...;-). 2) You beat me by 3 degrees in NLatitude, too bad... 3) Our daughter was born "around the corner" from Dundee. She is a real "Geordie", born in Newcastle/Tyne, while we visited Durham Univ. as guest Profs for 1/2 year...thus a "British subject" by passport. Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-06-19 22:08:35
Attachments:
earth.loc.zip
|
Hi all, I have hacked another Perl script (extract.pl) that converts the latest XEphem locations list (xephem-3.6pre.sit) [that Elwood Downey allowed us to use with the 'boilerplate' I have generated] to the actual Celestia locations format (earth.ssc). The deg:min:sec coordinates are converted to high accuracy degrees (4 decimal places) as needed for precise event timings etc. It's fun to watch the names superimposed on the 'nightlights' texture... Lots of observatories in exotic places... Just drop earth.ssc into extras. I have attached also the Perl script and the XEphem list, so everyone may adapt the output to future changes. Sorry Grant, Christophe, Dundee and Lyon are missing;-). So you got to live with 'low accuracy' for a while... Bye Fridger PS: The text files have UNIX-style line endings...but I guess all Windows fans have a converter ready. |
From: Grant H. <gra...@bl...> - 2003-06-20 23:04:34
|
Fridger: > Sorry Grant, Christophe, Dundee and Lyon are missing;-). So you got to live > with 'low accuracy' for a while... Well, I don't know about Hamburg, but Dundee and Lyon are sufficiently big that one-metre accuracy seems ... spurious ;-) But DeLorme's EarthA atlas software centres Lyon at LongLat [4.850 45.754 0]. And I happen to know that I'm sitting a few metres north of LongLat [-3.0046 56.4589 0]. BTW: I noticed a number of errors in your earth.ssc, just by spotting a few names in improbable places. Hanging Rock seems to be in open ocean, although I realise that the nearby KHBI is probably on Saipan island. Monte Alban in Mexico is sitting on the equator because its Latitude has been entered as "0.". Someone in Mexico does seem to have made a considerable hash of data entry - Oaxaca, Metapec and Puebla are all placed in Antarctic, because Lat and Long have been reversed and the decimal point has been misplaced in the Latitude figure. Grant |
From: Fridger S. <t0...@ma...> - 2003-06-21 16:18:42
Attachments:
earth.loc-1.1.zip
|
Grant: > > Sorry Grant, Christophe, Dundee and Lyon are missing;-). So you got to > live > > with 'low accuracy' for a while... > Well, I don't know about Hamburg, but Dundee and Lyon are sufficiently big > that one-metre accuracy seems ... spurious ;-) Well....you might have anticipated that this sort of argument has also crossed my mind before;-). In fact, the vast majority of the LongLat references in the XEphem list are precise positions of /observatories/ and other distinguished research institutions (including of course the city major's toilet;-)). It is meant to be a list like the one in the annual "Astronomical Ephemeris/Almanac" that all of us presumably own. In any case, the /final/ aim would be to set up a list of such (identified!) locations that are accurate enough as references for occultation predictions, for example. In that context, the astronomical Almanac also contains a list of /standardized/ city positions. > But DeLorme's EarthA atlas software centres Lyon at LongLat [4.850 45.754 > 0]. And I happen to know that I'm sitting a few metres north of LongLat > [-3.0046 56.4589 0]. OK, my attached revised earth.ssc contains the positions both of Dundee and Lyon as quoted. For Dundee, I would have a slight preference to use the position of Mills Observatory: (-3 d 00' 42", 56 d 27' 54.2" ) instead of your personal GPS output...;-) > > BTW: I noticed a number of errors in your earth.ssc, just by spotting a few > names in improbable places. > Hanging Rock seems to be in open ocean, although I realise that the nearby > KHBI is probably on Saipan island. Monte Alban in Mexico is sitting on the > equator because its Latitude has been entered as "0.". Someone in Mexico > does seem to have made a considerable hash of data entry - Oaxaca, Metapec > and Puebla are all placed in Antarctic, because Lat and Long have been > reversed and the decimal point has been misplaced in the Latitude figure. > Sorry for that. The errors arose /not/ because of typos in the original xephem list, but due to a /single/ tricky notational exception that was not accounted for by my pattern-matching regular expression in the Perl conversion script! There were /exactly/ 5 such exceptions that you apparently have /all/ spotted: CONGRATULATIONS;-)...quite a good record, indeed. It seems you have a very founded knowledge of this world's geography... Attached is the revised (1.1) Perl-script, the original xephem list and the new 'earth.ssc' output for the extras directory. I have improved the naming conventions quite a bit in the course of the conversion. Moreover, I decreased the 'importance' parameter from 100 for cities to 40 for isolated observational spots. So you have to approach somewhat closer to see the labels of the latter. This makes the city label display less crowded at larger distances. Have a look: "...getting ready for a new night of southern observing..." http://www.shatters.net/~t00fri/images/andes-obs.jpg After moving to a somewhat larger distance only 'Santiago' remains. Bye Fridger PS: I guess you are aware that if in the location .ssc files the 'Importance' parameter is present and has a non-negative value, it is used as a display criterion instead of the Size parameter. (Importance = -1.0f, if not set explicity). |
From: Grant H. <gra...@bl...> - 2003-06-21 17:18:18
|
Fridger: > OK, my attached revised earth.ssc contains the positions both of Dundee and > Lyon as quoted. For Dundee, I would have a slight preference to use the > position of Mills Observatory: (-3 d 00' 42", 56 d 27' 54.2" ) instead of your > personal GPS output...;-) Fair enough. The difference is less than a kilometre- it's on the hill behind my house. > PS: I guess you are aware that if in the location .ssc files the 'Importance' > parameter is present and has a non-negative value, it is used as a display > criterion instead of the Size parameter. (Importance = -1.0f, if not set > explicity). I didn't, thanks. It could solve the problem of the "Size 0" objects. Grant |