I have a rectangular map of square grid cells. Each grid cell has an
x,y (lat,lon) centroid, and a serial number, the cell_id, starting at
0,0 in the top-left corner, and increasing to the right and down. Here
is a picture

1     2    3  ..  9
10  11  12 .. 19
..

(except, in my map, the rows are much longer).

Right now, these "cells" are stored in Postgres/PostGIS, with the
geometry in a geometry-type column which enables drawing a grid image
and sending it to the browser. When a user clicks on or selects an
area of the map in the browser, the pixel coords are converted to
lat-lon, and a Pg query is able to retrieve the cell(s) that match the
click or the select area.

I am considering storing some of the attribute data for these cells as
a rectangular piddle, in files (hence, my experimentation with
FastRaw, and range() and at(), etc.). PDL is fast. Very, very fast.
Much faster than the database, in my initial, non-scientific tests.

However, in order to find the correct attributes, I have to have the
x,y of the piddle elements I want. But, what I have is the lat-lon of
the user click or area selection. Of course, I can query the Pg table,
get the cell_ids (the serial number), have a function that calculates
the x,y based on the serial number, and then look up in the piddle.
What I am wondering is -- can I bypass the db completely? Because of
my geog. transformation, the lat-lon spaces maps to the rectangular
space.

Hence, can I --
1. based on a click or an area selection, determine the cell_ids of
the one or more cells (the click will fall in a square cell, hence the
cell_id of that cell, and the area selection will "contain" within it,
for some definition of "contain," many square cells, hence the
cell_ids of those cells);

2. convert the cell_ids from #1 above to x,y coords of the PDL;

3. use range() or at() to retrieve the values for those cells from the PDL;

4. do something with those values, like, make an image using PLplot or GD?

How?

I want to do this because: (1) as I said, PDL is way faster than a db;
(2) PDL is way funner than a db; (3) it is a nice challenge, worth
exploring.

Since I am way too new with PDL, I would appreciate any guidance I can get.



-- 
Puneet Kishor

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to