[mkgmap-dev] Problem with splitter

Tue Mar 13 05:59:30 GMT 2012

Hi Wolfgang,

yes, that' s exactly what happens. I see three ways to solve this problem:
1) Enhance the logic in mkgmap that guesses how the missing ways completed
the multipolygon, e.g. by adding a backtracking algorithmn (this is already
suggested in the code).
2) Enhance splitter so that it writes all points and all ways of
multipolygon to each tile.
3) Enhance splitter to write one extra output file that contains only the
1st and last point of each way that is part of a multipolygon, and create a
method in mkgmap that looks for this data when 
it doesn't find the way in the normal input. We need only the end points
because we use the data only in cases where we know that they are outside of
the bounding box. Maybe that can be done with osmfilter as well ?

I did not start coding, but I think option 3) should be easy to do and I
hope it solves most
of the problems. Option 2) looks more difficult and will blow up tile sizes
and CPU cost both in splitter and mkgmap. Option 1) can be done as well. 

Does that sound reasonable?

Gerd

Wolfgang Hammel wrote
> 
> Hi Gerd,
> 
> when I had the problem some time ago, I did some rough checking on 
> splitters output.
> What I know so far is, that splitter removes all the ways from a certain 
> tile that have no
> node inside this tile.
> The problem arises when a tile boundary divides a multipolyon that 
> consist of normally
> a lot of different ways. Tile splitter includes the complete relation 
> for that multipolygon
> in the output including all the references to the ways that 
> mulitipolygon originally consisted of.
> But as some of the ways are removed from the output, the multipolygon is 
> corrupted and
> mkgmap is later no more able to correctly reconstruct the part (or 
> parts) of the multipolygon
> that fall inside the tile.
> 
> Wolfgang
> 
> Am 12.03.2012 16:06, schrieb GerdP:
>> Hi Matteo,
>>
>> okay, I am able to reproduce the problem (also without the coastfile
>> parameter).
>> The log shows some warnings for  relation 541757 (the Lago di Como) , so
>> I
>> should be
>> able to understand what's happening and why it fails.
>>
>> Gerd
>>
>>
>>
>> Matteo Gottardi wrote
>>> 2012/3/12 GerdP&lt;gpetermann_muenchen@&gt;:
>>>> Hi Teo,
>>>>
>>>> I tried to reproduce the problem with mkgmap trunk version r2248, but I
>>>> get
>>>> different results, esp. I don't see this flooding.
>>>> I am using coastlines_europe-120128.osm.pbf, maybe your file is older?
>>> Hi Gerd,
>>> my coastlines file was the same as yours, only with a different name :)
>>>
>>> I did some tests. The results were a bit different because of my typ
>>> and style files.
>>> Using no typ file, the default style file and passing only
>>> --generate-sea=multipolygon
>>> --coastlinefile=coastlines_europe-120128.osm.pbf the result look like
>>> this: http://www.gomatteo.net/17.png
>>>
>>> PS: I would like to thank all the developers who spends their time
>>> working on this great project, without mkgmap my gpsmap60c would be
>>> useless :)
>>>
>>> -- 
>>> * Matteo Gottardi | matgott@
>>> * ICQ UIN 20381372
>>> * Linux - the choice of a GNU generation
>>> * GPG Fingerprint:
>>> * B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at .org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Problem-with-splitter-tp5555886p5558068.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at .org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at .org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 

--
View this message in context: http://gis.19327.n5.nabble.com/Problem-with-splitter-tp5555886p5560021.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.