Il fatto di aver creato una classe a parte (ApriFileIrraggiamento) solo per la gestione del file, ok, è buono.
Se Irraggiamento rappresenta tutto il file (e mi pare di capire che è così), allora il fatto che parseString riceva il BufferedReader, tutto sommato potrebbe anche andare bene, perché tutta la gestione è in apriFiles e quindi per forza glielo deve passare.
Ma se ci pensi, e ragioni, parseString legge solo una riga e fa il parsing di quella riga. Quindi NON è affatto necessario che parseString riceva il BufferedReader. Basta che riceva la stringa.
Il parseString viene chiamato 4 volte da apriFiles e tu per evitare 4 readLine(), per questo hai passato il BufferedReader. Ma potevi fare es.
codice:String latitude = parseString(b.readLine(), "Lat", "Lati", true); ......
Che costava molto poco ....
Quello che va meno bene è che in parseString catturi IOException, fai un log (e questo va bene) ma poi finisce lì. No, quel IOException dovrebbe poter uscire da parseString e anche da apriFiles.
Ah, qui ad esempio:
String[] intestazione = b.readLine().split("\\s+"); // intestazione
non è molto buono: se readLine() restituisce null, ti becchi NullPointerException. Ma se ti dà null, vuol dire che sei a fine file e se quella riga te la aspettavi, vuol dire che il file è "malformato" e lo devi segnalare opportunamente.
Dovresti valutare questo aspetto in generale, anche per le altre readLine()