View results here ->
http://geo.openplans.org:9090/buildresults/geotools-2.3.x?log=log20061208215127Lbuild.81
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chanc
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061208191607
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to shar
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-2.3.x?log=log20061208190026
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to shar
Thx man,
I was just looking at the experimental plugins under that directory, I
need to upate and clean up a few poms. Anyway, that part should be out
of the default build process right? I assume you wanted to build them
yourself?
Simone.
On 12/8/06, Saul Farber <[EMAIL PROTECTED]> wrote:
> Hey
Hey coverage guys,
I had trouble building 2.3.x just now because the imageio pom.xml file
was still referencing gt2-referencing-2.3.0-RC1-SNAPSHOT
I updated it to 2.3.1-SNAPSHOT and everything built ok.
Is there a reason for that, or is it just a bug from the 2.3.0 release?
thanks!
--saul
---
Gabriel and I just discuss making up a Constants class in the ArcSDE
geotools plugin that contains the constants and use those constants
rather than the constants in the Dummy jar. This will certainly fix
this issue. However it can cause a problem if they every change the
values of their
GridFormatFinder cleanup
Key: GEOT-1060
URL: http://jira.codehaus.org/browse/GEOT-1060
Project: GeoTools
Issue Type: Improvement
Components: core coverage, core main
Affects Versions: 2.3.1, 2.4.M0, 2.4
Compiling against dummy api and running with real api causes
java.lang.NoSuchFieldError: SE_OPTIMIZE
Key: GEOT-1059
URL: http://jira.codehaus.org/browse/GEOT-1059
Hey all,
I can confirm that there's a bug in the dummy_api resulting in the
following scenario:
1) You compile and install gt-2.2.x without modifying any poms
2) You compile and install gs-1.4.x without modifying any poms
3) You copy the gt2-arcsde-2.2.3-SNAPSHOT.jar file into the
gs-1.4.x/W
Can you point me to the user instructions for use? I think that is the
only part I have not seen yet.
Jody
> Hi,
> I just changed the module's package name as agreed on this thread,
> thus asking permission to add the module to the build.
>
> Also asking if we can move it to supported land since w
Hi,
I just changed the module's package name as agreed on this thread,
thus asking permission to add the module to the build.
Also asking if we can move it to supported land since we have 4 (and a half)
gold stars of 5 required. Some code review, if possible, would be very
appreciated too.
rega
So it appears our current behaviour is correct. The service is supposed
to interpret this as the "default spatial key", which is indeed what we
do. The service has an option of throwing an exception when there are
multiple keys around.
-Justin
Justin Deoliveira wrote:
> After thinking about it
After thinking about it more I am actually unsure what the intent is. I
looked at the spec and couldn't find a definitive answer so I went to
the wfs-dev list.
-Justin
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> The reason for my last question about BinarySpatialOperator
Hmm...I think you figured out the issue on the udig list, but I'll
answer here for completeness.
I'm pretty sure that I compiled against the "real" jars, and that your
issue is due to compiling against the "dummy" jars and then inserting
the "real" jars in at runtime. Apparently this switch-er
Justin Deoliveira ha scritto:
> 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 att
Tim Schreiner ha scritto:
> Andrea,
>
> Thanks for the reply.
>
> Actually, my table has both fields for lat/lon and a field called
> “location”, which is a type, Geometry.
>
> What I'm not understanding is how the "Feature Type Editor" (see
> attached pics) knows which field to use to display
Doh - this is the feedback we need when trying to represent "default
geometry" - we proceeded with under the
assumption this was an invalid XPath it looks to me like this is
already covered by the use case you describe so we need a new trick :-(
So justin I think this is a case of "you wi
17 matches
Mail list logo
