Adding more data in the atlas2 exported json



Is there a way to get atlas2 to add more details about a map in the json that it exports? It’s not an urgent request, but wanted to find out if it’s something that’s already been requested or being discussed or planned to be added to atlas2 at some point.

The idea is to have other drawing tools use the same data format for wardley maps as used in atlas2. This makes it easier to use the same map in different tools without having to redraw the map again and again.

I’ll use the image below as an example - (i’m using the path colours to highlight different paths even though the red one has another meaning in atlas2). Without more data in the json, the usual path is shown in green (which goes to “data input”). With more info in the json, I can follow the red path.

The corresponding json:

The blue boxes correspond to the green and red lines in atlas2.

There’s information missing: such as the user, inertia, comments.

P.S. I find the ‘maturity’ and ‘visibility’ numbers useful.


Since I got a pop stating “New users can attach only one image per post”, i’m adding the corresponding json here:


I have upped your trust level, so you have now all the privileges of the long term forum user :slight_smile:.

Regarding the original issue - there are two things here, as the work needs to be done in two places at once:

  1. The needs to be updated to support storing additional metadata. Currently, connections have only start and end properties. We need at least attributes with label, style and maybe type, and some specification around them. Getting @cioportfolio on the board would be welcome here.
  2. needs to be adjusted to support those attributes and map them to whatever there is in the model.


yay, thank you for the trust upgrade - guess I can attach cat images now :slight_smile: just kidding.

I’ll update the map later in the week to add the swardley-script and the json format (or DM me your email address and I’ll add you as editor, if you have time). Then we can use the updated map to discuss with @cioportfolioask (and others who might be interested) about the impact of changing the json format.

The metadata and attributes that you mentioned are a good start. I’ll attempt #2 on local dev once I get clearer mental picture of the model.


Not sure if i should start a new thread or ask my question here, but here goes: if you can’t say because of confidentiality, feel free to let me know. I fully understand and respect that.

Now onto my question - it’s about the numbers for ‘visibility’ and ‘maturity’. I’m trying to understand them by comparing the exported json with where the components are placed on the map.

  • Is there a formula for working out what the ‘visibility’ and ‘maturity’ numbers of a component are ?
  • If these values are based on where the component is on the map, can I assume that these pairs (maturity and visibility) specify every position/location on the map - that is, the same pair will always be shown on the same position on the map - like how GPS uses coordinates ?
  • Does every stage have a range of numbers applicable to it - e.g, product stage will be between ‘maturity’ level of 0.2 and 0.4?

P.S., i’m searching through the code for evolution/maturity but can’t understand the code snippets -



first of all, be sure to work with the v2-service-branch. Everything else is a work in progress with multiple experiments conducted simultaneously. The underlying model (Node) contains x and y fields, which are based on screen positions and are corresponding to the maturity (x) and visibility (y).

Both those numbers are normalised to fit the range [0,1], because only then it is possible to resize maps without computing too much (it is enough f.e. to multiply x and map width to get a relative left css position in px).

Maturity 0.1 is therefore in the middle of Genesis, while 0.95 - in utility.
Visibility 0 is on the top, while 1 on the bottom (which is exactly opposite as in the swardley-script). Therefore this line may contain a bug, as maturity should not be changed.


@chris.daniel Thank you for the detailed answers and confirming the normalised numbers to a range.

What I liked about the pairs (x and y), is that if i gave the pair to another tool, it would put the node in the right place.


A bit late, but here’s the updated map (as promised) - contains all the tools i’ve seen mentioned in the tools channel on slack. I’m appropriating the colours to mean something different than in atlas2 - mainly applicable to nodes under the swardley-script:

  • green represents the current path with the tools I’ve tried/looked at (i’m assuming
    @bemosior tool is the mapping canvas or maybe other prototypes he has in mind);
  • red represents the future path (I’ll be able to get my map’s json data by calling an API on atlas2 instead of logging in to do a manual export).

P.S. The API part is one idea that came up while mapping. My initial and current interest is still the json data. I can still live with the manual export. I’m repeating it if it helps with prioritising what features get added :slight_smile:


Oh do I ever have prototype ideas (all the blank stickies)! :wink:


hehe, fantastic. I should have made “Tool3” into plural :slight_smile:

The stickies make it feel like nothing is set in stone & easily movable. I like that feeling.