> * Problem: Since we are speaking about "vector tiling" it's > unavoidable that polygons are clipped, which makes me wonder on how > the client is informed and how he should deal with this?
I'm not sure if I have a complete answer for that yet. Do you have any suggestions? One possibility is to do what the API does for bbox queries, where complete geometry for ways with a node intersecting the tile is included, and also the relations which refer to the stuff in the tile, but that's it. (So if you have a tile intersecting with the border of a country, you don't get the entire border, just one part of it.) This may be a bit unsatisfying for client-side rendering, since it's possible that a tile could be sitting entirely inside some kind of polygon, and the client wouldn't know until it downloaded one (or more) of the tiles around that. Another idea: if a tile is contained entirely within a polygon, include the polygon's tags (or some subset) "along with" the tile, rather than as a feature of the tile. > @Michael: > * In the website you refer to [1] there's mentioned "Similar to kothic > js tile format": Why only "similar"? Why don't you not base/fork on > Kothic/KothicJS? One trivial reason: I'm not sure yet if it makes sense for tiles to be in JSONP (rather than JSON). Also, I may want to abbreviate keys in JSON, and I was considering the possibility of some properties being represented by JSON arrays (for example, a list of element ids). -- Michael _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
