I've implemented the distance() method for GeometryImpl in the geometry
module. I based it off of what JTS does. The geometry module creators
had already implemented a distance calculation for point->point and
point->line in the CGAlgorithms class, much like in JTS, and I used
those methods f
The only modules with problems were "unsupported":
- gt2-geometry had a FactoryFinder import ... did not use it
- jts-wrapper just seems to be broken - is someone else stubbing the
required distance function?
I have closed : http://jira.codehaus.org/browse/GEOT-1222
Cheers,
Jody
---
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/886
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and t
Yeah we could add a "batch" mode - the resulting event ends up being
"something changed here is the bounding box" - basically the same event
AUTO_COMMIT listeners get after a transaction has committed on a
different thread.
Thinking.
Some FeatureSources implement their bulk operations (like addFe
Hi Martin, with the proposal out of the way (I suppose I better ask for
a vote?) I was going to get going on the referencing module.
To start with:
- I was going to make sure the tests (and online tests) were in place ...
- Rename classes as outlined in proposal (for clarity)
And then when the v
Continuum a écrit :
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/885
A NullPointerException in BufferedInputStream.close(), while no body changed GML
parser code as far as I know (and "mvn install" worked for me)...
For informat
Andrea Aime a écrit :
> Sounds good. Let me know when you have something I can test in Geoserver :)
Commited to Geotools trunk as of revision 25779 (took me the whole day). Not
sure if it is directly usable for Geoserver however (see below).
Using the Envelope given in previous Andrea's email for
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/885
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and t
Jody Garnett a écrit :
> Oh to be clear - I cannot reproduce this problem on my machine (so I
> cannot look into a fix).
Reminder: we have the Continuum test result here:
http://geo.openplans.org:9090/continuum/servlet/browse?file=1/modules/library/main/target/surefire-reports/org.geotools.data.m
Jody Garnett a écrit :
> What kind of hardware do you run these days? Multi core?
No, monocore. A 3 years old latop with Pentium 4 on Gentoo.
> The tests have not been changed to my knowledge - near as I can tell
> they are reporting actual locking failures. Please note I have
> refactored the t
Oh to be clear - I cannot reproduce this problem on my machine (so I
cannot look into a fix). If we can figure out a way to reproduce this
problem on anyone's machine then we should be able to figure out what is
happening and progress towards a fix ...
Please respond to this email, and we can t
What kind of hardware do you run these days? Multi core?
The tests have not been changed to my knowledge - near as I can tell
they are reporting actual locking failures. Please note I have
refactored the tests last year (so the variable names are transaction1
rather than t1) so people should be
Jody Garnett a écrit :
> That does sound bad - Martin you did not accidentally upgrade to maven
> 2.0.6 did you? This was the kind of problem that pushed me back ...
I'm using Maven 2.0.6 for a few months. But the error that I reported was on
Continuum (on my machine too at random occurence, but i
Andrea Aime wrote:
> This is bad, but I don't think it's your fault.
> Developers, did anyone touched memory data store or locking related
> stuff lately? The only change I see on main was made by chorner
> yesterday, but I don't know if it's relevant (does the memory data store
> use the filter
That does sound bad - Martin you did not accidentally upgrade to maven
2.0.6 did you? This was the kind of problem that pushed me back ...
Jody
Andrea Aime wrote:
> Martin Desruisseaux ha scritto:
>
> This is bad, but I don't think it's your fault.
> Developers, did anyone touched memory data
On Friday 08 June 2007 18:24:24 Jody Garnett wrote:
> Well if there are two of you working with *version* - and it is a part
> of the formal model I do not adding it back in (emphais to the current
> feature model).
>
> I just did not want it in the model with nobody using it - figured it
> would g
I assume this is testing our ability to handle concurrent access ... I
sometimes get random failures (usually on windows) when two threads are
attacking a shapefile.
In each and every case Jesse went in and looked at the "lock" code and
sorted things out...
I think this is "just" an honest pro
Well if there are two of you working with *version* - and it is a part
of the formal model I do not adding it back in (emphais to the current
feature model).
I just did not want it in the model with nobody using it - figured it
would get in the way when a real user (ie you two) came along.
Do y
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/881
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and t
For information the test failure on Continuum is:
---
Test set: org.geotools.data.memory.MemoryDataStoreTest
---
Tests run: 37, Failures: 1, Error
Martin Desruisseaux ha scritto:
> Continuum a écrit :
>> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/878
>
> Does anyone have any idea what is going on with those locking tests? Those
> tests
> fail randomly quite often!! I had t
Continuum a écrit :
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/878
Does anyone have any idea what is going on with those locking tests? Those tests
fail randomly quite often!! I had to launch "mvn install" 4 times with absolutl
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/878
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and t
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> In this case the singularity is the south pole, whose latitude is
>> determined, but longitude is not. When you have it, you should add
>> the -180,180 range to envelope longitudes (or I'm missing something)?
>
> Longitude would be tested
Andrea Aime a écrit :
> In this case the singularity is the south pole, whose latitude is
> determined, but longitude is not. When you have it, you should add
> the -180,180 range to envelope longitudes (or I'm missing something)?
Longitude would be tested too, like every bounded axis (no matter w
Martin Desruisseaux ha scritto:
> Sometime it is good to forget a little bit about a problem, have a good night
> and think again about it the day after. I believe that we can handle this
> issue
> in a finer way than brute force.
>
> There is my assumption, please correct me if I'm wrong:
>
> T
Sometime it is good to forget a little bit about a problem, have a good night
and think again about it the day after. I believe that we can handle this issue
in a finer way than brute force.
There is my assumption, please correct me if I'm wrong:
The problem arise because the Envelope to be proje
Jody Garnett ha scritto:
> Some more thoughts ...
> featureId is supposed to be immutable - so it makes a good hashcode /
> equals test.
>
> The formal OGC feature model did have a getVersion(): String - but we
> never used it, and never used it, and finally removed it from GeoTools.
> Andrea ha
28 matches
Mail list logo