I have a .dat file https://www.dropbox.com/s/8dbjg0i6l7a4sb6/CRUST10-xyz-complete.dat?dl=0 that I need to convert to either .grd or .nc, so that I can visualize the data in GMT(Generic Mapping Tool). I tried to do this using cdo using following command:
cdo -f nc import_binary CRUST10-xyz-complete.dat CRUST10-xyz-complete.nc
but got following error:
Open Error: Unknown keyword in description file
--> The invalid description file record is:
--> 0.5,89.5,4.19,0,2,0.7,0,0.73,1.62,5.01,14.25,10.06,7.36,2.7,1.5,3.81,2,3.5,0,5,6.5,7.1,8.07,5.5865805168986,6.7596467391304,2.3888888888889
The data file was not opened.
cdo import_binary (Abort): Open failed!
Can anyone please guide?
First make .ctl file then apply:-
cdo -f nc import_binary CRUST10-xyz-complete.ctl CRUST10-xyz-complete.nc
Here is the example link for to make .ctl file. http://cola.gmu.edu/grads/gadoc/descriptorfile.html
It will definitely work for you. Thanks!
Without the data itself, it is hard to see what went wrong. In any case, just look at the following message from cdo forum:
https://code.mpimet.mpg.de/boards/1/topics/3631
which you could use as an example of how to convert ASCII data to netCDF using cdo's.
Related
I have a google protobuf file from OpenStreetMap, specifically I have the 1.4MB Liechtenstein country extract from Geofabrik. The protoc command says it "write the raw tag/values to stdout" with the --decode_raw option. However I keep getting this error:
$ cat liechtenstein-latest.osm.pbf | protoc --decode_raw
Failed to parse input.
I have compiled and installed the protobuf library direct from Google, version 2.6.1 which is the current one.
This file is valid, various OpenStreetMap tools that read pbf files (osm2pgsql, osmosis) can read it fine.
What could be wrong? How can I get --decode_raw to work? Am I doing something wrong?
The OpenStreetMap .osm.pbf format is not a raw protocol buffer. The format is documented here:
http://wiki.openstreetmap.org/wiki/PBF_Format
Key quote:
The format is a repeating sequence of:
int4: length of the BlobHeader message in network byte order
serialized BlobHeader message
serialized Blob message (size is given in the header)
So you need to read four bytes first, interpret them as an integer (big-endian), then read that many bytes and parse as a BlobHeader, and that in turn will tell you how many bytes to read and parse as a Blob.
The protoc tool will not do this automatically since it doesn't know this format. Probably there is an OSM-specific tool out there that you can use.
I am using an FTP server which, while listing the files using e.g. ls command, returns the last modification date in following format:
05/06/12
Is there a way to know what date format the remote server is using?
There is no definition about date format in the listings, it is not even defined that the listings should include the date at all. So you can only guess if you need to parse the listing. For a reliable and defined way to get the modification time of a file use the MDTM command. Unfortunately you need to send this for each file which could make everything slower.
I have a simple .csv file.
Is it possible to convert it to .xls using the command line tool ssconvert?
I would also need to specify the name of the sheet.
ln -s input.csv MySheetName
ssconvert MySheetName output.xls
The OP asked how to convert csv to xls while controlling the sheet name in the output.
The generated .xls file will use the name of the input CSV file as the sheet name, so you can symlink the .csv to anything you want (or rename the input file) to produce the desired result.
The previous answer implies that --list-exporters leads to a solution, but it merely lists exporter names with no information about their options, and no options are documented in the man page for xls-exporters. Experimentally, none of the exporters which can create .xls accept options (they fail with "The file saver does not take options" if you use -O).
Yes, it is possible.
You must specify names with extensions as input and output files.
For example:
ssconvert in.csv out.xls
Using --list-importers and --list-exporters options can take a look to available formats.
am trying to extract to use all my box file to extract characters and when i try this line
unicharset_extractor *.box
it gives me an error that it cannot find *.box instead of loading all box files.
That specific program does not support such syntax. You have to chain the names of all the box files and feed to it, such as:
unicharset_extractor lang.fontname.exp0.box lang.fontname.exp1.box ...
You can write a script (e.g., train.ps1) to automate the process.
http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3
I finally made my own tool for that .
[link]http://code.google.com/p/serak-tesseract-trainer/
The .XFDL file extension identifies XFDL Formatted Document files. These belong to the XML-based document and template formatting standard. This format is exactly like the XML file format however, contains a level of encryption for use in secure communications.
I know how to view XFDL files using a file viewer I found here. I can also modify and save these files by doing File:Save/Save As. I'd like, however, to modify these files on the fly. Any suggestions? Is this even possible?
Update #1: I have now successfully decoded and unziped a .xfdl into an XML file which I can then edit. Now, I am looking for a way to re-encode the modified XML file back into base64-gzip (using Ruby or the command line)
If the encoding is base64 then this is the solution I've stumbled upon on the web:
"Decoding XDFL files saved with 'encoding=base64'.
Files saved with:
application/vnd.xfdl;content-encoding="base64-gzip"
are simple base64-encoded gzip files. They can be easily restored to XML by first decoding and then unzipping them. This can be done as follows on Ubuntu:
sudo apt-get install uudeview
uudeview -i yourform.xfdl
gunzip -S "" < UNKNOWN.001 > yourform-unpacked.xfdl
The first command will install uudeview, a package that can decode base64, among others. You can skip this step once it is installed.
Assuming your form is saved as 'yourform.xfdl', the uudeview command will decode the contents as 'UNKNOWN.001', since the xfdl file doesn't contain a file name. The '-i' option makes uudeview uninteractive, remove that option for more control.
The last command gunzips the decoded file into a file named 'yourform-unpacked.xfdl'.
Another possible solution - here
Side Note: Block quoted < code > doesn't work for long strings of code
The only answer I can think of right now is - read the manual for uudeview.
As much as I would like to help you, I am not an expert in this area, so you'll have to wait for someone more knowledgable to come down here and help you.
Meanwhile I can give you links to some documents that might help you:
UUDeview Home Page
Using XDFLengine
Gettting started with the XDFL Engine
Sorry if this doesn't help you.
You don't have to get out of Ruby to do this, can use the Base64 module in Ruby to encode the document like this:
irb(main):005:0> require 'base64'
=> true
irb(main):007:0> Base64.encode64("Hello World")
=> "SGVsbG8gV29ybGQ=\n"
irb(main):008:0> Base64.decode64("SGVsbG8gV29ybGQ=\n")
=> "Hello World"
And you can call gzip/gunzip using Kernel#system:
system("gzip foo.something")
system("gunzip foo.something.gz")