Cory Horner ha scritto:
> Hey guys,
>
> Lately we have been deploying the geotools trunk site report to
> http://lists.refractions.net/gt
>
> Unfortunately, things are currently misconfigured and as a result, many
> links don't correlate directly with real locations. For example: a
> relative
Can we move to just using "gt" or "geotools" - similar to how commons
collections etc.. do things.
Jody
> Hey guys,
>
> Lately we have been deploying the geotools trunk site report to
> http://lists.refractions.net/gt
>
> Unfortunately, things are currently misconfigured and as a result, many
>
Hey guys,
Lately we have been deploying the geotools trunk site report to
http://lists.refractions.net/gt
Unfortunately, things are currently misconfigured and as a result, many
links don't correlate directly with real locations. For example: a
relative link points to "/gt2-modules" while the
Done: http://jira.codehaus.org/browse/GEOT-1402
-Steve More
On 7/16/07, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Stephen More ha scritto:
> > I see that createSchema was not written for the MySQLDataStore.
> >
> > Here is a patch for createSchema and it seems to work fine for
> > mysql-5.1-wl1326
PATCH createSchema added to MySQLDataStore
--
Key: GEOT-1402
URL: http://jira.codehaus.org/browse/GEOT-1402
Project: GeoTools
Issue Type: Improvement
Components: data mysql
Environme
Stephen More ha scritto:
> I see that createSchema was not written for the MySQLDataStore.
>
> Here is a patch for createSchema and it seems to work fine for
> mysql-5.1-wl1326 ( MySQL that includes "Precise spatial operations" ).
>
> Please let me know if you need anything from me inorder to get
I see that createSchema was not written for the MySQLDataStore.
Here is a patch for createSchema and it seems to work fine for
mysql-5.1-wl1326 ( MySQL that includes "Precise spatial operations" ).
Please let me know if you need anything from me inorder to get this
checked into svn.
-Thanks
Ste
I have a slightly shorted code example for you:
> FeatureCollection collection = myFeatureSource.getFeatures();
> featureCollection memory = DataUtilities.collection( collection );
I have added this example - and you question - to the wiki:
- http://docs.codehaus.org/display/GEOTDOC/08+FeatureColle
I have gathered up the two FeatureList examples provided and place them
onto the following page:
- http://docs.codehaus.org/display/GEOTDOC/10+FeatureList
> Well, actually I was using:
>
> final FeatureIterator iter = features.features();
> while (iter.hasNext()) {
> // ...
> }
> iter.
improve javadocs of Parser class
Key: GEOT-1401
URL: http://jira.codehaus.org/browse/GEOT-1401
Project: GeoTools
Issue Type: Task
Reporter: Justin Deoliveira
Assignee: Justin Deoliveir
Hi Gertjan,
Andrea is correct when he states that FeatureCollection is an
inconsistent entity in geotools. To be quite honest with you it is a
complete mess.
The *only* part of the FeatureCollection api that is actually
implemented relativley consistently is the iterator part of it. This is
s
Yes. cory specified the version number which to roll back the reference
and referencing extension modules to. I have not quite gotten to this
yet. I will schedule a jira task for it as a 2.4-RC0 blocker.
http://jira.codehaus.org/browse/GEOT-1400
-Justin
Andrea Aime wrote:
> Martin Desruisseaux
revert referencing to stable state
--
Key: GEOT-1400
URL: http://jira.codehaus.org/browse/GEOT-1400
Project: GeoTools
Issue Type: Task
Components: core referencing
Affects Versions: 2.4-RC0
gc.getSampleDimension(0).getMinimumValue() seems not working properly
-
Key: GEOT-1399
URL: http://jira.codehaus.org/browse/GEOT-1399
Project: GeoTools
Issue Type: Bug
sort() method does not work on FeatureCollection
Key: GEOT-1398
URL: http://jira.codehaus.org/browse/GEOT-1398
Project: GeoTools
Issue Type: Bug
Components: core filter, data
Aff
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> Geoserver uses feature sorting, so it works, but only if you specify
> it in the Query apparently?
For those keeping notes (or trying to get their own question answered by
searching through the archives): this way of sorting does not currently
work
Gertjan van Oosten ha scritto:
> As quoted from Andrea Aime <[EMAIL PROTECTED]>:
>> FeatureCollection is one of those topics where geotools developers
>> are not agreeing with each other, as such is not evenly covered usage
>> wise (which also mean QA wise). I personally don't like them, and
>> don
Add dsType to DataSource factories
--
Key: GEOT-1397
URL: http://jira.codehaus.org/browse/GEOT-1397
Project: GeoTools
Issue Type: Bug
Components: data jdbc
Affects Versions: 2.4-M4
Re
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> FeatureCollection is one of those topics where geotools developers
> are not agreeing with each other, as such is not evenly covered usage
> wise (which also mean QA wise). I personally don't like them, and
> don't rely on them more than as a glorif
Gertjan van Oosten ha scritto:
> Hello again,
>
> If I try to sort a FeatureCollection, I get a null FeatureList.
> So I do:
>
> final FeatureCollection fc = source.getFeatures(filter);
>
> and this returns my feature collection (an instance of
> JDBCFeatureCollection to be precise). Good. B
Hello again,
If I try to sort a FeatureCollection, I get a null FeatureList.
So I do:
final FeatureCollection fc = source.getFeatures(filter);
and this returns my feature collection (an instance of
JDBCFeatureCollection to be precise). Good. But:
final SortBy rt = ff.sort(sortField,
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> Unfortunately this is intended behaviour :(
> FeatureCollection is a persistent collection, whatever you do against
> it, you do against your persistent data.
OK.
> [...] but it's not an in memory snapshot like one would expect (at
> least, like m
Gertjan van Oosten ha scritto:
> Hi developers,
>
> I'm getting unexpected behaviour from FeatureCollection.
> Basically, what I'm doing is this:
>
> final FeatureCollection featuresBeforeInsert =
> getAllFeatures(connectionString, typeName);
>
> insertFeature(connectionString, typeName,
Hi developers,
I'm getting unexpected behaviour from FeatureCollection.
Basically, what I'm doing is this:
final FeatureCollection featuresBeforeInsert =
getAllFeatures(connectionString, typeName);
insertFeature(connectionString, typeName, featureAttributes);
final FeatureCollection f
Martin Desruisseaux ha scritto:
> I was not really ready for the 2.4 branch since I didn't had the time to look
> at
> the work in the referencing module. Can I suggest to wait before to make a
> 2.4
> release from the branch? I may want to keep 2.4 with the old implementation
> (with only cla
I was not really ready for the 2.4 branch since I didn't had the time to look
at
the work in the referencing module. Can I suggest to wait before to make a 2.4
release from the branch? I may want to keep 2.4 with the old implementation
(with only classes renamed) before the release, so we have
26 matches
Mail list logo
