Dear Miguel,

I agree completely. This is certainly one of the key aspects of syntax representations that separates them from other forms of analysis and makes them conceptually elegant. I would have to think about it - which I will do - and I suspect that there may be a more elegant and compressed representation of the segment graph than the one that doubles up the nodes and which would therefore be compatible with Pajek. In fact I think it would be possible to solve the forward/back link problem with a convention on ordering. However, I suspect that when Alasdair coded this representation he may also have had in mind the need to be able to represent vehicular traffic networks in which segments might also need to represent one way streets and turning restrictions. For this purpose the simplest way of thinking about it would be generally to represent each direction of travel on a segment as a separate node in the graph.

All the best,

Alan


On 26 Nov 2012, at 14:25, miguel serra <[log in to unmask]>
 wrote:

Dear Alan,

I'm sorry to bother you, surely you have else to do than to reply to my erratic doubts. But it's difficult to resist when the subject is so close to my research interests.

As I understand them, axial lines are also fully geometrical entities (with lenght) not merely aspatial nodes in a graph. Actually, as you have so nicely shown, with universal geometrical properties. Angles of incidence between segments are properties of the edges linking those segments/nodes. And segments lenghts are node attributes, not edge attributes. All this is clear and can be formally stated. But one of the most interesting characteristics of space syntax is the duality between map/graph, indeed something that could be a lesson to the entire research comunity studying spatial networks (of all kinds, not just street networks). The idea of a graph that encapsulates geometrical properties because it is a product of a previous (and particularly inteligent) geometrical reduction of spatial form (the axial and subsquently the segment maps),  is a "Columbus egg" yet to be surpassed by other dual representations. I believe that the segment graph, while encoding geometrical attributes in the nodes (lenght) and in the edges (angle of incidence), is doing something very simillar to the axial graph (just with the difference that it is weighted). Now, if this virtuous duality is blurred by means of a less transparent computer implementation (and I should make clear here that I'm not criticising the method in itself, just the lack of explicity) something of the best space syntax has to offer would be lost. And if the reason for this being so is just because of the difficulty in implementing the search of shortest angular paths (i.e. making sure that such paths are not calculated in an erroneous way) it is a pitty that such matters are not made immediatly clear, because eventually someone (certainly not me!) could find a better (or alternative) way. As for Pajek, it can handle any type of graph and is widely used for many purposes else than social networks. Because, in the end, it all sums up to mathematics, I think that there are no real analytical hindrances between any type of network, providing that they are well defined.

Again, please excuse me for insisting in such enthusiastic way on this issue, it is just that it is particularly relevant to me. I thank you for having lost some time with it.
 
Kind regards,
Miguel   

 

De: "Penn, Alan" <[log in to unmask]>
Para: [log in to unmask]
Enviadas: Segunda-feira, 26 de Novembro de 2012 13:05
Assunto: Re: Enc: Problem exporting segment graph to Pajek

To answer the question - probably both :-) yes there may be other representations and this one probably has the benefit of fitting the specific structure of Depthmap algorithms (i.e.. it was a practical programmer's approach) but that itself may tell us something.

The key thing here is that segments in Depthmap are not just topological entities but fully geometric entities with both length and angles of incidence to other segments. The Depthmap segment graph allows that geometric information to be retained (and I think can be reconstituted to produce the original map). As I understand it Pajek was designed to deal mainly with 'non spatial' networks (e.g. social social nets) and so isn't really set up to think about networks that occur in the real space of geometry. It is possible to get from Depthmap to Pajek but to get back to a real map would require additional information.

Alan


On 26 Nov 2012, at 12:39, miguel serra <[log in to unmask]>
 wrote:

Dear Alan,

Actually, what I was planning to do was to calculate several general graph parameters (as diameter, density, transitivity, clustering coefficients, etc) and explore other graph characteristics. Not the same measures that Depthmap calculates. The latter are all made impossible by the current format of the export.

But, now that you mention it, is the diagram a reduced representation, or THE representation of a segment graph? In other words, is the Depthmap representation a short-cut to solve a computational problem or a meaningful structure in it self?

Miguel


De: "Penn, Alan" <[log in to unmask]>
Para: [log in to unmask]
Enviadas: Segunda-feira, 26 de Novembro de 2012 12:26
Assunto: Re: Enc: Problem exporting segment graph to Pajek

This seems all clear, however, I would point out that if you wished in Pajek to calculate the same kind of angular betweenness measures that you do in Depthmap you would need a representation that allowed for back links and forward links, so this export would (at least in principle) allow for that (but would of course require some scripting to handle). I am not entirely sure, but I suspect that a reduced representation to that shown in the diagram would have lost the key information needed.
Alan

On 26 Nov 2012, at 12:15, miguel serra <[log in to unmask]>
 wrote:

Ok, sorry, I see they are not supported directly on the email message. The image goes attached.

Best,
Miguel

----- Mensagem encaminhada -----
De: miguel serra <[log in to unmask]>
Para: "[log in to unmask]" <[log in to unmask]>
Enviadas: Segunda-feira, 26 de Novembro de 2012 12:11
Assunto: Enc: Problem exporting segment graph to Pajek

Dears Jorge, Kinda, Tasos and everybody else,

In order to be more clear regarding the issue of this thread, I would like to draw your attention to the following figure (I hope images are supported in this mailing list), extracted from (Hillier and Iida 2005):

I think this is what the generality of the space syntax comunity has in mind when thinking about segment graphs. Even if Depthmap follows another way to construct them, it would be great if it could export to Pajek in this way.

All the best,
Miguel

----- Mensagem encaminhada -----
De: miguel serra <[log in to unmask]>
Para: [log in to unmask]
Enviadas: Segunda-feira, 26 de Novembro de 2012 10:32
Assunto: Re: Problem exporting segment graph to Pajek

Dears Jorge, Kinda, Tassos:

Thanks a lot for your feedbacks.

I have tried to solve the problem within Pajek. To make the graph unweighted and undirected is easy, all there is to do is to symmetrize the network. But the double-node's issue is unsolvable in Pajek. The .csv export doesn't work also because, as Jorge points out, there's no info about the graph, just about the segments' attributes. And to do it manually (in excel or whatever) for graphs with hundreds of thousands of nodes is, of course, impossible.

Nonetheless, Jorge's insight is particularly revealing. In Alasdair Turner's (2007) paper "From axial to road-centre lines" there's the following note (p. 5):
"Directionality is important: you must leave from the segment in the same direction as you arrived. Within our implementation this handled by incorporating 'back' links and 'forward' links for the connections at each end of the segment. If you entered via a 'back' link, the you must leave via a 'forward' link, and vice versa." This seems to be implemented not exactely like this but, like Jorge says, through the duplication of the nodes and through the introduction of a maximum weighted edge between the duplicates.

Now, the point is: to solve the problem of "one-direction-only" paths (quoting Jorge, "the graph can't allow turning back to get a more favourable angle for changing direction"), Depthmap uses a strategy that has nothing to do with the hteoretical construct of the graph itself, but with a detour to solve an implementation issue. If this is allright with normal depthmap analysis, it also makes the Pajek export for segment maps useless in my opinion (if it remains "literal", as it is now). Either the export should be a one-segment/one-node weighted graph (accordingly to the distance metric used, topological, angular or metric), or a simple one-segment/one-node unweighted, undirected graph. The first option is probably best, because the second is easily achieved in Pajek. In any case, having double nodes is meaningless from the point of view of a "bare" network analysis (i.e. outside Depthmap and within any other network analysis package).

I would recommend that, when exporting to Pajek, all double-nodes should be collapsed onto a single one. Otherwise, there's no point in exporting segment maps in .net format. That would be inestimably useful for my work, at least.

One last remark to Kinda's proviso, if topological segment graphs have any analytical interest outside the framework of standard angular analysis. I think they do, because we need to know with which structures we are dealing with, to compare them and to know what it trully entails to use one or another. One thing is to accept them theortically (which, in priciple, we all do), another is to be able to systematically deconstruct them (or to reverse-engineering them, if you like), in order to step on firm ground whenever doing any kind of "deep-mining" research in space syntax.   

Thanks again for all your contributions and for the continuous effort in making Depthmap an increasingly consistent spatial network analysis tool.

All the best,
Miguel



      






De: Jorge Gil <[log in to unmask]>
Para: [log in to unmask]
Enviadas: Segunda-feira, 26 de Novembro de 2012 0:59
Assunto: Re: Problem exporting segment graph to Pajek

Dear all,

I've looked at what Miguel mentions.

First, this is not a problem but a feature of Depthmap. It works how it should, exporting the segment graph created and used by the software.

However, this segment graph is indeed much more complex when compared with the axial graph. So Depthmap could have an extra feature to export a simple version of the segment graph. The CSV export feature exports the segment map (lines and analysis values) and not the graph (the list of connections and their weights).

Because angular distance is used in segment analysis, the graph can't allow turning back to get a more favourable angle for changing direction. The solution in Depthmap is to construct a directed graph, where every segment allows the two directions, but the path only goes forward from one segment to the next. Turning back involves an extra step on the same node with the maximum cost of 180 degrees. For this reason the nodes appear duplicated.


Best,
Jorge


On 25/11/2012 17:44, Al-Sayed, Kinda wrote:
> <pre wrap>
> Dear Miguel,
>
> You could try the transform options in Pajek and create a new network with the arcs converted to edges...etc. Alternatively you could follow the longer procedure in exporting Depthmap data into Pajek file:
> Export your segment map into a CSV file and then convert your Excel file into Pajek via (PajekCreate) – downloadable from the main Pajek website. PajekCreate will help you generate a .net file that you could read in Pajek. Once you have got the segment map you can analyse its "topological" properties in Pajek, similar to the way you do it with axial or convex graph data.
>
> All the best,
>
> Kinda
> ________________________________________
> From: UCL Depthmap [[log in to unmask]] on behalf of Miguel Serra [[log in to unmask]]
> Sent: 25 November 2012 15:21
> To: [log in to unmask]
> Subject: Problem exporting segment graph to Pajek
>
> Dear All,
>
> Recently I've noticed that the Pajek export for the segment map/graph seems not to work properly. The number of nodes is doubled in the .net file, some of the edges are converted into arcs and the graph is directed.
>
> I am aware that the segment graph is different from the axial and that there are forward and backward links, to store the directionality of paths. Perhaps the export file has in it information whose utility I'm not aware, but what I wanted was to analyze it in Pajek as a simple undirected and unweighted graph.
>
> Has somebody already encountered this problem?
>
> Thanks in advance,
> Miguel
>
> </pre></body>
> </html>
> </html>

-- Jorge Gil
PhD Candidate

TU Delft / Faculty of Architecture
Department of Urbanism
Chair of Spatial Planning and Strategy

Julianalaan 134
2628 BL Delft
P.O. Box 5043
2600 GA Delft
The Netherlands

www.tudelft.nl






<seg_graph.PNG>