R: Re: about SRS parameter

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

R: Re: about SRS parameter

P.Rizzi Ag.Mobilità Ambiente
What about providing a default SRS value server-wide???
Something inside the config of GeoServer.
I think most people will only use the very same SRS for all
their tables, so a server-wide value should save client code
most of the time.

Bye
Paolo Rizzi


> -----Messaggio originale-----
> Da: Gabriel Roldán [mailto:[hidden email]]
> Inviato: martedì 29 novembre 2005 19.54
> A: [hidden email]
> Cc: Brent Owens; Justin Deoliveira; David Blasby
> Oggetto: Re: [Geoserver-devel] Re: about SRS parameter
>
>
> 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
>




AVVERTENZE AI SENSI DEL D. LGS. 196/2003  
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.


-------------------------------------------------------
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: R: Re: about SRS parameter

Brent Owens
That could be a possible solution, but I know in the past I have rarely
had a database with data using only one SRS. We would usually store the
data in different UTM zones because the total area of the map was so
large, and needed to be accurate.

Brent Owens
TOPP



P.Rizzi Ag.Mobilità Ambiente wrote:

>What about providing a default SRS value server-wide???
>Something inside the config of GeoServer.
>I think most people will only use the very same SRS for all
>their tables, so a server-wide value should save client code
>most of the time.
>
>Bye
>Paolo Rizzi
>
>
>  
>
>>-----Messaggio originale-----
>>Da: Gabriel Roldán [mailto:[hidden email]]
>>Inviato: martedì 29 novembre 2005 19.54
>>A: [hidden email]
>>Cc: Brent Owens; Justin Deoliveira; David Blasby
>>Oggetto: Re: [Geoserver-devel] Re: about SRS parameter
>>
>>
>>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
>>
>>    
>>
>
>
>
>
>AVVERTENZE AI SENSI DEL D. LGS. 196/2003  
>Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
>file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
>utilizzo è consentito esclusivamente al destinatario del messaggio, per le
>finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
>senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
>via e-mail e di procedere alla distruzione del messaggio stesso,
>cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
>principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
>divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>utilizzarlo per finalità diverse.
>
>  
>


-------------------------------------------------------
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: R: Re: about SRS parameter

Gabriel Roldán-2
I guess he meant having a server wide CRS for output? meaning reprojecting as
needed but having consistent results if multiple layers are queried at the
same time?

I have to say that neither option seems better than being spec compliant to
me. That is, make it required, and if SRS=NONE is passed then return each
feature results in whatever its native CRS is. That's why I say wait till
after 1.3.0 to have time to advertise it to the users.

Gabriel

On Tuesday 29 November 2005 19:17, Brent Owens wrote:

> That could be a possible solution, but I know in the past I have rarely
> had a database with data using only one SRS. We would usually store the
> data in different UTM zones because the total area of the map was so
> large, and needed to be accurate.
>
> Brent Owens
> TOPP
>
> P.Rizzi Ag.Mobilità Ambiente wrote:
> >What about providing a default SRS value server-wide???
> >Something inside the config of GeoServer.
> >I think most people will only use the very same SRS for all
> >their tables, so a server-wide value should save client code
> >most of the time.
> >
> >Bye
> >Paolo Rizzi
> >
> >>-----Messaggio originale-----
> >>Da: Gabriel Roldán [mailto:[hidden email]]
> >>Inviato: martedì 29 novembre 2005 19.54
> >>A: [hidden email]
> >>Cc: Brent Owens; Justin Deoliveira; David Blasby
> >>Oggetto: Re: [Geoserver-devel] Re: about SRS parameter
> >>
> >>
> >>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
> >
> >AVVERTENZE AI SENSI DEL D. LGS. 196/2003
> >Le informazioni contenute in questo messaggio di posta elettronica e/o
> > nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il
> > loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> > per le finalità indicate nel messaggio stesso. Qualora riceveste questo
> > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> > darcene notizia via e-mail e di procedere alla distruzione del messaggio
> > stesso,
> >cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
> >principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
> >divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> >utilizzarlo per finalità diverse.
>
> -------------------------------------------------------
> 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: R: Re: about SRS parameter

P.Rizzi Ag.Mobilità Ambiente
In reply to this post by P.Rizzi Ag.Mobilità Ambiente
> I guess he meant having a server wide CRS for output? meaning
> reprojecting as
> needed but having consistent results if multiple layers are queried at
> the
> same time?
Yes, if SRS is not specified at all in the request, use the server-wide
parameter to reproject the results (better than arbitrarily
choosing WGS84).
If SRS=NONE is specifed, leave each layer with its own SRS.
If the SRS, specified or taken from config, matches the SRS of all
the requested layer, don't reproject at all.
People working on large areas will have various SRS, but people working
on urban areas would probably have just one SRS for every layer,
so they will suffer no reprojection most of the time.

Bye
Paolo Rizzi


> I have to say that neither option seems better than being spec > >
compliant
> to
> me. That is, make it required, and if SRS=NONE is passed then return
> each
> feature results in whatever its native CRS is. That's why I say wait
> till
> after 1.3.0 to have time to advertise it to the users.

> Gabriel

On Tuesday 29 November 2005 19:17, Brent Owens wrote:
> That could be a possible solution, but I know in the past I have
rarely
> had a database with data using only one SRS. We would usually store
the

> data in different UTM zones because the total area of the map was so
> large, and needed to be accurate.
>
> Brent Owens
> TOPP
>
> P.Rizzi Ag.Mobilità Ambiente wrote:
> >What about providing a default SRS value server-wide???
> >Something inside the config of GeoServer.
> >I think most people will only use the very same SRS for all
> >their tables, so a server-wide value should save client code
> >most of the time.
> >
> >Bye
> >Paolo Rizzi
> >
> >>-----Messaggio originale-----
> >>Da: Gabriel Roldán [mailto:[hidden email]]
> >>Inviato: martedì 29 novembre 2005 19.54
> >>A: [hidden email]
> >>Cc: Brent Owens; Justin Deoliveira; David Blasby
> >>Oggetto: Re: [Geoserver-devel] Re: about SRS parameter
> >>
> >>
> >>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
> >
> >AVVERTENZE AI SENSI DEL D. LGS. 196/2003
> >Le informazioni contenute in questo messaggio di posta elettronica
e/o
> > nel/i file/s allegato/i, sono da considerarsi strettamente
riservate. Il
> > loro utilizzo è consentito esclusivamente al destinatario del
messaggio,
> > per le finalità indicate nel messaggio stesso. Qualora riceveste
questo
> > messaggio senza esserne il destinatario, Vi preghiamo cortesemente
di
> > darcene notizia via e-mail e di procedere alla distruzione del
messaggio
> > stesso,
> >cancellandolo dal Vostro sistema; costituisce comportamento contrario
ai
> >principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio
stesso,
> >divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,
od
> >utilizzarlo per finalità diverse.
>
> -------------------------------------------------------
> 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




AVVERTENZE AI SENSI DEL D. LGS. 196/2003  
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.


-------------------------------------------------------
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