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. (01)
> 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. (02)
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)." (03)
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. (04)
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. (05)
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. (06)
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. (07)
> steffen (08)
>> 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 (09)
>> =============================================================
>> 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
> _______________________________________________________________ (010)
=============================================================
doug foxvog doug@xxxxxxxxxx http://ProgressiveAustin.org (011)
"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.
============================================================= (012)
_________________________________________________________________
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 (013)
|