[mapserver-users] Creating an abutter's list (was: Accessing Vertices of a Shape - PHP MapScript)

[Thomas, Cord]

Mark

I think your idea sounds like a very good idea; however, as Ed points out,
the need for most municipalities is to create an "abutters list" of people
nearby (some distance, often 300 feet, sometimes more) for notification of
change.  In this example, the graph of adjoining parcels/properties would
not be reasonable as such a graph would be necessary for all imaginable
distances.

That said, since most municipalities require a standard set of distances,
say 100, 300, 500 feet, this graph could be developed by simply interating
through distance searches for all points in the property to all points in
all other properties and producing N graphs for N distance sets.  And, as
you point out, this could then be used in a module that would return the
graph results for the given distance very quickly and accurately.  The
module could include 2 methods - buildGraph (distance) and findAbutters
(propertyHash, distance) out Hash.

Cord

-----Original Message-----
From: Mark Phillips [mailto:mbp at geomtech.com]
Sent: Tuesday, November 19, 2002 10:10 AM
To: morissette at dmsolutions.ca
Cc: kevin at peoplegis.com; mapserver-users at lists.gis.umn.edu
Subject: Re: [mapserver-users] Creating an abutter's list (was:
Accessing Vertices of a Shape - PHP MapScript)


> ...
> The best would be if we could create a new shape that is the parcel of
> interest with a buffer added around it and use that buffered parcel in a
> queryByShape().  Unfortunately for you there is no way to create such a
> vector buffer in MapServer.
> 
> Another trick could be to sample points every few meters along the
> border of the parcel of interest and do a point query at every step with
> a tolerance of half the distance between the sampled points.  You would
> ...

Although both of these methods would probably work in most cases, it
seems to me that in both cases if there are parcels that are close to
but don't actually touch your given parcel, the algorithm could
falsely include them in the result.  With a judicious choice of buffer
size or sample point density you could minimize the chances of this
happening in practice, but it seems to me that the best solution would
be to do an actual search through the shapefile for parcels that share
an edge with the given one.

In fact, this computation could be done once for the whole shapefile,
producing a parcel adjacency graph that could be stored along with
the shapefile and used for lightening fast adjacency lookups.

Of course I'm speaking in pure algorithmic terms here, with no regard
to what might be possible with existing functions in mapserver /
mapscript, and I realize that part of the point is to find a way to do
it with existing functions.  If there is a way to do it with existing
functions that is easy and fast and works in all practical cases,
then perhaps there's no need to implement a new algorithm.

If the new algorithm seems like a good idea, however, I could be
interested in working on it.  I've been playing with mapserver,
shapelib, etc and would welcome a project that would give me a chance
to dive in deeper.  I also have a particular interest in municipal
applications.  [I imagine this function could be in a shared library
that could be optionally loaded into mapscript applications, so as to
avoid bloating the actual mapscript code itself.]

Before diving in, however, I'd like to ask whether this sounds like a
reasonable solution.  Is there a better way?  Are there hurdles or
other problems with what I'm suggesting that I've overlooked?

--Mark

Mark Phillips @ Geometry Technologies LLC
P.O. Box 1170
Black Mountain, NC  28711
828-664-1748
mbp at geomtech.com  http://www.geomtech.com