Hi,
I am not sure regarding the sizes of the area. At least one of the riverbank
polygons is a
multipolygon with two outer rings. The size calculation treats each outer
ring separately, without
subtracting the area of inner rings.
@Ticker: Is that intended?
Besides that I think that the
Hi Jakob,
Jakob Mühldorfer-2 wrote
> * The point simplification algorithm treats previously merged areas
> (like two buildings with common nodes) as separate and shapes might
> be more correct
Not really. The effect is that the ShapeMergeFilter is more or less
disabled. The screenshots
Yes thank you, I reproduced that now with 4mio nodes a tile 2/210 were
too large
Understood
Am 12.11.2016 um 23:40 schrieb Carlos Dávila:
Right, then you'll receive something like this:
GRAVE (MapFailedException): usa/60248060.o5m: (thrown in
BufferedImgFileWriter.ensureSize()) There is not
I know there is a built in draw order between some types. But I am sure that
those extended types I use for depth areas have the same draw order.
A few years ago I did some testing and learned that I can influence which
polygon is drawn on top by sorting the input. But this method only worked
This is a much higher increase in size than I was seeing; 14% rather
than around 3%. This might be due to lots of buildings being merged; I
suppress buildings in my style.
If you are happy with TYP/_draworder then use that. I didn't like the
idea of it at all.
Shape merging could be implemented
On my device I have to override the inbuilt _draworder, which gives a
higher priority to Ocean/Sea 0x32, to stop the sea areas hiding
everything - I just give polygon types 0x01 to 0x55 level 1 except for
background 0x4b which I give level 0. I don't have any extended types.
Is this on a device
Right, then you'll receive something like this:
GRAVE (MapFailedException): usa/60248060.o5m: (thrown in
BufferedImgFileWriter.ensureSize()) There is not enough room in a single
garmin map for all the input data. The .osm file should be split into
smaller pieces first.
Number of
I am guessing that
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
would be non zero, if I choose to high nodecount in one tile?
Am 12.11.2016 um 10:05 schrieb Gerd Petermann:
Hi Jakob,
Jakob Mühldorfer-2 wrote
* Does the splitter print an error when max-nodes is too
Thanks for writing the patch Ticker
Quite an impact on file size here:
3.872.456.704Byte to 4.431.544.320Byte in a Central European region with
the default style
So did I read correctly that the only benefit on a device with typ that
has draworder is
* Small Polygons on Polygons of the
Hi Jakob,
Jakob Mühldorfer-2 wrote
> * Does the splitter print an error when max-nodes is too large, or is
> it unpredictable and will it only fail on the GPS device
No. There is no specific limit on the number of nodes in the device, the
value is just an easy to calculate number which
10 matches
Mail list logo
