Tools like the image gallery are causing requirements that are more difficult to deal with. One is that the layer needs to draw with appropriate label handling for markers. This discussion actually applies to any feature type but let's focus on points, which is the bulk of the requirements.
We have so far avoided labeling layer markers with any type of text and have instead relied on mouse-over to show information. Labels for a busy map introduce a lot of text, which when overlapping is unreadable. Also, the human brain's short-term memory limits make it difficult to absorb lots of text. The search feature via data table is a better way to find data than visually scanning over many markers and their labels. It may be necessary to label markers in some cases, either with text within a marker (such as done at TriLynx Systems) or a label outside of the marker.
However, the implementation of the image gallery has introduced a need to label markers because there is a visual link between those markers and the images in the gallery. This design has been demonstrated by Esri and other tools and makes sense. Below are technical considerations.
The symbol properties is the logical place to include new properties for the label. See the following resources for label properties in other software.
Previous mapping work with TSTool Java software used LabelField, LabelFontName, LabelFontSize, LabelFormat, and LabelPosition (UpperRight, Right, LowerRight, Below, LowerLeft, Left, UpperLeft, and Above. These should be consistent with the marker positions that have been implemented. FontSize is also appropriate.
Use a JSON property labelText and allow property notation such as ${featureAttribute:AttributeName}. Multiple attributes could therefore be used if necessary and expanded when displayed. Additionally, the following modifier functions could be supported to address needs of the image gallery:
featurePosition() - the position in the layer, 1+, based on a lookup of the attribute value.
Or, support labelText=featurePosition() or labelText=FeaturePosition directly? Supporting the modifier function would allow something like labelText=${featureAttribute:id}.featurePosition() - ${featureAttribute:id}
If not labelText is not used, then no text label is shown (the current default).
labelPosition - see above, with default to Below?
labelFontName - pick something for now, can support more later. Handle with CSS with defaults.
labelFontSize - pick something for now and can support functionality later including font units of px, etc. This should be handled through CSS with defaults.
For normal situations, no label properties will be shown and missing labelText would indicate no label. If an image gallery is used, do we require labelText or default? Does the image gallery still work if no labels are shown? It is OK to choose defaults that override other default behavior, but need to be able to document.
Tools like the image gallery are causing requirements that are more difficult to deal with. One is that the layer needs to draw with appropriate label handling for markers. This discussion actually applies to any feature type but let's focus on points, which is the bulk of the requirements.
We have so far avoided labeling layer markers with any type of text and have instead relied on mouse-over to show information. Labels for a busy map introduce a lot of text, which when overlapping is unreadable. Also, the human brain's short-term memory limits make it difficult to absorb lots of text. The search feature via data table is a better way to find data than visually scanning over many markers and their labels. It may be necessary to label markers in some cases, either with text within a marker (such as done at TriLynx Systems) or a label outside of the marker.
However, the implementation of the image gallery has introduced a need to label markers because there is a visual link between those markers and the images in the gallery. This design has been demonstrated by Esri and other tools and makes sense. Below are technical considerations.
LabelField,LabelFontName,LabelFontSize,LabelFormat, andLabelPosition(UpperRight,Right,LowerRight,Below,LowerLeft,Left,UpperLeft, andAbove. These should be consistent with the marker positions that have been implemented.FontSizeis also appropriate.labelTextand allow property notation such as${featureAttribute:AttributeName}. Multiple attributes could therefore be used if necessary and expanded when displayed. Additionally, the following modifier functions could be supported to address needs of the image gallery:featurePosition()- the position in the layer, 1+, based on a lookup of the attribute value.labelText=featurePosition()orlabelText=FeaturePositiondirectly? Supporting the modifier function would allow something likelabelText=${featureAttribute:id}.featurePosition() - ${featureAttribute:id}labelTextis not used, then no text label is shown (the current default).labelPosition- see above, with default toBelow?labelFontName- pick something for now, can support more later. Handle with CSS with defaults.labelFontSize- pick something for now and can support functionality later including font units of px, etc. This should be handled through CSS with defaults.For normal situations, no label properties will be shown and missing
labelTextwould indicate no label. If an image gallery is used, do we requirelabelTextor default? Does the image gallery still work if no labels are shown? It is OK to choose defaults that override other default behavior, but need to be able to document.