Re: Scaling/size of geographical entities

I'd like to pick up Holger's question:

 > I wonder how do visual/interactive systems deal with the scaling 
issue > right now, if they only have latitude/longitude values?

This question reminded me to IBM's GFIS system. Each feature (having 
something like a identifying location) possessed geometrical properties 
(shapes) according to different (up to 5 as far as I remember) scale 
ranges. The geometrical elements could differ i.e.  point and polygon 
properties could appear independently according to the acale. 
Additonally the feature could be hidden in some scales.

Geometrical analyses were based on the identifying location *or* on the 
scale dependent shape properties. Perhaps such an approach could be used 
instead of the "radius approach".


Mit freundlichen Grüßen / Regards / Cordialement

Franz-Josef Behr


--
------------------------------------------------------------------------
The blending of technology and art has always turned me on.
                                           Molly E. Holzschlag
------------------------------------------------------------------------
Prof. Dr. Franz-Josef Behr - Home Office
Author of: Strategisches GIS-Management - http://www.gismngt.de
eMail: franz-josef.behr@hft-stuttgart.de
http://www.gis-news.de
Tel: 0721 / 453980-1 sowie 45 33 35
Fax: 0721 / 453980-7 sowie via web.de: 01212-5-12048213

Holger Knublauch schrieb:
> 
> Thanks Joshua.  With a basic glimpse on this, I would hope that the geo 
> ontology is extended with a geo:radius attribute: it is a low hanging 
> fruit while having feature types is probably an overkill.  To specify 
> the feature type of something, it would be sufficient to make it an 
> instance of some class, e.g. subclassing SpatialThing.
> 
> However, I wonder how do visual/interactive systems deal with the 
> scaling issue right now, if they only have latitude/longitude values? 
> Can anyone in this group explain at what zooming level they start, e.g. 
> if they show a mash-up page for real-estate development?  A "standard" 
> radius attribute could be attached to either classes or instances and 
> then used to automatically select an appropriate zooming level.
> 
> I can imagine that having no such standard facility for scaling will 
> likely lead to drifting solutions and partition the community.  Starting 
> small is fine, but could also be a wasted opportunity.
> 
> Holger
> 
> 
> Joshua Lieberman wrote:
>> I would suggest, if you haven't already, to have a look at 
>> www.georss.org, which we intend to use as the source of the geo 
>> update. There are two attributes defined in this model which could be 
>> useful for communicating scale. The first is the featuretypetag, since 
>> feature types such as cities may carry an implicit scale with them. 
>> The other is the radius attribute, which can define a radius of 
>> interest about a point or other geometry. One could go even farther 
>> and define an explicit semantic for point with radius (e.g. 
>> <is-located-at+aoi> ) using the relationshiptag attribute.
>>
>> You also point out an area for future geospatial ontology development 
>> activity, that of context or viewpoint. For now, however, it should be 
>> practical to start small.
>>
>> Cheers,
>>
>> Josh
>>
>> On Jul 20, 2006, at 5:19 PM, Holger Knublauch wrote:
>>
>>>
>>> All,
>>>
>>> long/lat coordinates are very useful to describe points but they 
>>> don't tell us anything about the scale/size of the item.  For 
>>> example, if we attach a coordinate to a city then this means 
>>> something really different from a coordinate on a specific restaurant 
>>> in that city.
>>>
>>> The practical problem I am facing right now is that I am developing a 
>>> map browser for our ontology editor, so that it can show Google maps 
>>> for the selected object (assuming it has coordinates).  However, when 
>>> the user navigates to a given resource, how can I determine a useful 
>>> zooming of the map - here I would need something like dimension or 
>>> area to get an idea of whether to show the whole city, a suburb, a 
>>> block, or a street or backyard.  What about introducing an optional 
>>> but recommended property for scale or size?  The onion stuff could 
>>> help, but I don't see a standard property for this in the 
>>> vocabulary.  Alternatively there could be an area class, but this may 
>>> complicate querying and using the vocabulary.
>>>
>>> I guess this may return the group to the discussion about the size of 
>>> the new vocabulary, and where to set the boundary.  But my feeling is 
>>> that some scaling information is critical for any form of visualization.
>>>
>>> Thanks for any comment,
>>> Holger
>>>
>>>
>>
>

Received on Wednesday, 26 July 2006 09:59:38 UTC