Hi all,
as a result of the thread opened by Bernhard Hiller
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026480.html
it turned out that the current implementation of the --bounds option causes
problems when you compile a
tile that covers a huge area but contains rather few data for that
Version mkgmap-r3861 was committed by gerd on Wed, 22 Mar 2017
improve performance of LocationHook when input file bounds data is huge.
Calculate the intersection of the bounds and the bounding box of all nodes
instead of using the bounds directly.
http://www.mkgmap.org.uk/websvn/revision.php?re
Hi Bernhard,
I assume that the merged file doesn't contain a bbox. In that case you may see
a few nodes from ferry routes in the input file and
splitter will calculate a bbox containing them. I did not see this problem when
merging Belgium + Netherlands with osmconvert.
Anyway, you may solve th
Hi Gerd,
I probably misunderstood reason for the last change. No problem anyway.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej,
the tags fixme and FIXME are checked in mkgmap to disable the dead-end-check. I
see no way to analyse the meaning of
these other tags, so this should be no problem.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Dienstag,
Hi Bernhard,
okay, that is a good guess. How do you combine the files? Do you download
single country extracts from geofabrik
and merge them with osmconvert? Or maybe another tool?
The splitter log file may show some hints why the area is so large, and maybe
you should check splitter option
no-
Hi,
there are more tags like "fixme", which can contain fixme info. This
could be "note", "description", "comment". See:
http://wiki.openstreetmap.org/wiki/Key:fixme
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
mkgmap is running now, I'll likely report tomorrow.
But I already saw that the first tile took very long, and in the areas
file it is:
4311: 1765376,-935936 to 2822144,139264
# : 37.880859,-20.083008 to 60.556641,2.988281
So, I suspect that here could be a problem: some of
Version mkgmap-r3860 was committed by gerd on Tue, 21 Mar 2017
correction for new option --ignore-fixme-values: don't remove the tags fixme or
FIXME if they have the value like fixme
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3860
Version mkgmap-r3859 was committed by gerd on Tue, 21 Mar 2017
Implement new option --ignore-fixme-values to ignore tags with values that
contain the fixme pattern. If one uses the option he can disable the
corresponding rules
in inc/name.
--ignore-fixme-values
Tells mkgmap to ignore al
Version mkgmap-r3858 was committed by gerd on Tue, 21 Mar 2017
refactoring: method idVal(String) is only used for XML reader
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3858
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Tue, Mar 21, 2017 at 7:03 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> yes, I also think that mkgmap should not modify the data by default.
+1
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
__
Hi Nick,
yes, I also think that mkgmap should not modify the data by default.
Gerd
Von: mkgmap-dev im Auftrag von osm@
Gesendet: Dienstag, 21. März 2017 12:50:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] fixme rules
Hi Gerd
Personally
Hi Gerd
Personally I would not recommend setting the option active by default as
some osm plotters may want to tag fixmes as a quick and visual way to
highlight and address possible fixmes.
I create maps showing fixme pois with labels containing the actual fixme
statement.
r
Nick
On 21
Hi Gerd,
removing fixme in code seems to be OK. You could even set option active
by default.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
In dispite we don't have this kind of problem in our Brazilian project (we
don't use OSM as source for maps), I agree with you that the first option
is better.
Alexandre
2017-03-21 7:04 GMT-03:00 Gerd Petermann :
> Hi all,
>
> any feedback on this?
> I see several ways to improve fixme handling.
Hi all,
any feedback on this?
I see several ways to improve fixme handling.
1) add a new option --ignore-fixme-values which is used when
reading osm data and means: ignore all tags when the value matches the fixme
pattern '(?i)fix[ _]?+me'
Disadvantage:
- Would add a regular expression check for
Version mkgmap-r3857 was committed by gerd on Tue, 21 Mar 2017
- refactoring to improve readability of code for high precision
- add TODO for 32 bit high prec
based on modified diff_coord_v3.patch
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3857
_
Hi Bernhard,
other tests did not show new results. Any idea why you got so different numbers?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Montag, 20. März 2017 07:40:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Performan
19 matches
Mail list logo