Hi Ticker,
on my machine (AMD Ryzen 9 PRO with 64GB RAM) it takes 6 minutes if
everything is Ok. But with my own self generated shapefile, I don't
remember the times of my tests with the upstream ones. I think they
where much longer.
I don't know exactly how long it took with my old machine (was a 8 year
old cheap Intel machine with 32GB RAM). It was always quick, too, but I
don't remember the exact times. But must be far below an hour, else I
wouldn't have generated the sea data daily.
My own shapefiles have always splitted polygons, since this is the
default of osmcoastline.
I will try to make my self generated shape file available the next days.
The file from
July, 8th has a huge amount of wrong coastline ways. Newer files should
be better, but looking at my latest "osmcoastline" run, there are still
66 wrong rings and somebody managed again to break the coastline :(
Regards,
Thorsten
Am 2026-07-12 11:27, schrieb Ticker Berkin via mkgmap-dev:
Hi Thorsten
I've been adding diagnostics and working in reducing memory usage.
Even with this it is going to take my machine (i7-2600, 3.4GHz, 4 core,
16G) a
few days to process all the tiles. How long did it take you and how
powerful is
your machine.
Using land-polygons-complete from 08-Jul-2026, in some areas I'm
getting quite a
diagnostic errors from the MultiPolygon processing.
Do you run with -Dlog.config=mkgmap_log.props where this contains
something
like:
# The default level FINE, WARNING, INFO, SEVERE
# use with java -Dlog.config=d:\dbg\mkgmap_log.props ...
.level=WARNING
#.level=SEVERE
handlers: java.util.logging.FileHandler
java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
#java.util.logging.ConsoleHandler.encoding=UTF-8
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%4$.4s: %3$s %5$s%n
...
Some coastline problems don't become obvious until the line / polygon
is split
across tiles.
Ticker
On Wed, 2026-07-08 at 06:16 +0100, Ticker Berkin via mkgmap-dev wrote:
Hi Thorsten
Running with land-polygons-complete, data dated 2026-07-02T00:00:00Z,
I got
the
behaviour as I described with no errors reported - when I killed it
Java was
using all 4 cores of my machine (typically 385% CPU usage)
Last night I tried land-polygons-split, data dated
2026-07-06T00:00:00Z. It
generated lots of sea output files quite quickly then started getting
OutOfMemoryErrors and the pool-threads started dying. After 5 hours it
had
produced 10663 sea files and ceased to use CPU.
I'll continue investigating
Ticker
On Tue, 2026-07-07 at 14:24 +0200, Thorsten Kukuk wrote:
>
> Hi Ticker,
>
> Am 2026-07-07 13:10, schrieb Ticker Berkin via mkgmap-dev:
> > Hi Thorsten
> >
> > I've got this running with latest/trunk mkgmap, up-to-date java system,
> > geotools-35.0 and land-polygons-complete-4326. I let it runs for 16
> > hours on my
> > 16G machine and it went from 131072 to 122940 tiles remaining,
> > generating 386
> > files in sea-latest. I had to kill it as my machine became unusable for
> > other
> > work!
>
> This sounds like most of or all of your java worker threads died (heap
> overflow?).
>
> If this happens, then you will either see a heap overflow error
> somewhere in the output or a java core file in your working directory.
> If this happens, your java process will not die but continue to run.
> Did you check the output for errors?
>
> Thorsten
>
>
_______________________________________________
mkgmap-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________
mkgmap-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________
mkgmap-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo/%(_internal_name)s
