On 10/5/06, Luca Morandini <lmorandini@anonymised.com> wrote:
Alessio Fabiani wrote:
> Hi all guys,
> the release is ready and alredy committed and uploaded to sourceforge.
>
> A lot of bugfixes are done during releasing: javadoc,
> GEOSERVER_DATA_DIR, Jetty, etc...
>
> The release works against Java 1.4.2+, GeoTools 2.3.0-M0 release, JAI
> 1.1.4 and ImageIO 1.1.
Well, I tried the binary WAR build on:
- JDK 1.4.2 + JAI 1.1.2
- JDK 1.4.2 + JAI 1.1.4 27/09 build + ImageIO 1.1 27/09 build
- JDK 1.5.0 + JAI 1.1.2
- JDK 1.5.0 + JAI 1.1.4 27/09 build + ImageIO 1.1 27/09 build
All of them on a Linux Fedora Core 3 box with Jetty 4.2.8.
What it did, consistently, was to have no data source working.
This is the log message for vector data when loading the webapp:
<<[SEVERE] org.vfny.geoserver.global.Data - FeatureTypeInfo
DS_tiger_roads:::tiger_roads ignored - as DataStore DS_tiger_roads is
unavailable:java.io.IOException: File either doesn't exist or is
unreadable :
/usr/local/apps/jettydev/webapps/geoserver/data/nyc/tiger_roads.shp>>
It seems vector data should directly be under "data" and not (as it
happens in this WAR) under "data/data" (when I moved those data, sample
featuretypes resumed working).
Alessio will look at this tomorrow.
This is the log message when displaying the sample_geotiff via WMS:
<<[INFO] org.vfny.geoserver.servlets.AbstractService - handling request:
org.vfny.geoserver.wms.requests.GetMapRequest@anonymised.com
Oct 5, 2006 10:38:46 PM org.vfny.geoserver.global.CoverageStoreInfo
getReader
SEVERE: No input stream for the provided source
java.lang.IllegalArgumentException: No input stream for the provided source
at
org.geotools.gce.geotiff.GeoTiffReader.<init>(GeoTiffReader.java:182)
at
org.geotools.gce.geotiff.GeoTiffFormat.getReader(GeoTiffFormat.java:194)
>>
This is quite strange, I'll have to look at it myself.
However, I was able to add an imagemosaic composed of two GeoTIFFs, but
the result using both WMS and uDIG was a white image (log message:
<<[WARNING] org.geotools.renderer.lite.StreamingRenderer - The number of
image bands (3) differs from the number of supplied 'SampleDimension'
objects (1).)>>
This is related to one of your previous emails that I have not had
time yet to answer (volunteer work is like that :-)).
I think I already pointed out in a previous email to another user that
as of now the gridcoverage package has limited support for paletted
images as the images you sent me were if I recall. It would not be
difficult to add support for them, but it is really low priority on my
roadmap (unless someone pays for it).
About the ImageMosaic. As the name says, it handles mosaic of
georeferenced images, which means tifff+tfw+prj, png+tfw+prj,
jpeg+tfw+prj as well as geotiffs. This does not mean that you throw
there a couple of images and it will do the trick no matter how these
images are. Requirements are:
-(almost) equal spatial resolution
-same number of bands
-same data type
-same projection
The first requirement can be relaxed a little but if they have the
same spatial resolution the performances are much better.
There are parameters that you can use to control the behaviour of the
mosaic in terms of thresholding and transparency. They are as follows:
---DefaultParameterDescriptor FINAL_ALPHA = new DefaultParameterDescriptor(
"FinalAlpha", Boolean.class, null, Boolean.FALSE)---
It asks the plugin to add transparency on the final created mosaic. IT
simply performs a threshonding looking for areas where there is no
data, i.e., intensity is really low and transform them into
transparent areas. It is obvious that depending on the nature of the
input images it might interfere with the original values.
---ALPHA_THRESHOLD = new DefaultParameterDescriptor(
"AlphaThreshold", Double.class, null, new Double(1));---
Controls the transparency addition by specifying the treshold to use.
INPUT_IMAGE_ROI = new DefaultParameterDescriptor(
"InputImageROI", Boolean.class, null, Boolean.FALSE);
public static final DefaultParameterDescriptor
INPUT_IMAGE_ROI_THRESHOLD = new DefaultParameterDescriptor(
"InputImageROIThreshold", Integer.class, null, new Integer(1));
These two can be used to control the application of ROIs on the input
images based on tresholding vlues. Basically using the threshold you
can ask the mosaic plugin to load or not certain pixels of the
original images.
-->Final annotation on the ImageMosaic plugin<--
To best use the ImageMosaic plugin the images have to be closer,
otherwise depending on how you set the above parameters you might get
large ares completely black because of the filling added. To avoid
thiss you migh ask the plugin to add alpha trasparency to the output
but this firstly slow down performances and also may interfere with
images that are black and white (like yours 
). The best option is
to add transparency as you need to the source images. The plugin will
recognize that and perfome a nice fading between overlapping images as
well as filling the holes with transparent pixels.
One last thing: when it starts, there is this error in the log:
<< [CONFIG] org.geotools.referencing.factory.epsg.HSQLDataSource -
Creating c
ched EPSG database.
java.util.logging.ErrorManager: 5
java.lang.NullPointerException
at java.io.Writer.write(Writer.java:126)
at
org.vfny.geoserver.global.Log4JFormatter.format(Log4JFormatter.java:
46)
at java.util.logging.StreamHandler.publish(StreamHandler.java:178)
at
org.vfny.geoserver.global.Log4JFormatter$Stdout.publish(Log4JFormatt
r.java:344)
at java.util.logging.Logger.log(Logger.java:424)
at
org.geotools.referencing.factory.epsg.DefaultFactory.log(DefaultFact
ry.java:336)
at
org.geotools.referencing.factory.epsg.DefaultFactory.createBackingSt
re(DefaultFactory.java:364)
at
org.geotools.referencing.factory.DeferredAuthorityFactory.getBacking
tore(DeferredAuthorityFactory.java:136)
at
org.geotools.referencing.factory.BufferedAuthorityFactory.isAvailabl
(BufferedAuthorityFactory.java:206)
at
org.geotools.referencing.factory.DeferredAuthorityFactory.isAvailabl
(DeferredAuthorityFactory.java:124)
at
org.geotools.factory.FactoryRegistry$DefaultFilter.filter(FactoryReg
stry.java:76)
at
org.geotools.factory.FactoryRegistry$1.filter(FactoryRegistry.java:1
3)
at
javax.imageio.spi.FilterIterator.advance(ServiceRegistry.java:789)
at
javax.imageio.spi.FilterIterator.<init>(ServiceRegistry.java:783)
at
javax.imageio.spi.ServiceRegistry.getServiceProviders(ServiceRegistr
.java:490)
at
org.geotools.factory.FactoryRegistry.getServiceProviders(FactoryRegi
try.java:177)
>>
This is not a problem at all. There is some code in the EPSG-HSQL
datastore that I have never had a chance to remove. It is harmless but
scary I know.
Final thoughts.
This build has been release for testing purposes, so plese report any
strange behaviour.
However next week we should release a new version with many fixes and
a brand new RW plugin for ascii grids (and hopefully, but please do
not circulate this :-), a R-only plugin for ECW and JPEG2K windows
only for the moment). Moreover the problem with output images size has
already been solved on our local repository.
Please, be patient because this work is quite complex, anyway, bug
reports and suggestions are welcome and appreciated (as well as
fundings!!!!).
Regards,
Simone.
I'm quite puzzled by now: it is only me experiencing this with the WAR
build ?
Regards,
--------------------
Luca Morandini
www.lucamorandini.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
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions
http://www.geo-solutions.it
-------------------------------------------------------