Trying to implement the getfeatureinfo operation using templates i have
run into an issue. I should also state that I am attempting to use the
same template for getfeatureinfo as for kml placemark descriptions.
Currently the template stuff is written to take a single feature or an
entire feature collection to process. Which is nice because in some
cases you want to pass in a single feature ( like with a kml placemark
), and other cases you want to pass in a feature collection ( like with
getfeatureinfo ).
The problem is on the template writers side. If I want to create a
single template for all these different output formats, i don't want to
have to worry about having to check if i was passed a single feature, or
an entire collection.
So... i see a couple of solutions for this problem.
1. Make the user create two templates ( boo )
2. Make the user do the check in the template ( boo hiss )
3. For every type of template we support specify if it takes a single
template or a collection as input ( yay! )
3 makes the most sense to me, and i apologize if i am stating the
obvious. However, #3 has circumstances for the getfeatureinfo operation
if we want to reuse the kml template. Since the kml stuff always takes a
single feature, the default template for it outputs a simple html table
with headings for every single attribute name, and the single row for
the values. Great!!
But lets say a getfeatureinfo operation hits multiple features, directly
applying the same template will produce a table in which the attributes
names are reproduced for each row.. blah!!
Now since the query in the getFeatureInfo op is a single x/y value it
matches a single feature *most* of the time but as we know its pretty
easy to come up with a case where multiple features are matched.
So... unsure how to proceed. Any feedback would be welcomed.
Can you do a three part template?
- header
- result - used to write out each feature
- footer
That way you do not have to care if they are doing more than one feature or not?
Jody
Hi all,
Trying to implement the getfeatureinfo operation using templates i have
run into an issue. I should also state that I am attempting to use the
same template for getfeatureinfo as for kml placemark descriptions.
Currently the template stuff is written to take a single feature or an
entire feature collection to process. Which is nice because in some
cases you want to pass in a single feature ( like with a kml placemark
), and other cases you want to pass in a feature collection ( like with
getfeatureinfo ).
The problem is on the template writers side. If I want to create a
single template for all these different output formats, i don't want to
have to worry about having to check if i was passed a single feature, or
an entire collection.
So... i see a couple of solutions for this problem.
1. Make the user create two templates ( boo )
2. Make the user do the check in the template ( boo hiss )
3. For every type of template we support specify if it takes a single
template or a collection as input ( yay! )
3 makes the most sense to me, and i apologize if i am stating the
obvious. However, #3 has circumstances for the getfeatureinfo operation
if we want to reuse the kml template. Since the kml stuff always takes a
single feature, the default template for it outputs a simple html table
with headings for every single attribute name, and the single row for
the values. Great!!
But lets say a getfeatureinfo operation hits multiple features, directly
applying the same template will produce a table in which the attributes
names are reproduced for each row.. blah!!
Now since the query in the getFeatureInfo op is a single x/y value it
matches a single feature *most* of the time but as we know its pretty
easy to come up with a case where multiple features are matched.
So... unsure how to proceed. Any feedback would be welcomed.
Trying to implement the getfeatureinfo operation using templates i have
run into an issue. I should also state that I am attempting to use the
same template for getfeatureinfo as for kml placemark descriptions.
I am already lost. Why do you need to reuse that template instead
of copying it and adapting it to the realities of GetFeatureInfo?
(more on the different nature later).
As a rule of thumb, templates will fall into user hands, so the
simpler and to the point they are, the better imho (so I agree filling
them with ifs is bad).
But lets say a getfeatureinfo operation hits multiple features, directly
applying the same template will produce a table in which the attributes
names are reproduced for each row.. blah!!
It's harder than that. You'll have to set up multiple tables.
GetFeatureInfo will catch feature from multiple levels, with different
schemas, so I guess you'll want to set up a table for each level.
From the template params point of view, I guess it would be ok to
provide a list of feature collections, each coming from a different
layer. Am I missing anything?
I am already lost. Why do you need to reuse that template instead
of copying it and adapting it to the realities of GetFeatureInfo?
(more on the different nature later).
As a rule of thumb, templates will fall into user hands, so the
simpler and to the point they are, the better imho (so I agree filling
them with ifs is bad).
I meant that I think it would be beneficial to have the user maintain a
single "description template" ( a little blurb of html that describes a
feature ) which could be used for both. But indeed this may not be a
case where that is possible.
But lets say a getfeatureinfo operation hits multiple features, directly
applying the same template will produce a table in which the attributes
names are reproduced for each row.. blah!!
It's harder than that. You'll have to set up multiple tables.
GetFeatureInfo will catch feature from multiple levels, with different
schemas, so I guess you'll want to set up a table for each level.
From the template params point of view, I guess it would be ok to
provide a list of feature collections, each coming from a different
layer. Am I missing anything?
We could do this. I guess the only downside is it gets more complicated
when the user wants to create their own template. Another tradeoff...