Bigger Maps Are Coming With Fair Usage Updates
I am preparing bigger map support with heavy optimization work, and I am introducing fair-usage multipliers so large jobs stay possible without pushing smaller maps to the back of the queue.
You have probably noticed that map creation is currently capped at 4 km on the platform. I want to explain why that limit appeared, what I have been improving behind the scenes, and how bigger maps are coming back in a fair way.
If you have followed Maps4FS for a while, you already know I care a lot about fair usage. I do not want people building normal-size maps to wait forever behind a few very heavy jobs, and I also do not want to lock bigger maps behind paywalls.
Why Size Is Not Just Size
A larger map is not just a slightly bigger request. Resource usage grows aggressively. As a concrete example, a 16x16 km map can demand around 64 times more resources than a 2x2 km map. That difference hits storage, processing time, RAM pressure, and queue throughput all at once.
When the platform treats those jobs as equal, everyone feels the downside. Smaller maps get delayed, shared infrastructure gets stressed, and the overall experience becomes less predictable for all users.
The Fair Usage Update
The rule I am adding is straightforward: bigger maps are allowed, but they count more against usage based on size. This keeps large projects possible while still protecting everyday workflows for people building smaller maps.
For a 16 km map, the multiplier will be 8x. In practice that means you can still run large jobs, but they no longer consume platform capacity as if they were lightweight tasks.
- Bigger maps stay available
- Usage scales with map size
- 16 km maps use an 8x multiplier
- Smaller-map users keep better task and export availability
What I Optimized For Large Exports
In parallel, I have been deep in optimization work for oversized exports. The goal is to avoid the old pattern where huge jobs could spike to extreme memory use and drag export times into painful territory.
I am tightening memory behavior, reducing avoidable overhead, and making heavy pipelines more stable under load so big exports do not feel like an infrastructure stress test every time.
So yes, bigger maps are coming, but with clear fair-usage logic that respects everyone on the platform. I want open access, strong performance, and predictable queues without pretending all workloads cost the same.
Thanks for sticking with me while I keep improving this. More rollout details are coming soon.
Stan, Developer of MapToPlay