IPB

Welcome Guest ( Log In | Register )

7 Pages V  « < 2 3 4 5 6 > »   
Reply to this topicStart new topic
March 15, 2010 PDS release
elakdawalla
post Mar 18 2010, 05:27 AM
Post #46


Administrator
****

Group: Admin
Posts: 5172
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



With such a short time between the spacecraft's arrival and the release of all these data, I'm not surprised that there are issues with metadata. There should be contact information for each data set, or, failing that, there is certainly a contact listed for the PDS Node(s) hosting each data set. If you notify them (politely) of issues, being specific about both problem and solution, I am sure you will get a response, and you'll help everyone out.


--------------------
My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
JohnVV
post Mar 18 2010, 05:34 AM
Post #47


Member
***

Group: Members
Posts: 890
Joined: 18-November 08
Member No.: 4489



I'm not surprised ether for the LRO lola it is
http://imbrium.mit.edu/
http://imbrium.mit.edu/DATA/LOLA_GDR/
lolahelp{at}gmail{dot}com
Go to the top of the page
 
+Quote Post
elakdawalla
post Mar 18 2010, 05:37 AM
Post #48


Administrator
****

Group: Admin
Posts: 5172
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



(Also I feel like I should point out that there is a very helpful member of the LOLA team who has been posting lots of useful info IN THIS THREAD. Scroll up.)


--------------------
My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
Ittiz
post Mar 18 2010, 12:09 PM
Post #49


Newbie
*

Group: Members
Posts: 9
Joined: 17-March 10
Member No.: 5271



I've noticed some issues at the left and right edges of LDEM_64. When you rotate it 180 degrees you can see what I mean. Especially on the craters. Here is a pic of what I'm talking about:

Go to the top of the page
 
+Quote Post
djellison
post Mar 18 2010, 12:35 PM
Post #50


Founder
****

Group: Chairman
Posts: 14431
Joined: 8-February 04
Member No.: 1



Yup - I found that as well - it's missing a few degrees somehow.
Go to the top of the page
 
+Quote Post
Ittiz
post Mar 18 2010, 01:21 PM
Post #51


Newbie
*

Group: Members
Posts: 9
Joined: 17-March 10
Member No.: 5271



QUOTE (djellison @ Mar 18 2010, 07:35 AM) *
Yup - I found that as well - it's missing a few degrees somehow.

I think the problem is that the data points are interpolated there at the edges, but not across the edge. If you get what I mean. So when they interpolated the missing data, near by data points weren't taken into consideration since they were at the other side of the image. That's my theory anyway tongue.gif
Go to the top of the page
 
+Quote Post
djellison
post Mar 18 2010, 01:34 PM
Post #52


Founder
****

Group: Chairman
Posts: 14431
Joined: 8-February 04
Member No.: 1



FWIW - IMG2PNG does work with the IMG's for me - but it's got a signed-problem I think.
Attached thumbnail(s)
Attached Image
 
Go to the top of the page
 
+Quote Post
Ittiz
post Mar 18 2010, 02:15 PM
Post #53


Newbie
*

Group: Members
Posts: 9
Joined: 17-March 10
Member No.: 5271



I got the same problem opening it in Photoshop (it doesn't allow you to select signed or unsigned). I fixed it by adjusting the output and input levels to move the bright colors down and the dark colors up.
Go to the top of the page
 
+Quote Post
zeBeamer
post Mar 18 2010, 02:36 PM
Post #54


Junior Member
**

Group: Members
Posts: 22
Joined: 20-June 09
Member No.: 4830



QUOTE (JohnVV @ Mar 17 2010, 11:25 PM) *
all of the lbl's are F-'ed up ( this is NOT an exaggeration)

the headers state 3 different bit formats and as 16 bit
the IMG files ARE 32 bit
however ther really are 16 bit images saved as 32 bit ???
also the "SCALING_FACTOR" and "OFFSET" are off
yes this is messed up

John...
as I noted earlier in response to mhoward, there was an issue with the cylindrical IMGs being unsigned instead of signed. This was corrected. Did you see that, and are talking about the IMGs currently on the website?

QUOTE (JohnVV @ Mar 17 2010, 11:25 PM) *
however you will find that in isis the map projection is off .It is in sym cyl BUT the lat/long are way off
you will need to run maplab on it

I personally haven't tried with the IMGs, but the JP2s seem fine when overlaid over a Clementine basemap. What do you mean by "way off" ?

Erwan
Go to the top of the page
 
+Quote Post
JohnVV
post Mar 18 2010, 06:50 PM
Post #55


Member
***

Group: Members
Posts: 890
Joined: 18-November 08
Member No.: 4489



Did you see that, and are talking about the IMGs currently on the website?

yes but i still have not talked to them .
I still need to re check
the "signed" problem is that the is the 32/16 bit issue and the offset that is listed it the .LBL
example the 4 px/deg
------------
SCALING_FACTOR = 0.5
OFFSET = 1728216.

----- and -----
SAMPLE_TYPE = LSB_UNSIGNED_INTEGER
SAMPLE_BITS = 16
-------------------
QUOTE
I personally haven't tried with the IMGs, but the JP2s seem fine when overlaid over a Clementine basemap. What do you mean by "way off" ?

the map is in positave east and 360
with the left 0 and right 360

BUT
qview and map2map see it is
the left north( 90lat 0long) as 0 lat and 180 long
and sees the middle pixel ( o lat 180long) and -90 and 360
only the north west 1/4 has map info

this is mostlikely do to the pixel values from 32 bit and 16 bit
Go to the top of the page
 
+Quote Post
Jim Mosher
post Mar 18 2010, 06:56 PM
Post #56


Newbie
*

Group: Members
Posts: 8
Joined: 19-November 09
Member No.: 5052



Erwan,

I don't think there are any major problems with the most recent *.LBL files, but I wonder if it would be possible to upload copies of "LDEM_4.LBL" and "LDEM_16.LBL" with the "OFFSET" parameter in "OBJECT = IMAGE" corrected to "1737400." <meters>? The text description implies this is the offset used for forming the signed integers, but it is correctly listed on the machine-readable "OFFSET" line only in "LDEM_64.LBL". The other two *.LBL files, as John points out, give "1728216.", a number which may never have been correct.

This may seem a very insignificant point -- since users can easily hand-edit these text files -- but I was writing directions on how to use the LOLA data with a program that automatically reads the *.LBL files associated with the *.IMG files, and this seems to add an unnecessary level of complication and confusion.

In LDEM_16.IMG, assuming the 0.5 m per count scaling and 1737.400 km reference radius are correct, I find minimum and maximum data values of -9.047 km (at line 2566, sample 3001) and +10.614 km (at line 1354, sample 3221); a slightly smaller range, so far, than the Kaguya values of -9.140 km and +10.716 at nearly the same positions in their 16 samples per degree grid. This would correspond to a LOLA height range, from the Moon's center, of 1724.953 (minimum) to 1744.614 km (maximum). Is that correct?

Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

One other very minor point: the *.LBL files say your grid is reported in the "MEAN EARTH/POLAR AXIS OF DE421" coordinate system. To the best of my knowledge, the Moon's Mean Earth/Polar Axis system is offset from the JPL DE421 ephemeris system by small rotations about each axis. Did you apply those corrections? If so, did you use the rotations recommended in the "IAU/IAG Working Group on Cartographic Coordinates" reports of Seidelmann et al. or some other ones?

Finally, although I find nothing materially wrong with the *.LBL files, I find the references to "planetopotential TOPOGRAPHY" and "GEOID" in the explanation of the data format slightly confusing. As I understand the explanation, the data represent "PLANETARY_RADIUS" rather than "planetopotential TOPOGRAPHY", and since no geoid is defined, and no correction for it required to use the data, the references to this additional computation seem unnecessary?

-- Jim Mosher
Go to the top of the page
 
+Quote Post
elakdawalla
post Mar 18 2010, 09:03 PM
Post #57


Administrator
****

Group: Admin
Posts: 5172
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



QUOTE (Jim Mosher @ Mar 18 2010, 10:56 AM) *
Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

For what it's worth, I witnessed at LPSC an interesting interaction between a member of the LOLA team and a Chinese scientist on this subject that would be relevant here. The Chinese scientist was quizzing the LOLA team member on their tracking methods, and during his response the LOLA team member expressed frustration that only NASA was providing, as part of their data release, the tracking data on the spacecraft. Without tracking data I think it would be impossible to integrate LOLA data with Kaguya LALT or Chang'E topographic data. It may even be very hard to do so with the tracking data; I don't know. But I think it's impossible unless JAXA or China choose to provide that data, along with less-derived data products.


--------------------
My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
JohnVV
post Mar 18 2010, 11:03 PM
Post #58


Member
***

Group: Members
Posts: 890
Joined: 18-November 08
Member No.: 4489



Ittiz

on almost all ( blue marble is an exception) maps there is a bit of a mis-match ether at the 0- 360 ( or -180 to 180 )

i have yet to see one that in not .
Go to the top of the page
 
+Quote Post
zeBeamer
post Mar 19 2010, 02:09 AM
Post #59


Junior Member
**

Group: Members
Posts: 22
Joined: 20-June 09
Member No.: 4830



John,

Nothing is 32bit except the GRDs.



Jim,

QUOTE (Jim Mosher @ Mar 18 2010, 01:56 PM) *
I don't think there are any major problems with the most recent *.LBL files, but I wonder if it would be possible to upload copies of "LDEM_4.LBL" and "LDEM_16.LBL" with the "OFFSET" parameter in "OBJECT = IMAGE" corrected to "1737400." <meters>? The text description implies this is the offset used for forming the signed integers, but it is correctly listed on the machine-readable "OFFSET" line only in "LDEM_64.LBL". The other two *.LBL files, as John points out, give "1728216.", a number which may never have been correct.

This seems sensible. I will double-check tomorrow and correct it.
We are working on improving the labels in general. Very soon you'll have one label file per product format (jp2,img,grd).
Bottom line, I think LDEM_64.LBL is correct.


QUOTE (Jim Mosher @ Mar 18 2010, 01:56 PM) *
This may seem a very insignificant point -- since users can easily hand-edit these text files -- but I was writing directions on how to use the LOLA data with a program that automatically reads the *.LBL files associated with the *.IMG files, and this seems to add an unnecessary level of complication and confusion.

Good to see people integrating the data in their program already wink.gif
On that website you say "Nonetheless, LOLA gridded data covering the period 2009-07-13 through 2009-12-17 are (unofficially?) available on an MIT website." Actually, this MIT website is the official LOLA PDS data node. PDS archives/mirrors it.

QUOTE (Jim Mosher @ Mar 18 2010, 01:56 PM) *
Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

Emily is perfectly correct in her post. We don't want to take the Kaguya data at face value (even though they've done a good job) and simply put them in. The LOLA data are geolocated based on LRO orbit solutions, which we understand and are working on improving... And with time, we'll cover (very close) to those Kaguya tracks.

QUOTE (Jim Mosher @ Mar 18 2010, 01:56 PM) *
One other very minor point: the *.LBL files say your grid is reported in the "MEAN EARTH/POLAR AXIS OF DE421" coordinate system. To the best of my knowledge, the Moon's Mean Earth/Polar Axis system is offset from the JPL DE421 ephemeris system by small rotations about each axis. Did you apply those corrections? If so, did you use the rotations recommended in the "IAU/IAG Working Group on Cartographic Coordinates" reports of Seidelmann et al. or some other ones?

I think all your answers will be found in :
ftp://naif.jpl.nasa.gov/pub/naif/generic_...orientation.pdf
If you're familiar with SPICE, basically, in addition to using the "de421.bsp" kernel, we also load the following kernels, which define the "MOON_ME" frame.
moon_pa_de421_1900-2050.bpc, moon_080317.tf, moon_assoc_me.tf, also available from the NAIF website.

QUOTE (Jim Mosher @ Mar 18 2010, 01:56 PM) *
Finally, although I find nothing materially wrong with the *.LBL files, I find the references to "planetopotential TOPOGRAPHY" and "GEOID" in the explanation of the data format slightly confusing. As I understand the explanation, the data represent "PLANETARY_RADIUS" rather than "planetopotential TOPOGRAPHY", and since no geoid is defined, and no correction for it required to use the data, the references to this additional computation seem unnecessary?

well, you can see that as superficial; but it's just recalling what is in this dataset, so that people know it's not geoid-related ("huge discovery: lava flows going uphill!"). We may release planetopotential topography grids in the future. Plus, in the RDRs, the geoid value at each LOLA point is defined.


Erwan
Go to the top of the page
 
+Quote Post
Jim Mosher
post Mar 19 2010, 03:37 AM
Post #60


Newbie
*

Group: Members
Posts: 8
Joined: 19-November 09
Member No.: 5052



QUOTE (zeBeamer @ Mar 19 2010, 03:09 AM) *
On that website you say "Nonetheless, LOLA gridded data covering the period 2009-07-13 through 2009-12-17 are (unofficially?) available on an MIT website." Actually, this MIT website is the official LOLA PDS node. PDS archives/mirrors it.


Thanks, Erwan! I have corrected my information. Thanks for your other answers, as well.

-- Jim
Go to the top of the page
 
+Quote Post

7 Pages V  « < 2 3 4 5 6 > » 
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 28th March 2024 - 04:35 PM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member.