JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for SPACESYNTAX Archives


SPACESYNTAX Archives

SPACESYNTAX Archives


SPACESYNTAX@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

SPACESYNTAX Home

SPACESYNTAX Home

SPACESYNTAX  September 2007

SPACESYNTAX September 2007

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: A software to calculate the convex spaces

From:

"S. N.C. Dalton" <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Mon, 10 Sep 2007 10:42:53 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (404 lines)

No one has still given me a good reason why we can't just use any  
number of spatial partitions 'as is'.

I don't see the Geographers worry about a formal definition of a road  
centre line or a land parcel. No one asks for a formal proof of road  
centre line being unique.

Each time I ask for a response on how comparable two maps of road  
centre lines made by two different operators from the same  
photography all I get is silence. With out some base line for  
comparison making any statements about the reproducibility of the  
axial map is irrelevant.

Still I think that my current work on finding community- 
neighbourhoods in axial lines could make a significant contribution  
to finding effectively rooms in buildings. The problem is that all  
the graph-neighbourhood finding algorithms tend to want to know how  
many rooms you want to find in advance.

sheep

On 8 Sep 2007, at 12:24, Alan Penn wrote:

> Alasdair,
>
> you introduce an interesting, and I suspect a deep point here, in  
> the notion
> of the need for the 'largest'. The pivot you are talking about  
> might be
> thought of in the case of the L shaped room as a triangular convex  
> space
> defined by pivoting a line across the inside corner of the elbow.  
> This space
> is larger than the overlap, which it completely contains, and may be
> metrically larger than either of the other two 'face hugging'  
> rectangular
> spaces. In your/Maria's pragmatic VGA approach to computing this  
> through
> looking for cliques, you are pretty much forced to look for the  
> largest
> first, and so may often find this kind of space in preference to  
> the face
> hugging kind. BUT... the point is that in the L shaped room, in  
> order to
> completely cover the system, if you choose the triangular zone as a  
> convex
> space first, you find that you have also to choose both face  
> hugging zones
> as well, and end up with three convex spaces to cover something  
> that is
> completely covered by just the two face huggers. In this sense the  
> 'largest'
> rule seems to be less important than the 'fewest that cover the  
> system'
> rule, but with the obvious caveat that smaller spaces that are  
> completely
> contained by another are redundant.
>
> This may be one 'deep' part - we see this kind of thing happening  
> also in
> axial line definition, where rules like 'longest' and 'fewest'  
> compete with
> each other and where actually what is required is a more global  
> optimisation
> of the representation to achieve (for example) depth or angle  
> minimisation,
> coupled to removal of redundancy.
>
> I think that there is a second 'deep' part here as well. This is in  
> the
> nature of 'pivoting'. Effectively what we do when we draw axial  
> lines is to
> pivot on the convex projecting corners of the boundary, often  
> looking for
> two opposing pivot points that allow a line just to get through, and
> maximise its extension (note the subtle avoidance of the word  
> 'length':-).
> Now I think it is possible, and can show examples, that the kind of  
> spatial
> property the 'pivoted' space produces is something like the axial  
> line or
> strip. It seems to me possible that our pairing of 'axial' and  
> 'convex'
> representation are actually two complementary but interlinked kinds  
> of thing
> that tell us quite different things about the more general isovist/VGA
> properties of the world.
>
> SpaceBox, which doesn't work from the same VGA/clique premise,  
> starts with
> face hugging: that is with the articulation of the boundary and its  
> effects
> when the face is projected across open space at all convex corners.  
> This
> gives rise to a finite subdivision (given a finite number of  
> straight faces
> on the boundary in the original map). What John showed so elegantly  
> is that
> these kind of lines across open space (plus the extended ends of  
> the axial
> lines in an all axial line map) define partitions of relative  
> informational
> stability, in which although the isovist changes at any point  
> within the
> partition it does so smoothly and offers little in the way of 'new'
> information on the geometry of the environment. When you cross one  
> of John's
> E or S partition lines you gain new information (see a new wall  
> face or see
> through between two corners) and often isovist properties change
> substantially.
>
> It is easy to see that the pivot line that defines a maximal clique  
> in the
> VGA approach may well not be related to these lines of  
> informational change,
> (except in the extreme where it becomes the axial line), and may in  
> these
> terms be a fairly irrelevant subdivision of space, experientially and
> socially. So back to the initial point - why are we doing these  
> things? Well
> in this field the representations are defined by our interest in human
> experience of architecture and its relation to the social, and here  
> concepts
> like John's of informational stability and change seem crucial.
>
> Alan
>
>>
>> At the risk of throwing the cat amongst the pigeons, we probably  
>> ought
>> to introduce some firm mathematics, even for fuzzily defined  
>> systems, as
>> the problems of convex space coverage and isovist coverage are in  
>> fact
>> different.  ("Uniqueness" is an unnecessary distraction.)
>>
>> I'll use a visibility graph as the fuzzy representation, but note  
>> that
>> what I am about to say is also true geometrically.
>>
>> Firstly note that the analogue of a isovist in a visibility graph  
>> is the
>> neighbourhood of a node.  For a certain resolution of graph, the  
>> set of
>> isovists is easily computable.
>>
>> However, a minimal covering set of isovists is not easily computable,
>> although a heuristic (such as, largest first) gives an easily  
>> computable
>> set in approximately linear time.  The reason a minimal covering  
>> set is
>> not easily computable is that combinations of isovists together  
>> need to
>> be tried.  If you do this, you find it takes exponential time (all
>> combinations may have to be evaluated) in order to find the minimal
>> covering set.  This does not mean the minimal covering set is not
>> unique.  It may or may not be.
>>
>> However, as pointed out by Maria Doxa, the analogue of a convex  
>> space in
>> visibility graph terms is a maximal closed subgraph (clique).   
>> That is,
>> to construct the space, we place John, Bill and Mike at various  
>> points
>> in the graph and check that they are co-visible.  This leads to
>> something surprising: calculation of the cliques is again only  
>> possible
>> in exponential time, as all combinations of nodes have to be  
>> calculated.
>>   So this is one step before completing a covering set: the  
>> individual
>> spaces themselves cannot be computed easily.  Again, a heuristic  
>> makes
>> the construction of convex spaces in reality straightforward:  
>> tools such
>> as SpaceBox construct spaces where each face of the convex space is
>> aligned with a face.
>>
>> The limits of text mean I cannot easily demonstrate why this  
>> heuristic
>> doesn't necessarily produce the largest convex polygon about a
>> particular point.  I'll try: imagine a pivot point and a line rested
>> upon it.  If the pivot is offset then the area above the line can be
>> increased by tilting it.  Now imagine the pivot broadened so it is a
>> short face rather than a point, the area above the line can still be
>> increased by tilting it.  Rather than a single offset pivotal face,
>> think of lots of pivotal faces arranged roughly into a circle.   
>> You have
>> to "tilt" lines in opposition to each other in order to try to  
>> find the
>> largest area.
>>
>> The important point in this is that this property (the convex space
>> boundaries do not necessarily align with faces) may or may not matter
>> socially -- it's not a matter of simply creating a fuzzy resolution.
>>
>> Alasdair
>>
>> Alan Penn wrote:
>>> At the risk of awakening a previous discussion, it is for this  
>>> reason
>>> (the impossibility of defining a unique convex partitioning) that we
>>> invented the 'overlapping' convex space. In this an L shaped room is
>>> divided into two convex elements, one for each leg of the L which
>>> overlap at the elbow. Each convex space is considered as a node  
>>> in the
>>> graph, and each overlap between two spaces is represented as a  
>>> link. For
>>> a boundary consisting of only straight lines (no smooth convex  
>>> curves)
>>> it is possible to compute all such convex spaces (curves can of  
>>> course
>>> be approximated by straight lines, but that is bound to introduce
>>> arbitrariness). This was first implemented in the Syntactica  
>>> software in
>>> about 1989, and then written properly by Sheep in SpaceBox in  
>>> 1991. This
>>> is not a partition in the conventional sense since a point in  
>>> space may
>>> be a member of two (eg. in the elbow) or more, sometimes very  
>>> many, but
>>> always a finite number of, convex spaces, and so points are not
>>> 'partitioned'. John Peponis went on to show how by considering  
>>> each of
>>> the spaces defined by different degrees of overlap as a partition  
>>> one
>>> can derive a unique partitioning for this kind of boundary. Now,  
>>> I have
>>> not been able to find anything in the mathematical literature  
>>> about this
>>> kind of 'overlapping convex space' map, and I am aware of no formal
>>> proof of its uniqueness or completeness, so although these  
>>> properties
>>> seem pretty obvious they must rest as a conjecture - my math is  
>>> isn't up
>>> to proving this kind of thing.
>>>
>>>
>>>
>>> That said, it is worth going back to what Bill and Julienne were  
>>> doing
>>> in the SLS. First, inside buildings with rooms and doorways or just
>>> archways through walls, the subdivision into 'unique' spaces for the
>>> purposes of analysis of social relations is often not too  
>>> problematic.
>>> The convexity of such spaces is a social property (as well as a
>>> geometric one) - if Bill can see Mike and Mike can see John, then  
>>> John
>>> can see Bill. This is why meetings generally happen in spaces of  
>>> this
>>> sort of shape. This is of course a pretty metrically and  
>>> geometrically
>>> fuzzy thing - minor deviations in the boundary wall (the alcove or
>>> chimney breast) have little real effect on the 'fatness' of a  
>>> space for
>>> these kind of social purposes. Anyway, the point is one doesn't  
>>> need to
>>> get too mathematically prissy for the purposes of a social  
>>> analysis of
>>> space of this kind, any more so than the housebuilder and their  
>>> client
>>> needed to be consciously aware of this kind of mathematics when they
>>> laid the walls out, or the users of the space are consciously  
>>> aware of
>>> these maths when they appropriate space for particular social  
>>> behaviours
>>> in use. The focus of the analysis tends to be on the relations in  
>>> space
>>> between a whole set of different more or less well defined fat  
>>> spaces
>>> which are appropriated for different social functions or meetings
>>> (living room, dining, parlour, bedroom), and how these relate to  
>>> each
>>> other and the outside world.
>>>
>>>
>>>
>>> Now, when one moves on to urban space things can get much less  
>>> clear.
>>> Having said that, the class of French villages that Bill and  
>>> Julienne
>>> were looking at do often seem to define 'fat' spaces with pretty  
>>> regular
>>> associations with other things (like building entrances). Given  
>>> that in
>>> those days everything was being done by hand, the use of a unique  
>>> convex
>>> partitioning is not only sensible, but the only possible way to  
>>> get at
>>> what seems like an important social property that characterised the
>>> vernacular settlement, and appeared to distinguish it from the  
>>> kinds of
>>> modern housing estate that these villages supposedly inspired in  
>>> the UK,
>>> but which consistently created fat spaces with blank walls. Again  
>>> the
>>> point is that the analysis has a specific purpose concerned with the
>>> social, and its precision is appropriate to that. The axial
>>> representation which has turned out to be the most useful for urban
>>> space is of course not problematic in this sense - but that has been
>>> discussed at length on this list before J
>>>
>>>
>>>
>>> Alan
>>>
>>>
>>>
>>>
>>>
>>> Ruth is absolutely correct. There is no solution to the problem of
>>> identifying a unique partition of a space into convex subspaces. The
>>> problem is not well defined and a corollary of this is that there  
>>> is no
>>> unique set of isovists that define a space.
>>>
>>> There are various notes about this scattered around the various  
>>> papers
>>> on isovists but I havent seen an exhaustive discussion of this.  
>>> My own
>>> paper has a note -
>>>
>>> Batty M, 2001, "Exploring isovist fields: space and shape in
>>> architectural and urban morphology" /Environment and Planning B:
>>> Planning and Design/ *28*(1) 123 - 150
>>> http://www.envplan.com/abstract.cgi?id=b2725
>>>
>>> and I reproduce the quote
>>>
>>> Emacs!
>>>
>>> Mike
>>>
>>> At 16:14 07/09/2007, Ruth Conroy Dalton wrote:
>>>
>>> Dear Ahmed,
>>>
>>> There is no software for discrete convex spaces, as there is no one
>>> unique solution. Sheep (Nick Dalton) wrote some software, a long  
>>> time
>>> ago, called space box, which produced overlapping convex spaces -  
>>> but
>>> this only runs on very, very old Apple Macs. Unless, it's an  
>>> extremely
>>> complicated layout or you have hundreds and hundreds of them, it  
>>> will
>>> take you far less time to draw them by hand.
>>>
>>> Regards
>>>
>>> Ruth
>>>
>>>
>>>
>>> Hi all,
>>> i was wondering if anybody has an idea if there is a software in  
>>> which i
>>> can calculate the number of convex spaces in any layout and how  
>>> to get
>>> this software
>>>
>>> thanks for you help
>>>
>>>
>>> *Ahmed Mohamed Refaat Mostafa
>>> *
>>> School of Architecture
>>> School of Environment & Development (SED)
>>> Manchester University
>>> mobile no: (+44) 07878185642
>>>
>>>
>>> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
>>> <http://us.rd.yahoo.com/evt=47093/*http:/tv.yahoo.com/collections/ 
>>> 222>
>>> to see what's on, when.
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> *Michael Batty* | CASA | University College London | 1-19 Torrington
>>> Place London WC1E 6BT UK | Tel 44 207 679 1782 | Mobile 44 7768  
>>> 423 656
>> |
>>> email: [log in to unmask] <mailto:[log in to unmask]> | web:
>>> www.casa.ucl.ac.uk <http://www.casa.ucl.ac.uk/>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Course Director
>> MSc Adaptive Architecture & Computation
>> UCL Bartlett School of Graduate Studies
>>
>> http://www.vr.ucl.ac.uk/people/alasdair

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager