I am gearing up for deployment of Geoserver in my organization. We are using it mostly to serve Google Earth clients to non-GIS users, and I am curious how others have organized their data distribution models in such a case. I also have an interesting idea for coding a model into geoserver.
With access to the back-end I can obviously update any layers that are already network-linked in client’s GE, but what are the options for adding new content/network links to my user’s clients? Since there is no way to have a true “push” model, how do you implement a pull strategy?
Ideas:
Email List: Either paste geoserver URL’s to generate KML or send out a pre-generated KML file via email
Advantages: Full control over KML content.
Disadvantages: No central repository of available layers
Simple, static and secure web page with a list of URL’s to call specific layers. Users are then instructed to save the layer in the “my places” pane in GE.
Advantages: If they ever lose the layer from GE they can always go back to the web page to call up layers.
Disadvantages: Layers are loaded one-by-one. Updates would require an email sent to users to download the newest layer.
Advanced, dynamic web page: keep the URL calls in a database table (like mapPreview.do), and construct a “pre-launch” web page where the user can select the layers they want to include in a KML which is generated from the DB.
Advantages: As above, but multiple layers can be called at once
Disadvantages: Some work coding the web page and DB. A little confusing to have a pre-launch selection of layers in addition to the GE layers pane. Basic users, remember.
Entertain my thoughts here for a minute. What about coding a feature into Geoserver for a really basic “push-pull” model? I don’t know if this is possible…but use an “index” file/table on the server side to generate multi-layer (multi-feature) KML files based on layers selected by the geoserver admin. The file/table would itself be constant so reference to it wouldn’t change, but its contents (rows in a table or a list of ID’s) would be specify which layers to include in the KML generation. Then it’s simply a matter of adding a KML header, concatenating the code for each layer specified in the request. and then adding the footer. There is already code to generate a single-layer KML, surely this would be possible.
Maybe implement it as a “Namespace SuperLayer” or something, loading all of the layers in a given namespace in a single KML? Similar to the actions of “mapPreview.do” in geoserver admin, just query all of the available layers from a single namespace, execute the KML code generation for each layer, concatenate and serve the resulting KML. This single-click solution could be integrated and launched from a web page or a desktop icon and would load all of the layers currently made available by the admin.
Hi Damian,
not sure how dynamically you need the layer list to be.
If not too dynamic I would say you can just configure a base map in geoserver holding the desired layers, and when you need to add/remove layers from the geoserver configuration and just give the clients a link to the base map, like in http://localhost:8080/geoserver/wms/kml_reflect?layers=spearfish
if that's not an option just tell and we'll see what else could be done.. I can't think of a push model easily though..
Gabriel
Damian_Bradley@anonymised.com escribió:
Hello fellow geoservers,
I am gearing up for deployment of Geoserver in my organization. We are using it mostly to serve Google Earth clients to non-GIS users, and I am curious how others have organized their data distribution models in such a case. I also have an interesting idea for coding a model into geoserver.
With access to the back-end I can obviously update any layers that are already network-linked in client's GE, but what are the options for adding new content/network links to my user's clients? Since there is no way to have a true "push" model, how do you implement a pull strategy?
Ideas:
1. Email List: Either paste geoserver URL's to generate KML or send out a pre-generated KML file via email
Advantages: Full control over KML content.
Disadvantages: No central repository of available layers
2. Simple, static and secure web page with a list of URL's to call specific layers. Users are then instructed to save the layer in the "my places" pane in GE.
Advantages: If they ever lose the layer from GE they can always go back to the web page to call up layers.
Disadvantages: Layers are loaded one-by-one. Updates would require an email sent to users to download the newest layer.
3. Advanced, dynamic web page: keep the URL calls in a database table (like mapPreview.do), and construct a "pre-launch" web page where the user can select the layers they want to include in a KML which is generated from the DB.
Advantages: As above, but multiple layers can be called at once
Disadvantages: Some work coding the web page and DB. A little confusing to have a pre-launch selection of layers in addition to the GE layers pane. Basic users, remember.
4. Entertain my thoughts here for a minute. What about coding a feature into Geoserver for a really basic "push-pull" model? I don't know if this is possible...but use an "index" file/table on the server side to generate multi-layer (multi-feature) KML files based on layers selected by the geoserver admin. The file/table would itself be constant so reference to it wouldn't change, but its contents (rows in a table or a list of ID's) would be specify which layers to include in the KML generation. Then it's simply a matter of adding a KML header, concatenating the code for each layer specified in the request. and then adding the footer. There is already code to generate a single-layer KML, surely this would be possible.
Maybe implement it as a "Namespace SuperLayer" or something, loading all of the layers in a given namespace in a single KML? Similar to the actions of "mapPreview.do" in geoserver admin, just query all of the available layers from a single namespace, execute the KML code generation for each layer, concatenate and serve the resulting KML. This single-click solution could be integrated and launched from a web page or a desktop icon and would load all of the layers currently made available by the admin.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------------------------------------------------
It seems, after some research, that the obvious answer is to take advantage of the Google Earth Plugin API and either reference a server-side KML file or code network links which can be controlled via a webpage/javascript implementation. It would take some work but I think would be easier than trying to interface with a standard GE client…
Subject
Re: [Geoserver-users] (Google Earth) Data distribution model?
Hi Damian, not sure how dynamically you need the layer list to be. If not too dynamic I would say you can just configure a base map in geoserver holding the desired layers, and when you need to add/remove layers from the geoserver configuration and just give the clients a link to the base map, like in http://localhost:8080/geoserver/wms/kml_reflect?layers=spearfish
if that's not an option just tell and we'll see what else could be done.. I can't think of a push model easily though..
Gabriel Damian_Bradley@anonymised.com escribió: > > Hello fellow geoservers, > > I am gearing up for deployment of Geoserver in my organization. We > are using it mostly to serve Google Earth clients to non-GIS users, > and I am curious how others have organized their data distribution > models in such a case. I also have an interesting idea for coding a > model into geoserver. > > With access to the back-end I can obviously update any layers that are > already network-linked in client's GE, but what are the options for > adding new content/network links to my user's clients? Since there is > no way to have a true "push" model, how do you implement a pull > strategy? > > Ideas: > > 1. Email List: Either paste geoserver URL's to generate KML or send > out a pre-generated KML file via email > Advantages: Full control over KML content. > Disadvantages: No central repository of available layers > > 2. Simple, static and secure web page with a list of URL's to call > specific layers. Users are then instructed to save the layer in the > "my places" pane in GE. > Advantages: If they ever lose the layer from GE they can always go > back to the web page to call up layers. > Disadvantages: Layers are loaded one-by-one. Updates would require > an email sent to users to download the newest layer. > > 3. Advanced, dynamic web page: keep the URL calls in a database > table (like mapPreview.do), and construct a "pre-launch" web page > where the user can select the layers they want to include in a KML > which is generated from the DB. > Advantages: As above, but multiple layers can be called at once > Disadvantages: Some work coding the web page and DB. A little > confusing to have a pre-launch selection of layers in addition to the > GE layers pane. Basic users, remember. > > 4. Entertain my thoughts here for a minute. What about coding a > feature into Geoserver for a really basic "push-pull" model? I don't > know if this is possible...but use an "index" file/table on the > server side to generate multi-layer (multi-feature) KML files based on > layers selected by the geoserver admin. The file/table would itself > be constant so reference to it wouldn't change, but its contents (rows > in a table or a list of ID's) would be specify which layers to include > in the KML generation. Then it's simply a matter of adding a KML > header, concatenating the code for each layer specified in the > request. and then adding the footer. There is already code to > generate a single-layer KML, surely this would be possible. > > Maybe implement it as a "Namespace SuperLayer" or something, loading > all of the layers in a given namespace in a single KML? Similar to > the actions of "mapPreview.do" in geoserver admin, just query all of > the available layers from a single namespace, execute the KML code > generation for each layer, concatenate and serve the resulting KML. > This single-click solution could be integrated and launched from a > web page or a desktop icon and would load all of the layers currently > made available by the admin. > > Thoughts? > > Damian Bradley > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > ``http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > ``https://lists.sourceforge.net/lists/listinfo/geoserver-users >
What you've described in this thread is essentially what I'd like to do -
albeit 2 years later. Did you have any luck inserting a networkLink into the
GE API referencing the geoserver KML reflector or did you have to implement
something else?
Thanks in advance.
Damian_Bradley wrote:
Hi Gabriel,
It seems, after some research, that the obvious answer is to take
advantage of the Google Earth Plugin API and either reference a
server-side KML file or code network links which can be controlled via a
webpage/javascript implementation. It would take some work but I think
would be easier than trying to interface with a standard GE client...
Cheers,
Damian
Gabriel Roldan <groldan@anonymised.com>
09/30/2008 09:34 AM
To
Damian_Bradley@anonymised.com
cc
geoserver-users@lists.sourceforge.net
Subject
Re: [Geoserver-users] (Google Earth) Data distribution model?
Hi Damian,
not sure how dynamically you need the layer list to be.
If not too dynamic I would say you can just configure a base map in
geoserver holding the desired layers, and when you need to add/remove
layers from the geoserver configuration and just give the clients a link
to the base map, like in http://localhost:8080/geoserver/wms/kml_reflect?layers=spearfish
if that's not an option just tell and we'll see what else could be
done.. I can't think of a push model easily though..
Gabriel
Damian_Bradley@anonymised.com escribió:
Hello fellow geoservers,
I am gearing up for deployment of Geoserver in my organization. We
are using it mostly to serve Google Earth clients to non-GIS users,
and I am curious how others have organized their data distribution
models in such a case. I also have an interesting idea for coding a
model into geoserver.
With access to the back-end I can obviously update any layers that are
already network-linked in client's GE, but what are the options for
adding new content/network links to my user's clients? Since there is
no way to have a true "push" model, how do you implement a pull
strategy?
Ideas:
1. Email List: Either paste geoserver URL's to generate KML or send
out a pre-generated KML file via email
Advantages: Full control over KML content.
Disadvantages: No central repository of available layers
2. Simple, static and secure web page with a list of URL's to call
specific layers. Users are then instructed to save the layer in the
"my places" pane in GE.
Advantages: If they ever lose the layer from GE they can always go
back to the web page to call up layers.
Disadvantages: Layers are loaded one-by-one. Updates would require
an email sent to users to download the newest layer.
3. Advanced, dynamic web page: keep the URL calls in a database
table (like mapPreview.do), and construct a "pre-launch" web page
where the user can select the layers they want to include in a KML
which is generated from the DB.
Advantages: As above, but multiple layers can be called at once
Disadvantages: Some work coding the web page and DB. A little
confusing to have a pre-launch selection of layers in addition to the
GE layers pane. Basic users, remember.
4. Entertain my thoughts here for a minute. What about coding a
feature into Geoserver for a really basic "push-pull" model? I don't
know if this is possible...but use an "index" file/table on the
server side to generate multi-layer (multi-feature) KML files based on
layers selected by the geoserver admin. The file/table would itself
be constant so reference to it wouldn't change, but its contents (rows
in a table or a list of ID's) would be specify which layers to include
in the KML generation. Then it's simply a matter of adding a KML
header, concatenating the code for each layer specified in the
request. and then adding the footer. There is already code to
generate a single-layer KML, surely this would be possible.
Maybe implement it as a "Namespace SuperLayer" or something, loading
all of the layers in a given namespace in a single KML? Similar to
the actions of "mapPreview.do" in geoserver admin, just query all of
the available layers from a single namespace, execute the KML code
generation for each layer, concatenate and serve the resulting KML.
This single-click solution could be integrated and launched from a
web page or a desktop icon and would load all of the layers currently
made available by the admin.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users