Gabriel I ended up modifying your Session contact with the taskExecutor;
I needed to store Thread being used so I could detect command recursion.
Cheers,
Jody
> Hi Gabriel; I see you put the command queue in - nice work.
>
> I have broken out the Transaction.State use into two:
> - ArcTransactio
Hi Gabriel; I see you put the command queue in - nice work.
I have broken out the Transaction.State use into two:
- ArcTransactionState has the feature event notification and versioned
flag and is stored against the DataStore
- SessionTransactionState holds the Session and is stored against the
I went looking for the "correct" method of creating a Feature; I
expected CommonFactoryFinder to provide a FeatureFactoryImpl(); but
instead find that SimpleFeatureBuilder is creating the class itself...or
having it provided as a parameter.
Do we want to support a "default" Feature implementati
Sunburned Surveyor wrote:
> Does GeoTools provide a default implementation of the SimpleFeature
> interface? If not, how about an abstract class?
>
It does, if you grab a FeatureFactory using CommonFactoryFinder you
should be okay ...
> Or should I just use SimpleFeatureBuilder and not worry a
Does GeoTools provide a default implementation of the SimpleFeature
interface? If not, how about an abstract class?
Or should I just use SimpleFeatureBuilder and not worry about the
implementation of SimpleFeature that is returned?
Thanks for the info.
Landon
---
Bolla, Péter wrote:
> Jody Garnett wrote:
>> Oh! We have actual progress to report on that front; I have been
>> trying to let GeoServer work with 3D data; and one of the
>> optimizations Andrea asked for was the ability to throw away any data
>> beyond X and Y (since it was not going to be used
Jody Garnett wrote:
> Oh! We have actual progress to report on that front; I have been trying
> to let GeoServer work with 3D data; and one of the optimizations Andrea
> asked for was the ability to throw away any data beyond X and Y (since
> it was not going to be used for rendering).
>
> Thu
Bolla, Péter wrote:
>> Here is an alternative; you can ask a JTS CoordinateSequence to hold
>> your own Coordinates that can include x,y,z and a time stamp. While
>> this is easier with ISO Geometry (where your CRS could literally be
>> x,y,time) you can certaintly fake it with JTS right now.
>
Peter,
You wrote: "The problem with the timestamps come up in the case of the
tracks. For waypoints - a point feature - you can store the geographic
coordinates in the geometry, and the timestamp as an attributte. But
with tracks - which intuitively should be a linestring - you can have
timestamps
Oh! We have actual progress to report on that front; I have been trying
to let GeoServer work with 3D data; and one of the optimizations Andrea
asked for was the ability to throw away any data beyond X and Y (since
it was not going to be used for rendering).
Thus was born the Hints.FORCE_2D - s
Jody Garnett wrote:
> Do you have specifics? It sounds fine to me; you may uncover some bugs
> along the way .. but the OracleDataStore does similar tricks when
> working with x,y,z,m data (ie from LRS datasets). I think the other fun
> bit of info would be a new GeoTools Function to "grab" th
Hello,
Saying your question is naive is linguistically distinct from saying
you are naive. I've never met you so I could not possibly know if you
are or are not. Besides, I'm generally partial to the surveyors whose
paths I've had a chance to cross (or rod to carry) so I'd be inclined
to think hig
Jody Garnett wrote:
> Bolla, Péter wrote:
[...]
>> current implementation of the GPX datastore in the repository extends
>> JTS to use 4 coordinates for every point, so it can store the
>> timestamp along with the geometry, and I could even define a compound
>> CRS with 4 axes (lat, lon, eleva
Bolla, Péter wrote:
> Hi,
>
> The problem with the timestamps come up in the case of the tracks. For
> waypoints - a point feature - you can store the geographic coordinates
> in the geometry, and the timestamp as an attributte. But with tracks -
> which intuitively should be a linestring - you
Hi,
The problem with the timestamps come up in the case of the tracks. For
waypoints - a point feature - you can store the geographic coordinates
in the geometry, and the timestamp as an attributte. But with tracks -
which intuitively should be a linestring - you can have timestamps for
every
Adrian Custer ha scritto:
> Hey all,
>
> Wherein we discover that stats are hard, even for the simple
> questions...
>
>
> On Tue, 2008-05-20 at 10:18 +0200, Andrea Aime wrote:
>> Jody Garnett ha scritto:
>>> What a difficult question; is there a strict definition of the quantile
Peter,
You wrote: "So if I might suggest a path how to get involved, there is
a much more GIS related problem with the GPX datastore, than the xml
parsing. It is the temporal capabilities, that is only very coarsly
supported by geotools (and I guess by any other GIS toolkit), and
makes it hard to
Andrea Aime wrote:
> Yeah, silly. Unfortunately that's exactly what you're getting today
> out of the quantile classification simple. I have cases, with real
> data, where the current function generates 3 subsequent intervals at 0.
Okay since the stats are not helping us that much let me share wi
Andrea Aime wrote:
> Jody Garnett ha scritto:
>> What a difficult question; is there a strict definition of the
>> quantile function we could grab from statistics or something?
>
> I did not find much, and none of what I've found talks about how to
> handle flat areas in the data histogram:
> htt
I'm sorry that some topics has gone that emotional. This is true that figthing
against complexity is a very hard topic - hacking GeoTools is a daily fight
against entropy.
On my side, the complexity in GeoTools that scare me the most is not the ISO
model complexity. While ISO models try to scop
Adrian,
Thank you for the detailed response, it seems that you, like other
GeoTools programmers, are willing to patiently answer my questions.
This is appreciated. I have some interleaved responses to your e-mail
below.
You wrote: "Your question seems totally naive."
I am a lot of things, but I
Hey all,
You are now expected to use maven 2.0.9. Earlier versions may work but
we make no guarantees.
On an empty .m2/repository, using
mvn --version
Maven version: 2.0.9
Java version: 1.5.0_15
OS name: "linux" version: "2.6.24-16-generic" arch: "amd64"
Hey all,
Wherein we discover that stats are hard, even for the simple
questions...
On Tue, 2008-05-20 at 10:18 +0200, Andrea Aime wrote:
> Jody Garnett ha scritto:
> > What a difficult question; is there a strict definition of the quantile
> > function we could grab from statist
Sunburned Surveyor a écrit :
> [2] Why wrap simple geometries in an ISO or OGC specification? Is
> there a FOSS Java library for representing simple geometries that
> offers serious competition for JTS? Are there any plans for such a
> library in the future? I wonder if it is worth the additional
>
Sunburned Surveyor a écrit :
> Martin wrote: "was an independant effort and could probably be
> replaced by existing ReferencedEnvelope"
>
> Is there a task list or something similar where these housecleaning
> items are tracked and delegated?
I'm not aware of task list specifically dedicaced to
Jody Garnett a écrit :
> I had a look; it does not look like an actual overlap; Envelope2D
> extends Rectangle2D and thus can be directly used with Java APIs
Right.
ReferencedEnvelope is for interraction with JTS.
Envelope2D is for interraction with Java2D.
Both extend the appropriate class f
Jody Garnett ha scritto:
> What a difficult question; is there a strict definition of the quantile
> function we could grab from statistics or something?
I did not find much, and none of what I've found talks about how to
handle flat areas in the data histogram:
http://www.gisbanker.com/introduc
Sunburned Surveyor wrote:
> Jody,
>
> I will have to read some of the documentation you highlighted and
> revist this issue, as I still don't completely understand. This is a
> struggle for me because I'm moving from a single monolithic
> application (OpenJUMP) to a multi-part library (GeoTools). I
Sunburned Surveyor wrote:
> The recent threads on the different Envelope classes got me to
> thinking about the policy for Geometry representation in GeoTools, if
> there is one. In OpenJUMP land representation of feature geometries is
> pretty simple. You just use JTS. :] If something more is need
Hello,
Your question seems totally naive.
JTS is a good library but it should be obvious why it cannot form the
basis of a geometric engine for a geographic information system at
anything other than local scales. Using JTS has been a great first step
for Geotools since we've been able to focus o
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/598/changes
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt
31 matches
Mail list logo
