I am trying to use gdal2tiles to batch-create a bunch of KML superoverlays from a set big geotiff files; problem is that the gdal2tiles output seems to be stripped of its lowest-values point (i.e. the blue ones in the first image below)
This is an example of a superoverlay created directly from Google Earth Pro (using its built-in function):
This is the corresponding output of gdal2tiles, which I generated following the instructions explained in this KML guide; particularly, this is what I did:
gdalwarp -of VRT -t_srs EPSG:4326 input.tif output.vrt
gdal2tiles.py -p geodetic -k output.vrt outputdir/
Does anyone know why this happens? Any suggestions on how to avoid it?
Thanks
Related
I am new to LiDAR technology. From the Documentation I found that we can visualize LiDAR data using Veloview software. But my aim is to create a 3D image using .pcap file and process it further for object detection. Whole working is in Ubuntu 14.04.
Can anyone provide me a good solution?
Open 6 terminal tabs (Ctrl + Shift + t):
1st tab:
$ roscore
2nd tab (run your .pcap file):
$ rosrun velodyne_driver velodyne_node _model:=VLP16 _pcap:=/path/to file.pcap
3rd tab: (create .bag file to visualize in Rviz)
$ rosrun rosbag record -O vlp_16.bag /velodyne_packets
4th. tab: (play your .bag file just created from 3rd. tab):
$ rosbag play vlp_16.bag
5th. tab: (to convert velodyne_msgs/VelodyneScan to /Pointcloud2 and /LaserScan topic to visualize in Rviz):
$ roslaunch velodyne_pointcloud VLP16_points.launch
6th. tab: (fixed frame MUST be assigned to "velodyne")
$ rosrun rviz rviz -f velodyne
In Rviz:
To visualize /scan topic:
Displays -> Add -> By topic -> LaserScan
To visualize velodyne_points topic:
Displays -> Add -> By topic -> PointCloud2
Enjoy!
I would suggest looking into using ROS and the point cloud library. There is a lot of support for this kind of processing using those. For pulling in the data form the VLP-16 you could use this ROS package.
You may use the Point Cloud Library.
Compiling PCL is a bit tricky, but once you get it going, you can do quite a lot of point cloud analysis.
Follow the instructions here for the LiDAR HDL Grabber.
For your purpose, you will want to include the <pcl/io/vlp_grabber.h> along with the <pcl/io/hdl_grabber.h>. The vlp_grabber, basically uses the same hdl_grabber but supplies the vlp calibration parameters. Also in the main, you will want to instantiate a pcl::VLPGrabber instead of a pcl::HDLGrabber.
These few changes alone may not be enough to getting a fully functional grabber and viewer, but it is a start.
The example on PCL is for the hdl_viewer_simple.cpp but there is also a vlp_viewer.cpp also located in visualization/tools/. Check that out.
This is not an answer to fully solve your problem, but provide a path to a solution if you want to use PCL.
I have found that GraphicsMagick is unable to process my files named in Chinese. I did the same test on ImageMagick but IM worked as expected.
I thought this might be a bug so I filed a bug report here: https://sourceforge.net/p/graphicsmagick/bugs/384/
Anyway, this is how to reproduce my situation:
Platform: Win10
Version: GraphicsMagick 1.3.20
Code: gm -identify 獅藝學會.jpg
This is the returned text from Command Prompt:
>gm -identify 獅藝學會.jpg
gm identify: Unable to open file (????.jpg) [Invalid argument].
gm identify: Request did not return an image.
Using IM worked:
identify 獅藝學會.jpg
ç?.è-?å-,æoƒ.jpg JPEG 3264x2448 3264x2448+0+0 8-bit sRGB 2.691MB 0.016u 0:00.004
Although the text returned is scrambled, but converting the file to a .png still maintained the same filename apart from the different extensions of course.
What happened
I found this problem by using the gm node.js library batch processing my images, the source of the call is made from a UTF-8 webpage, so I assume the filename is passed as Unicode encoding.
I found no documentation related to this problem, although the documentation states that there was a -encoding option, it cannot be sent as parameter on Windows as it does not recognize it and I cannot find relevant solutions on Google.
Please help, is there any easy way around this problem, while keeping the exact filename?
In case someone uses the C api.
(You can only give (char *)-type filenames. And UTF-8 encoding does not work, if using GraphicsMagick on Windows.)
You could do the following:
Open the file for input (or output) yourself (use fopen(), _wfopen() etc).
Then set the filehandle within the ImageInfo structure for reading and Image structure for writing respectively (instead of setting the filename).
To have GraphicsMagick generate the right output file format, set magick within the Image structure.
f.e.:
//Reading
imageInfo->file=_wfopen(input_filename,L"rb"); //ImageInfo *imageInfo;
ReadImage(imageInfo,exception);
//Writing
image->file=_wfopen(output_filename,L"wb"); //Image *image;
strcpy(image->magick,"PNG");
WriteImage(imageInfo,image);
GraphicsMagick automatically closes the file after writing/reading.
I have the same problem using GM in C++. UTF-8 filenames are not supported under Windows (not even in the API!).
My workaround is to get the short path name (8.3), you can do that both using command line and Win32. However this doesn't work 100% - and if you want to save a file you have to create an empty one first to be able to get the short name.
I'm using ST3+pandown+pandoc to convert markdown to PDF. I want to use pandown's includes_paths setting to avoid typing the path to my image directory every time. I haven't been able to get it to work, however. Here's a MWE:
I have a directory structure as follows:
text.markdown
test/img.pdf
In text.markdown, I have:
I've got set includes_paths as follows in Pandown.sublime-settings:
"includes_paths":
[
"test/"
],
But, no dice. I've also tried with an absolute path, ./test, and test. Any ideas?
I think Pandown's includes_paths only applies to Pandoc's --include-in-header, --include-before-body and --include-after-body options, not image locations etc.
From Pandown.sublime-settings about includes_paths:
Pandoc apparently doesn't search for values for its --include
arguments anywhere but the working directory, which makes
working from a standard stylesheet or standard script
sort of tedious.
A workaround, using the graphicx package loaded in the YAML header and \graphicspath:
---
header-includes:
- \usepackage{graphicx}
---
\graphicspath{{test/}}
Pandoc will say that it can't find img.pdf, but the image will be present in the final pdf.
I want to create a thumbnail view of a file type similar to thumbnails displayed in gnome/kde.
Wondering if anyone knows which libraries gnome/kde uses to display thumbnail view of different file types in Linux.
It appears there is a D-BUS specification for sending requests to a cross-toolkit Thumbnailing service called Tumber: http://gezeiten.org/post/2009/10/Using-Tumbler-in-Client-Applications
But documentation seems to be very sparse.
ImageMagick is a command-line tool and the library. This library has interfaces for C++ and Perl. Or you can also try GraphicsMagick.
The utility 'convert' from ImageMagick is often used for this.
http://www.cyberciti.biz/tips/howto-linux-creating-a-image-thumbnails-from-shell-prompt.html has an example that I have adapted here.
Given two directories, images/ and thumbnails/, this little script will convert all the images into thumbnails in the other directory, with 'thumb.' at the start of the filename :
#!/bin/bash
for i in images/*
do
echo "Prcoessing $i ..."
/usr/bin/convert -thumbnail 200 "$i" thumbnails/thumb.$(basename "$i")
done
I am trying to split a PDF into 2 smaller PDF's using gs (Ghostscript version 8.62
on Debian Lenny). I only have Debian Linux on hand, so please don't offer Windows or Mac solutions.
When specifying -dLastPage=740, I receive the error:
GPL Ghostscript 8.62: ERROR: A pdfmark destination page 1203 points
beyond the last page 740.
I have scoured the Ghostscript documentation for how to disable
pdfmark entirely (I don't need links or bookmarks for a straight-to-
print pdf). -dDOPDFMARKS=false does not work.
I've scoured the internet for anyone reporting a similar error. I
haven't found a solution yet.
Please help!
For reference, the command I'm using is:
gs -dSAFER -dBATCH -sDEVICE=pdfwrite -DNOPAUSE -sPAPERSIZE=halfletter -
dFIXEDMEDIA -dEmbedAllFonts=true -sOutputFile=library.1of2.pdf -
dLastPage=740 -dPDFFitPage library.pdf
Give CAM::PDF a try (note: I'm the author). The syntax would be:
deletepdfpage.pl library.pdf 741- library.1of2.pdf
deletepdfpage.pl library.pdf -740 library.2of2.pdf
or programmatically, it would be roughly like this:
use CAM::PDF;
my $pdf = CAM::PDF->new('library.pdf') || die;
$pdf->deletePages('741-');
$pdf->cleanoutput('library.1of2.pdf');
It's open source and it's pretty fast, too.
As it turns out, the error is not fatal. The pdf is generated anyhow, and since I do not care about pdf links or bookmarks functioning, this problem is solved for me.
In general, though, it would be good to know why pdfmark or ghostscript is failing, and how to generate a valid pdf with functioning links. If anyone has an answer, I'd still like to hear.
You should ask a new question which details exactly how and where you want to generate what kind of "PDFs with functioning links".