-
Notifications
You must be signed in to change notification settings - Fork 210
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
Comments
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? |
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. |
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? |
@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. |
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. |
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
The text was updated successfully, but these errors were encountered: