Re: Scaling/size of geographical entities

Franze -

I believe that you are speaking of scale based symbology. Rather than store 
different feature geometries, one geometry (such as a point, polygon, or 
circle) is stored or encoded and then a reference is made to the symbology 
rule base. The application checks the scale of the display, checks the rule 
base for that feature, and displays the feature based on the rules. So, for 
example, at 1:200000 the feature is not displayed, 1:100000 the feature is 
displayed as a point blob, at 1:50000 it is displayed as a circle with a 
radius, and at 1:20000 it is displayed as a solid filled circle of a given 
radius. In the case of the circle/radius example, the radius is determined 
by either the scale or some attribute (property) of the feature or a 
combination of both.

Cheers

Carl

----- Original Message ----- 
From: "Dr. Franz-Josef Behr" <franz-josef.behr@hft-stuttgart.de>
To: <public-xg-geo@w3.org>
Cc: <georss@lists.eogeo.org>
Sent: Wednesday, July 26, 2006 3:59 AM
Subject: 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 15:24:43 UTC