[Geoserver-users] Customize Google Earth Attribute Display

The ability to configure or even template the attributes in at at least
some simple way is exactly what we'd be looking for if we setup
geoserver for Google streaming. Some sort of xml template file (per
applicaton, per layer) or something would be excellent!

-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net
[mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of
Brent Owens
Sent: Monday, December 18, 2006 12:23 PM
To: david@anonymised.com
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Customize Google Earth Attribute Display

It is possible, but not in an easy way: you will have to modify the
actual code itself.
The class that writes out the description information is the
KMLWriter.java class
In the future we might be able to make the output a little more robust
by allowing the user to supply a KML template file for each layer, that
will format the output of the data.
One thing you could do is add an extra column to your dataset that is a
link:
<a href="example.com">link</a>

A pretty big hack, but it will work for now.

Brent Owens
(The Open Planning Project)

david@anonymised.com wrote:

Hi, I'm a new user of Geoserver and am interested in using it to feed
streaming KML data to Google Earth. My question concerns how to

modify or

edit how the attribute data is displayed in google earth upon clicking

on

a placemarker. Geoserver's KML output automatically displays the
attribute data from the datasource as a table. Is there a way to edit
this display to display other information than just raw attribute

data.

In particular, I would like to build a URL from one of the attribute

data

columns and display it as a link within the description bubble, along

with

some custom text. Is this possible?

Thanks,

David

------------------------------------------------------------------------
-

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to

share your

opinions on IT & business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

John Zastrow ha scritto:

The ability to configure or even template the attributes in at at least
some simple way is exactly what we'd be looking for if we setup
geoserver for Google streaming. Some sort of xml template file (per
applicaton, per layer) or something would be excellent!

Ah, right, templating would be a choice too, and a more flexible one I guess. In fact, we do have Velocity in our classpath already (maybe
that's a struts dependency, don't know).

Cheers
Andre

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to create
their own custom-formatted KML files, as well any other file type they want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.

- Tyler

Andrea Aime-3 wrote:

John Zastrow ha scritto:

The ability to configure or even template the attributes in at at least
some simple way is exactly what we'd be looking for if we setup
geoserver for Google streaming. Some sort of xml template file (per
applicaton, per layer) or something would be excellent!

Ah, right, templating would be a choice too, and a more flexible one I
guess. In fact, we do have Velocity in our classpath already (maybe
that's a struts dependency, don't know).

Cheers
Andre

--
View this message in context: http://www.nabble.com/Customize-Google-Earth-Attribute-Display-tf2838364.html#a7947613
Sent from the GeoServer - User mailing list archive at Nabble.com.

Tyler Erickson ha scritto:

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to create
their own custom-formatted KML files, as well any other file type they want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.

I'm not very good at transformations, but afaik they do refer elements
or attributes or a know schema. With GML, the schema changes each
time you change feature type.
Doesn't this prevent to build a generic XSLT sheet? (was thinking about
making the most useful transforms part of Geoserver)
Cheers
Andrea

You would have to make one for each feature type. But as for a generic transformation, I don't see a way to do it.

Brent Owens
(The Open Planning Project)

Andrea Aime wrote:

Tyler Erickson ha scritto:
  

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to create
their own custom-formatted KML files, as well any other file type they want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.
    
I'm not very good at transformations, but afaik they do refer elements
or attributes or a know schema. With GML, the schema changes each
time you change feature type.
Doesn't this prevent to build a generic XSLT sheet? (was thinking about
making the most useful transforms part of Geoserver)
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

I agree that it might not be possible to write generic transformations, but
it still might be a useful way to allow users to create custom-formatted KML
files for their data. (Provided they don't mind writing or learning XSLT.)

There are many aspects of a KML file that a user might want to customize, in
addition to how the attribute data is displayed. A few interesting examples
of are...
Creating rollovers for visualizing data with many-to-many relationships:
http://www.gearthblog.com/blog/archives/2006/01/south_american.html
creating 3-D bar graphs:
http://www.sgrillo.net/googleearth/gegraph.htm

As I disclaimer, I realize that an am unknowledgable in terms of what SLDs
can accomplish for KML files. Perhaps I am wishing for functionality that
already exists... :slight_smile:

- Tyler

Brent Owens wrote:

You would have to make one for each feature type. But as for a generic
transformation, I don't see a way to do it.

Brent Owens
(The Open Planning Project)

Andrea Aime wrote:

Tyler Erickson ha scritto:
  

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to
create
their own custom-formatted KML files, as well any other file type they
want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.
    
I'm not very good at transformations, but afaik they do refer elements
or attributes or a know schema. With GML, the schema changes each
time you change feature type.
Doesn't this prevent to build a generic XSLT sheet? (was thinking about
making the most useful transforms part of Geoserver)
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Customize-Google-Earth-Attribute-Display-tf2838364.html#a7950280
Sent from the GeoServer - User mailing list archive at Nabble.com.

It wouldn't be too hard to put in height values into SLD and the KML output. We could make a <vendorOption> variable in the SLD will specify the attribute that represents the height of the KML object.
Would that be an ideal solution for some of the things you want?

Here is an example that Chris Holmes made with some quick modifications to the geoserver KML code: http://docs.codehaus.org/display/GEOS/Google+Earth+2.5d

Brent Owens
(The Open Planning Project)

Tyler Erickson wrote:

I agree that it might not be possible to write generic transformations, but
it still might be a useful way to allow users to create custom-formatted KML
files for their data. (Provided they don't mind writing or learning XSLT.)

There are many aspects of a KML file that a user might want to customize, in
addition to how the attribute data is displayed. A few interesting examples
of are...
Creating rollovers for visualizing data with many-to-many relationships:
http://www.gearthblog.com/blog/archives/2006/01/south_american.html
creating 3-D bar graphs:
http://www.sgrillo.net/googleearth/gegraph.htm

As I disclaimer, I realize that an am unknowledgable in terms of what SLDs
can accomplish for KML files. Perhaps I am wishing for functionality that
already exists... :slight_smile:

- Tyler

Brent Owens wrote:
  

You would have to make one for each feature type. But as for a generic transformation, I don't see a way to do it.

Brent Owens
(The Open Planning Project)

Andrea Aime wrote:
    

Tyler Erickson ha scritto:
  

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to
create
their own custom-formatted KML files, as well any other file type they
want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.
    

I'm not very good at transformations, but afaik they do refer elements
or attributes or a know schema. With GML, the schema changes each
time you change feature type.
Doesn't this prevent to build a generic XSLT sheet? (was thinking about
making the most useful transforms part of Geoserver)
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Adding the ability to control the height of objects would certainly be very
useful for GE visualization.

The other KML tags that would be particularly useful are the ones related to
the time of the object: <timestamp> and <timespan>. If these could be
populated using SLD it would enable a wide range of visualizations for
environmental monitoring data.

- Tyler

Brent Owens wrote:

It wouldn't be too hard to put in height values into SLD and the KML
output. We could make a <vendorOption> variable in the SLD will specify
the attribute that represents the height of the KML object.
Would that be an ideal solution for some of the things you want?

Here is an example that Chris Holmes made with some quick modifications
to the geoserver KML code:
http://docs.codehaus.org/display/GEOS/Google+Earth+2.5d

Brent Owens
(The Open Planning Project)

Tyler Erickson wrote:

I agree that it might not be possible to write generic transformations,
but
it still might be a useful way to allow users to create custom-formatted
KML
files for their data. (Provided they don't mind writing or learning
XSLT.)

There are many aspects of a KML file that a user might want to customize,
in
addition to how the attribute data is displayed. A few interesting
examples
of are...
Creating rollovers for visualizing data with many-to-many relationships:
http://www.gearthblog.com/blog/archives/2006/01/south_american.html
creating 3-D bar graphs:
http://www.sgrillo.net/googleearth/gegraph.htm

As I disclaimer, I realize that an am unknowledgable in terms of what
SLDs
can accomplish for KML files. Perhaps I am wishing for functionality
that
already exists... :slight_smile:

- Tyler

Brent Owens wrote:
  

You would have to make one for each feature type. But as for a generic
transformation, I don't see a way to do it.

Brent Owens
(The Open Planning Project)

Andrea Aime wrote:
    

Tyler Erickson ha scritto:
  

How about providing a way to return Geoserver's GML after it has been
transformed by a user-specified XSLT file? That would allow users to
create
their own custom-formatted KML files, as well any other file type they
want
(i.e. HTML, CSV, etc.) I realize it would put the design burden on
the
user, but once useful XSLT files are created they could be shared, and
perhaps the most useful transformations could become part of Geoserver
itself.
    

I'm not very good at transformations, but afaik they do refer elements
or attributes or a know schema. With GML, the schema changes each
time you change feature type.
Doesn't this prevent to build a generic XSLT sheet? (was thinking about
making the most useful transforms part of Geoserver)
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Customize-Google-Earth-Attribute-Display-tf2838364.html#a7950918
Sent from the GeoServer - User mailing list archive at Nabble.com.