Re: [mkgmap-dev] removal of parallel lines
Hi Mike, the detection of parallel lines isn't easy. The housenumber code contains code to detect this but it fails in some situations (and it works with the high precision points, not with the results of the heavy rounding at lower levels. On the other hand it has to cope with sidewalks and service roads going parallel to main roads, so for your special case it might be possible to do better calculations. The main problem for me was that a road is split into several OSM ways, and the housenumber code has to cope with the fragments that are written to NET. In your case you can try to combine all motorways first and calculate a replacement line for the non-routable overview levels. Reg. the zig-zagging lines I think it isn't the Douglas-Peucker filter, it's the rounding that causes trouble. So, the points of the replacement lines should be calculated in a way that produces stable results for the different levels of rounding. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 9. März 2021 00:54 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] removal of parallel lines Hi all, At low resolutions I would like to be able to remove parallel lines so that (for example) only a single motorway carriageway or railway track is shown instead of two or (in the case of the West Coast Main Line) four lines, which due to different Douglas Peucker line simplifications end up crossing each other, look messy and add unnecessary lines to the overview. Has anyone done this before or have any ideas about how I might go about it? Cheers, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] removal of parallel lines
Hi all, At low resolutions I would like to be able to remove parallel lines so that (for example) only a single motorway carriageway or railway track is shown instead of two or (in the case of the West Coast Main Line) four lines, which due to different Douglas Peucker line simplifications end up crossing each other, look messy and add unnecessary lines to the overview. Has anyone done this before or have any ideas about how I might go about it? Cheers, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tile takes very long time to generate
Hi.
I have uploaded the splitter output
http://files.mkgmap.org.uk/download/502/7773.osm.pbf
This is not the largest splitted pbf, but it generates the largest img-file.
Around 12 MB compared to most other tiles which end up being 4-8 MB.
I tested running mkgmap (--max-jobs=1) with this file only as input (with
default style as well), it took 23 minutes before it was done, including any
startup over head.
I then took one random other pbf file and run mkgmap with the same parameters,
it took 48 seconds including startup and overhead.
I have a portion of data covering nordic and baltic countries, poland, chech,
slovakia, austria, switserland, parts of germany and aslo greenland.
Splitter options:
java -Xmx2200m -jar ${SPLITTER} \
--output-dir=./splitted/ \
--mapid=7771 \
--max-nodes=1275000 \
--no-trim \
kartdata/nord_ost.o5m
mkgmap options:
java -Xmx2800m -jar ${MKGMAP} \
--max-jobs \
--family-name="some name" \
--family-id=7770 \
--mapname=77710001 \
--draw-priority=20 \
--latin1 \
--net --route --index --split-name-index \
--housenumbers \
--add-boundary-nodes-at-admin-boundaries=2 \
--output-dir=./tiles_7771/ \
--bounds=bounds/ \
--precomp-sea=sea/ \
--style-file=styles_7771/ \
--description="some name" \
--add-pois-to-areas \
--lower-case \
./splitted/777*.pbf
is there some other tool or some options i can give to java runtime instead of
using virualvm to see the amount of time/cpu spent in various sections of the
program?
Regards
Karl
On måndag 8 mars 2021 kl. 07:31:44 CET Gerd Petermann wrote:
> Hi Karl,
>
> I don't think that the order of the tiles should make a big difference. It
> is quite normal that some tiles take longer than others, but 30 minutes is
> far too long. One well known reason for slow processing are very complex
> multipolygons like Lake Huron. Another might be huge areas of sea. So, to
> find out if the order or the content is causing the delay you can process
> the tiles in a different order. I often use VisualVM to monitor a running
> mkgmap, it helps to find out which routines are called most often. If you
> identify a single tile that takes very long (also with the default style)
> you can upload that tile to http://files.mkgmap.org.uk/ Best is to add a
> small file with the options that were used, but you can also post them
> here. Hope that helps.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag von 7770
> <7...@foskan.eu> Gesendet: Montag, 8. März 2021 06:53
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] tile takes very long time to generate
>
> Hi.
>
> I observe a situation that one of the very first tiles (often the first or
> the third) that mkgmap generates takes 20 - 30 minutes to generate, wheres
> the others take about 30 seconds each.
>
> The map data produced by splitter is a total of around 700 files with
> splitter option --max-nodes=1275000.
>
> sea and bouds are used for mkgmap.
>
> At first i thought i am running low on memory but changing to max-jobs=1
> (instead of the possible max of 2) did not make any change.
>
> Is mkgmap doing something specific in the beginning that can explain this
> long time generating one of the very first tiles?
>
> I can provide more details, let me know how i can best collect those details
> in case i need to set some parameters to have mkgmap to say more about what
> it is doing.
>
> Regards
> Karl
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] -c option crash
Hi Gerd, The attached patch fixes a crash if you inadvertently specify a .o5m file after the -c command line argument. Cheers, Mike CommandArgsReader.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] omit items from overview
Hi Ticker, Yes this does work, but you are right that the test for isOverviewComponent or isOverviewCombined only needs to test for isOverviewComponent and it doesn't need the change to OverviewMapDataSource. Please find an updated patch attached. Cheers, Mike -Original Message- From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] Sent: 08 March 2021 08:44 To: Development list for mkgmap Subject: Re: [mkgmap-dev] omit items from overview Hi Mike Does this work? There is no information about the tagging when the elements are read back from the ovm_ file. In MapBuilder I think you have to test for isOverviewComponent rather than isOverviewCombined and I don't think changes to OverviewMapDataSource make any difference to anything. Ticker On Sun, 2021-03-07 at 21:56 +, Gerd Petermann wrote: > Hi Mike, > > do you have a use case for that? My approach would be to change the > resolution/level for the object, so I wonder why we need a special > variable. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Mike Baggaley > Gesendet: Sonntag, 7. März 2021 22:30 > An: 'Development list for mkgmap' > Betreff: [mkgmap-dev] omit items from overview > > Hi Gerd, > > Please find attached a patch that causes objects that have > mkgmap:nooverview=yes to be omitted from the overview map. > > Cheers, > Mike > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev OverviewContent2.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] omit items from overview
Hi Mike, you lost me. Please describe what you do with -- levels and --overview-levels, how and why. I can't think of any situation where I would want to double the data to occur both in the detail map tiles and the overview map. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Montag, 8. März 2021 09:48 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] omit items from overview Hi Gerd, yes, I have overlapping resolutions for the overview and main map. Cheers, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 07 March 2021 21:56 To: Development list for mkgmap Subject: Re: [mkgmap-dev] omit items from overview Hi Mike, do you have a use case for that? My approach would be to change the resolution/level for the object, so I wonder why we need a special variable. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Sonntag, 7. März 2021 22:30 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] omit items from overview Hi Gerd, Please find attached a patch that causes objects that have mkgmap:nooverview=yes to be omitted from the overview map. Cheers, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tile takes very long time to generate
Hi Karl, The first tile is likely to be generated with only a single thread running whilst memory usage is checked, then the remainder may use both your processors. If there is something about this tile that causes it to take a long time, it may be worth moving it back in the list so that it doesn't hold up starting of parallel processes, resulting in an overall reduction in processing time. Cheers, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 08 March 2021 06:32 To: Development list for mkgmap Subject: Re: [mkgmap-dev] tile takes very long time to generate Hi Karl, I don't think that the order of the tiles should make a big difference. It is quite normal that some tiles take longer than others, but 30 minutes is far too long. One well known reason for slow processing are very complex multipolygons like Lake Huron. Another might be huge areas of sea. So, to find out if the order or the content is causing the delay you can process the tiles in a different order. I often use VisualVM to monitor a running mkgmap, it helps to find out which routines are called most often. If you identify a single tile that takes very long (also with the default style) you can upload that tile to http://files.mkgmap.org.uk/ Best is to add a small file with the options that were used, but you can also post them here. Hope that helps. Gerd Von: mkgmap-dev im Auftrag von 7770 <7...@foskan.eu> Gesendet: Montag, 8. März 2021 06:53 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] tile takes very long time to generate Hi. I observe a situation that one of the very first tiles (often the first or the third) that mkgmap generates takes 20 - 30 minutes to generate, wheres the others take about 30 seconds each. The map data produced by splitter is a total of around 700 files with splitter option --max-nodes=1275000. sea and bouds are used for mkgmap. At first i thought i am running low on memory but changing to max-jobs=1 (instead of the possible max of 2) did not make any change. Is mkgmap doing something specific in the beginning that can explain this long time generating one of the very first tiles? I can provide more details, let me know how i can best collect those details in case i need to set some parameters to have mkgmap to say more about what it is doing. Regards Karl ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] omit items from overview
Hi Gerd, yes, I have overlapping resolutions for the overview and main map. Cheers, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 07 March 2021 21:56 To: Development list for mkgmap Subject: Re: [mkgmap-dev] omit items from overview Hi Mike, do you have a use case for that? My approach would be to change the resolution/level for the object, so I wonder why we need a special variable. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Sonntag, 7. März 2021 22:30 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] omit items from overview Hi Gerd, Please find attached a patch that causes objects that have mkgmap:nooverview=yes to be omitted from the overview map. Cheers, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] omit items from overview
Hi Mike Does this work? There is no information about the tagging when the elements are read back from the ovm_ file. In MapBuilder I think you have to test for isOverviewComponent rather than isOverviewCombined and I don't think changes to OverviewMapDataSource make any difference to anything. Ticker On Sun, 2021-03-07 at 21:56 +, Gerd Petermann wrote: > Hi Mike, > > do you have a use case for that? My approach would be to change the > resolution/level for the object, so I wonder why we need a special > variable. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Mike Baggaley > Gesendet: Sonntag, 7. März 2021 22:30 > An: 'Development list for mkgmap' > Betreff: [mkgmap-dev] omit items from overview > > Hi Gerd, > > Please find attached a patch that causes objects that have > mkgmap:nooverview=yes to be omitted from the overview map. > > Cheers, > Mike > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
