Interactive, thoroughly customizable maps in the browser, powered by vector tiles and WebGL

Adding this back as an issue, since its original one was converted into stagnated PR #1466, but remains a pretty cool feature!

Original Issue Text:

Hey mapbox team! I first want to say I'm truly blown away by what you've built here. This is really, really impressive.

Anyhow, I'm curious to know if there is any interest in support non-mercator projections? I checked out the transformation logic and the projection appears to be hard-coded.

I'm sure there are optimizations to be had by assuming a single projection, but it would be really neat to be able to provide mapbox-gl with custom projection functions: not only would this enable other "common" map formats, but would open the door for some really creative visualizations (check out this and this).

It would also make mapbox-gl an ideal candidate for non-geo-based maps, like a cross-section of a human body with organs, circulatory system, nervous system, etc.

Thanks again for all the cool tech, and for developing in the open!

Cheers, Mike

Hello! As we can see here https://www.mapbox.com/mapbox-gl-js/example/custom-marker-icons/ we could create a custom Marker and add it to map. e.g. new mapboxgl.Marker(...).setLngLat(...).addTo(map);

I'm trying to find the way how to add marker to the layer and organize into the Cluster. Smth like https://www.mapbox.com/mapbox-gl-js/example/cluster/ but with custom Markers:

1. var map = new mapboxgl.Map...
2. map.addSource(...);
3. map.addLayer(...);
4. and here map.getLayer(...).addMarker(Marker). or marker.addto(Layer/Source) or ... As a result we should see a Cluster with custom markers.

--- 🔴 EDIT from a gl-js maintainer 🔴 ---- We've just opened #10565 do go over some of the decisions of why we moved to ES6, and also summarizing the solutions that everyone has contributed in this thread. Would love for the discussion to be continued there. 🙇🏽 --- 🔴 END EDIT🔴-----

mapbox-gl-js version: 2.0.0

browser: Google Chrome Version 87.0.4280.67 (Official Build) (x86_64)

Steps to Trigger Behaviour

I'm trying to build a library of Vue components and one component uses mapbox-gl. I created a test project to showcase the issue.

1. Create a Vue library (vue create library)
2. Add mapbox-gl to the library in a component
3. Build the library
4. Use the library in a Vue application

When I build and use it I have an error message saying:

Uncaught ReferenceError: _createClass is not defined

Link to Demonstration

https://gitlab.com/antoinealej/test-lib-mapbox-gl-build

Expected Behaviour

Display the map over a beige background

Actual Behaviour

Only displays the beige background container

We should draw polygons by tesselating them instead of using the stencil buffer trick. Native already does this. https://github.com/mapbox/mapbox-gl-js/commit/7b353122b46503b57e6d5073184883c1c2e21404 is a first attempt that uses libtess.js. Rendering is faster but the tesselation is slow. The buildings layer can take up to 500ms to tesselate.

• take a look at poly2tri.js (which only accepts simple polygons)
• revisit tesselating polygons in the tiles

I want to use this library in conjunction with the Mapbox service for a game I am currently developing. However, we need support for custom markers like the Google Maps JavaScript API provides. We need markers with custom images, bindable events and a similar simple API.

After working with the stylesheet structure a bit, I think there are a few improvements we can make without losing configuration flexibility.

This is my personal wishlist, which draws from many of the previously discussed ideas in https://github.com/mapbox/llmr/issues/244, https://github.com/mapbox/llmr/issues/279, and https://github.com/mapbox/llmr/issues/276. I'm not sure if this should be the content for a preprocessor, a replacement for the current stylesheet, or a step towards a styling language.

Here is an example to illustrate the idea:

{
    buckets: {
        'streets': {
            'poi': {
                layer: 'poi_label',
                point: true,
                children: {
                    'poi_park': {
                        filter: { 'maki': 'park' }
                        point: true,
                        text: {
                            textField: 'name',
                            path: 'curve',
                            font: 'Open Sans',
                            fontSize: 18
                        }
                    },
                    'poi_other': {
                        filter: { 'maki': ['airport', 'bus'] }
                        point: true,
                    }
                }
            },
            'road': {
                layer: 'road',
                line: true,
                'road_motorway': {
                    filter: { 'class': ['motorway', 'motorway_link'] },
                    line: {
                        cap: 'round',
                        join: 'bevel'
                    }
                },
                'road_main': {
                    filter: {
                        'class': 'main',
                        'oneway': 1
                    },
                    line: {
                        cap: 'round',
                        join: 'bevel'
                    }
                }
            },
            'building': {
                layer: 'building',
                fill: true
                stroke: {
                    cap: 'round',
                    join: 'round'
                }
            },
            'wetland': {
                layer: 'landuse_overlay',
                filter: { 'class': 'wetland' },
                fill: true
            }
        }
    },
    structure: [
        'wetland',
        'poi',
        'poi_park',
        'poi_other',
        { 
            composite: 'road',
            layers: [
                'road_motorway',
                'road_main'
            ] 
        },
        'building'
    ],
    layers: {
        'default': {
            'background': { fillColor: 'black' },
            'poi': {
                fillColor: 'white',
                pointRadius: 5
            },
            'poi_park': {
                pointImage: 'park-18',
                textColor: 'white',
                textTranslate: [40, 0]
            },
            'poi_other': {
                pointImage: 'star-stroked-18'
            },
            'road': {
                opacity: 0.9
            },
            'road_motorway': {
                fillColor: 'white',
                lineWidth: 3,
                strokeColor: 'green',
                strokeWidth: 1,
                transition: {
                    fillColor: { duration: 300 },
                    strokeColor: { 
                        duration: 300,
                        delay: 100
                    }
                }
            },
            'road_main': {
                fillColor: 'white',
                lineWidth: 1
            },
            'building': {
                fillColor: '#333333',
                fillOpacity: 0.8,
                strokeColor: '#555555',
                strokeWidth: 3
            }
        }
    }
}

Buckets

Bucket structure

filter: {
    'class': ['motorway', 'motorway_link'],
    'oneway': 1
}

• Specify type using fill: true or line: { cap: 'round', join: 'bevel' }

Multiple types in buckets

Specifying multiple types in a bucket can alleviate a lot of the confusion around line casings and fill strokes, cut down on repeating bucket code, more closely resemble carto patterns, and most importantly, remove the need for multiple layers pointing at a single bucket.

• Allow for stroke control on fill buckets, which can later be styled in classes, such as:

'building': {
    layer: 'building',
    fill: true
    stroke: {
        cap: 'round',
        join: 'round'
    }
}

• Allow for points and text to be specified in a single bucket:

'poi_park': {
    filter: { 'maki': 'park' }
    point: true,
    text: {
        textField: 'name',
        path: 'curve',
        font: 'Open Sans',
        fontSize: 18
    }
}

Structure

By baking multiple types in bucket specification and solving for the road casing issue in the class (see layer updates below), there doesn't seem to be a need for multiple layers pointing to a bucket. We can move to a flatter array for the structure:

structure: [
    'wetland',
    'poi',
    'poi_park',
    'poi_other',
    { 
        composite: 'road',
        layers: [
            'road_motorway',
            'road_main'
        ] 
    },
    'building'
]

This requires layer names to match up with bucket names.

Layers

transition: {
    fillColor: { duration: 300 },
    strokeColor: { 
        duration: 300,
        delay: 100
    }
}

With these changes, I tried to cover all current functionality while simplifying the process conceptually.

cc @nickidlugash @ansis @mourner @kkaefer @tmcw

I'm able to bundle gl-js using webpack, but I'm getting a runtime error (in glify) with Chrome 46 on OSX. @tmcw mentioned this has been reported before and that a webpack alternative to glify may be needed. Adding an issue for reference and noting workaround.

Uncaught TypeError: Cannot read property 'match' of undefined

at https://github.com/mapbox/glify/blob/master/index.js#L13

Simple example showing my work -- https://github.com/twelch/react-mapbox-gl-js/tree/webpack-test One workaround is to shim with the pre-built gl-js library using the webpack script-loader module.

require("script!mapbox-gl/dist/mapbox-gl.js");

instead of

import mapboxgl from 'mapbox-gl';

mapbox-gl-js version: 0.32.1

Steps to Trigger Behavior

Set up Mapbox with webpack 2 via vuejs-template

Configuration is as follows: Base: https://gist.github.com/henningko/5a76d12a14e485bfc4dd62c2e50ad08e Production: https://gist.github.com/henningko/3387f41a55558af60205ea00bbc6b530

Mapbox is used with import mapboxgl from 'mapbox-gl'.

Expected Behavior

Mapbox can be successfully uglified.

Actual Behavior

When building for production, UglifyJS2 has Mapbox throw a Uncaught ReferenceError: n is not defined. This error also occurs when using Google Closure instead of UglifyJS. May be related to #1649 , which mainly treats webpack v1 and is closed.

Thanks for your help!

For Issue #1231. This is a first pass that uses a slightly modified centroid function from turf-centroid.js

It works great for simple polygons, but it doesn't handle holes or complex polygons.

For holes, maybe the solution would be to look at using the formula for geometric decomposition

For complex polygons (e.g. river polygons ) a more complex straight polygon tree could be used but I haven't found a nicie clean fast solution for that yet.

This is also my first PR for mapbox-gl-js, so please let me know if I have missed something.

Replaces #2648

• Inverts TilePyramid and Source dependencies. TilePyramid now essentially serves as a common wrapper class for dealing with sources.
• Renames TilePyramid to SourceCache. This is partly aspirational, and partly to make it more reasonable to have things called source that are actually TilePyramids 😁
• Eliminates the ability to create a Source independently of a Map instance - i.e., no more new mapboxgl.GeoJSONSource(); sources must be created with map.addSource(id, json).
• Eliminates bucketStats, as it is no longer needed (so @lucaswoj assures me)
• Source types are now classes with constructor signature (id, options, dispatcher) => Source and an optional workerSourceURL static property
• The Source provided by the factory function is an object implementing:

id: string
tileSize: number
minzoom: number
maxzoom: number
roundZoom: boolean
reparseOverscaled: boolean
isTileClipped: boolean

loadTile: (tile: Tile, cb: (err, ?data) => void) => void
abortTile: (tile: Tile) => void
unloadTile: (tile: Tile) => void
serialize: () => Object // plain JS
?prepare: () => void

// @fires `load` to indicate source data has been loaded, so that it's okay to call `loadTile`
// @fires `change` to indicate source data has changed, so that any current caches should be flushed 

• WorkerSourceURL points to a script, which, when executed in the worker thread, must call self.registerWorkerSource(WorkerSource), where WorkerSource is a class that the worker will construct with new WorkerSource(actor, styleLayers).

WorkerSource instances may implement a loadTile method; if they do, then this will be used by the worker when its 'load tile' target is invoked with a type: 'source-type' parameter (e.g. type: 'geojson'). Any other methods on workerSource instance can be targeted by the main-thread Source via dispatcher.send('source-type.methodname', params, callback).

Questions:

• [x] Does the above design have broad (enough) approval?
• [x] The Tile objects are used by various source types to maintain tile-specific state; ideally, this implicit contract between TilePyramid and Source should be made explicit in the Source interface... but I think this is perhaps out of scope for this particular PR - perhaps this would be naturally addressed in #2703, or else could be ticketed separately?
• [x] I'm not sure what the data yielded by loadTile should look like. Currently, the only thing I can see being needed by code outside of the particular source is bucketStats, which the pyramid uses to emit the tile.stats event. @lucaswoj can you weigh on in this?

Remaining Tasks:

• [x] Video source - @lucaswoj if you can help me get this working, I'm assuming I can probably then manage Image source.
• [x] Image source
• [x] Settle Geojson Source design
  • supercluster: separate source type, or option for geojson source?
  • Simplify the geojson source's WorkerSource so that it is (a) as clean/simple as possible, but (b) nicely supports 3rd party "geojson-like" source types
• [x] Document the Source interface
• [x] Document WorkerSource
• [x] Document addSourceType -- includes documenting the create function and the self.registerWorkerSource(...) requirement on WorkerSource modules.
• [x] Document "How to implement a source type" -- there's probably a bit more to say beyond the Source, WorkerSource, and addSourceType. Perhaps an example of a 3rd-party source type would suffice. update: went with a link to https://github.com/developmentseed/mapbox-gl-topojson in the docs for GeoJSONWorkerSource.
• [x] Update docs for ImageSource, VideoSource, GeoJSONSource to reflect that their constructors are no longer publicly available
• [x] Fix any test regressions
• [x] Add new unit tests as appropriate
• [x] Cleanup - drop async loading of core source types, and do it in the "right" place.
• [x] Cleanup - geojson is a core source type, and so I think we should hard-code require its worker source implementation directly in worker.js--in addition to avoiding the function (self) {} wrapper, it would be silly to webworkify it and waste time at runtime sending that code to all the worker threads
• [x] Cleanup - move loadTileJSON, queryRenderedFeatures, and querySourceFeatures out of source.js
• [x] Cleanup - fix upstream bug in WebWorkify
• [x] Cleanup - hunt & remove all TODO

Hello, I've started exploring this lib and have a feature request: Provide reduce function(s) to clustering configuration, so it's possible to filter clusters by aggregated properties rather than just point_count.

Fixes https://github.com/mapbox/gl-js-team/issues/494

In some projections, the straight edges of the screen become curved when transformed into Mercator space. This issue is most noticeable in conic projections like Albers.

This PR introduces a new function _getBoundsProjection() which checks 19 points along each edge in addition to the corners (20 * 4 = 80 points total), the extremums of all of them forming the bounds. This is the same approach used in the debug page introduced in https://github.com/mapbox/mapbox-gl-js/pull/12199, and is distinct from the recursive error-checking approach introduced for globe in https://github.com/mapbox/mapbox-gl-js/pull/12286. Because projecting a screen point (called in pointLocation) in non-globe projections is a faster operation (in globe or with terrain it requires raytracing), I think the increase in point count is acceptable.

Albers:

Before:

After:

Equal Earth:

Before:

After:

Launch Checklist

• [X] briefly describe the changes in this PR
• [X] include before/after visuals or gifs if this PR includes visual changes
• [x] write tests for all new functionality
• [ ] document any changes to public APIs
• [x] manually test the debug page
• [X] apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• [X] add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Fix map.getBounds returning incorrect bounds with adaptive projections.</changelog>

I am making a globe where countries of the world can be highlighted. I am adding a padding to the map (shown using showPadding-debug), and moving the map using fitBounds like this:

map.current.fitBounds( [ [west, south], [east, north] ], { duration: ANIMATION_TIME, easing: easeInOutCubic } );

The bounds sent to fitBounds are the same used to draw the blue-ish area in the video.

When clicking smaller countries this works like a charm, but there are major issues on larger areas like USA and Russia, and also when selecting countries near the north pole (Norway). There are completely viable configurations of zoom and translation available, like I am trying to illustrate in the video by manually moving/scaling the wrongly positioned areas.

Am I doing something wrong here, or is fitBounds simply not adapted completely for globe-projections?

https://user-images.githubusercontent.com/715134/210360341-dfb02601-17bf-4a1c-9584-795794fbc368.mp4

This PR fixes #11784, by implementing the change suggested by @mourner. A/B tested against published npm package and local build. Bug did not occur in local build with these changes.

Launch Checklist

• [x] briefly describe the changes in this PR (above)
• [ ] include before/after visuals or gifs if this PR includes visual changes
• [ ] write tests for all new functionality
• [x] document any changes to public APIs (none)
• [ ] post benchmark scores
• [ ] manually test the debug page
• [x] apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• [x] add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Fixes "undefined is not an object" in coalesceChanges</changelog>

Question

I am trying to transform the output of supercluster with turf, but since supercluster.getTile() returns a "vt-geojson" and turf expects a standardized geojson it won't compute. Which library is used to fill in this gap?

I tried [1] but it throws some internal errors. Is this up to date?

The library for geojson-vt[2] only provides methods for converting FROM geojson, but not TO geojson.

My previous flow was as follows: features[] -> supercluster: vt-geojson -> vt-pbf:pbf and expose this as tiled vector layer to mapbox-gl-js

Now I want to use turf and apply some transformations after supercluster, before sending to the client via vt-pbf.

What is the recommended way of doing this?

Thanks.

Links to related documentation

[1] https://github.com/mapbox/vector-tile-js [2] https://github.com/mapbox/geojson-vt

Hello Team,

I am building a map where there are thousands of small polygons, each with a background picture. Tried fill-pattern but this keeps repeating images over different zoom levels.

Just wondering if it is possible to create a new pattern from a sprite image that does not repeat but instead covers the polygon in question?

If not, any suggestion on how to accomplish this?

Thank you!

When you set Label.anchor, the icon and label overlap. Maybe it can be solved by that add the text padding parameteras a parameter for calculating the text placement position?