Re: [mkgmap-dev] NSIS option for Basecamp
Hi Diego, > I create different tiles setting the Splitter to 1.600.000, then I add > clipped contours and DEM with Mkgmap. Does your map have layers, like tiles with mapping data and tiles with contours only? If yes, then maybe MapInstall can't select tiles correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Indexing street belonging to two cities
Hi Gerd, > The doc shows that you can have up to three cities, and I've no idea > how to decide which numbers belong to which city. I guess the reasonable solution is to split "CityName" and assign all numbers to all cities. I have tested a bit my map and found that with 2 cities in "numbers" statement without house numbers, search index contains left city (first in statement) and combined city name (Left@Right) form "CityName" statement. Right city is missing. > The good thing is that we have a *.mp file and a GMP output. This > should help to understand the GMP format. This is not a true GMP format. This is an old MPC data packed as a GMP. I have discovered that it works and implemented conversion MPC->NT in GmapTool. Then I explained the idea to Staszek Kozicki and he implemented the same in cGPSmapper. You can convert any img using command line version of GMapTool like this: gmt -jxzo ntlike.img source.img MPC data consist of blocks TRE, RGN, LBL etc. Each block starts with a header and then data. Header contains pointers to data. GMP is similar. It starts with a GMP header, then it contains TRE, RGN, LBL, NET, NOD, DEM (sometimes more) headers and then all data. GMP header contains pointers to following headers. It is relatively easy pack old format as GMP. But it is not a real thing, since it doesn't use any features of NT maps. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Indexing street belonging to two cities
Hi Gerd, > I thought that mkgmap can handle roads with multiple cities but you > seem to be right that this only works when the cities are encoded with > the house numbers. Actually in mp format you can encode void house numbers with 2 cities. Doesn't it work in mkgmap? I mean statement like: Numbers1=0,N,-1,-1,N,-1,-1,Płońsk,-1,-1,Skarżyn,-1,-1 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Merge tiles to gmapsupp based on poly files
Hi Daniel, > How can this "lists of tiles" be generated? I'm doing it with Qgis and some scripts. General idea is to import tiles created by splitter as a layer to Qgis, add region attributes to tiles and export result as a csv file. Then I use awk script on csv to extract IDs of tiles with a selected attribute. This makes a list, which I use as an input to mkgmap. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Merge tiles to gmapsupp based on poly files
Hi Daniel, there should be no problems with routing, because a route should switch maps at the country border. See mkgmap option --add-boundary-nodes-at-admin-boundaries. If you don't like tiles without full content, then use bigger extract and smaller poly file as an option for splitter. See splitter option --polygon-file. Other possibility is to split bigger extract (for example Europe), convert all tiles to img and then create lists of tiles for each country you need (for example Germany and France). Then you can run again mkgmap with list of img as an input, to create separate maps. Unfortunately rectangle tiles causes a problem for address search. If you are near the border on a tile shared by 2 maps, then GPS could use wrong map for a search. Proper solution would be to have irregular tiles cut at an administrative border. This is how original Garmin maps are split into countries. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Osmium -Tool
Hi Thomas, osmium tool executable can be downloaded by conda: https://conda.io/projects/conda/en/latest/user-guide/install/windows.html https://anaconda.org/conda-forge/osmium-tool -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some observations
Hi Ticker, I hope that I understand style parsing correctly now. Thanks for advice. > Not sure what you mean. I'm a programmer. I have some preconception about conditional statement, logical operators etc. Situation, where rules for condition "tag=value" are different than for "tag!=value" is surprising for me. I was aware about some restriction for tests in style, but when I tripped on a problem, I couldn't find a clear explanation in manual. I had to use trial and errors to find a solution. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some observations
Hi Ticker!
> I don't get a crash
Maybe there are other factors? I'm using AMD Ryzen, Windows 10, OpejJDK
18.0.1 (just have updated, 17.02 worked the same). I can create a set
which cause crash, if you are interested. Right, it should be
mkgmap:option:test, but I get a crash in both cases.
> The "test" part of a rule must contain at least 1 "positive" limiting
> clause, as per the style-manual paragraph already mentioned.
So "tag existing" or "positive" means, that "test" have to include at
least one check/condition equivalent to "tag=value" (including "tag=*")?
If I only use single check, then I have to use "tag=value" and nothing
else. It is OK, only not the common situation in programming.
> The full "else" test also require positive limiting and this can only
> come from the "elseCond". Attempting:
>
> if (someTag=*) then
> else
> () {actionIfNotSet}
> end
>
> won't fool the rule processor and you'll get the "Invalid rule, unable
> to index" error.
It doesn't work, but this works:
if (mkgmap:option:test=true) then else
highway=* {...}
end
while these don't work (but should?):
if (mkgmap:option:test!=true) then
highway=* {...}
end
if (!(mkgmap:option:test=true)) then
highway=* {...}
end
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some observations
Hi Gerd, > On the other hand you already found the work around Kind of blind search for solution. I have implemented some kind of processing in style, where I need temporary variables. Now I have a long sequence, where i only use operator "=" for variables, since "!=" doesn't work :) > I don't think that if-then can improve performance. Ok, thanks for insight on working of mkgmap. I think mkgmap is really fast, but I'm always tempted to make some improvements. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some observations
Hi Gerd, thanks for explanations. > the option --make-opposite-cycleways is implemented like this Somehow I imagined, that opposite cycleway is magically added at a final step, when the main road is already prepared by style. Your way is more flexible, but needs more diligence in style. Actually I had to make a lot corrections in my style, when I realized how it works. It would be good to add your explanation to options.txt. > The manual has this note: "There used to be some restrictions on the kind of expression you could use. Now the only restriction is you must have at least one test that depends on a tag existing. So you cannot match on everything, regardless of tags, or test for an object that does not have a tag." Sorry, I missed it. It is at the section, "Combining tag tests", while I was interested in a single test. I read the section "Allowed operations" and found no difference between using tag=value and tag!=value. This make me wonder, why "mkgmap:option:test=true" works but "mkgmap:option:test!=true" doesn't. To be true, I'm not understanding this explanation. What does it mean "tag existing"? Does tag "highway" exist but "mkgmap:synthesised" doesn't? > I wonder why mkgmap complains. Seems it checks only the "if" part. I guess it is about "if then", most problems appear when I try to use this statement. Another question: is the condition of "if then" statement checked once or for each line included in the conditional block? I wonder whether "if then" could optimize processing of style. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some observations
Hi Ralf, I had similar style: overlay line first, roundabout next. I can't repeat the problem, maybe it was my fault. Now I'm using transparent graphics for 0x0c, so it looks correct regardless of order. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Some observations
Hi,
I have tweaked my maps recently and tripped on some problems. Nothing
serious, but a bit troublesome.
First I noticed, that tweak for better looking roundabouts not always
works. In default style there is something like that:
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c
road_class=1 road_speed=1 resolution 24 continue]
junction=roundabout & (highway=tertiary | highway=tertiary_link)
[0x10804 resolution 21]
I have noticed, that sometimes I get roundabout partially covered by
line 0x10804. Maybe mkgmap is splitting roundabout and a part of it is
written into img after line 0x10804? Sorry, I have reworked my style and
can't provide an example now.
Then I got problems with --make-opposite-cycleways. Looks like this
option is not executed at finalize step, but the created line gets full
processing in style. If there exist somewhere a roundabout with opposite
cycle line, then default style will create double lines 0x10804. Safe
version of style would be:
mkgmap:synthesised!=yes & junction=roundabout & (highway=tertiary |
highway=tertiary_link) [0x10804 resolution 21]
Then I have found that following doesn't work:
if (mkgmap:synthesised!=yes) then
junction=roundabout & (highway=tertiary | highway=tertiary_link)
[0x10804 resolution 21]
end
Result:
Mkgmap version 4902
Time started: Sun May 29 21:47:50 CEST 2022
SEVERE (global): Error in style: Error: (lines:15): Invalid rule,
expression cannot be indexed: $mkgmap:synthesised!=yes
SEVERE (global): Could not open style
But this one works:
if (mkgmap:synthesised=yes) then else
junction=roundabout & (highway=tertiary | highway=tertiary_link)
[0x10804 resolution 21]
end
I understand, that there is some kind of optimization for keywords, but
why one type of condition works while others don't? Mkgmap accepts
"keyword=false" but not "keyword=!true" nor "!(keyword=true)". If this
is unavoidable, then would be nice to get a warning in manual.
Finally I made an error in style and crashed mkgmap. I wrote something
like this:
if (mkgmap:style-option:test=true) then
() echo {"test"}
end
and got following:
Mkgmap version 4902
Time started: Sun May 29 21:06:03 CEST 2022
SEVERE (global): Unexpected error
java.lang.NullPointerException: Cannot invoke
"uk.me.parabola.mkgmap.osmstyle.eval.Op.isType(uk.me.parabola.mkgmap.osmstyle.eval.NodeType)"
because the return value of
"uk.me.parabola.mkgmap.osmstyle.eval.Op.getFirst()" is null
at
uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.selectivity(ExpressionArranger.java:381)
at
uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.arrangeAndChain(ExpressionArranger.java:348)
at
uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.arrangeTop(ExpressionArranger.java:95)
at
uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.arrange(ExpressionArranger.java:74)
at
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.loadFile(RuleFileReader.java:132)
at
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:102)
at
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:303)
at uk.me.parabola.mkgmap.osmstyle.StyleImpl.(StyleImpl.java:158)
at
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readStyle(StyleImpl.java:546)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.createConverter(OsmMapDataSource.java:324)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:206)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.parse(OsmMapDataSource.java:166)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:142)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:165)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58)
at
uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:291)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
SEVERE (global): Exiting due to unexpected error
Number of ExitExceptions: 1
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Hardcoded naming scheme for DEM tiles
Hi Nop, simply make links to existing files. For Windows this is command "mklink", for linux it is "ln". -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bridge type code
Hi Karl, there is no common definition for objects types on Garmin map, see https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types Mapsource and some devices treat POI 0x6401 as a bridge, so I think it is a good choice. But I prefer to use a line for a bridge. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] signed maps / new device
Hi, 65001 is exactly Unicode UTF-8, that we are talking about. It doesn't work for me. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] signed maps / new device
Hi Marek, I have tested on 66st firmware 7.20. Unicode maps compiled with mkgmap are rejected, the same message as you have found on issue 26 - "Cannot authenticate maps". -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] signed maps / new device
Hi Felix, I guess the idea is that Garmin holds certificates and only offers signing services for money. Or doesn't offer at all. Well, maps aren't encrypted, so you could hack firmware in your GPS to disable verification. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] signed maps / new device
Hi, I think different models of GPS react differently. Most common is that new devices require digital signature for Unicode maps. Maps with CP1252 usually work. At least handheld GPS, more problems could be with nuvi. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?
Hi Felix, I really don't know java. As far as it looks like "C", I can tweak a simple code, but it's not enough to make any bigger change. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?
Hi, actually gmaptool doesn't split and merge img, when replacing typ. It overwrites old data with a new one. If new typ is longer then the old one, gmaptool has to search for free sectors in img or increase img size. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong Douglas-Peucker implementation?
Hi Gerd, Josm's algorithm removes some spikes, which probably aren't common for real data and layer 0 of img. So differences aren't big. But maybe for lower resolution it could be better, especially for polygons. Wouldn't it be faster? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, then what about proposed: > For line--types-with-direction it would be best to give a resolution > limit for each type, so if resolution is lower than associated lines > can be reversed. Does it means, that you accept wrong direction at lower resolution? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix! > If the main road is merged but the direction dependant road not - then > at lower resolutions the DP filter will create a mess But direction dependent road are merged, aren't they? > And because I have lots of overview - E.g. oneway arrows, oneway > streets are loads, there is quite a difference in map size regarding > oneway roads being merged from resolution 23 onwards or not. As I understand, dropping has-direction attribute will allow to merge roads with reversing (when option allow-reverse-merge is active). This means that you can get arrows in wrong direction. Is this acceptable? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 4179
Hi Felix, why don't make it simple? Routable roads with oneway=-1 have to be reversed. Non-routable lines with oneway=-1 have to be reversed if has-direction is present. If has-direction is present, road is not reversible for merging at all layers. I don't understand your suggestion for non-reversible road limited to some resolutions. I can't imagine what is the use of it, but maybe you have some example. Anyway, I see it like that: - there are rare cases for it if any, - even if the line remains non-reversible at all levels, there is not much difference for a whole map, - if you really need that kind of solution, you can create 2 different objects for different layers. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4715: rework of options for reverse merge
Hi Gerd, I understand, that mkgmap:has-direction=no takes priority over list and that oneway is independent of has-direction. > Next RoadMerger merges roads. It will not reverse roads with oneway > flag true or direction flag true and it will not merge roads which > have different oneway or direction flags. If it does that Looks OK. I think that lines with and without direction flag could be merged, but this probably would be a rather rare case if not error in style. > Each line and road is converted to a MapLine or MapRoad object. Both > have a dir-flag, MapRoad also has a pointer to further data for NOD > which also contains the oneway flag. The dir-flag is set if the > ConvertedWay says it is a oneway or has direction (or both). I guess, that oneway flag in NOD is only set because of oneway description in data. I think has-direction value shouldn't influence routing. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit 4710
Hi all, reading the discussion, I think it would be good to separate 2 cases: - routable roads with one-way attribute, - all lines which have direction. As for routing, I would assume, that all problems are resolved automatically and correctly by mkgmap. Routing is only valid at level 0. On lower resolution one-way attribute can be ignored by default. I don't see any problems here and I hope we could drop this case. Second case is more general an it include roads too. It is about preserving direction of a line to get a correct drawing on a map. This is dependent on a style and TYP. Basically style defines, which objects should preserve direction because graphics defined in TYP is not symmetrical. It seems obvious, that direction should be preserved at all levels. Now, if we get one-way road, we have 2 option. Leave it at default and allow for reverse merging at lower resolution. Or we can add "preserve-direction" attribute, and make it behave like any other line, that has direction. Which means no revers merging at lower resolution. I don't get the idea of a list of types with preserved direction. For me this attribute is defined in style and separate list, or even list as a part of style doesn't make sens. I would prefer to have all attributes directly in style at place, where I define object. It seems tedious to sync list, whenever I do a change to object in style. @Ticker My nuvi 3540 shows direction arrows on roads, when TYP doesn't override graphics. Older nuvis don't and I got no newer one to check. I have looked more carefully and I found that arrows are present on railroads too. This is probably due to mkgmap processing oneway=yes for railroad (actually tramway). I can't see anything on rivers, but river is a thin line and it is difficult to tell if anything is drawn over it. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit 4710
Hi Gerd, here example of lines, that shouldn't be merged: https://www.openstreetmap.org/way/481106241 https://www.openstreetmap.org/way/481106244 https://www.openstreetmap.org/way/481106242 I have tested with mkgmap-low-res-opt-r4711 and it works correctly. Lines are not merged with mkgmap:has-direction=true and merged without. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit 4710
Hi Gerd, it is clear, but I was thinking about something else, about merging lines with reversed points. If mkgmap performs that kind of merging, there should be an option to block reversing for a particular object type. I got impression, that mkgmap:has-direction is a flag, that can be used. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit 4710
Hi Gerd, I don't know particulars about direction flag, that is written into img. Maybe it gives some kind of protection against drawing a line in revers direction? Would be nice to test, if it were possible. Anyway, for me problem is about reversing a line by mkgmap. I think that attribute, which prevents mkgmap from doing it, is necessary to control line merging. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit 4710
Hi all, I didn't know about mkgmap:has-direction. Good to see there is possibility to protect direction of the line. Please note, there are lines, which aren't roads but really have directions. Some example: - waterway=river, stream, maybe canal, ditch too, - natural=cliff, - man_made=embankment, - sidewalk=left, right. Are there any situation, where mkgmap adds this tag by itself? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems
Hi,
some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4685)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -87,6 +87,7 @@
import uk.me.parabola.mkgmap.filters.RemoveEmpty;
import uk.me.parabola.mkgmap.filters.RemoveObsoletePointsFilter;
import uk.me.parabola.mkgmap.filters.RoundCoordsFilter;
+import uk.me.parabola.mkgmap.filters.RoundCoordsFilter2;
import uk.me.parabola.mkgmap.filters.ShapeMergeFilter;
import uk.me.parabola.mkgmap.filters.SizeFilter;
import uk.me.parabola.mkgmap.general.CityInfo;
@@ -1188,10 +1189,10 @@
LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
- filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
if(reducePointError > 0)
filters.addFilter(new
DouglasPeuckerFilter(reducePointError));
+ filters.addFilter(new RoundCoordsFilter2());
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,7 +1244,6 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
- filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
filters.addFilter(new
SizeFilter(sizefilterVal));
@@ -1251,6 +1251,7 @@
//Is there an similar algorithm for polygons?
if(reducePointErrorPolygon > 0)
filters.addFilter(new
DouglasPeuckerFilter(reducePointErrorPolygon));
+ filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
Index: src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java
===
--- src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java (nonexistent)
+++ src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java (working copy)
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2007 Steve Ratcliffe
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+package uk.me.parabola.mkgmap.filters;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import uk.me.parabola.imgfmt.app.Coord;
+import uk.me.parabola.imgfmt.app.CoordNode;
+import uk.me.parabola.mkgmap.general.MapElement;
+import uk.me.parabola.mkgmap.general.MapLine;
+import uk.me.parabola.mkgmap.general.MapRoad;
+
+public class RoundCoordsFilter2 implements MapFilter {
+
+ private int shift;
+ private boolean keepNodes;
+ private int level;
+
+ @Override
+ public void init(FilterConfig config) {
+ shift = config.getShift();
+ level = config.getLevel();
+ keepNodes = level == 0 && config.hasNet();
+ }
+
+ /**
+* @param element A map element that will be a line or a polygon.
+* @param next This is used to pass the possibly transformed element
onward.
+*/
+ @Override
+ public void doFilter(MapElement element, MapFilterChain next) {
+ if (shift == 0) {
+ // do nothing
+ next.doFilter(element);
+ } else {
+ MapLine line = (MapLine) element;
+ int full = 1 << shift;
+ int half = 1 << (shift - 1);// 0.5 shifted
+ int mask = ~((1 << shift) - 1); // to remove fraction
bits
+
+ // round lat/lon values to nearest for shift
+ List newPoints = new
ArrayList<>(line.getPoints().size());
+
+ List coords = line.getPoints();
+ int
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems
Hi Gerd,
I don't observe any significant differences in compilation. But to make
it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I
have attached a second patch here.
There is a difference in results. See pictures with DouglasPeuckerFilter
after RoundCoordsFilter and new version with DouglasPeuckerFilter
before. This is for 22-bit resolution, so effects are probably more clear.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4677)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -1188,10 +1188,10 @@
LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
- filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
if(reducePointError > 0)
filters.addFilter(new
DouglasPeuckerFilter(reducePointError));
+ filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,7 +1243,6 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
- filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
filters.addFilter(new
SizeFilter(sizefilterVal));
@@ -1251,6 +1250,7 @@
//Is there an similar algorithm for polygons?
if(reducePointErrorPolygon > 0)
filters.addFilter(new
DouglasPeuckerFilter(reducePointErrorPolygon));
+ filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems
Hi,
maybe 10m contours are too dense for this area?
Please try attached patch. I have moved D-P simplification before
rounding of coordination. This should preserve shape of the line a bit
better. I'm not sure if this is a safe modification, but it seems to works.
I haven't found, where is done simplification of lines at resolution 24.
Angle fixer probably works on roads only or I don't understand this code
correctly.
--
Best regards,
Andrzej
Index: MapBuilder.java
===
--- MapBuilder.java (revision 4677)
+++ MapBuilder.java (working copy)
@@ -1188,10 +1188,10 @@
LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
+ if(reducePointError > 0)
+ filters.addFilter(new
DouglasPeuckerFilter(reducePointError));
filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
- if(reducePointError > 0)
- filters.addFilter(new
DouglasPeuckerFilter(reducePointError));
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,6 +1243,8 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
+ if(reducePointErrorPolygon > 0)
+ filters.addFilter(new
DouglasPeuckerFilter(reducePointErrorPolygon));
filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
@@ -1249,8 +1251,6 @@
filters.addFilter(new
SizeFilter(sizefilterVal));
//DouglasPeucker behaves at the moment not really
optimal at low zooms, but acceptable.
//Is there an similar algorithm for polygons?
- if(reducePointErrorPolygon > 0)
- filters.addFilter(new
DouglasPeuckerFilter(reducePointErrorPolygon));
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Embedding raster maps
Hi Oliver, that's an interesting subject, you are working on. You probably know this free map, I think this is an example of required minimum: http://static.garmin.com/shared/aus/HTML/_pages/isle-of-man.html -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Which options apply when.
Hi Karl, > But how about creating indices (--net, --index, --split-name-index, > --road-name-config=filename)? --net is about putting address data into *.img tiles, so this is your step 2. Others are about creating index file *_mdr.img, this is done in step 3. > How about using the same tiles, but applying different TYP to each > created gmapsupp.img? TYP is combined with *.img, you do it in step 3. You can add any TYP to any set of *img. Technically TYP is linked to img by FID/ProductCode and family-id/product-id. Probably mkgmap fills FID/PID into TYP file in step 3, but I have no experience with this process. > It would be great if documentation could give some hints to when the > various options are applied or when they can be best applied. You can simply create a config file with all options and use it in all stages. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mapnik TYP, forest and wetland
Hi Karl, > I tried makling a map using the same draworder > Type=0x050,2 > Type=0x051,2 > plus using the option --order-by-decreasing-area This is some kind of trick, not a general solution. There is no guarantee, that GPS will follow the order of objects in img. And I'm sure you can find examples, where bigger polygon should be drawn over a smaller one. Wetland is semi-transparent, you can set higher draw-order for it and forest below still will be visible. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi Karl, > Square is probably "Rynek" in Polish but given the other mappings "Plac" should be as good. I guess "plac" is better word for a typ file, since it is a general term describing a public area inside a city. "Rynek" has more precise meaning in Polish, it is market square or the main square in an old town. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file. Descriptions and translations
Hi Karl, about Polish: type=0x25 String7=0x15,Plac type=0x4b String7=0x15,Tło (Tle = wrong form/declination) For waterfall and canal Polish is OK, but other languages looks like "water" instead. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Split gmapsupp.img
Hi Felix, > Right now for scripting I can only see how to create gmapsupp part > files without address search. Doesn't mkgmap combine *.img with correct index? I mean you can get like 1000 of tiles after compiling a big area, but you can combine first 500 and next 500 separately. I'm doing something similar for my maps. I split and compile area like Africa in one go and then I run separate tasks to create parts of Africa, without recompiling tiles. Mkgmap calculates indexes and preview maps basing on provided list of img. What could be a problem with partial maps is that one country can be split into multiple parts. This can prohibit for correct address search, if your current position is in one part, but searched address in another. But I haven't tested that. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Split gmapsupp.img
Hi Carlos, splitting could be useful, when you'd like to create img in one step. Other option is to install map on PC and then use MapInstall to create img. MapInstall does splitting for big maps. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 192GB recommended
Hi Gerd, I see, not a simple problem. While the idea is nice, the actual implementation looks problematic. Maybe better remove the message or replace it with some general advice? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] 192GB recommended
Hi,
I recently have noticed the following suggestion in mkgmap output:
"To reduce the run time, consider increasing the amnount of memory
available for use by mkgmap by using the Java -Xmx flag to set the
memory to more than 196700 MB, providing this is less than the amount of
physical memory installed."
I run mkgmap to create files for PC installation - overview map, index,
tdb. There is no actual compilation of any map. I guess, that condition
for triggering the message is wrong in my case and maybe the
calculations too. I mean this part of code in Main.java:
if ((taskCount > threadCount + 1) && (maxJobs == 0) && (threadCount <
runtime.availableProcessors())) {
System.out.println("To reduce the run time, consider increasing the
amnount of memory available for use by mkgmap by using the Java -Xmx
flag to set the memory to more than " + 100* (1 + ((runtime.maxMemory()
* runtime.availableProcessors()) / (threadCount * 1024 * 1024 * 100))) +
" MB, providing this is less than the amount of physical memory
installed.");
}
Is "taskCount" correct, when input files are only *.img?
"threadCount" is probably forced to 1, because I see message: "Setting
max-jobs to 1". Then probably there is no need to multiply memory for
all processors.
I'm not sure about "runtime.maxMemory()". It looks like 24GB which I
have allocated with option -Xmx24G. Shouldn't it be a real memory used?
Well, all is not a problem really. I just found the message funny and
investigated a bit. Btw, there is a typo: "amnount".
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Processing of mp source
Hi Gerd, yes, it can be commited, I haven't noticed any problems. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Processing of mp source
Hi Mike, > I think that if a copyright file is provided, this should override any > existing copyright messages from any input files It looks like current processing of copyright-file is to override any previously defined copyright. This is acceptable, only needs a clear explanation in documentation. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Processing of mp source
Hi Gerd, I was looking at wrong places. Actually there is a copyright line from mp header. After patching, option "copyright-file" overrides mp header. Without "copyright-file" reappears value from mp. I'm not sure, maybe there should be both copyrights present? Dropping a copyright doesn't look proper. When copyright from mp header is used, is preceded by a line: "PROGRAM LICENCED UNDER GPL V2". I guess it is about mkgamp, wouldn't be better to put explicit "PROGRAM MKGMAP..." there? Just to make sure, it wasn't Mapwel or MapTk ;) One more question. Does mkgmap correct problems with routing network in mp? I mean problems like distance between routing nodes too short, road intersects with itself or something like adjusting turn headings. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Processing of mp source
Hi Gerd, good to see, that optimizations are active. I set both variants: copyright in mp and in copyright-file, but img contains empty string. I think mp header is not processed at all, at least I haven't found any procedure for it. On the other side, license-file works correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Processing of mp source
Hi, I'm curious, what processing is active, when source data is in mp format. Particularly, which mkgmap options are active? For example, do these options have any use: no-lower-case reduce-point-density reduce-point-density-polygon merge-lines min-size-polygon polygon-size-limits drive-on=detect order-by-decreasing-area preserve-element-order I have noticed, that --copyright-file option doesn't work, is it a bug? Maybe copyright form mp file could be used instead? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Polygon 4A in mp sources
Hi Gerd, your solution for polish reader is OK, thanks. As for other readers, mkgmap should have some handling/protection for the use of 4A and 4B in style. I haven't noticed any (I can be wrong), so maybe is better to ban both these types for now. -- Best regrads, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Polygon 4A in mp sources
Hi Gerd, preview compiled with r4436 works correctly. You probably can relax the check for all readers. Polygon 0x4A needs some extra care, when mkgmap creates its own preview map, but I don't think it is dangerous in a detailed tile. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Polygon 4A in mp sources
Hi, I'm trying to edit and compile preview map in mp format. Unfortunately mkgmap forces a restriction: SEVERE (MapFailedException): img\Topo.mp: (thrown in PolishMapDataSource.checkType()) invalid type 0x4a for POLYGON I'm not sure, why this restriction exist. Is there any problem to accept polygon 4A in mp source? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Background in polish format reader
Hi Gerd, thanks for updating mkgmap. I think the idea behind background is to provide an arbitrary shape for trimming tile area. CGPSmapper doesn't execute trim on mp files, so the meaning of background is lost. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Background in polish format reader
Hi Gerd, yes, when I compile my map, I get only object 4b at layer 0. I use simple definition of background: [POLYGON] Type=0x4b Background=Y Data0=... [END] This works for cGPSmapper, but not for mkgmap. I could add EndLevel=5 to all my sources, but it was easier to recompile mkgmap, to make it a bit more compatible with cGPSmapper. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Background in polish format reader
Hi,
the following quote from cGPSmapper describes peculiarities of command
"Background=Y":
If there is only one object set as the background, then the
EndLevel is automatically set to 9.
If there is no background object, or more than one, then the
EndLevel is not changed.
As I understand, background is a special object for cGPSmapper. If there
is only single background in a source, then compiler can modify EndLevel
value.
Mkgmap doesn't change EndLevel. I prepared a patch, that simply extends
EndLevel for any background object, which contains only "Data0=" layer.
I hope this should work for most cases.
Proper solution would be to count all background objects and
conditionally modify single background after reading an entire source file.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(revision 4465)
+++ src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(working copy)
@@ -104,6 +104,8 @@
private int endLevel;
private char elevUnits;
private int currentLevel;
+ private boolean dataHighLevel;
+ private boolean background;
private int poiDispFlag;
private String defaultCountry;
private String defaultRegion;
@@ -306,6 +308,8 @@
if (!lineStringMap.isEmpty()) {
if (extraAttributes != null &&
shape.hasExtendedType())
shape.setExtTypeAttributes(makeExtTypeAttributes());
+ if (background && !dataHighLevel)
+ endLevel = levels.length -1;
for (Map.Entry>>
entry : lineStringMap.entrySet()) {
setResolution(shape, entry.getKey());
addShapesFromPattern(entry.getValue());
@@ -329,6 +333,8 @@
endLevel = 0;
lineStringMap.clear();
currentLevel = 0;
+ dataHighLevel = false;
+ background = false;
}
private void addShapesFromPattern(List> pointsLists) {
@@ -595,6 +601,9 @@
} else if (name.startsWith("Data")) {
extractResolution(name);
addLineString(value, true);
+ } else if (name.equals("Background")) {
+ if ("Y".equals(value))
+ background = true;
}
else {
if(extraAttributes == null)
@@ -765,6 +774,8 @@
*/
private int extractResolution(String name) {
currentLevel = Integer.parseInt(name.substring(name.charAt(0)
== 'O'? 6: 4));
+ if (currentLevel > 0)
+ dataHighLevel = true;
return extractResolution(currentLevel);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, just after expressing hope for good work of resolution, I got following error in r4420: Error in style: Error: Cannot use type [0x2f17 resolution 24] with level 0 at resolution 23 in style file points, line 270 It is again something, that I have used for a long time. My understanding is that object defined with "resolution 24" simply won't appear on level with resolution 23, regardless if it is level 0 or 1. Maybe you could change this error into a warning? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, thanks! I never cared about levels in style, I have always used options. My guess is, that levels doesn't need much control, only there should be foolproof conversion from levels to resolution. I expect, that objects defined with resolution are processed correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, maybe the problem depends not only on levels. I have uploaded simplified version of a set for creating my map. You can examine, what is going on. http://files.mkgmap.org.uk/detail/460 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, tested again, the error really appeared somewhere after v4323. And I'm compiling the same map since 2014, this is the modification date on my scrips and style. See for example this changelog: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4345 Looks like changes include reading of levels from options - file StyleImpl. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, probably some other changes made this error to appear. I have checked that v4323 compiles my map, while v4386 reports error. I'm not sure about the purpose of the patched function, but I'm afraid there could be problems with following example: options: levels=0:24,1:22 style: [... level 2-3] I don't know which part of code would be responsible for discarding an object with levels higher than maximum. If this is due to patched function, then maybe better would be something like: if (level > max) return levels[0].getBits() -1; -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Level number too large
Hi All,
since something is wrong with downloads on mkgmap site, I have compiled
version 4419. I guess this is the latest official release. Now with some
old maps I get a new error:
Error in style: Error: Level number too large, max=0
I guess this is a conflict between arguments:
levels=0:24
and style with declarations like:
[... level 3]
In my opinion, this should be no error, as it wasn't in older versions
of mkgmap. It is harmless and quite useful, that style defines higher
levels then a particular map compiled with the style.
I have attached a patch, but I'm not sure what I'm really changing.
Please look at it.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java (revision 4419)
+++ src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java (working copy)
@@ -245,7 +245,7 @@
private int toResolution(int level) {
int max = levels.length - 1;
if (level > max)
- throw new SyntaxException("Level number too large,
max=" + max);
+ return levels[0].getBits();
return levels[max - level].getBits();
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Elevation data just partially accessable by Basecamp
Hi Gerd, for GMapTool to set first flag, all tiles should include DEM. I'm afraid, that mapset with mixed tiles - with and without DEM - is not standard for Garmin. It might be impossible to invent a proper way to handle that configuration. Some years ago I did a number of tests and chose the most safe way to set both flags. I remeber, that some arrangement of tiles and flags can cause errors for Mapsource, but I'm not able to directly give examples. Unfortunately I don't remember now, what was the reason for GMapTool algorithm. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Elevation data just partially accessable by Basecamp
Hi, there are 2 consecutive bytes in TDB file. Let's name them "fist" and "second". Current processing of mkgmap is: Option --show-profiles=0|1 sets byte "first" to 0 or 1. Byte "second" is always 0. Processing of cgpsmapper is: Byte "first" is always 0. Option HeightProfile=N|Y sets byte "second" to 0 or 1. Cgpsmapper doesn't support DEM, so the option is evidently designed for contour lines. Processing of GMapTool: Byte "first" is set to 1 if all tiles contain DEM, otherwise is set to 0. Byte "second" is always set to 1. I don't know, which way is valid or better. I suspect, that BaseCamp and Mapsource can somehow deal with all cases. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Elevation data just partially accessable by Basecamp
Hi Gerd, I think the hasDem flag comes from mkgmap sources. I still can trace it in changelogs: http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap=%2Ftrunk%2Fsrc%2Fuk%2Fme%2Fparabola%2Ftdbfmt%2FHeaderBlock.java=4093=4093 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Elevation data just partially accessable by Basecamp
Hi, just have realized, that option --show-profiles could remain at default 0 even when DEM are processed. Kalle, please make sure, that you include --show-profiles=1 in mkgmap options. I think the default for --show-profiles could be dependent on DEM presence. Would make less hassle. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Elevation data just partially accessable by Basecamp
Hi Kalle, I have downloaded your map - KK_MiFra_DEM.gmap.7z. It really doesn't support height profiles. The reason is that an appropriate flag in TDB is missing. I have patched your tdb file, please replace it on your PC and try again. Question for Gerd: how it is possible to create a map with DEM without setting "enableProfile == 1", see tdbformat/HeaderBlock.java . -- Best regards, Andrzej osmmap.7z Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New branch for default typ file
Hi, see example of natural=bay, which can give problems: https://www.openstreetmap.org/relation/9408222 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New branch for default typ file
Hi Gerd, I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that: " c none" where space ' ' is used for marking pixels. Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object. -- Best regard, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New branch for default typ file
Hi Gerd, natural=bay is not a water but a name for an area. It can cover islands too: https://wiki.openstreetmap.org/wiki/Tag:natural=bay IMHO transparent polygon is a good solution. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patch for mp parsing
Hi,
here is a small patch to correct a typo.
--
Best regards,
Andrzej
Index: trunk/src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
===
--- trunk/src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(revision 4288)
+++ trunk/src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(working copy)
@@ -508,11 +508,11 @@
} else
nextPos = 10;
city = strings[nextPos];
- if ("-1".equals(city)){
+ if (!"-1".equals(city)){
region = strings[nextPos + 1];
country = strings[nextPos + 2];
nums.setCityInfo(Numbers.RIGHT,
createCityInfo(city, region, country));
- }
+ }
}
return nums;
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Different simplification of routable and non-routable lines
Hi Gerd, thanks for explanation. Not a big problem, so let it be. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Different simplification of routable and non-routable lines
Hi, I want to create 2 lines on a map from a single highway object. I have noticed recently, that sometimes these 2 lines are misaligned. I guess this is because of different simplification. Is it a new problem (maybe extra points for house numbers)? Or maybe there was never guarantee to get these lines precisely aligned? I think this topic was discussed, but I don't remember conclusions. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR 9 & 10 groups
Hi Gerd, point 0x28 is a label or region name without an icon. Do any Garmin's map include 0x28 in search index? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Ticker, > I don't agree with --recommended because this file will often required > some tweaking and eventually become the basis of the new users > building environment. I don't see problems with tweaking --recommended option. Mkgmap allows for repeated options and process the last one. Minor tweaks for beginners could work like this: mkgmap --recommended --drive-on=left ... I assume, that default config would be distributed with mkgmap, just like default style. This copy could be a basis for more advanced users. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd, maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4271: improve reader for polish (*.mp) format
Hi Gerd, I have extracted objects, that are problematic on my map, see attached file. Both roads trigger error messages, when I compile my whole map: SEVERE (RoadDef): D:\Emapa\Popej\_Topo-360\zrodla\8011.mp: internal error? The nodeCount doesn't match value calculated by RoadNetWork: (http://www.openstreetmap.org/browse/way/326440) SEVERE (RoadDef): D:\Emapa\Popej\_Topo-360\zrodla\8042.mp: internal error? The nodeCount doesn't match value calculated by RoadNetWork: (http://www.openstreetmap.org/browse/way/986610) There are no errors, when compiling this extract. Maybe there is interaction with other roads? Single polygon is not compiled correctly. Compared to GPSMapEdit and map compiled by cGPSmapper, some parts of polygon are missing. I think polygon processing should be exactly like for ESRI shape file. Values of DATA are direct equivalent of rings in SHP. This is what I have found, when preparing conversion form SHP to mp. If I put all rings from SHP to mp objects, then cGPSmapper can deal with them correctly. According to ESRI Shapefile Technical Description, a polygon can contain multiple outer rings and inner rings. Difference between outer and inner is drawing direction. Vertices for outer ring are ordered clockwise, while holes are ordered counterclockwize. When following a border, interior of a polygon is always to the right side. See page 8 of Description: https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf -- Best regards, Andrzej <> ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4271: improve reader for polish (*.mp) format
Hi Gerd, overview is my fault. I have used wrong options. I set 3 layers of DEM, while overview map has only 1 layer of data. That kind of setup is not supported by Garmin. I have corrected it and now overview map is OK. I got 2 errors "The nodeCount doesn't match value calculated by RoadNetWork", which I have to check yet. There is something wrong with displaying map in Mapsource. Some colours are wrong and sometimes Mapsource doesn't redraw map properly. And I have found a missing polygon. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4271: improve reader for polish (*.mp) format
Hi Gerd, I have complied a big map from mp sources (about 3.8GB in 50 files) in one go. Map is usable, routable, with index search and DEM. It is quite impressive, thanks! The problems I have noticed: - Overview map is not accepted by Mapsource and Basecamp. It looks ok, but it includes NET, NOD and DEM. Maybe empty NET/NOD is a problem? - I can't control parameters defining house number after street name or zip code before city name. I guess mkgmap takes them form some config file, which is not used for mp sources. - Value of mapid is taken form file name instead of mp source. - There seems to be 2 sets of city/region/country names in search index. In my sources country is named "POLSKA TOPO~[0x1d]PL" and some results from address search contain this name, while others use simply "PL". I don't use "bounds" option, I can't guess from where comes country "PL". In my mp sources, city/region/country appears in 2 places. Once as statements CitName, RegionName, CountryName, second as a part of Numbers# statement. Maybe there is different processing for them? - ~[0x1d] is a special character, indicating country/region abbreviation. See cgpsmapper manual paragraph 4.2.2.1. Mkgmap doesn't process this code in country name. My guess is that any value inside "~[]" could be simply inserted into label as a hex value. - For search results with country name from my sources, national characters are wrong. Maybe mkgmap assume that mp source is in Unicode? Cgpsmapper doesn't support Unicode, my mp sources are in code page 1250. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, doesn't mkgmap support multiple points restrictions from OSM data? Anyway, removing 4-point restriction prevents mkgmap from crashing, but errors still remains: SEVERE (RoadNetwork): 8001.mp: 1 can't locate arc from 'via' node 1 to 'to' node 171 on way 431744 SEVERE (RoadNetwork): 8001.mp: 4 can't locate arc from 'via' node 4 to 'to' node 59519 on way 1020461 SEVERE (RoadNetwork): 8001.mp: 8 can't locate arc from 'via' node 8 to 'to' node 80234 on way 812265 Looks like this message is issued for all restrictions, regardless if they are before or after roads in source file. I have checked in BaseCamp, restrictions don't work. Except of restrictions, map looks good. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I have tried to compile some more complicated mp. First problem is, that restriction placed on the beginning of the file give multiple warnings, like: SEVERE (RoadNetwork): 8001.mp: 1 can't locate arc from 'via' node 1 to 'to' node 171 on way 431744 SEVERE (RoadNetwork): 8001.mp: 4 can't locate arc from 'via' node 4 to 'to' node 59519 on way 1020461 SEVERE (RoadNetwork): 8001.mp: 8 can't locate arc from 'via' node 8 to 'to' node 80234 on way 812265 Then mkgmap crashes: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:320) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.reader.polish.RestrictionHelper.processAndAddRestrictions(RestrictionHelper.java:54) at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.load(PolishMapDataSource.java:151) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:289) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:285) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option If I move restriction to the end of file, then there is no warning, but crash is the same: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:320) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.reader.polish.RestrictionHelper.processAndAddRestrictions(RestrictionHelper.java:54) at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.load(PolishMapDataSource.java:151) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:289) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:285) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I would rather have mkgmap compatible with real compiler than manual, but in this particular case, both options are reasonable. I'm using the latest version of cGPSmapper 100d. The earliest version I have is 74 from 2004. It behaves the same. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I have compiled this example. cGPSmapper doesn't work like in quoted description. When EndLevel is present, cGPSmapper uses only lowest DATA and ignore any other. See description of EndLevel, this one is true: Endlevel=# - The coordinates in the lowest numbered Data# line apply up to the specified EndLevel=#. When compiling example: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] the result is the same as for: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) [END] You can see the change between level0 and level1, if you remove EndLevel statement: [RGN40] Type=22 Label= Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] This means, that GPSMapEdit doesn't display multiple DATA with EndLevel correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I think GPSMapEdit does it correctly. Each line should be extended up to EndLevel, so it means that first line should be present on levels 0-2 and second on levels 1-2. Multiple DATA in a statement is not a typical case. I think these statements are created usually by GPSMapEdit. I know about to cases. First is, when you truncate map area. This operation can remove a middle part of a polyline and create an object with multiple DATA on the same level. That kind of statement could include EndLevel statement, which should be applied for each DATA. Second case is, when you convert img to mp. In this case, every polyline contains multiple DATA on different levels, but no EndLevel statement. Youd example is a mixed case, but I think EndLevel should be applied for each DATA. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion)
Hi Gerd, I think I have written about these problems some time ago. There is similar problem for polylines, which contains multiple DATA statement. Each DATA is a separate line in mp format, but mkgmap connects them together, which is wrong: SEVERE (PolishMapDataSource): 29483016.mp: Line null has multiple Data lines - concatenating the points See attached picture with source mp and compiled img in GPSMapEdit. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?
Hi, I'm against changing defaults for existing options. I'm in the first group of users, I have scripts with options. A change of defaults would probably require to change options in my scripts. I'm afraid I wouldn't catch changes in mkgmap and in many cases I would get a faulty map without knowing the reason. For example, I never use --process-destination --process-exits in scripts, I don't want these features in my maps and I'm not even sure, if my styles support correctly these options. I rather suggest to prepare an example of config file, which would contain recommended options for default style. It could be dedicated to second group of users. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter, mapid
Hi Gerd, we can use any formula to assign mapid. If this formula would be widely accepted, there wouldn't be much conflicts between maps created by different developers. If we use the original Garmin's formula, then we would avoid conflicts with many existing Garmin's maps too. The only requirement would be to avoid FIDs already used by Garmin. As for my other divagation, it was about how to implement Garmin's formula. For full implementation, we would need some changes to mkgmap too. Without changes to mkgmap, we can implement forumla only for FIDs up to some limit. I have suggested, how this partial implementation could look like. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter, mapid
Hi Gerd, yes, I got the formula after examining numerous Garmin's maps. I know, that City Navigator is different, my guess is that next CN map gets next free mapid. I'm not sure about marine maps and other new maps from Garmin. It looks like the formula is easy to support up to FID 45744. For bigger values you could take different strategy. The rules I know are following: Mapid inside img data is 4-byte value, no problem here. File names are independent of mapid, could be any arbitrary 8-digit number (number from file name could be even written in TRE header, at offset 0xCF). Names of subfiles like 12345678.TRE can be written in HEX, in this case you should use prefix 'I'. So 12345678.TRE is equivalent of I0BC614E.TRE. Mapid 140.531.712 could correspond to I8605800.TRE. My first suggestion is to limit --fid to max 45744. For bigger FID option --mapid should be used. Second proposition is to overlap mapid values for big FIDs, but with an offset of 1024. So for FID > 45744 formula could be like this: mapid = (fid - 19792)*2048 + 6316032 + 1024 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter, mapid
Hi, basically map ID should be unique for all tiles, regardless of FID. If you load 2 tiles with the same map ID to a GPS, it will silently ignore one of these tiles. Most probably GPS assume, that these are the same tiles and there is no reason to process both. Search index contains map ID. If you use 2 maps with repeated map ID, then most probably search won't work correctly. There is no problem with map ID in Basecamp or Mapsource, these programs don't support multiple maps. I suggest to link map ID with FID using following formula: First map ID in a mapset = FID*2048 + 6316032 Or in hex: First map ID in a mapset = FID*800h + 606000h This formula assigns 2048 IDs for each FID. It should be true also for original Garmin's maps, except for City Navigator series. Gerd, maybe you could include these formula into splitter? Something like: ;--fid=27795 : Calculate mapid basing on a FID value. Can be used instead of --mapid. Splitter sets first mapid value as 2048*fid + 6316032 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] label rendering
Hi Brad, there are many factors: - Style for mkgmap, used for compiling. It defines maximum level of an object and the content of a label. Some markers in label can hide a part of a label, depending on zoom level. - TYP file attached to mapset. It defines graphics of an object, size and colour of a label and label visibility. - Settings in GPS. Some GPS allow to modify maximum zoom levels, label sizes and visibility. - Hardcoded properties of GPS. Some GPS don't allow for settings and these properties are simply hardcoded. Many POI have a hardcoded maximum level, railroads 0x14 usually are limited to most detailed level. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd, > are in fact copies of the original way members of the MP and those are > typically not closed I see 3 possible solutions: 1. Convert multipolygon ways to a proper, continuous outline. 2. Return is_closed() as true, when mkgmap:mp_created is true. 3. Add info to documentation, that lines with mkgmap:mp_created=true are part of a closed outline, but not necessary result in is_closed()=true. I would suggest solution 3. I assume that is_closed() means, that object could be a polygon, while mkgmap:mp_created=true or area=yes describe a more complex object, but essentially a kind of polygon too. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Gerd, I think it would be better to have something like apply_first_way. See for example these relations, where first member is a point: https://www.openstreetmap.org/relation/1699620 https://www.openstreetmap.org/relation/254686 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Ticker, > Is this logic general enough to move into the default style? This is a solution for my maps and I have tried to make it universal. There could be other propositions, for example some people could prefer name of the road over ref number or include name into shield (but it doesn't look good on nuvis). For my topo maps, I set road name on level 0 and ref number on next levels. But this is much complicated style. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Andreas, > The problem is that most other relations dont have members with role > „Start“ I see, that I have repeated an answer already given, sorry. The main problem is, that many relation aren't quite clean. For example, segments aren't in order or relation could be not a single line but in a topology like 'Y'. There are roles "forward" and "backward", which complicate further the idea of finding start and stop of a route. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi,
for some time mkgmap allows for code like this:
type=route & route=mtb
{
apply role=start {
set ...
}
apply role=stop {
set ...
}
}
I'm not sure about "role=stop", it is described as a bus stop, but maybe
for cycle route it has a different meaning.
--
Best regard,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Ticker,
I guess variables like mkgmap:us_interstate come from my style. I use
them for shields with road reference numbers. There are dedicated
shields for US maps and standard shields for other countries. These
variables allows to create single style for both cases.
This is an example from my style, file "lines":
# Set highway names to include the reference if there is one
highway=motorway& mkgmap:us_interstate=*{name
'${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:us_usroute=* {name
'${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:us_state=* {name
'${mkgmap:us_state|highway-symbol:round:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2=USA {name
'${name}' | '${ref}'; set mkgmap:refnam=yes} #disable box
highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2!=USA {name
'${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set
mkgmap:refnam=yes}
highway=trunk& mkgmap:refnam!=* & mkgmap:admin_level2!=USA {name
'${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set
mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:us_interstate=*{name
'${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:us_usroute=* {name
'${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:us_state=* {name
'${mkgmap:us_state|highway-symbol:round:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:admin_level2=USA {name '${name}'
| '${ref}'; set mkgmap:refnam=yes} #disable box
highway=primary & mkgmap:refnam!=* & (name=* | ref=*) {name
'${name|not-equal:ref}' | '${ref|highway-symbol:box:12}'; set
mkgmap:refnam=yes}
highway=secondary & mkgmap:refnam!=* & (name=* | ref=*) {name
'${name|not-equal:ref}' | '${ref|highway-symbol:oval:12}'; set
mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* {name '${name}'
| '${ref}'}
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] City search problem
Hi Gerd, I'll try to do some tests with mp, when I find some time. I wasn't aware, that mkgmap accept background with this format. Does mkgmap process statement "background=Y"? I wonder if background object in img has any distinctive attributes. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] City search problem
Hi Gerd, yes, I think that we could use irregular background without trimming other objects. At least for some testing. I'm not sure, what would be the easiest way to implement it. Maybe add background polygon as explicit data in input source and include processing for it in the style? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] City search problem
Hi Gerd, I'm not sure if there should be any cutting of objects. My guess is, that only background polygon is essential. Maybe would be enough to simply discard objects, which are fully outside of background? All this needs some testing. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Beaches as a polygon
Hi Joris, >From which perspective are you talking? Well, from my perspective. I would consider your typ for maps, that I publish, but I wont, unless you provide a clear license. > For me personal drawing simple single collored 16 x16 bitmap pixel > icons is free for the community. I understand, but creativity of a content doesn't depend on picture size. Typ file defines a "look and feel" of a map and usually this is the main part of a copyright for a map. So for me a license to use a typ file looks like a necessity. Currently I base my typ file on following resources: https://code.google.com/archive/p/mkgmap-style-sheets/ http://www.sjjb.co.uk/mapicons/ Please note, that both sites states, how I'm allowed to use their work. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] City search problem
Hi Gerd, Probably the solution is to use background polygon trimmed by country/region area. I think GPS look for background at current position to determine which map to use for a search. Some GPS allow to select map, but mostly it goes automatically, GPS selects a map and then doesn't look for another, even if there is no hits. So near the border, where tiles overlap, GPS can select a tile from a wrong map. I hope that trimmed background could make a clean division at the border, even if tiles coordinates overlap. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Beaches as a polygon
Hi Joris, > I volunteer in maintaining a default typ for mkgmap This is very interesting, thanks! I think you should clearly state the license for your work. Especially because it include graphics art, which is quite heavy topic, when dealing with copyrights. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] probably dumb question about style type
Hi Steve, > Are the ones above 0x1f different though? Or is it just ignoring the > top bits? When a typ file is attached, then icons are repeated, icon for subtyp 0x00 is the same as for subtyp 0x20. I can't create icon for subtyp greater than 0x1F in TYPViewr, is there a limit in typ structure? In BaseCamp there are some default icons, for example for POI 0x5904, 0x640E, 0x6616. These icons aren't repeated with higher subtyp values. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
