[Geoserver-devel] State of W3DS Community Module

Nuno_Oliveira · February 23, 2013, 11:53pm

Hi,

The last weeks I have received some inqueries from several people about the actual
state of the Geoserver W3DS community module.

Related to the W3DS specification, the following operations have been implemented:
  * GetCapabilities (minor improvements are needed related to service metadata).
  * GetScene, support all mandatory and the optionals 'styles' and 'offset' parameters. Can be request by GET or POST.
  * GetTile, support all mandatory parameters and can be request by GET or POST.
  * GetFeatureInfo, partially implemented.
  * GetLayerInfo, not implemented.

At the moment the only supported output format is X3D (and HTML+X3D).

In order to have more compatibility with the existings 3D GIS we need to provide KML (3D) output.
The recent GeoServer refactoring, related with KML generation, may be a good opportunity to add this feature.

TODO LIST:
  - Implement a decent support for 3D styles following the candidate standard (SLD 3D Portrayal);
    (the Geoserver styling logic must be improved to accept different style languages)
  - Improve the generation of X3D format (textures 3D, external models, etc ...).
  - Add support for KML 3D format (inclusion of 3D collada models).
  - Finish the implementation of GetFeatureInfo operation.
  - Improve GetCapabilities operation.

In the next days we will commit the last improvements and our demo service will be updated.

Any suggestions are very welcome.

Regards,

Nuno Oliveira

Andrea_Aime4 · February 24, 2013, 10:06am

On Sun, Feb 24, 2013 at 12:53 AM, Nuno Miguel Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Implement a decent support for 3D styles following the candidate standard (SLD 3D Portrayal);
(the Geoserver styling logic must be improved to accept different style languages)

Some feedback regarding styling. GeoServer already supports two variants of SLD, what
is probably needed is a way to make that pluggable.
Regardless of the source though, the rendering subsystem needs to be fed GeoTools
Style objects, so whatever is the source it has to be turned into some standard SLD
object.
Having to deal with new concepts will require extensions in the Style API, something that
has to be done in GeoTools and that I’m afraid is going to be difficult to make pluggable.
The process of changing the style API is a bit painful, all parsers/encoders/style visitors,
plus the renderer itself, need to be modified to handle (or ignore) the new API bits.

Improve the generation of X3D format (textures 3D, external models, etc …).

Add support for KML 3D format (inclusion of 3D collada models).

As far as I remember this means supporting a “geometry” that is not a JTS Geometry
in the output.
I can try to include this requirement in the redesign.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Nuno_Oliveira · February 24, 2013, 12:50pm

Hi,

Thanks for the quick feedback.

Related whit the SLD: the rendering process of a W3DS unlike WMS is in the client side (WPVS is the only 3D service that has the rendering on server side).
So no need of Geotools rendering support, which solve a problem in our case :).
W3DS module already use is custom styles the problem is that they are not integrate to GeoServer catalog, as a normal style.
As you identify, the problem will be solve if Geoserver let us plug another kind of Style parser that will be used to parse 3D styles specific to W3DS module.

Related to KML: I don't make my propose clear, sorry about that. KML natively support the inclusion of Collada models
(https://developers.google.com/kml/documentation/models). Basically in KML the 3D model is not included but referenced,
the client have the responsibility to include the model in the rendering process.

Resuming the actual needs of W3DS related to GeoServer core components are:

* The possibility to plug a custom SLD parser that will catch 3D styling definitions.
* A way to a customize the KML 'Placemark' node to include a 'Model' definition.

Any suggestions are very welcome.

Regards,

Nuno Oliveira
________________________________________
De : andrea.aime@anonymised.com [andrea.aime@anonymised.com] de la part de Andrea Aime [andrea.aime@anonymised.com]
Date d'envoi : dimanche 24 février 2013 10:06
À : Nuno Miguel Oliveira
Cc : geoserver-devel@lists.sourceforge.net
Objet : Re: [Geoserver-devel] State of W3DS Community Module

On Sun, Feb 24, 2013 at 12:53 AM, Nuno Miguel Oliveira <nuno-miguel-oliveira@anonymised.com<mailto:nuno-miguel-oliveira@anonymised.com>> wrote:
- Implement a decent support for 3D styles following the candidate standard (SLD 3D Portrayal);
(the Geoserver styling logic must be improved to accept different style languages)

Some feedback regarding styling. GeoServer already supports two variants of SLD, what
is probably needed is a way to make that pluggable.
Regardless of the source though, the rendering subsystem needs to be fed GeoTools
Style objects, so whatever is the source it has to be turned into some standard SLD
object.
Having to deal with new concepts will require extensions in the Style API, something that
has to be done in GeoTools and that I'm afraid is going to be difficult to make pluggable.
The process of changing the style API is a bit painful, all parsers/encoders/style visitors,
plus the renderer itself, need to be modified to handle (or ignore) the new API bits.

- Improve the generation of X3D format (textures 3D, external models, etc ...).
- Add support for KML 3D format (inclusion of 3D collada models).

As far as I remember this means supporting a "geometry" that is not a JTS Geometry
in the output.
I can try to include this requirement in the redesign.