Another question about the earth observation mode. As I understand it
currently the eo support is being built as an extension / community module?
Whereas the LayerGroupInfo.Type.EO is in the core model? Is the plan to
eventually include the eo support in the core wms module? Or leave it as
an extension?
On Fri, Jan 4, 2013 at 12:08 PM, Justin Deoliveira <[email protected]>wrote:
> 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.
>
--
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
