The short answer is that it looks like the latter, unique id for each NFT, regardless of grouping (eg stadium). But to have NFT-like grouping there are a couple of considerations:
The nft example implementation uses an IS_NFT bit for id's with single supplies. Notice that mint uses a packId.
Perhaps this can be done more simply for your use case, or you can just use the example code.
And, from the spec's metadata section...
This JSON schema is loosely based on the "ERC721 Metadata JSON Schema", but includes optional formatting to allow for ID substitution by clients. If the string {id} exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard.
Which presumably is a cosmetic different to not have large, unwieldy id's.
This for(uint i=0; i< numberOfSold is an unbounded loop and is a big no-no. Eventually, the cost of 1 transaction will be over the block gas limit, and it will revert. At this point buyLand would be bricked.
Try:
// x, y
mapping (uint256 => mapping (uint256 => ParcelInfo)) parcels;
You cannot enumerate through a mapping. And you don't want to, again, because that would be an unbounded loop. However, you may want to keep track of the plots sold, for instance with a:
// Token ids perhaps?
uint256[] allSold;
But never have your Solidity code do a for on it. This increases the complexity of your contract. So think hard about what is needed in your contract, and what can be outsourced to Web2.0 servers.
To improve: you do land.mint and then tokenId = land.getTokenCount(). That does not sound right. Right now you are saved by the fact that Ethereum is "single-thread". Instead, the mint should return the new tokenId, something like:
uint256 tokenId = land.mint(msg.sender, tokenURI);
Best Answer
You can either 1) have a big @ss collection and keep all user collections and group them by user data or 2) you can make a mock contract and implement OpenZeppelin clones contract to make a new contract on users demand
Openzeppelin Github repo
if you were to keep all tokens within one colllection youre saving deployment costs for your users but all the tokens would be centralized in one collection and you'd have to find a way to split royalties
if you were to make a clones implementation, it will cost to the end user the gas for deployment
You can take a look at foundation.app, they did what you're trying to do but in two steps; When they started, they had a big @ss collection where they store all tokens from their end users; but now they offer to help users to deploy their own contract