[postgis-users] Pipeline Data Model

[Burgholzer,Robert]

We might think to do a little divide and conquer strategy on the database that Abe has, perhaps recruiting a group of individuals to each sign up for a handful of tables to convert to postgres, and then upload them all to a sourceforge repository.



r.b.


-----Original Message-----
From:	postgis-users-bounces at postgis.refractions.net on behalf of Chris Hermansen
Sent:	Sun 1/13/2008 12:47 PM
To:	PostGIS Users Discussion
Cc:	
Subject:	Re: [postgis-users] Pipeline Data Model

Gustavo makes a great point here.

Having worked with workstation ArcInfo for many years, I have a kind of
"conceptual library" of how to do common tasks in the field in which I work.

As I use PostGIS I have to re-learn this "conceptual library", based on
the building blocks defined by OGC.  I have to say that my general
impression is that the OGC geoprocessing model sometimes necessitates
some pretty complicated SQL to achieve what is relatively
straightforward in workstation ArcInfo, an example being given in the
Wiki on geometrically combining partially overlapping polygon geometries
so as not to generate null geometries where only one or the other input
geometry exists.

In our company, we are (slowly) working on some documentation that
demonstrates how to accomplish "model tasks" in PostGIS.

One of the biggest challenges we face (and would face on platforms other
than PostGIS as well) is cleaning up the cruft coming in from all the
nasty shapefiles floating around out there.  For example,
self-overlapping polygon geometry, gaps between polygons that aren't
supposed to be there, tiny noise components arising from unfiltered
GPS-source data.  I could go on :-)

Another area of challenges is where we want a different geometric
outcome than provided for in the OGC standard.  A simple example is
first being surprised by, then dealing with, degenerate geometries or
composite geometries generated by what seem to be fairly straightforward
geometric operations.  A more complex example is the example given above
- most of the time, when we overlay partially overlapping geometries, we
don't want null geometries as a result in locations where only one or
the other input geometry exists, rather we want whatever geometry exists
with the appropriate attributes set to null.

Another is creating new geometries from components - geometries from
text files, polygons from lines and points, etc.

Two things I see discussed on this list that could be of interest in the
future are topology and time travel.  Way back when PostgreSQL was just
Postgres I did some work with time travel; I can see real potential in
the concept, for example as a framework for managing and reporting on
environmental certification.  However that's a big design issue even
with time travel working :-)  With respect to topology, I'm surprised
how little I miss it; though there are people in our offices who find
it's the only solution for fixing up really nasty shape files; ie
convert the data to coverages and bang away at them using the polygon
topology until either nothing is left or the problem is fixed.

Anyway.  Whether the approach to sharing this kind of info is through
separate projects or just a bit more input to the PostGIS wiki, it seems
pretty worthwhile to me.

Gustavo Ces wrote:
> You can´t export a geodatabase ( i supose your model is just that) by
> odbc, because the geometric logic is not transfered ( can you export a
> geodatabase in arcgis to postgis?) I think you have to rewrite the
> model, adapting it to postgis. Is a hard work, but the you can use the
> postgresql full potential ( triggers, views, etc.. ) to make your
> model more powerfull, smaller and dynamic.
> In my experience, this work simplifies the model, and you can make it
> "real-time", user adapted, etc...
>
> I´ve posted a long time ago a question about postgis models. I imagine
> all postgis community members working alone, creating complex
> functions and schemas to solve their problems and... reinventing the
> wheel. Perhaps it´s time to create especific projects to create ( or
> traduce ) schemas and functions for various cases. I know the wiki,
> but i think in environmental members creating  schemas, functions to
> solve environmental questions( for instance). At this time each of
> them has to walk his way alone ...
>
> It´s just an opinion :)
>
> Gus
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users


-- 
Regards,

Chris Hermansen · mailto:clh at timberline.ca
tel:+1.604.714.2878 · fax:+1.604.733.0631
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5

C'est ma façon de parler.

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5576 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20080114/be7461b5/attachment.bin>