Tim Swanson wrote:
> Do you mean GeometryDescriptor and GeometryType?
>
Sorry I have been looking at too much GeoTools 2.2. code recently :-( I
am pretty much sure to have some of the names wrong ... looks like you
got the split between Descriptor and Type now. For Geometry vs Attribute
it is the difference in your intentions; are you intending to capture
location data? If so you convey that intention by using a GeometryAttribute.
You can hold a Point in a normal Attribute; but other programs would not
know what you are up to; you are treating it as data - rather than
location. And as such the rest of the library will leave it alone - ie
treat it as data just like you did.
What does it mean to be a GeometryAttribute; it means you have a CRS and
a Bounds. It is not an ensure of the Java Binding.
The following could all be used as a GeometryAttribute:
- Shape (ie Java2D)
- Geometry (ie JTS)
- TransfineSet (ie Geoapi)
- SDO_GEOMTRY
- etc....
Now for those of you who like JTS this sounds terrible; the trick is to
remember this is straight data model.
If you want to see a JTS Geometry we will use the query model to figure
that out; use an Expression to evaulate the attribute with a the class
you want to see produced.
- expression.evaulate( feautre, Geometry.classs ); // if you wanted to
do some spatial analysis
- expression.evaulate( feature, Shape.class ); // if you wanted to draw
on screen
How do you know what expressions are valid? Use the metadata model; ie
the SimpleFeature, AttributeDescriptor and GeometryDescriptor; this
records the "names" used when making your query.
> Assuming you do, doesn't such a check seem brittle, as it depends on the
> actual underlying implementation of the GeoAPI? (In the case of GeoTools,
> this is obviously irrelevant, as the implementation is what it is. In the
> more general case, however, this is troubling.)
>
No that is the contract we are going for; GeometryAttribute reports the
CRS and Bounds in a "geometry implementation independent" way... it is a
strong API contract we mean to keep.
> Suppose that in some fictional GeoAPI implementation I write a class that
> creates AttributeDescriptor objects. Now, some of these objects /could/
> technically be created as GeometryDescriptor objects,
> but there is nothing in the interface contract that requires me to do that.
True; any suggestions on how we can make the requirement more clear?
> I could happily return an object whose type implements AttributeDescriptor
> but not GeometryDescriptor. In this case, a direct cast would fail at runtime.
Sorry it is not a direct cast; we are asking you to do an instance of
GeometryAttribute check; that is how (as you go through the attributes)
you can test which ones represent geometry.
> (And an instanceof check would return false, which would be misleading.)
>
Agreed if we use it wrong; we will not communicate well. Having a
specific method in Feature that returns the default GeometryAttribute is
one of the ways we advertise this functionality.
> It seems that in this case an explicit conversion is needed, which would
> necessitate a method to check to see if conversion is possible, asÃ:
>
> interface AttributeDescriptor {
> ...
> boolean isGeometryDescriptor();
> GeometryDescriptor asGeometryDescriptor();
> ...
> }
>
We tend to use instanceof checks (rather than isXXX and toXXX - ie we
are making a strong ISA statement; not advertising the availability of
an adapter ...). This is not an optional or casual use of classes; we
are using the Class to communicate what we mean.
You will see the same split with FeatureSource (read-only) FeatureStore
(read/write) and FeatureLocking (concurrency control)
> Assuming that every AttributeDescriptor that is convertible to a
> GeometryDescriptor actually /is/ a GeometryDescriptor at runtime creates a
> hidden requirement on anyone who implements the GeoAPI.
>
So how can we not hide this one? Is the getDefaultGeometry method enough?
> At the risk of repeating myself (since I just thought of another way to say
> it), I think there's a risk in this blurring of the lines between the Java
> object hierarchy and the abstract data model.
Not a risk an intention. We are asking people not to care about the
format of the geometry; we are asking them to care about what the data
structure (we are representing the meaning as Attribute;
GeometryAttribute, ComplexAttribute, Feauture and SimpleFeature). We are
presenting the vocabularly in AttributeDescriptor,
GeometryAttributeDescriptor, etc... and the data type in AttrubuteType,
GeometryAttributeType etc...
> Assuming that any object that is created is always the most specific type it
> possibly can be seems like a bad idea.
>
>
>> PS. you are having a whole bunch of talented questions; it would really
>> help if you had either commit access (for helping with javadocs) or wiki
>> access (for jotting notes down for the next person :-)
>> PPS. yes GeoTools is accepting volunteers ;-)
>>
>>
>
> Thanks for the vote. I'll have to see about it. The work I'm doing currently
> is my job, not my hobby, and unfortunately at the moment I don't have time
> for another hobby.
>
Still open source works via contribution; I answer questions (that help
you in your work) exactly so I can recruit good feedback and good people.
> However, if it's ok with my employers, I'd be happy to do some work here and
> there to write up what I've taken in so far. I have several pages of notes
> that might (if cleaned up) make decent user manual material.
>
That is exactly the kind of thing that helps; notes are the start of
documentation.
> P.S. Sorry about the signatures. They're automatically generated by our mail
> server and sometimes it goes in the wrong place.
Cheers,
Jody
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
