Just as an update, I have submitted a project for sourceforge hosting approval, called "Environmental Data Models", short name "envirodata".
Perhaps the "envirodata" moniker is too restrictive, maybe, ogcdata would be better. Since I didn't get any feedback, I just called it something that I thought was relevant. Any suggestions would be welcome. I will mail more when I get approval. r.b. Robert W. Burgholzer Surface Water Modeler Office of Water Supply and Planning Virginia Department of Environmental Quality [EMAIL PROTECTED] 804-698-4405 Open Source Modeling Tools: http://sourceforge.net/projects/npsource/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Burgholzer,Robert Sent: Monday, January 14, 2008 12:26 PM To: PostGIS Users Discussion; PostGIS Users Discussion Subject: RE: [postgis-users] Pipeline Data Model OK, I will begin the process of starting a sourceforge project to house the data models and supporting SQL functions, etc. It would be great if Abe can facilitate some space for some of this as well, I think that the sourceforge is a good way to go about managing contributions and so forth, but if geoloaded.com could host some demos/case-studies, that would be really great (if that is what you have in mind). What would we be trying to do, putting together/porting some data models for this kind of pipeline/hydro data? What would it be called, i.e., what would one call a generic class of data models that would encapsulate that which we are working on? r.b. -----Original Message----- From: [EMAIL PROTECTED] on behalf of Abram Gillespie Sent: Mon 1/14/2008 11:35 AM To: PostGIS Users Discussion Cc: Subject: Re: [postgis-users] Pipeline Data Model All, These are all very interesting ideas. I have a proposal - I've been meaning to get a site running at geoloaded.com (nothing there ATM), and though sharing data models isn't *specifically* the idea I had in mind, it's very much in the spirit of what I intend to do. I'm happy to host anything the group manages to put together. I'm not clear on the EULA of the data model I currently have in my possession, but if I can, I will post my results at the site as soon as I have something. R.B., I'm swamped right now but will be in touch as soon as I have a moment. I live at 14th & Main BTW. Small world indeed. -Abe On Jan 14, 2008 7:47 AM, Burgholzer,Robert <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] 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@postgis.refractions.net > > http://postgis.refractions.net/mailman/listinfo/postgis-users > > > -- > Regards, > > Chris Hermansen · mailto:[EMAIL PROTECTED] > 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@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