Address pathways craziness

[timothyfcook]

The pathway lines are too crazy and overlapping

We might need to change our genmap parameters so that resource bricks show up in an order more closely related to their pathways.

@chelseaerdner do you have any brilliant ideas on a way that we could change the design so that we don't have to make the bricks adjacent within pathways?

Some possibilities:

• We could replace the center nodes with nodes that contain number (1,2,3,4) for the point in pathway associated with that bricks; then we could simplify the visual expression and reduce the lines shown as you go further in the pathway, i.e. the first 3 bricks could have heavy line connecting them, the next 3 could have transparent lines, the next 3 could have "barely there" transparent dashed-lines, the remaining could have just have the highlighting and numbered nodes without lines. Some variation on this so that the mess of lines is reduced.
• We could add some visual magic where the blocks within the pathway actually pop up and out of the grid, 3D like they get raised above and the rest of the grid loses color/focus.

[timothyfcook]

Oh! I remember when @whit537 and I were talking, we discussed the possibility of using the alleyways as the conduit for the lines. Maybe instead of the crazy node-to-node lines, we could change it so that the lines travel down the alleyways as the route, enter into the brick hit the node, and then leave back to the alleyway.

This is an option as well.

[timothyfcook]

@whit537 how hard would it be in genmap to have genmap "print" the blocks in groups, one pathway at a time so that bricks are always adjacent to those within their pathway?

[chadwhitacre]

First step on this will be to push the DAG comprehension down from JavaScript into Python.

[timothyfcook]

Which option are you going for?

[chadwhitacre]

Here's the snip from the current js where we use the DAG:

            for (var i=0, resource_id; resource_id=dag.names[i]; i++) {
                var v = dag.vertices[resource_id];
                for (var j=0, prev_id; prev_id = v.incomingNames[j]; j++)

That's the API we need to reproduce in resources.json → topics.json. Looks like we need:

• names—an Array of Strings, the ordered list of resource_ids in the pathway
• vertices—an Object mapping resource_id to an Object with an incomingNames attribute: an Array of Strings, the resource_ids of any previous items in the graph relative to the resource_id mapped

[chadwhitacre]

Which option are you going for?

The option I think it makes sense for me to work on is to "have genmap 'print' the blocks in groups," because the other suggestions I'm seeing alter the design, and I think that only makes sense for @chelseaerdner to do. :-)

[chadwhitacre]

Python side of DAG push-down is done in #62.

JavaScript side of DAG push-down is done in https://github.com/saxifrage/cityasacampus/pull/210.

Now ready to use the DAG within genmap ... but https://github.com/saxifrage/caac-map/issues/63!

[chadwhitacre]

63 is fixed.

[chadwhitacre]

Now ready to use the DAG within genmap?

[chadwhitacre]

I'm seeing where a resource_id is ending up in subtopic['dag']['names'] without a corresponding entry in subtopic['resources']. Hmm ...

Does that mean there's breakage in _before and/or _after?

[chadwhitacre]

(Pdb) resource_id
u'pittsburgh-filmmaker-and-center-for-the-arts-stained-glass'
(Pdb) pp subtopic['resources'].keys()
[u'mcg-youth-and-arts-electric-avenue',
 u'labs-at-carnegie-library-of-pittsburgh-the-labsy-awards',
 u'pittsburgh-filmmaker-and-center-for-the-arts-anime',
 u'pittsburgh-filmmaker-and-center-for-the-arts-graphic-design',
 u'mcg-youth-and-arts-digital-expressions',
 u'the-andy-warhol-museum-andy-warhol---pop-portraits-and-selfies',
 u'open-ideo-adding-visual-goodness-to-your-ideas-',
 u'carnegie-museums-of-art-and-natural-history-youth-museum-institute---exhibit-design-lab',
 u'the-andy-warhol-museum-online-weeeknd-factory',
 u'labs-at-carnegie-library-of-pittsburgh-open-lab',
 u'carnegie-museums-of-art--interact']
(Pdb) subtopic['id']
u'visual-communication'
(Pdb) subtopic['topic_id']
u'art-design'
(Pdb)

[chadwhitacre]

No, there's a record in the spreadsheet for pittsburgh-filmmaker-and-center-for-the-arts-stained-glass:

[chadwhitacre]

Oooh! A subtopic mismatch? pittsburgh-filmmaker-and-center-for-the-arts-stained-glass is in artisan, but its after_this is mcg-youth-and-arts-electric-avenue, which is in visual-communications. The subtopic we're looking at is visual-communications.

[chadwhitacre]

Maybe this also explains the empty ending cells of pathways?

[chadwhitacre]

Decision taken w/ @timothyfcook IRL is to write genmap (and map.js?) to ignore after_this (and before_this?) if it isn't in the same subtopic as the resource in question.

[chelseaerdner]

@timothyfcook & @whit53 ,

I just realized my name was throughout this thread (sorry sometimes I miss them) but, can I still be helpful here? If so, whats the best way to go about it?

[chadwhitacre]

Thanks for checking in, @chelseaerdner! :-)

I am plugging away on reducing pathway craziness in the process that actually builds the SVGs. I guess it's up to @timothyfcook whether he'd like to ask you to propose some design modifications to address the problem as well.

My current status (ignore circle size plz):

[chelseaerdner]

Ooo, those lines definitely look more organized. Regardless, I think we are heading in the right direction @whit537!

[chadwhitacre]

:-)

[chadwhitacre]

We want planar graphs.

The crossing number of a drawing is the number of pairs of edges that cross each other. If the graph is planar, then it is often convenient to draw it without any edge intersections; that is, in this case, a graph drawing represents a graph embedding. However, nonplanar graphs frequently arise in applications, so graph drawing algorithms must generally allow for edge crossings.

https://en.wikipedia.org/wiki/Graph_drawing#Quality_measures

Also: "An Algorithm for the Graph Crossing Number Problem"

[timothyfcook]

Two rules we've decided upon:

1. Lines can't cross over other lines
2. Nodes cannot be mapped sequentially (can move any direction, but not the same direction two times in a row)

We will implement this by creating the map of blocks FIRST and then plotting resources onto available blocks by prioritizing BEST PATHWAY PLEASANTNESS (first) and APPROPRIATE BLOCK SIZE pegged to duration meta-data (second).

[chadwhitacre]

During World War II, Hungarian mathematician Pál Turán was forced to work in a brick factory, pushing wagon loads of bricks from kilns to storage sites. The factory had tracks from each kiln to each storage site, and the wagons were harder to push at the points where tracks crossed each other, from which Turán was led to ask his brick factory problem: what is the minimum possible number of crossings in a drawing of a complete bipartite graph?

https://en.wikipedia.org/wiki/Crossing_number_(graph_theory)#History

O.o

[chadwhitacre]

Alright, so what's next here?

[timothyfcook]

Looks like we need to fix for #50 and #67 first!

[chadwhitacre]

Design:

[chadwhitacre]

The thing is that specifics of resources are now irrelevant at map building time. We just build a map and then go back over it to assign resources to pieces.

[chadwhitacre]

Handbook of Graph Drawing and Visualization

[chadwhitacre]

"In contrast, crossing minimization is extremely hard also practically."

[chadwhitacre]

Reassigning resources to pieces, using a random assignment function:

[chadwhitacre]

Landed #69, now integrating in https://github.com/saxifrage/cityasacampus/pull/272.

[chadwhitacre]

Ready to close, ya?