[osmosis-dev] Cutting PBF file into 1° tiles
Sylvain Melin
s.melin at alsim.com
Mon Apr 18 12:19:48 UTC 2016
Hi Peter and thank you for your help.
I had the same kind of approach and I guess the problem was your 4th point.
I'll give a try at osmconvert with "complex-ways" option as a second step.
But as you mentioned, there will be a problem with features that are
bigger than the margin.
Anyway, this will be a good temporary solution and I will have to move
Jochen's solution as soon as I have a better system with enough RAM.
Thank you again for this detailed description and your sources, I'll
definitely give it a look.
Regards,
Sylvain
On 18/04/2016 13:42, Peter Svensson wrote:
>
> Hi
>
> I've spent a lot of time trying to solve this problem for OSMTileMachine.
> OSMTimeMachine is basically a tool that bridges the gap between a full
> planet file and a data consumer loads all the data into RAM.
>
> This makes it possible to render a map of a very large region using
> Maperitive (which itself cannot handle very large amounts of data, due
> to the loads-everything-into-memory-limitation). See example of
> results here: www.mtbmap.se <http://www.mtbmap.se> . This map is
> rendered using OSMTileMachine. I don't know about your requirements,
> but as a working proof of concept, the input do that map is a single
> planet.pbf and all of this is rendered on a Windows PC with 8 GB of RAM.
>
> So what I have figured out so far is this:
>
> 1. osmconvert is MUCH faster than osmosis for extracting data, at
> least for me.
>
> 2. For generation of map tiles, complete ways/relations are needed.
> This means that at the boundary, everything related to each
> way/relation passing through the boundary of the tile image needs to
> be complete.
>
> 3. osmconvert with the "complex-ways" option is very suited to
> generate complete data for visualisation of a geograpically limited
> region (square). I use 0.04 degrees of margin when i extract data for
> a tile for zoom level 10.
>
> 4. it's not possible to use the complex-ways cutmethod at the full
> planet due to time and/or RAM/DISK usage.
>
> 5. If i extract the data in two steps, it is possible to prepare
> complete data for a small box:
>
> 6a) First extract a region AROUND the box of interest with cutmethod
> "clip". I think this is default for osmconvert. I use 2 degrees of
> extra margin around my box of interest here. This makes it possible to
> produce anything within reasonable abount of time and RAM / disk usage.
>
> 6b) Since the output of 6a) is too big for my data consumer (in my
> case maperative) i need to shrink it again and cut away even more
> data. This time i clip at the exact box of interest + 0.04 degrees.
> (This is what i need to have enough overlap for place-labels etc that
> can stick into neighboring map tiles). If i use the complex-ways
> method i will not loose any data inside my map file and the results
> looks good.
>
> The drawback is that features that are larger than 2 degrees will be
> incomplete. This is mainly a problem for very large lakes and of
> course the coastline.
>
> Some source code, if you have an interest:
>
>
> https://github.com/psvenz/OSMTileMachine/blob/master/osmTileMachine/src/osmTileMachine/SplitAndRenderStrategy.java
>
> Hope this helps.
>
> with regards,
> zvenzzon
>
>
> On Mon, Apr 18, 2016 at 10:10 AM, Sylvain Melin <s.melin at alsim.com
> <mailto:s.melin at alsim.com>> wrote:
>
> Hi everyone.
>
> I'm working on a 3D earth rendering engine and I want to use osm
> data for forest, cities, roads, etc...
> Of course it involves a lot preprocessing to filter and convert
> vector data into OpenGL friendly format.
>
> My plan is to :
> - exploit a planet sized pbf file
> - cut it into 1° tiles using osmosis
> - filter and extract the data from these tiles as shapefiles using
> libosmium
> - rasterize these shapefiles with gdal
>
> My problem occurs when trying to cut the big PBF file into tiles.
> I can't find an efficient way to prevent the elements from being
> clipped on the edges of the tiles.
>
> I've tried to use completeWays=yes and completeRelations=yes but
> the first tile was still empty after a few hours when it took 6
> minutes to process it without these options.
>
> The only way I can see to limit the damage is to set a wider
> bounding box than necessary but there will always be a polygon
> bigger than my margin that will be clipped, and the size of my
> tiles is also greatly impacted.
>
> Do you have any suggestion about this ?
>
> Thanks.
>
>
>
> _______________________________________________
> osmosis-dev mailing list
> osmosis-dev at openstreetmap.org <mailto:osmosis-dev at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osmosis-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20160418/be62c72f/attachment.html>
More information about the osmosis-dev
mailing list