We actually use this as an interview question. I agree with jk, you should use a third party library, but I'll give you an idea
First storing this data as an image is the wrong approach. We actually word our question to immediately direct people away from this approach. You really want to store individual roads or features as a series of points (preferably using splines so you can efficiently represent curves) and then render the correct roads. Now because you're using vector (rather than raster) data your scaling and rotation issues are solved.
You were going down the right path when you discussed breaking it into smaller squares. Each square should contain data about all of the roads that pass through it. If a road crosses an edge, break it into two road pieces, one in each square. That way each square has enough data to render itself completely.
Looking up the squares you need to draw can be a bit of a pain, but no worse than you had to solve with images. Personally I'd store a bunch of data structures in a binary file with an index at the beginning, listing where each square begins in the file and how long it is. That way you can read the data for the square pretty efficiently (jump to correct position in TOC, read TOC data, jump to start of square, read square data). You could even optimize for empty squares sharing space.
Last, you'll probably want to do different levels of zoom. Personally I'd store a completely separate set of blocks at a few different zoom levels. That way you can vary the size of the block as appropriate.
Again, to reiterate, use a product off the shelf, but there's no problem using this as a gedankenexperimente.