Flows can change a feature's usage, height, or cost as they run. When one of those values comes out wrong, like a parking area misclassified as a road, you need to find exactly where that value lives before you can fix it. The Reader node shows you the JSON a flow produces so you can find it without writing any code.

Connect the Reader node's input to the output of any other node in your flow. Turn on the Inspector, also called the Spectacles (the glasses icon in the top toolbar), to see live data flow through the graph for the geometry you have selected.

The Reader prints the connected object as JSON text: a read-only view of everything flowing into it at that point in the graph. Large or repetitive sections, like coordinates, collapse automatically so the properties you care about stay visible. Click a collapsed section to expand it.

JSON only has a few punctuation marks to learn. Once you can recognize them, you can find any value in the Reader's output.

A pair of curly braces { } marks an object: a group of key/value pairs. Each key names a piece of data, and its value sits after a colon. An object can hold another object as one of its values, and that nested object gets its own pair of braces.

A pair of square brackets [ ] marks a list of items, called an array. The items in a list are numbered starting at 0, not 1. The first item is item 0, the second is item 1, and so on. A flow's list of coordinates, or a list of features it produces, both take this form.

Here is the full JSON of a carpark feature, as the Reader might show it before a flow does anything to it:

The outer curly braces hold the whole feature. Inside it, geometry and properties are each their own object, wrapped in their own curly braces. The coordinates array inside geometry is a list, wrapped in square brackets, holding the points of the polygon's outline.

Placing a Reader before a node and another Reader after it lets you compare exactly what changed. Here is the properties object from a Reader on each side of an Apply Usage node, if the wrong usage was connected to its input by mistake. The feature's geometry does not change, so only properties is shown.

Applying a usage does not just rename the usage label. It brings in that usage's own defaults, which is why stackOrder and hardCost changed too, along with usage going from "Carpark - On Grade" to "Road". That is also why the parking count for this feature would stop showing up correctly.

Nodes like Read Property and Write Property ask for a property path: a single line of text that tells the node exactly where a value lives. Build a property path by writing the key at each nesting level, separated by a period.

Using the carpark feature above:

Most property paths fail for one of a few predictable reasons. Check this list before assuming a node is broken.

A property path is the string you type into a node like Write Property or Write Feature Property to tell it where a value lives. The reason these two nodes exist separately comes down to what each one can safely assume about the object you're writing to.

Write Property writes to any object, whether or not it is a GeoJSON feature: a plain object from Construct Object, a list, or anything else your flow has built. Because it makes no assumptions about the object's shape, you type the full path from the top, including properties if that's where the value lives, like properties.usage. If you feed it a list of objects instead of a single one, it writes the value onto every item in the list.

Write Feature Property only works on features. Because it already knows the object is a feature, it can safely assume your value belongs inside that feature's properties { }, and writes there for you. Leave properties out of the path here: to fix the carpark feature above, type usage, not properties.usage, and connect a value of Carpark.

Read Property and Read Feature Property follow the same split, for the same reason: Read Property works on any object and takes the full path, while Read Feature Property only works on features and already starts inside properties { }.

If the object you are writing to has a list of items, like a flow's list of child features, reach into a specific one with a plain number, separated by periods, like childFeatures.0.usage. Do not use square brackets in the path, like childFeatures[0].usage. Square brackets can work when reading a property, and they will not reliably write one. If a value will not update no matter what you type, check the path for square brackets first.

Type the property path into the Property field on Read Property, Write Property, Read Feature Property, or Write Feature Property. You can also connect a Panel or String node to the Property input instead of typing directly on the node.

If you are writing to one of a feature's own properties and are not sure of its exact spelling or case, connect a Get Feature Property Name node instead of typing the name by hand. It lists every property in the project in a dropdown.