1.3.0-rc2: WMS getCapabilites content type not set?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

1.3.0-rc2: WMS getCapabilites content type not set?

Christopher Cobb-2

On the welcome.do page there are two links for getCapabilites.  One for WFS and one for WMS.

 

When I click on the WFS getCapabilities link, I get a nice xml display.

 

When I click on the WMS getCapabilities link, I get a dialog:

 

   You have chosen to open

      wms

   which is a: application/vnd.ogc.se_xml

   What do you want me to do with this?  ( ) Save ( ) Open with…

 

Shouldn’t this be text/xml like the WFS link is?

 

cc

 


Attention:
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized
to state them to be the views of any such entity. The information
contained in this message and or attachments is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. If you received this in error, please
contact the sender and delete the material from any system and destroy
any copies.

Reply | Threaded
Open this post in threaded view
|

Re: 1.3.0-rc2: WMS getCapabilites content type not set?

Chris Holmes-2
Quoting Chris Cobb <[hidden email]>:

> On the welcome.do page there are two links for getCapabilites.  One
> for WFS
> and one for WMS.
>
>
>
> When I click on the WFS getCapabilities link, I get a nice xml
> display.
>
>
>
> When I click on the WMS getCapabilities link, I get a dialog:
>
>
>
>    You have chosen to open
>
>       wms
>
>    which is a: application/vnd.ogc.se_xml
>
>    What do you want me to do with this?  ( ) Save ( ) Open with.
>
>
>
> Shouldn't this be text/xml like the WFS link is?
Unfortunately no, the Open Geospatial Consortium (OGC) who wrote the
standards decided to have their own special mime type for WMS.  For WFS
they got sensible and just called it text/xml.  I don't really know the
reasoning for this.  But yes, it's annoying.  You can open it with
anything, it's just text.  We're just forced to return it in geoserver,
since the spec says we should.

Chris


>
>
>
> cc
>
>
>
>
>
>
> -----------------------------------------
> Attention:
> Any views expressed in this message are those of the individual
> sender,
> except where the message states otherwise and the sender is
> authorized
> to state them to be the views of any such entity. The information
> contained in this message and or attachments is intended only for the
> person or entity to which it is addressed and may contain
> confidential
> and/or privileged material.  If you received this in error, please
> contact the sender and delete the material from any system and
> destroy
> any copies.
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

RE: 1.3.0-rc2: WMS getCapabilites content type not set?

Christopher Cobb-2
I'm a newbie here so please be patient with me.

I'm looking at version 1.3 of the Web Map Service specification found here:

   http://portal.opengeospatial.org/files/?artifact_id=5316

In section "6.6 Output Formats" on "page 7" (page 16 of the pdf), it says:

   Text output formats are usually formatted as Extensible Markup Language
   (XML; MIME type text/xml).  Text formats are used to convey service
   metadata, descriptions of error conditions, or responses to queries for
   information about features shown on the map.

I also looked in the section on GetCapabilities beginning on page 14 to see
if there was any indication that a special MIME type should be used and
didn't see anything to override the directive on page 7.

In addition, in section "E.2 Service Exception schema" on "page 61" (page 70
of the pdf), it states:

   Service exception XML shall be valid according to this service exception
   schema. In an HTTP environment, the MIME type of the returned XML shall
   be "text/xml".

I scanned the document for all instances of the term "MIME" to see if there
were any places that would modify or change the use of "text/xml" as the
MIME type for text documents and didn't find any.

The MIME type that GeoServer is actually returning in my case is:

   application/vnd.ogc.se_xml

After searching the web for this string I see that OGC has waffled from
using text/xml (version 1.0) to using custom types (version 1.1) back to
using standard types in versions 1.2 (eliminate "OGC-defined MIME types for
XML document such as application/vnd.ogc.wms_xml. Use text/xml instead.")
and 1.3.  I guess this is the source of the confusion.

Is GeoServer aiming to be compliant with the two most recent versions, 1.2
and 1.3?  If so, then it seems like it should be using "text/xml" as the
mime type for returned xml documents.

Since we are still in RC status, maybe a fix for this can still be slipped
in.

cc

-----Original Message-----
From: Chris Holmes [mailto:[hidden email]]
Sent: Thursday, July 28, 2005 12:01 PM

Unfortunately no, the Open Geospatial Consortium (OGC) who wrote the
standards decided to have their own special mime type for WMS.  For WFS
they got sensible and just called it text/xml.  I don't really know the
reasoning for this.  But yes, it's annoying.  You can open it with
anything, it's just text.  We're just forced to return it in geoserver,
since the spec says we should.

Chris



-----------------------------------------
Attention:
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized
to state them to be the views of any such entity. The information
contained in this message and or attachments is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material.  If you received this in error, please
contact the sender and delete the material from any system and destroy
any copies.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.3.0-rc2: WMS getCapabilites content type not set?

Richard Gould
I don't think GeoServer support WMS 1.3.0 at all.

Also, all future versions of WMS (and all other Open Web Services) will
return "text/xml" by default with a capabilities response.

Richard

Chris Cobb wrote:

> I'm a newbie here so please be patient with me.
>
> I'm looking at version 1.3 of the Web Map Service specification found here:
>
>    http://portal.opengeospatial.org/files/?artifact_id=5316
>
> In section "6.6 Output Formats" on "page 7" (page 16 of the pdf), it says:
>
>    Text output formats are usually formatted as Extensible Markup Language
>    (XML; MIME type text/xml).  Text formats are used to convey service
>    metadata, descriptions of error conditions, or responses to queries for
>    information about features shown on the map.
>
> I also looked in the section on GetCapabilities beginning on page 14 to see
> if there was any indication that a special MIME type should be used and
> didn't see anything to override the directive on page 7.
>
> In addition, in section "E.2 Service Exception schema" on "page 61" (page 70
> of the pdf), it states:
>
>    Service exception XML shall be valid according to this service exception
>    schema. In an HTTP environment, the MIME type of the returned XML shall
>    be "text/xml".
>
> I scanned the document for all instances of the term "MIME" to see if there
> were any places that would modify or change the use of "text/xml" as the
> MIME type for text documents and didn't find any.
>
> The MIME type that GeoServer is actually returning in my case is:
>
>    application/vnd.ogc.se_xml
>
> After searching the web for this string I see that OGC has waffled from
> using text/xml (version 1.0) to using custom types (version 1.1) back to
> using standard types in versions 1.2 (eliminate "OGC-defined MIME types for
> XML document such as application/vnd.ogc.wms_xml. Use text/xml instead.")
> and 1.3.  I guess this is the source of the confusion.
>
> Is GeoServer aiming to be compliant with the two most recent versions, 1.2
> and 1.3?  If so, then it seems like it should be using "text/xml" as the
> mime type for returned xml documents.
>
> Since we are still in RC status, maybe a fix for this can still be slipped
> in.
>
> cc
>
> -----Original Message-----
> From: Chris Holmes [mailto:[hidden email]]
> Sent: Thursday, July 28, 2005 12:01 PM
>
> Unfortunately no, the Open Geospatial Consortium (OGC) who wrote the
> standards decided to have their own special mime type for WMS.  For WFS
> they got sensible and just called it text/xml.  I don't really know the
> reasoning for this.  But yes, it's annoying.  You can open it with
> anything, it's just text.  We're just forced to return it in geoserver,
> since the spec says we should.
>
> Chris
>
>
>
> -----------------------------------------
> Attention:
> Any views expressed in this message are those of the individual sender,
> except where the message states otherwise and the sender is authorized
> to state them to be the views of any such entity. The information
> contained in this message and or attachments is intended only for the
> person or entity to which it is addressed and may contain confidential
> and/or privileged material.  If you received this in error, please
> contact the sender and delete the material from any system and destroy
> any copies.
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Geoserver-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.3.0-rc2: WMS getCapabilites content type not set?

Chris Holmes-2
GeoServer currently targets version 1.1.1, which is the most widely
implemented, and the only version for which there are conformance
tests.  I imagine in the future we will support 1.3.0, since it's an
open project and such an advanement would be welcome.  But there don't
seem to be any huge wins with 1.3.0, as far as I know (though I also
didn't know they did fix the silly mime type stuff).  But even if we
support 1.3.0, we will still support 1.1.1, it'll just be a matter of
the capabilities negotiation to figure out which version you want.  I
wonder if it's possible to just return a 1.3.0 caps document without
changing any of the other operations at all?  If it is it could be
interesting to look into it, because I do find the mime type thing damn
annoying.

Chris

Quoting Richard Gould <[hidden email]>:

> I don't think GeoServer support WMS 1.3.0 at all.
>
> Also, all future versions of WMS (and all other Open Web Services)
> will
> return "text/xml" by default with a capabilities response.
>
> Richard
>
> Chris Cobb wrote:
> > I'm a newbie here so please be patient with me.
> >
> > I'm looking at version 1.3 of the Web Map Service specification
> found here:
> >
> >    http://portal.opengeospatial.org/files/?artifact_id=5316
> >
> > In section "6.6 Output Formats" on "page 7" (page 16 of the pdf),
> it says:
> >
> >    Text output formats are usually formatted as Extensible Markup
> Language
> >    (XML; MIME type text/xml).  Text formats are used to convey
> service
> >    metadata, descriptions of error conditions, or responses to
> queries for
> >    information about features shown on the map.
> >
> > I also looked in the section on GetCapabilities beginning on page
> 14 to see
> > if there was any indication that a special MIME type should be used
> and
> > didn't see anything to override the directive on page 7.
> >
> > In addition, in section "E.2 Service Exception schema" on "page 61"
> (page 70
> > of the pdf), it states:
> >
> >    Service exception XML shall be valid according to this service
> exception
> >    schema. In an HTTP environment, the MIME type of the returned
> XML shall
> >    be "text/xml".
> >
> > I scanned the document for all instances of the term "MIME" to see
> if there
> > were any places that would modify or change the use of "text/xml"
> as the
> > MIME type for text documents and didn't find any.
> >
> > The MIME type that GeoServer is actually returning in my case is:
> >
> >    application/vnd.ogc.se_xml
> >
> > After searching the web for this string I see that OGC has waffled
> from
> > using text/xml (version 1.0) to using custom types (version 1.1)
> back to
> > using standard types in versions 1.2 (eliminate "OGC-defined MIME
> types for
> > XML document such as application/vnd.ogc.wms_xml. Use text/xml
> instead.")
> > and 1.3.  I guess this is the source of the confusion.
> >
> > Is GeoServer aiming to be compliant with the two most recent
> versions, 1.2
> > and 1.3?  If so, then it seems like it should be using "text/xml"
> as the
> > mime type for returned xml documents.
> >
> > Since we are still in RC status, maybe a fix for this can still be
> slipped
> > in.
> >
> > cc
> >
> > -----Original Message-----
> > From: Chris Holmes [mailto:[hidden email]]
> > Sent: Thursday, July 28, 2005 12:01 PM
> >
> > Unfortunately no, the Open Geospatial Consortium (OGC) who wrote
> the
> > standards decided to have their own special mime type for WMS.  For
> WFS
> > they got sensible and just called it text/xml.  I don't really know
> the
> > reasoning for this.  But yes, it's annoying.  You can open it with
> > anything, it's just text.  We're just forced to return it in
> geoserver,
> > since the spec says we should.
> >
> > Chris
> >
> >
> >
> > -----------------------------------------
> > Attention:
> > Any views expressed in this message are those of the individual
> sender,
> > except where the message states otherwise and the sender is
> authorized
> > to state them to be the views of any such entity. The information
> > contained in this message and or attachments is intended only for
> the
> > person or entity to which it is addressed and may contain
> confidential
> > and/or privileged material.  If you received this in error, please
> > contact the sender and delete the material from any system and
> destroy
> > any copies.
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> September
> > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> > Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Geoserver-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Geoserver-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

RE: 1.3.0-rc2: WMS getCapabilites content type not set?

Chris Holmes-2
In reply to this post by Christopher Cobb-2
> Is GeoServer aiming to be compliant with the two most recent
> versions, 1.2
> and 1.3?  If so, then it seems like it should be using "text/xml" as
> the
> mime type for returned xml documents.
>
> Since we are still in RC status, maybe a fix for this can still be
> slipped
> in.

Ok, don't think I explained this completely.  Basically the specs allow
for backwards compatibility, so it's not a matter of 'fixing' it, it's
making the next version of the capabilities document available as well.
 So unfortunately we can't just change a line of code, or else we
wouldn't be compliant with any of the specs.  Right now we just assume
1.1.1, so there's needs to be a bit of coding to deal with multiple
versions.  If you were interesting in coding this up I'd be happy to
investigate exactly what is needed.

best regards,

Chris


>
> cc
>
> -----Original Message-----
> From: Chris Holmes [mailto:[hidden email]]
> Sent: Thursday, July 28, 2005 12:01 PM
>
> Unfortunately no, the Open Geospatial Consortium (OGC) who wrote the
> standards decided to have their own special mime type for WMS.  For
> WFS
> they got sensible and just called it text/xml.  I don't really know
> the
> reasoning for this.  But yes, it's annoying.  You can open it with
> anything, it's just text.  We're just forced to return it in
> geoserver,
> since the spec says we should.
>
> Chris
>
>
>
> -----------------------------------------
> Attention:
> Any views expressed in this message are those of the individual
> sender,
> except where the message states otherwise and the sender is
> authorized
> to state them to be the views of any such entity. The information
> contained in this message and or attachments is intended only for the
> person or entity to which it is addressed and may contain
> confidential
> and/or privileged material.  If you received this in error, please
> contact the sender and delete the material from any system and
> destroy
> any copies.
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Geoserver-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.3.0-rc2: WMS getCapabilites content type not set?

Richard Gould
In reply to this post by Chris Holmes-2
There is a bit more work involved in WMS 1.3.0. I can't exactly remember
the specifics, but some of the changes are very obscure.

The elements related to the SLD extension have been removed. (The four
SLD operations - GetLegendGraphic, GetStyles, PutStyles and
DescribeLayer) But they have a generic hook that can add those back in.
It isn't standardized.

The biggest issue is that the order of the CRS axes changes from WMS
1.1.1 and WMS 1.3.0. It is for this reason that uDig does not support
1.3.0. (Note that the WMS client in GeoTools does. uDig doesn't because
not all 1.3.0 servers behave properly regarding this CRS and there is no
easy way to tell. Plus almost every 1.3.0 server can do 1.1.1)

The rules for encoding special character sequences have changed a
little. Can't recall the exact differences.

The parameters "X" and "Y" of the GetFeatureInfo request have been
renamed to "I" and "J", respectively.

That's all I can remember off the top of my head.

Richard

Chris Holmes wrote:

> GeoServer currently targets version 1.1.1, which is the most widely
> implemented, and the only version for which there are conformance
> tests.  I imagine in the future we will support 1.3.0, since it's an
> open project and such an advanement would be welcome.  But there don't
> seem to be any huge wins with 1.3.0, as far as I know (though I also
> didn't know they did fix the silly mime type stuff).  But even if we
> support 1.3.0, we will still support 1.1.1, it'll just be a matter of
> the capabilities negotiation to figure out which version you want.  I
> wonder if it's possible to just return a 1.3.0 caps document without
> changing any of the other operations at all?  If it is it could be
> interesting to look into it, because I do find the mime type thing damn
> annoying.
>
> Chris
>
> Quoting Richard Gould <[hidden email]>:
>
>
>>I don't think GeoServer support WMS 1.3.0 at all.
>>
>>Also, all future versions of WMS (and all other Open Web Services)
>>will
>>return "text/xml" by default with a capabilities response.
>>
>>Richard
>>
>>Chris Cobb wrote:
>>
>>>I'm a newbie here so please be patient with me.
>>>
>>>I'm looking at version 1.3 of the Web Map Service specification
>>
>>found here:
>>
>>>   http://portal.opengeospatial.org/files/?artifact_id=5316
>>>
>>>In section "6.6 Output Formats" on "page 7" (page 16 of the pdf),
>>
>>it says:
>>
>>>   Text output formats are usually formatted as Extensible Markup
>>
>>Language
>>
>>>   (XML; MIME type text/xml).  Text formats are used to convey
>>
>>service
>>
>>>   metadata, descriptions of error conditions, or responses to
>>
>>queries for
>>
>>>   information about features shown on the map.
>>>
>>>I also looked in the section on GetCapabilities beginning on page
>>
>>14 to see
>>
>>>if there was any indication that a special MIME type should be used
>>
>>and
>>
>>>didn't see anything to override the directive on page 7.
>>>
>>>In addition, in section "E.2 Service Exception schema" on "page 61"
>>
>>(page 70
>>
>>>of the pdf), it states:
>>>
>>>   Service exception XML shall be valid according to this service
>>
>>exception
>>
>>>   schema. In an HTTP environment, the MIME type of the returned
>>
>>XML shall
>>
>>>   be "text/xml".
>>>
>>>I scanned the document for all instances of the term "MIME" to see
>>
>>if there
>>
>>>were any places that would modify or change the use of "text/xml"
>>
>>as the
>>
>>>MIME type for text documents and didn't find any.
>>>
>>>The MIME type that GeoServer is actually returning in my case is:
>>>
>>>   application/vnd.ogc.se_xml
>>>
>>>After searching the web for this string I see that OGC has waffled
>>
>>from
>>
>>>using text/xml (version 1.0) to using custom types (version 1.1)
>>
>>back to
>>
>>>using standard types in versions 1.2 (eliminate "OGC-defined MIME
>>
>>types for
>>
>>>XML document such as application/vnd.ogc.wms_xml. Use text/xml
>>
>>instead.")
>>
>>>and 1.3.  I guess this is the source of the confusion.
>>>
>>>Is GeoServer aiming to be compliant with the two most recent
>>
>>versions, 1.2
>>
>>>and 1.3?  If so, then it seems like it should be using "text/xml"
>>
>>as the
>>
>>>mime type for returned xml documents.
>>>
>>>Since we are still in RC status, maybe a fix for this can still be
>>
>>slipped
>>
>>>in.
>>>
>>>cc
>>>
>>>-----Original Message-----
>>>From: Chris Holmes [mailto:[hidden email]]
>>>Sent: Thursday, July 28, 2005 12:01 PM
>>>
>>>Unfortunately no, the Open Geospatial Consortium (OGC) who wrote
>>
>>the
>>
>>>standards decided to have their own special mime type for WMS.  For
>>
>>WFS
>>
>>>they got sensible and just called it text/xml.  I don't really know
>>
>>the
>>
>>>reasoning for this.  But yes, it's annoying.  You can open it with
>>>anything, it's just text.  We're just forced to return it in
>>
>>geoserver,
>>
>>>since the spec says we should.
>>>
>>>Chris
>>>
>>>
>>>
>>>-----------------------------------------
>>>Attention:
>>>Any views expressed in this message are those of the individual
>>
>>sender,
>>
>>>except where the message states otherwise and the sender is
>>
>>authorized
>>
>>>to state them to be the views of any such entity. The information
>>>contained in this message and or attachments is intended only for
>>
>>the
>>
>>>person or entity to which it is addressed and may contain
>>
>>confidential
>>
>>>and/or privileged material.  If you received this in error, please
>>>contact the sender and delete the material from any system and
>>
>>destroy
>>
>>>any copies.
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>
>>September
>>
>>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams *
>>
>>Testing & QA
>>
>>>Security * Process Improvement & Measurement *
>>
>>http://www.sqe.com/bsce5sf
>>
>>>_______________________________________________
>>>Geoserver-users mailing list
>>>[hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September
>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>>& QA
>>Security * Process Improvement & Measurement *
>>http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Geoserver-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users