Quoting Steve Way <[email protected]>: > Hi Christian, > > Thanks for your advice. > > We are actually getting the max pyramid level from Oracle, so if no > pyramids exist, then the base table will be used for all requests, > therefore, having a plugin for only feature 3 is not required as > this is handled in the implementation. No, some misunderstanding. I talked about having each pyramid in its own sql table. But this is more complicated, we should defer this.
> > Can you give me more information about pyramids not working with > gridlines? I have not come across this issue - my raster data has > gridlines and it works? Maybe my gridlines do not run along the > edges of the tile but through the middle. Building pyramids means interpolating a set of neighbour pixels to get one pixel. If you create tiles and build pyramids on a tile basis, some neighbour pixels are missing at the tile borders. Starting with on large image and creating tiles/pyramids, the order is important. a) Building the pyramids on the large image and create the tiles b) Create the tiles and build pyramids for each tile separately. If you mosaic your large image on a pyramid level, the resulting image from a) is not identical to the resulting image from b). a) is correct, b not, but if you are lucky, you do not see a difference. I always prefer a. As I did the gdal_retile utility, I had these effects. gdal_retile solves this problem by loading all neighbour tiles, mosaicing a small image, interpolating the small image and cropping the result tile. Conclusion: b) will not work for all maps > > Thanks for your advice regarding tests - I think I will follow a > similar approach and document db setup etc in the wiki. Then you need 2 classes, plugin and test, your xml config will contain the class name of your plugin. That is the way to go. > > I am still waiting for developer permission to the wiki - do you > know who I can contact for this? Andrea, Justin and Jody, select one of your choice :-) So far, so good > > Thanks, > Steve > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 31 January 2011 09:35 > To: Steve Way > Cc: geotools-devel ([email protected]); > [email protected] > Subject: RE: [Geotools-devel] Proposed Oracle Georaster Mosaic Module > > Ahh I remember, you build the pyramids for each tile separately. I > hope you are aware of the fact that this does not work for each map. > I had maps with grid lines. You should mention this fact in the wiki. > > Oracle Georaster offers 3 features > 1) mosaicing > 2) pyramids > 3) georeferencing and spatial operations on the georaster object > > The current georaster plugin uses 1) + 2) + 3) > > Your plugin will use 2) + 3) > > I would propose to add a third plugin which only uses 3) having the > pyramids stored in their own georaster objects. You can use a meta > table for storing the pyramid infos > > http://docs.codehaus.org/display/GEOTDOC/Create+the+meta+table > > In this case, TileTable=SpatialTable > > This is also the way for PostGIS Wkt Raster. > > Look here for an example > http://docs.codehaus.org/display/GEOTDOC/Image+Mosaicing+Pyramidal+JDBC+Plugin#ImageMosaicingPyramidalJDBCPlugin-SetupExample > > As a consequence, we could offer OracleGeoraster support in 3 > variations, but this is only a proposal and depending on your time. > ------------ > About the community module. If you want to implement the reader > plugin and a test case only, a community module is ok. > > If you want include support for importing tiles and generation of > DDL statements, a patch would be better. > > Look at this classes > org.geotools.gce.imagemosaic.jdbc.Import > org.geotools.gce.imagemosaic.jdbc.DDLGenerator > > There is a base class for the tests > > org.geotools.gce.imagemosaic.jdbc.AbstractTest > > The test cases use the DDLGenerator to create the db setup, the > Import class to import the test tiles into the database and, of > course, the different plugins to produce images. > > If you prefer, you can do it like I did it with the Georaster plugin > and delegate DDL creation and import to Oracle Tools. In this case > you only have to document the db setup in the wiki and write a test > case like > > org.geotools.gce.imagemosaic.jdbc.GeoRasterOnlineTest > > Please let me know how you want to continue. Depending on the way > you choose, I can give additional hints. > > > Cheers > Christian > > > Quoting Steve Way <[email protected]>: > >> Hi Christian, >> >> Thanks for your mail. >> >> Yes you are right about the mosaic on the fly. With respect to >> pyramid building, this is actually completed in Oracle on a tile by >> tile basis. The plugin will find the max pyramid level of the >> coverage on initialization, and based on the spatial resolution, >> will select the relevant pyramid level. >> >> It is funny you mentioned about extending the abstract JDBCCustom >> class, I started this work on Friday and am now complete. >> >> Still waiting for developer access to codeHause to write a wiki page >> on this, and then hopefully carry on the next steps to releasing >> this as an unsupported plugin (or community module). >> >> I think it is a good idea to use the current test case as much as >> possible -this is where I am going to struggle creating Junit tests >> - so any help, guidance and advice would be welcome. >> >> Many Thanks, >> Steve >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: 30 January 2011 14:08 >> To: Steve Way >> Cc: geotools-devel ([email protected]); >> [email protected] >> Subject: Re: [Geotools-devel] Proposed Oracle Georaster Mosaic Module >> >> Hi, I can remember working with Baskar. I hope your extension is a >> subclass of the JDBCAccessCustom base class, otherwise we would have >> an additional architecture (We have already two, one based on files >> maintained by Simone, the second based on jdbc, maintained by me). >> The current Oracle Georaster plugin is an implementation of >> >> http://docs.codehaus.org/display/GEOTDOC/Customized+JDBC+Access+for+im >> ages >> >> If I got it right, you calculate the mosaic on the fly, what about >> pyramid building ?. >> >> About the test case. There is already an OracleGeoraster test, I >> think it would be a good idea to use this test as a template. If I >> am right, you only have to modify the import of the images. >> >> Anyway, your approach is very interesting for me because I intend to >> add postgis wkt raster which has a database layout similar to yours. >> >> And last not least, do you plan to extend the import utility. The >> current Oracle Georaster implementation can use the original Oracle >> tools for import, postgis wkt raster has its own tool and for the >> rest I wrote the import utility based on the output of gdal_retile. >> >> >> Cheers >> Christian >> >> >> >> >> >> Quoting Steve Way <[email protected]>: >> >>> Hi Jody, >>> >>> Last year I extended Christian's imagemosaic-jdbc module to support >>> Oracle Georaster. This however, was quite a dirty implementations >>> and had a dependency on about 11 external Oracle java libraries >>> (which, is not workable in the opensource world!). >>> >>> The imagemosiac-jdbc module was then officially extended by the >>> community, however, it is limited to only working with the Oracle >>> Georaster format if a mosaic has been created in the DB. >>> >>> What I have created in collaboration with another developer (Baskar >>> Dhanapal), and would like to release to the community, is a plugin, >>> which is dependant only on one external Oracle Library (the Oracle >>> JDBC Driver ojdbc14.jar), and works with the most common GeoRaster >>> data model, where there are many raster tiles for a given dataset and >>> does not rely on the DBA to create a mosaic within Oracle. An >>> example of this would be the Ordnance Survey 1:10,000 scale raster >>> products, where there are 10,585 tiles. To create a mosaic for this >>> is timely, high maintenance (as mosaic would need to be re-created >>> even if a few tiles were updated) and costly in storage. The >>> proposed module would mosaic on the fly, and take out those issues >>> mentioned above. >>> >>> I hope yourself and the community see the benefit to having this >>> module, and accept this as a formal request to submit. We will >>> definitely be using this in the WMS service we provide to Ordnance >>> Survey(GB) in the current Geoserver upgrade to 2.1.0 for INSPIRE >>> compliance in the coming months. >>> >>> Kind Regards, >>> >>> Steve Way >>> >>> >>> >>> >>> >>> >>> >>> >>> ________________________________ >>> DISCLAIMER: >>> >>> This email may contain confidential information and is intended only >>> for the use of the specific individual(s) to which it is addressed. >>> If you are not the intended recipient of this email, you are hereby >>> notified that any unauthorized use, dissemination or copying of this >>> email or the information contained in it or attached to it is >>> strictly prohibited. If you received this message in error, please >>> immediately notify the sender at Infotech or >>> [email protected] and delete the original message. >>> >> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
