TypeError: long() argument must be a string or a number, not 'NoneType'

[gillins]

Original report by Stefan Milutinovic (Bitbucket: Milutinke, GitHub: Milutinke).

---

When i want to run "/home/stefan/Downloads/python-fmask-0.4.2/bin/fmask_sentinel2Stacked.py -a allbands.vrt -z angles.img -o cloud.img ", I get this error.

I am using this for one Granule of sentinel 2 image.

Is it my fault or no?

Thanks.

[gillins]

Original comment by Neil Flood (Bitbucket: neilflood, GitHub: neilflood).

---

Hi Stefan,

I suspect it is not your fault. At the top of your screen shot of the error, is the end of another line of the error. I think this is the most important bit The part which is visible is saying that the band 1 .jp2 file is not a recognised format, which means that it is not reading that file as a .jp2 file. One possible reason for this could be that the file is corrupted. There are many of the Sentine-2 zipfiles which have CRC errors when unzipping, and in some cases this results in one of the unzipped .jp2 files being incomplete, and GDAL then fails to read the data from it.

I can't say for sure, but I suggest you test this by trying to display that file in your favourite image viewer, and see if it is OK. Also, have a look at the error messages which come out of the unzip command and see if there were any clues there.

Neil

[gillins]

Original comment by Stefan Milutinovic (Bitbucket: Milutinke, GitHub: Milutinke).

---

I think is my fault. I didn't done with anaconda environment.

I use now this instruction: conda config --add channels conda-forge conda config --add channels rios conda create -n myenv python-fmask

And done this: gdalbuildvrt -resolution user -tr 20 20 -separate allbands.vrt S2_B0[1-8].jp2 S2_B8A.jp2 S2_B09.jp2 S2_B1[0-2].jp2

and this: fmask_sentinel2makeAnglesImage.py -i ../S2*.xml -o angles.img

And then, on third step: fmask_sentinel2Stacked.py -a allbands.vrt -z angles.img -o cloud.img

I get this error: (myenv) stefan@W04704:/media/stefan/Ekstra/Vojvodina-Merge-Oper-User/Oper-User-Files/Oper-User-20160201-20160520/S2A_OPER_PRD_MSIL1C_PDMC_20160420T170324_R036_V20160420T094738_20160420T094738.SAFE/GRANULE/S2A_OPER_MSI_L1C_TL_SGS__20160420T134755_A004323_T34TDQ_N02.01/IMG_DATA$ fmask_sentinel2Stacked.py -a allbands.vrt -z angles.img -o cloud.img Segmentation fault (core dumped)

Help?

[gillins]

Original comment by Neil Flood (Bitbucket: neilflood, GitHub: neilflood).

---

That looks bad. My guess is some conflict in the Anaconda installation of the various pieces.

Try the fmask_sentinel2Stacked.py command with the --verbose switch, so you can see where it gets up to before the segmentation fault.

[gillins]

Original comment by Stefan Milutinovic (Bitbucket: Milutinke, GitHub: Milutinke).

---

What can be problem with this?

(myenv) stefan@W04704:/media/stefan/Ekstra/Vojvodina-Merge-Oper-User/Oper-User-Files/Oper-User-20160201-20160520/S2A_OPER_PRD_MSIL1C_PDMC_20160420T170324_R036_V20160420T094738_20160420T094738.SAFE/GRANULE/S2A_OPER_MSI_L1C_TL_SGS__20160420T134755_A004323_T34TDQ_N02.01/IMG_DATA$ fmask_sentinel2Stacked.py -a allbands.vrt -z angles.img -o cloud.img Segmentation fault (core dumped)

[gillins]

Original comment by Neil Flood (Bitbucket: neilflood, GitHub: neilflood).

---

I think that you might have a conflict with the different sets of packages installed with conda. I think it is possible that you already have a conda installation of gdal, and this is conflicting with the binaries which get installed to support pythonfmask. I am guessing, but I think that you may have the osgeo channel set up in conda, and that build of gdal. So, if this is the case, I think that the following should fix things

source deactivate myenv conda config --remove channels osgeo conda create -n mynewenv python-fmask source activate mynewenv

[gillins]

Original comment by oaznay (Bitbucket: oaznay, GitHub: oaznay).

---

Hi Neil,

I have almost the same issue. Can you help me?

Regards

[gillins]

Original comment by Neil Flood (Bitbucket: neilflood, GitHub: neilflood).

---

Original poster never got back to me, so I assume that they solved the problem without further need of us. New poster oaznay then opened a separate issue #9. Closing this issue on the assumption that nothing further required.