logo separator

[mkgmap-dev] Problem in splitter (Africa)

From Steve Sgalowski steve.sgalowski at gmail.com on Wed Jan 7 06:57:41 GMT 2015

gerd , have tried some of your ideas
no not all worked for me
however have worked out and are combining my poi strings
am re checking now with the new poi test file you have just uploaded to
mkgmap server

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/20150107/f50d9e20/attachment.html>


More information about the mkgmap-dev mailing list