[Geoserver-devel] discussion about wms 1.3 support

Hi all,

Recently some fellow developers have started to look at implementing wms 1.3 support in geoserver. So I wanted to spark some design and general discussion about how to go about implementation. I wrote down some quick thoughts on this wiki page:

http://geoserver.org/display/GEOS/WMS-1.3

I welcome to anyone interested to chime in with thoughts, feedback, and opinions. But note that the above is still very rough and by no means complete. But the hope is with all the feedback to come up with a good implementation strategy.

Also note that a few things (like axis ordering) i am still not sure I fully understand. So I am hoping those much wiser than myself can correct me where i am wrong.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Thanks for putting this up Justin. Looks very promising.

Just a quick note, I think the ExtendedCapabilitiesProvider interface
getSchemaLocation() method should return multiple schema locations, and
it doesn't say which namespace the schema location is for, so I guess
you mean it returns the complete definition like in "<namespace>
<location>"?

perhaps it could better be getSchemaLocation():Map<String, String> where
the return value maps namespaces to schema locations.

my 2c/
Gab

On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:

Hi all,

Recently some fellow developers have started to look at implementing
wms 1.3 support in geoserver. So I wanted to spark some design and
general discussion about how to go about implementation. I wrote down
some quick thoughts on this wiki page:

  http://geoserver.org/display/GEOS/WMS-1.3

I welcome to anyone interested to chime in with thoughts, feedback,
and opinions. But note that the above is still very rough and by no
means complete. But the hope is with all the feedback to come up with
a good implementation strategy.

Also note that a few things (like axis ordering) i am still not sure I
fully understand. So I am hoping those much wiser than myself can
correct me where i am wrong.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

ok, thinking about it looks like multiple schema locations may not be
necessary at all, since an extension point may be confined to contribute
extensions for a single schema and the schema should import anything
else needed.... sorry for the confusion, I'll grab some early morning
coffee now and shut up.

On Fri, 2010-12-03 at 08:23 -0300, Gabriel Roldán wrote:

Thanks for putting this up Justin. Looks very promising.

Just a quick note, I think the ExtendedCapabilitiesProvider interface
getSchemaLocation() method should return multiple schema locations, and
it doesn't say which namespace the schema location is for, so I guess
you mean it returns the complete definition like in "<namespace>
<location>"?

perhaps it could better be getSchemaLocation():Map<String, String> where
the return value maps namespaces to schema locations.

my 2c/
Gab

On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:
> Hi all,
>
>
> Recently some fellow developers have started to look at implementing
> wms 1.3 support in geoserver. So I wanted to spark some design and
> general discussion about how to go about implementation. I wrote down
> some quick thoughts on this wiki page:
>
>
> http://geoserver.org/display/GEOS/WMS-1.3
>
>
> I welcome to anyone interested to chime in with thoughts, feedback,
> and opinions. But note that the above is still very rough and by no
> means complete. But the hope is with all the feedback to come up with
> a good implementation strategy.
>
>
> Also note that a few things (like axis ordering) i am still not sure I
> fully understand. So I am hoping those much wiser than myself can
> correct me where i am wrong.
>
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

Hi Justin,

wrt axis order, the description does not seem right to me.

"The WMS 1.3 spec itself only mandates support for two default geographic
projections. Named CRS:84 and EPSG:4326 respectively. Both of these define
the "regular" axis order of longitude, latitude or x,y."

EPSG:4326 should be y,x instead.

Best regards,
Bart

Thanks for putting this up Justin. Looks very promising.

Just a quick note, I think the ExtendedCapabilitiesProvider interface
getSchemaLocation() method should return multiple schema locations, and
it doesn't say which namespace the schema location is for, so I guess
you mean it returns the complete definition like in "<namespace>
<location>"?

perhaps it could better be getSchemaLocation():Map<String, String> where
the return value maps namespaces to schema locations.

my 2c/
Gab

On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:

Hi all,

Recently some fellow developers have started to look at implementing
wms 1.3 support in geoserver. So I wanted to spark some design and
general discussion about how to go about implementation. I wrote down
some quick thoughts on this wiki page:

  http://geoserver.org/display/GEOS/WMS-1.3

I welcome to anyone interested to chime in with thoughts, feedback,
and opinions. But note that the above is still very rough and by no
means complete. But the hope is with all the feedback to come up with
a good implementation strategy.

Also note that a few things (like axis ordering) i am still not sure I
fully understand. So I am hoping those much wiser than myself can
correct me where i am wrong.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for
grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________ Geoserver-devel mailing
list Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

It looks like EPSG ones are lat/lon for the WMS 1.3 spec.

Check the following excerpt from page 16, section 6.7.3.1. My read is it basically says axis order shall be respected and EPSG geographic CRS’s are latitude/longitude:

"The Layer CRS has two axes, denoted x and y. The x axis is the first axis in the CRS definition, the y axis is the
second axis. Depending on the particular CRS, the x axis may or may not be oriented West-to-East, and the y axis
may or may not be oriented South-to-North. The WMS portrayal operation shall account for axis order, origin and
direction in the Layer CRS when projecting geographic information from a Layer CRS to the Map CS.

Coordinates shall be listed in the order defined by the CRS and shall be mapped appropriately to the Map CS i
and j axes, swapping axis order as needed during the projection operation. Many projected coordinate reference
systems have an axis and coordinate order other than easting, northing. For example, the Uniform Coordinate
System used in Finland (EPSG:2393) orders northing before easting. EPSG geographic coordinate reference
systems follow ISO 6709 and always list latitude before longitude."

On Fri, 2010-12-03 at 12:32 +0100, Bart van den Eijnden (OSGIS) wrote:

Hi Justin,

wrt axis order, the description does not seem right to me.

"The WMS 1.3 spec itself only mandates support for two default geographic
projections. Named CRS:84 and EPSG:4326 respectively. Both of these define
the "regular" axis order of longitude, latitude or x,y."

EPSG:4326 should be y,x instead.

Best regards,
Bart

> Thanks for putting this up Justin. Looks very promising.
>
> Just a quick note, I think the ExtendedCapabilitiesProvider interface
> getSchemaLocation() method should return multiple schema locations, and
> it doesn't say which namespace the schema location is for, so I guess
> you mean it returns the complete definition like in "<namespace>
> <location>"?
>
> perhaps it could better be getSchemaLocation():Map<String, String> where
> the return value maps namespaces to schema locations.
>
> my 2c/
> Gab
>
> On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:
>> Hi all,
>>
>>
>> Recently some fellow developers have started to look at implementing
>> wms 1.3 support in geoserver. So I wanted to spark some design and
>> general discussion about how to go about implementation. I wrote down
>> some quick thoughts on this wiki page:
>>
>>
>>   [http://geoserver.org/display/GEOS/WMS-1.3](http://geoserver.org/display/GEOS/WMS-1.3)
>>
>>
>> I welcome to anyone interested to chime in with thoughts, feedback,
>> and opinions. But note that the above is still very rough and by no
>> means complete. But the hope is with all the feedback to come up with
>> a good implementation strategy.
>>
>>
>> Also note that a few things (like axis ordering) i am still not sure I
>> fully understand. So I am hoping those much wiser than myself can
>> correct me where i am wrong.
>>
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - [http://opengeo.org](http://opengeo.org)
>> Enterprise support for open source geospatial.
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for
>> grabs.
>> [http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
>> _______________________________________________ Geoserver-devel mailing
>> list [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
>> [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
>
> --
> Gabriel Roldan
> [groldan@anonymised.com](mailto:groldan@anonymised.com)
> Expert service straight from the developers
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> [http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
> _______________________________________________
> Geoserver-devel mailing list
> [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
> [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
[http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)



<br>-- <br>Gabriel Roldan<br>[groldan@anonymised.com](mailto:groldan@anonymised.com)<br>Expert service straight from the developers<br><br>

On Fri, Dec 3, 2010 at 2:31 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Recently some fellow developers have started to look at implementing wms 1.3
support in geoserver. So I wanted to spark some design and general
discussion about how to go about implementation. I wrote down some quick
thoughts on this wiki page:
http://geoserver.org/display/GEOS/WMS-1.3

I second Gabriel about the axis order thing.

One thing that surprises me in the document is the statement that
"WMS 1.3 comes with a new version of SLD".
As far as I know WMS is completely opaque wrt styling, otherwise it would
not be possible for MapServer to be a valid WMS (since the styling is done
in the mapfile, not in SLD).

My understanding of things is that if you want to implement SLD 1.1
extended WMS methods then yeah, you have to use WMS 1.3, but
nothing prevents you from using WMS 1.3 and styling things in
SLD 1.0 behind the scenes.

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

On Fri, 2010-12-03 at 13:18 +0100, Andrea Aime wrote:

On Fri, Dec 3, 2010 at 2:31 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
> Hi all,
> Recently some fellow developers have started to look at implementing wms 1.3
> support in geoserver. So I wanted to spark some design and general
> discussion about how to go about implementation. I wrote down some quick
> thoughts on this wiki page:
> http://geoserver.org/display/GEOS/WMS-1.3

I second Gabriel about the axis order thing.

One thing that surprises me in the document is the statement that
"WMS 1.3 comes with a new version of SLD".
As far as I know WMS is completely opaque wrt styling, otherwise it would
not be possible for MapServer to be a valid WMS (since the styling is done
in the mapfile, not in SLD).

My understanding of things is that if you want to implement SLD 1.1
extended WMS methods then yeah, you have to use WMS 1.3, but
nothing prevents you from using WMS 1.3 and styling things in
SLD 1.0 behind the scenes.

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

I think we could quickly come up with a WMS 1.3 implementation that
supports SLD 1.0 and add SLD/SE 1.1 support later?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

On Fri, Dec 3, 2010 at 4:24 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

ok, thinking about it looks like multiple schema locations may not be
necessary at all, since an extension point may be confined to contribute
extensions for a single schema and the schema should import anything
else needed… sorry for the confusion, I’ll grab some early morning
coffee now and shut up.

Actually what I implemented was schemaLocation as an array so the ability to return multiple schemaLocations which seems could be necessary. Sorry for the typo in the doc.

On Fri, 2010-12-03 at 08:23 -0300, Gabriel Roldán wrote:

Thanks for putting this up Justin. Looks very promising.

Just a quick note, I think the ExtendedCapabilitiesProvider interface
getSchemaLocation() method should return multiple schema locations, and
it doesn’t say which namespace the schema location is for, so I guess
you mean it returns the complete definition like in “
”?

perhaps it could better be getSchemaLocation():Map<String, String> where
the return value maps namespaces to schema locations.

my 2c/
Gab

On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:

Hi all,

Recently some fellow developers have started to look at implementing
wms 1.3 support in geoserver. So I wanted to spark some design and
general discussion about how to go about implementation. I wrote down
some quick thoughts on this wiki page:

http://geoserver.org/display/GEOS/WMS-1.3

I welcome to anyone interested to chime in with thoughts, feedback,
and opinions. But note that the above is still very rough and by no
means complete. But the hope is with all the feedback to come up with
a good implementation strategy.

Also note that a few things (like axis ordering) i am still not sure I
fully understand. So I am hoping those much wiser than myself can
correct me where i am wrong.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Great, thanks for the clarification guys, I knew i did not have it right.

On Fri, Dec 3, 2010 at 4:53 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

It looks like EPSG ones are lat/lon for the WMS 1.3 spec.

Check the following excerpt from page 16, section 6.7.3.1. My read is it basically says axis order shall be respected and EPSG geographic CRS’s are latitude/longitude:

"The Layer CRS has two axes, denoted x and y. The x axis is the first axis in the CRS definition, the y axis is the
second axis. Depending on the particular CRS, the x axis may or may not be oriented West-to-East, and the y axis
may or may not be oriented South-to-North. The WMS portrayal operation shall account for axis order, origin and
direction in the Layer CRS when projecting geographic information from a Layer CRS to the Map CS.

Coordinates shall be listed in the order defined by the CRS and shall be mapped appropriately to the Map CS i
and j axes, swapping axis order as needed during the projection operation. Many projected coordinate reference
systems have an axis and coordinate order other than easting, northing. For example, the Uniform Coordinate
System used in Finland (EPSG:2393) orders northing before easting. EPSG geographic coordinate reference
systems follow ISO 6709 and always list latitude before longitude."

On Fri, 2010-12-03 at 12:32 +0100, Bart van den Eijnden (OSGIS) wrote:

Hi Justin,

wrt axis order, the description does not seem right to me.

"The WMS 1.3 spec itself only mandates support for two default geographic
projections. Named CRS:84 and EPSG:4326 respectively. Both of these define
the "regular" axis order of longitude, latitude or x,y."

EPSG:4326 should be y,x instead.

Best regards,
Bart

> Thanks for putting this up Justin. Looks very promising.
>
> Just a quick note, I think the ExtendedCapabilitiesProvider interface
> getSchemaLocation() method should return multiple schema locations, and
> it doesn't say which namespace the schema location is for, so I guess
> you mean it returns the complete definition like in "<namespace>
> <location>"?
>
> perhaps it could better be getSchemaLocation():Map<String, String> where
> the return value maps namespaces to schema locations.
>
> my 2c/
> Gab
>
> On Thu, 2010-12-02 at 18:31 -0700, Justin Deoliveira wrote:
>> Hi all,
>>
>>
>> Recently some fellow developers have started to look at implementing
>> wms 1.3 support in geoserver. So I wanted to spark some design and
>> general discussion about how to go about implementation. I wrote down
>> some quick thoughts on this wiki page:
>>
>>
>>   [http://geoserver.org/display/GEOS/WMS-1.3](http://geoserver.org/display/GEOS/WMS-1.3)
>>
>>
>> I welcome to anyone interested to chime in with thoughts, feedback,
>> and opinions. But note that the above is still very rough and by no
>> means complete. But the hope is with all the feedback to come up with
>> a good implementation strategy.
>>
>>
>> Also note that a few things (like axis ordering) i am still not sure I
>> fully understand. So I am hoping those much wiser than myself can
>> correct me where i am wrong.
>>
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - [http://opengeo.org](http://opengeo.org)
>> Enterprise support for open source geospatial.
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for
>> grabs.
>> [http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
>> _______________________________________________ Geoserver-devel mailing
>> list [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
>> [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
>
> --
> Gabriel Roldan
> [groldan@anonymised.com1...](mailto:groldan@anonymised.com)
> Expert service straight from the developers
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> [http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
> _______________________________________________
> Geoserver-devel mailing list
> [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
> [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
[http://p.sf.net/sfu/intelisp-dev2dev](http://p.sf.net/sfu/intelisp-dev2dev)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)



<br>-- <br>Gabriel Roldan<br>[groldan@anonymised.com](mailto:groldan@anonymised.com)<br>Expert service straight from the developers<br><br>


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Fri, Dec 3, 2010 at 5:18 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Dec 3, 2010 at 2:31 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Recently some fellow developers have started to look at implementing wms 1.3
support in geoserver. So I wanted to spark some design and general
discussion about how to go about implementation. I wrote down some quick
thoughts on this wiki page:
http://geoserver.org/display/GEOS/WMS-1.3

I second Gabriel about the axis order thing.

One thing that surprises me in the document is the statement that
“WMS 1.3 comes with a new version of SLD”.
As far as I know WMS is completely opaque wrt styling, otherwise it would
not be possible for MapServer to be a valid WMS (since the styling is done
in the mapfile, not in SLD).

My understanding of things is that if you want to implement SLD 1.1
extended WMS methods then yeah, you have to use WMS 1.3, but
nothing prevents you from using WMS 1.3 and styling things in
SLD 1.0 behind the scenes.

Yeah, this is poorly phrased. It should have read that a wms 1.3 sever can optionally implement support for SLD 1.1/SE 1.1. Will update the doc.

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

It is not 100% yet if the funding is there but yes, at least a partial implementation. The first pass of this will mostly likely just be a parser / encoder for SE. That is the parts of SE that we are capable of implementing. See recent geotools thread.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Fri, Dec 3, 2010 at 5:24 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

On Fri, 2010-12-03 at 13:18 +0100, Andrea Aime wrote:

On Fri, Dec 3, 2010 at 2:31 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Recently some fellow developers have started to look at implementing wms 1.3
support in geoserver. So I wanted to spark some design and general
discussion about how to go about implementation. I wrote down some quick
thoughts on this wiki page:
http://geoserver.org/display/GEOS/WMS-1.3

I second Gabriel about the axis order thing.

One thing that surprises me in the document is the statement that
“WMS 1.3 comes with a new version of SLD”.
As far as I know WMS is completely opaque wrt styling, otherwise it would
not be possible for MapServer to be a valid WMS (since the styling is done
in the mapfile, not in SLD).

My understanding of things is that if you want to implement SLD 1.1
extended WMS methods then yeah, you have to use WMS 1.3, but
nothing prevents you from using WMS 1.3 and styling things in
SLD 1.0 behind the scenes.

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

I think we could quickly come up with a WMS 1.3 implementation that
supports SLD 1.0 and add SLD/SE 1.1 support later?

Indeed, which is what we actually have on that github branch. A wms 1.3 that pases all cite tests. But the customer has specified that they may want to fund SE work as well. So i figure why not get it in while it is being paid for :slight_smile:

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev


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


Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

It is not 100% yet if the funding is there but yes, at least a partial implementation. The first pass of this will mostly likely just be a parser / encoder for SE. That is the parts of SE that we are capable of implementing. See recent geotools thread.

Our thought on this, which we’re talking to our client about, is that it’d be really worth it to be able to parse and encode SE 1.1 at the level of the current renderer’s capabilities, and then work through the particular rendering improvements more slowly. So we’d have SLD 1.1 and SE 1.1 in a release, but they’d have documented limitations (lack of geometry transforms in pixel space, colorReplacement and InlineContent in external graphics, line generalizations, etc). This gets us compatibility with any SE 1.1 document written that doesn’t make use of those features. Our client may be able to fund the most used ones, if not all, and we’d do that at a slower pace.

C

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev


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

On Mon, Dec 6, 2010 at 8:50 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

It is not 100% yet if the funding is there but yes, at least a
partial implementation. The first pass of this will mostly likely just be a
parser / encoder for SE. That is the parts of SE that we are capable of
implementing. See recent geotools thread.

Our thought on this, which we're talking to our client about, is that it'd
be really worth it to be able to parse and encode SE 1.1 at the level of the
current renderer's capabilities, and then work through the particular
rendering improvements more slowly. So we'd have SLD 1.1 and SE 1.1 in a
release, but they'd have documented limitations (lack of geometry transforms
in pixel space, colorReplacement and InlineContent in external graphics,
line generalizations, etc). This gets us compatibility with any SE 1.1
document written that doesn't make use of those features. Our client may be
able to fund the most used ones, if not all, and we'd do that at a slower
pace.

Sounds like a good plan to me.
Wondering, many of our existing extensions are still not supported by SLD 1.:
think most of the text symbolizer vendor options, or the open ended geometry
transformations abilities, or the open ended mark and graphics factories
with CQL expression replacements and so on: will these be maitained in
the SE 1.1 parser?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

On Mon, Dec 6, 2010 at 3:17 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 6, 2010 at 8:50 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

It is not 100% yet if the funding is there but yes, at least a
partial implementation. The first pass of this will mostly likely just be a
parser / encoder for SE. That is the parts of SE that we are capable of
implementing. See recent geotools thread.

Our thought on this, which we’re talking to our client about, is that it’d
be really worth it to be able to parse and encode SE 1.1 at the level of the
current renderer’s capabilities, and then work through the particular
rendering improvements more slowly. So we’d have SLD 1.1 and SE 1.1 in a
release, but they’d have documented limitations (lack of geometry transforms
in pixel space, colorReplacement and InlineContent in external graphics,
line generalizations, etc). This gets us compatibility with any SE 1.1
document written that doesn’t make use of those features. Our client may be
able to fund the most used ones, if not all, and we’d do that at a slower
pace.

Sounds like a good plan to me.
Wondering, many of our existing extensions are still not supported by SLD 1.:
think most of the text symbolizer vendor options, or the open ended geometry
transformations abilities, or the open ended mark and graphics factories
with CQL expression replacements and so on: will these be maitained in
the SE 1.1 parser?

Justin’s doing the investigation, so we’ll see what he says. I certainly hope so, and indeed I’d prioritize those over the obscure SE requirements, since those are actually real world tested. We may not be able to squeeze them in for the next release, but would try to do them in the future.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


+1 on this strategy

its perfectly natural to have "levels of conformance" - and at some
point someone will probably want to define limited functionality
profiles of these specs - so it should be possible to prioritise
improvements against such requirements if and when they emerge,
otherwise be driven by clients willing to invest in them (or shoot-out
pride :slight_smile: )

Rob

On Tue, Dec 7, 2010 at 9:47 AM, Chris Holmes <cholmes@anonymised.com> wrote:

On Mon, Dec 6, 2010 at 3:17 PM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Mon, Dec 6, 2010 at 8:50 PM, Chris Holmes <cholmes@anonymised.com> wrote:
>
>>>
>>> Anyways, if I understand the document properly you also intend to add
>>> support for SLD 1.1/SE 1.1 to GeoServer?
>>
>> It is not 100% yet if the funding is there but yes, at least a
>> partial implementation. The first pass of this will mostly likely just
>> be a
>> parser / encoder for SE. That is the parts of SE that we are capable of
>> implementing. See recent geotools thread.
>>
>
> Our thought on this, which we're talking to our client about, is that
> it'd
> be really worth it to be able to parse and encode SE 1.1 at the level of
> the
> current renderer's capabilities, and then work through the particular
> rendering improvements more slowly. So we'd have SLD 1.1 and SE 1.1 in
> a
> release, but they'd have documented limitations (lack of geometry
> transforms
> in pixel space, colorReplacement and InlineContent in external graphics,
> line generalizations, etc). This gets us compatibility with any SE 1.1
> document written that doesn't make use of those features. Our client
> may be
> able to fund the most used ones, if not all, and we'd do that at a
> slower
> pace.

Sounds like a good plan to me.
Wondering, many of our existing extensions are still not supported by SLD
1.:
think most of the text symbolizer vendor options, or the open ended
geometry
transformations abilities, or the open ended mark and graphics factories
with CQL expression replacements and so on: will these be maitained in
the SE 1.1 parser?

Justin's doing the investigation, so we'll see what he says. I certainly
hope so, and indeed I'd prioritize those over the obscure SE requirements,
since those are actually real world tested. We may not be able to squeeze
them in for the next release, but would try to do them in the future.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Mon, Dec 6, 2010 at 3:17 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 6, 2010 at 8:50 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Anyways, if I understand the document properly you also intend to add
support for SLD 1.1/SE 1.1 to GeoServer?

It is not 100% yet if the funding is there but yes, at least a
partial implementation. The first pass of this will mostly likely just be a
parser / encoder for SE. That is the parts of SE that we are capable of
implementing. See recent geotools thread.

Our thought on this, which we’re talking to our client about, is that it’d
be really worth it to be able to parse and encode SE 1.1 at the level of the
current renderer’s capabilities, and then work through the particular
rendering improvements more slowly. So we’d have SLD 1.1 and SE 1.1 in a
release, but they’d have documented limitations (lack of geometry transforms
in pixel space, colorReplacement and InlineContent in external graphics,
line generalizations, etc). This gets us compatibility with any SE 1.1
document written that doesn’t make use of those features. Our client may be
able to fund the most used ones, if not all, and we’d do that at a slower
pace.

Sounds like a good plan to me.
Wondering, many of our existing extensions are still not supported by SLD 1.:
think most of the text symbolizer vendor options, or the open ended geometry
transformations abilities, or the open ended mark and graphics factories
with CQL expression replacements and so on: will these be maitained in
the SE 1.1 parser?

Yup, definitely. The plan is to support all the custom vendor stuff we do today in the SE parser.

Do we have a “master” list of exactly what all the vendor specific stuff is? Is the modified sld schema we ship within geoserver the best reference?

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.