WFS Feature Attributes for Image URLs and Custom Lists?

GeoServer GeoServer User
,
1

Hi, we are currently evaluating GeoServer as a means to publish our geolocation data with custom attributes. My question is about how custom attribute types can be delivered and rendered in a client like QGIS.

Basically, we have a large DB of geolocations (points), and each point has one or more image URLs attached to it, as well as custom attributes, including lists.

One list might be called ‘point_type’, and be of integer type with allowed values 93, 94, 95. Each value corresponds to some textual description, like “Type A”, “Type B”, “Type C” that is shown to users in our app instead of the raw values.

The table containing our data is published as a layer in GeoServer. So when a GIS client makes a WFS query, it gets the raw data and can display it as such, i.e. the URL is a text string and the list is a number.

My question is: in a standards-conformant GIS client, is it possible to display the actual image instead of the URL, and the textual descriptions instead of the list values?

For textual descriptions, we would also want to include multilingual support, so they can be displayed in a user-defined language.

I suppose XML would be well suited to encode image URLs and custom attribute types, but is this supported in the WFS standard?

I have been searching the WFS specification and the Internet for several hours, but could not find any indication or example of this working. I would like to get more confirmation this is not possible without custom client code though, before looking for a different solution.

2

Hey @stf976 welcome back to the user forum.

I am hard pressed to know how to respond to your question; as the WFS protocol is more for machine to machine communication and provides access to data rather than anything approaching interactive experience. It is up to the client app (such as QGIS) to provide the experience desired.

So your question about “using a standards confirming GIS client” is really to be directed … to a client such as QGIS, or one of the many applications built with OpenLayers.

So here are some ideas:

  1. The WMS protocol is slightly higher level, and allows you to configure the layer with a template of what to show when the user clicks on the map. See the example here which would let you configure what is shown in QGIS when map is clicked on.

  2. GeoServer does let you modify the feature type details on the fly as a transformation, so you could use an expression to show strings rather than the raw values: RECODE( value, 1, "hello", 2, "world")

  3. QGIS lets you configure how stuff is displayed when selected with the attribute table, identify tool, labels, custom attributes forms (there is a form designer), and so on …

3

Thank you @jive for your reply. You are absolutely correct that questions regarding how a client displays data is best directed to the client. I will try to rephrase my question to hopefully make it more clear what I am trying to get at. A possible solution might also exist, as mentioned below.

The ideal goal would be an infrastructure where a client can query data from our GeoServer using WFS and interpret it in a way that goes beyond opaque strings and numbers. For example, to have the server describe in a machine-readable form that one string attribute is an image URL, and a numeric attribute is associated with a list of textual descriptions of its values (possibly in multiple languages).

Ideally, this should be done within the bounds of the WFS specification and related standards, that is without any proprietary extensions or custom client logic. So the questions is first and foremost how GeoServer can provide data in such a way using WFS, and if WFS is suitable for this purpose at all. It is not so much about whether any GIS client can fully interpret and visualize that data right now, but whether it could possibly be made to, only relying on WFS and other standards.

Having a HTML template for WMS GetFeatureInfo requests is an interesting option that could be useful to us. In the context of WMS, SLD transformations might also come in handy. WFS is mostly of interest as it provides direct access to feature attributes instead of a visual representation and allows for complex queries on feature attributes.

Reading further on the topic of WFS queries and the GeoServer documentation, it seems the app-schema extension is exactly what we are looking for. It enables complex features for WFS, which are expressed in GML and can include standardized XML schema definitions, such as GeoSciML, as well as custom schemas as needed.

This would allow us to define an information model with proper type annotations for publishing our data. In theory, any client that understands GML could then interpret the data based on its types, e.g. for visualization (at least for the standardized schemas), without requiring custom configuration. At least this is my understanding so far.

Regarding internationalization, GeoSciML for example provides vocabularies for its concepts which contain translations of textual descriptions (see e.g. cgi-vocabs/vocabularies/geosciml at master · CGI-IUGS/cgi-vocabs · GitHub). However, I will have to do further research to determine which user applications, if any, can process these vocabularies to provide translations of GML data.

So far, the app-schema extension and GML seems a good approach to provide a full information model to users of our data. I suppose it will also depend on tool/client support whether it is worth the effort or a ‘flat’ data format is more appropriate.

1 Like
4

Hey you are starting to pull the bits of the standard to gather. I will caution that GML allows you to define your own custom data format using XML - so while you can indicate that an specific URL attribute is an image (and that is great) - this does not mean that clients will automatically know what you are talking bout.

In the case of GeoSciML a bunch of scientists got together to define their terms and share as an application schema (defining a new set of spatial files; which people could then develop tools to work with).

Another approach is the “linked data” or LD approach used for xml and json documents; this is a bit more high level and was defined by Facebook or someone to enable scraping web pages (probably for AI training data). There has not been a lot of use of these standards in the Geo world yet, but you see it more with meta data and records.

I am personally not sure if you mark your FeatureType with this information:

<xs:elment name="photo" vocab="http://schema.org/image" type="xs:string"/>

Or mark the resulting document (probably the resulting document):

<photo vocab="http://schema.org/image">https://geoserver.org/img/geoserver-logo.png</photo>

Whatever the correct the approach, the idea is a “generic” client would know the URL could be displayed as an image.

If anyone knows this stuff I would be interested to learn more!

SDI: I encourage you to try the WMS GetFeatureInfo and recognize that the different standards (WMS + WFS + WMTS) are intended to be used to gather (technically as a "spatial data infrastructure SDI thing).

5

The linked data approach might be of interest too. Right now it is more about assessing the available options than implementing a specific solution.

As you mentioned, WFS is more for machine to machine communication, so that is one use case we would like to cover. We have already setup WMS/WMTS services for map visualizations, and WMS GetFeatureInfo looks like a good addition to that.

GML and Linked Data in particular seem like viable approaches for defining a machine-readable information model. I will mark the question as answered. Thank you for the feedback!