Hi,
today I was trying to add a raster backdrop to my
(vector) versioned data set and got stuck with
the coverage store telling me that the url provided
wasn't good.
Now, the url was in fact good, but the geotiff
format wasn't accepting it because the geotiff lacked
the CRS information. It would be nice if the provider
had a way to tell _why_ it's refusing to load data.
Simone, Alessio, any suggestion on how to get this
info? Maybe if the file exists, we should try to
open it anyways and report to the user the
exception message we get?
Cheers
Andrea
I'm just about done with a fix that will help a bit with this.
I get the file and check exists() - and report file does not exist, and canRead() and report that the file can't be read, before passing on to the coverage store to try out.
I also did this for url's in datastores as well, which hopefully should help.
Right now it then goes to AbstractGridFormat.accepts(). Which I had thought just rejected if the suffixes of files weren't there. Didn't know it's reject things if it lacked CRS info.
That accepts call unfortunately doesn't seem to return anything though...
C
Andrea Aime wrote:
Hi,
today I was trying to add a raster backdrop to my
(vector) versioned data set and got stuck with
the coverage store telling me that the url provided
wasn't good.
Now, the url was in fact good, but the geotiff
format wasn't accepting it because the geotiff lacked
the CRS information. It would be nice if the provider
had a way to tell _why_ it's refusing to load data.
Simone, Alessio, any suggestion on how to get this
info? Maybe if the file exists, we should try to
open it anyways and report to the user the
exception message we get?
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
!DSPAM:1003,45f05259119612051017194!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Hi Guys,
if it’s ok for all, I would like to spend some time on this, trying to do some more checks and come out with more understandable error messages.
On 3/8/07, Chris Holmes <cholmes@anonymised.com> wrote:
I’m just about done with a fix that will help a bit with this.
I get the file and check exists() - and report file does not exist, and
canRead() and report that the file can’t be read, before passing on to
the coverage store to try out.
I also did this for url’s in datastores as well, which hopefully should
help.
Right now it then goes to AbstractGridFormat.accepts(). Which I had
thought just rejected if the suffixes of files weren’t there. Didn’t
know it’s reject things if it lacked CRS info.
That accepts call unfortunately doesn’t seem to return anything though…
C
Andrea Aime wrote:
Hi,
today I was trying to add a raster backdrop to my
(vector) versioned data set and got stuck with
the coverage store telling me that the url provided
wasn’t good.
Now, the url was in fact good, but the geotiff
format wasn’t accepting it because the geotiff lacked
the CRS information. It would be nice if the provider
had a way to tell why it’s refusing to load data.
Simone, Alessio, any suggestion on how to get this
info? Maybe if the file exists, we should try to
open it anyways and report to the user the
exception message we get?
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
!DSPAM:1003,45f05259119612051017194!
–
Chris Holmes
The Open Planning Project
http://topp.openplans.org
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
–
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions
http://www.geo-solutions.it
Wait for me to commit my fix, and then you can see what it does. Since I don't really code any more it's hard for me to find the time to completely clean it up and test it and get it in, but it's just about there.
Chris
Alessio Fabiani wrote:
Hi Guys,
if it's ok for all, I would like to spend some time on this, trying to do some more checks and come out with more understandable error messages.
On 3/8/07, *Chris Holmes* <cholmes@anonymised.com <mailto:cholmes@anonymised.com>> wrote:
I'm just about done with a fix that will help a bit with this.
I get the file and check exists() - and report file does not exist, and
canRead() and report that the file can't be read, before passing on to
the coverage store to try out.
I also did this for url's in datastores as well, which hopefully should
help.
Right now it then goes to AbstractGridFormat.accepts(). Which I had
thought just rejected if the suffixes of files weren't there. Didn't
know it's reject things if it lacked CRS info.
That accepts call unfortunately doesn't seem to return anything
though...
C
Andrea Aime wrote:
> Hi,
> today I was trying to add a raster backdrop to my
> (vector) versioned data set and got stuck with
> the coverage store telling me that the url provided
> wasn't good.
>
> Now, the url was in fact good, but the geotiff
> format wasn't accepting it because the geotiff lacked
> the CRS information. It would be nice if the provider
> had a way to tell _why_ it's refusing to load data.
>
> Simone, Alessio, any suggestion on how to get this
> info? Maybe if the file exists, we should try to
> open it anyways and report to the user the
> exception message we get?
>
> 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
<http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
<http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions
http://www.geo-solutions.it
--------------------------------------------------------- !DSPAM:1003,45f14959264781460912952!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org