Mapbox-gl-native: Show the contour-label symbol in meters or feet

[roblabs]

Summary — Give the Mapbox mobile or web customer an option to show the contour-label symbol in meters or feet. We also include discussion and our thoughts on the side effects of this [feature] request.

Platform: core, but working demo shown in iOS
Mapbox SDK version: ios-v3.2.2

Steps to trigger behavior

1. Using the Mapbox Outdoor style, zoom to Lake Tahoe in the Sierra Nevada mountains on the border between California and Nevada
2. This will show you features from terrain-v2 (contour-line and contour-label).
3. Zoom to greater than 12 or 13, (even though the minzoom for contour-label is 11)
4. contour-label will display as '12345 m', as the data is in meters
5. USGS topo maps are in feet, and our customers will not want to do the arithmetic conversion from meters to feet. Especially, in the back country where our customers will likely use our Mapbox maps.
   

   Proposed [feature]

• This working iOS demo shows contours intervals in both meters and feet
• This _is an example only_. We don't propose this as the final implementation, as it needs more architecture discussion with Mapbox.
• See this commit on our fork, which also has a discussion on implementation, precision and affect on customers expecting 'feet', but instead getting 'converted meters'.
• The mountain is Black Mountain Open Space Preserve in San Diego county

Actual behavior

• For example, Black Mountain Open Space Preserve in San Diego county, showing contours as meters only

Background

• Typical US Geological Service topo maps are in 40 foot intervals
• Mapbox elevations from the Outdoors style (terrain-V2) are in 50 meters intervals
• Ideally, our team would like to draw the topo lines as 40 feet intervals
• But we don't know if the contour data comes in feet, or only as meters.
• We are aware that Mapbox Streets v7 offers Peak elevations in feet and meters, and we want to drive the discussion on contours.
  

  Mapbox Architecture

This has many implications that need input and architecture from the Mapbox core team —

• [ ] How would the mobile customer set meters or feet? Should Mapbox provide a switch control somewhere accessible in the SDK?
• [ ] What changes are needed for Outdoor styles when used in Android and the web?
• [ ] What implications are on the Mapbox styles which already define "contour-label" as "{ele} m"?
• [ ] What implications are on the Mapbox styles which already define "mountain-peak-label-with-elevation" as "{name_en}, {elevation_m}m"?

[1ec5]

Thank you for taking the time to come up with this proof of concept. As you’re probably aware, we’d either want the choice of units to be explicit either at design time in the style or at runtime based on the user locale, but this area of the codebase probably isn’t well suited to unit conversion logic. The surrounding code handles various properties defined in the style according to the Mapbox GL Style Specification. We’ve started to discuss the possibility of extending the specification to handle number formatting in mapbox/mapbox-gl-style-spec#452; perhaps unit options make sense in this context.

As for placing the contour lines at different intervals, that’s largely something the source would have to implement. Different sources can provide polylines at different elevations. @lucaswoj can probably explain better. 😃

[roblabs]

Thanks for the feedback on the unit conversion. Yes, are right "_sniffing for meters on every symbol and converting_" isn't well suited. Empirically, we checked several large mountain peaks to see if the contour levels in feet still made sense. We wanted to make something real, rather than slide ware. We will not create a pull request, as it's the wrong architecture.

@lucaswoj, if you have any pointers on source data that may have contour levels in feet, rather than meters, then it would solve all. Then the style JSON could just deal with the units as a label, instead of the conversion.

[lucaswoj]

The raw elevation data and prebuilt contour geometries are available from USGS. They can be hard to work with due to their size. We have some internal projects underway to make this easier to work with but nothing to announce yet.

I wish you luck and regret that I can't provide more help! This is a Hard Problem.

[1ec5]

Now that the iOS and macOS SDKs support runtime styling, it’s possible for MGLMapView to automatically swap meters for feet, at least in mountain peak elevation labels, without requiring any changes to mbgl. mapbox/mapbox-gl-language#9 discusses the same approach but geared toward GL JS.

[HikingDev]

Hi,

whats the point in changing the mountain peak to ft whereas the contour labels stay with meter?
Are there any plans to offer {elevation_ft} for contour-label as its available for mountain-peak-label?

[roblabs]

@roesneb — you bring up a good point, and this indeed is a hard problem to solve. My original proposal from a year ago had its own problems. My contour lines were drawn in metric, as it is how the Mapbox contours were made, but the units were converted to Imperial. Still not the right solution.

In order to offer both imperial and metric units for contours would mean the map tile service would have to serve up two distinct layers of contours.

I've studied this quite extensively, and the best solution I could come up with is to make my own contours in Imperial units using USGS data. The contour data set could be large. For the region of San Diego County, California the vector tiles was 100 MB.

Comparison between 𝘦 π Maps, Klokantech Terrain, and Mapbox Outdoors.

Map | Contour Lines | Contour Labels |
| ------------- |-------------| -----|
| Original Proposal | Metric | Imperial converted from Metric. Lines are still Metric!! |
| 𝘦 π Maps | Imperial using raw data from USGS | Imperial |
| Klokantech Terrain | Metric | Metric |

| Mapbox Outdoors | Metric | Metric |

(left to right) 𝘦 π Maps, Klokantech Terrain, Mapbox Outdoors, 𝘦 π (USGS) + Mapbox (Metric)

Hot Springs Mountain, highest point in San Diego County

[1ec5]

We’ve started to discuss the possibility of extending the specification to handle number formatting in mapbox/mapbox-gl-style-spec#452; perhaps unit options make sense in this context.

As of #9439, the style JSON can now contain freeform mathematical expressions, which makes it much easier to implement unit conversions for labels. Runtime styling support for expressions has landed on Android as of #10654, and iOS/macOS support will land in #10726. In Swift, demetricating the label would look like this:

// Convert to feet, round down, cast to a string, and append “ft”.
contourLabels.text = NSExpression(format: "mgl_join({CAST(mgl_round(ele / 0.3048), 'NSString'), ' ft'})")

(I’m working on a more concise way to append strings, but the unit conversion itself is pretty concise.)

But to @roesneb’s point, a more complete solution would require moving the contours to more appropriate intervals. One approach would be for the source to provide contours at closer intervals, relying on the layer to filter out minor contours. Mapbox Terrain does support variable density, keyed on the index field. However, I’m unsure whether the density is sufficient.

10642 is adding new source types for rawer vector terrain data. While that PR is focused on hillshading effects, I wonder if it would unblock generating these terrain contour geometries on the client side as well.

/cc @mollymerp @kkaefer

[mollymerp]

@1ec5 for reference: client side contour generation ticketed here https://github.com/mapbox/mapbox-gl-js/issues/5844

[GitStu]

Hello,
I work for Recreation.gov and we are rebuilding the entire website and system as we speak. Going live with this new effort this October. We will be including an interactive MapBox map on the new site showing campgrounds, campsites, and other federal recreation-related features/places. We are interested in using a MapBox base layer with contours labeled in feet rather than meters (or at least would like the option to toggle between them). Is there an update on the problem with being able to show contours in feet in MapBox?

[roblabs]

@GitStu — Our team has solved this problem of "contours in feet" by processing USGS contour lines as Mapbox vector tiles.

The solution for Rec.gov could be similar:

• use USGS contours line with Mapbox base layer
• Swap out the Mapbox contour layer used in Mapbox Terrain V2 with the USGS contours in feet
• Contact me if you need assistance; we make custom maps using authoritative Federal trail & campsites

See a live map of the San Bernardino National Forest, http://RobLabs.com/sbnf that has contours in feet and USFS campsites.

[GitStu]

Thanks much! Another quick question: do you use authoritative federal roads data too? Such as campground loop roads?

[roblabs]

Yes, we use authoritative federal roads data, so campground loop roads do show up. Some forests have "Yellow Posts" campgrounds and those are fairly well documented on the FS web sites, but the loop roads with campsites doesn't seem to be published.

[bcbeta]

@roblabs it would seem the tilesets are huge? I haven't been able to get them under the upload limit.

[GitStu]

Can anyone tell me how we can request Mapbox to remove sensitive data from one of its base layers?

[friedbunny]

@GitStu If the site/app is following Mapbox ToS, there will be an “Improve this map” link in the attribution — that site will guide you through reporting issues.

[GitStu]

Thanks. I tried that but there is no map to locate the place I need to identify. See screen grab…
[cid:[email protected]]

[GitStu]

FYI - This wasn’t working in Chrome or IE 11, but I got it to work in Firefox.

[friedbunny]

@GitStu let’s keep this issue on topic — please feel free to report issues via our website.

[GitStu]

Will do. Sorry about that.

[roblabs]

Hello @davem2020,

Regarding your question on the size of the tiles:

@roblabs it would seem the tilesets are huge? I haven't been able to get them under the upload limit.

Here are some solutions that We have used to work with large tile sets

• Mapbox limitations are that tiles should be < 500KB/tile when uploading to Mapbox.com/studio
• We make offline maps for mobile, so we don't have that limitation.
• Use data reduction techniques in Tippecanoe to reduce tile size, https://github.com/mapbox/tippecanoe
• Reduce the zoom level range. For example, in my research zoom levels of 11-13 or 11-14 are sufficient for dense, high frequency lines such as contours.
• Tippecanoe will give a warning and error when any tile is > 500 KB. Use that information to determine your next step. For example, if your tile set of contours throws errors at zoom=5, then ask yourself why you need contours at zoom=5.

[bcbeta]

Thanks for the explanation. I will have to explore tippecanoe. I had been uploading the shp file directly to mapbox which quickly exceeded the 260 mg limit.

[stale[bot]]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale[bot]]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.