I am working on a test GridCovreageReader; problem is I am using a URI (to look up something in a catalog); while I can write my GeoTools code to work with URI -(format.accepts( uri ) == true) the GeoServer user interface is only set up to work with URLs right now ....
Questions:
- Can I confirm that the use of URL is an assumption GeoServer has made (and not a part of the GeoTools interfaces I have missed)
The separation between data source (ie the above URL) and configuration (the additional parameters used when reading) is now making sense to me.
Oh no - it is worse then that. The GeoServer system only gives me a *File* ... right now I am getting the following out of my reader.
270609 [WARNING] ImageFormat - Could not use C:\java\geoserver\1.5.x\web\src\main\webapp\data\coverages
\img_sample\usa.png (class java.io.File)
While I can hack around this problem; we need to revisit this configuration ui policy.
Cheers,
Jody
Hi guys;
I am working on a test GridCovreageReader; problem is I am using a URI (to look up something in a catalog); while I can write my GeoTools code to work with URI -(format.accepts( uri ) == true) the GeoServer user interface is only set up to work with URLs right now ....
Questions:
- Can I confirm that the use of URL is an assumption GeoServer has made (and not a part of the GeoTools interfaces I have missed)
The separation between data source (ie the above URL) and configuration (the additional parameters used when reading) is now making sense to me.
And then hacking it to work when that file-name is internalized inside a java.io.File (file.getAbsoluteName() or whatever).
The Geotools side handles arbitrary source-types (a Map or a specific configuration object), it's just a geoserver limitation. Thank goodness for that!
--saul
Jody Garnett wrote:
Oh no - it is worse then that. The GeoServer system only gives me a *File* ... right now I am getting the following out of my reader.
270609 [WARNING] ImageFormat - Could not use C:\java\geoserver\1.5.x\web\src\main\webapp\data\coverages
\img_sample\usa.png (class java.io.File)
While I can hack around this problem; we need to revisit this configuration ui policy.
And then hacking it to work when that file-name is internalized inside a
java.io.File (file.getAbsoluteName() or whatever).
The Geotools side handles arbitrary source-types (a Map or a specific
configuration object), it’s just a geoserver limitation. Thank goodness
for that!
–saul
Jody Garnett wrote:
Oh no - it is worse then that. The GeoServer system only gives me a File … right now I am getting the following out of my reader.
270609 [WARNING] ImageFormat - Could not use
C:\java\geoserver\1.5.x\web\src\main\webapp\data\coverages
\img_sample\usa.png (class java.io.File)
While I can hack around this problem; we need to revisit this
configuration ui policy.
Right, and for coverages backed by file-based data (the location of which can be translated from a URL) this makes a lot of sense.
My particular problem (and I think jody's too) is that sometimes we want to back coverages by things that aren't files, and don't live "on-disk" (or at least the location of these things are hard to represent with URLs).
My example was what about rasters stored in a DB. Geotools allows an arbitrary object to be passed in to the creation of a GridCoverageReader, so handling a GCReader targeting rasters stored in a Db is as simple as passing in a java.util.Map, or maybe a MyCustomLocatorObject to that object. However, Geoserver stores the object which is passed into the "create-a-GCReader" method as a URL (and the actual call to createReader is made with a java.io.File). So folks who want to target non-URL-based coverage storage formats (like DBs or maybe coverages which can be pulled via a URI, but not a URL) have to make our createReader methods accept a File, and then shoehorn whatever creation-time-options we have into that File's getAbsoluteName() method.
It's entirely possible that Jody and I have totally different problems and that I'm distorting his complaint due to my own view of the problems! Chime in if that's the case jody.
--saul
Alessio Fabiani wrote:
GeoServer, infact, should use only paths relative to the (local) GeoServer Data Dir to access the resources, at least the current version.
Thanks Saul you summed up the situation perfectly; I think I could get by with a URL (although a URI would be better). Saul it will be hard for us to make the case for this until we have some examples in the GeoTools codebase.
Cheers,
Jody
Right, and for coverages backed by file-based data (the location of which can be translated from a URL) this makes a lot of sense.
My particular problem (and I think jody's too) is that sometimes we want to back coverages by things that aren't files, and don't live "on-disk" (or at least the location of these things are hard to represent with URLs).
My example was what about rasters stored in a DB. Geotools allows an arbitrary object to be passed in to the creation of a GridCoverageReader, so handling a GCReader targeting rasters stored in a Db is as simple as passing in a java.util.Map, or maybe a MyCustomLocatorObject to that object. However, Geoserver stores the object which is passed into the "create-a-GCReader" method as a URL (and the actual call to createReader is made with a java.io.File). So folks who want to target non-URL-based coverage storage formats (like DBs or maybe coverages which can be pulled via a URI, but not a URL) have to make our createReader methods accept a File, and then shoehorn whatever creation-time-options we have into that File's getAbsoluteName() method.
It's entirely possible that Jody and I have totally different problems and that I'm distorting his complaint due to my own view of the problems! Chime in if that's the case jody.
--saul
Alessio Fabiani wrote:
GeoServer, infact, should use only paths relative to the (local) GeoServer Data Dir to access the resources, at least the current version.
Also note (at least in JBoss rather then jetty:run) that the datastores are paying attention to relative URLs correctly; but the coverage implementations all end up as file not found (even for the sample data). Apprently this is a problem Jesse discovered last week but did not report; the recomended fix is to use an absolute path.
Oh no - it is worse then that. The GeoServer system only gives me a *File* ... right now I am getting the following out of my reader.
270609 [WARNING] ImageFormat - Could not use C:\java\geoserver\1.5.x\web\src\main\webapp\data\coverages
\img_sample\usa.png (class java.io.File)
While I can hack around this problem; we need to revisit this configuration ui policy.
Cheers,
Jody
Hi guys;
I am working on a test GridCovreageReader; problem is I am using a URI (to look up something in a catalog); while I can write my GeoTools code to work with URI -(format.accepts( uri ) == true) the GeoServer user interface is only set up to work with URLs right now ....
Questions:
- Can I confirm that the use of URL is an assumption GeoServer has made (and not a part of the GeoTools interfaces I have missed)
The separation between data source (ie the above URL) and configuration (the additional parameters used when reading) is now making sense to me.
GeoServer, infact, should use only paths relative to the (local) GeoServer Data Dir to access the resources, at least the current version.
Alessio, I already removed this particular limitation, you
can have coverages wherever you want now (still on disk, but
also outside of the data dir). Beta2 shipped without this limitation,
if you still find it, it's a bug.
Also note (at least in JBoss rather then jetty:run) that the datastores are paying attention to relative URLs correctly; but the coverage implementations all end up as file not found (even for the sample data). Apprently this is a problem Jesse discovered last week but did not report; the recomended fix is to use an absolute path.
Hum, relative path names do work, provided that you use the right path
name.
The release configuration, for some reason I don't understand,
references shapefiles with:
file:data/shapefiles/xxx.shp
whilst coverages are referred as:
file:coverages/mycoverage/gtopo.xxx
which is not found. If you change it to look like the shapefile
url it works:
file:data/coverages/mycoverage/gtopo.xxx
Okay thanks for the tip; we should fix the examples ...
I am more worried that a URL is used (and that it has to point to a File, and the File is passed as the source to the GridCoveargeFormat). The geotools interface accepts URLs, URIs, and can even cascade other web map servers.
Going to look if it is a user interface limitation or if it goes deeper.
Cheers,
Jody
Jody Garnett ha scritto:
Also note (at least in JBoss rather then jetty:run) that the datastores are paying attention to relative URLs correctly; but the coverage implementations all end up as file not found (even for the sample data). Apprently this is a problem Jesse discovered last week but did not report; the recomended fix is to use an absolute path.
Hum, relative path names do work, provided that you use the right path
name.
The release configuration, for some reason I don't understand,
references shapefiles with:
file:data/shapefiles/xxx.shp
whilst coverages are referred as:
file:coverages/mycoverage/gtopo.xxx
which is not found. If you change it to look like the shapefile
url it works:
file:data/coverages/mycoverage/gtopo.xxx