EF-Map is not just a star list with names and coordinates. Behind the map is an extended solar system database that describes stars, planets, moons, Lagrange points, orbital zones, landscape sites, and several physical fields that are still underused in the public UI.
This blog post is the plain-English version of that inventory. It does not claim official server-side truth, and it does not turn uncertain field names into confirmed gameplay mechanics. It explains what EF-Map has inspected, what the app uses today, and what might become useful for scouts, route planners, and data explorers later.
The short version
What the current inventory shows
- 24,426 solar systems with system-level values such as security, bounds, frost line, habitable-zone boundaries, remnant gas and dust fields, potential, and radius.
- 24,026 stars with class, temperature, radius, luminosity, age, metallicity, and related physical fields.
- 230,317 planets and moons, including position, parent orbit, radius, temperature, pressure, density, surface gravity, escape velocity, dust and gas mass-like fields, orbit radius, orbit period, rotation rate, and eccentricity.
- 416,285 Lagrange points, usually L1 through L5 around planets.
- 87,381 landscape zones and 122,951 landscape sites tied to asteroid belts, trojans, ecosystem families, and tags.
The basic hierarchy of a solar system in EF-Map
The database is easier to read if you picture each system as a stack of related layers. At the top is the solar system row, which gives the system ID, security, center position, bounds, frost line, habitable zone, and a few derived or extracted system values.
Inside that system is a star, then planet-like bodies, then moons that orbit parent planets. Lagrange points hang off planets as L1 through L5 positions. Stargates connect systems for routing. A separate landscape layer describes asteroid belt zones, trojan zones, ecosystem definitions, and individual landscape sites.
| Layer | What it represents | Examples EF-Map can use |
|---|---|---|
| System | The container for one solar system. | Security, center, bounds, frost line, habitable zone, system radius, potential. |
| Star | The main sun-like body for the system. | Spectral class, temperature, luminosity, radius, age, metallicity. |
| Planets and moons | Orbiting bodies with physical and orbital properties. | Type, radius, position, orbit parent, pressure, gravity, dust and gas fields. |
| Lagrange points | System-local points around planets, labeled L1 through L5. | Planet context, Smart Assembly context, system inspection markers. |
| Landscape | Generated zones, sites, ecosystems, and tags. | Asteroid belts, trojans, site counts, ecosystem families, danger tags. |
Star data
Every mapped system starts with a star record when the source data provides one. EF-Map can read the star's spectral class, temperature, luminosity, radius, age, mass-like field, and metallicity. Some of those units are clear from the extraction code and app usage, such as temperature in kelvin and luminosity in watts. Others, such as mass and metallicity, should be treated as field names unless the unit is confirmed elsewhere.
That star data already matters in the app. Star class and temperature help EF-Map color systems and support star-based filters in System Finder. The same data also helps the Solar System View make a system feel like a physical place instead of a list of IDs.
Planet and moon data
Planets and moons share most of the same shape in the database. EF-Map can inspect their type description, radius, local position, parent orbit, orbit radius, orbit period, rotation rate, eccentricity, and orbit-plane information. Moons are linked to parent planets through the orbit relationship rather than being a separate isolated list.
The physical fields are where the inventory gets especially interesting. Bodies can carry temperature, density, pressure, surface gravity, escape velocity, mass_dust, and mass_gas. Pressure is handled by EF-Map as pascals, and surface gravity as meters per second squared. Density, escape velocity, dust mass, gas mass, orbit period, and rotation rate still need cautious language because the inspected inventory does not prove every unit.
EF-Map also has loader support for optional compatibility fields named life, locked, and fragmented. That does not mean those columns are present in the current inspected database. They are defensive fields for schemas that may appear in legacy or future data.
Lagrange points and why they matter
The inspected database contains 416,285 Lagrange point rows. Each row ties a system-local coordinate to a planet and an L-point number from 1 to 5. For players, the important part is not the table name. It is that EF-Map can place the points in context with the planet, the star, and nearby landscape data.
That makes L-points useful for Smart Assembly context, scouting notes, and any future view that needs to explain "where in this system is the interesting thing?" They are not route nodes by themselves, and this blog post does not claim that every L-point has gameplay content attached to it. It only says the positional layer exists and EF-Map can render or query it.
Zones, sites, asteroid belts, and trojans
The landscape layer comes from separate landscape and ecosystem data. It is not just decoration. The current inventory includes asteroid belt zones, trojan zones, individual landscape sites, ecosystem definitions, ecosystem pattern rows, and hundreds of thousands of landscape tags.
A zone can describe belt or trojan context, site count, inner and outer planet references, radius boundaries, a trojan host planet, and a weight-like value whose unit is not confirmed. A landscape site can describe an ecosystem ID, position, distance from the star, and coordinate frame. Ecosystems are grouped into families such as natural, broken, and transitional, with some display aliases kept cautious because decoded names do not always map cleanly to older labels.
This is one reason EF-Map's System Resource Potential blog post is careful. The landscape layer looks important, but the inspected schema does not expose explicit resource, fuel, or mineral columns.
Frost line and habitable zone
At the system level, EF-Map can read a frost line and inner and outer habitable-zone boundaries. The app treats these as meter values when it renders Solar System View overlays. These boundaries are useful visual context because they let a player compare planets, moons, and landscape sites against a rough thermal structure for the system.
The caveat is important: some outer habitable-zone values are placeholders or otherwise not meaningful. EF-Map already guards against outer values that are less than or equal to 1, or not greater than the inner boundary. That is a good example of how the app handles the database as real data with validation, not as a flawless source of final gameplay meaning.
Interesting underused fields
Several fields are available today but only lightly surfaced, or not surfaced at all, in the public UI. They are interesting because they could support better filters, scouting summaries, or future research views. They are not proof of hidden mechanics by themselves.
| Field or signal | What EF-Map can safely say | Caution |
|---|---|---|
density |
Stored on celestial bodies and useful for comparing body profiles. | Unit not confirmed in the inspected inventory. |
pressure |
Stored on bodies and used by EF-Map as pascals. | It should not be turned into a habitability claim without the rest of the heuristic. |
surface_gravity |
Stored on bodies and used as meters per second squared. | Useful context, not a final settlement score by itself. |
escape_velocity |
Stored on bodies and potentially useful for physical comparisons. | Unit not confirmed. |
mass_dust and mass_gas |
Mass-like body fields that may help compare generated bodies. | Names are suggestive, but the gameplay meaning and unit are not confirmed. |
remnant_dust_mass and remnant_gas_mass |
System-level mass-like values. | Do not call them resource pools without validation. |
orbit_radius, orbit_period, rotation_rate, eccentricity |
Orbital fields that can explain where and how bodies sit in a system. | Radius is handled as meters, but period and rotation units are not confirmed. |
metallicity |
A star field that may matter for future star or system comparisons. | Unit or scale not confirmed. |
| Landscape weights, tags, and ecosystem families | Useful for filters around belts, trojans, outer icy context, danger tags, and site families. | Tags are generated data, not direct loot tables. |
life, locked, fragmented |
Compatibility fields supported by the loader for legacy or future schemas. | Not present as columns in the current inspected database. |
What EF-Map uses today
EF-Map already uses this database in visible ways. Solar System View uses system center data, frost and habitable-zone values, stars, planets, moons, L-points, landscape sites, zones, ecosystems, and tags. Hover cards can show star class, temperature, luminosity, radius, age, planet and moon type, orbit context, temperature, pressure, gravity, and zone chips.
System Finder uses structured database fields for star filters, planet and moon filters, moon counts, stargate counts, orbital-zone counts, landscape summaries, tags, and human-habitability flags. Route planning still depends on stargates, while the broader map remains the quickest way to move from a system-level question to a visible location. The open map is the right place to test that context interactively.
Why this matters
For players, this database turns EF-Map from a coordinate browser into a research surface. A scout can ask for systems with certain planet families, moons, gates, belts, trojans, landscape tags, or habitable-zone relationships. A builder can inspect L-point context before talking about Smart Assemblies. A planner can compare system shape before deciding whether a region deserves closer attention.
It also matters for transparency. The State of the Frontier page and EF-Map's static database tools work best when they separate known data from interpretation. Publishing this inventory helps keep that line visible.
Caveats
Read this as an inventory, not a rules leak
EF-Map's solar system database is static and client-derived. It is not official server-side truth. CCP can change the universe, server services can apply rules that are not visible in this database, and some fields may be generated inputs rather than player-facing outputs.
Units are also not equally certain. Position, radius, frost line, habitable-zone boundaries, pressure, temperature, and surface gravity have clear handling in the inspected tooling and app code. Several other fields are best treated as named signals until their units and semantics are confirmed.
Conclusion
The useful takeaway is simple: EF-Map knows much more about EVE Frontier solar systems than a name, a region, and a point in space. It has a layered model of stars, planets, moons, L-points, landscape zones, ecosystem sites, and physical values that can support better exploration tools over time.
The honest boundary is just as important. More data does not automatically mean confirmed mechanics. EF-Map will keep surfacing the parts that are useful today, keep labeling uncertain fields carefully, and keep the database pipeline documented so future universe updates can be compared instead of guessed.