Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-dev] Oracle GeoRaster contribution
No problem, just trying to keep discussion on the mailing list as much as possible :)

To wit it is not my review, but the communities that we are seeking.



Jody Garnett


On Mon, Mar 10, 2014 at 1:55 PM, Ivan Lucena <lucena_ivan@xxxxxxxxxxx> wrote:
Hi Jody,

I didn't intent to send code for review. I send my branch so that you can test it. But if that makes things go faster and you want to go ahead and merge the changes. Let's do it.

But I don't know if you need to go into "details" (or "params") at that point. This code is just an attempt to use the current status of GeoTools ImageMosaic-JDBC extension to handle the GeoRaster object. That might be good enough for the upcoming workshop but we may choose another path to provide better performance an flexibility.

If you have a chance to test it, there are some limitations you need to comply to:

1 - The table containing the sdo_georaster column must have a primary key column.

2 - The GeoRaster objects must have pyramids.

3 - DEM or anything other than unsigned integer 8 but doesn't' render well (image shows black and with and there is not place for user to define a color ramp).

4 - It seems like the ImageMosaic-JDBC support for GeoRaster doesn't handle images with more than 3 bands.

If you have the latest GDAL release with the georaster driver, you can load the image into the database, create table, define primary key, select bands and generate pyramids with just one command. Example:

$ gdal_translate -of georaster input-file.tif \
georaster:user/pwd@db,urban,image \
-co "description=(id number, name varchar2(128), image sdo_georaster, primary key (id))" \
-co "insert=(1,'Tokyo',sdo_geor.init())" \
-co genpyramid=NN \
-b 1 -b 2 -b 3

Regards,

Ivan

Date: Mon, 10 Mar 2014 10:08:38 +1100
From: jody.garnett@xxxxxxxxx
To: udig-dev@xxxxxxxxxxxxxxxx
Subject: [udig-dev] Oracle GeoRaster contribution


I have been chatting a bit with Ivan off list, and his work is available here:


I did not see anything too scary in my review:

a) OracleServiceExtension.java.html <-- article that appears to be committed by accident
b) Same with  plugins/sqlnet.log
c) OracleRasterResource(parent, details, params) <-- is it actually easier to pass in "details" rather than params? Or are these details directly usable by the format.getReader ??

Ivan is working with oracle (which has signed a contributor agreement) so I believe we can accept this initial patch.

As for Ivan's question (stuck at the end of the last thread) - does format.getReader( source ) always need a file?

1) Sometimes source can take an input stream,  in which case you could create an in memory input stream?
2) We could even ask if passing in the data structure object would be appropriate? 
3) Failing that I recommend creating a temporary file as needed

Perhaps ask on geotools-user list ... 

Jody Garnett

_______________________________________________ udig-dev mailing list udig-dev@xxxxxxxxxxxxxxxx https://locationtech.org/mailman/listinfo/udig-dev

_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
https://locationtech.org/mailman/listinfo/udig-dev


Back to the top