Opened 16 years ago
Closed 16 years ago
#2414 closed enhancement (fixed)
support srsName in GetObservation
| Reported by: | tomkralidis | Owned by: | tomkralidis |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.2 release |
| Component: | SOS Server | Version: | svn-trunk (development) |
| Severity: | normal | Keywords: | |
| Cc: | assefa, cplist |
Description
SOS optionally allows for the client to request OM in any gml:srsName element advertised in GetCapabilities.
For SOS Server to support this, the following would have to be implemented:
- allow for a list of srs in sos_srs; advertise them in Capabilities XML
- support srsName in GET and POST requests in msSOSParseRequest
- do the reprojection on the resultset data in msSOSGetObservation
Change History (7)
follow-up: 2 comment:1 by , 16 years ago
comment:2 by , 16 years ago
Replying to tomkralidis:
I've been trying to figure this one and have come to the conclusion that discussion is needed. FYI note that #2558 is affected by this.
Assefa: what is SOS Server's position on multiple projections? It looks like from mapogcsos.c that only one EPSG code is supported a la WFS Server. Can you confirm?
Correct. geometry and srs are returned in the map projection.
If we are to support multiple SRSs, we should
- decipher where we want SRS metadata defined (in WEB/METADATA or LAYER/METADATA). Which one? Both? The difference with SOS Server and, say, WMS Server is that WMS has a "root" set of SRS codes, whereas for SOS Server it is at the ObservationOffering level, which, for us, is at the same level at the LAYER level.
What is our strategy here? Do we define WEB/METADATA/sos|ows_srs and only use LAYER/METADATA/sos|ows_srs to override if defined?
Once we decide on this, we can apply to GetCapabilities output. We already fetch srsName for GET or POST requests, so that's done. We then have to apply to msSOSGetObservation.
I would see using the web/metadata as a mechanism to advertise the multiple srs supported. When we get the the request we check if it is a valid(advertised) srs and if that is the case we set the map projection. I think using layer level projection for this would be confusing (since several layers can be part of an observation) and I see no real gain for it.
... checking the code ... We currently advertise the srs of the layer (around line 1434) I think that is a problem since the geometries/srs returned are in the map srs. The more I think about this, I believe that the layer level sos srs should not exist; we should simply advertise at a minimum the map srs and if the web/sos_srs list is defined, advertise that also .
comment:3 by , 16 years ago
| Milestone: | FUTURE → 5.2 release |
|---|
comment:4 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I will try to make this change this weekend. Any final thoughts to moving sos_srs to MAP.WEB.METADATA?
comment:5 by , 16 years ago
FYI GetCapabilities output of 0..* gml:srsName elements as per MAP.WEB.METADATA.sos_srs now committed via r7678.
Once GetObservation support for srsName is implemented, I'll update the docs as well.
comment:7 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
I've been trying to figure this one and have come to the conclusion that discussion is needed. FYI note that #2558 is affected by this.
Assefa: what is SOS Server's position on multiple projections? It looks like from mapogcsos.c that only one EPSG code is supported a la WFS Server. Can you confirm?
If we are to support multiple SRSs, we should
What is our strategy here? Do we define WEB/METADATA/sos|ows_srs and only use LAYER/METADATA/sos|ows_srs to override if defined?
Once we decide on this, we can apply to GetCapabilities output. We already fetch srsName for GET or POST requests, so that's done. We then have to apply to msSOSGetObservation.