You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current spec uses center as an anchor. This works well for symbols like monument, bank, hospital, logo etc.
For symbols like pin, marker, location, and flag it appears a bit off because they should be anchored to the bottom.
Currently, there is a workaround to create an icon with double the height while leaving the bottom half as a whitespace. This disables you from using icon links from public CDNs.
label
Label is probably the most commonly used feature in geospatial files that I know. Labels are the text displayed on the map:
Most commonly created by anchoring some text to a marker (or without it by not providing a marker-symbol at all).
Also seen attached to streets, roads, routes, cables, pipes etc.
And very loved on polygons as plot IDs, names, area values, prices etc.
I considered using title for label, but it just doesn't work in some cases:
Apple Inc. vs just Apple
Kaunas University of Technology vs KTU
Hospital of Lithuanian University of Health Sciences Kaunas Clinics vs Klinikos abbr.
label-anchor
label-anchor is mostly used as a balancing mechanism to align marker-symbol with label properly. The most common use case is to set marker-anchor as bottom and label-anchor as top.
Some maps have their own handling of label-anchor position (i.e. mapbox), while others don't (i.e. google).
In theory, it might be smart to set the default value for label-anchor as reverse to marker-anchor, but it might lead to some strange placement (i.e. while using corner placement).
There are also cases where you don't give a damn about label placement (marker-symbol = brand logo, marker-anchor = center, label = short brand name, and label on either side (in Latin preferably placed in either horizontal side because of horizontal text orientation compared to some Asian languages))
The text was updated successfully, but these errors were encountered:
Hello,
I suggest adding three additional properties to the spec.
marker-anchor
In my practice, I noticed that
marker-anchor
is a commonly used property to define the relative position of the icon vs the actual position in the coordinate system.Google used pixel coordinates to set the anchor (x, y).
While Mapbox uses CSS like string positions (
center
,bottom
,bottom-left
...).The current spec uses
center
as an anchor. This works well for symbols likemonument
,bank
,hospital
,logo
etc.For symbols like
pin
,marker
,location
, andflag
it appears a bit off because they should be anchored to thebottom
.Currently, there is a workaround to create an icon with double the height while leaving the bottom half as a whitespace. This disables you from using icon links from public CDNs.
label
Label is probably the most commonly used feature in geospatial files that I know. Labels are the text displayed on the map:
marker-symbol
at all).I considered using
title
forlabel
, but it just doesn't work in some cases:Apple Inc.
vs justApple
Kaunas University of Technology
vsKTU
Hospital of Lithuanian University of Health Sciences Kaunas Clinics
vsKlinikos
abbr.label-anchor
label-anchor
is mostly used as a balancing mechanism to alignmarker-symbol
withlabel
properly. The most common use case is to setmarker-anchor
asbottom
andlabel-anchor
astop
.Some maps have their own handling of
label-anchor
position (i.e. mapbox), while others don't (i.e. google).In theory, it might be smart to set the default value for
label-anchor
as reverse tomarker-anchor
, but it might lead to some strange placement (i.e. while using corner placement).There are also cases where you don't give a damn about label placement (
marker-symbol
= brand logo,marker-anchor
=center
,label
= short brand name, and label on either side (in Latin preferably placed in either horizontal side because of horizontal text orientation compared to some Asian languages))The text was updated successfully, but these errors were encountered: