[Context.RWG] Using OWS Context to describe GML/WFS layers whichdecimate

Cameron Shorter cameron.shorter at gmail.com
Mon Oct 30 19:30:56 EST 2006

Yes, Joshua,
You have done a better job describing my problem.

Joshua Lieberman wrote:
> Bart,
> There isn't really an option in WFS, though, to express what  
> "density" is appropriate for a given GetFeature request. Colleagues  
> of mine once introduced a random order function into WFS so that the  
> client could use maxFeatures for this purpose, requesting for example  
> maxFeatures=200 and expecting that these features would be randomly  
> (not necessarily evenly) distributed within the requested extent.  
> That doesn't give you scale-dependent generalization of polygon  
> features, though, and it would be a bit scary for a WFS to return  
> different polygon coordinate strings in response to maxFeatures  
> without a way to express that capability.
> Josh
> On Oct 30, 2006, at 9:31 AM, Bart van den Eijnden (OSGIS) wrote:
>>Alternatively, you can also leave this at the server level.
>>Like Geoserver does, with its kml_reflect script. If the extent is too
>>large, it will produce an image for Google Earth, if you zoom in  
>>you will get actual vectors in KML.
>>A similar thing could be done for this use case, where you would let a
>>server-side script (acting as a WFS) decide how accurate and dense the
>>point featurecollection returned would be.
>>Best regards,
>>>It is probably worth looking at the Google Earth "super overlay"
>>>definition (http://earth.google.com/kml/
>>>kml_21tutorial.html#superoverlays)  to inform this discussion. It's a
>>>pretty awkward way of defining a tile pyramid out of anything,
>>>whether image files, cacheable WMS calls (their protestations against
>>>WMS notwithstanding), or even WFS calls to features with different
>>>levels of generality. It does, however, answer a need of working with
>>>different zoom levels and tiles.
>>>We lack a few things, not just OWS Context capabilities, to do this
>>>more elegantly. For example, it isn't immediately clear to me how to
>>>define a GML feature which has different geometries at different
>>>defined resolutions or scale ranges, or indicate that two feature
>>>collections are the same features intended for different scales.
>>>Without this sort of definition, there is something rather ad hoc
>>>about expressing it in OWS Context.
>>>On Oct 30, 2006, at 5:07 AM, Martin Daly wrote:
>>>>>zoomLevel is a term used by Google/Yahoo/MSN Maps.
>>>>>It is a measure of resolution. As you zoom out, the zoomLevel
>>>>That is not a definition that will wash in a standard that aims for
>>>>In fact, OWS Context already uses sld:Min/MaxScaleDenominator in the
>>>>AbstractResourceType, so the capability already exists.
>>>>As with the previous long e-mail trail re. GYM data, this spec.  
>>>>leverage de jure OGC standards, not de facto ones that large  
>>>>parts of
>>>>the target audience cannot use.
>>>>Context.rwg mailing list
>>>>Context.rwg at opengeospatial.org
>>>Context.rwg mailing list
>>>Context.rwg at opengeospatial.org
>>Context.rwg mailing list
>>Context.rwg at opengeospatial.org
> _______________________________________________
> Context.rwg mailing list
> Context.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/context.rwg

Cameron Shorter

More information about the Webmap-discuss mailing list