Thanks for the plain english: I really like your introduction.
A brief, totally preliminary glance at your doc gives me two questions:
1) can we actually read the spec or is it private? If we can read it, could you post a link to it?
2) what do you mean when you saya the following?
"But try to imagine the significance of a polygon defined using a CRS with one spatial axis and one temporal axis, or a sphere defined with two spatial dimensions and one temporal dimension. While these constructs may have some esoteric use in the halls of mathematicians and those studying Einstein's theory of relativity, spatio-temporal polygon and spheres are not useful map concepts."
For a historical gis, we certainly do
need polygons which have different shapes, topologies, presence in
space-time. "The roman empire" has a very different presence on a map
according to what part of the historical record you consider. Neither
the map at any particular time, nor the map of the "maximal extent"
(which may have occurred in different parts of the world during
different centuries) are particularly useful. So if we want geoapi to
provide the tools for historical gis, then we need either to have
coverageTimeSeries or have coverages with temporal objects within. But
perhaps I have misunderstood you; I would love to read the spec.
Cheers everyone,
--adrian
On 1/14/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
Bryce L Nordgren wrote:
> Now available in the hotbox on:
>
> http://docs.codehaus.org/display/GEOTOOLS/ISO+19123+progress+and+future+plan
>
> Holy crap! Did you realize that using IE on Windows to click on an
> openoffice document on a website opens the document up inside IE, like a
> proper helper should? Shocked the crap out of me just now!
>
It open up inside eclipse as well ;-)
> Warning, early feedback suggests that this document is dense. Meaning (I
> hope) that it packs a lot of information into a small space. Just consider
> that writing it is the result of two weeks of staring at ISO19123,
> scratching my head and wondering what it means. Reading it shouldn't take
> two weeks, but I doubt that it can reduce two weeks down to a 15 minute
> coffee break. And this is _assuming_ that I'm not coming from so far in
> left field that I could be considered to be leading a bunch of lemmings off
> a cliff. :)
>
> Release Notes -- Changes from Draft1 :
> ====================================
> * Revisions of things I found to be dumb, obvious, or inaccurate.
> * Bug fixes in my spelling (too many things trigger the spell checker).
> * Fixed the figures.
> * Added a Comment from Martin concerning efficient data access.
> * Added a proposal to specialize CV_GridValuesMatrix for the case when all
> attributes of the range's Record are the same numeric type (e.g., Images).
> The development of this proposed extension borrows from the design of
> java.awt.Raster/DataBuffer/SampleModel and the Multiarray2 library (JSR-83
> -- Withdrawn).
> * Added a section on the treatment of the Record and RecordType objects
> (e.g., Range objects for every coverage). Proposed a schema for
> consideration in GeoAPI.
> * Added a review of Stefane Fellah's coverage proposal in GeoAPI's pending
> directory.
>
> JIRA Issues resulting from this Document:
> ====================================
> http://jira.codehaus.org/browse/GEO-71
> http://jira.codehaus.org/browse/GEO-72
>
> Future work:
> ============
> Jody has requested that I review the new Complex feature type stuff w.r.t.
> the notion of an ISO19103 Record/RecordType as well as an ISO19109 Feature
> (which is a MetaClass/Class relationship and hurts my head.) If this
> yields any fruit, it will probably modify or delete the relevant sections.
>
Thanks Bryce, I am starting the ground work in geoapi right now (letting
_expression_ work against Object), this will keep us in good stead
reardless of you you represent Record.
I hope that you can just go "yeah that is the same thing" when you look
at ComplexAttribute/ComplexType that is a Record/RecordType....
I have the FeatureCollections and Filter 1.1 support in GeoAPI as well.
I am going to let people respond/panic for a bit before the fun really
starts with the rest of the FeatureModel.
I figured out a clever way of avoiding the JTS / Geometry issue a few
more weeks, it all comes down to _expression_ eventually so I placed
FilterFactory2 allowing creation of the spatial filters using two
expressions - should act as a bridge allowing geoapi uptake a step at a
time.
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
