Polygon Formats That Keep Attributes and Metadata.

When people say “convert my polygon”, they often mean more than geometry. They usually mean geometry plus:

Attributes. Fields like name, id, crop, owner, area_class.
CRS information. Which coordinate system the numbers are in.
Styling. Color, labels, icons, folders.

Some formats keep this. Some formats drop it by design.

This guide helps you choose formats based on what you need to preserve.

Keep attributes and metadata.
Avoid silent data loss during conversion.
Pick a safe workflow in ClearSKY Polygon Tools.

The core idea. Geometry only vs features with properties

There are two common “shapes” of data.

Geometry only

This is just coordinates and topology. No fields. No labels. No dataset context.

Typical examples:

WKT. Like POLYGON((...)).
WKB. A binary blob, often shown as hex.

Features with properties

This is geometry plus an attribute dictionary.

Typical examples:

GeoJSON Feature, or FeatureCollection.
Shapefile records, with DBF fields.
KML Placemark, with ExtendedData.

If you convert a feature into a geometry only format, the attributes cannot survive. They have nowhere to go.

Quick decision guide

Use this when you do not want to think too hard.

If you need attributes, use GeoJSON, Shapefile, or KML/KMZ.
If you need a compact geometry payload for databases or APIs, use WKT or WKB.
If you need “one file that opens everywhere”, use GeoJSON.
If you need styling and folders for Google Earth, use KML or KMZ.

What each format can actually carry

WKT

What it is: A text representation of geometry.

Attributes. No.
CRS metadata. No.
Styling. No.

WKT is great for quick copy and paste, debugging, and simple database inputs. It is a bad choice for “dataset export” if you care about fields.

WKB

What it is: A binary representation of geometry, often transported as hex or base64.

Attributes. No.
CRS metadata. No.
Styling. No.

WKB is common in databases and low level geospatial tooling. It is great when you want a compact payload and you already store attributes elsewhere.

GeoJSON

What it is: JSON that can represent geometry alone, or full features.

Attributes. Yes, if you use Feature or FeatureCollection.
CRS metadata. Usually not in modern workflows. Assume WGS84 lon, lat.
Styling. Not standardized. Some tools add non standard style fields.

Important detail:

This is a geometry only GeoJSON. It has no properties.

{
  "type": "Polygon",
  "coordinates": [[[0,0],[2,0],[2,2],[0,2],[0,0]]]
}

This is a Feature with attributes.

{
  "type": "Feature",
  "properties": { "name": "Field 12", "crop": "rye" },
  "geometry": {
    "type": "Polygon",
    "coordinates": [[[0,0],[2,0],[2,2],[0,2],[0,0]]]
  }
}

If you paste only the geometry object into another tool, you will lose the attributes.

Shapefile

What it is: A bundle of files, usually zipped. Geometry plus an attribute table.

Attributes. Yes.
CRS metadata. Yes, via the .prj file.
Styling. Not really. Styling is usually stored separately, for example QGIS .qml.

Shapefile is still widely used, but it has sharp edges:

Field names are limited. Many tools enforce 10 characters.
Data types are limited.
Unicode handling depends on tooling and encoding files.

If you need modern flexible attributes, GeoJSON often feels better.

KML and KMZ

What they are: Formats for Google Earth style workflows. KMZ is just zipped KML with optional embedded assets.

Attributes. Yes, via ExtendedData.
CRS metadata. Practically fixed to WGS84 lon, lat.
Styling. Yes. KML supports styles, icons, folders, and labels.

KML is great when presentation matters. KMZ is great when you want one package with icons and multiple layers.

The most common way people lose attributes

Here are the classic mistakes.

Converting Shapefile to WKT.
- The geometry survives.
- The DBF fields cannot survive.
Copying a GeoJSON geometry instead of a GeoJSON Feature.
- Geometry survives.
- properties are gone.
Exporting a geometry only format from a tool and expecting labels to follow.
- Labels are usually attributes.
- Geometry only exports will drop them.

If you see “my polygon converted but my fields disappeared”, it is usually one of these.

How to preserve attributes in ClearSKY Polygon Tools

ClearSKY Polygon Tools runs locally in your browser. It is fast, and it does not upload your data.

Rule 1. Validate and fix geometry separately from dataset export

The validators are meant to detect problems. They can apply conservative fixes to geometry output, but they do not manage datasets. Use them to answer “is this polygon valid”.

Use the Editor when you need to reshape, split, merge, or rebuild geometry.

Rule 2. If you need attributes, keep a container format

If you care about fields, pick an export that can carry them.

Export as GeoJSON FeatureCollection.
Export as Shapefile.
Export as KML or KMZ.

If you export as WKT or WKB, treat that as geometry only. Store attributes separately.

Rule 3. If you must convert to WKT or WKB, do it at the end

A safer workflow is:

Start with Shapefile, KML, KMZ, or GeoJSON FeatureCollection.
Fix geometry in the Editor.
Export GeoJSON, Shapefile, or KML if you still need fields.
Convert to WKT or WKB only for the final target that requires geometry only.

CRS notes that matter for metadata

CRS mistakes look like attribute loss, because the geometry “moves” or becomes nonsense.

GeoJSON. Most tools assume WGS84 lon, lat.
KML and KMZ. Assume WGS84 lon, lat.
Shapefile. CRS is carried in .prj.
WKT and WKB. CRS is not embedded in the value.

If you store WKT or WKB, always store an EPSG code next to it.

Practical checklist

Use this before you hit export.

Do I need attributes to survive.
Do I need CRS metadata to survive.
Do I need styling or folders to survive.
Do I need one file, or a dataset with many features.

Then choose:

GeoJSON, when you need attributes and interoperability.
Shapefile, when a legacy workflow demands it.
KML or KMZ, when presentation and Google Earth workflows matter.
WKT or WKB, when you need geometry only.

FAQ

›Why did my attributes disappear after converting to WKT or WKB?

WKT and WKB represent geometry only. They have no place to store properties, so any fields must be stored separately or exported in a different format like GeoJSON, Shapefile, or KML.

›GeoJSON can be geometry-only or a Feature. Which should I use?

Use Feature or FeatureCollection when you care about attributes. Use geometry-only when you only need coordinates and topology.

›Does GeoJSON store CRS information?

In modern practice, GeoJSON is treated as WGS84 lon, lat. Some older tools supported a CRS member, but many tools ignore it. If CRS matters, store EPSG metadata alongside your file, or use a format that carries CRS explicitly, like Shapefile.

›Can I keep styling when converting formats?

KML and KMZ are best for styling. GeoJSON styling is not standardized and often tool-specific. Shapefile styling is usually stored separately. WKT and WKB do not carry styling.

›Which format should I choose for an API payload?

If you need attributes, use GeoJSON Feature. If you only need geometry, WKT is easiest to debug, and WKB is often the most compact.