Hi Emily:
The filter thing is not strongly typed (it does not really know they
are integers).
It should however be able to check that your DAMAGE attribute is of
type interger and then it will compare try and convert the other
strings into an interger to match.
The same thing happens in reverse
I have shapefile with 5 features with an integer attribute - DAMAMGE).
Each of these features as a unique DAMAGE value between 1 and 5. In
uDig I'm creating a color-theming style that creates 5 rules that are
similar to the SLD below. These rules basically evaluate the statement
"1 <= DAMAGE
With the introduction of SimplifyingFilterVisitor for StreamingRenderer on
trunk, rasters with a rastersymbolizer no longer work due to a NPE
-
StyleGenerator bug with creating ExplicitRules
--
Key: GEOT-2542
URL: http://jira.codehaus.org/browse/GEOT-2542
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.6-M2
Environment:
Justin Deoliveira ha scritto:
>> Nope, there is none. Actually the spatial effort on H2 is languishing
>> as well, the author won't implement R-tree indexes for the moment and
>> thus the datastore is stuck into doing full scans in memory everytime
>> a spatial operator is used.
> The current "plan
Christian Müller ha scritto:
> I want to be careful here. I think we should check first if all our
> jdbc-ng and the shape file datastore are capable of handling such
> coordinates.
> Some time ago, I tried to implement the JDBC3DTest for DB2 and was NOT
> successful. At the moment, there is onl
Christian Müller ha scritto:
>
> +1 for Derby where it is possible. It is integrated in SDK 6 and, to my
> surprise, even WebSphere 7 offers a Derby XA Data Source (doing 2 phase
> commits).
> I think the long term support will be better too.
> Where we need a spatial extension, we could stay a
I want to be careful here. I think we should check first if all our jdbc-ng
and the shape file datastore are capable of handling such coordinates.
Some time ago, I tried to implement the JDBC3DTest for DB2 and was NOT
successful. At the moment, there is only an Oracle3DTest, so we should make
Hello again
We've tried recently to render our maps on Graphics other than the
screen (e.g., Batik's SVGGraphics and Graphics for printing). Almost
everything shows up nicely, BUT.. all the SVGs used as ExternalGraphics
in our SLDs suck big time.
It looks like all SVG ExternalGraphics are rend
+1 for Derby where it is possible. It is integrated in SDK 6 and, to my
surprise, even WebSphere 7 offers a Derby XA Data Source (doing 2 phase
commits).
I think the long term support will be better too.
Where we need a spatial extension, we could stay at H2 until there is a
better solutio
Andrea Aime wrote:
> andrea antonello ha scritto:
>> [...]
>>> Opinions? I noticed GeoToolkit also ditched
>>> HSQL, but in favour of the Derby version that's
>>> shipping with the JDK.
>>>
>>> Opinions, preferences?
>>>
>>> I for one prefer H2, mostly because we're already
>>> using it extensively
Thanks Milton; I am not going to get to this stuff until next weekend.
Jody
On Tue, Jun 9, 2009 at 11:36 PM, Milton
Jonathan wrote:
> Hello again folks
>
> On the previous patches I sent regarding UOM support in 2.6.x, I did not
> include a UomRescaleStyleVisitor class that we are currently using
Nice dose of caution; but it should be fine - we kind of thought this
one through when we introduced ReferencedEnvelope.
Interfaces:
- ReferencedEnvelope <- BoundingBox <- Envelope (GeoAPI)
Classes:
- ReferencedEnvelope <- Envelope (JTS)
The Envelope (GeoAPI) is very generic and allows for multi
I will go ahead with extension, but this actually hits on something I
have wanted to bring up lately, in that I think we are outgrowing our
current organization scheme. I will start a separate thread for this but
I think "extension" becoming the place where we are starting to put
everything is
+1, but i am more or less in Micheals shoes, not really qualified to
make any in depth feedback. I looked it over and the general approach
looks good to me.
-Justin
Andrea Aime wrote:
> Hi all,
> following previous discussions on the mailing list
> I've put togheter the following proposal:
> ht
Hello again folks
On the previous patches I sent regarding UOM support in 2.6.x, I did not
include a UomRescaleStyleVisitor class that we are currently using to
scale our styles/symbolizers according to the specified unit of measure.
It is currently in our own library, but if you are interes
Hi,
If everybody is ok, I have copied the parts of the geotool's trunk pom
involving the opengeo repo to the 2.5.x's pom.
I will committ it.
Cheers,
Daniele
On Mon, Jun 8, 2009 at 9:40 PM, Justin Deoliveira wrote:
> Daniele Romagnoli wrote:
> > Hi lists,
> > I have noticed that both geotools tr
andrea antonello ha scritto:
> [...]
>> Opinions? I noticed GeoToolkit also ditched
>> HSQL, but in favour of the Derby version that's
>> shipping with the JDK.
>>
>> Opinions, preferences?
>>
>> I for one prefer H2, mostly because we're already
>> using it extensively in GeoServer and GeoWebCache,
Simone Giannecchini ha scritto:
> I have a few doubts about the update of ReferencedEnvelope. Are you
> sure it is already capable of doing 3D semantic-wise?
> It implementes BoundingBox which is purely 2D and that's why it is
> used almost everywhere in the feature code. If we start to put 3d
> en
[...]
> Opinions? I noticed GeoToolkit also ditched
> HSQL, but in favour of the Derby version that's
> shipping with the JDK.
>
> Opinions, preferences?
>
> I for one prefer H2, mostly because we're already
> using it extensively in GeoServer and GeoWebCache,
> and we have a JDBC datastore based o
I have a few doubts about the update of ReferencedEnvelope. Are you
sure it is already capable of doing 3D semantic-wise?
It implementes BoundingBox which is purely 2D and that's why it is
used almost everywhere in the feature code. If we start to put 3d
envelopes in it, we would be clearly violati
Hi,
yesterday I tried to apply Emily's patch that would
upgrade our EPSG database to version 6.18:
http://jira.codehaus.org/browse/GEOT-2493
Unfortunately I found a few show stoppers, the EPSG
database started using the degree symbol extensively
in axis directions, that symbol cannot be represente
Andrea Aime ha scritto:
> Hi all,
> so I'm tagging 2.5.6, and if any further bug fix is needed
> for 2.5.6, I'll back port it directly to the tag.
>
> Out of the pool for 10 minutes please :-)
Tag done, business as usual on the 2.5.x branch
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.
Hi all,
so I'm tagging 2.5.6, and if any further bug fix is needed
for 2.5.6, I'll back port it directly to the tag.
Out of the pool for 10 minutes please :-)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
First of all - a solid +1
I really like how you have used the facilities of the feature model to
store the extra information about Z or M handling.
I am tempted to provide a Types.getDimension( GeometryAttribiute )
implementation that:
- consults the hint
- looks at the CRS dimension if the hint
Understood; when the parser is deemed ready I thought it would move to
library as well?
How about we place it in extensions (so we can get on with life) and
consider moving when the parser is ready...
Jody
On Tue, Jun 9, 2009 at 5:35 PM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>>
>> I exte
Jody Garnett ha scritto:
> I extensions or library? Extensions is getting a little heavy and non
> optional these days.
If we had to move them to library, what would be of the parser?
xsd-core in library, all the others in extensions?
I was suggesting extensions because of the tight bound between
I extensions or library? Extensions is getting a little heavy and non
optional these days.
Jody
On Tue, Jun 9, 2009 at 5:36 AM, Justin Deoliveira wrote:
> Andrea Aime wrote:
>> Hi,
>> quick mail to make some final checks on the modules
>> cleanup process.
>>
>> It seems to me all module re-assignm
28 matches
Mail list logo
