WMS might get super anal spec types a bit mad at us, I've had people tell me we shouldn't even offer the shortcuts that we do. But I would see the value. Could get around anal WMS types by making url like kml_reflect, wms/reflect?params. Want to submit a feature request to JIRA?
sounds reasonable to me – don’t fix the /wms handler, but make a reflector. the things I think of as should-handle-defaults include the BBOX, the FORMAT, the STYLE, the WFS VERSION, TRANSPARENT, etc. etc.
should i do the feature request, or was that for b. owens?
thanks,
mike
Go ahead and make a feature request for it and set it to 1.6.
Brent Owens
(The Open Planning Project)
Michael Frumin wrote:
WMS might get super anal spec types a bit mad at us, I've had people tell me we shouldn't even offer the shortcuts that we do. But I would see the value. Could get around anal WMS types by making url like kml_reflect, wms/reflect?params. Want to submit a feature request to JIRA?
sounds reasonable to me -- don't fix the /wms handler, but make a reflector. the things I think of as should-handle-defaults include the BBOX, the FORMAT, the STYLE, the WFS VERSION, TRANSPARENT, etc. etc.
should i do the feature request, or was that for b. owens?
thanks,
mike
Michael Frumin wrote:
mutter mutter,
why cant this be the case for _all_ WMS and WFS requests in geoserver?
-mike
cholmes@anonymised.com wrote:
I wouldn't say it definitely makes things more complicated - the thing that's much nicer than a regular getmap request is it supplies defaults. But if you really want to change things, then let people over-ride.
Now, if it's a matter of having to over-ride each, then yeah, doing epsg over-rides is silly. But if it's easy to do it'd be better to just reflect everything by default, providing defaults if things aren't there.
C
Brent Owens wrote:
>>> I agree that kmscore and kmattr should be passed through, but the rest > of the parameters shouldn't. It would make the kml reflector more > complicated than it needs to be. If you start passing in the other > parameters you essentially have the regular getMap request. So I would > like the reflector to remain simple, and a starting point for figuring > out how to get KML out of geoserver.
>>>> I will take a look into the kmscore and kmattr values and see that they > get passed through, and set a jira for it.
Brent Owens
>>> (The Open Planning Project)
>>>>>> Michael Frumin wrote:
>>>> I would think that these basic parameters that affect the way it works >> in GEarth, like KMScore and KMAttr, should be passed through. This >> still gets you the benefits of not having to worry about all the other >> crap (EPSG, VERSION, BBOX, etc. etc.) in a normal WMS request.
thanks,
mike
brentowens@anonymised.com wrote:
>>>>> No, parameters get cut off and default parameters are set.
The only ones that are changeable are the bounding box, and layers, >>> and I think styles.
All the reflector does is return a regular WMS getMap request, with >>> KML output, so you can just use that once, get the proper URL, and >>> use that from then on with your specific parameters.
Its intent is just a quick and dirty way of getting data, with >>> default parameters, into Google Earth.
Brent Owens
(The Open Planning Project)
mfrumin wrote:
>>>> something I'm not completely clear on -- for the whole kml_reflect >>>> thing, are
>>>>>> you supposed to be able to change the default parameters by tacking >>>> on more
GET params, eg:
http://localhost:8080/geoserver/wms/kml_reflect?layers=topp:states&KMScore=100&KMAttr=false >>>>
because when i add them onto the request, the WMS request inside the >>>> kml
file returned still has >
KMScore=30&KMAttr=true
thanks,
mike
>>
>>>> >>
-- Chris Holmes
The Open Planning Project
http://topp.openplans.org
> !DSPAM:1003,45e5f931269171194215290!
-- Chris Holmes
The Open Planning Project
http://topp.openplans.org