From: Adrian C. <ac...@gm...> - 2006-01-14 09:31:34
|
Dear Bryce Nordgren, 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 spatia= l 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 ma= p 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 t= o 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 <jga...@re...> wrote: > > Bryce L Nordgren wrote: > > Now available in the hotbox on: > > > > > http://docs.codehaus.org/display/GEOTOOLS/ISO+19123+progress+and+future+p= lan > > > > 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 i= n > > left field that I could be considered to be leading a bunch of lemmings > off > > a cliff. :) > > > > Release Notes -- Changes from Draft1 : > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * 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: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://jira.codehaus.org/browse/GEO-71 > > http://jira.codehaus.org/browse/GEO-72 > > > > Future work: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |