Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nice To have: BBox or Centroid per Feature #101

Open
strech345 opened this issue Dec 11, 2017 · 5 comments
Open

Nice To have: BBox or Centroid per Feature #101

strech345 opened this issue Dec 11, 2017 · 5 comments

Comments

@strech345
Copy link

Hello,

by geojson spec features could have a bbox
see https://geojson.org/geojson-spec.html#bounding-boxes

i need to read as fast as possible the the boundary box per feature. I export it now as propertie, but it will scale the filesize by 3 times. So maybe its possible to get it as small as the geometry by include it and calculate it with tippecanoe and put it to the bbox attribute?
Would be nice to include it to the vector-tile-spec

Thanks

@andrewharvey
Copy link

At the moment making a map in Mapbox GL, if you want a zoom to fit feature function, sometimes you might not have the whole feature in the view if it's split across tiles, if we had the feature bbox, you immediately know how to zoom to fit that feature (at least for bearing: 0).

@strech345 identifies the current workaround, but native support would support this use case.

@flippmoke Is this specifically not being considered for v3?

@flippmoke
Copy link
Member

I am not overly convinced currently this should be a part of the VT specification, but I am listening.

Currently you can update individual vector tiles with out it necessarily affecting another tile. Suppose you are adding a new point to a multipoint feature and suddenly it adds one new point and the multipoint is across 5 tiles already. The new point would simply add a point to a 6th tile. If you have to update bounding box, then I would have to update every single tile perhaps. Understandably this could be optional, but if its optional it means that it might not be used or filled in situations where it is wanted for a feature as you described above.

@andrewharvey
Copy link

Encoding a feature bbox in the vector tiles is a simple way to say if you want the whole feature then download all the tiles within this bbox and you're guaranteed to get the complete feature.

Are there any other better ways to do this?

@flippmoke
Copy link
Member

@andrewharvey I wonder if this should be done prior or as an external service though at times because I feel this would be better then including extra data into tiles. I suppose it greatly depends on what sort of data you are dealing with however.

@andrewharvey
Copy link

Right now I'm dealing with it externally, via a bbox property, which does work as @strech345 pointed out. I suspect having it part of the mvt spec would reduce the file size slightly, but given it's only two coordinates pairs for each feature, it's probably not by much.

The benefit of having this in the spec really comes from it being standardised across all tools creating and consuming mvt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants