You need an appvar. I will explain how to create one later since I am on my phone at the moment and typing is a pita.
Welcome to omnimaga by the way!

And as for world maps: it really depends on the application. If your world consists of screens of tiles you should organize your data in a different manner than if your world consists of a large tile map. As for compression: If you only use 16 different tiles you can store two tiles in every byte instead of just one per byte. If you want to go even further you can replace all zero tiles with a zero followed by the number of zero tiles until a new kind of tile occurs. This technique is only suited if there is just a single tilemap in your appvar or if you indexed where all tilemaps start.
Example for storing 2 tiles in one byte:
.Not actual sourcecode:
.tile1 = 7
.tile2 = 3
.tile1 << 4 | tile2 = $73
.Axe syntax:
[73]Example for compressing zero tiles:
[15 00 26 00 00 00 00 00 00 00 00 24 A5]
.becomes
[15 00 01 26 00 08 24 A5]
.Downside to this technique is that single zero's will take up more space.
.Now to decompress:
.if the byte = 0
.load counter with next byte that defines the amount of zero's that should be inserted
.do
.  insert 0 tile
.  counter decrease
.while counter is not 0
.when the counter runs out go to the next tile and repeat the process until you aquired enough tiles.


Another efficient compression method is the one deeph and chickendude showed me. Basically, it is RLE, but with a special treatment for isolated tiles. The only downside is that it only works if you have less than 128 tiles.
So, when you have 8 instances of a 4, you just put a 8 followed by a 4 in your data, and you just used 2 bytes for 8 bytes of data, so you saved space.
But when you have 1 instance of a 4, putting a 1 followed by a for would use 2 bytes for 1 byte of data. So instead of that, you'll store 4+128 (basically a 4 but with an extra bit at the "beginning").
And now, to uncompress, you just have to look at the first bit:
-if it's 0, treat the two bytes like RLE compressed data
-if it's 1, then put one instance of the byte (and don't forget to retrieve 128 from it).

writing directly to archive is both tricky and a terrible idea, as it risks bricking your calculator. also, like i said above trying to write back a huge appvar every time your program is exited will be annoying for the user (taking a long time, causing lots of garbage collects, and, eventually, wearing out the flash). to get around both this issue and the issue of having too little ram during runtime, you basically have one of two options:

if you expect your user to only modify a few tiles here and there, the best method is to keep separate diff files for sections of your map, like i described above.

if you expect basically every tile on the entire map to be overwritten, you might want to break your map up into smaller chunks and write back only those that have been modified, decreasing the amount of writing necessary a bit.

With the first method he is describing, I believe he means that you basically keep a list of changes in something like a save file. This way your tilemap data can remain archived, but when you copy (I mean copy, not unarchive) it to RAM, you check the list of changes to see if any of the tiles have to be modified. So for example, if Map00 has the (3,3) tile modified to a 6, you might include in the list a sequence of bytes: 00030306. When the player enters Map00, you copy the appvar data to RAM, then you read the list of changes to see that (3,3) needs to be changed to a 6.

Ah, thank you Xeda, that clears it up a bit.  If I were to do that though, I would still have to either archive the list of changes, or change the base map and archive that, which doesn't really seem efficient to me.  So, it seems, to me, that my best bet is using a single appvar to hold all the data, unarchiving it at the beginning, and archiving it at the end of the program.

And AngelFish, I am well aware of that, which is why I was suprised when shmibs suggested using multiple appvars as a better method.

But that would vastly increase the number of archive writes, would it not?  A fairly severe problem (after a while).