[Geoserver-users] vector pyramids

I had just sent an email on the OL ml about a midnight question, when
I've seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of "runtime simplification"
on the base of the zoom level, something the pyramids concept with
rasters...

Is this something that will be featured inside Geoserver?

Giovanni

Ciao Giovanni,

this is a hard call for WFS because of two reasons. Firts, there's no such concept as zoom level in WFS. For a zoom level calculation you need both the data extent and the output device dimensions (width, height, DPI). Note the pyramids concept for raster, if I'm not wrong, only applies to WMS where you do have a requested map dimension to calculate a zoom level with.
The other reason is more of a separation of concerns one. WFS is about getting to the raw data and has no concept of calculated fields. Ie, you can apply a function to the query predicate but not to the subject properties to return (eg, can't do a sort of "select simplify(geom, factor) from featureType" but just "select geom from FeatureType where simplify(geom, factor)....")
That would be the job of a WPS (Web Processing Server) if I get it rigth.
That said, I'm not sure what your exact use case is, if its just about getting simplified geometries to reduce output size cause you just want to display them in a map, or a matter of volume for data processing. If the later, I wonder if paging would alleviate the problem, since GeoServer supports paging for certain backends.

Regards,

Gabriel

G. Allegri escribió:

I had just sent an email on the OL ml about a midnight question, when
I've seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of "runtime simplification"
on the base of the zoom level, something the pyramids concept with
rasters...

Is this something that will be featured inside Geoserver?

Giovanni

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
  

G. Allegri ha scritto:

I had just sent an email on the OL ml about a midnight question, when
I've seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of "runtime simplification"
on the base of the zoom level, something the pyramids concept with
rasters...

Adding just some bits over Gabriel response. WFS is indeed not
meant to compute fields that are not there, or to alter existing
ones. Yet, not even the vector super overlay code works that way,
it does not simplify geometries, just "allocates" them into a
pyramid of tiles, basically the algorithm has a way to determine
the most important featueres falling into a tile, and allocates
N into the topmost tile, then allocates N into the 4 lower tiles
that haven't already been allocated in the upper ones, and so on,
in a way that makes the most important features available first.
The allocation does not need any zoom info, the extraction neither,
since it assumes the Google Earth client behaviour, that explicitly
requires tile number x,y,z using a custom protocol (I believe)
that's getting translated into an equivalent WMS call.
Humm... that could be done the same way with WFS if we make the x,y,z
indication a custom filter function, something like:
featureInTile(feature, x, y, z) = true

However, I'm digressing. Maybe you should explain a little more
your specific use case. The WFS protocol per se does not offer
anything, even paging is our custom extension (will be introduced
officially in a future version of WFS, and the protocol would be
different as far as I know), so if you "own" the client you
can try out custom solutions, otherwise, not.

Is this something that will be featured inside Geoserver?

If what you need is a mix between simplification and filtering
I guess you need WPS. We have a WPS module made by Refractions
in the community section, so far I haven't found the time to
look into it, but it seems the right fit for your needs?

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Thanks everyone. I admit my need were not clear enough... Probably, as
Andrea says, it's a mix of simplification and feature
extraction/ranking. I know that the WFS protocol doesn't consider this
kind of things, but I was just wondering if someone had ever developed
modules/libraries/etc to be used in a customized WFS request. I'm
building the client over OL,. so I could manage it somehow.
The WPS could ideally a solution, but it's a too long chain for fast
interactions (wheel zoomin, brownian zoomin, etc.).

I'll convince the customer about the problem, and I will propose a
more classical solution: WMS until a certain resolution, and then
WFS...

I'll let you know if I will experiment strange solutions :slight_smile:

2008/9/18 Andrea Aime <aaime@anonymised.com>:

G. Allegri ha scritto:

I had just sent an email on the OL ml about a midnight question, when
I've seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of "runtime simplification"
on the base of the zoom level, something the pyramids concept with
rasters...

Adding just some bits over Gabriel response. WFS is indeed not
meant to compute fields that are not there, or to alter existing
ones. Yet, not even the vector super overlay code works that way,
it does not simplify geometries, just "allocates" them into a
pyramid of tiles, basically the algorithm has a way to determine
the most important featueres falling into a tile, and allocates
N into the topmost tile, then allocates N into the 4 lower tiles
that haven't already been allocated in the upper ones, and so on,
in a way that makes the most important features available first.
The allocation does not need any zoom info, the extraction neither,
since it assumes the Google Earth client behaviour, that explicitly
requires tile number x,y,z using a custom protocol (I believe)
that's getting translated into an equivalent WMS call.
Humm... that could be done the same way with WFS if we make the x,y,z
indication a custom filter function, something like:
featureInTile(feature, x, y, z) = true

However, I'm digressing. Maybe you should explain a little more
your specific use case. The WFS protocol per se does not offer
anything, even paging is our custom extension (will be introduced
officially in a future version of WFS, and the protocol would be
different as far as I know), so if you "own" the client you
can try out custom solutions, otherwise, not.

Is this something that will be featured inside Geoserver?

If what you need is a mix between simplification and filtering
I guess you need WPS. We have a WPS module made by Refractions
in the community section, so far I haven't found the time to
look into it, but it seems the right fit for your needs?

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea and G.Allegri:

I’m very interested in hearing where you end up going with this. What you describe is known, in academia, as a multi-resolution database, and is at the heart of my PhD dissertation research.

As far as I know, every MRDB created so far uses a custom protocol if it works in a client/server model. Theodor Foerster recently presented his PhD research towards creating a WPS for automated generalization. You can view his presentation at:

http://www.nottingham.ac.uk/~cczrmg/accordent/pmzcc1/20080616-141916-IH01/msh.htm

I am currently exploring automated generalization in the client. One of the fundamental problems with generalization is that topology errors conflate when you combine datasets. You can resolve topology errors if all the datasets are generalized and stored together. But if you ‘mash-up’ data from more than one WFS, topology conflation errors can only be resolved in the client.

-Eric

On Thu, Sep 18, 2008 at 3:14 AM, G. Allegri <giohappy@anonymised.com> wrote:

Thanks everyone. I admit my need were not clear enough… Probably, as
Andrea says, it’s a mix of simplification and feature
extraction/ranking. I know that the WFS protocol doesn’t consider this
kind of things, but I was just wondering if someone had ever developed
modules/libraries/etc to be used in a customized WFS request. I’m
building the client over OL,. so I could manage it somehow.
The WPS could ideally a solution, but it’s a too long chain for fast
interactions (wheel zoomin, brownian zoomin, etc.).

I’ll convince the customer about the problem, and I will propose a
more classical solution: WMS until a certain resolution, and then
WFS…

I’ll let you know if I will experiment strange solutions :slight_smile:

2008/9/18 Andrea Aime <aaime@anonymised.com>:

G. Allegri ha scritto:

I had just sent an email on the OL ml about a midnight question, when
I’ve seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of “runtime simplification”
on the base of the zoom level, something the pyramids concept with
rasters…

Adding just some bits over Gabriel response. WFS is indeed not
meant to compute fields that are not there, or to alter existing
ones. Yet, not even the vector super overlay code works that way,
it does not simplify geometries, just “allocates” them into a
pyramid of tiles, basically the algorithm has a way to determine
the most important featueres falling into a tile, and allocates
N into the topmost tile, then allocates N into the 4 lower tiles
that haven’t already been allocated in the upper ones, and so on,
in a way that makes the most important features available first.
The allocation does not need any zoom info, the extraction neither,
since it assumes the Google Earth client behaviour, that explicitly
requires tile number x,y,z using a custom protocol (I believe)
that’s getting translated into an equivalent WMS call.
Humm… that could be done the same way with WFS if we make the x,y,z
indication a custom filter function, something like:
featureInTile(feature, x, y, z) = true

However, I’m digressing. Maybe you should explain a little more
your specific use case. The WFS protocol per se does not offer
anything, even paging is our custom extension (will be introduced
officially in a future version of WFS, and the protocol would be
different as far as I know), so if you “own” the client you
can try out custom solutions, otherwise, not.

Is this something that will be featured inside Geoserver?

If what you need is a mix between simplification and filtering
I guess you need WPS. We have a WPS module made by Refractions
in the community section, so far I haven’t found the time to
look into it, but it seems the right fit for your needs?


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


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


-=–=—=----=----=—=–=-=–=—=----=—=–=-=-
Eric B. Wolf 720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography

Andrea and G.Allegri:

I’m very interested in hearing where you end up going with this. What you describe is known, in academia, as a multi-resolution database, and is at the heart of my PhD dissertation research.

As far as I know, every MRDB created so far uses a custom protocol if it works in a client/server model. Theodor Foerster recently presented his PhD research towards creating a WPS for automated generalization. You can view his presentation at:

http://www.nottingham.ac.uk/~cczrmg/accordent/pmzcc1/20080616-141916-IH01/msh.htm

I am currently exploring automated generalization in the client. One of the fundamental problems with generalization is that topology errors conflate when you combine datasets. You can resolve topology errors if all the datasets are generalized and stored together. But if you ‘mash-up’ data from more than one WFS, topology conflation errors can only be resolved in the client.

-Eric

On Thu, Sep 18, 2008 at 3:14 AM, G. Allegri <giohappy@anonymised.com> wrote:

Thanks everyone. I admit my need were not clear enough… Probably, as
Andrea says, it’s a mix of simplification and feature
extraction/ranking. I know that the WFS protocol doesn’t consider this
kind of things, but I was just wondering if someone had ever developed
modules/libraries/etc to be used in a customized WFS request. I’m
building the client over OL,. so I could manage it somehow.
The WPS could ideally a solution, but it’s a too long chain for fast
interactions (wheel zoomin, brownian zoomin, etc.).

I’ll convince the customer about the problem, and I will propose a
more classical solution: WMS until a certain resolution, and then
WFS…

I’ll let you know if I will experiment strange solutions :slight_smile:

2008/9/18 Andrea Aime <aaime@anonymised.com>:

G. Allegri ha scritto:

I had just sent an email on the OL ml about a midnight question, when
I’ve seen this:
geoserver.org/display/GEOS/Vector+Super+Overlays
It is exactly about my question: how to distribute heavy vector
features on WFS services (mine is about 12 MB)? I was wondering if
there is anything that can manage a sort of “runtime simplification”
on the base of the zoom level, something the pyramids concept with
rasters…

Adding just some bits over Gabriel response. WFS is indeed not
meant to compute fields that are not there, or to alter existing
ones. Yet, not even the vector super overlay code works that way,
it does not simplify geometries, just “allocates” them into a
pyramid of tiles, basically the algorithm has a way to determine
the most important featueres falling into a tile, and allocates
N into the topmost tile, then allocates N into the 4 lower tiles
that haven’t already been allocated in the upper ones, and so on,
in a way that makes the most important features available first.
The allocation does not need any zoom info, the extraction neither,
since it assumes the Google Earth client behaviour, that explicitly
requires tile number x,y,z using a custom protocol (I believe)
that’s getting translated into an equivalent WMS call.
Humm… that could be done the same way with WFS if we make the x,y,z
indication a custom filter function, something like:
featureInTile(feature, x, y, z) = true

However, I’m digressing. Maybe you should explain a little more
your specific use case. The WFS protocol per se does not offer
anything, even paging is our custom extension (will be introduced
officially in a future version of WFS, and the protocol would be
different as far as I know), so if you “own” the client you
can try out custom solutions, otherwise, not.

Is this something that will be featured inside Geoserver?

If what you need is a mix between simplification and filtering
I guess you need WPS. We have a WPS module made by Refractions
in the community section, so far I haven’t found the time to
look into it, but it seems the right fit for your needs?


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


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


-=–=—=----=----=—=–=-=–=—=----=—=–=-=-
Eric B. Wolf 720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography


-=–=—=----=----=—=–=-=–=—=----=—=–=-=-
Eric B. Wolf 720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography

That sounds really interesting. Are you experimenting and developing
on an usual client, or something specifically dedicated to the
problem?
As you note, the real problem is always the topological consitency.
How do you manage it on the client side if the data passed from the
server are stored in non-topological structures like, i.e., GML
(excluding GML3-Topology)?

2008/9/18 Eric Wolf <ebwolf@anonymised.com>:

Andrea and G.Allegri:
I'm very interested in hearing where you end up going with this. What you
describe is known, in academia, as a multi-resolution database, and is at
the heart of my PhD dissertation research.
As far as I know, every MRDB created so far uses a custom protocol if it
works in a client/server model. Theodor Foerster recently presented his PhD
research towards creating a WPS for automated generalization. You can view
his presentation at:
http://www.nottingham.ac.uk/~cczrmg/accordent/pmzcc1/20080616-141916-IH01/msh.htm
I am currently exploring automated generalization in the client. One of the
fundamental problems with generalization is that topology errors conflate
when you combine datasets. You can resolve topology errors if all the
datasets are generalized and stored together. But if you 'mash-up' data from
more than one WFS, topology conflation errors can only be resolved in the
client.
-Eric

On Thu, Sep 18, 2008 at 3:14 AM, G. Allegri <giohappy@anonymised.com> wrote:

Thanks everyone. I admit my need were not clear enough... Probably, as
Andrea says, it's a mix of simplification and feature
extraction/ranking. I know that the WFS protocol doesn't consider this
kind of things, but I was just wondering if someone had ever developed
modules/libraries/etc to be used in a customized WFS request. I'm
building the client over OL,. so I could manage it somehow.
The WPS could ideally a solution, but it's a too long chain for fast
interactions (wheel zoomin, brownian zoomin, etc.).

I'll convince the customer about the problem, and I will propose a
more classical solution: WMS until a certain resolution, and then
WFS...

I'll let you know if I will experiment strange solutions :slight_smile:

2008/9/18 Andrea Aime <aaime@anonymised.com>:
> G. Allegri ha scritto:
>>
>> I had just sent an email on the OL ml about a midnight question, when
>> I've seen this:
>> geoserver.org/display/GEOS/Vector+Super+Overlays
>> It is exactly about my question: how to distribute heavy vector
>> features on WFS services (mine is about 12 MB)? I was wondering if
>> there is anything that can manage a sort of "runtime simplification"
>> on the base of the zoom level, something the pyramids concept with
>> rasters...
>
> Adding just some bits over Gabriel response. WFS is indeed not
> meant to compute fields that are not there, or to alter existing
> ones. Yet, not even the vector super overlay code works that way,
> it does not simplify geometries, just "allocates" them into a
> pyramid of tiles, basically the algorithm has a way to determine
> the most important featueres falling into a tile, and allocates
> N into the topmost tile, then allocates N into the 4 lower tiles
> that haven't already been allocated in the upper ones, and so on,
> in a way that makes the most important features available first.
> The allocation does not need any zoom info, the extraction neither,
> since it assumes the Google Earth client behaviour, that explicitly
> requires tile number x,y,z using a custom protocol (I believe)
> that's getting translated into an equivalent WMS call.
> Humm... that could be done the same way with WFS if we make the x,y,z
> indication a custom filter function, something like:
> featureInTile(feature, x, y, z) = true
>
> However, I'm digressing. Maybe you should explain a little more
> your specific use case. The WFS protocol per se does not offer
> anything, even paging is our custom extension (will be introduced
> officially in a future version of WFS, and the protocol would be
> different as far as I know), so if you "own" the client you
> can try out custom solutions, otherwise, not.
>
>> Is this something that will be featured inside Geoserver?
>
> If what you need is a mix between simplification and filtering
> I guess you need WPS. We have a WPS module made by Refractions
> in the community section, so far I haven't found the time to
> look into it, but it seems the right fit for your needs?
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-=--=---=----=----=---=--=-=--=---=----=---=--=-=-
Eric B. Wolf 720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography