Use "_" instead of " " as separators in spectra names

Issue #275 closed
Former user created an issue

.sli files have companion .hdr files in which spectra names are such as: spectra names = { FX10FX17_Quartz1_small.raw 738.785219770416 358.03143995717653 USER:100025, FX10FX17_Quartz2_small.raw 615.0409742461194 446.71481591625576 USER:100025, FX10FX17_Quartz3_small.raw 346.9284422768101 586.9582941771253 USER:100025}

For ulterior processing, "_" would be more convenient: spectra names = { FX10FX17_Quartz1_small.raw_738.785219770416_358.03143995717653_USER:100025, FX10FX17_Quartz2_small.raw_615.0409742461194_446.71481591625576_USER:100025, FX10FX17_Quartz3_small.raw_346.9284422768101_586.9582941771253_USER:100025}

Comments (11)

  1. Benjamin Jakimow
    • changed status to open

    How do you think about replacing the whitespaces by '_', at least for the default spectra names? @Andreas Janz @Fabian Thiel ?

  2. Andreas Janz

    Whitespaces are allowed in the original ENVI format. So you should expect them. However, in your routines, you are free to replace them with underscores.

  3. Agustin Lobo

    White spaces should be avoided in names, as a white space is most often used to separate fields. Within names they are an endless source of problems.

  4. Agustin Lobo

    I do insist on this issue that should be very simple to implement. The fact that white space is allowed in hdr files is not a reason

    to actually include them within hdr section “spectra names” to separate the coordinates from the actual file name. Including coordinates in the

    “spectra names” section of the hdr is really not an elegant solution. In order to facilitate the automatic processing of these hdr files in a transparent way, please use characters such as “|” or “;” (rather than “_” as I said, because “_” can actually be part of the filename quite often) to separate the coordinates from the actual name.

  5. Andreas Janz

    @Agustin Lobo , I agree that spectra names like FX10FX17_Quartz1_small.raw 738.785219770416 358.03143995717653 USER:100025 are very ugly.

    @Benjamin Jakimow do you create such names? I would just place the “real” name FX10FX17_Quartz1_small.raw under the spectra names key. Tho location and projection infos should go to seperate metadata items (e.g. spectra location, spectra projection).

  6. Agustin Lobo

    Those hdr are the ones created by OpenMapBox when making sli files, we do not make them. I agree with you, the best would be having coordinates under other sections in the hdr. I do not see those fields (spectra location, spectra projection) among hdr fields though (http://www.harrisgeospatial.com/docs/ENVIHeaderFiles.html

    http://www.harrisgeospatial.com/docs/EnterOptionalHeaderInformation.html)

    Let me put this in context:

    1. We interactively create sli files with EnMapBox
    2. We input the sli set of files into R and create a shapefile for all of them using an R function I 've made.
    3. We use the shapefile in the EnMapBox classification workflow.

    I have figured out how to extract the points coordinates from the hdr files despite the current problem of having white spaces, but it would have been easier

    with other separators. So this is not critical, but still think it is a bad way to record the coordinates of the spectra.

  7. Andreas Janz

    You can have additional metadata items inside an ENVI header. So spectra location and spectra projection is a problem.

  8. Benjamin Jakimow

    added enmapboxtesting/test_template.py

    SpectralProfileBridge: - added .setRunAsync (and removed it from the bridge panel) - added .currentProfiles() - refactored style updating and setting of current profiles - removed current profile "flickering" (closes issue #355) - fixed numbering of added profiles (addresses issue #275) - closes issue #342

    Signed-off-by: Benjamin Jakimow benjamin.jakimow@geo.hu-berlin.de benjamin.jakimow@geo.hu-berlin.de

    → <<cset a5631614d51f>>

  9. Log in to comment