See below...

On Tue, 2010-06-29 at 23:12 -0500, P Kishor wrote:
> 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.

Of course, that would be the "normal" way to do things.

> 
> 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.
> 

All of this is possible, but I would also note that you can probably
ignore the cell_ids as well. If you have a lat/lon click, then you can
just do an inverse transformation to find the X/Y coords (in image
space), and then just slice out the data you want from the image based
on those coords.

Things would get a little more complicated if you were using a map
projection, but the PDL::GIS::Proj interface could easily handle that as
well. 

My answer is assuming things about the format of the PDL data, however.
If your clicks are in lat/lon, then you should probably store the PDL
data in a eqc projection (aka no projection), were you can just do a
simple linear calculation from the lat/lon to the image space
coordinates.

> 
> 
-- 
____________________________
Judd Taylor
Software Engineer

Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415

[email protected]
(972) 915-3669 x127

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

Reply via email to