I want to download data of a specific area from open street map. Whenever I try to export from openstreetmap.org it downloads the data in .osm format but I want the data to be in .pbf format. I have tried converting .osm file to .pbf file using osmconvert.exe but whenever I try to open the converted file in a text editor ( geany to be specific) it shows nothing. But when I tried opening the converted file in vim there was something but not readable. Can someone suggest me a way to download the data of specific area from open street map in readable pbf format?
For downloading area specific OSM files I would like to recommend the service of Geofabrik:
http://download.geofabrik.de/
The format .osm usually is human-readable since it's XML-structured text.
The format .pbf is not human-readable because this is a binary format. PBF-formatted OSM data are highly compressed and need to be converted (for example to .osm or to .csv) before you can read them.
Further information can be found in OSM Wiki:
https://wiki.openstreetmap.org/wiki/OSM_XML
https://wiki.openstreetmap.org/wiki/PBF_Format
Related
I have been trying to examine a JPEG file, known to contain IPTC data, but could notice no strings whatsoever. I tried the well known UNIX strings command, ASCII, 8-bit, 16-bit Unicode --- to no avail: I could not see any strings that I expect to find in IPTC fields.
My question is: How is IPTC data encoded? Is it encrypted? Compressed? Other? Why can't it be viewed using the strings command?
The most probable reason why you cannot view IPTC data using a hex viewer is because it has no IPTC data.
An image that contains IPTC data like this one:
http://regex.info/exif.cgi?dummy=on&imgurl=https%3A%2F%2Fwww.iptc.org%2Fstd%2Fphotometadata%2Fexamples%2FIPTC-PhotometadataRef-Std2014_large.jpg
has an XML structure and text fields that are view-able through a text editor like Emacs (8-bit, not even Unicode).
I have a folder of image file which have been compressed into .dat file. Since the .dat files are extremly huge(They are the microscopic image of the organ.), I don't really know what kind of tools that I can use to convert it into jpeg file. So the best case would that the whole image is split up into pieces, and I can get all the pieces of the image.
The ".dat" file suffix is used broadly, so you'll need to specify more details on what format/source software created the original data. As a guess, from a quick search of ".dat" format microscopy, these tools looks like they might be applicable to your domain:
http://gwyddion.net/
or
http://www.openmicroscopy.org/site/products/bio-formats
If you can't find a library for the format/languages you are using, then you'll need to find documentation of the file format, and write a converter (at least, the reading portion of the converter - you can use something like libjpeg to handle the writing portion.)
I downloaded big point cloud file with extension .pts and I want to convert it into .pcd format. What is the simplest and easiest way to do it?
Is .pts ASCII?
If so, you can easily write a parser for it and save it as a .pcd.
Or, if you are looking for a tool, meshlab can read in plain XYZ data and save it to .ply format (remove all header content, if there is any). .ply files are supported by the Point Cloud Library, you can either convert it or just read in the .ply.
I use SuperCSV to write Excel files. How can I add font formatting to some of the cells - strikethrough etc.?
Thanks!
If you're using SuperCSV to write an "Excel" file, you're just writing out a comma delimited file. If you need to start getting fancy and trying to add fonts, colors and other formatting tools, it may be time to step up from CSV as an output to an actual XLSX / XLSM. There is a tool out there called Apache POI. We use that on my team for when we need to have full featured Excel files. You can find it here: http://poi.apache.org/ Just be forewarned that conversion from SuperCSV to POI is not a fast or easy conversion.
We're creating an app that is going to generate some text files on *nix systems with hashed filenames to avoid too-long filenames.
However, it would be nice to tag the files with some metadata that gives a better clue as to what their content is.
Hence my question. Does anyone have any experience with creating files with custom metadata in Ruby?
I've done some searching and there seem to be some (very old) gems that read metadata:
https://github.com/kig/metadata
http://oai.rubyforge.org/
I also found: system file, read write o create custom metadata or attributes extended which seems to suggest that what I need may be at the system level, but dropping down there feels dirty and scary.
Anyone know of libraries that could achieve this? How would one create custom metadata for files generated by Ruby?
A very old but interesting question with no answers!
In order for a file to contain metadata, it has to have a format that has some way (implicitly or explicitly) to describe where and how the metadata is stored.
This can be done by the format, such as having a header that says where the "main" data is stored and where the "metadata" is stored, or perhaps implicitly, such as having a length to the "main" data, and storing metadata as anything beyond the "main" data.
This can also be done by the OS/filesystem by storing information along with the files, such as permission info, modtime, user, and more comprehensive file information like "icon" as you would find with iOS/Windows.
(Note that I am using "quotes" around "main" and "metadata" because the reality is that it's all data, and needs to be stored in some way that tools can retrieve it)
A true text file does not contain any headers or any such file format, and is essentially just a continuous block of characters (disregarding how the OS may store it). This also means that it can be generally opened by any text editor, which will merely read and display all the characters it finds.
So the answer in some sense is that you can't, at least not on a true text file that is truly portable to multiple OS.
A few thoughts on how to get around this:
Use binary at the end of the text file with hope/requirements that their text editor will ignore non-ascii.
Store it in the OS metadata for the file and make it OS specific (such as storing it in the "comments" section that an OS may have for a file.
Store it in a separate file that goes "along with" the file (i.e., file.txt and file.meta) and hope that they keep the files together.
Store it in a separate file and zip the text and the meta file together and have your tool be zip aware.
Come up with a new file format that is not just text but has a text section (though then it can no longer be edited with a text editor).
Store the metadata at the end of the text file in a text format with perhaps comments or some indicator to leave the metadata alone. This is similar to the technique that the vi/vim text editor uses to embed vim commands into a file, it just puts them as comments at the beginning or end of the file.
I'm not sure there are many other ways to accomplish what you want, but perhaps one of those will work.