chris.hermansen at timberline.ca
Mon May 26 20:23:04 PDT 2008
Ok, I think I'm tuned in now :-)
So the main purpose of st_transform() is to convert geographical data
from one coordinate system to another.
For example, a lot of our spatial data is provided in a rectangular
projection called "UTM". When we want to make a Google Maps "mashup",
we need to convert our data back into latitude / longitude.
This is the kind of thing for which st_transform() is designed.
For your use, I would think you might, say, define each one of your
processes as a point, say (0 0). Then you would go about shifting
processes' coordinates relative to each other. For example, if you did
your topological sort you might have one process at (0 0), another at
(-10 0), another at (-10 10), another at (-20 0), and so on.
You don't need to use some PostGIS function to do that. All you really
need to do is compute the offset from one process to another. If you
processed your data row by row, in a stored procedure, say, or in a
cursor in a programming language like Python or Java, and the data was
sorted in a partial ordering, or say by work breakdown structure or some
other ordering, then you could compute your coordinates on that
You'd have to get a bit fancier if you wanted to draw arrows from one
point to another.
You don't really need the geographic bits provided by PostGIS, the
geometry from PostgreSQL is fine for this. However, it would be useful
to be able to view your resulting "process space" with e.g. OpenJump or
So essentially you would be using PostgreSQL to hold your process
descriptions (one per logical table row, though you might normalize it
in some way), PostgreSQL stored procedures to compute your geometry, and
the geometry viewing capabilities of some desktop GIS to view the end
Not exactly a "normal" GIS application but nothing wrong with it,
either. And human geographers are always going on about maps of things
other than physical space...
Just another thought: you can do the same kind of computations and write
out XML that is compatible with Dia. For example, if you have your
processes in a spreadsheet, say by work breakdown structure, you can
read that spreasheet with VBA or Python and write out XML. Not knowing
much about what you're doing, still I'd hazard a guess that this would
be the approach I'd take if I had to do something like this.
Note I'm saying things like "Dia" and "Python" because those are the
tools I use. Others would prefer to do this with VBA and Visio.
Bob Pawley wrote:
> That is what I am attempting.
> I know of Visio. My thought of using Postgis is to, if possible, use
> the functions that Postgis provides. In the very long range I was also
> considering the 3D aspect of Postgis.
> Your suggestion of using "boxes", presumably to provide reference
> points is my backup method, if ST_Transform isn't applicable.
> I would still like to consider ST_Transform as it appears to be a more
> flexible approach.
> ----- Original Message ----- From: "Chris Hermansen"
> <chris.hermansen at timberline.ca>
> To: "PostGIS Users Discussion" <postgis-users at postgis.refractions.net>
> Sent: Monday, May 26, 2008 6:05 PM
> Subject: Re: [postgis-users] srid
>> Or, in another direction... Bob, if your "geometrical data" is meant to
>> be something like a "data flow diagram" or a "process diagram", you can
>> surely do that with PostGIS.
>> Doubtless you must be aware of tools like Visio (in Windoze) or Dia (in
>> Linux or Windoze) that are made for drawing diagrams like "data flow",
>> but nevertheless you've decided to put your data into PostGIS instead.
>> Then you probably want to make some "boxes" in your process diagram
>> appear above, below, to the right of, or to the left of, other boxes.
>> To do that, you would need to define some kind of partial order on the
>> boxes (this box is to the right of that box, etc). This sounds like a
>> topological sort to me.
>> Presumably you could turn that topological ordering into some set of
>> offsets that could be applied to compute coordinates of each box.
>> is that where you're trying to end up?
>> Andy Anderson wrote:
>>> On May 26, 2008, at 3:06 PM, Bob Pawley wrote:
>>>> However, I attempting to interpret functions made for geographic data
>>>> to use with geometric data.
>>>> I have PostgreSQL tables which represent engineering processes.
>>>> I want to display that data in a graphical form - hopefully using
>>>> Postgis - - - if I can translate the functions (or the Postgis
>>>> concept) into a form that I can use.
>>> Hmmm... if all you want to do is display X-Y data, I would suggest
>>> using geographic coordinates, e.g. SRID = 4326 (WGS84 datum), which
>>> most programs will display by default with X and Y rectilinear.
>>> However, you earlier said you wanted to use ST_Transform(geometry,
>>> integer), which implies you want to switch between different
>>> So it sounds like you need to pick a particular projection for your
>>> Is your geography spherical or spheroidal? If so, you might want to
>>> define your own datum. If not, you'll need to use a projection to a
>>> flat surface. What's more important, that it be conformal
>>> (equiangular) or equal area or that it preserve distance in one
>>> -- Andy
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>> Chris Hermansen mailto:chris.hermansen at timberline.ca
>> tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
>> Timberline Natural Resource Group · http://www.timberline.ca
>> 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
> postgis-users mailing list
> postgis-users at postgis.refractions.net
Chris Hermansen mailto:chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5
More information about the postgis-users