Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Sounds good on the whole Andrea. A few comments inline. >> >> <snip> >>> >>> Opinions? (I know I had a similar conversation with Justin >>> some time ago and he was lending towards having one class >>> per possible output, thought in that case it was about >>> an OGR datastore using the java bindings). >> >> Yeah having to write separate classes or deploy separate jars I agree >> is a lot of work, which is probably unnecessary. > > I'm not really scared about that work, but the fact that the user > might have an ogr2ogr build that supports format XYZ that we did > not code up support for. If it's configurable, then he can add > his own format without leaning java, setting up maven and so on. > >> My motivation here is to be able to somehow configure which formats >> from ogr show up in GeoServer, and not get bombarded with the many >> formats ogr provides. Others may disagree... this really just stems >> from my minimalist need to only have things around that I ask for :). >> Regardless, not a big issue. > > Ah, but we would list only the formats that the user has provided > a property file for. Maybe we can ship with a few sample formats > supported by default and hard coded into the plugin > (MapInfo and a few others), and allow the user to provide > extras by adding those property files. > Whatever is used provided has not been tested by the devs, > so no big issue there. Hmmm... good point. Mission accomplished then!! :). > > >>> Of course I could circumvent the issue and have >>> ogr2ogr invoked on each of the shapefiles in output, >>> and then zip up the whole result (I'm actually kind >>> of lending towards this solution). >> How about perhaps making the "feed source" configurable? For instance >> perhaps use shapefile as the default but provide a facility to allow >> users to use postgis or some other source they want to configure. > > You mean, direct connection to the original data source from > ogr2ogr, like connecting directly to the postgis database that > we know holds the data? I see a few issues: > - how do we handle all of the WFS options like filtering and so on? > - what happens if ogr2ogr does not have the proper driver? > > The mechanisms I envisioned would use GeoServer to do all the > filtering, attribute shaving, reprojecting and so on (eventually, > computation too, as this can be used as a WPS output format too), > then dump into shapefile, and have ogr2ogr turn that shapefile > into the format that we want to return. > > Maybe I misunderstood your suggestion. Please elaborate? :) Yeah, not quite, sorry, did not explain my self well :).
So what we are talking about this this correct: 1. request comes in and his handled by geoserver 2. geoserver dumps response to local shapefile 3. geoserver pumps the shapefile through ogr to another format and returns the new format to the client My suggestion is in step 2 instead of dumping to a shapefile, dumping to some other intermediary data source. The rationale being that you stated issues with shapefile, and gml... so perhaps being able to configure a postgis db for the temporary storage might work better? Just a thought. > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
