Kill it, it was just like getAttributes() and getAssociations().
Jody
> So what about AttributeType#getOperations()?
>
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>
>> Yes... actually i would almost like to kill operations in that it is not
>> referenced from anywhere. Not kill the interface. My reasoning is that
>> we dont currently have a use case for them. Jody keeps mentioning some
>> coverage stuff... but noone really seems to be chomping at the
Justin Deoliveira wrote:
> I can see the argument for bringing the parent filters down... and it
> should probably be consistent with how we bring other things down from
> parent types. Like properties for instance.
>
I would recommend adding the following methods (just not right now):
- getAllR
Hi guys,
Sorry for jumping into this thread late... you guys are working too hard
for a weekend :).
Andrea Aime wrote:
> Hi all,
> I've reviewed Justin work, Jody featureland document, and this
> is my take on them. Warning, long email, thought most of what
> I'm going to say is not earth shatter
Andrea Aime wrote:
>> Perhaps I am mis understanding; would you not just refer to the the
>> above as "name" ? Are you getting conflicts between gml:name and
>> something else?
> Conflicts are quite common since a "name" column is not forbidden
> in many dbs, as well as "location" (another gml:Fe
Jody Garnett ha scritto:
> Andrea Aime wrote:
Got it, but there were two questions here. The first one is still
unanswered:
"attributes are non qualified". Hum, what do we do with GML Feature
attributes like gml:name?
>>> I would guess that SimpleFeature would not be applicable
Andrea Aime wrote:
>>> Got it, but there were two questions here. The first one is still
>>> unanswered:
>>> "attributes are non qualified". Hum, what do we do with GML Feature
>>> attributes like gml:name?
>> I would guess that SimpleFeature would not be applicable then? Um
>> "gml:name" is an o
Jody Garnett ha scritto:
...
>> I don't think you can do anything but an interactive pixel query
>> with such a method thought, it's too inefficient for anything else.
>> Access to big amounts of raster data must be optimized to the bone
>> if you want it to perform decently, I think coverage peopl
Andrea Aime wrote:
>> Afraid not - we need to consult getSuper().getRestrictions() as well.
> Any specific reason for this? Ah, I guess to properly encode the
> restrictions in an XML schema we need to know on which elements
> of the hierarchy they have been placed...
Yeah if we collapse the inform
Jody Garnett ha scritto:
> Hi Andrea - a more detailed response this time:
>> * PropertyType.getRestrictions(): List.
>> Does this list include the parent restrictions? Would be nice so.
> Afraid not - we need to consult getSuper().getRestrictions() as well.
Any specific reason for this? Ah, I g
Hi Andrea - a more detailed response this time:
> * PropertyType.getRestrictions(): List.
> Does this list include the parent restrictions? Would be nice so.
Afraid not - we need to consult getSuper().getRestrictions() as well.
> * AssociationType javadoc.
> We should have the notion of simple
Thanks for getting back to me.
> Jody Garnett ha scritto:
>> Hi Andrea; I am afraid you missed the part we needed your help on -
>> choose between these code examples.
> I fear you did not read the place in my mail where I talk about it:
Sorry Andrea; I was hoping you woudl delete the page that d
Jody Garnett ha scritto:
> Hi Andrea; I am afraid you missed the part we needed your help on -
> choose between these code examples.
I fear you did not read the place in my mail where I talk about it:
"About the Feature.getDefaultGeometry(), I prefer this alternative
compared to getDefaultGeomet
Hi Andrea; I am afraid you missed the part we needed your help on -
choose between these code examples.
-
http://docs.codehaus.org/display/GEOTDOC/02+Measurement+Example+with+getGeometry
Here is an example of what we are having trouble with:
> String sitename = (String) feature.getAttribute( "si
Hi all,
I've reviewed Justin work, Jody featureland document, and this
is my take on them. Warning, long email, thought most of what
I'm going to say is not earth shattering.
About the javadocs
--
First off, Justin, nicely done, the Prope
Thanks Justin; I have a checkout now and am writing code examples based
on what Gabriel supplied:
If anyone wants to see the difference between getGeometry and
getDefaultGeometry here it is in code:
-
http://docs.codehaus.org/display/GEOTDOC/02+Measurement+Example+with+getGeometry
-
http://doc
>>> I would like to see the "geometry" methods be consistent with the
>>> getAttribute()/getProperty()"
>>> - getAttribute( Name ): Object
>>> - getGeometryAttribute( Name ): Object (depends on your Geometry
>>> implementation)
>>> - getGeometryProperty( Name ): GeometryAttribute
>>> - getPropert
Justin Deoliveira wrote:
> Yeah, thats all i did was remove it from the factories.
>
>> Andrea mentioned fixing up the Query interface to take Name, can we do a
>> sanity check on Query to make sure it agrees with this new feature model?
>>
> Hmmm... not sure about this, Wont this kill the
> What I would like to do is this: Remove FeatureCollection from the
> factory interface. If an Feature implementation happens to have a
> "members" association it may very well decide to implement the
> FeatureCollection interface as well in order to provide some nice
> methods for java programs.
A couple of things Justin:
- great work! Internet was out at my place so I did not get to review
the javadocs yet
- can you confirmed you taged and deployed a geoapi 2.1-M9 ? I am
tripping up trying to figure out what is going on...
> * Killed FeatureCollection
>
> OK I did not kill it... but I k
Hi all,
Time for round2 with geoapi. Based on andreas initial feedback and the
thread that resulted I have taken a crack at simplifying the model. Here
is a summary of what I have done.
* JavaDocs
JavaDocs are now to the point, and no longer a brain dump from Jody :).
They should be much more ap
21 matches
Mail list logo
