[postgis-users] srid

Tue May 27 11:49:59 PDT 2008

Hi Regina and Bob,

Wow, IDEF in PostGIS. 
	Awhile back I struggled with rendering IDEF node layouts for simple
IDEF web navigation and ended up using the xml DB eXist
(http://exist.sourceforge.net/ ) for my store and then exporting to SVG for
rendering. I could then use something like jung graph
(http://jung.sourceforge.net/) to create a navigation node diagram. Perhaps
I could have considered the IDEF hierarchy as a 3D spatial model in PostGIS.
Hierarchy levels would be z values while the interlevel diagrams would be
x,y. I did experiment a bit with rendering IDEF as 3D WPF, but didn't get
very far at least not far enough to think about using PostGIS as the backing
store. 

But I think DDD reminds me more of parametric design in AEC community circa
1980. The idea there was to utilize geometry from CAD to trigger rules based
on physical properties and construction parameters that in turn automated an
instance design. So in theory, the architectural CAD design laid out macro
geometry and materials properties to feed the Engineering design which added
physical properties, design loads, etc and then flowed into manufacturing to
create individual item designs complete with tooling and bills of materials,
all based on stored rules. I assume that this has all evolved into something
much more sophisticated since my experience in the '80s.

Since "Transform" in the CAD world probably means 'matrix transform' rather
than 'coordinate system transform' as in the GIS world I wonder if there is
a vocabulary misalignment in the discussion of ST_Transform. I think Bob
wants to use ST_Affine.

GIS 'coordinate system transform' also fits into DDD since a design instance
exists somewhere on the planet. I imagine that a UTM based coordinate system
makes sense for a DDD scenario. The curious question is where to place the
abstract model from which design instances are created by the rules? I guess
wherever the abstract model is located you need to both ST_Transform to the
appropriate UTM zone,units, and then ST_Affine to the proper physical
location for the DDD instance. Unfortunately a familiar engineering 0,0,0
Cartesian origin doesn't exactly fit well. The nice thing about this
approach is the final instance model is entirely georeferenced and can be
exported to a variety of 3D viewers GE, VE, WPF, X3D ...

I just saw this too:
http://www.foss4g2007.org/presentations/viewattachment.php?attachment_id=92 

It sounds like X3D, Google SKP, WPF are all beginning to point out the need
for general FOSS geometry storage in 3D.  

randy

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Obe,
Regina
Sent: Tuesday, May 27, 2008 9:37 AM
To: PostGIS Users Discussion
Subject: RE: [postgis-users] srid

Bob,

This looks neat.  Don't quite understand all of it, but will be
interesting to see what the final finished product looks like.

This vaguely reminds me of autogenerating IDEF diagrams from
hierarchical data -
http://www.eod.gvsu.edu/eod/automate/automate-40.html  

I liked IDEF mostly because the code was easy to generate from
well-structured data and it gave you a graphical reprensentation.

Although I have since forgotten all that stuff. 

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Bob
Pawley
Sent: Tuesday, May 27, 2008 10:41 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] srid

Hi Regina

You are right in thinking that the Postgis model can be useful in apps
other 
that geographic.

My little project is best summed up by the term Data Driven Design. 
Basically, I have created a prototype design model for designing
industrial 
plants (Oil and Gas, Pulp and Paper etc.) in PostgreSQL. For the
functions 
so far included, it works quite well.

The principal behind DDD is the wealth of information hidden within
basic 
data and the fact that there are fundamental scientific laws and wide 
ranging industry standards that can be employed to drive information,
which 
then drives further information until the design is complete.

What I am now doing is attempting to use the data to drive the graphic 
representation of the relational datastream. It wouldn't do to have a
data 
system, which will soon become self organizing and self generating, then

expect the user to manually draw the graphics one line, one circle and
one 
peice of text at a time.

If you're interested in learning more about my version of Data Driven
design 
check out my website www.automatingdesign.com.

I can easily see this technology being exploited for other industries
such 
as architectural and the facility design for the manufacturing industry
and, 
quite possibly, many others.

Bob

----- Original Message ----- 
From: "Paragon Corporation" <lr at pcorp.us>
To: "'PostGIS Users Discussion'" <postgis-users at postgis.refractions.net>
Sent: Monday, May 26, 2008 8:08 PM
Subject: RE: [postgis-users] srid

> Bob,
>
> I find it very interesting what you are trying to do.  I've always
thought
> that the whole spatial database model can be usefully applied to other
> domains besides geography.  It is nice to see someone trying to do
that.
>
> As far as ST_Transform goes,  still not quite clear how it plays into
your
> problem.  To be honest - I haven't really delved into the guts of what
> assumptions proj4 makes about geometry models except that it was
founded 
> on
> dealing with geography data.
>
> The whole Transformation infrastructure of PostGIS is based on proj4
and
> really the proj4text in the spatial_ref_sys as far as I know is all
that 
> is
> used by the PostGIS ST_Transform (srid for lookup).
>
> I would imagine to expand its use for other domains in a meaningful
way we
> would probably have to replace the field proj4text in spatial_ref_sys 
> tables
>
> with  - projmodeltext,  projmodel
>
> Where projmodel would define a library used for doing the spatial 
> transforms
> (in current case - they would all be filled in with 'proj4') , 
> projmodeltext
> would be the transformation params that the model needs
> and then any spatial reference systems based on the same function
model 
> can
> be transformed in between each other.
>
> Note: PostGIS actually deviates from the standard OGC spatial_ref_sys
> structure in that in the plain vanilla OGC Spatial_ref_sys,  proj4text

> field
> doesn't exist.
>
>
> Just my 2 cents,
> Regina
>
>
> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of
Bob
> Pawley
> Sent: Monday, May 26, 2008 9:34 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] srid
>
> 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.
>
> Bob
>
>
> ----- 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 
>>> geographies.
>>>
>>> So it sounds like you need to pick a particular projection for your 
>>> work.
>>>
>>> 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
>>> direction?
>>>
>>> -- Andy
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> -- 
>> Regards,
>>
>> 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
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users 

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users