[Geoserver-users] Additional WMS GetFeatureInfo questions

Hi Matthew,

Maybe this is out of the discussion but...

Have you considered using WFS? I am using WMS to present the layers
and WFS to get the details when the user click. With WFS you will be
able to:

-Set the buffer, tolerance of the click by units of measurement.
-Get the data in XML and trasnform it to any other format like HTML.
-Decide how many features you want to get when the user click and
there are several features behind a point. You can decide to get them
all, to get only one, etc...
-Decide the data, properties, that you want the server to return to you.

And many more things...

Javier.

On 16/06/2006, at 0:11, Matthew Perry wrote:

While we're at it, I have two additional question for the list
regarding GetFeatureInfo requests:

* Is there a way, other than recompiling the servlet, to adjust the
html layout of the output? Some configuration file perhaps?

* Is there a way to support info on multiple features at the same XY?
My initial experience says that only one feature is returned when
there may be many features at the query point.

Thanks,

Matthew Perry

On 6/15/06, Ralph Buchfelder <Ralph.Buchfelder@anonymised.com> wrote:
QUESTION 1:
how is your X and Y parameter set/pixel coordinate system implemented?
0,0 in the upper left corner?

QUESTION 2:
where can i configure the "snapping" for focussing getFeatureInfo in
server administration?
i.e. adjust the snapping tolerance in pixel?

QUESTION 3:
why does parameter I and J according to OGC WMS Specs
(http://portal.opengeospatial.org/files/?artifact_id=14416)
return an error?

--
Matt Perry
perrygeo@anonymised.com
http://www.perrygeo.net

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

Javier,

  Based on what you and Chris Holmes have said, yes, I am defintely
going the WFS GetFeature route.

My plan is to write an AJAX interface that will route the WFS request
through a jsp page which will also serve as a proxy for external WFS
requests. I'll transform it to html server-side and send it back to
the browser.

  Still, coming from a long history with mapserver, I am frustrated at
the amount of work it takes to simply query the data. With mapserver,
the concept of query templates are key, allowing you to create custom
html layouts that are populated by query results from the vector
attribute tables. It literally takes 3 minutes to accomplish.
Customizing my javascript to do a WFS request and transforming the GML
into HTML is a cumbersome process but apparently quite necessary.

As I am quite new to XSLT, does anyone have an example of transforming
WFS/GML into a tabular HTML layout?

- matt

On 6/16/06, Javier de la Torre <jatorre@anonymised.com> wrote:

Have you considered using WFS? I am using WMS to present the layers
and WFS to get the details when the user click. With WFS you will be
able to:

-Set the buffer, tolerance of the click by units of measurement.
-Get the data in XML and trasnform it to any other format like HTML.
-Decide how many features you want to get when the user click and
there are several features behind a point. You can decide to get them
all, to get only one, etc...
-Decide the data, properties, that you want the server to return to you.

--
Matt Perry
perrygeo@anonymised.com
http://www.perrygeo.net

Matthew Perry wrote:

My plan is to write an AJAX interface that will route the WFS request
through a jsp page which will also serve as a proxy for external WFS
requests. I'll transform it to html server-side and send it back to
the browser.

Matthew,

Not sure if anyone's pointed you in this direction yet, but there's a *great* and very powerful AJAX javascript framework for taking XML and translating in via XSLT into web mapping clients, called "community mapbuilder". You can find out more at http://www.communitymapbuilder.org, but here's an example of an all WMS, all WFS application running with no JSP's, no servlets and so server-side code (well, very very little server-side code...a little PHP proxy script to get around JS http host-connection limitations):

http://maps.massgis.state.ma.us/~sfarber/setb/

It's all javascript and WMS/WFS.

--saul

Saul

On 6/16/06, Saul Farber <Saul.Farber@anonymised.com> wrote:

Matthew Perry wrote:
> My plan is to write an AJAX interface that will route the WFS request
> through a jsp page which will also serve as a proxy for external WFS
> requests. I'll transform it to html server-side and send it back to
> the browser.

Matthew,

Not sure if anyone's pointed you in this direction yet, but there's a
*great* and very powerful AJAX javascript framework for taking XML and
translating in via XSLT into web mapping clients, called "community
mapbuilder". You can find out more at
http://www.communitymapbuilder.org, but here's an example of an all WMS,
all WFS application running with no JSP's, no servlets and so
server-side code (well, very very little server-side code...a little PHP
proxy script to get around JS http host-connection limitations):

http://maps.massgis.state.ma.us/~sfarber/setb/

It's all javascript and WMS/WFS.

Yes I have checked out Mapbuilder and have been using it for various
projects over the last year. It is nice for some things but this
current project I'm working on is using an OpenLayers interface and I
am trying to avoid relying on client-side XSLT due to the potentially
large amount of data transfer involved.

In addition, our web servers will likely be running on a different
server than our geoserver instance making it impossible, due to
javascript security, to make ajax requests. So we'll have to use a
proxy anyways.. why not do the transform server side and save some
bandwidth and client-side processing.
--
Matt Perry
perrygeo@anonymised.com
http://www.perrygeo.net

Hi Matt,

  Thanks, I liked your synopsis on Where 2.0. Wish I could have been
there.
  
  What's your take on GeoServer vs Mapnik/MapServer?

randy

-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net
[mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of Matthew
Perry
Sent: Sunday, June 18, 2006 8:03 PM
To: Saul Farber
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Additional WMS GetFeatureInfo questions

Saul

On 6/16/06, Saul Farber <Saul.Farber@anonymised.com> wrote:

Matthew Perry wrote:
> My plan is to write an AJAX interface that will route the WFS request
> through a jsp page which will also serve as a proxy for external WFS
> requests. I'll transform it to html server-side and send it back to
> the browser.

Matthew,

Not sure if anyone's pointed you in this direction yet, but there's a
*great* and very powerful AJAX javascript framework for taking XML and
translating in via XSLT into web mapping clients, called "community
mapbuilder". You can find out more at
http://www.communitymapbuilder.org, but here's an example of an all WMS,
all WFS application running with no JSP's, no servlets and so
server-side code (well, very very little server-side code...a little PHP
proxy script to get around JS http host-connection limitations):

http://maps.massgis.state.ma.us/~sfarber/setb/

It's all javascript and WMS/WFS.

Yes I have checked out Mapbuilder and have been using it for various
projects over the last year. It is nice for some things but this
current project I'm working on is using an OpenLayers interface and I
am trying to avoid relying on client-side XSLT due to the potentially
large amount of data transfer involved.

In addition, our web servers will likely be running on a different
server than our geoserver instance making it impossible, due to
javascript security, to make ajax requests. So we'll have to use a
proxy anyways.. why not do the transform server side and save some
bandwidth and client-side processing.
--
Matt Perry
perrygeo@anonymised.com
http://www.perrygeo.net

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

Hi matt,

My plan is to write an AJAX interface that will route the WFS request
through a jsp page which will also serve as a proxy for external WFS
requests. I'll transform it to html server-side and send it back to
the browser.

Yes, this is what I am doing in a Google Maps interface I am working on.

Still, coming from a long history with mapserver, I am frustrated at
the amount of work it takes to simply query the data. With mapserver,
the concept of query templates are key, allowing you to create custom
html layouts that are populated by query results from the vector
attribute tables. It literally takes 3 minutes to accomplish.
Customizing my javascript to do a WFS request and transforming the GML
into HTML is a cumbersome process but apparently quite necessary.

Yes, I understand your frustration. I also had the same issues at the beginning. I also think that the popularization of services API, like the ones google i creating, had changed a little bit the service paradigm. A convenient API like Google Maps make programmers life much easier than standard protocols, but does not help in opening a market like OGC standards are doing.
I also have the impression that OGC standards where not created with the "web2.0" ideas in mind.

As I am quite new to XSLT, does anyone have an example of transforming
WFS/GML into a tabular HTML layout?

If you pretend to do transformations on the client using Javascript be careful, this is really slow and some users might have problems with it. You can do it on the server or you can parse the XML in the client taking little pieces of the XML without having to transform it using XSLT.

It would be cool if you could send to a WFS server the location of an XLST file that must be used to processed the data from a WFS request before sending it back. In this way you could create an XSLT that transform your GML app schema into geoRSS or something similar and integrate it with other applications that do not support OGC standards but that support opening a file from a URL (the WFS request).

But as you see this kind of request somehow do not "respect" the WFS standard, it was not intended to be used like this... It is a little bit like the KML reflector that geoserver has now, is hacking around the standards.

Javier.

Javier de la Torre wrote:

Hi matt,

My plan is to write an AJAX interface that will route the WFS request
through a jsp page which will also serve as a proxy for external WFS
requests. I'll transform it to html server-side and send it back to
the browser.

Yes, this is what I am doing in a Google Maps interface I am working on.

Still, coming from a long history with mapserver, I am frustrated at
the amount of work it takes to simply query the data. With mapserver,
the concept of query templates are key, allowing you to create custom
html layouts that are populated by query results from the vector
attribute tables. It literally takes 3 minutes to accomplish.
Customizing my javascript to do a WFS request and transforming the GML
into HTML is a cumbersome process but apparently quite necessary.

Yes, I understand your frustration. I also had the same issues at the beginning. I also think that the popularization of services API, like the ones google i creating, had changed a little bit the service paradigm. A convenient API like Google Maps make programmers life much easier than standard protocols, but does not help in opening a market like OGC standards are doing.
I also have the impression that OGC standards where not created with the "web2.0" ideas in mind.

As I am quite new to XSLT, does anyone have an example of transforming
WFS/GML into a tabular HTML layout?

If you pretend to do transformations on the client using Javascript be careful, this is really slow and some users might have problems with it. You can do it on the server or you can parse the XML in the client taking little pieces of the XML without having to transform it using XSLT.

It would be cool if you could send to a WFS server the location of an XLST file that must be used to processed the data from a WFS request before sending it back. In this way you could create an XSLT that transform your GML app schema into geoRSS or something similar and integrate it with other applications that do not support OGC standards but that support opening a file from a URL (the WFS request).

Well, for GeoRSS in particular I'm actually working on having it as an output format for WFS. The WFS spec is nice in that it has a lot of flexibility for how it outputs things. But yes, there are limits, I would probably draw the line at html templates, though I could see it being possible.

But in general I like your idea a lot. The main design goal of GeoServer 1.4 is actually to make it much easier to build services on top of the core OGC services. An XSLT/html output service on top of WFS would be a great plug-in that one could do. I would love to have it as easy as MapServer to customize an html template. Though I'd _much_ prefer to do it with the WFS spec, as WMS GetFeatureInfo just isn't as powerful.

But as you see this kind of request somehow do not "respect" the WFS standard, it was not intended to be used like this... It is a little bit like the KML reflector that geoserver has now, is hacking around the standards.

Yes, I'm all for hacking around the standards, but using them as a base. And who knows, eventually some of what we do around the standards might be rolled back in to the main spec.

Chris

Javier.

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

!DSPAM:1003,44980569203632081064789!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Hi Chris,

Well, for GeoRSS in particular I'm actually working on having it as an output format for WFS. The WFS spec is nice in that it has a lot of flexibility for how it outputs things. But yes, there are limits, I would probably draw the line at html templates, though I could see it being possible.

Right, I did not take in consideration that WFS does not force you to use GML as the outputFormat.

But in general I like your idea a lot. The main design goal of GeoServer 1.4 is actually to make it much easier to build services on top of the core OGC services. An XSLT/html output service on top of WFS would be a great plug-in that one could do. I would love to have it as easy as MapServer to customize an html template. Though I'd _much_ prefer to do it with the WFS spec, as WMS GetFeatureInfo just isn't as powerful.

This is what we are doing in this protocol I have been working on. In the request header you have two optional parameters:

xslt: is the url of the xslt that must be used

xslt-apply: a boolean indicating if the server must process the data, if set to false then the server must just include the xslt instruction in the result xml, for example Internet explorer would transform the XML is he finds this instruction (in mozilla it does not work).

So, he goes a proposal... maybe for WFS 2.0? jeje. A WFS request, in its XML form would look like:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="GML2" xslt="http://url_to_my_xslt" xslt-apply="1">
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Both parameters are optional and xslt-apply is default to true in case xslt is specified and xslt-apply is not.

Of course some errors must be specified in the standard... and probably implementations will have to prevent themselves of attacks of self recursive xslts that would crash the server, a timeout for processing or something like this should be considered.

Regarding WMS GetFeatureInfo I dot not understand it well,It was created before WFS was invented I suppose. But there is something that you can do with GetFeatureInfo and that you can not do with WFS, requesting info by pixels on a generated map, this is not possible to do in WFS I believe.

JAvi.

Javier de la Torre wrote:

Hi Chris,

Well, for GeoRSS in particular I'm actually working on having it as an output format for WFS. The WFS spec is nice in that it has a lot of flexibility for how it outputs things. But yes, there are limits, I would probably draw the line at html templates, though I could see it being possible.

Right, I did not take in consideration that WFS does not force you to use GML as the outputFormat.

But in general I like your idea a lot. The main design goal of GeoServer 1.4 is actually to make it much easier to build services on top of the core OGC services. An XSLT/html output service on top of WFS would be a great plug-in that one could do. I would love to have it as easy as MapServer to customize an html template. Though I'd _much_ prefer to do it with the WFS spec, as WMS GetFeatureInfo just isn't as powerful.

This is what we are doing in this protocol I have been working on. In the request header you have two optional parameters:

xslt: is the url of the xslt that must be used

xslt-apply: a boolean indicating if the server must process the data, if set to false then the server must just include the xslt instruction in the result xml, for example Internet explorer would transform the XML is he finds this instruction (in mozilla it does not work).

So, he goes a proposal... maybe for WFS 2.0? jeje. A WFS request, in its XML form would look like:

<wfs:GetFeature service="WFS" version="1.0.0"
  outputFormat="GML2" xslt="http://url_to_my_xslt" xslt-apply="1">
  <wfs:Query typeName="topp:states">
    <ogc:Filter>
       <ogc:FeatureId fid="states.3"/>
    </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>

Both parameters are optional and xslt-apply is default to true in case xslt is specified and xslt-apply is not.

Of course some errors must be specified in the standard... and probably implementations will have to prevent themselves of attacks of self recursive xslts that would crash the server, a timeout for processing or something like this should be considered.

Yeah, timeout would probably be key, definitely allowing xslt opens up some potential for DoS attacks. I'm not sure if the WFS people would really like such a thing in their spec. But I'd be very interested in having this ability in GeoServer, as a plug-in on top of the main WFS service. See: http://docs.codehaus.org/display/GEOSDEV/3+Programmers+Guide for some more info about making plug-ins. It could be bundled as it's own service, and extend the GetFeature operation to handle the additional params.

Would be cool if we could also have more 'traditional' templates, that one could add on the config side and just reference the name instead of sending the xslt.

Regarding WMS GetFeatureInfo I dot not understand it well,It was created before WFS was invented I suppose. But there is something that you can do with GetFeatureInfo and that you can not do with WFS, requesting info by pixels on a generated map, this is not possible to do in WFS I believe.

Interesting. Yeah, I suppose that would be one advantage.

Chris

JAvi.

!DSPAM:1003,44980b9c208041425493344!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org