Feature: Add way to uniquely identify a tile within a map by exposing Gid

[Niashi24]

What problem does this solve or what need does it fill?

I'm currently using rs-tiled to load in a tilemap. When I load it into the engine, I need to do some processing on the data of each tile in each tileset to import it into my engine. This processing is considered costly so doing it each time I spawn a tile would be not ideal, so I'd like to cache it at the time of loading by having some kind of map from Tile to processed Data and store it with my Tilemap. My request is to have some cheap way to uniquely identify a tile within a map.

What solution would you like?

In the tmx file itself the tile layer uses a Gid to identify which tile it is. This Gid would be great as a key for a HashMap<Gid, UserData>, but it's currently discarded at the end of the loading process:

rs-tiled/src/map.rs

Lines 275 to 276 in 1ffab03

	// We do not need first GIDs any more
	let tilesets = tilesets.into_iter().map(|ts| ts.tileset).collect();

What alternative(s) have you considered?

#303 adds the source path of each tileset, allowing you to create a HashMap<PathBuf, HashMap<TileId, UserData>>, but this would not be as ideal as using the Gid since this is a much more expensive key with lots of indirection.

[bjorn]

Regarding the HashMap<Gid, UserData>, just note that the Gid for a given tile can (and often will) be different depending on the map the tile is referenced from. Hence it also can't be exposed on the TileData, Tile or even Tileset. To expose the Gid in the API, we'd need to add a function to Map that returns the Gid for a given Tile, which would be "tile.tileset's first_gid for this map + tile_id". So it adds another lookup that's not exactly fast either (but if this works for you, then you could implement this entirely in your own code based on Map::tilesets and assigning your own "first gid" each each tileset).

In C++ I'd probably solve this case by raw pointers, but this is likely problematic in Rust due to lifetimes? Like having a std::unordered_map<Tile*, UserData>.

Alternatively, I guess you could create an entirely parallel data structure for each loaded map, which you can use to look up the UserData for each location. You could set this up just after the map is loaded and it would avoid the need for looking up UserData by the tile entirely, at the cost of using a bit more memory.