What I'd eventually like to see is that the reflector ease of use is part of the rest hierarchy. We're going to have the layer overview page, with like states.html. I think there you should be able to do reflector type stuff /states.png&srs=900913&style=blue
We can promote that as an alternate API, which is nice and easy to use, and isn't a hack on top of WMS that confuses the issue. I think I agree that KML and WMS on the demo page should either both be reflectors or both not. I think how I feel about which it should be fluctuates between how in to OGC I am at the time. I mean, the real thing to do would be to influence them so that the way the reflector does it becomes part of the standard. Which in my humble opinion is how they should have done it from the start - supply reasonable defaults, and indeed is the case with WFS. I agree WFS is less complicated, but it's way easier to get some data out of it with a url and iterate from there. Chris Mike Pumphrey wrote: > I've been working with the KML reflector with all the Google Earth work > that we've been doing, and I think it's great. It allows users to > request layers using a URL structure that is simple and only includes > what the user specifically cares about. It's customizable, but it makes > sensible assumptions. That's nifty. > > So, it was very neat to learn (yes, you all know this, and I'm sure > someone has shown it to me at some point) that there is an equivalent > for WMS requests. > > I think this should be more prominent. Specifically, I would like to > see the WMS reflector available as part of the list of links we include > on our Map Preview page. Before I file a JIRA, I wanted to know if > there was any specific reasoning why the KML reflector was included on > that page, but not the WMS reflector? > > I talked to Andrea in the channel about this and since he mentioned that > he's likely to be slow to respond due to other commitments, I will quote > from our conversation below to provide his 2 eurocents. > > --- > > [12:56] <bmmpxf> aaime: Out of curiosity, is there a reason why we don't > have the Map Preview links use the WMS reflector? > [12:56] <bmmpxf> ...considering we use the KML reflector for the KML > links... > [12:56] <aaime> because we're supposed to teach people the standards > [12:56] <aaime> (imho) > [12:57] <aaime> why the KML links used the reflector in the first place, > eh, don't know > [12:57] <aaime> I prefer the vanilla WMS request from a "this is WMS" > point of view > [12:57] <aaime> thought I see how the reflector may be nicer > [12:58] <aaime> as in easier > [12:58] <aaime> but it's misleading as well > [12:59] <bmmpxf> aaime: I can see it from both sides, but I think we > should either use the reflector for both or neither. (I prefer both.) > [12:59] <aaime> yeah, I'd prefer neither instead ;) > [13:00] <bmmpxf> But it's tough, because we don't want to dumb down our > demo page... > [13:00] <aaime> it really boils down to what audience you want to get > [13:00] <aaime> the people looking for OGC stuff will be put off by the > reflector usage > [13:00] <aaime> the people looking for quick and dirty will prefer the > reflector instead... > [13:02] <bmmpxf> But if we have this nifty, easy-to-use feature, perhaps > we should push it a bit more? > [13:02] <bmmpxf> As in, why not have both links on the demo page? > [13:02] <aaime> because we have too many links already ;) > [13:02] <aaime> we need more demo pages > [13:02] <aaime> one that shows off the reflectors would be great > [13:03] <aaime> as would be one that allows you to easily build a WFS > GetFeature request > [13:05] <bmmpxf> aaime: Yeah, I guess we should add that to the list. :) > [13:06] <aaime> or else we could have a demo page showing how to build a > wms GetMap > [13:06] <aaime> and use the reflectors in the preview > [13:10] <bmmpxf> aaime: These are good ideas. Shall we start a thread > on the users or devel list? I'd like to solicit some feedback from > others as well... > > > > Thanks, > Mike Pumphrey > OpenGeo - http://opengeo.org > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Chris Holmes OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
