Andrea Aime wrote:
>> The duplication of method names results in hard to understand code.
>> Here is the suggested improvement:
>> - FeatureType.getAttributeDescriptor(): AttributeDescriptor
>> - Feature.getAttribute(): Attribute
> Yes, I like the proposed solution better. I believe the original
Andrea Aime wrote:
> Yes, I like the proposed solution better. I believe the original method
> names were shortened to save space.
> Anyways, that's a GeoAPI change. I'm favourable, but not very keen to
> work on it as you may already know.
That is why you have friends; just got the email now - I w
Andrea Aime wrote:
> Anyone against this?
>
We need the check with CQL parser people; make sure "." is an acceptable
thing.
Jody
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that vo
Andrea Aime wrote:
> A better solution is to have those filters use an expression
> that evaluates to the feature/value being passed, Jody has suggested
> "." and I agree.
>
> Anyone against this?
>
I need us to verify against XPath use for refering to "this"; let me
check ... http://www.w3scho
Andrea Aime wrote:
> As I said, it's actually doing all the work, no factory at all...
> FeatureFactoryImpl is actually able to build a feature, but
> it requires a List as parameter, which is nothing
> short of atrocious performance wise.
And therefore we must fix it. SimpleFeatureFactory used to
I am worried about duplication; a lot of the information you describe is
covered by the pom.xml file
> We need to agree on a layout of files. For isogeom, I've settled on:
>
> LGPL --- version 2.1 (i.e. a copy of each license applicable)
>
in the pom.xml
> LICENSE --- the actual text of th
Jody Garnett a écrit :
> I am not sure what the time line is for the ISO Geometry work? The
> existing wrapper based implementation is not very well done.
I would said approximatively one year. Of course we don't know for sure.
Martin
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Validation today occurs in two places:
>> * in feature building, when using SimpleFeatureBuilder
>> * in feature attribute change, since our features are mutable
>>
> I kind of figure that the attribute change validation check should be an
> impl
Hi Johann; I know we have talked about the matter before. Reading my
last email and it came across a little too blunt.
What do you think about the idea of making FeatureTypeStyle and below
(ie the Symbology Encoding Specification) immutable? If you think it can
be done I would like to see it ha
Andrea Aime wrote:
>> I do like the idea of *time* as a measure of how hard the the code is
>> to get right; how about 1 week Andrea?
> To make you a realistic example, most of the paid works I worked on
> lately where split in chunks varying from 3 days to two weeks, adding a
> week on top of one
Thanks Adrian; we have a similar understanding of the problem. Actually
I venture to suggest my lack of understanding exceeds yours :-)
Jody
Adrian Custer wrote:
> The JTS-Wrapper vision does not convince me yet since I'm not sure that
> it is possible to logically integrate the capabilities of s
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> This will be a tough one; I am strict about the need to support both
>> ISO Geometry and JTS Geometry. I think I mentioned these ideas (and a
>> JTS 2.0) in one of the planning emails.
> The way I see the design, GeoTools core would work stri
Andrea Aime wrote:
> Validation today occurs in two places:
> * in feature building, when using SimpleFeatureBuilder
> * in feature attribute change, since our features are mutable
>
I kind of figure that the attribute change validation check should be an
implementation option; ie off by defaul
Hi guys;
I would like to make sure FeatureTypeStyle and below are immutable; this
is the part we actually feed into a portrayal engine; and it makes sense
to address thread safety etc up front. If the rendering implementations
can trust the style not to change they can be coded in a much more
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/769/changes
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with
Hi guys,
while working on ND plugins, I'm starting to change JODA's temporal
dependencies in favor of unsupported temporal module, containing temporal
implementation of GeoApi. In such a context I have noticed that the Utils
class in org.geotools.temporal.object package allows to build a Date from
Between predicate with expressions
--
Key: GEOT-1869
URL: http://jira.codehaus.org/browse/GEOT-1869
Project: GeoTools
Issue Type: Improvement
Components: core cql
Affects Versions: 2.5-M2
Hello,
I would like every PMC opinion on this.
I'm working on a branch for style and I arrived at the Symbolizer level.
Martin raised this issue of GeoAPI when I started to work on the new
style interfaces.
"Should we make Styles Immutable ?"
Here is the structure of the style interfaces :
St
Hi,
we've been discussion for quite some time now that feature
validation should be disabled. There are quite a few
decent arguments pro disabling it:
* validation, especially in the new feature model framework
using filters for expressing restrictions, is extremely
expensive (more on this in
Ability to change the threshold for the goodness fit algorithm for polygon
labels
-
Key: GEOT-1868
URL: http://jira.codehaus.org/browse/GEOT-1868
Project: GeoTools
Baroudi Malek ha scritto:
> Hello list,
>
> I would like to know if geotools 2.4.2 have a supported datastore for GML?
> The developed datastore is to be used as part of conversion between OSM
> (Open Street Map) file format and another GIS file format using GML
> Datastore.
Nope, we don't have
Hello list,
I would like to know if geotools 2.4.2 have a supported datastore for GML?
The developed datastore is to be used as part of conversion between OSM
(Open Street Map) file format and another GIS file format using GML
Datastore.
Regards Malek Baroudi
-
Hi,
we discussed this already in a recent thread but since it's
a little bit buried I would like to put it in plain sight
and get a confirmation no one is against it.
In feature restrictions we have filters that have to check
the validity of an attribute value. This filter is expressed
against the
On Tue, 2008-07-01 at 11:16 +0200, Martin Desruisseaux wrote:
> Adrian Custer a écrit :
> > Standardizing the format and layout is probably a great idea.
> >
> > Moving it to an obscure location is likely to make module maintainers
> > even less likely to create, update and maintain that file.
>
Hey all,
I don't want to delve into this discussion too deeply right now but, for
the long term, there is quite a bit to discuss.
Currently, GeoTools uses JTS in two roles: to *define* the vector
representation of the data and to *represent* the data. I suspect these
roles will have to be split i
Hi Martin,
On Tue, Jul 1, 2008 at 11:13 AM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> Hello Daniele
>
> Daniele Romagnoli a écrit :
> > Not sure to fully understand this statement. Are there coverages having
> a
> > vertical/temporal crs definition without a 2d spatial extent defined?
>
Hi guys,
I would like just to clarify that my intend was to describe the whole
coverage CRS using the SpatialCRS Node which can be general, i.e. may
contain an Horizontal a Vertical and a Temporal CRS in any combination ... I
guess in this sense you are right Martin, the name should be changed fro
Jody Garnett a écrit :
> This will be a tough one; I am strict about the need to support both ISO
> Geometry and JTS Geometry. I think I mentioned these ideas (and a JTS
> 2.0) in one of the planning emails.
The way I see the design, GeoTools core would work strictly on ISO geometries
(which ma
Martin Desruisseaux a écrit :
> http://www.mumm.ac.be/Assets/Pages/ADCPstroomprofiel.jpg
>
> This is a vertical slice. We typically have "depth" as the vertical axis of
> the
> raster, and "time" as the horizontal axis of the raster. Raster values are
> speed
> in m/s.
I mean "depth" as
Adrian Custer a écrit :
> Standardizing the format and layout is probably a great idea.
>
> Moving it to an obscure location is likely to make module maintainers
> even less likely to create, update and maintain that file.
Well, the problem is that if we want to integrate the review in the Maven
Hello Daniele
Daniele Romagnoli a écrit :
> Not sure to fully understand this statement. Are there coverages having a
> vertical/temporal crs definition without a 2d spatial extent defined?
Yes. An example in the oceanography field (I'm supposed to be an oceanographer
:) ) are the images produ
Hi guys,
I have uploaded the document to google docs. I have invited some of you as
co-workers.
Some observations:
- As stated before, the actual document contains some figures and notes
which come from a previous version. The interesting part is about the
Metadata structure.
- I have cut away the
Standardizing the format and layout is probably a great idea.
Moving it to an obscure location is likely to make module maintainers
even less likely to create, update and maintain that file.
On Mon, 2008-06-30 at 22:52 +0200, Martin Desruisseaux wrote:
> At last IRC meeting, it has been propose
On Mon, 2008-06-30 at 11:42 -0700, Sunburned Surveyor wrote:
> I'm trying to complete the tasks I need for my "unsupported" GeoTools
> module. One of these steps was completing the paper work necessary to
> transfer my copyright for GeoTools code to the OSGeo. However, the
> GeoTools developer guid
Hi Martin,
thank you for the feedbacks.
Some of our choices (choices of mine and Alessio) have been made while
extending/improving the MetadataAccessor class. Therefore, sometime we have
"reduced the complexity of/bypassed" some metadata nodes to reduce the
accessor's hierarchy.
Here below, some qu
On Tue, Jul 1, 2008 at 12:55 AM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Thanks everyone that was a great bit of discussion. What started this thread
> was an guideline to use when trying to decide if we needed to roll our own
> on any given Sunday. Andrea's numbers ring true to me; two weeks are
Jody Garnett a écrit :
> we have already forked JTS once; can we fork JODA and just
> take out the tricky code we are having trouble with?
I don't think we need that. The "trouble" is that GregorianCalendar has an
unituitive API ("January" is month 0), is not thread-safe, java.util.Date is
muta
Martin Desruisseaux ha scritto:
> At last IRC meeting, it has been proposed to include the review document into
> the page generated by "mvn site:site". For this purpose, I would like to move
> every review.txt file (currently at the root of each module) to the following
> location:
>
> /sr
Jody Garnett ha scritto:
> Hi Andrea; just to let you know there have been some request on the user
> list about making the method names consistent. If you can consider the
> following requests I would like your feedback.
>
> - FeatureType.getAttribute(): AttributeDescriptor
> - Feature.getAttri
39 matches
Mail list logo
