Feature names appear in ALL CAPS vs normal case in HERE Map data

Issue
---------

Customers notice that feature names (e.g., street names, POIs, administrative names) are displayed differently depending on the HERE data format being used. For example, street names appear in ALL CAPS vs normal case like "MICHIGAN AVE" vs "Michigan Ave".

### Symptoms / Triggers

You may experience this behavior if:

Street names appear in ALL CAPITAL LETTERS (e.g., MICHIGAN AVE) instead of normal readable format (e.g., Michigan Ave)
The same dataset shows different casing when switching between formats (e.g., Shapefile vs geodatabase/API)
POI, address, or road names appear less readable or inconsistent across systems
Data exported from HERE differs from what is shown in maps, SDKs, or APIs
You are consuming legacy HERE data (e.g., Shapefile-based) and comparing it with modern HERE data

Cause
---------

This behavior occurs because feature-name casing depends on the HERE data format used.

NavStreets (Shapefile format) publishes feature names in uppercase only (ALL CAPS)
Modern HERE data formats (e.g., file geodatabase, GIS Data Suite, APIs, SDK data) preserve natural mixed casing (uppercase/lowercase)

This difference is due to:

Legacy format limitations (Shapefile-based datasets used simplified naming conventions)
Modern HERE data models supporting language-aware, structured text fields (e.g., STREET_NAME, STREET_NAME_LATIN, name:en)
Internal naming rules that normalize names into mixed case for readability, even if the original signage is uppercase

Example:

Raw signage: MICHIGAN AVE
Modern HERE datasets: Michigan Ave

Additionally:

Mixed case is only applied to languages that support uppercase/lowercase distinctions
Some scripts (e.g., Chinese, Arabic) do not use casing in the same way

Resolution
--------------

The quick answer is, the difference in casing is expected behavior based on the data format.
To use readable, mixed-case names, switch to modern HERE data formats or APIs.

### Options

1. Use modern HERE datasets (recommended)
Examples: HERE GIS Data Suite, File Geodatabase, HERE platform APIs
These formats preserve proper mixed-case names suitable for display and search
2. Normalize casing in your application (if using legacy data)
Convert ALL CAPS text to title case or apply your own formatting logic
Note: This may not preserve language-specific rules (e.g., accents, prefixes, special names)
3. Verify naming behavior in product documentation
Check field definitions such as:
+ STREET_NAME, STREET_NAME_LATIN
+ BUILDING_NAME, STREET_NAME_FULL
+ localized names (e.g., name:en, name:zh-Hant)
4. Avoid relying on Shapefile/NavStreets for display use cases

+ These formats are legacy and optimized for interoperability, not presentation

Result
----------

After applying the recommendation:

Feature names appear in readable mixed case (e.g., Michigan Ave)
Naming is consistent across APIs, SDKs, and GIS tools
Better support for:
+ Map display
+ Routing instructions
+ Address matching and search
+ Multi-language/localized names

Reference
-------------

HERE GIS Data Suite overview and components
Routing street-name fields (STREET_NAME_LATIN, alternate names)
Address and building/street name attributes
* Localized naming schema (e.g., name:en, name:zh-Hant)

Tags
--------

street names, capitalization, uppercase, mixed case, navstreets, shapefile, gis data, data formats, naming, map data