Hello, I creating a 3D scene with babylon.js and I would like to integrate a 3D map inside. I mean, using a Tangram 3D map with a free fly camera, and adding 3D markers... Is it possible?

When I detach from my not-retina display, the Tangram map appears low-quality on my retina Macbook display. It should detect the change and "reload" to be retina.

When I attach my not-retina display, the Tangram map seems to perform fine, though?

Tested with Tangram v0.4

Relatively small public syntax footprint in the 0.6 releases:

https://github.com/tangrams/tangram/releases/tag/v0.6.0
https://github.com/tangrams/tangram/releases/tag/v0.6.1

Hi again :)

I was playing with the simple demo today. What I wanted to do was to add a base layer on the back of the vector rending.
You can see my code in this gist, but basically what I did was copied the simple demo, and added an extra base layer (toner_lite) and a map control.

What I realized was that if I don't include the base layer, everything works. Once I enable the base layer (from the code or from the UI) the vector data dissapears and there's no way to add it again. At first I thought it was something related to the order (base layer drawing on top of the polygons), but changing the order to 1000+ in the scene.yaml didn't do the trick.

Is it possible to add a base layer to a Tangram layer? How can I do it?

I'm seeing a lot of black junk around text that has both a fill and stroke, when the stroke is a light color like white or yellow.

Hi,

I wonder if it is possible or ever intended in tangram to change the appearance of a map dynamically.

I have the following use case: I have a moving object on the map that travels routes from A to B on the map. That is quite easy thanks to leaflet-routing-machine and Greensocket Tweening library. However now that we have Tangram I wonder if we can add support for WebGL Models or Shader Objects that interact with the map, for instance, that a car the travels along the route may change the appearance of travelled route. For instance I use a dark (night) style of the map and a car with lights would lighten up the way.

Thanks for your suggestions of how to implement that.
Best,
Matthias

Hi.
Is that any way to run demo on local machine without local server .Its is giving the following error

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Thanking you in advance

I am using TileStache to serve GeoJSON vector tiles using my own data (stored in Postgres).

I want to use tangram to display the tiles, but I'm not sure how to go about doing this, the example uses TopoJSON osm tiles which are different than what TileStache is serving.

Is it possible to do this? and is there a guide I can follow?

We don't (currently anyway) need support for writing YAML files, only reading them. We can slim down the library by building without it (though on first glance it doesn't appear that js-yaml has an existing option to build for read-only).

Hello guys,

Very nice work indeed ... you are coming from the future.

I've downloaded the demo which works excellent in FF not at all in Chrome. Tested on Ubuntu 14.04 and Android 4.2.2 all with latest versions for both browsers.

Please check the console output screenshot.

As we add more features, we increasingly have 3rd party libraries and potential Tangram-developed functionality that need not be bundled for every user and are adding considerable weight to the library.

For example, we currently load the entire TopoJSON and MVT decoding libraries, regardless of whether they are needed for the scene's data sources. This will be exacerbated by new features like potential zip support (see #253).

We could add a dependency loading system that loads them on demand. We could a pre-configured CDN/hosted location for dependencies, with a way to override them to allow for future-proofing or alternate hosting.

See:

• https://github.com/ModuleLoader/es6-module-loader
• https://github.com/systemjs/systemjs
• http://jspm.io

Browsing around Washington DC I'm seeing tons of buildings that don't fill (but do stroke) at mid zooms. Zooming into high (neighborhood) zooms they do fill. And sometimes the interior ring (that shouldn't be filled) is filling in at high zooms.

Howard University in DC with v0.4 Tangram shows outline only buildings (a regression):

Howard University in DC with v0.3 Tangram draws fill properly:

Elsewhere in DC...

Note the Thomas Jefferson Memorial outer ring not filling. Same for Library of Congress.

I'm back to annoy you good people at Tangram.

I have been trying to get my labels to follow the direction of the roads but I have not had any success. I want the road label's text to follow the direction of the road and not be in a straight line, is it possible to do this in Tangram?

When Tangram is served under basic auth, texture load requests are failing in Chrome because the auth header is not being included in the request. Firefox appears to automatically add the header.

See tangrams/tangram-es#579.

Should be:

• Lighting fragment: normal and color applied in fragment shader
• Lighting vertex: normal and color applied in vertex shader
• Lighting false: color applied in vertex shader, normal not applied
• In all cases, filter applied in fragment shader for final pixel color modifications

I'm trying to incorporate a Tangram layer into an existing project, but I'm experiencing the above issue.

The full error is: Tangram v0.4.6: Scene.load() failed to load /css/scene.yaml: Can't load worker because couldn't find base URL that library was loaded from

The web server is IIS 10. I've had to add a mimetype for .yaml files (I was getting 404 errors before doing that). Any ideas what's causing this error?

There are significant limitations in the way Tangram currently loads its web workers. These mainly restrict others' desire to host or bundle the library, rather than loading it from the "official" Mapzen URLs.

Current library design:

• The same code is executed on both main and worker threads. This is because there is so much overlap of core code that needs to be executed by both. Many objects such as Style get instantiated in both thread types (albeit with some differences in behavior). There are a handful of switches (using Utils.isMainThread and Utils.isWorkerThread) to control behavior that differs across threads, usually where some code is applicable to one thread but not the other. Having one library file also simplifies distribution/hosting (rather than having to host and load a separate file built for worker execution).
• To instantiate its workers, Tangram needs a full copy of its own code. It currently accesses its code by looking for the <script> tag that it was loaded from. It restricts this search to known/expected library names: either tangram.min.js or tangram.debug.js.

Limitations of this approach:

• Tangram must be loaded from a file called either tangram.min.js or tangram.debug.js. For instance, copying it to a file called tangram.js will cause it to fail (because it cannot find the expected <script> tag.
• Tangram must be able to access its code in isolation from other code, which means it cannot be bundled with other JS dependencies (e.g. via a minifier or even simple cat bundle).
• It's possible for frameworks to modify the DOM before Tangram searches for its <script> tag. For example, there was an apparent case where Webpack was removing <script> tags before Tangram executed, causing it to fail (but note this is speculative and would need to be verified with current versions, nonetheless the possibility remains).

Possible solutions:

1. Without changing current functionality, Tangram could have an option to provide an alternate URL from which its worker code should be loaded (instead of trying to infer that URL). Currently this could mean simply pointing back to the same URL that Tangram itself is being loaded from (since the main and worker thread bundles are the same); in option 4 below, the worker URL could point to a different bundle. There is actually an existing internal option for this which only needs to be exposed in the Leaflet plugin. However, this solution is incomplete, as it allows Tangram to be hosted under different filenames, but not easily bundled with other code.
2. Tangram could "self-execute", meaning the library code could itself be placed in a variable that is eval'ed on the main thread, and then that same variable could be used to load the workers. Here is a branch showing this approach. Initial tests are functional, however there are unanswered questions as to whether this is advisable, especially as it relates to library load/start-up time, and VM optimization paths (e.g. will a large eval'ed library still receive optimal treatment by the VM, does this differ for AOT compilation, etc.). This option would enable hosting under different filenames and/or bundling with other code, while preserving single-file distribution.
3. A utility such as webworkify could be used to load the worker code. This shares some aspects with the self-executing approach above, except that only the worker portions of the code are stringified (and then loaded into the worker via object URL). This has the downside of duplicating any shared code between the threads. Since the current library design actually maximizes rather than minimizes code overlap, this would likely cause a large amount of library bloat without re-architecting (it is worth trying though). This option would enable alternate hosting filenames and bundling w/other code, as above.
4. Tangram could build separate bundles for the main thread and worker threads. Doing this efficiently would mean re-architecting to separate main/worker code as for webworkify. It would enable the main bundle to be hosted under different names and/or bundled w/other code, but it would require that the worker bundle is still distributed alongside the library, as a separate file, and its URL configured as in option 1 above.

Bundle multiple scene files and related assets into a single file for easier distribution and less network overhead. Becomes more important as we add scene "include" functionality, increasing the number of network requests to load a scene.

• Multi-document YAML
  • Meta info about "file system" in first document
  • Custom logic to resolve paths, etc.
  • Doesn't support images/binary assets (without inefficient methods like base64 images)
• JSON wrapper with meta info
  • Individual scenes stored as YAML or JSON (just text, either works, and technically YAML is a superset of JSON anyway)
  • Stringified JSON scenes are smaller than YAML due to whitespace removal
  • Doesn't support images/binary assets as above
• Binary format
  • Protobuf, flatbuffers, etc.
  • Supports any asset type, and could reduce payload through custom data structures
  • Significant downside of needing to design format, encoder/decoder, less accessible (not human openable, debuggable, etc.)
• Zip archive
  • Natively preserves file paths, supports images/binary assets, easily readable by machines and openable by humans
  • Reasonable size improvements (compressed text), though we're already gzipping on server
  • Possibly less custom logic to resolve paths, etc. (still necessary, but can go through zip reader API vs. designing our own metata/format)
  • https://github.com/Stuk/jszip - large new depedency (75k minified), may increase value of conditionally loaded modules, e.g. only load TopoJSON, MVT, Zip, etc. libraries/modules as needed (currently the first two are always loaded with the library, regardless of whether they are needed for the scene's data sources. See #255.

From @almereyda on October 6, 2015 22:4

As long as Leaflet.Hash is loaded, mouse scrolling will yield:

mapzen.com/tangram/tangram.min.js:10 Uncaught TypeError: e._move is not a function

How to proceed from here?

• Does Tangram need an update to be compatible with https://github.com/mlevans/leaflet-hash
• or do we need to send a PR to https://github.com/mlevans/leaflet-hash to make it work properly again?

It seems someone is stealing events here.

Copied from original issue: tangrams/generic-demo#1

With a relatively simple syntax change I think we can make the stylesheet easier to learn and give the library more room to grow in the future!

There's a pattern in several parts of the stylesheet where the "keys" of a map are user-specified values, like this example from the docs:

layers:
    landuse:
        data: { source: osm }
        filter: ...
        draw: ...
        sublayer:
            filter: ...
            draw: ...
        sublayer2:
            filter: ...
            draw: ...

This is a nice example of the brevity enabled by YAML, but (as we probably know) there are two issues with this pattern:

1. There is implicit knowledge about which keys have built-in meaning. It's not obvious that sublayer doesn't have some special semantics, for instance, and in general one needs to have read the documentation for every field in order to determine if its name is meaningful.
2. We can't add keywords to any sections using this pattern without potentially breaking existing stylesheets. In the landuse section here, we have locked ourselves out of adding any new properties at this level.

An alternative:

layers:
    - name: landuse
      data: { source: osm }
      filter: ...
      draw: ...
      layers:
          - name: sublayer
            filter: ...
            draw: ...
          - name: sublayer2
            filter: ...
            draw: ...

The "sequence" syntax generally creates less indentation and, while there is slightly more text, it can actually be more readable because it makes semantics more explicit. And of course if users aren't specifying the names of fields, there's no concern that those names will collide in the future.

This would be a breaking change for existing stylesheets, but I am optimistic that our total future adoption can greatly outnumber the current users, so we should plan to make the best experience we can for those future users!

PS Not sure if this belongs in "issues" but I wasn't sure where else to put it

Hi, I'm creating a map application for which I'm thinking of using tangram for client-side styling. I want it to run on old browsers which might not have webgl support. Since only flat camera type needs to be supported, is there a way to disable webgl and use only leaflet to render the tiles?

We currently draw labels with Canvas text, which means we get web/CSS font styling "for free". However, the Canvas text API is not aware of and does not wait for custom web fonts (non-system fonts) to load before drawing. This means web fonts can't be used reliably (often the first tile or two to render without the font but cause the browser to begin the font loading process; later tiles draw with the font once it has loaded).

The CSS Font Loading Module Level 3 provides an API for detecting font loads, but is only natively supported by Chrome and FF.

FontFaceObserver provides a partial polyfill that can be used to detect font loads across all browsers, and is a promising solution (with one issue noted below).

For full custom font support, we should consider adding a top-level fonts section to the scene file, allowing for named font faces to be specified, along with their URLs for loading. If used with TrueType or OpenType fonts, this could hopefully be done in a compatible way across Tangram JS and ES (this could even probably be done with web-specific formats like WOFF(2), which are apparently mostly containers for TT/OT font data). In a web context, additional fonts may also already be loaded via CSS (for example, using Google Fonts), which should be considered for any syntax to avoid attempts to load a font face more than once.

A first step could be to use FontFaceObserver to detect when any font face is specified for label rendering. This would allow for CSS-loaded fonts to start working properly, without any additional scene file syntax (just like locally installed fonts do on both web and native). However, FontFaceObserver currently times out (rather than immediately detecting) system fonts (e.g. Helvetica etc.) when using native FontFaceSet support on Chrome and FF. This adds a 3-second delay to all text rendering (clearly unworkable). Currently investigating solutions for this, which could involve either minor modifications to the behavior (either via fork or PR, possibly using the document.fonts.check() method), or running a build with native FontFaceSet support disabled (FontFaceObserver's fallback behavior actually does detect system fonts, but is slower and using the native API is always preferable).

I've got this error

[.CommandBufferContext]GL ERROR :GL_INVALID_OPERATION : glDrawArrays: attempt to access out of range vertices in attribute 0
WebGL: too many errors, no more errors will be reported to the console for this context.

and a lot of partialy rendered tile in my maps.

To get this error I just put the cinnabar-style ìdemo inside an ionic 2 app using Chrome 49.

The plain cinnabar demo works fine

This is the typescript source code of the page with the map

/// <reference path="../../../typings/leaflet/leaflet.d.ts" />

import {Page} from 'ionic-angular';

declare let L: any;
declare let Tangram: any;

@Page({
  templateUrl: 'build/pages/map/map.html'
})
export class MapPage {

  constructor() {}

  onPageLoaded() {
    // workaround map is not correctly displayed
    // maybe this should be done in some other event
    setTimeout(this.loadMap.bind(this), 100);

  }

  loadMap() {

      let map = L.map('map');
      var layer = Tangram.leafletLayer({
        scene: 'scene.yaml',
        attribution: '<a href="https://mapzen.com/tangram" target="_blank">Tangram</a> | &copy; OSM contributors | <a href="https://mapzen.com/" target="_blank">Mapzen</a>'
      });
      layer.addTo(map);
      map.setView([40.70531887544228, -74.00976419448853], 15);  var layer = Tangram.leafletLayer({ scene: 'scene.yaml' });
      layer.addTo(map);
  }

}

I have been trying to replicate the mouse over/click function I have seen in many of your examples ( where you get the name/details of the POI on mouse hover / click ).

But I have had no success at all! I have tried to modify the function in the JavaScript Files but it just doesn't seem to work.

I think the main issue is that I am using tiles that I have created and not the OSM tiles and will have to modify the code accordingly. I'd really appreciate it if you could guide me a little bit about how I should go about modifying the function or writing my own.

did Tangram v0.6 mess up the lat-lng to tile coordinate magic?

I used to be able to cmd-click in all my maps to get the raw tile data

For instance:
http://indyhurt.github.io/nyr-fitness/map/#19/37.76825/-122.45218
cmd-click near the Funky Door Yoga

in v0.6 I get:
http://vector.mapzen.com/osm/all/undefined/NaN/NaN.topojson?api_key=vector-tiles-HqUVidw

but if I downgrade to v0.5 Tangram I get:
http://vector.mapzen.com/osm/all/19/83809/202660.topojson?api_key=vector-tiles-HqUVidw

Which is the expected behavior. I use this feature constantly through the day, is it possible to roll a patch update to fix the issue soon?

@blair1618 noticed that lines seem to lose some of their width when overzoomed multiple levels (particularly now that we are overzooming from z16). For example, a 10px line renders consistently from z16-20, but starting at z21, it slims down to around 8px, and at z24 it disappears entirely. This appears to be an issue with precision, given that we are encoding line extrusion vector and width information in a signed short (16-bit int). I verified that hypothesis by switching back to using raw floats in the VBO, which showed no overzooming artifacts.

Given internal tile scale of [0, 4096], we start to run up against the limits of a short as the compounding effects of 2^z overzooming kicks in. The "slimming" effect is likely when the values start to get quantized to an insufficient bit-range, finally disappearing when they collapse into a single point and/or zero width.

We can probably tune the storage of these attributes to address this.

I am just digging into this awesome project, so I may have missed something. But I was wondering if there is an event or some other way to alter the vector tiles as they come in? Specifically I would like to combine some data that is not in OSM.

Many thanks!

Hello :-),

Thanks for this great piece of code!
Nevertheless, is it possible to avoid to “repaint” the whole map when we zoom and have a smooth transition between 2 zoom levels instead? Like Mapbox GL does for instance.

Thanks :-).

Here https://github.com/tangrams/tangram/blob/master/src/scene.js#L42-L43
and https://github.com/tangrams/tangram/blob/master/src/scene.js#L111-L112

We currently have a lot of redundant GL state changes for setting uniforms. We could reduce these by caching uniform values in JS, and comparing the values to see if they have changed before calling any GL updates. This will need to be benchmarked however, as there is a trade-off between increased JS time to check uniform state vs. increased driver/GL time to update.

I am using Tangram to render Vector Tiles I have created using the Postgres source with TileStache, and it is working much better than I had hoped it would, kudos for a job well done!

I went through the documentation and was able to get most of the things without much issues, the problem I am facing now is that I can't figure out how to alter my label placements, I have looked through the various label demos but I have not been able to understand how the label placements works (particularly the labels for polygons, my land polygons have really weird label placements, they appear 2-3 times in some polygons while they appear once in a random location in another similar polygon).

Is there a listing of the label placement parameters available, or is there some documentation about it that I could read through?

Importing the transitland operator polygons and used labels text visible:true -- seeing text at many strange positions rather than one central position.

http://tangrams.github.io/tangram-play/?scene=https://gist.githubusercontent.com/anonymous/78d5327116ac44d26a07/raw/50bfb7e5b086a2697c6b1ccbe5fe97fff12dec13/transitland-operators.yaml#10/41.4556/-72.7487

Is it possible/is there a straightforward way to switch between using tangram or normal OSM map tile images based on webGL support (using Modernizr)?

Thanks

This error happens on Tangram 0.4 and not in Tangram .3

Here is a link to the project. To replicate the error just change the version to 0.4 in the index.html
https://github.com/patriciogonzalezvivo/InvisibleTracks

In the Eraser Map scene file, when I update the sources block's max_zoom from 18 to 16, the landuse dot patterns in the shader seem to freeze size at zoom 16 and then get larger and larger, like they're treated in meter space instead of pixel space.

/cc @sensescape

observed:

expected:

Is there some design documents on how you guys are using web workers? I'm curious to know in order to learn and develop my skills using workers for rendering-related tasks. If there are no architecture docs, mind explaining here the basic concepts?

Some members of the web community are working on a rendering project at http://infamous.io (discussing and planning at http://forums.infamous.io). Thanks!

EDIT: Funny thing, I'm also using something called a SceneWorker in my prototype. Nothing renders yet though, I'm getting there. :}

EDIT: I was thinking of doing something similar to the WorkerBroker concept you have, and calling methods on workers. It's similar to RPC over network, but between workers instead. The difference with my idea is that instead of passing the method name into the postMessage call, I'd like to just make methods on the worker, so f.e. worker.someMethod(arg1, arg2, etc).

See tangrams/tangram-es#502

https://mapzen.com/vector-map Should be changed to http://vector-map.mapzen.com/, yes?

Is it possible to doa filter where we can check if a point is inside the polygon,
something like POSTGIS ST_Contains,

I tried the filter function, but it does not reveals the geometry parameter of the json, so could not do any operations there.

Your site crashes my browser(Firefox v29)
this link: http://mapzen.com/tangram

To match issue for ES (behavior change should ideally be coordinated): tangrams/tangram-es#592

Testing with GL_LESS instead of GL_LEQUAL should result in many fewer fragments being processed with no change in visual quality.

The only cases where this could change visual results would be overlapping geometries set to the same order, but this case is effectively a user error and those geometries will have visual artifacts from z-fighting anyway.

The traffic animation direction look reversed (against one way). The rest is AMAZING!

To support tangrams/tangram-play#236

I keep getting this error after make run-tests:

TypeError: L.GridLayer is undefined
at /home/nassar/Desktop/tangram-master/dist/tangram.debug.js:21887

Im using Ubuntu, Firefox 23...

Some lines are being dropped -- and not just along straight tile edge boundaries.

see near Old Saybrook and Branford, CT

http://tangrams.github.io/tangram-play/?scene=https://gist.githubusercontent.com/anonymous/78d5327116ac44d26a07/raw/50bfb7e5b086a2697c6b1ccbe5fe97fff12dec13/transitland-operators.yaml#10/41.4556/-72.7487

see near Mount Diablo:

http://tangrams.github.io/tangram-play/?scene=https://gist.githubusercontent.com/anonymous/78d5327116ac44d26a07/raw/50bfb7e5b086a2697c6b1ccbe5fe97fff12dec13/transitland-operators.yaml#11/37.8095/-122.0760

Hey guys,

First of all, awesome work! I was on the "Mapzen SF Happy Hour Demo Time" at Code for America last week and saw all the cool stuff that Tangrams can do. Needless to say, I was very impressed! I love the clean yaml syntax.

I'm thinking about start working on an open source project that combines a lot of things: Django, GeoDjango, TileStache, and hopefully Tangram (fingers crossed).

I was going over the documentation and couldn't find an example of a styling "scene file" that uses multiple sources with single layers instead of one single source with multiple layers.

So for instance, instead of having this URL:

//domain.com/all/{z}/{x}/{y}.geojson

That returns this:

{
   "earth": {
      "type":"FeatureCollection",
      "features": [...],
      ...
   },
   "landuse": {
      "type":"FeatureCollection",
      "features": [...],
      ...
   }
}

I would have several of these URLs:

//domain.com/earth/{z}/{x}/{y}.geojson
//domain.com/landuse/{z}/{x}/{y}.geojson
...

Where each of them return something like this:

{
  "type":"FeatureCollection",
  "features": [...],
  ...
}

How would my scene.yaml look like for this setup, if I would like to get the same result as this scene file (simple-demo)? I'm sure there is an example somewhere there and I totally missed it.

Thanks, and keep the good work!

When tiles are overzoomed, the line labels can become too sparse. This is because we place one label per line segment. When tiles represent a constant screenspace area at every zoom (as unzoomed tiles do), this has provided a decent level of label density. But when those line segments are scaled up to cover several times the original screen area (16x for z16 tiles overzoomed to z20!), the labels get spread out over a much larger area.

To solve this, we can introduce some optional factor for placing labels at subdivided points along the line geometry, which can be adjusted according to the tile's overzoom factor (if any).

z19 with z19 tiles:

z19 with z16 overzoomed tiles:

I have been facing a weird issue for a while now ( it has persisted over all three Tangram versions I have used 0.4, 0.5 and now 0.6.1 ). Sometimes the colors I assign in the scene file (the yaml) are not correctly displayed in the map. They are a few shades lighter for some reason.

I have compared the hex codes of the two (the codes I assigned in the scene file and the code in tangram and they are not the same). This is the color I've assigned to the Parks in the Cartographic Layer ('#b5c899')

And this is the color being displayed:

This difference in this case is not that big but it still poses consistency issues and in other cases (when I assigned color to buildings) the difference can be much more noticeable.

Is this an issue on my end? What can I do to try to get consistent colors?

P.S: Great job on the updated documentation, really makes this clear and easy to understand. Also loving the new feature in the 0.6.1 build.

Hi,
first of all I wanted to say that you guys are doing an amazing job, this is the most impressive map styling/rendering solution I have worked with, loving it.

the issue [broad]

I'm trying to integrate some of our own data with your provided osm Data and after a lot of debugging I think the issue I'm having is coming from projection calculations. The integrated data layer is creating some sort of abstract art instead of the shapes I want to see.

versions used

Leaflet 0.7.5
latest version of tangram_debug

My tasks

As much as I found in your documentation, to add my own data that is not coming from a tile url I need to do this through the transform function at the sources section in the yaml file.

In the following code snippet I do three things.

1. I check for buildings that in regards to our data has a store inside and I give them a tag to later draw and style them differently (this works flawelessly)
2. I check in our data for store spaces that match the loaded osm buildings and add those spaces to a new layer called 'spaces' formatted as GeoJson (here is the issue)
3. I check if the buildings are in a certain bounding box to be able to only draw the ones inside that bounding box (to save on performance) (this works flawlessly)

the issue [detail]

As you can see in the following code is that I limit the data match at the moment for debugging.
What I found that the coordinates of the same space through the transformGeometry function (line 31140) and the projectData function (line 31186) multiple times. The first calculation is fine (it seems at least in regards to the numbers), it takes the Lat and Lng and calcualtes the correct Mercartor meter equivalent, but the second time around it will take the mercartor meter calculation as a base and then it quickly ends up giving me NaN for one of the Latitude since it can't exist.
What I haven't understood fully is where my added data gets overwritten with the Mercartor calculations, so that the second time around it takes those as the base.

I would be really grateful if you could point me in the right direction, how to solve this issue.

the function I have written so far looks like this:

YAML Data post processing

function(data, extra_data){
                var counter = 0;
                data.spaces = {};
                var all_spaces = {};
                if(data.buildings){
                    data.buildings.features.forEach( function(building) { 
                        //defining if building has a store and how many levels
                        if (extra_data.our_buildings[building.properties.id]){
                            building.properties.store = true;
                            building.properties.level = extra_data.our_buildings[building.properties.id].building_levels;
                            if(extra_data.our_buildings[building.properties.id].spaces){
                                for(var space in extra_data.our_buildings[building.properties.id].spaces){
                                    if(data['spaces'] && building.properties.id === 37037045){
                                        //console.log(extra_data.our_buildings[building.properties.id].spaces[s].space_g);
                                        data.spaces = {
                                            'features': [
                                                extra_data.our_buildings[building.properties.id].spaces[space]
                                            ],
                                            'type': 'FeatureCollection'
                                        }
                                    }
                                    else if(!all_spaces[extra_data.our_buildings[building.properties.id].spaces[space].space_id]){
                                        data.spaces.features.push(
                                            extra_data.our_buildings[building.properties.id].spaces[space]
                                        );
                                        all_spaces[extra_data.our_buildings[building.properties.id].spaces[space].space_id] = true;
                                    }
                                    if(extra_data.our_buildings[building.properties.id].spaces[space].properties.space_id === 6813){
                                        console.log('this is the space in a building yaml file ' + counter + ' building: ' + building.properties.id);
                                        console.log(extra_data.our_buildings[building.properties.id].spaces[space].geometry.coordinates[0]);
                                        counter++;
                                    }
                                }
                            }   
                        }

                        else{
                            building.properties.store = false;
                        }
                        //defining if in bounding box
                        if(building.geometry.type === 'Polygon'){
                            //console.log(building.geometry.coordinates[0][0]);
                            var lon = building.geometry.coordinates[0][0][0]
                            var lat = building.geometry.coordinates[0][0][1];
                            var leftlon = 8.531055450439453; 
                            var rightlon = 8.551998138427734;
                            var toplat = 47.37948104213511;
                            var botlat = 47.36541428270504;
                            //checking if the first point is in the bounding box
                            if (lon > leftlon && lon < rightlon && lat < toplat && lat > botlat){
                                building.properties.draw = true;
                            }
                            else{
                                building.properties.draw = false;
                            }
                        }

                    });
                }
                console.log(data);
                return data;
            }  

YAML layer styling

spaces:
        data: { source: osm }
        filter: function () { return feature.space_id === 6813 }
        draw:
            polygons:
                order: 55
                color: red
        extruded:
            draw:
                polygons:
                    extrude: function() { return (feature.space_levels * 2) }

the added Space Layer

the space layer is successfully added

the art

but the rendering looks like this (zoomed out also in browser to capture it):

how it should look like

and just now when capturing the image and zooming in and out, the correct polygon was showing in red between the buildings.

looks like the projection calculations that happen with the zoomlevel have an issue with the data being provided?
The additional data is provided only once when initially loading the map.
Do I have to insert my data everytime a user zooms in/out and moves around?

Thanks,

Dominic