about SRS parameter

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

about SRS parameter

Gabriel Roldán-2
Hi all,

I just created
http://jira.codehaus.org/browse/GEOS-493

the question is if you're ok in making SRS parameter mandatory  (that's what
the spec says).

Cheers,

Gabriel.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: about SRS parameter

Justin Deoliveira-3
I guess my only concern is that making the SRS parameter manditory
breaks client code that doesn't presently supply the paramter. Making
things optional is much easier then making things mandatory.

On the other hand the spec saying it should be manditory is big hammer
to throw around.

What does everyone else think.

-Justin

Gabriel Roldán wrote:

> Hi all,
>
> I just created
> http://jira.codehaus.org/browse/GEOS-493
>
> the question is if you're ok in making SRS parameter mandatory  (that's what
> the spec says).
>
> Cheers,
>
> Gabriel.
>


--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: about SRS parameter

Brent Owens
If we do make this manditory, do we want it for 1.3.0?

We can always make it pseudo optional. If the SRS is supplie din the
request, we use it. If it is not supplied, we add in 4326 as a default.
This will stop client code from breaking. This could result in
unexpected results however.

I think we need to look at how long it would take to change, and how
many other things it will break, in order to determine when we should
implement it.

Brent Owens
TOPP



Justin Deoliveira wrote:

> I guess my only concern is that making the SRS parameter manditory
> breaks client code that doesn't presently supply the paramter. Making
> things optional is much easier then making things mandatory.
>
> On the other hand the spec saying it should be manditory is big hammer
> to throw around.
>
> What does everyone else think.
>
> -Justin
>
> Gabriel Roldán wrote:
>
>> Hi all,
>>
>> I just created http://jira.codehaus.org/browse/GEOS-493
>>
>> the question is if you're ok in making SRS parameter mandatory  
>> (that's what the spec says).
>>
>> Cheers,
>>
>> Gabriel.
>>
>
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

RE: Re: about SRS parameter

Efren Serra
In reply to this post by Justin Deoliveira-3
Justin,

The interaction should be:

1. client issues GetCapabilities; upon receival of the
   Capabilities document, it obtains the SRSs supported by the server.
2. client interacts with the server or gives up.
3. SRS=NONE is allowed in Capabilities document.

Note that SRS is part of the GetMap request not the response.

v/r,
Efren

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Justin
Deoliveira
Sent: Tuesday, November 29, 2005 9:36 AM
To: Gabriel Roldán
Cc: David Blasby; Brent Owens; [hidden email]
Subject: [Geoserver-devel] Re: about SRS parameter


I guess my only concern is that making the SRS parameter manditory
breaks client code that doesn't presently supply the paramter. Making
things optional is much easier then making things mandatory.

On the other hand the spec saying it should be manditory is big hammer
to throw around.

What does everyone else think.

-Justin

Gabriel Roldán wrote:

> Hi all,
>
> I just created
> http://jira.codehaus.org/browse/GEOS-493
>
> the question is if you're ok in making SRS parameter mandatory  (that's what
> the spec says).
>
> Cheers,
>
> Gabriel.
>


--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: about SRS parameter

Gabriel Roldán-2
In reply to this post by Brent Owens
Agreed, we can schedule it for after 1.3.0.

Anyway, note the current behavior is to let it null, not to use 4326, so I'm
letting it as is, which finally means querying in whatever the feature source
is in.
Problem is when more than one FS is being queries at the same time, though.

comments?

On Tuesday 29 November 2005 18:48, Brent Owens wrote:

> If we do make this manditory, do we want it for 1.3.0?
>
> We can always make it pseudo optional. If the SRS is supplie din the
> request, we use it. If it is not supplied, we add in 4326 as a default.
> This will stop client code from breaking. This could result in
> unexpected results however.
>
> I think we need to look at how long it would take to change, and how
> many other things it will break, in order to determine when we should
> implement it.
>
> Brent Owens
> TOPP
>
> Justin Deoliveira wrote:
> > I guess my only concern is that making the SRS parameter manditory
> > breaks client code that doesn't presently supply the paramter. Making
> > things optional is much easier then making things mandatory.
> >
> > On the other hand the spec saying it should be manditory is big hammer
> > to throw around.
> >
> > What does everyone else think.
> >
> > -Justin
> >
> > Gabriel Roldán wrote:
> >> Hi all,
> >>
> >> I just created http://jira.codehaus.org/browse/GEOS-493
> >>
> >> the question is if you're ok in making SRS parameter mandatory
> >> (that's what the spec says).
> >>
> >> Cheers,
> >>
> >> Gabriel.
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Geoserver-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: about SRS parameter

dblasby
In reply to this post by Gabriel Roldán-2
When I added reprojection to geoserver, people were still used to the
old behavior which was to never reproject.  Making the SRS parameter
manditory would break most of the current users.

So, if you dont specify a CRS in your GetMap then it will does the same
as SRS=NONE.  This means that there's no reprojection done. This also
means that you better have made the request bbox in the same projection
as your data or you'll probably get a blank map.

If you have a layer where you do not specify a SRS (in the FeatureType
editor) then geotools assumes that its projection is the same as the
request projection.  Obviously geotools cannot arbitrarily transform
from an unknown SRS to a known SRS.

Both these assumptions save most people from shooting themselves in the
foot, but its not without its consequences.

I dont really care if we make it manditory or not, but we will almost
certainly get people complaining about it if we change it.  We could
add a WMS config option for it though (and have it default - at least
for a while - to 'no SRS in request means SRS=NONE').

People who dont put the SRS in the request are likely:
a) wanting the SRS=NONE behavior (request projection=data projection)
b) actually wanted WSG84 lat-long (4326) with the axis hopefully
correctly aligned.
c) made a boo-boo in the request

dave



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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

RE: Re: about SRS parameter

Efren Serra
Folks,

I think this is the wrong behaviour for a server.  Either the client knows
what it wants or the server throws a ServiceException.
Adding smarts to the server to try to figure out what the client wants is
just going to complicate the server code un-necessarily.
SRS is a REQUEST parameter and the WMS 1.1.1 Implementation Specification
clearly states that is Required.

v/r,
Efren

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of
[hidden email]
Sent: Wednesday, November 30, 2005 6:26 AM
Cc: [hidden email]
Subject: [Geoserver-devel] Re: about SRS parameter


When I added reprojection to geoserver, people were still used to the
old behavior which was to never reproject.  Making the SRS parameter
manditory would break most of the current users.

So, if you dont specify a CRS in your GetMap then it will does the same
as SRS=NONE.  This means that there's no reprojection done. This also
means that you better have made the request bbox in the same projection
as your data or you'll probably get a blank map.

If you have a layer where you do not specify a SRS (in the FeatureType
editor) then geotools assumes that its projection is the same as the
request projection.  Obviously geotools cannot arbitrarily transform
from an unknown SRS to a known SRS.

Both these assumptions save most people from shooting themselves in the
foot, but its not without its consequences.

I dont really care if we make it manditory or not, but we will almost
certainly get people complaining about it if we change it.  We could
add a WMS config option for it though (and have it default - at least
for a while - to 'no SRS in request means SRS=NONE').

People who dont put the SRS in the request are likely:
a) wanting the SRS=NONE behavior (request projection=data projection)
b) actually wanted WSG84 lat-long (4326) with the axis hopefully
correctly aligned.
c) made a boo-boo in the request

dave



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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel