Hey all,
Here's a quick preview of SDE rasters:
http://maps.massgis.state.ma.us:8090/geoserver/preview/massgis_GISDATA.IMG_COQ2005.html
It's a 13-level pyramided SDE raster mosaic of the 2005 Massachusetts Orthophotos.
Currently my implementation is pretty much at the "toy" level. It's clearly not rendering colors correctly, it's not using JAI at all, and most of the important functionality is completely stubbed out. Lots more work to be done before I'd say it's even alpha quality!
In addition to this, the Y axis of the mapbuilder viewer seems to be inverted, but not the X axis (try panning left-right vs. up-down). So there's probably something really wrong with the way that I'm presenting the returned images...as in asking for the top of the state gets you the bottom.
Also, it looks like if you zoom in too far, you start getting nothing back. Not sure what's up with that. Like I said, really just a toy right now!
--saul
Saul Farber ha scritto:
Hey all,
Here's a quick preview of SDE rasters:
http://maps.massgis.state.ma.us:8090/geoserver/preview/massgis_GISDATA.IMG_COQ2005.html
It's a 13-level pyramided SDE raster mosaic of the 2005 Massachusetts Orthophotos.
How big is that?
Currently my implementation is pretty much at the "toy" level. It's clearly not rendering colors correctly, it's not using JAI at all, and most of the important functionality is completely stubbed out. Lots more work to be done before I'd say it's even alpha quality!
I'm curious, what's the most important functionality that you left out?
(I mean, besides getting color right and so on)
In addition to this, the Y axis of the mapbuilder viewer seems to be inverted, but not the X axis (try panning left-right vs. up-down). So there's probably something really wrong with the way that I'm presenting the returned images...as in asking for the top of the state gets you the bottom.
Also, it looks like if you zoom in too far, you start getting nothing back. Not sure what's up with that. Like I said, really just a toy right now!
Well, nice toy anyways 
Keep up the good work
Cheers
Andrea
How big is that?
The raw, four-band orthos are about 450Gb. That's 32 bits per pixel (8-red, 8-blue, 8-green, 8-near-infrared).
I'm curious, what's the most important functionality that you left out?
(I mean, besides getting color right and so on)
I think there are two biggies that are missing right now:
* Integration with JAI, meaning that JAI has this pretty powerful "generate a RenderedImage from a datasource" plugin system that enables streaming images from one JVM to another, tiled image caching, graphics-hardware acceleration, and some other cool stuff. To get these benefits, you just have to write the "load up this little bit of image from your data" part, and JAI will take care of the rest for you. The rest of the GT2-Coverage plugins do this, but right now I'm just manually constructing a BufferedImage for each request.
* Correct image resampling. Suppose that you get a request for an image with an extent that doesn't cleanly map onto your grid of raster pixels. You have to create an image that includes all the pixels that are *touched* by the requested extent, and then let the GridCoverageRenderer resample the image you created into the image that was requested (using some kind of pixel interpolation). I'm not sure this is working correctly right now, which means that my rasters won't line up correctly with any vector datasets that might be on top.
Other than those two, there are probably a hundred little things...from fixing color and the Y-Axis inversion to handling cases where you zoom in past the least-compressed level of the pyramid.
Plus there's refactoring the ArcSDE datastore plugin to be able to share connection-pooling code, and figuring out a way to have ArcSDE datastores share connection pools with ArcSDE coverages. Not sure how to work that right now.
--saul
Saul Farber ha scritto:
How big is that?
The raw, four-band orthos are about 450Gb. That's 32 bits per pixel (8-red, 8-blue, 8-green, 8-near-infrared).
Quite big, interesting.
I'm curious, what's the most important functionality that you left out?
(I mean, besides getting color right and so on)
I think there are two biggies that are missing right now:
* Integration with JAI, meaning that JAI has this pretty powerful "generate a RenderedImage from a datasource" plugin system that enables streaming images from one JVM to another, tiled image caching, graphics-hardware acceleration, and some other cool stuff.
Hmm... I'm not sure JAI gives you any better graphics-hardware acceleration than buffered images provided you're using at least java 5
(and Geoserver works just fine with java5, we should publicize this
a bit more, since it's faster there. We should try java6 too, afaik
now gt2 has trouble building with java 6).
* Correct image resampling. Suppose that you get a request for an image with an extent that doesn't cleanly map onto your grid of raster pixels. You have to create an image that includes all the pixels that are *touched* by the requested extent, and then let the GridCoverageRenderer resample the image you created into the image that was requested (using some kind of pixel interpolation). I'm not sure this is working correctly right now, which means that my rasters won't line up correctly with any vector datasets that might be on top.
This one is a good question for Simone. Don't hold your breath thought,
he'll be away for a few days.
Plus there's refactoring the ArcSDE datastore plugin to be able to share connection-pooling code, and figuring out a way to have ArcSDE datastores share connection pools with ArcSDE coverages. Not sure how to work that right now.
Hmm... sharing the connection pool seems something to be done at the
factory level, but it also means putting the pool in a shared static cache. Probably a weak/soft reference map would do.
Cheers
Andrea
Hi Saul,
even if its a rough prototype it looks very promising!
Thanks for taking the time of making it visible
As Andrea said, connection sharing looks like a factory level detail. Guess we
should do some planning on the sde plugin as for the improvements we talked
about before and making room for this new stuff.
cheers,
Gabriel
On Friday 29 December 2006 16:13, Andrea Aime wrote:
Saul Farber ha scritto:
>> How big is that?
>
> The raw, four-band orthos are about 450Gb. That's 32 bits per pixel
> (8-red, 8-blue, 8-green, 8-near-infrared).
Quite big, interesting.
>> I'm curious, what's the most important functionality that you left out?
>> (I mean, besides getting color right and so on)
>
> I think there are two biggies that are missing right now:
>
> * Integration with JAI, meaning that JAI has this pretty powerful
> "generate a RenderedImage from a datasource" plugin system that enables
> streaming images from one JVM to another, tiled image caching,
> graphics-hardware acceleration, and some other cool stuff.
Hmm... I'm not sure JAI gives you any better graphics-hardware
acceleration than buffered images provided you're using at least java 5
(and Geoserver works just fine with java5, we should publicize this
a bit more, since it's faster there. We should try java6 too, afaik
now gt2 has trouble building with java 6).
> * Correct image resampling. Suppose that you get a request for an image
> with an extent that doesn't cleanly map onto your grid of raster pixels.
> You have to create an image that includes all the pixels that are
> *touched* by the requested extent, and then let the GridCoverageRenderer
> resample the image you created into the image that was requested (using
> some kind of pixel interpolation). I'm not sure this is working
> correctly right now, which means that my rasters won't line up correctly
> with any vector datasets that might be on top.
This one is a good question for Simone. Don't hold your breath thought,
he'll be away for a few days.
> Plus there's refactoring the ArcSDE datastore plugin to be able to share
> connection-pooling code, and figuring out a way to have ArcSDE
> datastores share connection pools with ArcSDE coverages. Not sure how
> to work that right now.
Hmm... sharing the connection pool seems something to be done at the
factory level, but it also means putting the pool in a shared static
cache. Probably a weak/soft reference map would do.
Cheers
Andrea
-------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90