[mkgmap-dev] Problem in splitter (Africa)

Tue Jan 6 10:34:00 GMT 2015

yes gerd p i did
will try it ok gerd p
ty
stephen

On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Stephen,
>
> yes, you should have received an answer a now.
>
> Gerd
>
> ------------------------------
> Date: Tue, 6 Jan 2015 19:15:51 +1000
> From: steve.sgalowski at gmail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
>
> gerd P
>
> did you get my direct e-mail to you sir
>
> stephen
>
>
> On Tue, Jan 6, 2015 at 10:18 AM, GerdP <gpetermann_muenchen at hotmail.com>
> wrote:
>
> Hi Stephen,
>
> the log shows no problems. Why do you think that max-nodes=400000 doesn't
> work?
> Do you see an error message in mkgmap?
> If yes, please provide your style files so that I can reproduce the
> problem.
> Maybe your style still adds one POI for each point of each highway?
>
> Gerd
>
>
> steve sgalowski wrote
> > canada splitter log file
> > as expected ,  looks like i was correct
> > the size of the split has to be smaller
> > stephen
> >
> > On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >
> > wrote:
> >
> >> Final file size depends on the amount of data in the input, not on the
> >> value of max-nodes. If you need a final img smaller than a given size
> you
> >> have to reduce the area covered by the input file or reduce the number
> of
> >> osm elements from the input that go into the map playing with your style
> >> files.
> >>
> >> El 05/01/15 a las 22:07, Steve Sgalowski escribió:
> >>
> >>> gerd and carlos
> >>> i am now running the splitter log file setup on my canada map
> >>> and see what it does , the end result on this map = 6.8 gb img file
> >>> wonder why some country can exceed and others not
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >> <mailto:
>
> > cdavilam@
>
> > >> wrote:
> >>>
> >>>     Not sure what you mean. If you split a given country in a higher
> >>>     number of tiles (lower max-nodes) final size will be the same or
> >>>     slightly bigger, as there are more duplicated info due to overlap.
> >>>     Or you are loosing some information in the process to reduce final
> >>>     file size.
> >>>
> >>>     El 05/01/15 a las 21:34, Steve Sgalowski escribió:
> >>>
> >>>         in some of the countries i do , if i dont make the node count
> >>>         small , the map size exceedds , size limit of 3 gb
> >>>         then unshure how , canada has done this ok
> >>>
> >>>         stephen
> >>>
> >>>
> >>>         On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
> >>>         <
>
> > gpetermann_muenchen@
>
> > >>         <mailto:
>
> > gpetermann_muenchen@
>
> > >
> >>>         <mailto:
>
> > gpetermann_muenchen@
>
> > >>         <mailto:
>
> > gpetermann_muenchen@
>
> > >>> wrote:
> >>>
> >>>             Hi all,
> >>>
> >>>             I wonder what splitter should do in this case:
> >>>
> >>>             Stephen uses paramter --max-nodes=80000
> >>>             and splitter reports
> >>>             "Highest node count in a single grid element is 557,084"
> >>>
> >>>             It is obvious that at least one tile will have much more
> >>>         than the
> >>>             requested 80.000 nodes,
> >>>             on the other hand, the file africa.osm.pbf contains large
> >>>         nearly
> >>>             empty areas,
> >>>             and that makes it very difficult to find a good split.
> >>>             The current version r416 fails because it doesn't accept
> >>> tiles
> >>>             with less than 5% of
> >>>             the max-nodes value, so it searches for a solution where
> >>> every
> >>>             tile has at least 4000 nodes,
> >>>             and that might not exist.
> >>>
> >>>             I see these options:
> >>>             1) splitter can continue trying to split the data,
> accepting
> >>>             almost empty output files
> >>>             (e.g. some with < 5 nodes and very high aspect ratios like
> >>> 32)
> >>>             2) if that fails,  splitter can set the max-nodes value to
> >>>         557,084
> >>>             and try again
> >>>             3) or stop with an error message that tells the user that
> >>>         it is
> >>>             not possible
> >>>             to split with the used resolution
> >>>             4) or restart using a higher resolution  (15 would be
> >>> required
> >>>             here instead of 13),
> >>>
> >>>             @Stephen
> >>>             What reason do you have to use such a small max-nodes
> value?
> >>>             Would it be ok for you to use a higher one?
> >>>
> >>>             Gerd
> >>>
> >>>
> >> _______________________________________________
> >> 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
> >
> > splitter.log (356K)
> > <http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log>
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
> _______________________________________________ mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150106/fd11a48c/attachment.html>