<div>The great part of this data model is the use of linear referencig. does postgis support linear referencig? or any software that works with it?</div>
<div> </div>
<div>im happy to help with all data models you guys are interested in building. just drop me a line</div>
<div> </div>
<div>george<br><br> </div>
<div><span class="gmail_quote">On 1/14/08, <b class="gmail_sendername">Abram Gillespie</b> <<a href="mailto:abe.gillespie.lists@gmail.com">abe.gillespie.lists@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">All,<br><br>These are all very interesting ideas. I have a proposal - I've been<br>meaning to get a site running at
<a href="http://geoloaded.com">geoloaded.com</a> (nothing there ATM),<br>and though sharing data models isn't *specifically* the idea I had in<br>mind, it's very much in the spirit of what I intend to do. I'm happy
<br>to host anything the group manages to put together. I'm not clear on<br>the EULA of the data model I currently have in my possession, but if I<br>can, I will post my results at the site as soon as I have something.
<br><br>R.B.,<br><br>I'm swamped right now but will be in touch as soon as I have a moment.<br>I live at 14th & Main BTW. Small world indeed.<br><br>-Abe<br><br>On Jan 14, 2008 7:47 AM, Burgholzer,Robert<br><<a href="mailto:rwburgholzer@deq.virginia.gov">
rwburgholzer@deq.virginia.gov</a>> wrote:<br>> 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.
<br>><br>><br>><br>> r.b.<br>><br>><br>> -----Original Message-----<br>> From: <a href="mailto:postgis-users-bounces@postgis.refractions.net">postgis-users-bounces@postgis.refractions.net</a> on behalf of Chris Hermansen
<br>> Sent: Sun 1/13/2008 12:47 PM<br>> To: PostGIS Users Discussion<br>> Cc:<br>> Subject: Re: [postgis-users] Pipeline Data Model<br>><br>><br>> Gustavo makes a great point here.<br>>
<br>> Having worked with workstation ArcInfo for many years, I have a kind of<br>> "conceptual library" of how to do common tasks in the field in which I work.<br>><br>> As I use PostGIS I have to re-learn this "conceptual library", based on
<br>> the building blocks defined by OGC. I have to say that my general<br>> impression is that the OGC geoprocessing model sometimes necessitates<br>> some pretty complicated SQL to achieve what is relatively<br>
> straightforward in workstation ArcInfo, an example being given in the<br>> Wiki on geometrically combining partially overlapping polygon geometries<br>> so as not to generate null geometries where only one or the other input
<br>> geometry exists.<br>><br>> In our company, we are (slowly) working on some documentation that<br>> demonstrates how to accomplish "model tasks" in PostGIS.<br>><br>> One of the biggest challenges we face (and would face on platforms other
<br>> than PostGIS as well) is cleaning up the cruft coming in from all the<br>> nasty shapefiles floating around out there. For example,<br>> self-overlapping polygon geometry, gaps between polygons that aren't
<br>> supposed to be there, tiny noise components arising from unfiltered<br>> GPS-source data. I could go on :-)<br>><br>> Another area of challenges is where we want a different geometric<br>> outcome than provided for in the OGC standard. A simple example is
<br>> first being surprised by, then dealing with, degenerate geometries or<br>> composite geometries generated by what seem to be fairly straightforward<br>> geometric operations. A more complex example is the example given above
<br>> - most of the time, when we overlay partially overlapping geometries, we<br>> don't want null geometries as a result in locations where only one or<br>> the other input geometry exists, rather we want whatever geometry exists
<br>> with the appropriate attributes set to null.<br>><br>> Another is creating new geometries from components - geometries from<br>> text files, polygons from lines and points, etc.<br>><br>> Two things I see discussed on this list that could be of interest in the
<br>> future are topology and time travel. Way back when PostgreSQL was just<br>> Postgres I did some work with time travel; I can see real potential in<br>> the concept, for example as a framework for managing and reporting on
<br>> environmental certification. However that's a big design issue even<br>> with time travel working :-) With respect to topology, I'm surprised<br>> how little I miss it; though there are people in our offices who find
<br>> it's the only solution for fixing up really nasty shape files; ie<br>> convert the data to coverages and bang away at them using the polygon<br>> topology until either nothing is left or the problem is fixed.
<br>><br>> Anyway. Whether the approach to sharing this kind of info is through<br>> separate projects or just a bit more input to the PostGIS wiki, it seems<br>> pretty worthwhile to me.<br>><br>> Gustavo Ces wrote:
<br>> > You canīt export a geodatabase ( i supose your model is just that) by<br>> > odbc, because the geometric logic is not transfered ( can you export a<br>> > geodatabase in arcgis to postgis?) I think you have to rewrite the
<br>> > model, adapting it to postgis. Is a hard work, but the you can use the<br>> > postgresql full potential ( triggers, views, etc.. ) to make your<br>> > model more powerfull, smaller and dynamic.<br>
> > In my experience, this work simplifies the model, and you can make it<br>> > "real-time", user adapted, etc...<br>> ><br>> > Iīve posted a long time ago a question about postgis models. I imagine
<br>> > all postgis community members working alone, creating complex<br>> > functions and schemas to solve their problems and... reinventing the<br>> > wheel. Perhaps itīs time to create especific projects to create ( or
<br>> > traduce ) schemas and functions for various cases. I know the wiki,<br>> > but i think in environmental members creating schemas, functions to<br>> > solve environmental questions( for instance). At this time each of
<br>> > them has to walk his way alone ...<br>> ><br>> > Itīs just an opinion :)<br>> ><br>> > Gus<br>> ><br>> > _______________________________________________<br>> > postgis-users mailing list
<br>> > <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>> > <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users
</a><br>><br>><br>> --<br>> Regards,<br>><br>> Chris Hermansen · mailto:<a href="mailto:clh@timberline.ca">clh@timberline.ca</a><br>> tel:+1.604.714.2878 · fax:+1.604.733.0631<br>> Timberline Natural Resource Group ·
<a href="http://www.timberline.ca">http://www.timberline.ca</a><br>> 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5<br>><br>> C'est ma faįon de parler.<br>><br>> _______________________________________________
<br>> postgis-users mailing list<br>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">
http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>><br>><br>><br>><br>> _______________________________________________<br>> postgis-users mailing list<br>> <a href="mailto:postgis-users@postgis.refractions.net">
postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>><br>><br>_______________________________________________
<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users
</a><br></blockquote></div><br>