Of course, (vector) tiling is an inevitable phase of any efficient mapping system covering large areas. But tiled data representation of the RW objects has many drawbacks/limitations especially when it comes to error detection, spatial analyses, data volume and so on and this is what I want to comment very shortly. Assume, we understand the same thing when mentioning notions like tile-frame, data-tile (shortly - tile), tile grid, tiling and so on. Though, this is risky and could cause misunderstandings (just try to find a well-founded tile definition, you will be surprised). Anyway, the last point in this related article https://www.mapbox.com/developers/vector-tiles/ indicates that a vector tile is an extract from an input object data layer (like primary roads, lakes, rivers, buildings.) provided by clipping along the tile-frame and restructuring (the data format, compression, languages. here are totally irrelevant). Consequently, tiles are mutually independent and are adding huge extra fragmentation (to the already fragmented) source data. At the same time, most of the spatial analyses and error detection issues require large/un-fragmented data (model of the RW objects), except maybe in some trivial cases. Here are some examples. Assume the task/analyses needs all roundabouts on a long primary road or building-layouts in a larger area, or the water surface of a large lake or all islands/holes in a river, just to mention some. Because of the tiling based fragmentation, the related tile based search/retrieval is practically impossible and so is the task. Example gratia, many of the islands/holes on a river source data will simply disappear after tiling (if a tile-frame edge crosses a hole the corresponding border line will be clipped into segments and these will get outer area border roles in restructuring). Regards, Sandor
P.S. Besides the mentioned limitations, the tiling based fragmentation may cause unwanted rendering effects too. If interested, there are more details, examples and arguments here https://drive.google.com/file/d/0B6qGm3k2qWHqTlREaEN3QnF0T0k/view?usp=sharing -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 05 September 2015 14:00 To: [email protected] Subject: dev Digest, Vol 126, Issue 3 Send dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..." Today's Topics: 1. OSM QA Tiles for data analysis (Matt Greene) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 Sep 2015 16:18:48 -0700 From: Matt Greene <[email protected]> To: [email protected] Subject: [OSM-dev] OSM QA Tiles for data analysis Message-ID: <caorm0a8cr+g68vffudyafgejxtd7bfq7874sexxdvnai2me...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" As announced yesterday on Mapbox's blog ( https://www.mapbox.com/blog/osm-qa-tiles/), a full-spectrum vector tileset of OpenStreetMap is now publicly available for download at http://osmlab.github.io/osm-qa-tiles/. We are generating these tiles with libosmium - Jochen wrote about this just this week ( https://lists.openstreetmap.org/pipermail/dev/2015-September/028671.html) and tippecanoe. At Mapbox we're using this QA tiles to discover disconnected roads, alignment errors, vandalism, etc. This is further facilitated by using these tiles in conjunction with Turf.js (http://turfjs.org/), the javascript-based geospatial analysis toolset, and Tile Reduce ( https://github.com/mapbox/tile-reduce), which can run the analysis across all tiles in a given area. We're opening this work with the spirit of sharing approaches to improve the map - I'd love to get some feedback from members on here regarding this release and its potential to provide meaningful QA for OpenStreetMap. Cheers, Matt Greene -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20150904/e964d91e/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev ------------------------------ End of dev Digest, Vol 126, Issue 3 *********************************** _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
