Hi all,
On trunk max number of decimals is stored on a per feature type basis, however its not hooked up to any of the encoders, only the global one is respected.
http://jira.codehaus.org/browse/GEOS-3332
Fixing is easy, however I began to think of what the behavior should be when the wfs query contains multiple types since the encoders only accept a single value for all features, not one per feature type.
I can think of a couple of different options:
1. use the minimum of all the per feature type values and the global
2. use the maximum ""
3. ignore the per feature type settings when multiple types are being queried and just use the global
Thoughts? Using maxFeatures as a guide it would seem #1 would be the most consistent. But I could also see a case made for #3 as well.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Given the options I would say Use the maximum, using global only if at least one of the queried types has no numDecimals configured (is it Integer.MAX_VALUE in that case?). Rationale being it's the one going to cause least damage (ie, you may get some more decimals for a type, but won't loose precision for the ones with a higher numdecimals), and still respect the setting as much as possible?
I'm not sure what would be involved in making the encoder respect the settings for each one though...
my 2c.-
Cheers,
Gabriel
Justin Deoliveira wrote:
Hi all,
On trunk max number of decimals is stored on a per feature type basis, however its not hooked up to any of the encoders, only the global one is respected.
http://jira.codehaus.org/browse/GEOS-3332
Fixing is easy, however I began to think of what the behavior should be when the wfs query contains multiple types since the encoders only accept a single value for all features, not one per feature type.
I can think of a couple of different options:
1. use the minimum of all the per feature type values and the global
2. use the maximum ""
3. ignore the per feature type settings when multiple types are being queried and just use the global
Thoughts? Using maxFeatures as a guide it would seem #1 would be the most consistent. But I could also see a case made for #3 as well.
-Justin
Gabriel Roldan wrote:
Given the options I would say Use the maximum, using global only if at least one of the queried types has no numDecimals configured (is it Integer.MAX_VALUE in that case?). Rationale being it's the one going to cause least damage (ie, you may get some more decimals for a type, but won't loose precision for the ones with a higher numdecimals), and still respect the setting as much as possible?
That is a good point, i never thought about it like that. Maximum number does make more sense in that light.
I'm not sure what would be involved in making the encoder respect the settings for each one though...
Not that much work i suppose, just add a map of feature type to number of decimals...
my 2c.-
Cheers,
Gabriel
Justin Deoliveira wrote:
Hi all,
On trunk max number of decimals is stored on a per feature type basis, however its not hooked up to any of the encoders, only the global one is respected.
http://jira.codehaus.org/browse/GEOS-3332
Fixing is easy, however I began to think of what the behavior should be when the wfs query contains multiple types since the encoders only accept a single value for all features, not one per feature type.
I can think of a couple of different options:
1. use the minimum of all the per feature type values and the global
2. use the maximum ""
3. ignore the per feature type settings when multiple types are being queried and just use the global
Thoughts? Using maxFeatures as a guide it would seem #1 would be the most consistent. But I could also see a case made for #3 as well.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Gabriel Roldan wrote:
Given the options I would say Use the maximum, using global only if at least one of the queried types has no numDecimals configured (is it Integer.MAX_VALUE in that case?). Rationale being it's the one going to cause least damage (ie, you may get some more decimals for a type, but won't loose precision for the ones with a higher numdecimals), and still respect the setting as much as possible?
That is a good point, i never thought about it like that. Maximum number does make more sense in that light.
I agree using the maximum looks like the most sensible choice, and
agree on the algorithm proposed as well.
I'm not sure what would be involved in making the encoder respect the settings for each one though...
Not that much work i suppose, just add a map of feature type to number of decimals...
Hmmm... interesting one. With this we would respect the user wish
fully, but at the same time we'd produce a GML document that looks
a little odd. If it's much more work than setting a single max
let's just wait for someone to have a real need for this?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.