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

[Cameron Shorter]

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  
>>further,
>>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,
>>Bart
>>
>>
>>>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.
>>>
>>>Josh
>>>
>>>
>>>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
>>>>>increases.
>>>>
>>>>That is not a definition that will wash in a standard that aims for
>>>>interoperability.
>>>>
>>>>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.  
>>>>should
>>>>leverage de jure OGC standards, not de facto ones that large  
>>>>parts of
>>>>the target audience cannot use.
>>>>
>>>>M
>>>>
>>>>
>>>>_______________________________________________
>>>>Context.rwg mailing list
>>>>Context.rwg at opengeospatial.org
>>>>https://mail.opengeospatial.org/mailman/listinfo/context.rwg
>>>
>>>_______________________________________________
>>>Context.rwg mailing list
>>>Context.rwg at opengeospatial.org
>>>https://mail.opengeospatial.org/mailman/listinfo/context.rwg
>>>
>>
>>
>>_______________________________________________
>>Context.rwg mailing list
>>Context.rwg at opengeospatial.org
>>https://mail.opengeospatial.org/mailman/listinfo/context.rwg
> 
> 
> _______________________________________________
> Context.rwg mailing list
> Context.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/context.rwg
> 


-- 
Cameron Shorter
http://cameron.shorter.net