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
