It is usually not required for each tile to know its own x, y and z coordinates. These are usually inferred from their position in the data-structure which stores the tiles. But there are a few situations where it actually can be useful, so I am giving you the benefit of a doubt.
When your map is static (does not change during the game, or at least doesn't change much), then you might want to consider to add a complete copy of your map as an asset to your game client. That way the server doesn't need to send any map data to the clients (except maybe through the pre-game auto updater).
If your game has a dynamic map (it is altered during gameplay), then you might want to send it to the player in form of chunks (rectangular cells of map data). When you send the client a chunk, you don't need to send the x, y and z coordinate of every single tile. You just need to tell the coordinates where the chunk starts, its width and height (number of layers will likely be constant) and then a long list of id's. You might be able to save some more bandwidth by running the id collection through a stock compression algorithm like Deflate or LZW. Check which algorithm gives the best results for your particular mapping style.
Also make sure you don't send any map data the client already knows. When the client walks back and forth between two points, and the terrain doesn't change, you don't need to tell it how it looks over and over again. You could solve this by either having the server remember which client already got which version of which chunk. Or you could turn it around and use a request-model where the client asks the server when it wants a chunk by telling the server the chunk-coordinates and the latest version it got. The server then either replies with a new version of that chunk or with a "chunk didn't change" message.
