On 10/27/2010 5:45 PM, Chris Partridge wrote:
> Hi Doug,
>
> I think we may be talking at cross purposes.
>
> 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.
>
> I was talking about 3D + 1 data, where the spatial extent is stored
> separately from the temporal extent. (01)
Yes, we are talking past each other. I joined the discussion when the
multiple locations of Berlin were discussed and specified that i was
discussing geo-spatial regions. Such regions are non-moving -- existing
in the same extended location for a substantial period of time. (02)
I was discussing things an ontology would need so that a KB using that
ontology could store positional data, not the operation of systems
that use information from the KBs. (03)
Trajectories of and corridors for moving objects would have different 3D
regions associated with different time points. (04)
> 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. ... (05)
I have no argument here. (06)
> DF> These are different issues. The full data exists in both 3D+1 and 4D. (07)
> 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. (08)
For most purposes, the system accessing the KB would not care if Berlin
were founded in 200 CE, 1600 CE, or 2000 CE, so infering the time data
would not be difficult. And elevation figures for Berlin are available,
too. For example, freemeteo.com lists Tegel airport (within Berlin) at
37 m elevation, and the average elevation of the city as 35 m. (09)
> 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. (010)
For many objects, sure. (011)
For geo-spatial regions, the temporal extent of places is generally broad.
Most cities, towns, and countries have been around for decades, and for
planning activities in the near future, would generally be expected to
still exist. For planning for a future timespan, the temporal intersection
of the place with that period would be a 4D slice of the place for the
whole period. (012)
> 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. (013)
Correct. I was not referring to just *any* dataset with 2D or 3D data, but
to a dataset of static geographic regions, basically considering
geopolitical territories (those of cities, countries, counties, etc.) but
also static terrain features. For them, the temporal range intersection
with the planning period should be calculable. (014)
> 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'. (015)
I was referring to populating a knowledge base, not to searching for data
in real time. (016)
A knowledge base that "knows" that altitude data, e.g. for lakes or cities,
is available from a given service, site, SQL querty, or external knowledge
base need not copy the data locally. (017)
Elevations with error bars can be specified if the elevation range of a
surrounding region is known. Similarly, if the elevation of one or more
enclosed spatial things is known, an elevation for the whole region (with
error bars) can be estimated. (018)
These techniques won't work for mobile objects, although an aerial vehicle
has a minimum altitude of the ground below it (except in an underground
hanger), a land vehicle has the altitude of the surface below it, and water
surface and submersible vehicles have similar elevation restrictions. (019)
Regards,
doug (020)
>
> Regards,
> Chris
>
>> -----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 (021)
_________________________________________________________________
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 (022)
|