[Geoserver-users] Customizing Google Earth output

GeoServer GeoServer User
1

I received some suggestions from a GeoServer user that I wanted to pass on to the team for comments:

Hi Mike,

Here are two recommendations for improvements to GeoServer:

1) If possible, can you allow the GeoServer developer to have control over the layout of the left hand folder menus? Currently there are folders with "0" and "1" values, which are very confusing to most people.

This is referring to the folder structure on Google Earth.

Quote:

> * *Folder menus:* Could have better organization of folder menus in
> GE. Need more descriptive folder names for each of the sub-folders
...
> is ugly, the following subfolder
> has no name, and the remaining subfolders are badly named ("0",
> "1") or unnamed. This could be structured better for improved
> clarity of function. As it is, I don't know what I would want to
> click/unclick or investigate further. Kind of a "black box" that
> needs some light shed on it. What might be difficult but would be
> super nice (!) for the end user would be to have sub-folders named
> by different regions on the globe (Alaska, Alps, Greenland,
> Canadian Arctic, Andes, Kilimanjaro, etc. etc.)--that way they
> could just click on one of those folders and be flown to that
> area, and it would give them a good spatial overview of what's
> available just by looking in the folder menu.

2) Can you allow the GeoServer developers to not include the "Download" option at the bottom of Placemarks? This is also very confusing and does not make sense to users who are not familiar with GeoServer output.

This is referring to the new "Full dataset info and download" link that we now include by default.

Quote:

   * *Data download page*: i.e. Where the second kind of link (/"Full
     dataset info and download"/) takes you. The page this takes me to
     is very muddled in my opinion. As a first time user, it kind of
     frightens me, I must admit. So much text, and the large confusing
     title "wgms_glacier_info_Type" and the "Map" screen is usually
     just a blank white screen with a few confusing red dots on it, and
     what is "POSTGIS" (I know, but most users won't), and what's an
     SRS or Native CRS or Declared CRS (again, I know, but most users
     won't), and what are "Access tiles" or GeoWebCache or OpenLayers
     code snippet, etc. etc. etc. I can imagine some users wondering
     if the whole thing isn't some sort of mistake. In other words, I
     think this page needs some definite fleshing out before it's ready
     for prime time, possibly with the assistance of a technical writer
     and/or web person.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

2

Mike Pumphrey wrote:

I received some suggestions from a GeoServer user that I wanted to pass on to the team for comments:

Hi Mike,

Here are two recommendations for improvements to GeoServer:

1) If possible, can you allow the GeoServer developer to have control over the layout of the left hand folder menus? Currently there are folders with "0" and "1" values, which are very confusing to most people.

This is referring to the folder structure on Google Earth.

Quote:

> * *Folder menus:* Could have better organization of folder menus in
> GE. Need more descriptive folder names for each of the sub-folders
...
> is ugly, the following subfolder
> has no name, and the remaining subfolders are badly named ("0",
> "1") or unnamed. This could be structured better for improved
> clarity of function. As it is, I don't know what I would want to
> click/unclick or investigate further. Kind of a "black box" that
> needs some light shed on it. What might be difficult but would be
> super nice (!) for the end user would be to have sub-folders named
> by different regions on the globe (Alaska, Alps, Greenland,
> Canadian Arctic, Andes, Kilimanjaro, etc. etc.)--that way they
> could just click on one of those folders and be flown to that
> area, and it would give them a good spatial overview of what's
> available just by looking in the folder menu.

The "folders" are just a by product of how the dataset is served in
tiles instead of being served into a single long stream that Google Earth cannot handle due to size. Technically it's very close to what
GE does with its own layers, we should just find a way to hide those
folders, since they have no "structural" meaning other than being
a way to give GE data in small manageable chunks.

Building subfolders with meaningful structure would be interesting,
but unrelated to the data streaming itself (which, as I said, is
a technicality which should be better hidden).
Structuring in folders would be possible but we first need a good
specification of how to configure it, and then look for funding
for implementing it (it's definitely not a "one day coding" thing).

So maybe open a jira issue about that, we can try to gather more
opinionos on how that could be configured. Once we have a solid spec
about that we can make a time estimate and either wait for someone
willing to dedicate his spare time to it, or see if any organisation
is interested in sponsoring the effort.

Just to throw in my 2 cents, a quick way to configure it would
be to provide a number of attributes of the feature type,
and have the code generate a layer tree by inspecting the possible
values of each attribute, in turn. So, for example, if you have
the "state" and "county" attributes the code would end up generating
a list of states on the first level of the tree, and the counties on
the second level, each under the containing state (no geometric
evaluation, just a by product of how the attributes are structured).

Cheers
Andrea

3

On Thu, 2009-03-05 at 17:41 -0500, Andrea Aime wrote:

Mike Pumphrey wrote:
> I received some suggestions from a GeoServer user that I wanted to pass
> on to the team for comments:
>
>> Hi Mike,
>>
>> Here are two recommendations for improvements to GeoServer:
>>
>> 1) If possible, can you allow the GeoServer developer to have control over the layout of the left hand folder menus? Currently there are folders with "0" and "1" values, which are very confusing to most people.
>
> This is referring to the folder structure on Google Earth.
>
> Quote:
>
> > * *Folder menus:* Could have better organization of folder menus in
> > GE. Need more descriptive folder names for each of the sub-folders
> ...
> > is ugly, the following subfolder
> > has no name, and the remaining subfolders are badly named ("0",
> > "1") or unnamed. This could be structured better for improved
> > clarity of function. As it is, I don't know what I would want to
> > click/unclick or investigate further. Kind of a "black box" that
> > needs some light shed on it. What might be difficult but would be
> > super nice (!) for the end user would be to have sub-folders named
> > by different regions on the globe (Alaska, Alps, Greenland,
> > Canadian Arctic, Andes, Kilimanjaro, etc. etc.)--that way they
> > could just click on one of those folders and be flown to that
> > area, and it would give them a good spatial overview of what's
> > available just by looking in the folder menu.

The "folders" are just a by product of how the dataset is served in
tiles instead of being served into a single long stream that Google
Earth cannot handle due to size. Technically it's very close to what
GE does with its own layers, we should just find a way to hide those
folders, since they have no "structural" meaning other than being
a way to give GE data in small manageable chunks.

This would be pretty easy to implement.

Building subfolders with meaningful structure would be interesting,
but unrelated to the data streaming itself (which, as I said, is
a technicality which should be better hidden).
Structuring in folders would be possible but we first need a good
specification of how to configure it, and then look for funding
for implementing it (it's definitely not a "one day coding" thing).

So maybe open a jira issue about that, we can try to gather more
opinionos on how that could be configured. Once we have a solid spec
about that we can make a time estimate and either wait for someone
willing to dedicate his spare time to it, or see if any organisation
is interested in sponsoring the effort.

Just to throw in my 2 cents, a quick way to configure it would
be to provide a number of attributes of the feature type,
and have the code generate a layer tree by inspecting the possible
values of each attribute, in turn. So, for example, if you have
the "state" and "county" attributes the code would end up generating
a list of states on the first level of the tree, and the counties on
the second level, each under the containing state (no geometric
evaluation, just a by product of how the attributes are structured).

This could conflict with regionation if the attribute grouping differs
from the geographic grouping; I don't believe KML provides a way to
structure networklinks in a way that is not reflected in the folder
(other than disabling the folder listing entirely).

--
David Winslow
OpenGeo - http://opengeo.org/

4

David Winslow wrote:

On Thu, 2009-03-05 at 17:41 -0500, Andrea Aime wrote:

Mike Pumphrey wrote:

I received some suggestions from a GeoServer user that I wanted to pass on to the team for comments:

Hi Mike,

Here are two recommendations for improvements to GeoServer:

1) If possible, can you allow the GeoServer developer to have control over the layout of the left hand folder menus? Currently there are folders with "0" and "1" values, which are very confusing to most people.

This is referring to the folder structure on Google Earth.

Quote:

> * *Folder menus:* Could have better organization of folder menus in
> GE. Need more descriptive folder names for each of the sub-folders
...
> is ugly, the following subfolder
> has no name, and the remaining subfolders are badly named ("0",
> "1") or unnamed. This could be structured better for improved
> clarity of function. As it is, I don't know what I would want to
> click/unclick or investigate further. Kind of a "black box" that
> needs some light shed on it. What might be difficult but would be
> super nice (!) for the end user would be to have sub-folders named
> by different regions on the globe (Alaska, Alps, Greenland,
> Canadian Arctic, Andes, Kilimanjaro, etc. etc.)--that way they
> could just click on one of those folders and be flown to that
> area, and it would give them a good spatial overview of what's
> available just by looking in the folder menu.

The "folders" are just a by product of how the dataset is served in
tiles instead of being served into a single long stream that Google Earth cannot handle due to size. Technically it's very close to what
GE does with its own layers, we should just find a way to hide those
folders, since they have no "structural" meaning other than being
a way to give GE data in small manageable chunks.

This would be pretty easy to implement.

Nice! I think leaving the current output as a debug option would be
best, looking into the regionating structure has its own merits.

Building subfolders with meaningful structure would be interesting,
but unrelated to the data streaming itself (which, as I said, is
a technicality which should be better hidden).
Structuring in folders would be possible but we first need a good
specification of how to configure it, and then look for funding
for implementing it (it's definitely not a "one day coding" thing).

So maybe open a jira issue about that, we can try to gather more
opinionos on how that could be configured. Once we have a solid spec
about that we can make a time estimate and either wait for someone
willing to dedicate his spare time to it, or see if any organisation
is interested in sponsoring the effort.

Just to throw in my 2 cents, a quick way to configure it would
be to provide a number of attributes of the feature type,
and have the code generate a layer tree by inspecting the possible
values of each attribute, in turn. So, for example, if you have
the "state" and "county" attributes the code would end up generating
a list of states on the first level of the tree, and the counties on
the second level, each under the containing state (no geometric
evaluation, just a by product of how the attributes are structured).

This could conflict with regionation if the attribute grouping differs
from the geographic grouping; I don't believe KML provides a way to
structure networklinks in a way that is not reflected in the folder
(other than disabling the folder listing entirely).

So if we were to implement this we'd basically would have to give up
regionating? Bummer... I was thinking that the main network links
would just be "structure" and the leaf would be regionated... think
appending filters that extract only the features of the current structural leaf, such as a specific county, and regionate underneath
it, assuming each county has many features inside (dunno, road network).

Cheers
Andrea

5

Andrea Aime wrote:

David Winslow wrote:

On Thu, 2009-03-05 at 17:41 -0500, Andrea Aime wrote:

Mike Pumphrey wrote:

I received some suggestions from a GeoServer user that I wanted to pass on to the team for comments:

Hi Mike,

Here are two recommendations for improvements to GeoServer:

1) If possible, can you allow the GeoServer developer to have control over the layout of the left hand folder menus? Currently there are folders with "0" and "1" values, which are very confusing to most people.

This is referring to the folder structure on Google Earth.

Quote:

> * *Folder menus:* Could have better organization of folder menus in
> GE. Need more descriptive folder names for each of the sub-folders
...
> is ugly, the following subfolder
> has no name, and the remaining subfolders are badly named ("0",
> "1") or unnamed. This could be structured better for improved
> clarity of function. As it is, I don't know what I would want to
> click/unclick or investigate further. Kind of a "black box" that
> needs some light shed on it. What might be difficult but would be
> super nice (!) for the end user would be to have sub-folders named
> by different regions on the globe (Alaska, Alps, Greenland,
> Canadian Arctic, Andes, Kilimanjaro, etc. etc.)--that way they
> could just click on one of those folders and be flown to that
> area, and it would give them a good spatial overview of what's
> available just by looking in the folder menu.

The "folders" are just a by product of how the dataset is served in
tiles instead of being served into a single long stream that Google Earth cannot handle due to size. Technically it's very close to what
GE does with its own layers, we should just find a way to hide those
folders, since they have no "structural" meaning other than being
a way to give GE data in small manageable chunks.

This would be pretty easy to implement.

Nice! I think leaving the current output as a debug option would be
best, looking into the regionating structure has its own merits.

JIRA filed:
http://jira.codehaus.org/browse/GEOS-2699

Building subfolders with meaningful structure would be interesting,
but unrelated to the data streaming itself (which, as I said, is
a technicality which should be better hidden).
Structuring in folders would be possible but we first need a good
specification of how to configure it, and then look for funding
for implementing it (it's definitely not a "one day coding" thing).

So maybe open a jira issue about that, we can try to gather more
opinionos on how that could be configured. Once we have a solid spec
about that we can make a time estimate and either wait for someone
willing to dedicate his spare time to it, or see if any organisation
is interested in sponsoring the effort.

Just to throw in my 2 cents, a quick way to configure it would
be to provide a number of attributes of the feature type,
and have the code generate a layer tree by inspecting the possible
values of each attribute, in turn. So, for example, if you have
the "state" and "county" attributes the code would end up generating
a list of states on the first level of the tree, and the counties on
the second level, each under the containing state (no geometric
evaluation, just a by product of how the attributes are structured).

This could conflict with regionation if the attribute grouping differs
from the geographic grouping; I don't believe KML provides a way to
structure networklinks in a way that is not reflected in the folder
(other than disabling the folder listing entirely).

So if we were to implement this we'd basically would have to give up
regionating? Bummer... I was thinking that the main network links
would just be "structure" and the leaf would be regionated... think
appending filters that extract only the features of the current structural leaf, such as a specific county, and regionate underneath
it, assuming each county has many features inside (dunno, road network).

JIRA not filed. :slight_smile:

Mike