No, just translate/reposition the child entity based on the width/height
of the parent entity. However, in thinking about this, it should be 1 *
width/height/depth plus a predefined constant for the spacing between
the entities.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Burgholzer,Robert
Sent: Monday, June 02, 2008 8:04 AM
To: PostGIS Users Discussion; PostGIS Users Discussion
Subject: RE: [postgis-users] Creating a Flow Diagram with
PostGIS
Stanley,
Do I read this right that you have a facility in here to scale
the child object based on some factor (ratio_x)?
r.b.
-----Original Message-----
From: [EMAIL PROTECTED] on behalf
of Sufficool, Stanley
Sent: Mon 6/2/2008 10:53 AM
To: PostGIS Users Discussion
Cc:
Subject: RE: [postgis-users] Creating a Flow Diagram with
PostGIS
Here's my possibly buggy 2 cents:
This stores all geometry as geometry, not x,y attribute values.
The
intent is to allow moving entities and have the database handle
the
updates to related entities.
=========================================
create table entity(
entity_id serial not null primary key,
the_geom geometry not null,
is_calculated bit not null
);
-- Your Entity to Entity relationships with offset multipliers
for
-- placement relative to the parent entity extents and position
which
-- is also relative to it's parent level entity position
create table entity_relation (
parent_entity_id int not null,
child_entity_id int not null,
ratio_x float4 not null,
ratio_y float4 not null,
ratio_z float4 not null,
primary key(parent_entity_id,child_entity_id )
);
/*
I havent done triggers, but this should be a trigger
function on
UPDATE of parent geomentry
PURPOSE: placement of child entities in relation to the
parent
entity,
Watch for Recursion!! 1-->2-->3-->1
Step 1: Center child on parent
Step 2: Offset by er.offset_N of parent extents
Step 3: Mark child as updated to prevent
recursion
*/
update c
SET c.the_geom =
select st_translate(
-- Center the child on parent geometry
st_translate(
c.the_geom,
st_x(st_centroid(p.the_geom)) -
st_x(st_centroid(c.the_geom)),
st_y(st_centroid(p.the_geom)) -
st_y(st_centroid(c.the_geom)),
st_z(st_centroid(p.the_geom)) -
st_z(st_centroid(c.the_geom))
},
--Translate to the left, right, top, bottom, front, back
of the
parent geometry by the ratio (x,y,x) stored in entity_relation
of the
parent entity width/height
( st_xmax(p.the_geom) - st_xmin(p.the_geom) ) *
er.ratio_x,
( st_ymax(p.the_geom) - st_ymin(p.the_geom) ) *
er.ratio_y,
( st_zmax(p.the_geom) - st_zmin(p.the_geom) ) *
er.ratio_z
),
is_calculated = 1
from entity as c
join entity_relation as er
on c.entity_id = er.child_entity_id
join entity as p
on er.parent_entity_id = p.entity_id
WHERE is_calculated=0 --To prevent recursive updates
AND p.entity_id = OLD.entity_id --Update from the OLD trigger
record
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bob
Pawley
Sent: Sunday, June 01, 2008 2:17 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Creating a Flow Diagram with
PostGIS
Hi Robert
I managed to get the function working - in part.
UPDATE graphics.process_dgm
Set the_geom = translate(the_geom, (x1 -
st_x(the_geom)), (y1 -
st_y(the_geom)))
where graphics.process_dgm.id = '178'
and graphics.process_dgm.id = '181';
This will move a point from one location to another depending on
what I
insert into the x and y column.
But when I attempt to move the geometry that I want moved I get
a
message
"Argument to X() must be a point".
What am I doing wrong??
Bob
----- Original Message -----
From: "Burgholzer,Robert" <[EMAIL PROTECTED]>
To: "PostGIS Users Discussion"
<postgis-users@postgis.refractions.net>
Sent: Friday, May 30, 2008 11:54 AM
Subject: [postgis-users] Creating a Flow Diagram with PostGIS
Bob,
I am taking this online, since it is relevant to PostGIS, and I
want to
make
sure that others review my comments for veracity
Original Question:
> At the moment I am importing dxf files, representing process
and
> devices, into Postgis.
>
> Say I want to make two processes A & B.
>
> I import the DXF graphic representing A and B into Postgis.
>
> I want B to be the first process and the output of B goes to A
which
> is situated to the right of or below B.
>
> Using ST_Translate I need to know the distance in both x and y
from
> the library to where I want to place the images and plug thos
values
> into the Transform function. Perhaps there is a method of
building a
> function to do this?
>
> Bob
>
>
My response:
You do not want to use transform for the location. It has
nothing to do
with the location, only to the projection, i.e., spatial
coordinate
system.
You DO want translate for location, however. Transform might be
useful
if
your objects are not imported from a standard library that you
generate,
or
are not in the projection that you wish to use for your
interface.
CASE 1 (Objects are in same projection as your "Workspace"):
In this case, we don't really have to "know" where the starting
location
is,
since we have functions that can derive this. Also, since our
shapes
are in
the same projection as the workspace, we only need the translate
function.
For this example, we are storing our components in a table
called
"widget_table", and the geometry column is "the_geom". Let's
assume
that
your original shape location coordinates are (x0, y0, z0), which
can be
obtained from the geometry column by using the function st_x,
st_y, and
st_z, and you want to move them to be located at (x1,y1,z1).
For this,
the
following translate call would work:
UPDATE widget_table SET the_geom = translate(the_geom, (x1 -
st_x(the_geom)), (y1 - st_y(the_geom)), (z1 - st_z(the_geom))) ;
CASE 2 (you are importing user defined shapes, or shapes in
disparate
projections):
In this case you WOULD need transform(), to take them from
whatever
their
source projection is, into whatever their base projection is, as
follows
(assuming that the workspace coordinate system is decimal
degrees):
UPDATE widget_table SET the_geom = transform(the_geom, 4326);
Then, you would need to relocate them to some other point by
using the
function above. That function could be encapsulated into its
own PG
function of course, something like relocate(x1,y1,z1) which
would hide
all
of the calls to st_x,y and z.
The catch of course, is that it is essential that we KNOW the
projection
of
our shapes before importing them. That is actually the real
sticky part
here, not the movement of them.
HTH,
r.b.
Quoting Bob Pawley <[EMAIL PROTECTED]>:
> Robert
>
------------------------------------------------------------------------
--------
> _______________________________________________
> 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
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
