search

tangrams / tangram

WebGL map rendering engine for creative cartography
https://tangram.city
MIT License
2.21k stars 290 forks source link

Default to data source's only layer #712

Closed bcamper closed 5 years ago

bcamper commented 5 years ago

Many data sources only have a single layer. With GeoJSON sources, the layer is implicit and un-named, because the contents of the file are a single FeatureCollection object. This layer gets automatically matched when a data block in layers leaves the source layer name unspecified, e.g.

layers:
  geojson:
    data: { source: geojson } # uses the default layer in the geojson source
    ...

Many MVT sources typically have a single layer as well, but there's no obvious or standard "default" layer name. Popular tools like Tippecanoe may reuse the source file name as the layer name (you can explicitly name those layers if you want instead), or similar behavior. Other tools may just use a generic layer name like features.

This has come up repeatedly as a gotcha when using single-layer MVT sources in Tangram, because it's not always natural to realize you have to specify the layer in these cases.

This PR changes the data source layer matching behavior such that, for any data source that has a single layer, that layer will be matched in cases where no source layer name is specified in the data block. (If a layer name is specified, Tangram will still try to match on that, and return no data if the layer names don't match.)

bcamper commented 5 years ago

Also see #713.

bcamper commented 5 years ago

cc @matteblair @meetar @tallytalwar @nvkelso @burritojustice

Any thoughts or gotchas here, as this changes the default data source layer name matching? I'm slightly worried about that, but think on balance this change will be more likely to generate the "expected" response.

nvkelso commented 5 years ago

I've also come up against this a few times and I think this is a useful change.

Both this and the other PR need Tangram ES changes, too.

bcamper commented 5 years ago

@nvkelso yep, waiting to create ES issues until we decide to move ahead, but do need to do that! Thank you for the ones you made to track other recent additions :)

matteblair commented 5 years ago

Seems useful!

I feel like this makes the data layer syntax harder to understand, the mental model of this option now requires more invisible variables and rules. However I would also believe that this "does the right thing" in practice for most situations.

How do you determine whether a data source has only a single layer? As I understand it, we don't know what layers are in a source until we get tiles from it. So how would we reason about an ocean tile that contains only the water layer? (I'm not sure if any known tile sources actually do that).

pnorman commented 5 years ago

How do you determine whether a data source has only a single layer?

You can't.

As I understand it, we don't know what layers are in a source until we get tiles from it. So how would we reason about an ocean tile that contains only the water layer? (I'm not sure if any known tile sources actually do that).

I think that's fairly common.

bcamper commented 5 years ago

How do you determine whether a data source has only a single layer?

You can't.

As I understand it, we don't know what layers are in a source until we get tiles from it. So how would we reason about an ocean tile that contains only the water layer? (I'm not sure if any known tile sources actually do that).

I think that's fairly common.

Hmm yes that's a good point. I'd been thinking of data sources that are inherently or known in advance to be single-layer, but you are right that this could be a problem with basemap tiles. That would create inconsistent behavior here so we'll probably have to abandon this change, absent support for something with more formal source definition like TileJSON.

I think I will close this for now, though if others have suggested changes to make something like this work, please drop them here.