Tag Archives: open source

Re-enable virtual terminals on Ubuntu 12.04

1 Reply

In the past month I’ve been getting accustomed to Ubuntu 12.04, and all of the changes it brings to the user interface of Ubuntu. One issue I’ve been especially bothered by is the lack of virtual terminals, at least of users of NVIDIA’s proprietary drivers (myself included). The issue seems to stem from the fact that Ubuntu 12.04 makes use of a hardware framebuffer to draw a splash screen on boot, which causes issues with the driver when attempting to switch virtual terminals. I had a hard time finding any solutions to my problem, until I found this post on AskUbuntu which gives a couple suggestions. While the poster suggests going all out and completely disabling graphical boot, he also suggests a less drastic solution, adding a flag to the linux boot options that prevent loading framebuffer modes that interfere with virtual terminals.

To do this, open /etc/default/grub in a text editor and find the line that reads

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

and change it to read

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=normal"

Rebooting your computer should leave the grub menu and boot splashscreen unchanged, while the virtual terminals work perfectly! Of course, your mileage may vary, depending on your system. This works for me on a fully updated install of Ubuntu 12.04, with an NVIDIA 9800 GT.

IndieWeb, or how to avoid Digital Sharecropping

Leave a reply

Thanks to the DorkbotPDX blog I found my way onto the website of this year’s IndieWebCamp, which took place in Portland June 25 & 26. Although I was saddened that I wasn’t in town for it, the projects that ended up being developed by the camp immediately grabbed my interest.

Although I had never been aware of the term “indie web” (which seems to have been around for almost 15 years, judging by this article from uzine.net), I’ve been building my own independent web presence for more than four years. In the words of the IndieWebCamp home page:

Rather than posting content on many third-party silos of content, we should all begin owning the content we’re creating. Publish short status updates on your own domain, and syndicate to Twitter. Publish photos on your own domain, syndicate to Flickr, etc, etc.

For some good summaries of the ideas and goals of the IndieWebCamp, this article from GigaOm and this post from Mark Hendrickson are a great place to start, while each of the camp’s guests also have their own websites, each with a wealth of information.

While I’ve been using this domain for quite a while, it’s been in use alongside Facebook, Delicious (and Flickr, to a smaller degree) as a part of my web presence. However, since I ditched Facebook five or six months ago, I’ve been relying on this domain for more, and overall I’ve been pleased. However, as the IndieWebCamp is readily willing to admit, there is room for a lot of room for technical innovation in expanding the functionality of the indie web. Towards that end, I see three threads of work that I’m interested in pursuing:

  • Using my site for Flickr-like photo sharing. While this might include syndication to Flickr at some point, I mostly want a light-weight DIY solution to photo sharing.
  • Similarly, using my site for bookmarking. I really like the service that delicious offers, but I want to own the data and let delicious simply keep a copy of it (see http://adactio.com/journal/4197/ for some ideas).
  • Finally, I’m hugely enamored of the work on delivery-agnostic messaging that took place at IndieWebCamp, which you can find details of here. Not only is it a ridiculously simple protocol, but it starts to address some real issues of a distributed social web, in that it allows two-party communication based solely on domain names as unique identifiers, therefore eliminating the middleman in social-web-type communications.
Hopefully I’ll have time to get one of these ideas worked out and running on my site soon (before school starts), so check back here soon, I’ll be sure to keep you posted.

Map Tiles with Python + GDAL

1 Reply

After getting GPSDrive running on OS X I started looking into different sources for maps. The GPSDrive wiki has a couple of interesting pages about this: one on creating maps and one on map sources. The second page pointed me to the LibreMap Project which has a complete collection of  USGS 1:24000 (large scale) topographic maps for the entire US. These files are distributed as high-resolution GeoTIFF files, along with world files, so the maps are fully geotagged. This means that they contain all of the information needed to generate GPSDrive-friendly map tiles, but GPSDrive will not read them directly. The creating maps page gives some (heavily out-of-date) advice on how to use the gdal_slice.sh script distributed with GPSDrive to create map tiles using the tools from GDAL. Sadly, this script is completely unusable on OS X, because of incompatibilities in the command line tools that are used by the shell script. After spending about five minutes trying to tune it to work with the tools that Apple ships, I completely gave up and looked into other approaches.

Luckily, I quickly found out that GDAL ships with Python bindings. I installed GDAL from source using the instructions from their wiki. To make sure it built with Python modules I ran ./configure –with-python. After that make and sudo make install ran without a hitch.

I then set about re-implementing gdal_slice.sh in Python. Once I got a handle on how to use the Python bindings it was fairly easy to write. You can find the script here.

Using gdal_slice.py is very similar to using gdal_slice.sh:

$ ./gdal_slice.py -h
Usage: gdal_slice.py [options] FILENAME

Options:
  -h, --help            show this help message and exit
  -o OVERLAP, --overlap=OVERLAP
                        percentage tiles will overlap. should be at least 20%
  -a, --add             write map info to map_koord.txt in current working
                        directory
  -m, --map             use *_map folders for output; use if input image is
                        UTM. Default behavior
  -t, --topo            use *_top folders for output; use if input image is
                        not UTM
  -v, --verbose         enable debugging output

The biggest difference is that gdal_slice.py does not perform any format conversion; it will write maps to TIFF files. Although the file size is decidedly larger than that of PNGs, my version of GDAL is unable to create PNGs, and disk space is (fairly) cheap. If I’m motivated I’ll get around to adding a format option, at least to allow conversion to PNG.

Running gdal_slice.py filename.ext will create a folder named filename_map (or _top, if you use the -t flag) that contains a set of 1280×1024 TIFF files, as well as a map_koord_draft.txt file. Moving this folder into GPSDrive’s map directory, and merging filename_[map|top]/map_koord_draft.txt with map_koord.txt will make the new maps available to GPSDrive. Note that filename.ext must be in the current working directory, as the script handles filenames/paths somewhat naivëly.

So far I’ve only tested this with GeoTIFFs from LibreMaps, but it seems to work great, with the caveat that LibreMaps’ files include the borders of map, and my script doesn’t do any cropping, so you see borders if you’re near the edges of quads. This doesn’t bother me terribly much, but you may need to turn mapsets on and off in the Map Control dialog to see the appropriate images.

Update 7-14-11: I’ve modified the script with an additional flag (-a) that will automatically merge the generated map_koords file with map_koord.txt in the current working directory. This means that if you run the script from inside .gpsdrive/maps with the -a flag the generated tiles will be automatically added to GPSDrive’s database. The script avoids creating duplicate entries in map_koord.txt, as well as alphabetizing all entries.

I’ve modified the documentation here, as well as the links, to reference the latest version.

GPSDrive on OS X

2 Replies

After getting GPSd to compile on OS X, I set my sights on GPSDrive, an open source navigation and map viewing program. When I posted about GPS a couple years ago, I installed GPSDrive, using the version from Fink. However, the latest version of GPSDrive on Fink nowadays is 2.08pre12, while the latest stable release is 2.11. I’ve also moved away from using Fink and/or MacPorts for package management in favor of Homebrew.

To get GPSDrive running I had to do a little bit of fiddling, but it’s fairly easy. First off, I needed to downgrade GPSd from 2.96 to 2.95 — apparently the newest version introduced slight changes to the library that GPSDrive hasn’t yet picked up. However, building the two versions is exactly the same — see my post on building 2.96 for instructions that apply to 2.95. You can get the source package for either version here.

Next I used homebrew to install the dependencies that GPSDrive needs by running brew install gtk+ cairo gtkglext postgresql gettext. Note that these are just the packages I didn’t have going into the build — you may need more, depending on your setup.

With preliminaries out of the way, I downloaded gpsdrive-2.11 from here. As per their build instructions I created a build directory (mkdir build), moved into it (cd build), and then ran cmake. After some serious wrestling with dependency locations and linker flags I figured out the following two steps to get GPSDrive to compile and build.

First, because GPSDrive seems to want to automatically link against libcrypt, which OS X bundles in it’s libc, you need to tell cmake not to use it. I couldn’t figure out how to do with with a cmake configuration option, so I edited gpsrive-2.11/src/CMakeLists.txt and commented out (put a # in front) of the two lines containing the word “crypt”. You could also delete these lines — it has the same effect. This is along the lines of the patch here (see the attachment), that was posted to the GPSDrive mailing list last year, when I pointed out this bug. Sadly, the patch has not been applied to the source tree yet, but I can attest it works, if you care to apply it yourself.

With that out of the way, we can now run the following command from inside the build directory.

cmake -DCMAKE_BUILD_TYPE=Debug\
 -DWITH_FRIENDSD=OFF\
 -DWITH_KISMET=OFF\
 -DWITH_MAPNIK=OFF\
 -DWITH_POSTGIS=OFF\
 -DWITH_SPEECH=OFF\
 -DLIBGPS_OLD=OFF\
 -DGTK2_ATK_INCLUDE_PATH=/usr/local/Cellar/atk/2.0.0/include/atk-1.0\
 -DGTK2_GLIBCONFIG_INCLUDE_PATH=/usr/local/lib/glib-2.0/include\
 -DGTK2_GLIB_INCLUDE_PATH=/usr/local/include/glib-2.0\
 -DGTK2_PANGO_INCLUDE_PATH=/usr/local/Cellar/pango/1.28.4/include/pango-1.0\
 -DGTK2_CAIRO_INCLUDE_PATH=/usr/local/Cellar/cairo/1.10.2/include/cairo\
 -DGTK2_GDKCONFIG_INCLUDE_PATH=/usr/local/Cellar/gtk+/2.24.4/lib/gtk-2.0/include\
 -DGTK2_GTK_LIBRARY=/usr/local/lib/libgtk-x11-2.0.0.dylib\
 -DCMAKE_C_FLAGS="-I/usr/local/Cellar/gdk-pixbuf/2.22.1/include/gdk-pixbuf-2.0"\
 -DCMAKE_EXE_LINKER_FLAGS="-lgdk_pixbuf-2.0.0 -lpango-1.0.0 -lgobject-2.0.0 -L/usr/local/Cellar/gettext/0.18.1.1/lib -lintl"\
 -DMSGFMT_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt\
 ..

After cmake generates all the necessary files, you can run make, and assuming it doesn’t give you errors, ./src/gpsdrive will allow you to test your newly built executable, and sudo make install will install it.

Once GPSDrive is up and running you should be able to see your current location (assuming you have a GPS connected to GPSd). If you want to get maps, you can download them from within GPSDrive, which has support for OpenStreeMap tiles, as well as NASA Landsat images (although I haven’t been able to get Landsat to download correctly).

GPSd under OS X (revisited)

4 Replies

It’s been almost 2 and half years since I originally posted about GPSd and OS X. That post got quite a bit of traffic for a while, but a whole lot has changed since then. If you’re interested in some in-depth background information, you should check out the old post; this post is mostly about the changes in the GPSd project since then, and the process of getting it running on OS X.

Two and a half years ago, GPSd had just released version 2.38. The latest version, which I just downloaded, is 2.96. Most significantly, GPSd has updated their communication protocol from a simple character-command format to one based on JSON-packed data. Further, they’ve built a significant portion of the project around python, and consequently built better python interfaces into the project.

OS X has also been updated, from whatever 10.5.x was current three Januaries ago, to 10.6.8. Luckily, the under-the-hood changes that Snow Leopard brought to the table should only make compiling software easier.

Building GPSd is a whole lot easier than it was the last time I went through all of this. I downloaded the latest source package (from http://prdownload.berlios.de/gpsd/gpsd-2.96bis.tar.gz). The bundled INSTALL file lists only python and py-gtk2 as dependencies, which makes compilation easy, given that python comes bundled with OS X. Although py-gtk2 is available through MacPorts (using sudo port install py-gtk2) I chose to avoid install the ridiculously long list of dependencies that it requires, as it is only required for the graphical test client (xgps), and GPSd also ships the perfectly functional command-line tool cgps, which provides the same information, albeit in a more sparse manner.

The actual build process is surprisingly easy: I ran ./configure –x-includes=/usr/X11R6/include, as suggested by the INSTALL file. As this indicated no issues, I ran make and sudo make install, which ran without a hitch, and gave me a working set of gps tools.

At this point it is possible for me to attach my GPS (see my old post for information about getting devices up and running), run gpsd -n /dev/cu.usbserial, and then use cgpsto get coordinates, date, and satellite information. However, this isn’t everything — all of the python based GPSd tools, such as gpsprof, still don’t work. This is because of Apple’s slightly special python distribution — while GPSd’s sudo make install puts python modules into /usr/local/lib/python2.6/site-packages/, they need to be in /Library/Python/2.6/site-packages/. Instead of having to install these manually, you can use the bundled python install script to put the modules in the correct path by running sudo python setup.py install (thanks to http://docs.python.org/install/index.html).

Now that I have the most recent GPSd up and running I’m hoping to do some fun things with it. If I do, you’ll see it here!

GPSd under OS X

6 Replies

Update 7-13-11: I’ve posted an updated set of instructions on getting GPSd to compile on OS X here; this post will remain for archival purposes. For information on installing GPSDrive, see this post.

So I recently picked up a cheap GPS module on Amazon. It was about $30 with shipping, and I got a neat little dongle which connects over USB to my computer and communicates with software. It didn’t come with support for OS X (although interestingly enough it shipped with Mac OS 8 and 9 drivers), but it promised to send generic NMEA-0183, so I wasn’t too worried.

When it showed up, some quick software probing revealed that it houses a usb to serial adaptor (a Prolific PL-2303, which I’ll get to in a bit) and a gps module that’s configured to send NMEA strings through the virtual serial port. This sort of information is compatible with a host of software, but most of it is commericial, and only available at a considerable price.

Luckily, there’s a wonderful open source project called gpsd which provides support for a wide raft of devices and protocols, and talks to an even wider assortment of software. Primarily, I wanted to be able to get my gps to talk to the network scanner Kismac, and Randall Munroe’s cyborg.py script. Both of these were built to take information from gpsd, so I was in business. However, gpsd, which is designed to play nicely with Linux, takes some coaxing under OS X. This is meant to describe how I got it all running. Continue reading →