Skip to main content
Every health check returns a number from 0 to 100. Here is the whole rulebook.

In four sentences

Your file starts at 100. Invalid entries (the ones we can’t auto-repair) take points off. The more of them, the bigger the hit. Fixable entries (the ones Fix All can repair in one click) also take points off, but less. As long as the file passes the critical checks, the score stays at 50 or higher. The only way to score 0 is if a critical check fails: the file couldn’t be opened, it has no entries inside, or it has no coordinate system we can identify. That is the whole model.

What the numbers mean in practice

The score moves continuously inside each band, so a file with 1 bad entry out of 50,000 reads as 100 (essentially clean), and a file with 100 bad entries out of 1,000 reads as 95 (a few issues, mostly fine).

Why invalid entries hit harder than fixable ones

A fixable entry is one bad entry away from being clean. Click Fix All and it’s repaired in place. An invalid entry can’t be repaired. The coordinates are out of range, or the geometry is empty, or the row didn’t parse. The only way to “fix” it is to remove it from your file (which we do, in the cleaned copy), or re-export from the source. That difference is why a file that’s 100% fixable scores 80 (clearly imperfect, but trivially salvageable), while a file that’s 100% invalid scores 50 (the worst openable result).

What a 100 doesn’t promise

A score of 100 means every entry in your file is structurally clean. Any mapping tool will read it without complaining. It does not mean the data inside the file is correct. We can’t tell whether your “Berlin parcels” file actually covers Berlin.

What we don’t check (yet)

The score is based on structural validity. It doesn’t currently look at:
  • Duplicate entries
  • Overlapping entries
  • Inconsistent property fields
  • Tiny stray entries from messy editing
A 100 means your file loads cleanly everywhere. It doesn’t mean the data inside is accurate.