Yet another missive from SHEEP sent via me. Sorry about this, he will
get it sorted out soon. Any personal comments directed to
[log in to unmask] please.
------------------------------------------------
> Always a danger of rubbish-in = rubbish-out,
Not always so, what makes integration such a nice measure is that it
tends to hang in there. The worse the map approximates reality the
worse the correlation gets, how ever a non perfect map does not give
a completely erroneous result. so
rubbish-in <> rubbish-out.
This is way integration can cope with the case of visibility is not
accessiblity the errors introduced do not throw the whole thing off
completely.
>so I am puzzled that Sheep writes that "fractional analysis will
>make such map based observation questions irrelevant".
Meaning I agree the current 'fix it in the art of digitising lines
mentality' is wrong, we should be improving processing techniques.
How ever most of the people doing syntax on work can only use what
software they are given. As such, the only way of making an axial map
correlate is to modify the map rather than do fundamental research on
altering the processing mechanism.
I belive The axial maps should reflect literal geometry. That said
axial maps do have a number of advantages at the urban level, I'm
personally not in favour of dropping the axial representation for
the sake of it. (Axman and Meanda have been able to process places
like Tokyo with over a million axial lines - no one is proposing
doing this with with V.A.G. style analysis).
>Especially
>as he follows this with "One thing we do not understand clearly from
>traditional space syntax is when the visibility matrix (where I can
>see) and the permeability matrix ( where I can go ) differ. For
>example an office with half-height partitions, or an office with
>glass walls." This is surely a critical point, in particular
>because on first impressions it would seem that visibility maps
>reflect the experience of strangers, and permeability maps reflect
>the experience of ‘familiars’ (residents?).
Who can say ? With out some understanding of either mechanism the
whole visibility/accessiblity thing keeps appearing hanging around..
Currently I feel syntax works best where movement and accessiblity is
the same which is most of the city most of the time. There is no
available observation counts for large spaces where the two do match
up most of the time. If some one has some data I would like to see it
I have some theories which might
be able to make some headway in this area.
>The ‘fractional’ analysis of the axial lines that make up a curve is
>most interesting – but why draw short, straight lines around a curve
in the first place?
Think about it before dismissing it out of hand. If you
knew/remembered differential calculus you would realise that if you
have a mechanism where lines are getting shorter but there are more
of them, makes it possible
to apply differential calculus. With fractional integration but NOT
traditional integration you can make an infinite number of lines go
to zero length yet still end up with a depth which has some value.
adding more and more shorter lines is a rough approximation to this.
Calculus could represent movement over an arbitrary curve with some
representative number for depth of the curve. While I don't have any
observation data for an area
include many curved walkways I can't yet test this theory. I can at
the moment only point out that fractional analysis is capable of
doing this where as traditional syntax included in Axman does not.
Without doing the differential calculus, users of Meanda can
experiment by doing successively smaller and smaller axial lines
filling a curve. The value for depth over the curve stays about
constant.
A curved space may also be is also an example of
visibility/accessiblity problem which Fractinal analysis does not
solve. for example walking between the library/theatre and Town Hall
in Manchester. This depends upon how wide the street and how tall the
buildings and how curved the space - perhaps you could be more
specific in what you mean.
I also agree that there should be a more accessible 'how to space
syntax' guide. I keep suggesting a book. In "Axman, The User Guide"
tried mentioning some of the main pitfalls in digitising but it would
be useful to have a reference for things like doing observations and
most importantly interpreting the results. If well written it
could handle the difficult questions architects and students ask
'what is good/what is bad'.
>See my note above about 'fewest', for those outside the field the problem is
>that jargon is also historical - the rules changed but the names used for
>the maps did not. The original rule used to generate axial maps was somthing
>like 'draw the fewest and longest lines that cross all convex spaces and
>make all rings of circulation' - the process of automating this rule by
>Stefan Czapski in the mid 80's led us to invent the all line map, the
>overlapping convex space map and to alter the rule used by human researchers
>to 'draw the set of longest lines that cross all convex spaces and make all
>rings of circulation whilst minimising the depth between any pair of
>lines' - Stefan's software automated the production of these maps, and
>although there is no mathematical proof that the software works consistently
>for any 'arbitary' input map, it was good at producing maps that a trained
>human would agree with.
Well if anyone wants to play all line axial maps production there is
a program called "Infinity Within" which can take an outline of a
number of buildings and generate the all line axial map. Most people
try this out after a lot of processing that the all line axial map
does not give significantly different results. "Infinity Within" is
available from Space Syntax Lab or me if I can find the disk I wrote
it on.
For all line axial map production you can also use SpaceBox, which
has a nifty auto convex space production algorithm. This takes the
model of solid stuff (walls) and can product all the convex spaces
automatically.
If I can stand on my soap box for the moment, what I want to
understand is the social process about the adoption of software. For
example, no one doing Space Syntax has ever bothered to use automatic
convex space analysis - i.e. thoroughly tested it against real world
observations.
You might have thought that this whole 'what is an axial line ? why
do we use them ?' debate could have been neatly answered more than 13
years ago when I wrote the SpaceBox software. As it was I noticed
that no one was in the least bit interested in using automatic convex
space production. So I removed it from the bits that people did use
to produce Axman. Over the last 10 years no Masters/PhD student has
ever been desperate enough to bother asking 'does automatic
generation of axial lines or convex spaces correlate with real world
movement ?'. So one answer to your original question.
>1) I know lines are not drawn at will, but do they always represent
>exactly the same thing in the real world? (Is there a rigid protocol
for extracting information from the environment? )
>The first concern relates to the fact that the impressive computing
>only applies after axial maps have been drawn. Many architects
>assume that the computing is a way of extracting spacesyntax
>information out of raw environmental data, much the same way that
>daylight programs take data about solid walls and windows and tell
you about ‘brightness’. I
Is really that after 13 or so years no one can be bothered to do the
hand work after getting the software to automatically generate the
result to correlate it with real movement. Most researchers in the
field are satisfied with the general visual appearance of similarity
between hand-drawn axial lines and automatically generated convex
spaces and generated all line axial maps. I believe most researchers
are happier dropping in to complex arguments about Popper and
fallibility rather than investigating why certain lines of research
are followed and others ignored. I think Mike Batty too has for some
time had problems with the human intervention axial line choice
process. Yet has this been enough to produce a paper finally using
SpaceBox to answer the questions it was originally designed to
answer? No. For me this is the key question, do we actually have any
reason for using
axial lines over other forms of representation ? Originally I was
told that the reason students where using axial lines and not testing
convex spaces was that axial lines where well tested and the new
techniques where not. I think a social research inertia took hold -
we use axial lines because it's the software we have been taught -,
we use the software we have been taught on the projects we do, we
teach axial line software because it's the software we use.
Everything else comes down to
a) Effort
----------
It's quicker to digitise a few axial lines in. Do some obersvations
on the streets and come up with a correlation. Than it is to
accurately digitise every building ground plan, make sure this
matches reality, process the whole thing and then do some complex
process of extracting the all convex space integration data and
correlating it with real world data.
b) Software Inertia
--------------------
As described above, how many people on a UCL short course or masters
get to hear about:
"James Choice" - Axman documents processed for the Choice measure.
"Infinity Within" - axial all line map production from boundary descriptions.
"Orange Box" - super fast processing of axial maps.
"Hard Wave" - integration processed from street center lines where a
space is defined any street centerline with a name. This works in
conjunction with a GIS system (Arc Info) to process integration
analysis for streets by name.
"New Wave" - integration analysis from a text file of numbers.
"NetBox" - a program which lets you process buildings by making up a
map of nodes and links.
"Pesh" - a simple drawing tool do which does by hand convex space
analysis (used by Bill Hillier in Space is the Machine) a.k.a. as
"Hyper Hyper Pesh and "aaaapesh". I know this software is widely
used but has anyone published a paper giving a correlation between
convex space integration and observed movement?
"NextPesh" - super advanced version of Pesh which could handle curved
shapes + layers + one way streets and no right turns at junctions.
"The Urban Machine" - a program which could permit the interactive
analysis/characterization of hundreds of different cities
simultaneously.
"Loglady" - Unix based super processor of axial maps.
"FarmerBrown" - Transputer based processing of integration via a
vastly parallel supercomputer.
"Omnivista" - a VGA style analysis with new measures including
"drift" and "restricted field of view" paths.
"Spacebox" - automatic generation of convex spaces and all line axial
maps from a boundary/wall description.
Some of these programs mentioned approach your questions and others
(does syntax work for cars with restrictions on turning/one way
streets) I won't bother to cover the software written by others in
the field (such as "Spatialist" by John Peponis, "Axwoman" by CASA,
software from Cardiff, Ruth's Isovist Generatosr written in Pangea in
1996 (IsoCam and AxialCam), A. Turner's VAG stuff, The VGA software
commissioned by Jake De Syllas - sorry don't know what it is called).
Why does one program get chosen and others ignored ?
c) Our amazing ability to post-rationalize.
------------------------------------------
All in all, I think your questions actually give rise of a more
detailed question of how does software get adopted in the space
syntax community ? What makes students go for one than another. What
gets software tested and why. Why are there no common data sets of
observation/spatial descriptions with which to test new
software/theories and compare across programs and against reality.
Why are there no lists of difficult situations. Ultimately this
suggests to me that Space syntax in still in it's infancy.
hope this helps
Sheep
|
