Zelda-style top-down RPG. How to store tile and collision data?

Question

I'm looking to build a Zelda: LTTP style top-down RPG. I've read a lot on the subject and am currently going back and forth on a few solutions. I'm using C#, MonoGame, and Tiled.

For my tile maps, these are the choices I can see in front of me:

1. Store each tile as its own array. Each one having 3-4 layers, texture/animation, depth, flags, and maybe collision(depending on how I do it). I've read warning about memory issues going this route, and my biggest map will probably be 160x120 tiles. My average map however will be about 40x30. The number of tiles might cut in half if I decide to double my tile size, which is currently 16x16. This is the most appealing approach for me, as I feel like I would know how to save maps, make changes, and separate it into chunks for collision checks.
2. Store the static parts of my tile map in multiple arrays acting as the different layers. Then I would just use entities for anything that wasn't static. All of the other tile data such as collisions, depth, etc., would be stored in their own layers as well I guess? This way just seems messy to me though.

Regardless of which one I choose, I'm also unsure how to plan all of that other tile data. I could write a bunch of code that would know which integer represents what tile and it's data, but if I changed a tileset in Tiled and exported it again, all of those integers could potentially change and I'd have to adjust a whole bunch of code.

My other issue is about how I could do collision. I want to at least support angled collision that slides you around the corners of objects like LTTP does, if not more oddball shapes as well. So do I:

1. Store collision as a flag for binary collision. Could I get this to support angles?
2. Would it be fine to store collision as an integer and have each number represent a certain angle of collision?
3. Store a list of rectangles or other shapes and do collision that way?

Sorry for the large two-part(three-part?) question. I felt like these needed to be asked together as I believe each choice influences the other.

Answer 1

For collisions I would simply store a polygon per tile.
I don't know if you need three degrees of movement, but for two, this would be very simple. In that case I would simply store a convex polygon per tile. For example a triangle, quad, hexagon or whatever shape you need.
Then simply do circle (player) vs polygon (tile) or box (player) vs polygon (tile) collision detection. This can be done with SAT (Separating Axis Theorem). Maybe XNA already offers you something like that.
With this approach you'd automatically get nice sliding on slopes and stuff.

If I wasn't clear enough, I mean something like you see in this video (the red lines around the objects): https://www.youtube.com/watch?v=-Q6ISVaM5Ww

Answer 2

Well old zeldas for static geometry had everything collide as squares. You could just have an array of flags where a single bit was 'occupied'. If the bit is occupied then you just do a basic AABB to AABB test for collision. Not a terrible system for tile. You can also do something like 1 bit means texture 1, next bit means texture 2 and so forth if your not wanting to do alpha mapped textures or blending. That means a single 8-bit values can store a plethora of info. No reason to have an array per tile ... 1 Array per chunk with a width / height parameter should be fine or if you have a standard dimension of chunk you can do it that way.