Hi all,
The reason for my last question about BinarySpatialOperator was this filter:
...
Note the empty property name. How i need to interpret this is as run the
intersection against every geometric attribute in the type. My question
is how do I do that.
With
Fair enough, you guys win :).
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Hmm, fair enough, if it is limiting it is limiting... but do you have
>> an example of where it is too limiting? The problem i am running up
>> against right now is when a "empty" property name is supplied as part
We also had a policy of adopting GeoAPI interfaces when they were
available; this habit broken when GeoAPI moved too quickly for us to
keep up when the go-1 renderer was introduced. I would try and reword
this to adopt official GeoAPI interfaces (ie that have been through the
review process); t
Justin Deoliveira wrote:
> Hmm, fair enough, if it is limiting it is limiting... but do you have
> an example of where it is too limiting? The problem i am running up
> against right now is when a "empty" property name is supplied as part
> of binary spatial op.
We had a choice between:
- Expre
Hello Simone
I would like to know if you have some more hints about your plan for
IndexColorModel support? I'm asking that because actually, IndexColorModel is
already supported (in some way) for at least 2 years, and I would like to agree
on what may be the beast approach for that.
What I wou
Andrea Aime a écrit :
> I guess you're referring to Sun's way of doing things, is it documented
> anywhere? Or is it just:
> * mark operations as deprecated for one release before removing;
> * mark release an API has been introduced into using @since
> * make sure interfaces do not change over tim
이승준 a écrit :
> I'm working with Canvas, and I have a problem at 'getGraphicsAt' and
> 'getGraphicsIn' which returns an array of Graphics.
>
> When a user requests small area dragging mouse on a displayed map, it's ok.
> However on a large request, I've got OutOfMemory error.
>
> Why don't they r
SLD and Filter both allow specification of geometry property to use.
I suspect defaultGeometry is a convenience for lazy configuration, but
also allows re-usable SLDs I guess.
The semantics are vague - I'd just choose the first geometry that
matches the available symboliser, for SLD and perhaps
Hmm, fair enough, if it is limiting it is limiting... but do you have an
example of where it is too limiting? The problem i am running up against
right now is when a "empty" property name is supplied as part of
binary spatial op.
Now does this mean that we should get the "default geometry", o
Hi Justin,
I worked through this a couple months ago - and came to a different
conclusion I did not think we could ask people to be limited by the
specification in this manner. So I place Expression on both sides of the
Operator and placed the limitations on FilterFactory, and took them off
Hi all,
I think i have found another gap between xml schema land and the geoapi
filter model, and you guess it, it is BinarySpatialOperator.
First the schema for the type:
Which states that one of the operands must b
HI Saul,
Did you compile the gt2 arcsde jar against the "real" jars or the
dummy jar? I have tried a zillion different permutations now but I
realize that I compiled against the dummy jar.
Jesse
On 7-Dec-06, at 3:14 PM, Saul Farber wrote:
> I updated and everything built to 2.2.3-SNAPSHOT l
I updated and everything built to 2.2.3-SNAPSHOT like a charm.
Thanks Gabriel!
--saul
Gabriel Roldán wrote:
> fixed the poms in 2.2.x land,
> you should just update and get it building ok.
>
> bug me if not.
>
> regards,
>
> gabriel
--
fixed the poms in 2.2.x land,
you should just update and get it building ok.
bug me if not.
regards,
gabriel
On Thursday 07 December 2006 23:27, Saul Farber wrote:
> Jesse,
>
> Sorry this took me so long!
>
> I'm trying with the latest build of 2.2.x (2.2.3-SNAPSHOT + some kind of
> weirdness in
thanks Cory,
that saved me a lot of pain
Gabriel
On Thursday 07 December 2006 18:35, Cory Horner wrote:
> Gabriel Roldán wrote:
> >Hi all,
> >
> >I've just found that all the poms in 2.2.x have the parent and self
> > version correctly set to 2.2.3-SNAPSHOT, but all the dependencies are set
> > to
Jesse,
Sorry this took me so long!
I'm trying with the latest build of 2.2.x (2.2.3-SNAPSHOT + some kind of
weirdness in the maven repo right now involving lots of downloaded 2.2.2
jars) and geoserver-1.4.x.
First try:
using jars from maven.geotools.fr
(http://maven.geotools.fr/repository/com
Justin Deoliveira wrote:
> Added page for graph module.
>
> http://docs.codehaus.org/display/GEOTOOLS/Graph
Thanks Justin can you go through the rest of the check list from
http://docs.codehaus.org/display/GEOT/Supporting+your+module ?
The remaining things for 2.3 are:
- rate your module
- review
Added page for graph module.
http://docs.codehaus.org/display/GEOTOOLS/Graph
Jody Garnett wrote:
> One of the "reasonable" request for supported modules was a wiki page
> showing end-users how the module is doing. The timeline for this was
> the 2.3.0 release; which has just occurred (see
>
I'm making up pages for wfs and shapefile renderer
Jesse
On 7-Dec-06, at 10:30 AM, Jody Garnett wrote:
> One of the "reasonable" request for supported modules was a wiki page
> showing end-users how the module is doing. The timeline for this was
> the 2.3.0 release; which has just occurred (se
Jody Garnett a écrit :
> One of the "reasonable" request for supported modules was a wiki page
> showing end-users how the module is doing. The timeline for this was
> the 2.3.0 release; which has just occurred (see
> http://docs.codehaus.org/display/GEOT/Supporting+your+module).
Added wiki p
Simone Giannecchini ha scritto:
> Ciao list,
> at our company GeoSolutions we are trying to set up public nightly
> builds for GeoTools 2.3.x since it is used by many people, especially
> by geoserver trunk. Right now between bug fix and release it is
> intercourring too much time. We are hoping to
Justin Deoliveira wrote:
>> A nice elegant solution, before I call it complete can I ask how we
>> can handle "@gml:fid" into a call to FidMapper (I do not need a
>> solution just to make sure you have thought ahead to how to handle
>> this case).
>> +0 (changed to +1 when I see a comment on ho
One of the "reasonable" request for supported modules was a wiki page
showing end-users how the module is doing. The timeline for this was
the 2.3.0 release; which has just occurred (see
http://docs.codehaus.org/display/GEOT/Supporting+your+module).
Plug-ins that will be "unsupported" are:
- a
Hi all,
I updated the geoapi 2.1-SNAPSHOT, so if you are having problems
building trunk try the -U option to force it to check for a new snapshot.
-Justin
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
---
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Hi all,
>>
>> I have made some changes to the jdbc module. I haven't committed yet and
>> was hoping that one ( or more :) ) of the other jdbc module maintainers
>> ( or anyone for that matter ) could perform a code review for me.
> Thanks Justin
Gabriel Roldán wrote:
>Hi all,
>
>I've just found that all the poms in 2.2.x have the parent and self version
>correctly set to 2.2.3-SNAPSHOT, but all the dependencies are set to 2.2.2.
>
>I'm going to fix it and commit at least someone stops me :)
>
>
This is a known issue in the release proc
Jesse Eichar ha scritto:
> As usual the maven release script did not modify all the version
> numbers up to 2.2.3-SNAPSHOT so the branch is not buildable if you
> don't have 2.2.2 in your workspace. Gabriel and I are trying to make
> the necessary changes.
Sob... I did fix it on my local ch
Thanks Simone, can you provide these links on the 2.3.x wiki page. Can
also ask if you can set up a nightly "deploy" (rather then just a build).
Cheers,
Jody
> Ciao list,
> at our company GeoSolutions we are trying to set up public nightly
> builds for GeoTools 2.3.x since it is used by many peop
Justin Deoliveira wrote:
> Hi all,
>
> I have made some changes to the jdbc module. I haven't committed yet and
> was hoping that one ( or more :) ) of the other jdbc module maintainers
> ( or anyone for that matter ) could perform a code review for me.
Thanks Justin ...
> Summary of changes:
>
>
Ciao list,
at our company GeoSolutions we are trying to set up public nightly
builds for GeoTools 2.3.x since it is used by many people, especially
by geoserver trunk. Right now between bug fix and release it is
intercourring too much time. We are hoping to tackle this issue.
You can see the resul
Hi all,
I've just found that all the poms in 2.2.x have the parent and self version
correctly set to 2.2.3-SNAPSHOT, but all the dependencies are set to 2.2.2.
I'm going to fix it and commit at least someone stops me :)
regards,
Gabriel
--
Gabriel Roldán ([EMAIL PROTECTED])
Axios Engineering
As usual the maven release script did not modify all the version
numbers up to 2.2.3-SNAPSHOT so the branch is not buildable if you
don't have 2.2.2 in your workspace. Gabriel and I are trying to make
the necessary changes.
Jesse
---
Jesse,
I'll build with the latest 2.2.x jars and see if I have the same
problem, but it definitely looks like a problem with your jsde jars. Do
you have all three of them in your webapps/lib directory and can you
confirm the version (and maybe an sha1 checksum to see if I have the
same ones?)
I think that's a good idea. Geoserver has been providing a seperate
download of the gt2-arcsde plugin for those who want it, but now that
there's a dummy API it doesn't seem that there's any reason not to have
it in the build.
--saul
---
Sure!, These operations could be reused in other projects too, We think
geotools is a good site.
Regards
Mauricio
--
Axios Engineering
www.axios.es
e-mail: [EMAIL PROTECTED]
tel-:+34 94 441 63 84
fax: +34-94 441 64 90
On Wednesday 06 December 2006 15:37, Andrea Aime wrote:
> Hum, really int
Hi all,
I have made some changes to the jdbc module. I haven't committed yet and
was hoping that one ( or more :) ) of the other jdbc module maintainers
( or anyone for that matter ) could perform a code review for me. The
diffs are located here:
http://jira.codehaus.org/browse/GEOT-1058
Summ
jdbc improvments
Key: GEOT-1058
URL: http://jira.codehaus.org/browse/GEOT-1058
Project: GeoTools
Issue Type: New Feature
Components: data jdbc
Affects Versions: 2.3
Reporter: Justin Deoliveira
37 matches
Mail list logo
