Re: FW: [Geoserver-users] Viewer with Geoserver

[Chris H. <ch...@op...>]

Randy George wrote:

 > Hi,
 >
 > ChrisHomes wrote:
 >
 >> So a scale hint actually should have an effect on the server?  I was=20
thinking that it was just a 'recommendation' for clients, but if they=20
really wanted to get the rendering, they should be able to request it?=20
And that if you actually want to _not_ render for a given zoom scale,=20
then you should just use Min and MaxScaleDenominator.  That tells the=20
server not to render outside a certain range.  This would make it so a=20
client doesn't even have to know about the scale hints...  Perhaps in an=20
ideal world you could also select your min/max scale denominator as well=20
as your hint through a gui.  They could be the same, or they could be=20
different?  If they are present, it might make sense to derive the scale=20
box from there.
 >
 >
 >
 > Hmm, I see. I forgot about the sld Min and MaxScaleDenominator which=20
means a
 > minimum system could just publish administrator defined scale hints=20
by layer
 > in the getCapabilities request and leave it up to the client to do=20
something
 > about it if they want. I was concerned about eliminating any prior=20
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 le=
ast
 > that is what happens with USGS Atlas and NOAA ENC. DEMIS DCW also limi=
ts
 > 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=20
rendering on the server side is a good thing, and we probably should=20
allow more options for it, or, as Saul pointed out to me, clients could=20
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 u=
Dig
 > admin configuration utility would complicate GeoServer.

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

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

Chris

>=20
>=20
> -----Original Message-----
> From: geo...@li...
> [mailto:geo...@li...] On Behalf Of Chris
> Holmes
> Sent: Friday, February 24, 2006 11:47 AM
> To: Randy George
> Cc: geo...@li...
> Subject: Re: FW: [Geoserver-users] Viewer with Geoserver
>=20
>=20
>=20
> Randy George wrote:
>=20
>>Hi,
>>
>>Chris Holmes wrote:
>>
>>
>>>Could you submit this to the task tracker?  See:=20
>>>http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more=20
>>>information.  It would be really helpful if you could suggest first th=
e=20
>>>minimum needed for this to be useful (like just allow you to fill out=20
>>>the value yourself), and what more could be done on it.  Like could=20
>>>there be some sort of 'generate' button similar to the bbox of=20
>>>featureType?  Could we derive it from the bounds of the datastore in a=
=20
>>>similar way?
>>
>>
>>Scale hints can provide two things:
>>A. Let the administrator declare scale visibility by layer. This helps
>=20
> with
>=20
>>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
>=20
> the
>=20
>>client can get tangled up in very long rendering cycles at best and at
>=20
> worst
>=20
>>blow up the local client altogether.
>>
>>B. Let the client know what is appropriate. If the getCapabilities requ=
est
>>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
>=20
> the
>=20
>>current scale. Autogenerated scalehints are not useful from the overall
>>bounding box, since the idea is to manipulate visibility at larger scal=
es.
>>You could work out some way to generate the scale hints from a client b=
y
>>letting the admin zoom to the desired level and then request the min or
>=20
> max
>=20
>>scale hint be populated on the server. However, this requires a client
>=20
> like
>=20
>>uDig be used for administration. I think the easiest approach is just t=
o
>=20
> add
>=20
>>min and max scale hint textboxes to the config page for a featuretype.
>>Publish those attributes in the getCapabilities results and then calcul=
ate
>>the zoom scale from furnished BBOX queries which is then compared to th=
e
>>min/max scale hints. If the current BBOX scale falls within the scale
>=20
> hints
>=20
>>for the layer it is queried and rendered, otherwise skipped.
>=20
> So a scale hint actually should have an effect on the server?  I was=20
> thinking that it was just a 'recommendation' for clients, but if they=20
> really wanted to get the rendering, they should be able to request it?=20
> And that if you actually want to _not_ render for a given zoom scale,=20
> then you should just use Min and MaxScaleDenominator.  That tells the=20
> server not to render outside a certain range.  This would make it so a=20
> client doesn't even have to know about the scale hints...  Perhaps in a=
n=20
> ideal world you could also select your min/max scale denominator as wel=
l=20
> as your hint through a gui.  They could be the same, or they could be=20
> different?  If they are present, it might make sense to derive the scal=
e=20
> box from there.
>=20
> Would you mind submitting this as a bug to our tracker?=20
> http://jira.codehaus.org/browse/GEOS  If you'd like I'm happy to do it=20
> myself, but if you submit it you'll be automatically notified whenever=20
> there are any comments or progress on the issue.
>=20
> thanks!
>=20
> Chris
>=20
>=20
>=20
>>USGS Atlas uses some scale hints which are implemented in their ESRI OW=
S.
>>Note: the ScaleHint element does not use the defined SRS but is calcula=
ted
>>on an estimated pixel size in ground units.
>>
>>
>=20
> http://ims.cr.usgs.gov/servlet19/com.esri.wms.Esrimap/USGS_EDC_National=
_Atla
>=20
>>s?Service=3DWMS&Version=3D1.1.1&Request=3DGetCapabilities
>>
>>- <Layer queryable=3D"1" opaque=3D"0" noSubsets=3D"0">
>>  <Name>ATLAS_DAMS_LARGE_DRAINAGE</Name>=20
>>  <Title>ATLAS_DAMS_LARGE_DRAINAGE</Title>=20
>>  <SRS>EPSG:4326</SRS>=20
>>  <LatLonBoundingBox minx=3D"-162.934219894082" miny=3D"18.016076966487=
7"
>>maxx=3D"-66.0146106597344" maxy=3D"68.0675886974449" />=20
>>  <ScaleHint min=3D"1814.4917218905402" max=3D"33670.98040621619" />=20
>>  </Layer>
>>- <Layer queryable=3D"1" opaque=3D"0" noSubsets=3D"0">
>>  <Name>ATLAS_DAMS_150</Name>=20
>>  <Title>ATLAS_DAMS_150</Title>=20
>>  <SRS>EPSG:4326</SRS>=20
>>  <LatLonBoundingBox minx=3D"-122.7628" miny=3D"25.7603799999997"
>>maxx=3D"-67.7777800000003" maxy=3D"48.7481800000005" />=20
>>  </Layer>
>>- <Layer queryable=3D"1" opaque=3D"0" noSubsets=3D"0">
>>  <Name>ATLAS_DAMS_075</Name>=20
>>  <Title>ATLAS_DAMS_075</Title>=20
>>  <SRS>EPSG:4326</SRS>=20
>>  <LatLonBoundingBox minx=3D"-153.10449" miny=3D"18.1013500000008"
>>maxx=3D"-66.4879500000006" maxy=3D"61.4155800000008" />=20
>>  <ScaleHint min=3D"1814.4917218905402" max=3D"8230.68409929728" />=20
>>  </Layer>
>>- <Layer queryable=3D"1" opaque=3D"0" noSubsets=3D"0">
>>  <Name>ATLAS_DAMS</Name>=20
>>  <Title>ATLAS_DAMS</Title>=20
>>  <SRS>EPSG:4326</SRS>=20
>>  <LatLonBoundingBox minx=3D"-162.934219894082" miny=3D"18.016076966487=
7"
>>maxx=3D"-66.0146106597344" maxy=3D"68.0675886974449" />=20
>>  <ScaleHint min=3D"31.426248379135124" max=3D"1814.4917218905402" />=20
>>  </Layer>
>>
>>>And does one need to be able to add multiple scale hints?  Is that eve=
n=20
>>>possible?
>>>
>>>Also, the advice you give here is great, any chance you could write it=
=20
>>>up as a 'use narrative'?  Or if you've blogged about it, you can just=20
>>>give a link to the blog posts.  This kind of information is super=20
>>>helpful, and is great when it lives outside of just the mailing list.=20
>>>see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative  It can be=20
>>>super informal, just experiences you've had with GeoServer.
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: geo...@li...
>>[mailto:geo...@li...] On Behalf Of Chris
>>Holmes
>>Sent: Friday, February 24, 2006 10:42 AM
>>To: Randy George
>>Cc: geo...@li...; '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 seamles=
s
>>>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 coup=
le
>>>things you could try:
>>>
>>>1. At small scales show points (circles) rather than polygons. I assum=
e
>>
>>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=3D"31.426248379135124" max=3D"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.=20
>>
>>Could you submit this to the task tracker?  See:=20
>>http://docs.codehaus.org/display/GEOSDOC/Reporting+Issues for more=20
>>information.  It would be really helpful if you could suggest first the=
=20
>>minimum needed for this to be useful (like just allow you to fill out=20
>>the value yourself), and what more could be done on it.  Like could=20
>>there be some sort of 'generate' button similar to the bbox of=20
>>featureType?  Could we derive it from the bounds of the datastore in a=20
>>similar way?
>>
>>And does one need to be able to add multiple scale hints?  Is that even=
=20
>>possible?
>>
>>Also, the advice you give here is great, any chance you could write it=20
>>up as a 'use narrative'?  Or if you've blogged about it, you can just=20
>>give a link to the blog posts.  This kind of information is super=20
>>helpful, and is great when it lives outside of just the mailing list.=20
>>see http://docs.codehaus.org/display/GEOSDOC/Use+Narrative  It can be=20
>>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 mak=
e it
>>>useful on the client. Note: with very large datastores the time to ren=
der
>>>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 point=
ing
>>
>>to
>>
>>
>>>the WMS like this:
>>>     <image id=3D"img" x=3D"-125.0" y=3D"-53.0" width=3D"60.0" height=3D=
"30.0"
>>>
>>
>>
> xlink:href=3D"http://onearth.jpl.nasa.gov/wms.cgi?styles=3D&service=3DW=
MS&ServiceN
>=20
>>
> ame=3DWMS&request=3DGetMap&layers=3DBMNG&format=3Dimage/jpeg&srs=3DEPSG=
:4326&bbox=3D-125
>=20
>>>,23,-65,53&width=3D1000&height=3D500">
>>>     </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 yo=
u
>>>pointed out.=20
>>>	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 geoserv=
er
>>
>>to
>>
>>
>>>add client capability. I still wonder about injecting event listener
>>>attribution through sld somehow, since listeners could be considered j=
ust
>>
>>a
>>
>>
>>>form of rendering like fill or stroke.
>>>
>>>rkgeorge
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: geo...@li...
>>>[mailto:geo...@li...] On Behalf Of Omar
>>>Zevallos
>>>Sent: Thursday, February 23, 2006 10:41 PM
>>>Cc: geo...@li...
>>>Subject: [Geoserver-users] Viewer with Geoserver
>>>
>>>Hi there, months ago, I have been looking for a viewer (for Browser) t=
o
>>
>>show
>>
>>
>>>cadastral data through geoserver. I have tried MapBuilder and Adobe SV=
G
>>>Viewer.
>>>With MapBuilder I did not continue working because I did not find the =
way
>>
>>to
>>
>>
>>>work with events (onclick, mouseover, etc), and I=B4m 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 suggesti=
on
>>>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=3Dk&kid=110944&bid$1720&dat=121642
>>>_______________________________________________
>>>Geoserver-users mailing list
>>>Geo...@li...
>>>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=3Dlnk&kid=110944&bid$1720&dat=1216=
42
>>>_______________________________________________
>>>Geoserver-users mailing list
>>>Geo...@li...
>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
>=20

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