How about this site?
http://www.johndcook.com/blog/2009/03/16/quasi-random-sequences-in-art-and-integration/
Jan
On 05/07/10 03:59, Ben Madin wrote:
Martin,
Assuming you wanted feedback - from an epidemiologists perspective, I like the
first one - Complete Spatial Randomness is an important concept to avoid
engendering a perception of order or clustering, and I'm thinking as long as
the relative 'dot-density' is correct for each polygon, the CSR approach is
less like to lead people to think the dots are located on significant points -
in the context of obscuring actual locations etc this is important.
If you want it more regular, then maybe you don't need to randomise it - or
maybe this just means the function needs a user parameter to be able to set the
level of randomisation - From 0 (completely ordered) to 1 (completely Random)
(... to 2.5 completely clustered?)
Just my thoughts - also for my money, I wouldn't change dot sizes. very
confusing.
cheers
Ben
On 07/05/2010, at 6:11 , Martin Davis wrote:
Check out this blog post for some images of different kinds of random point
fields:
http://lin-ear-th-inking.blogspot.com/2010/05/more-random-points-in-jts.html
Martin Davis wrote:
Sounds like it could work - with maybe a bit of fiddling to deal with cases
where the grid cells overlapped the polygon only slightly?
Random perturbation by cell radius can still result in some points being very
close together. (And I think this would also be an issue where only a small
part of each grid cell overlapped the polygon). This may or may not be
desirable. Perhaps a further check could be made to reduce the radius for
points where this occurs. Or maybe some sort of simulated annealing process
could be use to push the points into a more even distribution.
M
Paul Ramsey wrote:
Even-yet-random :) nice requirement. How about just starting with a
regular grid and then perturbing the elements randomly with a radius
of a cell size? You can use the area of the polygon and number of
needed points to calculate the appropriate cell size and go from
there.
P
On Thu, May 6, 2010 at 10:28 AM, Martin Davis<[email protected]> wrote:
Good point about the need for even distribution of the points. That seems
like a whole lot harder to code than simply randomly placing points in a
polygon. Does anyone have any pointers to algorithms for producing this
effect?
George Silva wrote:
The really big problem with dot density is that dots can overlap
themselves,
masking the real number, so if anything will be developed in this area,
the
points should be
A) evenly distributed
or
B) randomly distributed, but with some sort of "colision" tests, so there
is
no or little overlap.
This is a interesting idea, especially if we could make a materialized
view
with those points, which could be added to GIS software for presentation.
George
On Thu, May 6, 2010 at 1:53 PM, Sufficool, Stanley<
[email protected]> wrote:
Looks nasty, but it might work:
select
st_line_interpolate_point(
st_intersection(
the_geom,
st_makeline(
st_pointn(st_exteriorring(the_geom), (rand1.rand *
st_npoints(st_exteriorring(the_geom)))::int),
st_pointn(st_exteriorring(the_geom), (rand2.rand *
st_npoints(st_exteriorring(the_geom)))::int)
)
)
,rand3.rand
)
from insert_your_table_name_here,
(select random() as rand, generate_series(1,1000) as point_number) as
rand1
JOIN (select random() as rand, generate_series(1,1000) as point_number)
as
rand2
ON rand1.point_number = rand2.point_number
JOIN (select random() as rand, generate_series(1,1000) as point_number)
as
rand3
ON rand2.point_number = rand3.point_number
WHERE st_geometrytype(
st_intersection(
the_geom,
st_makeline(
st_pointn(st_exteriorring(the_geom), (rand1.rand *
st_npoints(st_exteriorring(the_geom)))::int),
st_pointn(st_exteriorring(the_geom), (rand2.rand *
st_npoints(st_exteriorring(the_geom)))::int)
)
)
) = 'ST_LineString'
AND oid = 5030 /* Enter your own OID here */
limit 100
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; [email protected]; Martin Davis
Subject: Re: [postgis-users] Dot Density idea
I was thinking the same thing!
strk wrote:
ST_RandomPoinsOnSurface(geometry, numpoints) would be an interesting
function indeed. Sounds like a good job for GEOS/JTS.
--strk;
On Mon, May 03, 2010 at 10:49:32PM -0600, John Abraham wrote:
One of the things I miss about using ESRI's GIS is the
ability to do
dot-density maps. Within a polygon, the number of dots is
proportional to a value, and the dots are randomly placed. I
find it useful to be able to present several data values at
once (e.g. blue dots for population, red dots for employment).
I also find that it is a more intuitive way of scaling for
zone size
than dividing the value by the area of the zone. That is,
the count
of the dots represents the actual number, but the density
of the dots
represents the density of the number. So I don't have to decide
whether to divide the value by the area of the polygon to plot
density: both the absolute number and the density are
easily visible.
Since my open-source GIS viewing systems (mostly QGIS and
Mapserver)
won't plot dot-density, I've done without.
But today I realized that I can build these on the server
instead. I
can generate random points within the bounding-box of the polygon,
throwing out those that aren't contained within the polygon,
repeating until I have enough. Then I can save these points as a
separate layer, and display this layer using almost any desktop or
web based viewer!
Has anyone done this? Can I do it in SQL or do I need to write
something in PL/pgsql?
--
John Abraham
PS I just bought the Postgis In Action book; enjoying it so far.
_______________________________________________
postgis-users mailing list [email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
------------------------------------------------------------------------
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
