Last updated: 03/02/2004 05:56 PM
| Number |
Priority |
Status |
From |
Issue |
| 1 | 2 | RTT
- descriptions should work for all targets
Tested (R) 1/20/04 |
T | Target description seems to be just free text for solar system targets. Handle that properly. Also for ss targets, the Keyword: isn’t set. Is this just the first word in the ss target description? |
| 2 | PR 50162 | filed APT PR | T | APT allows both an RV and Z, but doesn’t write both to the prop file. I don’t think it should. It should probably red X the distance when both are set though. I seem to be able to import either one. |
| 3 | PR 50163 | filed APT PR | T | Generic target criteria not being set. I can’t even see the criteria field on my generic target If I duplicate the generic target that has it, the duplicate doesn’t have it! Ok. This is related to phase ½ duality. When I switch back and forth from phase 2 to 1 to 2, I see the proper value for all the criterias. |
| 4 | 2 | Test behavior for illegal wavelengths -
decide if the importer needs to generate its own diag.
Assigned (C) Closed (T) 1/22/04 |
T | Wavelength gets put in the free text area when it’s
not legal at the time. It
doesn’t get moved back if it becomes legal.
This is probably OK, but it makes me nervous.
I thnk this issue can be closed. There was a little more to this
issue, but I'm not concerned about it. Due to some subsequent APT
changes in the wavelength GUI, it's less of an issue than before. |
| 5 | OK | Try it
Looks OK (T) No Action |
T | Consider the hideous case where the visit number matches another token. Make sure I cover all those. |
| 6 | Doc | propinst should match what APT requires
Assigned (C) Filed PP PR 50279 Doc that only legal format is dd-MMM-yyyy:[HH[:mm[:ss]]] |
T | What formats are allowed for Epoch and T in levels? Propinst says 4 digits, test file has DateSpec(). |
| 7 | 2 | Assigned (T)
Made changes to the importer only. RTT 1/9/04 Failed (R) 1/20/04 RTT (T) 2/6/04 Passed (R) 2/12/04 |
T | APT
marks AFTER Visit as illegal. It says that both by and to must be
specified. Both actually are, and the error goes away when the
fields are refreshed.
This could probably be fixed either in APT or the importer.
The specific item to be fixed works, but the ability to just use AFTER 30, with no BY and TO should work but does not. Also, AFTER 30 BY 30D should work (although APT will give a red X about the missing TO), but also fails. Both are due to the same cause (reading the units token). |
| 8 | RTT 12/31
Tested (R) |
C | Visit PCS modes FINE and GYRO need to be input as Fine and Gyro. | |
| 9 | 2 | Assigned (T)
Changed just the importer RTT 1/9/04 Passed (C) 1/13/04 |
T, R | Offset targets From Target is marked as illegal initially, but the diag goes away if you go to look at the offset position in the form editor. This could probably be fixed either in APT or the importer. |
| 10 | 2 | APT shouldn't write this out.
We can then give a warning if it's specified (and ignore the value) We should see what PP does with that value. The PP silently ignores the offset target's equinox when creating the tdf. We should just worry about how to ensure all targets use J2000. (see #40) Closed. |
T, R | What should the importer do with equinoxes specified for offset targets? When APT creates an RPS2 file with offset targets, it writes out the equinox. |
| 11 | RTT 12/31
Passed (C) 1/13/04 |
C | Time_Per_Exposure with "." in the number gets
parsing error. Examples are 300.0 S and 30.5 S |
|
| 12 | Doc | same as PP->xml
Doc? Closed |
C | PI and Co-I names weren't in format with just PI_Name or
CoI_Name and had to be fixed in APT for Last/Honorific/First/(Middle) |
| 13 | OK | same as PP->xml?
Illegal? No action. |
C | Commanding certification proposal had Targets with Description: UNIDENTIFIED which was translated to Category UNIDENTIFIED and blank Description field which needed to be filled in. |
| 14 | Doc | same as PP->xml
Doc |
C | Phase II ID field needs to be filled in. |
| 15 | Doc | If multiple fluxes are on the Flux: line,
they need commas between them.
Doc |
C | Flux of form V=10.7 B-V=3.2 had to be rewritten as Flux: V = 10.7 Other_Fluxes: B-V = 3.2 or got parsing error. |
| 16 | OK | I'm surprised the PP still accepts this.
No Action |
C | Scan_Data had to be removed. got parsing error. (Yes, I know that's old, but was in my commanding props.) |
| 17 | 2 | same as PP->xml
Doc Needs fix for B1950 It's serious so it needs to stop the import and be an ERROR. Assigned (T) RTT (T) 2/6/04 Passed (C) 2/9/04 |
C, T | Invalid Equinox Equinox 2000 on target: MRK190 (Fixed Target) is invalid. But there is a problem in that the importer does not warn if they use B1950! |
| 18 | Importer needs to upcase these.
RTT 12/31 Passed (C) 1/13/04 |
C | Coordinate_Source: Guide_Star_Catalog getting saved back to .rps2 file as Coordinate_Source: Other_Source: Guide_Star_Catalog |
|
| 19 | Importer needs to upcase these.
RTT 12/31 Passed (C) 1/13/04 |
C
|
target Description: STAR, FU Orionis Star giving Rps2 Importer Uncaught exception during import however Description: STAR, FU ORIONIS STAR imports cleanly, so appears to need capitalization |
|
| 20 | 2 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
C | 954 visit 33 exposure 1 had been missing Comment: line caused parser error expected but it took me a while to figure this one out I kept thinking it was something to do with the next visit /data/mimir2/apt/rps2/127/127.prop loads fine. |
| 21 | RTT 1/7/04
Passed (C) 1/13/04 |
C | patterns need exposure number if exposure 1 has Special_Requirements: PATTERN 1 you'll get a parsing error need to use Special_Requirements: PATTERN 1 1 |
|
| 22 | Doc | Doc | C | dual spectral elements need "," between them Sp_Element: F555W F435W gives parsing error Sp_Element: F555W,F435W is ok |
| 23 | PR 50156 | APT differentiates case for targets. In
APT, you can define both FU-Ori and FU-ORI as separate targets.
APT PR filed. |
C | PP would change FU-Ori to FU-ORI in the tdf file. import of .prop doesn't change target and therefore APT gives Target is a required field for FU-Ori with defined target of FU-ORI. |
| 24 | PR 50158 | I think it's OK to defer to what APT thinks
is required.
No action unless Christine says otherwise after investigating. Filed APT PR |
C | I have a pattern without defined Coordinate Frame and Pattern Orientation. PP had put default of POS-TARG for Coordinate Frame and 0 for Pattern Orient in the tdf. APT gives Coordinate Frame is a required field and Pattern Orientation is a required field. |
| 25 | PR 50538 | needed for cal if at all.
These are illegal in APT because APT doesn't like the leading 0. file PR |
C | 896 86.02 STIS MSMOFF warning on SETOFFSET=0500 87.03 STIS MSMOFF warning on SETOFFSET=0700 87.07 STIS MSMOFF warning on SETOFFSET=0900 88.01 STIS MSMOFF warning on SETOFFSET=0200 why are these illegal? |
| 26 | 2 | expecting a value, either fix or change
propinst
Fixed it to allow no value. RTT 1/9/04 Passed (C) 1/13/04 |
C | 884 parsing errors for MIN DUR and MAX DUR |
| 27 | 2 | assigned (T)
need to make it work as well as PP RTT 1/8/04 Passed (C) 1/13/04 |
C | 887 parsing error on word "Visits" in Abstract: expected Cmd prop 887 had lines like Visits 07-08: Lines 500-590 test standard WFPC2 IMAGE operations. ---......... |
| 28 | 3 | doc
I decided to allow ";" or "," because it was easy. RTT 1/8/04 Passed (C) 1/13/04 |
C | parsing error on optional parameters separated by a
";" need to be "," |
| 29 | 4 | on wfc3 or cos
Closed. |
C | 887 Time_Per_Exposure: DEF saved back to .prop as Time_Per_Exposure: |
| 30 | 2 | assigned (t)
test was on solaris RTT 1/8/04 Passed (C) 1/13/04 |
C | parsing error if Questions line has a comment starting with an exclamation mark (diagnostic will mention Observing_Description:) example below Questions ! comment starting with exclamation mark Observing_Description: |
| 31 | 2 | assigned (t)
RTT 1/8/04 Passed (C) 1/13/04 |
C | 893 parsing error if no blank line between Investigators PI_Name: gives error Investigators PI_Name: doesn't |
| 32 | 2 | assigned (t)
RTT 1/9/04 Passed (C) 1/13/04 |
C | parsing error if last Special_Requirement ends with ';'
punt if complicated; the issue is that the diag is not informative enough, so either change the diag or accept the ';' I decided to accept the last ';' with the side effect that multiple ;'s can be used in SR's wherever just one was allowed before. |
| 33 | 2 | assigned (t)
RTT 1/9/04 Passed (C) 1/13/04 |
C | AFTER BY (exposure level sr) seems to be giving an Uncaught exception during import. And example prop is /data/mimir2/apt/rps2/665/665.prop 01.02 line 102 dying The parser didn't like the AFTER BY without a 'TO' clause. |
| 34 | RTT 1/7/04
Passed (C) 1/13/04 |
T | Invalid target descriptions cause concurrent mod exception in list. This is related to issue #19. This is an important bug. | |
| 35 | PR 50309 | Assigned (T)
Filed autofill PR. |
R | Random question: should the clear
orbit numbers button also clear the actual duration field, since the duration makes no sense without the
orbit numbers?
Yes. "Clear All Orbit Numbers and Actual Durations" |
| 36 | Doc | doc
The PP allows this, and it would be easy for us to allow it, but there's really no need to. |
C | Visit_Requirements: SEQ 1-10 WITHIN 24H gives Rps2 Importer error invalid range as the visits are numbered 01, 02, 03 ... 10 |
| 37 | PR 50161 | assigned (t)
same as PP->xml->APT, but still wrong. Filed APT PR. |
C | /data/mimir2/apt/rps2/886b/886.prop gets This Plate ID may only be used with engineering proposals for Target 6 (NGC188-1). But it is an engineering prop. Proposal_Category: ENG/FGS |
| 38 | 2 | assigned (t)
The fix in the visit range handler should affect all SR's that use visit ranges. RTT 1/11/04 Passed (C) 1/13/04 |
C | /data/mimir2/apt/rps2/886b/886.prop < original rps2 > exported rps2 < SEQ 01-10 WITHIN 24H > SEQ 01,02,03,04,05,06,07,08,09 WITHIN 24 H there are visits 01...10 but the new numbering only goes through 09 similar for < SEQ 11-19 WITHIN 24H > SEQ 11,12,13,14,15,16,17,18 WITHIN 24 H < SEQ 20-26 WITHIN 24H > SEQ 20,21,22,23,24,25 WITHIN 24 H < SEQ 37-39 WITHIN 24H < SEQ 40-41 WITHIN 24H were dropped in the exported rps2. There are visits 37, 39 (no 38), 40, 41 |
| 39 | 2 | assigned (t)
RTT 1/8/04 Passed (C) 1/13/04 |
C | double filters truncated to one: /data/mimir2/apt/rps2/887b/887.prop visit 04 exp 02 < Sp_Element: F122M,F130LP > Sp_Element: F130LP |
| 40 | PR 50333 | see #17 for more info.
Filed PROPINST PR that equinox is required in RPS2 format and that it must be J2000 s/w changes handled in issue 17. Closed |
R | I note that Equinox is optional, but since all coordinates must have an equinox, I do not understand how this field can be optional. On the other hand, we now require equinox 2000 for all objects, so in a sense this keyword is unnecessary. However, it is still populated in the apt file, so it is necessary. In APT, it is cleared marked that coordinates are 2000, but for people doing ingest, the should have the reminder that equinox is important. So, I propose we make equinox required. We also need to have the software flag this as an error (at present, if you put B1950 in the RPS2-like file, the keyword is ignored). |
| 41 | Not a Bug
No Action |
R | I used the CR-SPLIT parameter for testing. Everything
worked as expected, except that the software REQUIRED CR-SPLIT to be intact. |
|
| 42 | Doc | Assigned (T)
This is due to the tokens not including NL's in between the words. Those cannot be added to the tokens cleanly due to possible comments, so the correct fix would be to break up the tokens, and allow all WS() in the grammar. 1 day or so effort. Doc |
R | The software requirements all multi-part requirements (e.g.
POS TARG) to be on the same line. The arguments, however, can be on different lines (e.g. -1.0, and +2.0 on different lines). The software requirements all hyphenated requirements (e.g. LOW-SKY) to be on the same line. These are all acceptable. |
| 43 | See #32
Passed (C) 1/13/04 |
R | If you have a ";" on the last requirement, the
importer dies (since it is looking for a new requirement which is not there). This will be a common error, so a more benign failure mode is needed. |
|
| 44 | Prop file values for FORMAT, EXP PCS MODE and
GS ACQ SCENARIO will all be forced to upper case by the importer.
RTT 1/11/04 Passed (C) 1/13/04 |
R | A follow-on to my previous message regarding ingest of exposure level special requirements. There are 3 requirements (FORMAT, EXP PSC MODE, and GS ACQ SCENARIO) that have defined text inputs (e.g. FORMAT has AN, FN, etc.), and these inputs are case sensitive. So, if your input file as "FORMAT an", the ingest works, but you get a red X saying the "an" is illegal. This is OK since you can then use the picklist to select "AN". | |
| 45 | Prop file values for FORMAT, EXP PCS MODE and
GS ACQ SCENARIO will all be forced to upper case by the importer.
RTT 1/11/04 Tested (R) 1/20/04 |
R | However, for GS ACQ SCENARIO, I think we have a problem.
This requirement has specific text inputs, but it also allows free text. So, if you wanted BASE1 as your selection, but put "base1" in
your ingest file, you do NOT get a red X. Although this is a PC mode and
therefore the chance of a GO messing up are small, the PCs will be doing a lot of work from the ingest file, and this could be a problem for them. I talked with Denise about this, and the PC situation will not change from the present operational scenario when the APT ingest is functional. So, we do NOT need to worry about this. |
|
| 46 | 2 | ***
RTT (T) 2/6/04 Passed (C) 2/11/04 |
T | For parse errors (those that stop parsing), what should we
do to make sure they know that the prop wasn't fully read in.
Options:
We decided to do the following for all import errors, whether or not they cause parsing to stop:
|
| 47 | 2 | assigned (t)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
T | add popup if any import diags are created |
| 48 | The list not working should be fixed by #38.
The white space issue is separate. Assigned (T) RTT 1/12/04 Tested (R) 1/20/04 |
R | Issue: Visit lists do not seem to work properly. If the list is 1,2,3, it works. However, if the list is 1-3, only 1 is marked in APT. If there are spaces between the visits (e.g. 1, 2, 3), it also does not work. | |
| 49 | Assigned (T)
RTT 1/12/04 Tested (R) 1/20/04 |
R | Issue: the Visit-level requirement VISIBILITY INTERVAL CORON does not work at all. It seems to want a time only, so this is being confused with the other usage of VISIBILITY INTERVAL (which does require a time). | |
| 50 | Doc | I think this is a
misunderstanding.
Actually though, the importer does not require that the visit with the sr be included in the list. Should it? What does the PP require. Doc that you *should* have the current visit. Assigned (T) - make sure the only issue is the single digit visit id's. (issue #36) |
R | Issue: when using requirements list GROUP visitlist WITHIN,
the current visit CANNOT be included in the visit list. We must
document this prominently.
Actually the import accepts the current visit in the visit list, but does not require it. The PP may require that. The biggest potential difference here is if the user intentionally puts the sr on a visit that they don't want in the list. Say you have 3 visits. |
| 51 | PR 50201 | Same issue when specified in the GUI.
APT PR filed. |
R | Issue: for SEQ vistlist WITHIN, I had a case where my visitlist was illegal. APT did not populate the visit field, but kept the WITHIN requirements. I did NOT get a red X (WTHIN specified but no visitlist), and I think I should have. |
| 52 | OK | The PP doesn't accept the white space between
JD and number either.
No issue with SCHED. No action. |
R | Issue: for PERIOD AND ZEROPHASE, the software requires no spaces between the JD and date (i.e. JD2450000 works, JD 2450000 does not). This is similar to things list SCHED 100%, so we need to document this restrictions carefully. |
| 53 | Doc | Just make sure the new propinst contains rps2
syntax for things like this.
Closed |
R | Issue: ORIENT angle TO angle FROM visit is a different format than the Phase II instructions (ORIENT FROM visit BY angle TO angle). Also note that the orient range does NOT appear in the spreadsheet editor. |
| 54 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
T | There seem to be (at least) two problems with doing runAll. 1) Batch mode with -import hangs if there's no -export. 2) -runAll expects another argument, so the next argument after -runAll on the command line is being ignored. |
|
| 55 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/11/04 |
T | Deal with this PR:
47948 - Allow non-consecutive target numbers |
|
| 56 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
C | while testing opr 50219. I imported a prop with an unfinished REGION specification, Position:RA=01H 31M 01.7S, DEC=+30D 24' 15", REGION Upon import it was quietly turned into a rectangular region with sides 0.1 RA, 0.1 DEC. Lost the PP warning of "fixed position beginning with RA = 01H31M01.7S DEC = +30D24'15\" REGION appears to be incomplete" |
|
| 57 | 1 | Assigned (T)
Passed (R) 2/11/04 |
R | 1) the error messages for incomplete requirements and parameters point to the line in the file AFTER the incomplete statement. This is correct (since the next line could have had the missing information), but is confusing to the users (since they look at the line and see nothing wrong). Could we change the software to point to the line the is missing the text? |
| 58 | Doesn't matter now that warning causes visits
not to exist.
No Action |
R | 2) GROUP 10-40 WITHIN 10D (where there is no visit 40) - you get a warning about the illegal range, but the ingest does insert the GROUP requirement with only visit 10 (even though 20 and 30 are also legal). If you try GROUP 10,20,30,40 WITHIN 10D, you get the same warning, but visits 10-30 are included in the group. | |
| 59 | 2 | Assigned (T)
(Should change message) RTT (T) 2/12/04 Tested (R) 2/17/04 |
R | 3) PAR 1-2 WITH 4 (where there is no exposure 4) - you get a warning about the illegal range, but the software claims the range will be created as specified. This does not happen (it cannot since the prime exposure does not exist). |
| 60 | 1 | Assigned (T)
(Make warning clearer) RTT (T) 2/12/04 Tested (R) 2/17/04 |
R | 4) PAR 2-3 WITH 1 (where these is no exposure 3) - very confusing. The ingest error says "PAR 2-3 WITH 1 on line 165 overlaps with exposure group: Visit. The former will be ignored." This is very unclear, but tells me that the PAR will be ignored. However, an PAR container is created, but it just has the prime exposure. The same situation arises if there I try PAR 2-4 WITH 1, where only 4 does not exist. |
| 61 | Assigned (T)
Problem seemed to go away with new OP interface. No Action. |
R | 5) STIS/CCD ACQ ACQTYPE=CRAP (illegal; pulldown) - the error message says "null is no valid on the specified exposure. The parameter will be ignored." This is fine (although it should say CRAP is NOT valid), except that the line number with the problem is reported as line 167, which is well past where the offending line is, and is even past another exposure in the visit. It is pointing to the next Visit keyword in the file (or the end of the file). The entire file is ingested. | |
| 62 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
C | Simple MARS isn't working... parsing on Level_1/Level_2 lines Target_Number: 2 Target_Name: CERMARS Description: PLANET PLANET-MARS Level_1: STD=MARS Level_2: Level_3: Window: CML OF MARS FROM EARTH BETWEEN 0.0 30.0 Ephem_Uncert: Acq_Uncert: Flux: V = -2.6 SURF(2500)=2.84 +/-0.3E-13 SURF(4350)=2.52 +/-0.3E-11 SURF(6580)=6.87 +/-0.3E-11 Comments: This turned out to be a collision between the token "MAR" for March and the planet name "MARS". Also there needs to be a comma after the V = -2.6. That is one of the separators that is now required that the PP didn't require. |
|
| 63 | Assigned (T)
RTT (T) 2/6/04 Passed (C) 2/9/04 |
C | /data/mimir2/apt/rps2/133/133.prop error parsing at line 41. /data/mimir2/apt/rps2/134/134.prop error parsing at line 42. 133 exposed a parser problem that wouldn't allow decimal numbers that started with a '.'. It also had a new-line in the middle of a number on line 51. 134 had the same problems discussed in issue 62. |
|
| 64 | Assigned (T)
This is an APT issue. GS ACQ SCENARIO allows an "other" value that can accept any text. Do we need a warning? No. No action. |
C | APT doesn't mark unknown GS ACQ SCENARIO value of BASES (based on Karla's earlier tests) when imported from an rps2 or opened from an xml file. PP gives: "Warning: Unknown GS ACQ SCENARIO value (BASES)." |
|
| 65 | Assigned (T)
These illegal values were caught by the parser instead of being red X'd by APT. There was no particular reason for that distinction. No action. |
C | parsing error on rps2 import of illegal FORMAT ZN. parsing error on rps2 import of illegal EXP PCS MODE SLOW. |
|
| 66 | PR 50309 | filed APT PR
RTT (T) 2/6/04 Passed (C) 2/9/04 |
T | Either get rid of the visit-id on subexposures, or flag an
error when one's value doesn't match that of the visit it's in.
Decided to stop exporting the visit_number and ignore it on read. |
| 67 | RTT (T) 2/6/04
Now these diagnostics have gone away entirely with the new optional parameter interface. (T) 2/17/04 Closed. |
T | Diagnostic for invalid optional parameter had parts missing and didn't look good. | |
| 68 | RTT (T) 2/6/04
Passed (C) 2/9/04 |
T | Automatically upcase o.p. values | |
| 69 | RTT (T) 2/6/04
Passed (C) 2/9/04 |
T | Allow both PAR and PARALLEL for visit level requirement, because APT currently exports "PARALLEL" and it's easier to change the importer to accept both. | |
| 70 | RTT (T) 2/6/04
Passed (C) 2/19/04 |
T | Importer diagnostics about optional parameters contained misleading line numbers. (They were also a little sloppily written.) | |
| 71 | RTT (T) 2/6/04
Passed (C) 2/9/04 |
T | Stop restricting RPS2 importing to STScI mode. Do not mark the action as unsupported. | |
| 72 | The reponse matches the
current behavior.
Closed (T) 2/12/04 |
T | When importing an ACS-SBC-DITHER-BOX pattern
with line spacing and sides angle unspecified, APT gives those values
defaults. When APT opens the same thing from an xml file, those
values are left blank.
In the APT file case, the user either cleared those defaults from the APT editor and saved the proposal or is reading an old APT file. In the former, we should definitely preserve the blank fields. In the latter, I'm not sure what we should do. The RPS2 importer has the same dilemma. Those fields are optional with built-in defaults. The prop file doesn't give us a good way to determine whether unspecified values for those fields meant "use the default" or "preserve the fact that I still haven't entered a value". So what should we do in APT and the RPS2 importer for unspecified line spacing and sides angles when the pattern gives defaults but leaves the fields editable? Response: Since the PI was reading in an old APT file, that file had to ASSUME the default values, so we should do the same thing on read. I think we should assume that the PI would have populated the fields if they wanted non-default values, so if they are blank, put in the defaults. |
|
| 73 | Assigned (T)
RTT (T) 2/10/04 Passed (C) 2/19/04 |
T | Visit 03, exposure 2 in Import-Test is not part
of a pattern or number of iterations. It does have a CR-SPLIT.
In an APT load, those indeces for the subexposures are nil, but in an RPS2
load they are 1.
This will happen in all cases where the exposure's target name is not legal for that exposure. The outermost clause in createSubexposures() prevents it from running and setting the proper indeces for the ExposureCopy's. The fix requires retesting of subexposure ingest. This needed to be fixed in conjunction with PR 50347 |
|
| 74 | 4 | Let's not do anything about this.
Closed. |
C/T | When the Fixed_Targets line is missing,
the fixed targets can be ignored (gobbled up by the Additional_Comments:
field of the proposal description).
I wrote the grammar to require the Fixed_Targets line. I didn't realize the PP would recognize the fixed targets in this case. |
| 75 | 2 | RTT (T) 2/12/04
Passed (C) 2/17/04 |
C | When the Sub_Exposures: line is present, the parser requires it to be populated. The PP allows a blank Sub_Exposures: line. |
| 76 | Ignore
Closed |
C | Getting Error Line 68: Incomplete Target Position Region target requires either a radius specification or +/- values for both RA and Dec. /data/mimir2/apt/phase2/5596/5596new/5596.prop Target_Number: 2 Target_Name: M33 Alternate_Names: Description: GALAXY, SPIRAL Position: RA=01H01M1.1S +/- 2.0S,DEC=+01D01'1.1" +/- 3.0",REGION This prop was exported from APT after having read in the /data/mimir2/apt/phase2/5596/5596new/5596new.apt file |
|
| 77 | PR 50534 | File PR. | R | In parser errors, the "Was expecting one of:" lists can be confusing. This is especially true when the list is trying to describe something general, like an alphanumeric string. Optional parameter values are such strings, so if they are missing, the "Was expecting one of:" list is long and not helpful. |
| 78 | 2 | Importer was getting NPE's on any
STD level 2's.
RTT (T) 2/17/04 Passed (C) 2/17/04 |
C | Getting an rps2 importer error on line 46
for /data/mimir2/apt/rps2/143/143.prop NullPointerException Solar_System_Targets Target_Number: 1 Target_Name: GANYMEDE Description: SATELLITE Ganymede Level_1: STD=JUPITER Level_2: STD=GANYMEDE Level_3: Window: OLG OF GANYMEDE BETWEEN 15 50 Ephem_Uncert: Acq_Uncert: Flux: V=5.32 Comments: |
| 79 | 2 | UTD 2/16/04
Closed |
C | ;; after last visit sr crashes parser. |
| 80 | PR 50535 | file PR | C | Blank target templates are not accepted. Neither are blank pattern templates. Are there any other blank parts of the template that should be accepted? |
| 81 | PR 50536 | file PR | C | Scientific notation not accepted for any numbers. Example was -4.0E-5 for RA_PM. Should all floating point fields allow scientific notation? |
| 82 | PR 50537 | file PR | C | There's a SEQ NON-INT 1-23 1,2,4,5,6... have SAME POS AS 3. APT reading the xml from PP has SAME POS AS on the input is at |
| 83 | I don't think this is a problem. The reason the PP accepts this is that the ";" wasn't required. | C | ! in line with a ; at the end:
not a problem, just a comment perhaps for doc |
|
| 84 | ||||