[Geoserver-devel] About WMS GetCapabilities and its specifications

Hi everyone,

I'd like to talk about standard for a GetCapabilities, which will be used for a WMS nD.
Here are my needs : a GetCapabilities that includes a time parameter, and for each date, the possibility to have several elevation values.
For one layer, I have several time values.

In the spec of WMS 1.1.1 GetCapabilities, we can see that the "Dimension" parameter only gets some attributes, like units ...
So I think about using the WMS 1.3.0. In the standards, the Dimension parameter can be filled with a list of time values, and a list of elevation values.
You can find an example of this kind of WMS 1.3.0 GetCapabilities here : http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xml.

In <Dimension name="time" ...>, it is possible to define a list of values. But it is not complusory that each values in the list of elevations can be used for each time values.
Indeed some elevation values may be out of the range for the coverage requested at a precise time...

So how can I deal with this problem ? Something that could resolve it would be to have the possibility to specify several <Dimension name="time" ...> properties, and specify in it this : <Dimension name="elevation" ...>0,100,200,500</Dimension>, but I don't see something like that in the WMS 1.3.0 specifications.
Another way would be to do that :
<Dimension name="elevation" *time="2007-07-01T4:01:11Z"* ...>0,100,200,500</Dimension>
But there is no time parameter possible for the dimension properties...

Regards,
Cédric Briançon.

I have no idea... But do know a better place to ask. Try: http://lists.eogeo.org/mailman/listinfo/wms-dev

And you know that GeoServer does not support WMS 1.3.0? Though it'd be a nice contribution if it did.

best regards,

Chris

Cédric Briançon wrote:

Hi everyone,

I'd like to talk about standard for a GetCapabilities, which will be used for a WMS nD.
Here are my needs : a GetCapabilities that includes a time parameter, and for each date, the possibility to have several elevation values.
For one layer, I have several time values.

In the spec of WMS 1.1.1 GetCapabilities, we can see that the "Dimension" parameter only gets some attributes, like units ...
So I think about using the WMS 1.3.0. In the standards, the Dimension parameter can be filled with a list of time values, and a list of elevation values.
You can find an example of this kind of WMS 1.3.0 GetCapabilities here : http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xml.

In <Dimension name="time" ...>, it is possible to define a list of values. But it is not complusory that each values in the list of elevations can be used for each time values.
Indeed some elevation values may be out of the range for the coverage requested at a precise time...

So how can I deal with this problem ? Something that could resolve it would be to have the possibility to specify several <Dimension name="time" ...> properties, and specify in it this : <Dimension name="elevation" ...>0,100,200,500</Dimension>, but I don't see something like that in the WMS 1.3.0 specifications.
Another way would be to do that :
<Dimension name="elevation" *time="2007-07-01T4:01:11Z"* ...>0,100,200,500</Dimension>
But there is no time parameter possible for the dimension properties...

Regards,
Cédric Briançon.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,4695f631151793327367457!

Chris Holmes a écrit :

I have no idea... But do know a better place to ask. Try: http://lists.eogeo.org/mailman/listinfo/wms-dev

And you know that GeoServer does not support WMS 1.3.0? Though it'd be a nice contribution if it did.

More investigations into the WMS 1.1.1 GetCapabilities specifications lead me to this :
<Dimension name="time" units="ISO8601"/>
<Dimension name="elevation" units="EPSG:5030"/>
<Extent name="time" default="2000-08-22">1999-01-01/2000-08-22/P1D</Extent>
<Extent name="elevation" default="0" nearestValue="1">0,1000,3000,5000,10000</Extent>

So in fact, with the extent element, I can specify a time value, or coma-separated list of time values, as I want. Consequently I can stay in WMS 1.1.1 to handle WMS nD.

But the same problem is still here.
<Dimension name="time" units="ISO8601"/>
<Dimension name="elevation" units="EPSG:5030"/>
<Extent name="time" default="2000-08-22T12:05:00Z">2000-08-22T12:05:00Z,2000-08-23T13:05:00Z,2000-08-24T12:05:00Z</Extent>
<Extent name="elevation" default="0" nearestValue="1">0,1000,3000,5000,10000</Extent>

If I specify this, the elevation is the same for all the dates present, and it may not be right.

best regards,

Chris

Cédric Briançon wrote:

Hi everyone,

I'd like to talk about standard for a GetCapabilities, which will be used for a WMS nD.
Here are my needs : a GetCapabilities that includes a time parameter, and for each date, the possibility to have several elevation values.
For one layer, I have several time values.

In the spec of WMS 1.1.1 GetCapabilities, we can see that the "Dimension" parameter only gets some attributes, like units ...
So I think about using the WMS 1.3.0. In the standards, the Dimension parameter can be filled with a list of time values, and a list of elevation values.
You can find an example of this kind of WMS 1.3.0 GetCapabilities here : http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xml.

In <Dimension name="time" ...>, it is possible to define a list of values. But it is not complusory that each values in the list of elevations can be used for each time values.
Indeed some elevation values may be out of the range for the coverage requested at a precise time...

So how can I deal with this problem ? Something that could resolve it would be to have the possibility to specify several <Dimension name="time" ...> properties, and specify in it this : <Dimension name="elevation" ...>0,100,200,500</Dimension>, but I don't see something like that in the WMS 1.3.0 specifications.
Another way would be to do that :
<Dimension name="elevation" *time="2007-07-01T4:01:11Z"* ...>0,100,200,500</Dimension>
But there is no time parameter possible for the dimension properties...

Regards,
Cédric Briançon.

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

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,4695f631151793327367457!

Hi all!

I'm working at the moment on a project where we want to use Geoserver as a cascading WFS. When I tried to use the WFS-DataStore in Geoserver, I couldn't even configure the WFS-DataStore. Entering a GET_CAPABILITIES_URL always ended in a "Could not find file..."-error.

This error has actually already been reported (http://www.nabble.com/WFS-as-datastore-t3945274.html) and jira-issue already exists (http://jira.codehaus.org/browse/GEOS-1164). Since I need to run Geoserver as cascading WFS quite urgently, I decided to try to fix this problem myself.

According to the response to the error report the problem is:

> As for you specific error, I believe that you're getting stuck because
> of a check we added lately. Basically, we were fed up of noticing
> shapefiles were badly configured (wrong path) only when trying to
> setup the feature type, so we added a generic check for URL existance
> on the file system... that is because both raster data and shapefiles
> use URL as the parameter that holds the "on the file system" path.
>
> That's obviously not working in your case, where the URL is a real
> internet URL for a change.

Since it was so well described, even I could locate the function that causes the problem, fix (somehow) the problem and now I can configure Geoserver as cascading WFS. To solve the problem I simply check the protocol of the URL and only perform the existence check if the protocol is "file". I only had to change the "special case check for url"-bit in the method "public ActionErrors validate(ActionMapping mapping, HttpServletRequest request)" in "/web/src/main/java/org/vfny/geoserver/form/data/DataDataStoresEditorForm.java". It looks now like this:

           //special case check for url
            if (URL.class.equals(param.type)) {
                String value = getParamValue(i);

                if ((value != null) && !"".equals(value)) {
                    URL url = null;

                    try {
                        // if this does not throw an exception then cool
                        url = new URL(value);
                       
                        if (url.getProtocol().equals("file")) {
                                                   //do a check to see if the file url is valid, report
                            // an error if it does not
                            File file = GeoserverDataDirectory.findDataFile(value);
                            FormUtils.checkFileExistsAndCanRead(file, errors);
                        }
                       
                        //check for special case of file
                        try {
                            if (GeoserverDataDirectory.findDataFile(value).exists()) {
                                new URL("file://" + value);
                                setParamValues(i, "file://" + value);
                                //do a check to see if the file url is valid, report
                                // an error if it does not
                                File file = GeoserverDataDirectory.findDataFile(value);
                                FormUtils.checkFileExistsAndCanRead(file, errors);
                            }
                        } catch (MalformedURLException e1) {
                            //replace that with an adequate error message
                            String actionKey = "error.file.NotExists";
                            Object params = new Object { value };
                            errors.add("URL", new ActionMessage(actionKey, params));
                        }
                    }

                    return errors;
                }
            }

However this is my first encounter with the Geoserver code and I am not sure which other, possibly negative effects the changes I made in the code might have. So I wanted to ask you, if you could have a look at my solution and tell me if you think it's ok...

It would be great, if anyone could help me with that!

Thanks,
stefan

ps.
I also attached the my version of DataDataStoresEditorForm.java

(attachments)

DataDataStoresEditorForm.java (15.5 KB)

Stefan Hansen ha scritto:

Hi all!

...

To solve the problem I simply check the protocol of the URL and only perform the existence check if the protocol is "file". I only had to change the "special case check for url"-bit in the method "public ActionErrors validate(ActionMapping mapping, HttpServletRequest request)" in "/web/src/main/java/org/vfny/geoserver/form/data/DataDataStoresEditorForm.java". It looks now like this:

          //special case check for url
           if (URL.class.equals(param.type)) {
               String value = getParamValue(i);

               if ((value != null) && !"".equals(value)) {
                   URL url = null;

                   try {
                       // if this does not throw an exception then cool
                       url = new URL(value);
                                                                   //Only check file existence if protocol equals file
                       if (url.getProtocol().equals("file")) {
                                                 //do a check to see if the file url is valid, report
                           // an error if it does not
                           File file = GeoserverDataDirectory.findDataFile(value);
                           FormUtils.checkFileExistsAndCanRead(file, errors);
                       }
                                                               } catch (MalformedURLException e) {
                       //check for special case of file
                       try {
                           if (GeoserverDataDirectory.findDataFile(value).exists()) {
                               new URL("file://" + value);
                               setParamValues(i, "file://" + value);
                               //do a check to see if the file url is valid, report
                               // an error if it does not
                               File file = GeoserverDataDirectory.findDataFile(value);
                               FormUtils.checkFileExistsAndCanRead(file, errors);
                           }
                       } catch (MalformedURLException e1) {
                           //replace that with an adequate error message
                           String actionKey = "error.file.NotExists";
                           Object params = new Object { value };
                           errors.add("URL", new ActionMessage(actionKey, params));
                       }
                   }

                   return errors;
               }
           }

However this is my first encounter with the Geoserver code and I am not sure which other, possibly negative effects the changes I made in the code might have. So I wanted to ask you, if you could have a look at my solution and tell me if you think it's ok...

Stefan, the patch looks ok to me. Chris, Justin, can you think of any case where this may be troublesome?

As for cascading WFS, great that you use it, but beware, the WFS datastore can cascade fine servers that do not use namespace qualified
layer names, as in "layerName", but usually fails if the layer name is
"namespace:layerName". Long story short, you can't cascade another GeoServer...
It is a bug in the datastore that has to be resolved, the layer name
should be stripped of the namespace prefix, or you could just change
the ":" char with an "_" and be done with it. The trouble is that
when serving a "x:y" typename we would add our namespace as well,
creating a "z:x:y" name that is invalid according to the GML schema.

Cheers
Andrea