Michael Bedward ha scritto:
Hi Andrea et al,
Thanks for looking at ways to improve the process module !
I'm happy with your comments about both VectorToRaster and RasterToVector.
I would much prefer to have FeatureSource used rather than
FeatureCollection unless that presents big
Jody Garnett ha scritto:
In general I like to keep new features for trunk; however back
porting existing work if needed seems fine - and the UOM work has
been out for a bit now and released to the public already.
The main module effected is of course rendering; so if you are happy
with the
Andrea Aime ha scritto:
Michael Bedward ha scritto:
Hi Andrea et al,
Thanks for looking at ways to improve the process module !
I'm happy with your comments about both VectorToRaster and RasterToVector.
I would much prefer to have FeatureSource used rather than
FeatureCollection unless
I think that kind of seals the deal andrea; you are the module maintainer. As I
recall the UOM patch mostly leverages api that was introduced for 2.6 but did
not yet function?
Is there any api changes at all introduced by the patch? If so we could talk
about them and see if they are
Jody,
does AppSchemaConfigurationTest now pass on Windows?
Kind regards,
Ben.
On 15/06/10 11:23, Ben Caradoc-Davies wrote:
Jody, I have committed a fix. Please update and try again. Apologies for
the inconvenience.
On 15/06/10 11:02, Ben Caradoc-Davies wrote:
Aieee. Have a look at
I will have to test tomorrow on my work machine; will let you know then.
Jody
On 16/06/2010, at 5:09 PM, Ben Caradoc-Davies wrote:
Jody,
does AppSchemaConfigurationTest now pass on Windows?
Kind regards,
Ben.
On 15/06/10 11:23, Ben Caradoc-Davies wrote:
Jody, I have committed a fix.
Hi,
I'm looking into exposing the DPI setting as part of
the GeoServer WMS request, mostly so that people can
get images to send to a printer with a certain DPI.
(note: the streaming renderer already takes a hint
allowing to specify the DPI)
What I expect to see is that the symbolizers sizes
Hi,
I'm looking into a request to have the label conflict
resolution algorithm consider other graphic elements
as obstacles for labeling, in particular point symbolizers,
but it could be something else as well.
As I understand this is something the ESRI products allow
for.
The current labeler
Graceful degradation when the native postgis srid cannot be determined
--
Key: GEOT-3141
URL: http://jira.codehaus.org/browse/GEOT-3141
Project: GeoTools
Issue Type:
Hello Andrea
I don't have any code around me right now, but I can tell you my
understanding of this topic:
- DPI should affect the pixels/meter ratio (map scale).
- Symbolizers given in meters should not change apparent size when DPI
varies, as the size of the map in meters also remains the
Milton Jonathan ha scritto:
Hello Andrea
I don't have any code around me right now, but I can tell you my
understanding of this topic:
- DPI should affect the pixels/meter ratio (map scale).
- Symbolizers given in meters should not change apparent size when DPI
varies, as the size of the
VirtualTable support does not honor pk and srid settings
Key: GEOT-3142
URL: http://jira.codehaus.org/browse/GEOT-3142
Project: GeoTools
Issue Type: Bug
Components: data
Hi,
the current filter factory creates case insensitive like filters
which end up being encoded in sql as upper(att) like 'BLAH%'
making it impossible to use indexing.
Was that done on purpose or just by accident?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service
On Wed, Jun 16, 2010 at 1:12 PM, Andrea Aime aa...@opengeo.org wrote:
Hi,
the current filter factory creates case insensitive like filters
which end up being encoded in sql as upper(att) like 'BLAH%'
making it impossible to use indexing.
Was that done on purpose or just by accident?
seems
Yeah seems strange. Although something vaguely familiar perhaps for cite
tests. But I can't recall anything that would require that behavior, I
think case sensitive should be the default.
On 10-06-16 11:12 AM, Andrea Aime wrote:
Hi,
the current filter factory creates case insensitive like
Is it feasible to only activate it via a system property? This seems to
have been the approach to backporting new features to the stable branch
in the past. Although perhaps this work is too cross cutting to do so?
On 10-06-16 12:37 AM, Andrea Aime wrote:
Jody Garnett ha scritto:
I think that
Justin Deoliveira ha scritto:
Is it feasible to only activate it via a system property? This seems to
have been the approach to backporting new features to the stable branch
in the past. Although perhaps this work is too cross cutting to do so?
Actually yeah, it's doable, the uom rescaling
Hey there
Hmm, I guess I see what you mean, although I feel like it is just a
different way of seeing things.
Let's see:
symbolizers to have the same size. However on the screen 50 pixels
are long X, whilst when printed the are long just X/3 because the
priter can cram a lot more pixels
+1
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Nominate-Xiangtan-Lin-for-GeoTools-commit-access-tp5161768p5188985.html
Sent from the geotools-devel mailing list archive at Nabble.com.
--
FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper()
that is not also a FeatureType
-
Key: GEOT-3143
URL:
I can remember this discussion since I think I pointed out the problem
with the indices. And I was against it.
I am wondering that this feature is implemented. Nobody, having a
little knowledge about db engines would formulate such an SQL clause
putting performance for large tables into the
21 matches
Mail list logo
