FW: [Geoserver-users] Viewer with Geoserver

[Randy_George1]

Hi,

ChrisHomes wrote:

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps in an
ideal world you could also select your min/max scale denominator as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the scale
box from there.

Hmm, I see. I forgot about the sld Min and MaxScaleDenominator which means a
minimum system could just publish administrator defined scale hints by layer
in the getCapabilities request and leave it up to the client to do something
about it if they want. I was concerned about eliminating any prior knowledge
requirement on the client, but just providing the scalehint accessible to
the client through getCapabilities would do the job and that should be an
easy fix. I'll put this into jira

Evidently ESRI WMS actually limits rendering on the server side, at least
that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also limits
rendering in the OWS. I don't know what their server implementation is.

As far as setting layer scalehints with a gui I would think making a uDig
admin configuration utility would complicate GeoServer.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 11:47 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: FW: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Chris Holmes wrote:

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore in a
similar way?

Scale hints can provide two things:
A. Let the administrator declare scale visibility by layer. This helps

with

problems of overwhelming rendering for inappropriate scale views. In my
experiments it has been a problem and I notice that it is a frustration in
using uDig as well. Without prior knowledge of scale appropriate layers

the

client can get tangled up in very long rendering cycles at best and at

worst

blow up the local client altogether.

B. Let the client know what is appropriate. If the getCapabilities request
returns the associated scale hint assigned to a layer the local client can
do something like grey out the layer that is not in zoom view.

Scale hints are scaler so bbox is helpful only in letting you calculate

the

current scale. Autogenerated scalehints are not useful from the overall
bounding box, since the idea is to manipulate visibility at larger scales.
You could work out some way to generate the scale hints from a client by
letting the admin zoom to the desired level and then request the min or

max

scale hint be populated on the server. However, this requires a client

like

uDig be used for administration. I think the easiest approach is just to

add

min and max scale hint textboxes to the config page for a featuretype.
Publish those attributes in the getCapabilities results and then calculate
the zoom scale from furnished BBOX queries which is then compared to the
min/max scale hints. If the current BBOX scale falls within the scale

hints

for the layer it is queried and rendered, otherwise skipped.

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps in an
ideal world you could also select your min/max scale denominator as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the scale
box from there.

Would you mind submitting this as a bug to our tracker?
http://jira.codehaus.org/browse/GEOS If you'd like I'm happy to do it
myself, but if you submit it you'll be automatically notified whenever
there are any comments or progress on the issue.

thanks!

Chris

USGS Atlas uses some scale hints which are implemented in their ESRI OWS.
Note: the ScaleHint element does not use the defined SRS but is calculated
on an estimated pixel size in ground units.

http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/USGS_EDC_National_Atla

s?Service=WMS&Version=1.1.1&Request=GetCapabilities

- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_LARGE_DRAINAGE</Name>
  <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="1814.4917218905402" max="33670.98040621619" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_150</Name>
  <Title>ATLAS_DAMS_150</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-122.7628" miny="25.7603799999997"
maxx="-67.7777800000003" maxy="48.7481800000005" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_075</Name>
  <Title>ATLAS_DAMS_075</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-153.10449" miny="18.1013500000008"
maxx="-66.4879500000006" maxy="61.4155800000008" />
  <ScaleHint min="1814.4917218905402" max="8230.68409929728" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS</Name>
  <Title>ATLAS_DAMS</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="31.426248379135124" max="1814.4917218905402" />
  </Layer>

And does one need to be able to add multiple scale hints? Is that even
possible?

Also, the advice you give here is great, any chance you could write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 10:42 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net; 'Omar Zevallos'
Subject: Re: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Adobe SVG ASV3.03 has problems rendering large datasets. The nice
thing, though, about OWS is that it provides a straightforward seamless
interface to very large data sets (such as your 30000+ polygons). You will
need to limit the number of polygons in small scale views. Here a couple
things you could try:

1. At small scales show points (circles) rather than polygons. I assume

the

polygons are house symbols. Even using points your 30000+ points could
overload the client rendering. This would mean adding another
table/datastore calculating a centroid for each existing polygon.

2. Do not allow polygons or points to render until zoomed in to a

reasonable

level. Unfortunately GeoServer doesn't let you set scale hints yet:
<ScaleHint min="31.426248379135124" max="33670.98040621619" />

So you will have to provide scale visibility on your own server
side. I am hoping that future versions of geoserver will implement the

scale

hints. The problem is what to show at small scales.

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore in a
similar way?

And does one need to be able to add multiple scale hints? Is that even
possible?

Also, the advice you give here is great, any chance you could write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

best regards,

Chris

3. Combine a WMS image/jpeg with WMS image/svg+xml. In other words use the
more or less static WMS jpeg, png etc until zoomed to a certain level and
then switch to image/svg+xml with the necessary event listeners to make it
useful on the client. Note: with very large datastores the time to render
server side is also prohibitive at small scales. (another reason

scalehints

would be helpful)

Since you are using Adobe ASV here is a sample svg interface you might be
interested in seeing:
http://www.web-demographics.com/OWSGeothermal
There are about 6000 Geothermal SMUWells at the Western US zoom level

shown

as point symbols. There are about 50000 Quatenary Faults,
gml:MultiLineString elements, which will not render at the US level of

zoom

without blowing up the ASV rendering on a 512Mb client.

This experimental site uses client side svg for both WMS and WFS. For WMS
the image is embedded as an svg image element with an xlink:href pointing

to

the WMS like this:
     <image id="img" x="-125.0" y="-53.0" width="60.0" height="30.0"

xlink:href="http://onearth.jpl.nasa.gov/wms.cgi?styles=&service=WMS&ServiceN

ame=WMS&request=GetMap&layers=BMNG&format=image/jpeg&srs=EPSG:4326&bbox=-125

,23,-65,53&width=1000&height=500">
     </image>

This allows local Geoserver WFS site layers to overlay selected WMS.

The handy thing about svg (or any declarative xml graphic spec) are
all of the things you can do with event listeners on the client, which is
why the svg export from geoserver WMS is fairly useless(static), as you
pointed out.
I found using the WFS export and then decorating with custom event
capability to be a more flexible approach. You could do the same with the
svg. In both cases you need server side control in addition to geoserver

to

add client capability. I still wonder about injecting event listener
attribution through sld somehow, since listeners could be considered just

a

form of rendering like fill or stroke.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Omar
Zevallos
Sent: Thursday, February 23, 2006 10:41 PM
Cc: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Viewer with Geoserver

Hi there, months ago, I have been looking for a viewer (for Browser) to

show

cadastral data through geoserver. I have tried MapBuilder and Adobe SVG
Viewer.
With MapBuilder I did not continue working because I did not find the way

to

work with events (onclick, mouseover, etc), and I´m working with SVG now,
but I have troubles with overload data, since, I have a layer that

includes

lotes (polygons that draw a house in the map) of all my region (about

30000

rows). I do not know like handling so many data in the browser...

I suppose that one of you has had the same problems, I wish a suggestion
about this...
Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

[Allan_Doyle1]

On Feb 24, 2006, at 14:27, Randy George wrote:

Hi,

ChrisHomes wrote:

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps in an
ideal world you could also select your min/max scale denominator as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the scale
box from there.

Hmm, I see. I forgot about the sld Min and MaxScaleDenominator which means a
minimum system could just publish administrator defined scale hints by layer
in the getCapabilities request and leave it up to the client to do something
about it if they want. I was concerned about eliminating any prior knowledge
requirement on the client, but just providing the scalehint accessible to
the client through getCapabilities would do the job and that should be an
easy fix. I'll put this into jira

Min and MaxScaleDenominator are WMS 1.3 constructs. ScaleHint is a WMS 1.1.1 construct. They are not meant to constrain the server, rather they are meant to indicate to the client that the server might behave differently while rendering a view that falls within the range than it would outside the range.

Evidently ESRI WMS actually limits rendering on the server side, at least
that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also limits
rendering in the OWS. I don't know what their server implementation is.

It's up to the server deployer to decide what to do. The capabilities file was not originally meant to control the server, the server was meant to produce the capabilities based on what it will do. Of course, that's not to say that one could not actually build a WMS that reads a capabilities file and configures itself. That's an interesting idea, and in some sense cascading WMS's probably come closest to being configured by the capabilities of their upstream WMS's.

  Allan

As far as setting layer scalehints with a gui I would think making a uDig
admin configuration utility would complicate GeoServer.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 11:47 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: FW: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Chris Holmes wrote:

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore in a
similar way?

Scale hints can provide two things:
A. Let the administrator declare scale visibility by layer. This helps

with

problems of overwhelming rendering for inappropriate scale views. In my
experiments it has been a problem and I notice that it is a frustration in
using uDig as well. Without prior knowledge of scale appropriate layers

the

client can get tangled up in very long rendering cycles at best and at

worst

blow up the local client altogether.

B. Let the client know what is appropriate. If the getCapabilities request
returns the associated scale hint assigned to a layer the local client can
do something like grey out the layer that is not in zoom view.

Scale hints are scaler so bbox is helpful only in letting you calculate

the

current scale. Autogenerated scalehints are not useful from the overall
bounding box, since the idea is to manipulate visibility at larger scales.
You could work out some way to generate the scale hints from a client by
letting the admin zoom to the desired level and then request the min or

max

scale hint be populated on the server. However, this requires a client

like

uDig be used for administration. I think the easiest approach is just to

add

min and max scale hint textboxes to the config page for a featuretype.
Publish those attributes in the getCapabilities results and then calculate
the zoom scale from furnished BBOX queries which is then compared to the
min/max scale hints. If the current BBOX scale falls within the scale

hints

for the layer it is queried and rendered, otherwise skipped.

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps in an
ideal world you could also select your min/max scale denominator as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the scale
box from there.

Would you mind submitting this as a bug to our tracker?
http://jira.codehaus.org/browse/GEOS If you'd like I'm happy to do it
myself, but if you submit it you'll be automatically notified whenever
there are any comments or progress on the issue.

thanks!

Chris

USGS Atlas uses some scale hints which are implemented in their ESRI OWS.
Note: the ScaleHint element does not use the defined SRS but is calculated
on an estimated pixel size in ground units.

http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/USGS_EDC_National_Atla

s?Service=WMS&Version=1.1.1&Request=GetCapabilities

- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_LARGE_DRAINAGE</Name>
  <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="1814.4917218905402" max="33670.98040621619" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_150</Name>
  <Title>ATLAS_DAMS_150</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-122.7628" miny="25.7603799999997"
maxx="-67.7777800000003" maxy="48.7481800000005" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_075</Name>
  <Title>ATLAS_DAMS_075</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-153.10449" miny="18.1013500000008"
maxx="-66.4879500000006" maxy="61.4155800000008" />
  <ScaleHint min="1814.4917218905402" max="8230.68409929728" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS</Name>
  <Title>ATLAS_DAMS</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="31.426248379135124" max="1814.4917218905402" />
  </Layer>

And does one need to be able to add multiple scale hints? Is that even
possible?

Also, the advice you give here is great, any chance you could write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 10:42 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net; 'Omar Zevallos'
Subject: Re: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

  Adobe SVG ASV3.03 has problems rendering large datasets. The nice
thing, though, about OWS is that it provides a straightforward seamless
interface to very large data sets (such as your 30000+ polygons). You will
need to limit the number of polygons in small scale views. Here a couple
things you could try:

1. At small scales show points (circles) rather than polygons. I assume

the

polygons are house symbols. Even using points your 30000+ points could
overload the client rendering. This would mean adding another
table/datastore calculating a centroid for each existing polygon.

2. Do not allow polygons or points to render until zoomed in to a

reasonable

level. Unfortunately GeoServer doesn't let you set scale hints yet:
<ScaleHint min="31.426248379135124" max="33670.98040621619" />

  So you will have to provide scale visibility on your own server
side. I am hoping that future versions of geoserver will implement the

scale

hints. The problem is what to show at small scales.

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore in a
similar way?

And does one need to be able to add multiple scale hints? Is that even
possible?

Also, the advice you give here is great, any chance you could write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

best regards,

Chris

3. Combine a WMS image/jpeg with WMS image/svg+xml. In other words use the
more or less static WMS jpeg, png etc until zoomed to a certain level and
then switch to image/svg+xml with the necessary event listeners to make it
useful on the client. Note: with very large datastores the time to render
server side is also prohibitive at small scales. (another reason

scalehints

would be helpful)

Since you are using Adobe ASV here is a sample svg interface you might be
interested in seeing:
http://www.web-demographics.com/OWSGeothermal
There are about 6000 Geothermal SMUWells at the Western US zoom level

shown

as point symbols. There are about 50000 Quatenary Faults,
gml:MultiLineString elements, which will not render at the US level of

zoom

without blowing up the ASV rendering on a 512Mb client.

This experimental site uses client side svg for both WMS and WFS. For WMS
the image is embedded as an svg image element with an xlink:href pointing

to

the WMS like this:
     <image id="img" x="-125.0" y="-53.0" width="60.0" height="30.0"

xlink:href="http://onearth.jpl.nasa.gov/wms.cgi?styles=&service=WMS&ServiceN

ame=WMS&request=GetMap&layers=BMNG&format=image/jpeg&srs=EPSG:4326&bbox=-125

,23,-65,53&width=1000&height=500">
     </image>

This allows local Geoserver WFS site layers to overlay selected WMS.

  The handy thing about svg (or any declarative xml graphic spec) are
all of the things you can do with event listeners on the client, which is
why the svg export from geoserver WMS is fairly useless(static), as you
pointed out.
  I found using the WFS export and then decorating with custom event
capability to be a more flexible approach. You could do the same with the
svg. In both cases you need server side control in addition to geoserver

to

add client capability. I still wonder about injecting event listener
attribution through sld somehow, since listeners could be considered just

a

form of rendering like fill or stroke.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Omar
Zevallos
Sent: Thursday, February 23, 2006 10:41 PM
Cc: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Viewer with Geoserver

Hi there, months ago, I have been looking for a viewer (for Browser) to

show

cadastral data through geoserver. I have tried MapBuilder and Adobe SVG
Viewer.
With MapBuilder I did not continue working because I did not find the way

to

work with events (onclick, mouseover, etc), and I´m working with SVG now,
but I have troubles with overload data, since, I have a layer that

includes

lotes (polygons that draw a house in the map) of all my region (about

30000

rows). I do not know like handling so many data in the browser...

I suppose that one of you has had the same problems, I wish a suggestion
about this...
Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Allan Doyle
+1.781.433.2695
adoyle@anonymised.com

[Chris_Holmes1]

Randy George wrote:

> Hi,
>
> ChrisHomes wrote:
>
>> So a scale hint actually should have an effect on the server? I was thinking that it was just a 'recommendation' for clients, but if they really wanted to get the rendering, they should be able to request it? And that if you actually want to _not_ render for a given zoom scale, then you should just use Min and MaxScaleDenominator. That tells the server not to render outside a certain range. This would make it so a client doesn't even have to know about the scale hints... Perhaps in an ideal world you could also select your min/max scale denominator as well as your hint through a gui. They could be the same, or they could be different? If they are present, it might make sense to derive the scale box from there.
>
> Hmm, I see. I forgot about the sld Min and MaxScaleDenominator which means a
> minimum system could just publish administrator defined scale hints by layer
> in the getCapabilities request and leave it up to the client to do something
> about it if they want. I was concerned about eliminating any prior knowledge
> requirement on the client, but just providing the scalehint accessible to
> the client through getCapabilities would do the job and that should be an
> easy fix. I'll put this into jira

Thanks!

>
> Evidently ESRI WMS actually limits rendering on the server side, at least
> that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also limits
> rendering in the OWS. I don't know what their server implementation is.

I believe DEMIS is mapserver based, but I could be wrong. Limiting rendering on the server side is a good thing, and we probably should allow more options for it, or, as Saul pointed out to me, clients could inadvertantly just take up tons of resources and cause a DOS attack.

>
> As far as setting layer scalehints with a gui I would think making a uDig
> admin configuration utility would complicate GeoServer.

Our thoughts on this front are more on the lines of expanding MapBuilder, the ajax client that we already embed, as the config gui. Before we'd thought of it as a nice SLD editor, but that could fairly easily be expanded to min/max scale stuff. But this stuff is pretty far in the future, will take some major resources, which we don't have right now.

I wouldn't mind uDig as some sort of 'studio' application, that allows you to configure GeoServer layers, with a 'publish to geoserver' button. But making it the default configuration would be silly and complicated indeed. We're hoping to redo the config relatively soon, so that a number of different front ends can easily plugin.

Chris

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 11:47 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: FW: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Chris Holmes wrote:

Could you submit this to the task tracker? See: http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more information. It would be really helpful if you could suggest first the minimum needed for this to be useful (like just allow you to fill out the value yourself), and what more could be done on it. Like could there be some sort of 'generate' button similar to the bbox of featureType? Could we derive it from the bounds of the datastore in a similar way?

Scale hints can provide two things:
A. Let the administrator declare scale visibility by layer. This helps

with

problems of overwhelming rendering for inappropriate scale views. In my
experiments it has been a problem and I notice that it is a frustration in
using uDig as well. Without prior knowledge of scale appropriate layers

the

client can get tangled up in very long rendering cycles at best and at

worst

blow up the local client altogether.

B. Let the client know what is appropriate. If the getCapabilities request
returns the associated scale hint assigned to a layer the local client can
do something like grey out the layer that is not in zoom view.

Scale hints are scaler so bbox is helpful only in letting you calculate

the

current scale. Autogenerated scalehints are not useful from the overall
bounding box, since the idea is to manipulate visibility at larger scales.
You could work out some way to generate the scale hints from a client by
letting the admin zoom to the desired level and then request the min or

max

scale hint be populated on the server. However, this requires a client

like

uDig be used for administration. I think the easiest approach is just to

add

min and max scale hint textboxes to the config page for a featuretype.
Publish those attributes in the getCapabilities results and then calculate
the zoom scale from furnished BBOX queries which is then compared to the
min/max scale hints. If the current BBOX scale falls within the scale

hints

for the layer it is queried and rendered, otherwise skipped.

So a scale hint actually should have an effect on the server? I was thinking that it was just a 'recommendation' for clients, but if they really wanted to get the rendering, they should be able to request it? And that if you actually want to _not_ render for a given zoom scale, then you should just use Min and MaxScaleDenominator. That tells the server not to render outside a certain range. This would make it so a client doesn't even have to know about the scale hints... Perhaps in an ideal world you could also select your min/max scale denominator as well as your hint through a gui. They could be the same, or they could be different? If they are present, it might make sense to derive the scale box from there.

Would you mind submitting this as a bug to our tracker? http://jira.codehaus.org/browse/GEOS If you'd like I'm happy to do it myself, but if you submit it you'll be automatically notified whenever there are any comments or progress on the issue.

thanks!

Chris

USGS Atlas uses some scale hints which are implemented in their ESRI OWS.
Note: the ScaleHint element does not use the defined SRS but is calculated
on an estimated pixel size in ground units.

http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/USGS_EDC_National_Atla

s?Service=WMS&Version=1.1.1&Request=GetCapabilities

- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>ATLAS_DAMS_LARGE_DRAINAGE</Name> <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title> <SRS>EPSG:4326</SRS> <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" /> <ScaleHint min="1814.4917218905402" max="33670.98040621619" /> </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>ATLAS_DAMS_150</Name> <Title>ATLAS_DAMS_150</Title> <SRS>EPSG:4326</SRS> <LatLonBoundingBox minx="-122.7628" miny="25.7603799999997"
maxx="-67.7777800000003" maxy="48.7481800000005" /> </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>ATLAS_DAMS_075</Name> <Title>ATLAS_DAMS_075</Title> <SRS>EPSG:4326</SRS> <LatLonBoundingBox minx="-153.10449" miny="18.1013500000008"
maxx="-66.4879500000006" maxy="61.4155800000008" /> <ScaleHint min="1814.4917218905402" max="8230.68409929728" /> </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>ATLAS_DAMS</Name> <Title>ATLAS_DAMS</Title> <SRS>EPSG:4326</SRS> <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" /> <ScaleHint min="31.426248379135124" max="1814.4917218905402" /> </Layer>

And does one need to be able to add multiple scale hints? Is that even possible?

Also, the advice you give here is great, any chance you could write it up as a 'use narrative'? Or if you've blogged about it, you can just give a link to the blog posts. This kind of information is super helpful, and is great when it lives outside of just the mailing list. see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be super informal, just experiences you've had with GeoServer.

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Chris
Holmes
Sent: Friday, February 24, 2006 10:42 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net; 'Omar Zevallos'
Subject: Re: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Adobe SVG ASV3.03 has problems rendering large datasets. The nice
thing, though, about OWS is that it provides a straightforward seamless
interface to very large data sets (such as your 30000+ polygons). You will
need to limit the number of polygons in small scale views. Here a couple
things you could try:

1. At small scales show points (circles) rather than polygons. I assume

the

polygons are house symbols. Even using points your 30000+ points could
overload the client rendering. This would mean adding another
table/datastore calculating a centroid for each existing polygon.

2. Do not allow polygons or points to render until zoomed in to a

reasonable

level. Unfortunately GeoServer doesn't let you set scale hints yet:
<ScaleHint min="31.426248379135124" max="33670.98040621619" />

So you will have to provide scale visibility on your own server
side. I am hoping that future versions of geoserver will implement the

scale

hints. The problem is what to show at small scales.

Could you submit this to the task tracker? See: http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more information. It would be really helpful if you could suggest first the minimum needed for this to be useful (like just allow you to fill out the value yourself), and what more could be done on it. Like could there be some sort of 'generate' button similar to the bbox of featureType? Could we derive it from the bounds of the datastore in a similar way?

And does one need to be able to add multiple scale hints? Is that even possible?

Also, the advice you give here is great, any chance you could write it up as a 'use narrative'? Or if you've blogged about it, you can just give a link to the blog posts. This kind of information is super helpful, and is great when it lives outside of just the mailing list. see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be super informal, just experiences you've had with GeoServer.

best regards,

Chris

3. Combine a WMS image/jpeg with WMS image/svg+xml. In other words use the
more or less static WMS jpeg, png etc until zoomed to a certain level and
then switch to image/svg+xml with the necessary event listeners to make it
useful on the client. Note: with very large datastores the time to render
server side is also prohibitive at small scales. (another reason

scalehints

would be helpful)

Since you are using Adobe ASV here is a sample svg interface you might be
interested in seeing:
http://www.web-demographics.com/OWSGeothermal
There are about 6000 Geothermal SMUWells at the Western US zoom level

shown

as point symbols. There are about 50000 Quatenary Faults,
gml:MultiLineString elements, which will not render at the US level of

zoom

without blowing up the ASV rendering on a 512Mb client.

This experimental site uses client side svg for both WMS and WFS. For WMS
the image is embedded as an svg image element with an xlink:href pointing

to

the WMS like this:
    <image id="img" x="-125.0" y="-53.0" width="60.0" height="30.0"

xlink:href="http://onearth.jpl.nasa.gov/wms.cgi?styles=&service=WMS&ServiceN

ame=WMS&request=GetMap&layers=BMNG&format=image/jpeg&srs=EPSG:4326&bbox=-125

,23,-65,53&width=1000&height=500">
    </image>

This allows local Geoserver WFS site layers to overlay selected WMS.

The handy thing about svg (or any declarative xml graphic spec) are
all of the things you can do with event listeners on the client, which is
why the svg export from geoserver WMS is fairly useless(static), as you
pointed out. I found using the WFS export and then decorating with custom event
capability to be a more flexible approach. You could do the same with the
svg. In both cases you need server side control in addition to geoserver

to

add client capability. I still wonder about injecting event listener
attribution through sld somehow, since listeners could be considered just

a

form of rendering like fill or stroke.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Omar
Zevallos
Sent: Thursday, February 23, 2006 10:41 PM
Cc: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Viewer with Geoserver

Hi there, months ago, I have been looking for a viewer (for Browser) to

show

cadastral data through geoserver. I have tried MapBuilder and Adobe SVG
Viewer.
With MapBuilder I did not continue working because I did not find the way

to

work with events (onclick, mouseover, etc), and I´m working with SVG now,
but I have troubles with overload data, since, I have a layer that

includes

lotes (polygons that draw a house in the map) of all my region (about

30000

rows). I do not know like handling so many data in the browser...

I suppose that one of you has had the same problems, I wish a suggestion
about this...
Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

[Randy_George1]

Hi,

Just to make sure I understand correctly.

The deployer/administrator sets the layer visibility min max in a layer
configuration.

The client can get this information through a getCapabilities request
As ScaleHint for WMS 1.1.1
Or
As Min and MaxScaleDenominator for WMS 1.3

The client can also set Min and MaxScaleDenominator in sld requests to
define a style <Rule> scope.
<xsd:element ref="sld:MinScaleDenominator" minOccurs="0"/>
<xsd:element ref="sld:MaxScaleDenominator" minOccurs="0"/>

A minimum approach to eliminating prior knowledge on the client is:
1. Set min max in the Geoserver featuretype configuration
2. Publish this as ScaleHint for WMS 1.1.1 or Min and MaxScaleDenominator
for WMS 1.3

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Allan
Doyle
Sent: Friday, February 24, 2006 12:35 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Viewer with Geoserver

On Feb 24, 2006, at 14:27, Randy George wrote:

Hi,

ChrisHomes wrote:

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request
it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it
so a
client doesn't even have to know about the scale hints... Perhaps
in an
ideal world you could also select your min/max scale denominator
as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the
scale
box from there.

Hmm, I see. I forgot about the sld Min and MaxScaleDenominator
which means a
minimum system could just publish administrator defined scale hints
by layer
in the getCapabilities request and leave it up to the client to do
something
about it if they want. I was concerned about eliminating any prior
knowledge
requirement on the client, but just providing the scalehint
accessible to
the client through getCapabilities would do the job and that should
be an
easy fix. I'll put this into jira

Min and MaxScaleDenominator are WMS 1.3 constructs. ScaleHint is a
WMS 1.1.1 construct. They are not meant to constrain the server,
rather they are meant to indicate to the client that the server might
behave differently while rendering a view that falls within the range
than it would outside the range.

Evidently ESRI WMS actually limits rendering on the server side, at
least
that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also
limits
rendering in the OWS. I don't know what their server implementation
is.

It's up to the server deployer to decide what to do. The capabilities
file was not originally meant to control the server, the server was
meant to produce the capabilities based on what it will do. Of
course, that's not to say that one could not actually build a WMS
that reads a capabilities file and configures itself. That's an
interesting idea, and in some sense cascading WMS's probably come
closest to being configured by the capabilities of their upstream WMS's.

  Allan

As far as setting layer scalehints with a gui I would think making
a uDig
admin configuration utility would complicate GeoServer.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Chris
Holmes
Sent: Friday, February 24, 2006 11:47 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: FW: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Chris Holmes wrote:

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest
first the
minimum needed for this to be useful (like just allow you to fill
out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore
in a
similar way?

Scale hints can provide two things:
A. Let the administrator declare scale visibility by layer. This
helps

with

problems of overwhelming rendering for inappropriate scale views.
In my
experiments it has been a problem and I notice that it is a
frustration in
using uDig as well. Without prior knowledge of scale appropriate
layers

the

client can get tangled up in very long rendering cycles at best
and at

worst

blow up the local client altogether.

B. Let the client know what is appropriate. If the getCapabilities
request
returns the associated scale hint assigned to a layer the local
client can
do something like grey out the layer that is not in zoom view.

Scale hints are scaler so bbox is helpful only in letting you
calculate

the

current scale. Autogenerated scalehints are not useful from the
overall
bounding box, since the idea is to manipulate visibility at larger
scales.
You could work out some way to generate the scale hints from a
client by
letting the admin zoom to the desired level and then request the
min or

max

scale hint be populated on the server. However, this requires a
client

like

uDig be used for administration. I think the easiest approach is
just to

add

min and max scale hint textboxes to the config page for a
featuretype.
Publish those attributes in the getCapabilities results and then
calculate
the zoom scale from furnished BBOX queries which is then compared
to the
min/max scale hints. If the current BBOX scale falls within the scale

hints

for the layer it is queried and rendered, otherwise skipped.

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps
in an
ideal world you could also select your min/max scale denominator as
well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the
scale
box from there.

Would you mind submitting this as a bug to our tracker?
http://jira.codehaus.org/browse/GEOS If you'd like I'm happy to do it
myself, but if you submit it you'll be automatically notified whenever
there are any comments or progress on the issue.

thanks!

Chris

USGS Atlas uses some scale hints which are implemented in their
ESRI OWS.
Note: the ScaleHint element does not use the defined SRS but is
calculated
on an estimated pixel size in ground units.

http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/
USGS_EDC_National_Atla

s?Service=WMS&Version=1.1.1&Request=GetCapabilities

- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_LARGE_DRAINAGE</Name>
  <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="1814.4917218905402" max="33670.98040621619" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_150</Name>
  <Title>ATLAS_DAMS_150</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-122.7628" miny="25.7603799999997"
maxx="-67.7777800000003" maxy="48.7481800000005" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_075</Name>
  <Title>ATLAS_DAMS_075</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-153.10449" miny="18.1013500000008"
maxx="-66.4879500000006" maxy="61.4155800000008" />
  <ScaleHint min="1814.4917218905402" max="8230.68409929728" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS</Name>
  <Title>ATLAS_DAMS</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="31.426248379135124" max="1814.4917218905402" />
  </Layer>

And does one need to be able to add multiple scale hints? Is
that even
possible?

Also, the advice you give here is great, any chance you could
write it
up as a 'use narrative'? Or if you've blogged about it, you can
just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing
list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It
can be
super informal, just experiences you've had with GeoServer.

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Chris
Holmes
Sent: Friday, February 24, 2006 10:42 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net; 'Omar Zevallos'
Subject: Re: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

  Adobe SVG ASV3.03 has problems rendering large datasets. The nice
thing, though, about OWS is that it provides a straightforward
seamless
interface to very large data sets (such as your 30000+ polygons).
You will
need to limit the number of polygons in small scale views. Here a
couple
things you could try:

1. At small scales show points (circles) rather than polygons. I
assume

the

polygons are house symbols. Even using points your 30000+ points
could
overload the client rendering. This would mean adding another
table/datastore calculating a centroid for each existing polygon.

2. Do not allow polygons or points to render until zoomed in to a

reasonable

level. Unfortunately GeoServer doesn't let you set scale hints yet:
<ScaleHint min="31.426248379135124" max="33670.98040621619" />

  So you will have to provide scale visibility on your own server
side. I am hoping that future versions of geoserver will
implement the

scale

hints. The problem is what to show at small scales.

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest
first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore
in a
similar way?

And does one need to be able to add multiple scale hints? Is that
even
possible?

Also, the advice you give here is great, any chance you could
write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

best regards,

Chris

3. Combine a WMS image/jpeg with WMS image/svg+xml. In other
words use the
more or less static WMS jpeg, png etc until zoomed to a certain
level and
then switch to image/svg+xml with the necessary event listeners
to make it
useful on the client. Note: with very large datastores the time
to render
server side is also prohibitive at small scales. (another reason

scalehints

would be helpful)

Since you are using Adobe ASV here is a sample svg interface you
might be
interested in seeing:
http://www.web-demographics.com/OWSGeothermal
There are about 6000 Geothermal SMUWells at the Western US zoom
level

shown

as point symbols. There are about 50000 Quatenary Faults,
gml:MultiLineString elements, which will not render at the US
level of

zoom

without blowing up the ASV rendering on a 512Mb client.

This experimental site uses client side svg for both WMS and WFS.
For WMS
the image is embedded as an svg image element with an xlink:href
pointing

to

the WMS like this:
     <image id="img" x="-125.0" y="-53.0" width="60.0" height="30.0"

xlink:href="http://onearth.jpl.nasa.gov/wms.cgi?
styles=&service=WMS&ServiceN

ame=WMS&request=GetMap&layers=BMNG&format=image/jpeg&srs=EPSG:
4326&bbox=-125

,23,-65,53&width=1000&height=500">
     </image>

This allows local Geoserver WFS site layers to overlay selected WMS.

  The handy thing about svg (or any declarative xml graphic spec) are
all of the things you can do with event listeners on the client,
which is
why the svg export from geoserver WMS is fairly useless(static),
as you
pointed out.
  I found using the WFS export and then decorating with custom event
capability to be a more flexible approach. You could do the same
with the
svg. In both cases you need server side control in addition to
geoserver

to

add client capability. I still wonder about injecting event listener
attribution through sld somehow, since listeners could be
considered just

a

form of rendering like fill or stroke.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Omar
Zevallos
Sent: Thursday, February 23, 2006 10:41 PM
Cc: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Viewer with Geoserver

Hi there, months ago, I have been looking for a viewer (for
Browser) to

show

cadastral data through geoserver. I have tried MapBuilder and
Adobe SVG
Viewer.
With MapBuilder I did not continue working because I did not find
the way

to

work with events (onclick, mouseover, etc), and I´m working with
SVG now,
but I have troubles with overload data, since, I have a layer that

includes

lotes (polygons that draw a house in the map) of all my region
(about

30000

rows). I do not know like handling so many data in the browser...

I suppose that one of you has had the same problems, I wish a
suggestion
about this...
Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Allan Doyle
+1.781.433.2695
adoyle@anonymised.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Allan_Doyle1]

Humph. I forgot about the SLD part. I'm not well versed in that, so hopefully someone else can confirm that bit.

  Allan

On Feb 24, 2006, at 15:13, Randy George wrote:

Hi,

Just to make sure I understand correctly.

The deployer/administrator sets the layer visibility min max in a layer
configuration.

The client can get this information through a getCapabilities request
As ScaleHint for WMS 1.1.1
Or
As Min and MaxScaleDenominator for WMS 1.3

The client can also set Min and MaxScaleDenominator in sld requests to
define a style <Rule> scope.
<xsd:element ref="sld:MinScaleDenominator" minOccurs="0"/>
<xsd:element ref="sld:MaxScaleDenominator" minOccurs="0"/>

A minimum approach to eliminating prior knowledge on the client is:
1. Set min max in the Geoserver featuretype configuration
2. Publish this as ScaleHint for WMS 1.1.1 or Min and MaxScaleDenominator
for WMS 1.3

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of Allan
Doyle
Sent: Friday, February 24, 2006 12:35 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Viewer with Geoserver

On Feb 24, 2006, at 14:27, Randy George wrote:

Hi,

ChrisHomes wrote:

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request
it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it
so a
client doesn't even have to know about the scale hints... Perhaps
in an
ideal world you could also select your min/max scale denominator
as well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the
scale
box from there.

Hmm, I see. I forgot about the sld Min and MaxScaleDenominator
which means a
minimum system could just publish administrator defined scale hints
by layer
in the getCapabilities request and leave it up to the client to do
something
about it if they want. I was concerned about eliminating any prior
knowledge
requirement on the client, but just providing the scalehint
accessible to
the client through getCapabilities would do the job and that should
be an
easy fix. I'll put this into jira

Min and MaxScaleDenominator are WMS 1.3 constructs. ScaleHint is a
WMS 1.1.1 construct. They are not meant to constrain the server,
rather they are meant to indicate to the client that the server might
behave differently while rendering a view that falls within the range
than it would outside the range.

Evidently ESRI WMS actually limits rendering on the server side, at
least
that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also
limits
rendering in the OWS. I don't know what their server implementation
is.

It's up to the server deployer to decide what to do. The capabilities
file was not originally meant to control the server, the server was
meant to produce the capabilities based on what it will do. Of
course, that's not to say that one could not actually build a WMS
that reads a capabilities file and configures itself. That's an
interesting idea, and in some sense cascading WMS's probably come
closest to being configured by the capabilities of their upstream WMS's.

  Allan

As far as setting layer scalehints with a gui I would think making
a uDig
admin configuration utility would complicate GeoServer.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Chris
Holmes
Sent: Friday, February 24, 2006 11:47 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: FW: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

Chris Holmes wrote:

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest
first the
minimum needed for this to be useful (like just allow you to fill
out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore
in a
similar way?

Scale hints can provide two things:
A. Let the administrator declare scale visibility by layer. This
helps

with

problems of overwhelming rendering for inappropriate scale views.
In my
experiments it has been a problem and I notice that it is a
frustration in
using uDig as well. Without prior knowledge of scale appropriate
layers

the

client can get tangled up in very long rendering cycles at best
and at

worst

blow up the local client altogether.

B. Let the client know what is appropriate. If the getCapabilities
request
returns the associated scale hint assigned to a layer the local
client can
do something like grey out the layer that is not in zoom view.

Scale hints are scaler so bbox is helpful only in letting you
calculate

the

current scale. Autogenerated scalehints are not useful from the
overall
bounding box, since the idea is to manipulate visibility at larger
scales.
You could work out some way to generate the scale hints from a
client by
letting the admin zoom to the desired level and then request the
min or

max

scale hint be populated on the server. However, this requires a
client

like

uDig be used for administration. I think the easiest approach is
just to

add

min and max scale hint textboxes to the config page for a
featuretype.
Publish those attributes in the getCapabilities results and then
calculate
the zoom scale from furnished BBOX queries which is then compared
to the
min/max scale hints. If the current BBOX scale falls within the scale

hints

for the layer it is queried and rendered, otherwise skipped.

So a scale hint actually should have an effect on the server? I was
thinking that it was just a 'recommendation' for clients, but if they
really wanted to get the rendering, they should be able to request it?
And that if you actually want to _not_ render for a given zoom scale,
then you should just use Min and MaxScaleDenominator. That tells the
server not to render outside a certain range. This would make it so a
client doesn't even have to know about the scale hints... Perhaps
in an
ideal world you could also select your min/max scale denominator as
well
as your hint through a gui. They could be the same, or they could be
different? If they are present, it might make sense to derive the
scale
box from there.

Would you mind submitting this as a bug to our tracker?
http://jira.codehaus.org/browse/GEOS If you'd like I'm happy to do it
myself, but if you submit it you'll be automatically notified whenever
there are any comments or progress on the issue.

thanks!

Chris

USGS Atlas uses some scale hints which are implemented in their
ESRI OWS.
Note: the ScaleHint element does not use the defined SRS but is
calculated
on an estimated pixel size in ground units.

http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/
USGS_EDC_National_Atla

s?Service=WMS&Version=1.1.1&Request=GetCapabilities

- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_LARGE_DRAINAGE</Name>
  <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="1814.4917218905402" max="33670.98040621619" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_150</Name>
  <Title>ATLAS_DAMS_150</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-122.7628" miny="25.7603799999997"
maxx="-67.7777800000003" maxy="48.7481800000005" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS_075</Name>
  <Title>ATLAS_DAMS_075</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-153.10449" miny="18.1013500000008"
maxx="-66.4879500000006" maxy="61.4155800000008" />
  <ScaleHint min="1814.4917218905402" max="8230.68409929728" />
  </Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
  <Name>ATLAS_DAMS</Name>
  <Title>ATLAS_DAMS</Title>
  <SRS>EPSG:4326</SRS>
  <LatLonBoundingBox minx="-162.934219894082" miny="18.0160769664877"
maxx="-66.0146106597344" maxy="68.0675886974449" />
  <ScaleHint min="31.426248379135124" max="1814.4917218905402" />
  </Layer>

And does one need to be able to add multiple scale hints? Is
that even
possible?

Also, the advice you give here is great, any chance you could
write it
up as a 'use narrative'? Or if you've blogged about it, you can
just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing
list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It
can be
super informal, just experiences you've had with GeoServer.

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Chris
Holmes
Sent: Friday, February 24, 2006 10:42 AM
To: Randy George
Cc: geoserver-users@lists.sourceforge.net; 'Omar Zevallos'
Subject: Re: [Geoserver-users] Viewer with Geoserver

Randy George wrote:

Hi,

  Adobe SVG ASV3.03 has problems rendering large datasets. The nice
thing, though, about OWS is that it provides a straightforward
seamless
interface to very large data sets (such as your 30000+ polygons).
You will
need to limit the number of polygons in small scale views. Here a
couple
things you could try:

1. At small scales show points (circles) rather than polygons. I
assume

the

polygons are house symbols. Even using points your 30000+ points
could
overload the client rendering. This would mean adding another
table/datastore calculating a centroid for each existing polygon.

2. Do not allow polygons or points to render until zoomed in to a

reasonable

level. Unfortunately GeoServer doesn't let you set scale hints yet:
<ScaleHint min="31.426248379135124" max="33670.98040621619" />

  So you will have to provide scale visibility on your own server
side. I am hoping that future versions of geoserver will
implement the

scale

hints. The problem is what to show at small scales.

Could you submit this to the task tracker? See:
http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more
information. It would be really helpful if you could suggest
first the
minimum needed for this to be useful (like just allow you to fill out
the value yourself), and what more could be done on it. Like could
there be some sort of 'generate' button similar to the bbox of
featureType? Could we derive it from the bounds of the datastore
in a
similar way?

And does one need to be able to add multiple scale hints? Is that
even
possible?

Also, the advice you give here is great, any chance you could
write it
up as a 'use narrative'? Or if you've blogged about it, you can just
give a link to the blog posts. This kind of information is super
helpful, and is great when it lives outside of just the mailing list.
see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative It can be
super informal, just experiences you've had with GeoServer.

best regards,

Chris

3. Combine a WMS image/jpeg with WMS image/svg+xml. In other
words use the
more or less static WMS jpeg, png etc until zoomed to a certain
level and
then switch to image/svg+xml with the necessary event listeners
to make it
useful on the client. Note: with very large datastores the time
to render
server side is also prohibitive at small scales. (another reason

scalehints

would be helpful)

Since you are using Adobe ASV here is a sample svg interface you
might be
interested in seeing:
http://www.web-demographics.com/OWSGeothermal
There are about 6000 Geothermal SMUWells at the Western US zoom
level

shown

as point symbols. There are about 50000 Quatenary Faults,
gml:MultiLineString elements, which will not render at the US
level of

zoom

without blowing up the ASV rendering on a 512Mb client.

This experimental site uses client side svg for both WMS and WFS.
For WMS
the image is embedded as an svg image element with an xlink:href
pointing

to

the WMS like this:
     <image id="img" x="-125.0" y="-53.0" width="60.0" height="30.0"

xlink:href="http://onearth.jpl.nasa.gov/wms.cgi?
styles=&service=WMS&ServiceN

ame=WMS&request=GetMap&layers=BMNG&format=image/jpeg&srs=EPSG:
4326&bbox=-125

,23,-65,53&width=1000&height=500">
     </image>

This allows local Geoserver WFS site layers to overlay selected WMS.

  The handy thing about svg (or any declarative xml graphic spec) are
all of the things you can do with event listeners on the client,
which is
why the svg export from geoserver WMS is fairly useless(static),
as you
pointed out.
  I found using the WFS export and then decorating with custom event
capability to be a more flexible approach. You could do the same
with the
svg. In both cases you need server side control in addition to
geoserver

to

add client capability. I still wonder about injecting event listener
attribution through sld somehow, since listeners could be
considered just

a

form of rendering like fill or stroke.

rkgeorge

-----Original Message-----
From: geoserver-users-admin@lists.sourceforge.net
[mailto:geoserver-users-admin@lists.sourceforge.net] On Behalf Of
Omar
Zevallos
Sent: Thursday, February 23, 2006 10:41 PM
Cc: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Viewer with Geoserver

Hi there, months ago, I have been looking for a viewer (for
Browser) to

show

cadastral data through geoserver. I have tried MapBuilder and
Adobe SVG
Viewer.
With MapBuilder I did not continue working because I did not find
the way

to

work with events (onclick, mouseover, etc), and I´m working with
SVG now,
but I have troubles with overload data, since, I have a layer that

includes

lotes (polygons that draw a house in the map) of all my region
(about

30000

rows). I do not know like handling so many data in the browser...

I suppose that one of you has had the same problems, I wish a
suggestion
about this...
Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Allan Doyle
+1.781.433.2695
adoyle@anonymised.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Allan Doyle
+1.781.433.2695
adoyle@anonymised.com

[Omar_Zevallos]

Hi all, I´m trying to create a view in PostGis that shows center point of
the_geom field, but GeoServer doesnt recognise it. How I must define the
view so that Geoserver cant recognise the geographic field?
I have defined it thus:

CREATE OR REPLACE VIEW Points_provincia AS
SELECT provincia.gid, centroid(provincia.the_geom) AS the_geom,
point(centroid(provincia.the_geom)::box) AS the_geom1, provincia.desprov
   FROM provincia;

Thanks in advance

[Chris_Holmes1]

See: http://docs.codehaus.org/display/GEOSDOC/PostGIS+DataStore the section called: 'PostGIS view as a FeatureType'

Omar Zevallos wrote:

Hi all, I´m trying to create a view in PostGis that shows center point of
the_geom field, but GeoServer doesnt recognise it. How I must define the
view so that Geoserver cant recognise the geographic field?
I have defined it thus:

CREATE OR REPLACE VIEW Points_provincia AS
SELECT provincia.gid, centroid(provincia.the_geom) AS the_geom,
point(centroid(provincia.the_geom)::box) AS the_geom1, provincia.desprov
   FROM provincia;

Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

[Chris_Holmes1]

You'll have to use the batik (non-streaming) renderer, and you'll have to define an SLD file that will put the labelling on, see: http://docs.codehaus.org/display/GEOSDOC/SLD+Intro+Tutorial

Omar Zevallos wrote:

thanks for your answer. excuse that I´m so inquisitive, but I have been all
the day trying to solve this and I see that it was very simple.

How to make to show the description of a point in SVG? my view is thus:

CREATE OR REPLACE VIEW puntos_provincia AS
SELECT provincia.gid AS oid, provincia.gid, provincia.desprov,
centroid(provincia.the_geom) AS the_geom
   FROM provincia;

and when I request
http://localhost:8080/gs1.3rc7/wms?request=GetMap&layers=provincia,puntos_provincia&width=800&height=400&srs=EPSG:32719&styles=provincia,linea_simple&Format=image/svg+xml

draws a map and points, but I would like show the provincia.desprov field.
excuses the annoyances.

----- Original Message ----- From: "Chris Holmes" <cholmes@anonymised.com>
To: "Omar Zevallos" <omzeta@anonymised.com>
Cc: <geoserver-users@lists.sourceforge.net>
Sent: Sunday, February 26, 2006 9:05 PM
Subject: Re: [Geoserver-users] creating a view in PostGis for GeoServer

See: http://docs.codehaus.org/display/GEOSDOC/PostGIS+DataStore the
section called: 'PostGIS view as a FeatureType'

Omar Zevallos wrote:

Hi all, I´m trying to create a view in PostGis that shows center point

of

the_geom field, but GeoServer doesnt recognise it. How I must define the
view so that Geoserver cant recognise the geographic field?
I have defined it thus:

CREATE OR REPLACE VIEW Points_provincia AS
SELECT provincia.gid, centroid(provincia.the_geom) AS the_geom,
point(centroid(provincia.the_geom)::box) AS the_geom1, provincia.desprov
  FROM provincia;

Thanks in advance

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

[Omar_Zevallos]

Hi all, can geoserver to render SVG GZIP documents (svg.gz)?
Regards.

[Brent_Owens1]

I don't believe so. But it would be really easy to implement. There is even a tutorial on how to do it: (http://docs.codehaus.org/display/GEOSDOC/Create+your+own+Output+Format)
The tutorial is geared towards WFS output formats, but it should be easy to translate over to an SVG-GZIP format for getMap requests. All you would have to do is intercept the request type, pass off the rendering to the SVG renderer, and then take the output and zip it up and sent it to the output stream.

Brent Owens
(The Open Planning Project)

Omar Zevallos wrote:

Hi all, can geoserver to render SVG GZIP documents (svg.gz)?
Regards.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Omar_Zevallos]

thanks Brent ....

----- Original Message -----
From: "Brent Owens" <brentowens@anonymised.com>
To: "Omar Zevallos" <omzeta@anonymised.com>
Cc: <geoserver-users@lists.sourceforge.net>
Sent: Tuesday, February 28, 2006 9:32 PM
Subject: Re: [Geoserver-users] SVG gzip

I don't believe so. But it would be really easy to implement. There is
even a tutorial on how to do it:
(http://docs.codehaus.org/display/GEOSDOC/Create+your+own+Output+Format)
The tutorial is geared towards WFS output formats, but it should be easy
to translate over to an SVG-GZIP format for getMap requests. All you
would have to do is intercept the request type, pass off the rendering
to the SVG renderer, and then take the output and zip it up and sent it
to the output stream.

Brent Owens
(The Open Planning Project)

Omar Zevallos wrote:
> Hi all, can geoserver to render SVG GZIP documents (svg.gz)?
> Regards.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

> that extends applications into web and mobile media. Attend the live

webcast

> and join the prime developer group breaking into this new coding

territory!

> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>

[Omar_Zevallos]

Hi group. I would like to know if geoserver renders a reference map, I´m
working with SVG responses.
anyway, there is some approach to create reference maps?
Regards.

[Brent_Owens1]

Mapbuilder does this. It is essentially a single WMS getMap request that saves the image. Then, when the user pans and zooms on the real map, the bounding box on the reference map reflects the position of the bounding box of the real map. So all you have to do is update a box on the reference map each time the user changes the view on the main map.

Brent Owens
(The Open Planning Project)

Omar Zevallos wrote:

Hi group. I would like to know if geoserver renders a reference map, I´m
working with SVG responses.
anyway, there is some approach to create reference maps?
Regards.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users