01.16.10

1862

Posted in programming at 9:43 pm by paul

I made previous reference to a scan available online of a map of San Francisco and my intention to put that map on a Google Map. Well, I’ve spent way more time on it than I anticipated but it finally, actually works as I originally envisioned.

Challenges:

  1. Google Maps are aligned with “true north”; the old map is aligned with some other north, possibly magnetic north at the time the map was made
  2. the horizontal and vertical scales are not the same
  3. the old map apparently fell apart and was taped back together; this was not done perfectly and there are a few small gaps and missing bits
  4. the scale tends to vary over relatively small distances; agreement between the tiles I generated and Google’s tiles can wander even within one tile

I ultimately decided not to fix items 3 and 4. Fixing the gaps tended to do more harm than good and scale variances require far more graphics-fu than I am ever likely to have.

If you want to cut to the chase & see the map, it is here.

Here is what I did: Read the rest of this entry »

01.07.10

neighborhood

Posted in house, programming at 7:50 pm by paul

I tweeted a few days ago about an article on SFGate about the little street we live on. A couple days after that, the SFist posted an old map of the city from 1862.

Take close look at the map, in the lower left corner. If you follow Market Street to the lower left corner, near a large number 11 is “Kate Street”. This street no longer exists, and it leads to an area labeled “Hospital Area”; this is now Duboce Park and three cul-de-sac blocks of homes, one of which is now Potomac St. It’s fun to see the map agree with what I read in the book by Harry Nimmo referenced in the article.

I am entertaining a fantasy of creating a Google Map of the area and replacing the tiles with the old map. Hopefully I’ll actually get to that.

UPDATE: I’ve checked the Google Maps API, and it seems what I need to do is a “Custom Map Type”, which The Google deems an “Advanced Topic.” They put this in red; I may be in over my head!

01.02.10

macports

Posted in Mac, programming at 2:05 pm by paul

I thought it might not be the worst time to get more involved in a project I rely upon a great deal: MacPorts. Not really a resolution, but the New Year is not totally a coincidence.

Like most open source projects, you can’t just waltz in and start claiming to understand everything and submitting patches and opening and closing tickets. There is a circle of people that control access and you have to curry favor with/impress/gain cred with them before you can make any real contribution.

I thought I’d browse through some tickets, and see what I could contribute. What I found was, that for numerous tickets, there was already a fix posted, but that fix had not been committed. Not only that, but the method for actually applying the posted fixes is:

  1. download the patch to the sources
  2. download the patch to the port itself
  3. extract the port sources with port extract
  4. apply the patches: cd `port dir screen`
    sudo patch -p0 < ~/patch-screen.diff
    cd work
    cd screen-4.0.3/
    sudo patch -p1 < ~/screen-4.0.3-snowleopard.patch
  5. build & install screen with port install screen

In defense of the maintainer of this particular port, to experience this bug you need add a line to your .screenrc that explicitly calls the default shell as a login shell with a line like this:

shell -$SHELL

My real point is that there are any number of bugs that are the same, and an apparent shortage of people to just plug them in. Macports community: where can I dig in?

12.16.09

eyetv

Posted in Mac, fun, programming, toys at 10:30 pm by paul

I’ve been using an EyeTV device as a PVR for a while, and one of the features I felt was missing was the ability to stream the recordings.

After finding a few posts that showed how to accomplish this, I was struck by how primitive these were. So I set about making things a little more robust.

First up was to check out the file format that EyeTV uses to store the recordings, which is something called “MPEG Transport Stream”. Naturally, the now-1.0 VLC project can read these files.

Getting the files to a VLC player involves:

  • reading the XML that EyeTV keeps the program data in
  • converting this to a playlist format that VLC will understand
  • streaming the media files

Fortunately, VLC is happy to read an HTTP “stream”, that is, to fetch chunk of a media file, about 1 MB at a time, via HTTP. So that part was easy: set up a directory containing the media accessible via HTTP.

The playlist format was also pretty straightforward: XSPF is capable of carrying the (pretty basic) information required, and there is a Perl module available to write it.

The good news is that all of this was a bit of a drag to figure out, but pretty easy to understand. I’ve even got the index.pl if you think you might be able to make use of it. You’ll need to figure out a bit about paths and setting up mod_perl, but you understood all that already, right?

04.30.09

difference

Posted in programming, work at 5:25 pm by paul

You should not ever have to figure this out: the difference between the Unix and Visual Basic epochs is 2212147696.

This will come in handy if you ever find yourself in a position where you need to call VB methods from Perl, and then process the date in Perl. I, for example, find myself compelled to use the COM/VB API of a vendor’s product to extract log data and stuff (really, copy) into a tracking database. The database is supported by a Perl module, making it easier to process all the data. I had no inkling to rewrite (and then maintain) it in Visual Basic, and time/date logic is an important part of the requirements.

So that’s it. The Unix epoch is January 1, 1970 and the Visual Basic epoch is January 1, 100. Perl’s DateTime and Time::Local modules do not handle the year 100 well, so one cannot simply get a Unix time in seconds for that date.

As far as I can tell, this fact is documented nowhere else.