Hi Doug, (01)
I think we may be talking at cross purposes. (02)
When, I said:
CP> > In practice, it is not straight-forward to do it the other way around
CP> > - though (of course) it can be done. (03)
I was talking about 3D + 1 data, where the spatial extent is stored
separately from the temporal extent.
One example would be Air Control Means - in Air Defence.
Here the spatial extent is typically booked for a period of time. This means
the temporal boundaries are given by (stored as) a start and end time - so
the whole boundary is at one time. The shape is a time-slice of the extended
spatial extent.
When one specifies a 4D shape, one can have boundaries that cut across time.
A standard example would be an Air Control Means (of whatever shape) that
followed an aircraft around - which is not a time-slice (at least to the
traditional frames of reference). (Try defining how to store this this using
the standard 3D + 1 data layout.)
Booking time-slices is not a very efficient use of airspace.
So the 3D + 1 approach makes some efficient uses of airspace difficult to
specify. (In practice, in the systems we looked at, these efficient
airspaces were described in text fields - as the data layout could not
support it (easily?).) (04)
DF> These are different issues. The full data exists in both 3D+1 and 4D. (05)
WRT the comments on the Berlin data - my point was that the data (e.g.
Displayed as N52 31'27", E13 24'37") has no specified altitude or time - so
one needs to infer (if one can) these to get the 3D +1 data - and then the
4D. And this is not always easy, or possible, automatically when just given
the data. In our experience, when working with the datasets, it was not
uncommon to have only some of the co-ordinates stored (often 2D and 3D). It
was possible in some cases, to work out an algorithm for inferring these
from the given data, but not always.
One way of reading what you are saying above is that given a dataset with 2D
or 3D data, then there is always an algorithm to calculate the 4D (or 3D +
1) extent from the data in the dataset (which is usually all the system has
access to). I assume that you cannot mean this as it is false. (06)
I note that in your discussion, you talk about a "surface location from
elsewhere". Getting data "from elsewhere" is often not a practical option
with operational systems - though adding in a geoid or similar (for surface
location) is common. Maybe this is what gives rise to the 'cross-purposes'. (07)
Regards,
Chris (08)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of doug foxvog
> Sent: 27 October 2010 21:56
> To: [ontolog-forum]
> Cc: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] GPS coordinates in an ontology?
>
> On Wed, October 27, 2010 3:44, Chris Partridge said:
> > On 27/10/2010 06:40, doug foxvog wrote:
> > > Tools could generate 4D locations as needed from 3+1D.
>
> > In practice, it is not straight-forward to do it the other way around
> > - though (of course) it can be done. That is assuming that it is clear
> > from the context whether an altitude and/or time is assumed. E.g. in
> > Berlin's case, there is some kind of geoid-level altitude assumed.
>
> These are different issues. The full data exists in both 3D+1 and 4D.
> I was referring to CP's distinction: "the traditional 3D + 1 approach
(i.e. it is
> not 4D in our sense of the word)."
>
> Altitude data from one source can be used with 2D Earth surface location
> from elsewhere. One needs to provide an altitude range, instead of a
single
> value for the whole place (unless it is a still body of water).
> The altitude of a surrounded place or surrounding place can be used to
> estimate the region's altitude if no specific data is found. Geographical
> attributes such as flat or hilly can be used to help estimate altitude
range.
>
>
> On Wed, October 27, 2010 4:19, Steffen Lindek said:
> > Doug and Sean,
> >
> > The reason for the variation of Berlin's position according to Sean's
> > sources is not so much the extent of the urban area. It's rather due
> > to a bad choice of coordinates by the NY Times. If you look up the
> > position that it specifies, you end up near a small village north of
Berlin.
>
> The NY Times position is a converted typo. They must have intended
> 52 31'27" N (GeoNames's figure) but entered N52 31'37". That converts to
> NYT's decimal degrees N.
>
> If a knowledge base were given a bounding polygon for Berlin and the
single
> coordinate provided by each data source, a data verification program could
> flag that the point provided by the NTY is outside the boundary provided
by
> a different source.
>
> > steffen
>
>
> >> On Tue, October 26, 2010 14:49, sean barker said:
> >>> Just to add to the problem, it is interesting to compare the
> >>> position of
> >>> Berlin according to various sources:
> >> Berlin is almost 900 sq. km. Giving its position to centi-microns,
> >> as Geonames does makes no sense. If there is a an official marker
> >> from which distances are measured, it makes some sense to give its
> >> location to the closest meter. Specifying its center to the
> >> decimeter is not very useful.
> >>
> >> An ontology for representing static places that extend in area needs
> >> more than just to specify a single point. There are different ways
> >> to do this.
> >>
> >> Useful concepts to include in an ontology are
> >> * defined reference location
> >> * boundary curve(s) as one or more sets of vertexes with straight lines
> >> (or arcs) connecting them
> >> * bounding and bounded Mercator rectangle
> >> * bounding/bounded circle
> >> * Elevation
> >> + average
> >> + max& min
> >> * Error bars for all locations (a useful concept for all measured
> >> values).
> >>
> >> Just like other measured values, the ontology should have multiple
> >> units (and in this case systems of units) in which positions can be
> expressed.
> >> Conversion tools or services should allow a value to be input/output
> >> using any appropriate desired system.
> >>
> >> Moving objects would have a relation that specifies their 2D or 3D
> >> location at given times. Tools could generate 4D locations as needed
> >> from 3+1D.
> >>
> >> == doug foxvog
> >>
> >>
> >>> Geonames
> >>> 52.5243681651343;13.410530090332
> >>> Displayed as N52 31'27", E13 24'37", and 52.52437 13.41053
> >>> http://sws.geonames.org/2950159/
> >>>
> >>>
> >>> New York Times 52.6166667, 13.4 as geo: lat, long
> >>> http://data.nytimes.com/N50987186835223032381
> >>>
> >>>
> >>> DBpedia - 52.500557, 13.398889 as geo:lat long
> >>> AND 52 30' 2" 13 23' 56" as dbpprop:latd, latm, lats, longd,
> >>> longm,
> >>> longs
> >>>
> >>> http://dbpedia.org/resource/Berlin
> >>>
> >>> Freebase 52.52334 13.41269, contained by Germany, Europe
> >>>
> >>> http://rdf.freebase.com/ns/guid.9202a8c04000641f80000000000094d6
> >>>
> >>> The positions agree within about 1 km in longitude, but in
> >>> longitude the
> >>> variation is of the order of 10 km.
> >>>
> >>> Sean Barker
> >>> Bristol, UK
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> >>>> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Chris
> >>>> Partridge
> >>>> Sent: 26 October 2010 12:46
> >>>> To: '[ontolog-forum] '
> >>>> Subject: Re: [ontolog-forum] Fw: GPS coordinates in an ontology?
> >>>>
> >>>>
> >>>> *** WARNING ***
> >>>>
> >>>> This message has originated outside your organisation,
> >>>> either from an external partner or the Global Internet.
> >>>> Keep this in mind if you answer this message.
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Ian mentions below I had done some work in this area.
> >>>>
> >>>> As Sean said earlier, it is useful to distinguish between the
> >>>> object being represented and its representation.
> >>>> As Ian points out below, it can take some effort to be sure what
> >>>> object is being presented.
> >>>>
> >>>> The team found that it is often geo-spatial (all three dimensions)
> >>>> and temporal data - rather than just spatial data that is of
> >>>> interested (at least in the defence domain we were working in). We
> >>>> are often interested in the things that stay in the same place
> >>>> (place? See Aristotle for more
> >>>> details) over time.
> >>>> Maybe because we have a 4D bias :-) we found a 4D approach useful.
> >>>> I give some pointers to the 4D approach below.
> >>>> A geo-spatial (all three dimensions) and temporal position (point)
> >>>> is a point in 4D.
> >>>> So (as Ian says below) if we were not interested in the temporal
> >>>> co-ordinate
> >>>> - in programming terms, it was stripped out - then we have a point
> >>>> in 3D (with an associated time) and a line in 4D.
> >>>> If (as Ian says below) we were not interested in the altitude
> >>>> co-ordinate - in programming terms, it was stripped out - then we
> >>>> have a line in 3D (with an associated time) and 4D.
> >>>> There were the standard issues about whether the line was the
> >>>> tangent to the normal of some reference ellipsoid or through some
> >>>> notional centre of the earth.
> >>>> If we were not interested in either the altitude or temporal
> >>>> co-ordinates, then we have a line in 3D and a plane in 4D.
> >>>>
> >>>> Interestingly we found that taking the 4D approach revealed some
> >>>> potential improvements in airspace management.
> >>>> We were interested and amused to find the term 4DATM (4D Air
> >>>> Traffic
> >>>> Management) is in use - whereas from our perspective this follows
> >>>> the traditional 3D + 1 approach (i.e. it is not 4D in our sense of
> >>>> the word).
> >>>> Our take on this was that this recognised the importance of looking
> >>>> at space and time together (for things like ATM) but did not make
> >>>> the
> >>>> (paradigm?) shift from 3D + 1 to 4D.
> >>>>
> >>>> Regards,
> >>>> Chris
> >>>>
> >>> snip
>
> >> =============================================================
> >> doug foxvog doug@xxxxxxxxxx http://ProgressiveAustin.org
> > _______________________________________________________________
> > Steffen Lindek | Rightscom
> > | Linton House
> > | 164-180 Union Street
> > | London SE1 0LH, UK
> > steffen.lindek@xxxxxxxxxxxxx | www.rightscom.com
> > _______________________________________________________________
>
> =============================================================
> doug foxvog doug@xxxxxxxxxx http://ProgressiveAustin.org
>
> "I speak as an American to the leaders of my own nation. The great
initiative
> in this war is ours. The initiative to stop it must be ours."
> - Dr. Martin Luther King Jr.
> =============================================================
>
>
> ________________________________________________________________
> _
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
> http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?WikiHomePage#nid1J
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
> (09)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (010)
|