Hi,
I was looking into an odd failure that was happening when the
ogr format was around, but misconfigured (wrong ogr2ogr location).
In that case the ogr format reports no output formats, and that oddly
results in the dispatcher assuming ogr2ogr can handle every and any
output format!
The culprit seems to be in the dispatcher:
if ((req.getOutputFormat() != null) && (!outputFormats.isEmpty())
&& !outputFormats.contains(req.getOutputFormat())) {
//must do a case insensitive check
for ( Iterator of = outputFormats.iterator();
of.hasNext(); ) {
String outputFormat = (String) of.next();
if( req.getOutputFormat().equalsIgnoreCase(
outputFormat ) ) {
continue O;
}
}
itr.remove();
}
If the output format has no output formats it won't be removed from the
list of candidates... which is wrong. The code should have a separate
branch for the null/empty outputFormats case and just wipe out that
response from the list
Opinions?
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
Makes sense. So I guess just a check that if a response returns no supported output formats it should simply be skipped and removed to the candidate response list?
Hi,
I was looking into an odd failure that was happening when the
ogr format was around, but misconfigured (wrong ogr2ogr location).
In that case the ogr format reports no output formats, and that oddly
results in the dispatcher assuming ogr2ogr can handle every and any
output format!
The culprit seems to be in the dispatcher:
if ((req.getOutputFormat() != null) && (!outputFormats.isEmpty())
&& !outputFormats.contains(req.getOutputFormat())) {
//must do a case insensitive check
for ( Iterator of = outputFormats.iterator();
of.hasNext(); ) {
String outputFormat = (String) of.next();
if( req.getOutputFormat().equalsIgnoreCase(
outputFormat ) ) {
continue O;
}
}
itr.remove();
}
If the output format has no output formats it won’t be removed from the
list of candidates… which is wrong. The code should have a separate
branch for the null/empty outputFormats case and just wipe out that
response from the list
Opinions?
Cheers
Andrea
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev
On Mon, Nov 1, 2010 at 3:30 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Makes sense. So I guess just a check that if a response returns no supported
output formats it should simply be skipped and removed to the candidate
response list?
Indeed, that would be the plan
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
On Mon, Nov 1, 2010 at 8:44 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Mon, Nov 1, 2010 at 3:30 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Makes sense. So I guess just a check that if a response returns no supported
output formats it should simply be skipped and removed to the candidate
response list?
Indeed, that would be the plan
Looked into this a bit more and things weren't so straighforward....
so for a number
of operations there is no such a thing as an outputformat parameter,
so many responses do
not even bother to specify it.
The "hello" service used in the tests falls into this category, but
even the non fictional
TransactionResponse does not have the output format.
The answer to this for configurable output formats such as the ogr2ogr one is
to always return a negative answer to the "canHandle" call when they don't
have any possible way to handle the response.
The API was there, I just overlooked it
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
I need to change Geoserver’s source code.
I sent this email to Geoserver’s mailing list but nobody could tell me how to modify Geoserver’s source code I have waited for more than 2 weeks.
I need to offset the GIS data after getting data from source (database or others) and before publishing map. Therefore, the publishing map is not the correct one. Every point in that map is offset.
The reason why I do not use SLD is that my boss gave me a jar file and I should use this JAR file to offset data. My boss does not want to use SLD. This JAR file can create random data. I should get these random data and offset the correct GIS data. In each layer, ever point should be moved to a different place. For example, 30% points should be moved to North 100 meters. 30% points should be moved to south 20 meters. The rest points should be moved to east 300 meters.
Should I change the Geoserver’s source code or the jar file of GeoTool at Geoserver?
Which part of Geoserver’ source code should I modify?
