I am running into the following error when I am loading my shape files through the DashDB console:
My shape files are the following:
Would anyone have experience working with DashDB and ran into a similar problem?
UPDATE:
I downloaded a separate dataset with the following files, and I still running into the same error:
Please find the following sample files https://www.dropbox.com/s/bkrac971g9uc02x/deng.zip?dl=0
I brought the Shapefile into QGIS easily, so I knew the format was OK. I unzipped the Shapefile, changed the file names to lower-case and re-zipped it up. Then I was able to get further in the dashDB upload UI. I got to a message saying the SRS was unknown. I then used QGIS to convert the SRS (spatial reference system) into a known one -- EPSG:4269, NAD83, and I was then able to upload it into dashDB. Here's the version of your file that works:
https://dl.dropboxusercontent.com/u/8196680/dc.zip
Related
I have a directory consisting of 22 sub-directories. Altogether, the directory is about 750GB in size and I need this data on GDrive so that I can work with it in Google Colab. Obviously uploading this takes an absolute age (particularly with my slow connection) so I would like to zip it, upload it, then unzip it in the cloud.
I am using 7zip and zipping each subdirectory using the zip format and "normal" compression level. (EDIT: Can now confirm that I get the same error for 7z and tar format). Each subdirectory ends up between 14 and 20GB in size. I then upload this and attempt to unzip it in Google Colab using the following code:
drive.mount('/content/gdrive/')
!apt-get install p7zip-full
!7za x "/content/gdrive/My Drive/av_tfrecords/drumming_7zip.zip" -o"/content/gdrive/My Drive/unzipped_av_tfrecords/" -aos
This extracts some portion of the zip file before throwing an error. There are a variety of errors and sometimes the code will not even begin unzipping the file before throwing an error. This is the most common error:
Can not open the file as archive
ERROR: Unknown error -2147024891
Archives with Errors: 1
If I then attempt to rerun the !7za command, it may extract one or 2 files more from the zip file before throwing this error:
terminate called after throwing an instance of 'CInBufferException'
It may also complain about particular files within the zip archive:
ERROR: Headers Error : drumming/yt-g0fi0iLRJCE_23.tfrecords
I have also tried using:
!unzip -n "/content/gdrive/My Drive/av_tfrecords/drumming_7zip.zip" -d "/content/gdrive/My Drive/unzipped_av_tfrecords/"
But that just begins throwing errors:
file #254: bad zipfile offset (lseek): 8137146368
file #255: bad zipfile offset (lseek): 8168710144
file #256: bad zipfile offset (lseek): 8207515648
Although I would prefer a solution in Colab, I have also tried using an app available in GDrive named "Zip Extractor". But that too throws an error and has a dataquota.
This has now happened across 4 zip files and each time I try something new, it takes an a long time to try it out because of the upload speeds. Any explanations for why this is happening and how I can resolve the issue would be greatly appreciated. Also I understand there are probably alternatives to what I am trying to do and they would be appreciated also, even if they do not directly answer the question. Thank you!
I got same problem
Solve it by
new ProcessBuilder(new String[] {"7z", "x", fPath, "-o" + dir)
Use command line array, not just full line!
Luck!
Why does this command behave differently depending on whether it's called from terminal.app or a scala program?
It seems that the XYZ Studio has some problems with accepting files. The upload of .geojson and .csv files is recommended but it tells me i am trying to upload "unsupported file types". It still worked a few weeks ago but i cannot upload any .geojson and .csv files right now.
Kindly crosscheck the names in the header of your csv file. If the file does not have columns labelled Latitude and Longitude, the xyz studio may give you a message saying that you are trying to upload an unsupported file.
I ran into a similar issue. Turns out HERE Studio prefers comma (,) CSVs only. If modifying in excel and it gets saved as a caret (^) CSV, the uploader will only read the file as one wide column and pop out errors.
If HERE is listening, some documentation on properly formatted file types, formats, and limitations along with sample code for the .CSVs, json, shape, and GEOjson files would be immensely helpful to users of Studio as there is little in the way on the API/platform documentation.
I am testing the new Microsoft Custom Translator and trying to train a system EN-SC, but the file upload fails.
I am trying to upload unzipped TMX files, all less than 50 MB in size, as specified in the user's guide. The file names I have tried are:
Master1_en-us_zh-cn.tmx, Master2_en_zh.tmx, Master3_zh-cn.tmx,
in case the filename format had something to do with this.
I have successfully uploaded files and trained an EN-Spanish system using the same procedure, so I am not sure what I may be doing wrong.
I would be grateful for any suggestions on where to look for errors.
We indeed identified an issue related to Chinese tmx files that we are working to resolve now. The problem is that many of the abbreviations used in the tmx files to identify Chinese simplified are not resolving properly. The work around for now is exactly what you did: to change the abbreviation used in your tmx file to identify Chinese TUs to zh-hans rather than zh, zh-chs or zh-cn.
Solved - I have managed to submit files for training by editing the TMX to globally search&replace the target language code from zh-CN to zh-Hans. – maria c laguardia 5 hours ago
I am using ubantu and trying to configure ctags on sublime text 2 for rails.
I am getting the above error message on opening my sublime text.
On re building ctags its completing within a flash without generating a .ctag file in the specified location.
My guess is that is an empty file right now. Open the file (possibly through another editor) and insert {}. The settings files are JSON objects. That just looks like it's failing the JSON parse.
You could run cat ~/.config/sublime-text-2/Packages/User/CTags.sublime-settings to see if there is anything in the file. If there is not you could freely delete it.
Though this error could be caused by a plugin that requires some configuration looking for its preferences file and failing.
I am getting the exception "ValueError: insecure string pickle" when attempting to run my program after creating a sandbox from MKS.
Hopefully you are still interested in helping if you are still reading this, so here's the full story.
I created an application in Python that analyzes data. When saving specific data from my program, I pickle the file. I correctly read and write it in binary and everything is working correctly on my computer.
I then used py2exe to wrap everything into an .exe. However, in order to get the pickled files to continue to work, I have to physically copy them into the the folder that py2exe. So my pickle is inside of the .exe folder and everything is working correctly when I run the .exe.
Next, I upload everything to MKS (an ALM, here is the Wikipedia page http://en.wikipedia.org/wiki/MKS_Integrity).
When I proceed to create a sandbox of my files and run the program, I get the dreaded "insecure string pickle" error. In other words, I am wondering if MKS screwed something up or added an end of line character to my pickle files. When I compare the contents of the MKS pickle file and the one I created before I uploaded the program to MKS, there are no differences.
I hope this is enough detail to describe my problem.
Please help!
Thanks
Have you tried adding your pickled files to your Integrity sandbox as binaries and not text?
When adding the file, on the Create Archive interface, select the options button, and change data type to "Binary" from "Auto". This will maintain any non-text formatting within the file.