Proposal looks good. A few comments.
* The proposal uses the terminology "group mode" but the code uses "type".
I might use mode since its a property that controls how the contents of the
layer group are interpreted whereas type implies info about the contents
itself?
* Possibly rename LayerGroupInfo renderingLayers() and renderingStyles() to
just layers() and styles(). Rationale being that they are simply the
derived equivalents of getLayers()/getStyles() based on type/mode. Or do
you think its necessary that it should be explicit that they only affect
the rendering process?
* It would be nice if the javadoc for the derived properties explained that
they are derived from getType() + getLayers()/getStyles().
Nothing blocking here since i know due to holidays i am late with feedback.
On Wed, Dec 19, 2012 at 3:04 AM, Andrea Aime
<[email protected]>wrote:
> On Wed, Dec 19, 2012 at 6:41 AM, Chris Holmes <[email protected]> wrote:
>
>> +1 for me. It's a nice iterative improvement forward.
>>
>> Does wms path then go away with this? I hope so, it was one of the least
>> intuitive pieces of config we had, as you had to set up a couple things
>> right to achieve what you wanted. Or do you need the next step that you
>> allude to in order to have wms path go away? If it goes away should also
>> think about the backwards compatibility of it (though I think could be ok
>> if we just tell people to figure out the new stuff and just not break their
>> server).
>>
>
> The current work does not remove wms path, but we have in the pipe the
> notion of nesting layer groups,
> which would be a separate proposal, and in that one we should be looking
> at removing wms path
> and providing some upgrade path for users that have been using wmspath.
> We were planning to do the proposal this week, but it's getting late... at
> worst it will come the
> first week of January.
>
>
>>
>> (following stuff jumps off, should in no way be a block from moving
>> forward on the above)
>>
>> With these advances in LayerGroups I wonder do they start to get at the
>> 'map' concept. See the discussion at
>> http://osgeo-org.1560.n6.nabble.com/Catalog-extension-point-td4999352.html
>> I caught up with Alexandre in Australia a couple days ago, and he's mostly
>> implemented an extension for his needs, and could be down to contribute it
>> back. It'd be good to figure out if we want to just beef up layer groups to
>> handle the 'map' concept, or if we just go down the path that a
>> 'layergroup' is essentially a map. And then how that also interacts with
>> 'workspaces'
>>
>
> Uh, totally forgot about it, and it seems really close to what we want to
> do with nesting layer groups... but that's what you get
> when someone develops stuff completely outside of the community, with
> little or no discussion... reading the thread again
> it seemed like the thing was dropped in the end?
>
> However, wasn't the old concept of "map" was meant to create separate web
> services, have separate wms trees?
> What Alexandre was after instead seemed like a way to organize the wms
> layer tree, which nested layer groups
> along with the work in GSIP 84 would allow for.
>
>
>>
>> The concept of a map is one of the top ones in ArcGIS Server. When people
>> make a map on their desktop, consisting of layers and their stylings, they
>> can just 'export to arcgis server', where all their layers show up under
>> their map. So it's like a package of layers. There's also the 'web map
>> context' document, which gets at similar concepts. And we do some stuff in
>> our software that gets at the same general thing, with 'maps' in geonode (
>> http://mapstory.org/maps/427) or geoexplorer.
>>
>
>> I know this seems like it's jumbling together a lot of similar but not
>> necessarily exactly the same concepts. But I think it may be possible to
>> have a single concept in GeoServer that helps tie them together, or at
>> least gets at a number of them. And it could just be a flexible layer group
>> with nesting. But I think one of the use cases I'd like to see is a
>> GeoExplorer or GeoNode app be able to persist their map to GeoServer. And
>> for a desktop gis to upload and save that map. So it's aware of the view,
>> the layers it has, and the styles. And to be able to access it through a
>> smart rest interface that links to the other layers.
>>
>> Anyways, I guess my question is do we think layergroups could extend to
>> handle that? Like should our eventual answer to Alexandre's question be
>> 'create a map', and we'd have a resource to do that, or would it be 'use a
>> layergroup and configure it like X'
>>
>
> I guess so, we are definitely going into that direction and we want to
> have nested layer groups real soon...
> but I don't think they will be a match for the original "map" concept, nor
> we have the resources to go there.
> For example, a Map would have allowed to create a virtual service
> cherry-picking layers from different
> workspaces, and maybe associating to each a non default style, which is
> something that cannot
> be done using just layer groups and workspaces: a workspace can have its
> own service and layer,
> and its own layer groups, but it cannot pick layers from another workspace
> (not right now at least).
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
