Excellent summary, probably should be in the docs or a blog post :)
I always view it as name being for machine to machine communication (never
shown to users) and title being human readable.
Jody Garnett
On Thu, Sep 4, 2014 at 6:16 AM, Rahkonen Jukka (Tike) <
jukka.rahko...@mmmtike.fi> wrote:
> Hi,
>
>
>
> This may be TL;DR. However, names with special characters are an eternal
> battle. If someone verifies that what I write makes sense it might be good
> to include it in some place in Geoserver documentation.
>
>
>
> Short version: WMS standard allows anything in layer names but WFS
> standard puts strict rules for feature type names. By default Geoserver is
> using same names in both WMS and WFS services which means sooner or later
> troubles if the more strict rules are not followed. Wise people follow the
> rule: Name must start with either a letter or underscore (_) and may
> contain only letters, digits, underscores (_), hyphens (-), and periods (.).
>
>
>
> Long story: I have been fighting with peculiar WMS layer names and WFS
> feature type names sometimes and my current interpretation of what is valid
> and what is not is as follows.
>
>
>
> In WMS almost anything is allowed in layer names. I base this on WMS 1.3.0
> schema http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd
>
> It says:
>
> <!-- ** Elements Used In Multiple Places. ** -->
>
> <element name="Name" type="string">
>
> <annotation>
>
> <documentation>
>
> The Name is typically for machine-to-machine communication.
>
> </documentation>
>
> </annotation>
>
> </element>
>
>
>
> AND:
>
> <element name="Layer">
>
> <annotation>
>
> <documentation>
>
> Nested list of zero or more map Layers offered by this server.
>
> </documentation>
>
> </annotation>
>
> <complexType>
>
> <sequence>
>
> <element ref="wms:Name" minOccurs="0"/>
>
>
>
> So a layer name in WMS is defined to be just a string. Thanks to Andreas
> Eichner
> http://osgeo-org.1560.x6.nabble.com/cascading-wms-and-layer-names-encoding-td5058504.html
> I have learned that xs:string is a
>
> "... finite-length sequence of characters that match the Char production
>
> from [XML 1.0 (Second Edition)]" whereby Char is defined as:
>
>
>
> Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] |
>
> [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character,
>
> excluding the surrogate blocks, FFFE, and FFFF. */
>
>
>
> or in other words: almost every character.”
>
>
>
> However, in WFS situation is different. WFS 1.1.0 schema
> http://schemas.opengis.net/wfs/1.1.0/wfs.xsd specifies that feature type
> has a name that is of type QName
>
> <xsd:complexType name="FeatureTypeType">
>
> <xsd:annotation>
>
> <xsd:documentation>
>
> An element of this type that describes a feature in an
> application
>
> namespace shall have an xml xmlns specifier, e.g.
>
> xmlns:bo="http://www.BlueOx.org/BlueOx";
>
> </xsd:documentation>
>
> </xsd:annotation>
>
> <xsd:sequence>
>
> <xsd:element name="Name" type="xsd:QName">
>
>
>
> QName stands for qualified name
> http://books.xmlschemata.org/relaxng/ch19-77287.html and it is xsd:NCName
> with an optional prexif. Finally we get into NCName which has quite a many
> restrictions http://www.datypic.com/sc/xsd/t-xsd_NCName.html
>
>
>
> Therefore a WFS typeName must start with either a letter or underscore (_)
> and may contain only letters, digits, underscores (_), hyphens (-), and
> periods (.). WFS typeName which begins with a number is invalid, as well as
> names with colons in any place in the body of the name because colon is
> reserved for the namespace in the xsd:QName.
>
>
>
> -Jukka Rahkonen-
>
>
>
>
>
>
>
> *Lähettäjä:* Jody Garnett [mailto:jody.garn...@gmail.com]
> *Lähetetty:* 3. syyskuuta 2014 23:19
> *Vastaanottaja:* Bessette-Halsema, Dominique E
> *Kopio:* geoserver-users
> *Aihe:* Re: [Geoserver-users] [Geoserver-devel] wms getCapabilities
> special characters
>
>
>
> You should ask on the user list :) The devel-list is for those working on
> the GeoServer application.
>
>
>
> The WMS and WFS specifications dictate what is allowed as a layer name -
> in particular the WFS specification should have some limitations based on
> the structure of XML documents (which uses the format "prefix:identifier" -
> where prefix is mapped to an XML schema namespace).
>
>
>
> Check the specifications and let us know what you find? I expect in this
> case that even if GeoServer lets you add additional characters XML parsers
> and WFS clients will not be able to handle the situation.
>
>
>
> (Note the GeoServer web application and REST API will often allow you to
> configure setting that do not work, when you spot an example please report
> the issue).
>
> --
>
> Jody
>
>
>
>
>
>
> Jody Garnett
>
>
>
> On Wed, Sep 3, 2014 at 10:28 AM, Bessette-Halsema, Dominique E <
> dominique.besse...@gdit.com> wrote:
>
> I added a colon ‘:’ character to a grid name. Is this allowed in the WMS
> getCapabilities? Or is this a special character? I know this isn’t the
> recommended naming convention but it is required and I need to go back and
> accurately explain why it may or may not work.
>
>
>
> Where in the geoserver code is the WMS getCapabilities name set?
>
>
>
> For example: imagery:goes_13.infrared.1km
>
>
>
> In the WCS getCapabilities the identifier has the correct name
>
>
>
> <wcs:CoverageSummary>
>
> <ows:Title>infrared-goes_13 1km</ows:Title>
>
>
> <ows:Metadata metadataType="other" xlink:type="simple"
> xlink:href="/rest/metadata?request=getMetadata&layer=imagery:goes_13.infrared.1km"/>
>
> <ows:WGS84BoundingBox>
>
> <ows:LowerCorner>-120.0038771 -65.0093883</ows:LowerCorner>
>
> <ows:UpperCorner>-44.9961229 65.0093883</ows:UpperCorner>
>
> </ows:WGS84BoundingBox>
>
> <wcs:Identifier>*imagery:goes_13.infrared.1km*</wcs:Identifier>
>
> </wcs:CoverageSummary>
>
>
>
>
>
> In the WMS getCapabilities the Name is not correct it cuts off after the
> colon
>
>
>
> -<Layer opaque="0" queryable="1">
>
> <Name>*imagery*</Name>
>
> <Title>infrared-goes_13 1km</Title>
>
> …..
>
> </Layer>
>
>
>
> The WCS describecoverage looks correct, just odd because of the naming
> convention.
>
>
>
> wcs:CoverageDescription>
>
> <ows:Title>infrared-goes_13 1km</ows:Title>
>
> <ows:Abstract/>
>
> <ows:Keywords/>
>
> <wcs:Identifier>*imagery:imagery:goes_13.infrared.1km*</wcs:Identifier>
>
>
>
> ………….
>
>
>
> Dominique Bessette
>
> Engineer, Software
>
> General Dynamics Information Technology
>
> Supporting Fleet Numerical Meteorology and Oceanography Center (FNMOC)
>
> Office: 619-881-2748
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
