Allan - David - Andrew Thanks very much for your thoughtful replies - I hope this community can step up
my application - we build and program wireless sensor motes that collect temperature and humidity as part of our customers' need to collect corrosion data on remote and moving samples; our motes are connected to gateways that provide real time graphing via the web. my proposal for a recursive geospatial reference is this: a modified Hierarchical Triangular Mesh (HTM) - please bear with me on this - I need to understand if my description makes sense to this community. ultimately I'm looking for an application that can locate lat/log points into triangular areas designated as follows: for those familiar with HTM, please imagine using a consistent numerical base for the initial spherical division (major triads) and subsequent inner divisions (minor triads) for an easily translatable example let's assume a base-8/octahedral system where a major triad boundary is defined as perhaps north of the equator and between 0 and 90 deg. longitude. this is a common HTM method. my modification of the conventional begins with the desginations of subsequent minor triads. the octahedral or major triad is subdivided into 64 (8^2) first minor triads: an 8-frequency octahedron. for minor triad designations imagine the row of base triangles from east to west designated 07 to 70 (07, 16, 25, 34, 43, 52, 61, 70). rows are designated by a 2x8 matrix where each subsequent row (of same polarity) is designated by a circular shift of this matrix. subsequent minor triad boundaries are subdivided by the same method resulting in a recursive geospatial reference of ever increasing resolution. one interesting note is that this method creates a longitudinal component for each triad: the vertical row of minor triads perpendicular from the apex to the base become designated 00, 77, 11, 66, 22, 55, 33, 44 (with alternating polarity). the same holds true for other regular trianuglar polyhedra - tetrahedral and icosahedral. the "address" of a given area would look something like: 07:56.72.84.01 if xx:aa.bb.cc.dd then xx is the major triad and subsequent are recursively minor triads. the speed of lookup for it would be very fast with limitless attributes located on different databases. clear as mud? this is my stab at the problem - the inner triangular designations seem to separate one HTM method from another. this one is truly recursive, incorporates the polarity of each triangular area and contains a longitudinal component. my apologies for having to invent some language to explain this - I'm open to suggestions as to more conventional terms. - brian grant > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Allan Doyle > Sent: Wednesday, June 13, 2007 10:44 AM > To: [email protected] > Subject: Re: [Geowanking] Sensor observations > > > Addendum to my earlier message... > > > The other good news is that I suspect the geowanking community could > go a long way to working out the data catalog/search/access problems > in a new, useful way. > > There are some interesting things going on: > > 1. Open Search geo extensions > http://www.opensearch.org/Specifications/OpenSearch/Extensions/ > Geo/1.0/Draft_1 > > 2. OSGeo Geodata Committee > http://wiki.osgeo.org/index.php/Public_Geospatial_Data_Project > > 3. OSGeo DCLite4G > http://wiki.osgeo.org/index.php/DCLite4G > > 4. Google's KML search > http://www.directionsmag.com/article.php?article_id=2409 > > There's plenty of material about the existing geo-search activities > out there. Google for "ogc catalog", "spatial data infrastructure", > "fgdc metadata", etc. > > The problem seems so easy. Identify a point in space. Decide what > kind of data you want. Find the data. The axle people get wrapped > around is that they then have to decide on a whole bunch of stuff > that will support doing that and it's never clear how much yak- > shaving is happening, how much institutional rivalry is happening, > how much legacy inertia is happening, etc. > > ALlan > > > On Jun 13, 2007, at 10:21, David Fawcett wrote: > > > __ Brian, > > > > I am interested in this topic as well. We have a system to make > > Minnesota air quality data available to the public. It consists of > > point sources, ambient data from monitoring stations, and Air > > Quality Index data for regional areas. I am always interested in > > looking at new ways to store, slice, represent, and publish this > > type of information. > > > > David Fawcett > > > > On 6/13/07, Allan Doyle <[EMAIL PROTECTED]> wrote: > > > > On Jun 13, 2007, at 09:24, brian grant wrote: > > > > > pardon my impressions as I've lurked this site for years and read > > this > > > thread with some amusement. > > > > > > the street view focus on the visual seems to be an effort to > > > capture the > > > transient but my needs are to capture repeatedly over time and not > > > just the > > > visual - I need temperature, humidity, particulate and other > > > atmospheric > > > data. > > > > > > I'm not necessarily looking for a way to commercialize or publish > > > data - I'm > > > here trying to find an appropriate geospatial reference that > > > defines area > > > not points - recursive areas of ever increasing resolution that fit > > > nicely > > > into a database schema or even file directory structure. > > > > You are on to something. The environmental data you seek is being > > gathered by a number of groups in a number of formats with a number > > of different metadata schemas in a number of different repositories. > > The "appropriate geospatial reference" you seek should be something > > that you can then use to query for, find, and extract the data you > > are looking for. > > > > I think in the long run, it's easier to build OpenStreetView than to > > build something that lets you do what you want. > > > > The good news is that a lot of smart people have been working on your > > problem. The bad news is that they have been working for a long time > > and it's not clear that they have come up with a viable solution, nor > > is a viable solution anywhere on the horizon. > > > > Allan > > > > > > > > > > > > > > - brian grant > > > > > > > > > > > > > > > _______________________________________________ > > > Geowanking mailing list > > > [email protected] > > > http://lists.burri.to/mailman/listinfo/geowanking > > > > -- > > Allan Doyle > > +1.781.433.2695 > > [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > Geowanking mailing list > > [email protected] > > http://lists.burri.to/mailman/listinfo/geowanking > > > -- > Allan Doyle > +1.781.433.2695 > [EMAIL PROTECTED] > > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://lists.burri.to/mailman/listinfo/geowanking > _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
