[OSM-dev] dev Digest, Vol 126, Issue 3

Sandor Seres sandors39 at gmail.com
Tue Sep 15 09:18:21 UTC 2015

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

-----Original Message-----
From: dev-request at openstreetmap.org [mailto:dev-request at openstreetmap.org] 
Sent: 05 September 2015 14:00
To: dev at openstreetmap.org
Subject: dev Digest, Vol 126, Issue 3

Send dev mailing list submissions to
	dev at openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	dev-request at openstreetmap.org

You can reach the person managing the list at
	dev-owner at openstreetmap.org

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 <matt at mapbox.com>
To: dev at openstreetmap.org
Subject: [OSM-dev] OSM QA Tiles for data analysis
	<CAORm0a8Cr+G68vFFUDYAFGEjxtd7BfQ7874seXxdvNai2mEK2Q at 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 (
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.

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
dev at openstreetmap.org


End of dev Digest, Vol 126, Issue 3

More information about the dev mailing list