I don’t mind if I’m incomprehensible

Archive for December 2007

Campus Map Part II (of I): Nothing is Ever Simple

leave a comment »

I received a bit of feedback on my previous post.  Based on that, I’ll write more about some stuff we did because we had to.

There wasn’t an introduction to the project last time, so here’s a quickie.  Store GIS data in MySQL, deliver that data to the Google Maps API with PHP, profit!

Whining Mode: On.

The first issue wasn’t so much that there was no existent solution, but more why the hell was it so hard to find.  I’ve already mentioned in the previous post that we need to generate map tiles, and since we are stacking images, these tiles need transparent backgrounds.  And I don’t mean your one color transparency with ImageColorTransparent, but fit for the 21st century alpha channel transparency.  (Partly because IE6 requires it; amazingly one color transparency backgrounds worked in the modern browsers.)

This should be easy.  And it is once you figured out the right functions to call, but getting there was a pain.  I don’t know if it was the poor documentation in the PHP manual, the bad examples I saw, or I was just sleep deprived and really dumb.  It was probably all three ingredients with some weak sauce thrown in for that extra FAIL flavor.

At the beginning when I was just learning the GD functions by creating simple sample images, I’d manage to get PHP segfault on me.  Not an error message, not an exception, but segfault!  Just for calling a certain combination of GD functions.  (Not sure if order mattered.)

Anyway, I just wanted to bitch.

After I had the tiles working, I wanted to add anti-aliasing to them.  Luckily, GD’s ImageAntiAlias “does not support alpha components”.  Did I say “luckily”?  I mean “WTF, FINE!”  Learning from a user comment in the PHP doc, I made the original “master” image much bigger, and then used ImageCopyResampled to create the scaled down, pseudo-anti-aliased tiles.

They look much better.  But of course now the tile generation process is even slower (while keeping the memory footprint the same).

MySQL stores the GIS data in some sort of binary format.  There are no corresponding native PHP types.  That means whenever we retrieve data, we’d need to wrap AsText around the appropriate fields.  And then parse the returned text into something useful with regular expressions.  Now I have two problems.

Actually, I’ve got three.  CakePHP doesn’t provide a way to wrap a MySQL function around a column for its built-in find methods, nor does it offer a way to register callbacks on the records returned, so I can have CakePHP automatically perform the parsing.  (We’re using CakePHP, because, um, it’s the kind of the default around the office.  It’s far better than no framework at all.  But not awesome enough for me not to curse at it.)

Yep, had to cheesy hack that stuff in.

In the previous post I said one of the consequences of using tiles was having to move the click handling to PHP, i.e. whenever someone clicks on the map, send the latitude/longitude back to the server to check if she clicked on something (building, parking lot, whatever).  Since MySQL already has functions that test relationships between geometries, I can just use it for this purpose.

O Reader, surely you’ve noticed the pattern and know what’s coming…

Not if I RTFM!  “Currently, MySQL does not implement these functions according to the specification. Those that are implemented return the same result as the corresponding MBR-based functions.”  OMG wut good iz u then!?  A solution was implemented in PHP instead.

No choice really.


Written by Barry

December 28, 2007 at 6:07 am

Posted in Nerdy

Campus Map Part I (of I): Generating Tiles

leave a comment »

Wil has on a couple occasions encouraged me to give a presentation on at PDXPHP about the campus map project I worked on recently.  But I don’t think there are enough interesting and useful stuff for a talk.  So I do the next worse thing: write a bit about it on my blog.

When we first started the project, we wanted to use the Google Maps API as much as possible.  That means we used GPolyline and GPolygon to display all the elements on the map.  Unfortunately this produced a huge performance penalty.  Each element was rendered on the map with an image, so just to display all the buildings on campus, the map would have to load…well, a lot of images.

So we decided were forced to use tiles.  We’d lose the nice hover effect for the elements and have to move the click handling to PHP.  And of course, generate the tiles from the GIS data in MySQL.

The basic approach was:

  1. Get the layer from the database and turn its minimal bounding rectangle (MBR) from latitude/longititude into pixel units, per the current zoom level.  Then create a blank image with GD.
  2. Grab all the elements that belong to the layer and draw them on the image.
  3. Slice the master image into tiles and save them onto the appropriate locations on disk.  Since it’s unlikely that the layer’s width and height are perfectly divisible by 256 (did you read that tiles link??), we’ll have to do some arithmetic for offsets for the western and northern edges.  No big deal.

Simple and straight forward right?  Yes, it’s a simple and straight forward way to use up all the memory on the server.  At the higher zoom levels, the master image can get ginormous.

(Oh yeah, a layer is just a map with a grouped (logically, one hopes) set of things.  Buildings, student parking lots, dorms, etc.  A user can view just one layer or multiple simultaneously.)

Since generating an image for an entire layer is pretty much the same as generating an image for a part of it, recursive divide and conquer is the natural solution.  And that whole thing about the offsets with the edges was kinda dumb, or maybe just silly; we could simply make the master image’s dimensions a bit larger so they are divisible by 256.  No harm in pretending the MBR is a little bigger.

So now #1 above is now:

  1. Accept a MBR.
  2. If image is going to be too wide, slice vertically into halves.  If image is too tall, cut image(s) horizontally into halves, or quarters if it was also too wide.  Go back to the beginning with these pieces.
  3. Or, if the image isn’t too tall or too wide, then proceed.

This is of course slower.  Not because of the recursion (negligible really), but the increased number of database hits, especially at a high zoom level.  But compared to the drawing function calls and file writes… who cares.  :-P

There.  Done.  Not a single line of code, too.

Unfortunately, there isn’t a public preview of the project yet.  Jose and Montana are the other main developers on the project, maybe they’ll chime in on some of the stuff they’ve worked on.

Next time, I’ll bitch about GD and MySQL… except there isn’t a next time.  Lucky you.

Written by Barry

December 17, 2007 at 10:29 pm

Posted in Nerdy

The Data Has Spoken

leave a comment »

A lot has been written about Asian men not being able to get with the ladies.  (Google it.  Or go read the rants at Bitter Asian Men for lulz.)  And now we’ve got data, people!

The study: “Racial Preferences in Dating“.

Yo, a table:

(Click on the image above and a larger version will magically appear.)

Or, in words:

Finally, we can reject the hypothesis of equal preference against partners of other races for white, black, and Hispanic subjects, owing largely to the greater preference against Asian males by all other races.

“All other races” eh? Good, consistency.

For extra lulz, notice that Asian men said yes to more white women (53%) than any other race.  So to summarize, Asian men <3 white women, while white women respect their math skillz, from a distance.

Not that this should discourage us Asian men.  It just means that we have to work harder.  0.16 is not zero.

The data also shows that white women are the pickiest.  I wonder why that is.

On attractiveness:

For male partners (column(1)), our main finding is that Asians generally receive lower ratings than men of other races. In fact, when we run the regressions separately for each race, we find that even Asian women find white, black, and Hispanic men to be more attractive than Asian men.

Again, we win at consistency.

But there’s also this:

We similarly find that female Asian partners are consistently rated as less attractive (column (2)), though we also find that black females receive significantly lower ratings relative to whites. As above, we find that when these regressions are run separately for each race, even Asian men find white, black, and Hispanic women to be more attractive than Asian women.

What? So much for the whole white guys with “Asian fetish” stereotype.

Written by Barry

December 15, 2007 at 11:56 pm

Posted in General

PDX Coders Bash

with 2 comments

I went to the Coders Bash  last night in Portland with Wil and Montana.  (Lol @ Wil’s super short notice.  It was awesome of him for driving.)

Now photos, with colours!

Montana and Wil enjoying some hot cornholing action.

Here are some people that are smarter than me.  And yes, there were women in attendance.

It was a card game involving words and lulz.  I’ve never heard of the card and board games that were available.

Let me explain.  I didn’t find the carpets or my jeans that particular interesting.  That was right about when Wil hit me with a projectile, a bag of corn, extremely near my baby-maker, my “penis” if you will.  (It was pretty funny.  I’m okay.)

I’m disappointed that we didn’t play “Best WTF snippet” though.  As a professional PHP developer, I could’ve totally won by just doing what I do at work.

Written by Barry

December 12, 2007 at 10:51 pm

Posted in General, Nerdy