Re: [postgis-users] Dot Density idea

[Martin Davis]

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 
 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 <
ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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 tho

Re: [postgis-users] Dot Density idea

[Martin Davis]

Which is a nice segue into this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=s2he24c4c271005042228wfff7b9abjadf3eb357fe0c712%40mail.gmail.com&forum_name=jts-topo-suite-user


Norman Vine wrote:

When I have done this before I usually triangulate the polygon
first  then use each triangles area to normalize the number of 
points randomly inserted into each triangle


On May 6, 2010, at 1:51 PM, David William Bitner wrote:

  

If it was the overall density of the dots that mattered and not as much the exact number 
of dots, a representative table could be made with a "random yet even" set of 
dots covering a certain area. To apply to a polygon, you could then Scale the data to the 
appropriate density and translate/compute the intersection to apply to a given polygon.

On Thu, May 6, 2010 at 12:50 PM, Martin Davis  wrote:
Did your algorithm work with irregular polgon extents?


Jan Hartmann wrote:
I did this long ago. Regular points won't work, you'll get all kinds of moire 
patterns. I just computed random x and y values from the origin of the grid 
cell within the x- and y grid-size. Can't remember having any problems with 
overlapping points.

Jan

On 05/06/10 19:35, 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  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<
ssuffic...@rov.sbcounty.gov>  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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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 t

Re: [postgis-users] Dot Density idea

[Norman Vine]

When I have done this before I usually triangulate the polygon
first  then use each triangles area to normalize the number of 
points randomly inserted into each triangle

On May 6, 2010, at 1:51 PM, David William Bitner wrote:

> If it was the overall density of the dots that mattered and not as much the 
> exact number of dots, a representative table could be made with a "random yet 
> even" set of dots covering a certain area. To apply to a polygon, you could 
> then Scale the data to the appropriate density and translate/compute the 
> intersection to apply to a given polygon.
> 
> On Thu, May 6, 2010 at 12:50 PM, Martin Davis  wrote:
> Did your algorithm work with irregular polgon extents?
> 
> 
> Jan Hartmann wrote:
> I did this long ago. Regular points won't work, you'll get all kinds of moire 
> patterns. I just computed random x and y values from the origin of the grid 
> cell within the x- and y grid-size. Can't remember having any problems with 
> overlapping points.
> 
> Jan
> 
> On 05/06/10 19:35, 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  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<
> ssuffic...@rov.sbcounty.gov>  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: postgis-users-boun...@postgis.refractions.net
> [mailto:postgis-users-boun...@postgis.refractions.net] On
> Behalf Of Martin Davis
> Sent: Thursday, May 06, 2010 8:56 AM
> To: John Abraham; postgis-users@postgis.refractions.net; 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 deci

Re: [postgis-users] Dot Density idea

[pcreso]

Hi,

We use an application much like this for generating random sample points for 
2-phase random stratified trawl biomass surveys. Specify polygon name, number 
of points, minimum distance from the boundary, minimum distance between points 
in a file, then iterate through the file.

The code has a limit on the number of iterations per stratum to try before 
deciding that we can't actually fit that many points in it with the current 
parameters.

Strata can be polygons or multipolygons, with or without holes.

If anyone is really interested, a paper describing the approach for such survey 
design & analysis is at:

http://www.royalsociety.org.nz/Site/publish/Journals/nzjmfr/1984/8.aspx

This simply makes the assumption that the distribution of sample sites is 
random. 

The application we use is in C++, but I wrote a PostGIS version a few years ago 
as a bash script to demonstrate the functionality from within a db. 

One of the issues we ran into was running repeated iterations then looking at 
the distribution of the points across iterations to check that there was 
genuinely no pattern. Generally most random functions we tested were not truly 
random, there was a trend for coordinates to lie towards the top right or 
bottom left, as random values tended to be < or > 0.5. Not that noticeable with 
a single iteration but statistically present. We wrote our own random() 
function in the program to get around such artifacts.


Cheers,

  Brent Wood


--- On Fri, 5/7/10, Martin Davis  wrote:

> From: Martin Davis 
> Subject: Re: [postgis-users] Dot Density idea
> To: "PostGIS Users Discussion" 
> Date: Friday, May 7, 2010, 5:50 AM
> Did your algorithm work with
> irregular polgon extents?
> 
> Jan Hartmann wrote:
> > I did this long ago. Regular points won't work, you'll
> get all kinds of moire patterns. I just computed random x
> and y values from the origin of the grid cell within the x-
> and y grid-size. Can't remember having any problems with
> overlapping points.
> > 
> > Jan
> > 
> > On 05/06/10 19:35, 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 
> 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<
>  ssuffic...@rov.sbcounty.gov> 
> 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)
> >         
>       )
> >        )
>

Re: [postgis-users] Dot Density idea

[George Silva]

Yea, this is very cool indeed.

George

On Thu, May 6, 2010 at 3:33 PM, David Fawcett wrote:

> Doesn't OpenSource suck!!!
>
>
> On Mon, May 3, 2010 at 11:49 PM, 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
>
> An then an hour later...
>
>
> http://lin-ear-th-inking.blogspot.com/2010/05/random-points-in-polygon-in-jts.html
>
> Sure, it's not a PostGIS solution and isn't exactly there yet, but not
> bad...
>
> Imagine the converse:
>
> Dear Jack,
>
> There is this useful feature that is missing from your software, when
> do you think that you could get it into a release?...
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



-- 
George R. C. Silva

Desenvolvimento em GIS
http://blog.geoprocessamento.net
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[David Fawcett]

Doesn't OpenSource suck!!!


On Mon, May 3, 2010 at 11:49 PM, 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

An then an hour later...

http://lin-ear-th-inking.blogspot.com/2010/05/random-points-in-polygon-in-jts.html

Sure, it's not a PostGIS solution and isn't exactly there yet, but not bad...

Imagine the converse:

Dear Jack,

There is this useful feature that is missing from your software, when
do you think that you could get it into a release?...
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[Jan Hartmann]

I did it just for grids, but the idea could be extended to intersection 
of rectangles and polygons, as David suggests. Don't know how difficult 
this would be for vector maps, but for raster maps the idea looks viable 
to me. Dot-density maps *would* be useful for general mapping, anyway.


Jan

On 05/06/10 19:51, David William Bitner wrote:
If it was the overall density of the dots that mattered and not as 
much the exact number of dots, a representative table could be made 
with a "random yet even" set of dots covering a certain area. To apply 
to a polygon, you could then Scale the data to the appropriate density 
and translate/compute the intersection to apply to a given polygon.


On Thu, May 6, 2010 at 12:50 PM, Martin Davis > wrote:


Did your algorithm work with irregular polgon extents?


Jan Hartmann wrote:

I did this long ago. Regular points won't work, you'll get all
kinds of moire patterns. I just computed random x and y values
from the origin of the grid cell within the x- and y
grid-size. Can't remember having any problems with overlapping
points.

Jan

On 05/06/10 19:35, 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
Davismailto:mbda...@refractions.net>>  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<
ssuffic...@rov.sbcounty.gov
>  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(s

Re: [postgis-users] Dot Density idea

[David William Bitner]

If it was the overall density of the dots that mattered and not as much the
exact number of dots, a representative table could be made with a "random
yet even" set of dots covering a certain area. To apply to a polygon, you
could then Scale the data to the appropriate density and translate/compute
the intersection to apply to a given polygon.

On Thu, May 6, 2010 at 12:50 PM, Martin Davis wrote:

> Did your algorithm work with irregular polgon extents?
>
>
> Jan Hartmann wrote:
>
>> I did this long ago. Regular points won't work, you'll get all kinds of
>> moire patterns. I just computed random x and y values from the origin of the
>> grid cell within the x- and y grid-size. Can't remember having any problems
>> with overlapping points.
>>
>> Jan
>>
>> On 05/06/10 19:35, 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
>>>  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<
> ssuffic...@rov.sbcounty.gov>  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: postgis-users-boun...@postgis.refractions.net
>>> [mailto:postgis-users-boun...@postgis.refractions.net] On
>>> Behalf Of Martin Davis
>>> Sent: Thursday, May 06, 2010 8:56 AM
>>> To: John Abraham; postgis-users@postgis.refractions.net; 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).
>>>
>>>
>>>
>

Re: [postgis-users] Dot Density idea

[Martin Davis]

Did your algorithm work with irregular polgon extents?

Jan Hartmann wrote:
I did this long ago. Regular points won't work, you'll get all kinds 
of moire patterns. I just computed random x and y values from the 
origin of the grid cell within the x- and y grid-size. Can't remember 
having any problems with overlapping points.


Jan

On 05/06/10 19:35, 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  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<
ssuffic...@rov.sbcounty.gov>  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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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.
_

Re: [postgis-users] Dot Density idea

[Martin Davis]

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  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 <
ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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

Re: [postgis-users] Dot Density idea

[Jan Hartmann]

I did this long ago. Regular points won't work, you'll get all kinds of 
moire patterns. I just computed random x and y values from the origin of 
the grid cell within the x- and y grid-size. Can't remember having any 
problems with overlapping points.


Jan

On 05/06/10 19:35, 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  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<
ssuffic...@rov.sbcounty.gov>  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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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 postgis-users@postgis.refr

Re: [postgis-users] Dot Density idea

[Paul Ramsey]

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  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 <
>> ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
 [mailto:postgis-users-boun...@postgis.refractions.net] On
 Behalf Of Martin Davis
 Sent: Thursday, May 06, 2010 8:56 AM
 To: John Abraham; postgis-users@postgis.refractions.net; 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 

Re: [postgis-users] Dot Density idea

[George Silva]

Using St_SnapToGrid is a way to do it. A simple algorithm could calculate
the ideal distance between points depending on the number of resulting
points and then just place them in correct place.

The way to do it is to inform attribute and the value of each dot. On the
same note, a proportional symbols representation could be done, but that can
be very tricky, since building the actual circles could give you extensive
overlap, and they should change according to scale, so I guess that could be
done by software. PostGIS could generate a view using the centroid for
proportional symbols using a point a softwares need to take care of the
representation.

George

On Thu, May 6, 2010 at 2:28 PM, Martin Davis 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 <
>> ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
 [mailto:postgis-users-boun...@postgis.refractions.net] On
 Behalf Of Martin Davis
 Sent: Thursday, May 06, 2010 8:56 AM
 To: John Abraham; postgis-users@postgis.refractions.net; 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 are

Re: [postgis-users] Dot Density idea

[Martin Davis]

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 <
ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On
Behalf Of Martin Davis
Sent: Thursday, May 06, 2010 8:56 AM
To: John Abraham; postgis-users@postgis.refractions.net; 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 postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

  


--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

  

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users






  



___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.re

Re: [postgis-users] Dot Density idea

[George Silva]

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 <
ssuffic...@rov.sbcounty.gov> 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: postgis-users-boun...@postgis.refractions.net
> >[mailto:postgis-users-boun...@postgis.refractions.net] On
> >Behalf Of Martin Davis
> >Sent: Thursday, May 06, 2010 8:56 AM
> >To: John Abraham; postgis-users@postgis.refractions.net; 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 postgis-users@postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>>
> >>
> >>
> >
> >--
> >Martin Davis
> >Senior Technical Architect
> >Refractions Research, Inc.
> >(250) 383-3022
> >
> >___
> >postgis-users mailing list
> >postgis-users@postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



-- 
George R. C. Silva

Desenvolvimento em GIS
http://blog.geoprocessamento.net
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[Sufficool, Stanley]

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: postgis-users-boun...@postgis.refractions.net
>[mailto:postgis-users-boun...@postgis.refractions.net] On
>Behalf Of Martin Davis
>Sent: Thursday, May 06, 2010 8:56 AM
>To: John Abraham; postgis-users@postgis.refractions.net; 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 postgis-users@postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>
>>
>
>--
>Martin Davis
>Senior Technical Architect
>Refractions Research, Inc.
>(250) 383-3022
>
>___
>postgis-users mailing list
>postgis-users@postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[Martin Davis]

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
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



  


--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[Ben Madin]

I have used an R function before (using maptools package) to do something 
similar, but I can't remember the details, so I would be considering looking at 
PL/R.

cheers

Ben



On 06/05/2010, at 15:40 , strk wrote:

> 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?
> 
> PL/pgsql would be easier than SQL at the minimum.
> Still, a C implementation would likely be better, for speed reasons.
> 
> --strk; 
> 
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] OSM2pgsql, OpenStreetMap, MapServer, EPSG:900913, OpenLayers: issue

[Ben Madin]

I think you need to ask this on the MapServer List - MapServer doesn't use the 
postgis spatial_ref_sys table for it's projections, but the proj epsg library 
files, so you need to put the definition in there - I googled " MapServer 
Spherical Mercator Projection 900913 " to find out how to do this.

alternatively, you could just put the projection directly into the mapfile - 
look at http://spatialreference.org/ref/sr-org/6/

and click on MapServer mapfile

PROJECTION
"proj=merc"
"a=6378137"
"b=6378137"
"lat_ts=0.0"
"lon_0=0.0"
"x_0=0.0"
"y_0=0"
"k=1.0"
"units=m"
"nadgri...@null"
"wktext"
"no_defs"
END

good luck.

cheers

Ben

On 06/05/2010, at 21:10 , roshni.spain wrote:

> 
> Hi, I have more or less the same problem than you. I am rendering OSM data
> (imported to PostGIS with osm2pgsql) and i need to view the map with
> OpenLayers on MapServer.
> 
> I am more or less on the same point than you, because when i changed on the
> map file all the projection info to "init=epsg:900913", the map goes blank.
> It comes empty with no information. Plus, the mapserver does not return any
> error in the log, and i really have no clue what i can do to fix this.
> 
> My OSM data table (planet_osm_line) is on epsg:900913 and this is what i
> need to show on the map, but with no success. I have tried many options but
> i can never go further than this.
> Any clue??
> Thank you
> 
> 
> ibrahim saricicek wrote:
>> 
>> Hi;
>> 
>> 1) is your osm data table in Epsg:4326 projection?
>> if so use;  "init=epsg:4326" for each layer..
>> 2) 'grey empty image'?? so you can get map from mapserver?
>> right click on a tile and copy image location. Try the copied url, is
>> there
>> an error?
>> 
>> Regards..
>> 
>> 
>> On Tue, Mar 16, 2010 at 12:20 PM, Mulone1  wrote:
>> 
>>> 
>>> (apologies for cross-posting)
>>> 
>>> Hi everybody,
>>> I'm trying to render openstreetmap data on a WMS on MapServer.
>>> The system used to work with epsg:4326 but in our project we need a
>>> GoogleMaps like projection and we chose epsg:900913.
>>> 
>>> These are the steps I followed to reimport everything for the new
>>> projection:
>>> 
>>> 1) download osm xml file from Cloudmade (e.g. Italy.osm.bz2)
>>> 2) Run 900913.sql on my PostGIS
>>> 3) import that file into PostGIS with command:
>>> 
>>> ./osm2pgsql -U userid -W -H host -d maps -p myprefix -S default.style -c
>>> -m
>>> italy.osm.bz2
>>> 
>>> 4) At this point everything seems ok. The geometry columns have 900913 as
>>> SRID.
>>> 5) update MapFile with:
>>> 
>>> WEB
>>>  METADATA
>>>  wms_srs "epsg:900913"
>>> ...
>>> 
>>> PROJECTION
>>>  "init=epsg:900913"
>>> END
>>> 
>>> Then in each layer I put:
>>> 
>>> PROJECTION  "init=epsg:900913"  END
>>> 
>>> and all of the queries have:  using srid=900913
>>> 
>>> 6) load the wms layer into OpenLayers
>>> with
>>> 
>>> var wms = new OpenLayers.Layer.WMS("OpenStreetMap", mainurl, {
>>> ...
>>> units : 'm',
>>> projection:new OpenLayers.Projection("EPSG:900913"),
>>> ...
>>> 
>>> 
>>> 
>>> Unfortunately all I get is a grey empty image. Looking at the map server
>>> log
>>> I noticed that it's full of:
>>> 
>>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerWhichShapes query status:
>>> 2
>>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerWhichShapes got 0 records
>>> in
>>> result.
>>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerNextShape called.
>>> 
>>> 
>>> With the other projection I was getting the records.
>>> 
>>> Do you have any idea about what could be wrong in my set up? I tried to
>>> debug it in several ways but I couldn't find anything wrong.
>>> 
>>> Cheers,
>>> Mulone
>>> --
>>> View this message in context:
>>> http://old.nabble.com/OSM2pgsql%2C-OpenStreetMap%2C-MapServer%2C-EPSG%3A900913%2C-OpenLayers%3A-issue-tp27915684p27915684.html
>>> Sent from the PostGIS - User mailing list archive at Nabble.com.
>>> 
>>> ___
>>> postgis-users mailing list
>>> postgis-users@postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>> 
>> 
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
>> 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/OSM2pgsql%2C-OpenStreetMap%2C-MapServer%2C-EPSG%3A900913%2C-OpenLayers%3A-issue-tp27915684p28472339.html
> Sent from the PostGIS - User mailing list archive at Nabble.com.
> 
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[David Fawcett]

Not quite the same, but Carson Farmer's fTools plugins for QGIS
include the functionality to create random points (by count or
density) inside of a polygon.

http://www.ftools.ca/plugins.html  Nothing specific about this
functionality on this page, you need to look at the actual plugins in
QGIS.

David.



On Thu, May 6, 2010 at 4:10 AM, 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
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> --
>
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] encoding

[Nicolas Ribot]

> Thanks Ralf,
> I don't understand how to use this.
> pgsql2shp -f myshape mydb -h localhost -P  -u postgres mytable -export
> PGCLIENTENCODING=LATIN1 
>
> I'm using PostGIS 1.3.5 on an Windows-System
> Thanks
> Jo
>
>

You have to define an environment variable that will be used by PG
when exporting.

set PGCLIENTENCODING=LATIN1
then execute the plpgsql command

Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] encoding

[jj.wag]

Thanks Ralf,
I don't understand how to use this.
pgsql2shp -f myshape mydb -h localhost -P  -u postgres mytable -export 
PGCLIENTENCODING=LATIN1 


I'm using PostGIS 1.3.5 on an Windows-System
Thanks
Jo


- Original Message - 
From: "Ralf Suhr" 

To: "PostGIS Users Discussion" 
Sent: Thursday, May 06, 2010 3:38 PM
Subject: Re: [postgis-users] encoding



Hi Jo,

export PGCLIENTENCODING=LATIN1; pgsql2shp ...

will work

Gr
Ralf

Am Donnerstag 06 Mai 2010 15:30:35 schrieb jj@gmx.de:

Hi,
If I try to load a Latin1 Shape to my UTF-8 database there is no Problem 
to

convert the encoding:
shp2pgsql -d -s 31466 -W Latin1 -I myshape mytable | psql -U postgres -d
mydb

But if I want to export with pgsql2shp there is no flag to convert the
encoding from utf-8 to latin1
With ogr2ogr I have the same problem.
Any idea?

Greetings Jo

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] encoding

[Ralf Suhr]

Hi Jo,

export PGCLIENTENCODING=LATIN1; pgsql2shp ...

will work

Gr
Ralf

Am Donnerstag 06 Mai 2010 15:30:35 schrieb jj@gmx.de:
> Hi,
> If I try to load a Latin1 Shape to my UTF-8 database there is no Problem to
> convert the encoding:
> shp2pgsql -d -s 31466 -W Latin1 -I myshape mytable | psql -U postgres -d
> mydb
> 
> But if I want to export with pgsql2shp there is no flag to convert the
> encoding from utf-8 to latin1
> With ogr2ogr I have the same problem.
> Any idea?
> 
> Greetings Jo
> 
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] encoding

[jj.wag]

Hi,
If I try to load a Latin1 Shape to my UTF-8 database there is no Problem to
convert the encoding:
shp2pgsql -d -s 31466 -W Latin1 -I myshape mytable | psql -U postgres -d
mydb

But if I want to export with pgsql2shp there is no flag to convert the
encoding from utf-8 to latin1
With ogr2ogr I have the same problem.
Any idea?

Greetings Jo 


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] OSM2pgsql, OpenStreetMap, MapServer, EPSG:900913, OpenLayers: issue

[roshni.spain]

Hi, I have more or less the same problem than you. I am rendering OSM data
(imported to PostGIS with osm2pgsql) and i need to view the map with
OpenLayers on MapServer.

I am more or less on the same point than you, because when i changed on the
map file all the projection info to "init=epsg:900913", the map goes blank.
It comes empty with no information. Plus, the mapserver does not return any
error in the log, and i really have no clue what i can do to fix this.

My OSM data table (planet_osm_line) is on epsg:900913 and this is what i
need to show on the map, but with no success. I have tried many options but
i can never go further than this.
Any clue??
Thank you


ibrahim saricicek wrote:
> 
> Hi;
> 
> 1) is your osm data table in Epsg:4326 projection?
> if so use;  "init=epsg:4326" for each layer..
> 2) 'grey empty image'?? so you can get map from mapserver?
> right click on a tile and copy image location. Try the copied url, is
> there
> an error?
> 
> Regards..
> 
> 
> On Tue, Mar 16, 2010 at 12:20 PM, Mulone1  wrote:
> 
>>
>> (apologies for cross-posting)
>>
>> Hi everybody,
>> I'm trying to render openstreetmap data on a WMS on MapServer.
>> The system used to work with epsg:4326 but in our project we need a
>> GoogleMaps like projection and we chose epsg:900913.
>>
>> These are the steps I followed to reimport everything for the new
>> projection:
>>
>> 1) download osm xml file from Cloudmade (e.g. Italy.osm.bz2)
>> 2) Run 900913.sql on my PostGIS
>> 3) import that file into PostGIS with command:
>>
>> ./osm2pgsql -U userid -W -H host -d maps -p myprefix -S default.style -c
>> -m
>> italy.osm.bz2
>>
>> 4) At this point everything seems ok. The geometry columns have 900913 as
>> SRID.
>> 5) update MapFile with:
>>
>> WEB
>>METADATA
>>wms_srs "epsg:900913"
>> ...
>>
>> PROJECTION
>>"init=epsg:900913"
>> END
>>
>> Then in each layer I put:
>>
>> PROJECTION  "init=epsg:900913"  END
>>
>> and all of the queries have:  using srid=900913
>>
>> 6) load the wms layer into OpenLayers
>> with
>>
>> var wms = new OpenLayers.Layer.WMS("OpenStreetMap", mainurl, {
>> ...
>> units : 'm',
>> projection:new OpenLayers.Projection("EPSG:900913"),
>> ...
>>
>>
>>
>> Unfortunately all I get is a grey empty image. Looking at the map server
>> log
>> I noticed that it's full of:
>>
>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerWhichShapes query status:
>> 2
>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerWhichShapes got 0 records
>> in
>> result.
>> [Mon Mar 15 17:49:44 2010].517000 msPostGISLayerNextShape called.
>>
>>
>> With the other projection I was getting the records.
>>
>> Do you have any idea about what could be wrong in my set up? I tried to
>> debug it in several ways but I couldn't find anything wrong.
>>
>> Cheers,
>> Mulone
>> --
>> View this message in context:
>> http://old.nabble.com/OSM2pgsql%2C-OpenStreetMap%2C-MapServer%2C-EPSG%3A900913%2C-OpenLayers%3A-issue-tp27915684p27915684.html
>> Sent from the PostGIS - User mailing list archive at Nabble.com.
>>
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
> 
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OSM2pgsql%2C-OpenStreetMap%2C-MapServer%2C-EPSG%3A900913%2C-OpenLayers%3A-issue-tp27915684p28472339.html
Sent from the PostGIS - User mailing list archive at Nabble.com.

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[strk]

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
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Dot Density idea

[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?

PL/pgsql would be easier than SQL at the minimum.
Still, a C implementation would likely be better, for speed reasons.

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users