Re: [mkgmap-dev] Terraced/pixellated coastline with --precomp-sea

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

Re: [mkgmap-dev] To do: If-Then-Else

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

Re: [mkgmap-dev] Terraced/pixellated coastline with --precomp-sea

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

[mkgmap-dev] Commit r3819: fix typo: use int instead of double for duplicate point detection

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=3819

[mkgmap-dev] Commit r3818: code improvements, no change in output expected

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

Re: [mkgmap-dev] unpaved roads

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] aeroway in default style

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.

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

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

Re: [mkgmap-dev] aeroway in default style

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