Ciao guys, I think this approach of storing metadata inside a db and is one of the best ones. I hope to hear a bit more from Martin, to be honest it would be really cool to have a look at the code he wrote because that could be a great starting point (shame it has not been shared!).
At FOSS I have heard from andrea about this talk from Sandro Santilli but I unfortunately missed it. Is there a way to find some slides or docs about it? Anyway, I hope to hear something from Martin soon since I already started to design a abse for the next generation of interfaces and one of the problems to face is to come up with at least a standard set of metadata as well as a mean to store them. I hope on this new feature we can have an approach a bit more cooperative than in the past. Simone. On 9/23/06, Vincent Heurteaux <[EMAIL PROTECTED]> wrote: > Ciao Andrea, > > I'm looking at all the code that Martin has done around postgresql > raster storage, it doesn't only focus on the database part, he's done > a lot of Java stuff on top of it. > I don't know if Martin have subscribed to the list, then I forward > him thi mail, he will be more able to talk about it. > > Cheers > Vincent > Le 23 sept. 06 à 13:14, Andrea Aime a écrit : > > > Vincent Heurteaux ha scritto: > >> Ciao Simone, > >> In our case, postgresql doesn't store images in blobs. As Sandro > >> explained last week during "Future directions of PostGIS <http:// > >> www.foss4g2006.org/contributionDisplay.py? > >> contribId=109&sessionId=42&confId=1>" présentation, there is a lot > >> of overhead with that. The method we're using consist in storing > >> GridCoverage metadata in the database and images in the filesystem > >> (this is an other way that Sandro wanted to investigate). > > > > I agree this is basically the way to go if you want good > > performance, and > > it's also relatively easy to implement if your application is the > > only one using > > that data (so you keep the raster on the same filesystem as you > > app, and use > > postgis as an indexed metadata store). > > > > At same time it would be nice to have the database handle the > > details and provide > > access to the images thru the standard jdbc channels, so that you > > can share the > > same data with other applications. That is, have the database > > server store stuff on > > its filesystem, instead of using normal table storage, and allow > > people to access > > those the same way as blobs, or whatever other mean that does not > > require too much > > overhead (I don't know, for example as something out of the jdbc > > standarard > > that only postgresql supports, in order to have minimal overhead). > > > > Cheers > > Andrea Aime > > > > PS: this post won't probably be seen on the ml because my smtp is > > blacklisted, > > can anyone of you resend this to the ml acting as a rounter? > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geoserver-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
