WFS Source (beta): support multiple label names
Following the WFS Source documentation here, you can create a custom layout by setting the URL template pointing to custom map data, and a label name. The label name is used to extract a string from the data point and use it to decorate the map.
Today, CalTopo expects this label name field to exist on all data points that come back from that server URL endpoint, if it does not for a specific data point, it falls back to using the ID number of the data point. This enhancement request is to ask to be able to specify backup, secondary label names in order to support those third-party maps that might have missing label name fields, but could have other fields that can be used as a backup label name.
You can see this real life scenario with the following data.
- Elect to create a "WFS Source(beta)" object in your map
- Set the URL Template to this: https://mapsdep.nj.gov/arcgis/rest/services/Features/Land/MapServer/62/query?where=1%3D1&f=geojson&geometry={left},{bottom},{right},{top}&geometryType=esriGeometryEnvelope&spatialRel=esriSpatialRelIntersects&inSR=4326&outSR=4326&outFields=*&returnGeometry=true
- Set the Label Name to this: FEATURE_NAME
FEATURE_NAME is the correct label to use here - this is what we want all the data points to use as their label (the value of the label identifies if the data point is a parking lot, a boat ramp, etc.). Almost all (but NOT all) data points in this map contain the FEATURE_NAME field. Some do not (likely a mistake on the data author's part), but those that do not will have another field that could be used to label the data point.
See the screenshots below where you can see there are two data points, one labeled as "Rainbow Lake Parking" and one labeled "17437".
When you look at the Rainbow Lake Parking data point, you can see it has the label FEATURE_NAME (whose value is, obviously, "Rainbow Lake Parking"). However, the "17437" data point does NOT have a FEATURE_NAME field. But, it does have a couple fields that could be useful to show as a substitute - either FACILITY_NAME or FEATURE_TYPE. Either one is certainly more useful to the user than the ID number 17437 that CalTopo uses by default.
So this enhancement request is simply to be able to define a fallback default label name that CalTopo will use in the case when the first Label Name does not exist (as opposed to the ID number as the default, which is how it works today).
A simple solution would be to accept a comma-separated list of Label Names in the Label Name field. So, in this example, if I was able to set the Label name as "FEATURE_NAME,FACILITY_LABEL", this could tell CalTopo, "Use the FEATURE_NAME label, but if it does not exist use the FACILITY_LABEL label. If that doesn't exist, then fallback to the ID number as before." Extending further, you can allow N number of labels - in case FACILITY_LABEL doesn't exist, too, I could opt to specify a third label to fallback to -- e.g. "FEATURE_NAME,FACILITY_LABEL,FEATURE_TYPE". If no labels at all exist, CalTopo would simply default to what it does today - that is, use the ID number of the data point.
If this were supported, you would see that data point labeled with "Rainbow Lake Wildlife Management Area" which is certainly more useful and descriptive than the ID number currently being shown ("17437").
Comments
3 comments
I know this probably isn't a helpful response, but WFS layer styling is a place where we have let perfect be the enemy of good enough, and will probably continue to do so in the near term.
In the long term, we'd like to let users define rules for how to label and style objects based on attributes - so that beyond the label, you could for example color all FEATURE_CLASS="access" features blue. There isn't a well-standardized way of doing this, which means we have to come up with our own syntax. And for the part where perfect becomes the enemy of good enough, the more customizations we allow now, the harder it is to make existing layers forward-compatible with the syntax rules we define. Your comma suggestion makes sense as an incremental improvement on what we have, but if we go that route, we're now tied to using commas a certain way when we introduce broader styling changes.
> we'd like to let users define rules for how to label and style objects based on attributes
Even better :)
If that work is scheduled in the backlog or already in progress, then you can just close out this feature request since it will be encompassed by that longer term design goal.
BTW: If you need a beta tester for these new features, you know where to look ;)
Please sign in to leave a comment.