I think we dropped an important use-case (name the geosearch module, oops) when we rewrote the KML regionating code. It relied on the SLD strategy and used a simple start=index&stop=index pagination method.
I've been looking into fixing it today and ran into a number of issues. After speaking to David I also realized that the pagination had no functionality except that it was simpler to implement. (I thought this output form was better than having many tiles, but apparently James prefered tiles over it).
So I propose we drop everything but the sitemap and namespace indexes, and have the network links folders temporarily link to the GeoWebCache tile hierarchy instead?
Depending on what cholmes wants me to work on, I can focus on giving the KML stuff in GeoServer the same functionality / restrictions that GWC operates with. We already have tickets in jira for that.
-Arne
disclaimer: I'm very tired, if you think I missed something trivial, I probably did.
Arne Kepp ha scritto:
I think we dropped an important use-case (name the geosearch module, oops) when we rewrote the KML regionating code. It relied on the SLD strategy and used a simple start=index&stop=index pagination method.
Mumble, how exactly did we break it? I mean, SLD should still drive
the selection of data to be loaded, and start/stop parameters should
be part of the layer query, so I expect them to be honoured as well.
I guess my question really is, did we break it in a fundamental way
(design wise) or are we just talking about a bug waiting to be fixed?
I've been looking into fixing it today and ran into a number of issues. After speaking to David I also realized that the pagination had no functionality except that it was simpler to implement. (I thought this output form was better than having many tiles, but apparently James prefered tiles over it).
So I propose we drop everything but the sitemap and namespace indexes, and have the network links folders temporarily link to the GeoWebCache tile hierarchy instead?
I'm loosing you here. Is there any page I can read that explains what
geosearch is supposed to do?
Cheers
Andrea
Andrea Aime wrote:
Arne Kepp ha scritto:
I think we dropped an important use-case (namely the geosearch module, oops) when we rewrote the KML regionating code. It relied on the SLD strategy and used a simple start=index&stop=index pagination method.
Mumble, how exactly did we break it? I mean, SLD should still drive
the selection of data to be loaded, and start/stop parameters should
be part of the layer query, so I expect them to be honoured as well.
I guess my question really is, did we break it in a fundamental way
(design wise) or are we just talking about a bug waiting to be fixed?
I'm not super familiar with how the code used to look or work, but I believe it just asked for what data the SLD strategy would return for the layer bounds (everything) and then added the range of feature ids for each page. So the regionating code just got bypassed, it passes the pagination parameter along without considering it.
Since then I believe we have gotten a lot more tile centric. For instance, if the layer covers both hemispheres, the tile calculated will have z = -1 and the following code will crash. Just expanding that to two tiles may make for a chunk of data that is twice as big as the other ones. Furthermore, I'm not sure how to communicate I want the next 100 features, what tile do I go to? I looked for a way to say "give me a tile with 999999999999999999 features, and pass along these extra parameters", but it wasn't obvious to me where to do it.
If there's not an easy bypass that I have missed, I think fixing this will quickly lead to implementing the KML hierarchy in GeoServer.
I've been looking into fixing it today and ran into a number of issues. After speaking to David I also realized that the pagination had no functionality except that it was simpler to implement. (I thought this output form was better than having many tiles, but apparently James prefered tiles over it).
So I propose we drop everything but the sitemap and namespace indexes, and have the network links folders temporarily link to the GeoWebCache tile hierarchy instead?
I'm loosing you here. Is there any page I can read that explains what
geosearch is supposed to do?
I believe these were details discussed in meetings with Google, but didn't really make it to paper / wiki (I could be completely wrong about that). Chris did write up a lot of stuff here: http://geoserver.org/display/GEOS/Exposing+to+Geo+Search
Again, I don't feel like I have a complete overview, so feel free to correct violently
-Arne
Well, I think right now Google's crawler doesn't successfully navigate regionated hierarchies. Maybe that's changed since we started, but the original reason to do the pagination was because they didn't handle that. They said that it would be their preferred way to crawl, and we agreed, but we need to be crawled right away, not wait for them to implement it.
But since tiles do just consist of more links to tiles then maybe it will work? I'd say try it out, see if a big dataset gets crawled all the way down.
Chris
Arne Kepp wrote:
I think we dropped an important use-case (name the geosearch module, oops) when we rewrote the KML regionating code. It relied on the SLD strategy and used a simple start=index&stop=index pagination method.
I've been looking into fixing it today and ran into a number of issues. After speaking to David I also realized that the pagination had no functionality except that it was simpler to implement. (I thought this output form was better than having many tiles, but apparently James prefered tiles over it).
So I propose we drop everything but the sitemap and namespace indexes, and have the network links folders temporarily link to the GeoWebCache tile hierarchy instead?
Depending on what cholmes wants me to work on, I can focus on giving the KML stuff in GeoServer the same functionality / restrictions that GWC operates with. We already have tickets in jira for that.
-Arne
disclaimer: I'm very tired, if you think I missed something trivial, I probably did.
!DSPAM:4005,488e3eef210452090977483!