Visualizing Point Data

[David Bitner]

Given that you are already using PostGIS,  you should know that R can
be integrated into PostgreSQL as well using PL/R.  That being said,
this could also just be an exercise in writing some functions in
PL/PGSQL so that you could just query that function from Mapserver.

Just brainstorming here, but you could possibly calculate a buffer for
each point and for each cluster where there is an intersection (this
would include coincident points) and then clump points together where
the buffers overlap and place the point at the average x,y while
creating a count at the same time.  You could then symbolize by this
count so that you know a blue dot contained one point while a red
point contained 5 data points.  You might try throwing this question
out to the PostGIS list and see what you get there.

Whatever you figure out, I would be very interested to see.  Please
post back to either this list or the PostGIS list when you get
something figured out.  On my list for the near future is to get this
type of algorithm in Javascript to work with GeoRSS so that I can
place points from a GeoRSS while clumping the data together.

David

On 2/3/06, Bill Binko <bill at binko.net> wrote:
> Hi everyone,
>
> I posted a fairly specific question to the GDAL-dev list (and more on IRC)
> the other day, asking for input on how to do Kernel Density mapping using
> an OGR data source and sending the raster back through GDAL to be
> displayed through Mapserver.
>
> I got some good responses, one of which was: are you sure that's what you
> want?  Well, to be honest, I don't know.  So I'm posting a more general
> question here, hoping that someone in this larger audience has solved the
> problem I'm facing.
>
> What I'm trying to do is visualize point data (stored in PostGIS, but that
> can change) so that users can determine where the points are concentrated,
> even while zoomed out.  One caveat is that the points can be coincident
> (identical Lat/Long).
>
> For example, I'd use this with include recent real estate sales data -
> condos in the same building have the same shape, but both sales should
> count.  Similarly, in a customer counting scenario, two customers with the
> same address (even only to the building level) will geocode to the same
> lat/long.
>
> When Mapserver serves up Point layers directly, the results can be quite
> disappointing (and misleading).  In Mapserver, the last Point to be drawn
> on any spot will just hide the previous points, often hiding multiple data
> points.
>
> Similarly, when you zoom out on a point diagram, there are two options:
> either you set the symbol to have a max size (so that eventually, they
> become "less than clear"), or you keep the symbol size constant,
> eventually obliterating the background with huge blobs of overlapping
> points.
>
> When I tried to tackle this problem, I turned to a Real Estate Geography
> book I have (written by professor Thrall at my alma mater)
> http://www.amazon.com/gp/product/0195076362/sr=1-2/qid=1138949940/ref=sr_1_2/104-4827941-6490312?%5Fencoding=UTF8
>
> There, he is discussing Site Selection and Customer Spotting methods,
> and he discusses the Kernel Density method of generating a surface map
> showing where the customers live.  The discussion is brief, but the GDAL
> folks pointed me to two tools (parts of R and GRASS respectively) that can
> take points and generate kernel surfaces.  With some magic, contour maps,
> and other visualizations could be pushed through GDAL and into Mapserver.
>
> However, with further inspection, these methods all work on distance
> between customers, which causes a problem with coincident points.
>
> I am thinking that this problem must have been solved by someone out in
> this audience, so at this point, I'm very open to suggestions.
>
> I am very willing (and fairly able) to implement any custom software the
> solution my require.  I have considered filters between GDAL and OGR, or
> stand alone processing that generates the needed data.  I'm also very
> happy to feed it back to the community, if there's interest.
>
> (So, basically, I will trade working code for modeling/GIS/statistics
> knowledge if anyone's interested :)
>
> Thanks,
>
> Bill
>