Hi NopMap,
yes, docu is not correct here reg. the combination of options --precomp-sea and
--generate-sea.
The precompiled sea data (sea.zip) from e.g.
http://www.mkgmap.org.uk/download/mkgmap.html
doesn't contain type=multipilygon relations. It contains pbf files with
(generated) ways with the
Hi,
yes, Steve also noticed similar problems in the branch which also exist in
trunk:
"It should be possible to do this:
boundary=administrative { set mkgmap:if:0001=1 }
mkgmap:if:0001=1 & admin_level<3 [0x1e resolution 12]
mkgmap:if:0001=1 & admin_level<5 [0x1d resolution 19]
mkgmap:if:0001!=1
I definitely did not have a regular rule for natural=sea in my style. I need
to check whether there was a rule added by code in my tooling. (or in mkgmap
code)
Is the observation correct, that the SeaGenerator creates many simple
polygons, individually tagged as natural=sea, but not connected by a
Version mkgmap-r3819 was committed by gerd on Wed, 22 Feb 2017
fix typo: use int instead of double for duplicate point detection
No change in output expected, but maybe a minimal performance impact
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3819
_
Version mkgmap-r3818 was committed by gerd on Wed, 22 Feb 2017
code improvements, no change in output expected
- add constant Area PLANET
- add some unit tests to detect problems with > 30 bits resolution
- initialize minlat/minlon etc. with Integer.MAX(MIN)_VALUE
http://www.mkgmap.org.uk/websv
Gerd Petermann writes:
> I tried to create a patch for the rules which set mkgmap:unpaved using
> the wiki and taginfo:
> https://taginfo.openstreetmap.org/keys/surface#values
>
> One probem with surface is that we have so many values (taginfo lists
> 4844 different today), many of them typos or
Hi Ticker,
okay, I'll try to find out (again) why I decided to do the move only in
low-prec. I know that I was not happy with that, but I forgot the reason. I
think one was that the WrongAngleFixer started to move points too far. Anyway,
I should fix this first.
I started to go for 32 bits bec
Hi
According to my calcs, full 32 bit integers give a resolution of about
10mm at the equator. Why do you need better than existing high-res (30
bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.
Not to have the resolution as a powerOfTwo of the garmin map unit would
require a lot o
Hi Andrzej,
sounds possible, but would require lots of difficult changes.
That's the problem, each possible way seems to include lots of changes :-(
I think the first step is to code more unit tests ...
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popo
Hi Gerd,
could you really make a map, which include both +180 and -180
coordinates? I create a map of Asia and I intentionally limit area to
179., because of compilation problems.
Maybe if you limit input data that way, that you never process -180 and
+180 at the same time, then you coul
Hi Gerd,
functions like proposed create_area() perform tasks, that I usually
would do with a GIS program. Unfortunately processing OSM is not easy
like for example SHP. That's why I'd like to put some of these functions
into mkgmap. It's not a good solution but could be convenient.
create_ar
Hi Andrzej,
no, it causes lots of problems.
For example, the bounding box for planet is (-90.0, -180.0, 90.0, 180.0).
If we don't distinct the positions of the left side from the right the area is
a line with width 0.
The funny thing is that the precision in OSM doesn't even use all possible 32
Hi Gerd,
> I found new problems, e.g. 180.0 degrees and -180.0 degrees started
> to give the same 32 bit value.
Isn't it good? The same is true for 24 bit precision and even for 8bit
angles.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgma
Hi Ticker,
I thought about this for a while and I am still not sure where to go.
One problem with the high-prec stuff is that it is missleading.
When I started to code the highprec() code my only intention was to be able to
retreive "the original" position as coded in OSM.
You probably learned it
Hi Andrzej,
sorry, I somehow missid this post before. I agree in all points.
The "create_area" function seems a bit too special as it only makes sense for
maps without a TYP file, right?
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet:
15 matches
Mail list logo