[mkgmap-dev] problem with splitter and bounding polygon
Hi, I'm trying to compile a map of USA using North America extract form Geofabrik. I use splitter r427 with bounding polygon, something like that: splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf The result is that I get errors in mkgmap: SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. This error appears for some tiles at the map border. My guess is, that splitter uses only nodes inside bounding poly to compute tiles sizes. When a rectangular tile is placed on a polygon border, estimated node number could be significantly smaller than the full number actually saved in this tile. This could lead to problems as above. I don't have any suggestions for a solution, so I'm going to try to go around it using a simplified poly. I hope, that maybe someone could get an idea how to correct it. -- 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] Suggestions for DESTINATION hint and EXIT hint
Hi Greg, > It might be nice if we could ABBREVIATE road names > in the Default style Your example works only for English and isn't suitable for universal style, because it can damage valid names in other languages. You can add conditions like mkgmap:country=USA but then it could all became unreadable. -- 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] [Patch v1] reduce line distortion
Hi Gerd, > 3) When the housenumber functions add new nodes to the road to > improve the address search, these nodes may be > 1m away from > the overlay line. Maybe do not add nodes? Or limit these nodes to cases with random numbering? I guess GPS finds position of an address as an interpolation between numbers assigned to 2 consecutive nodes. In many cases you can drop intermediate points, without worsen the functionality. > So, I'll try again to fix the overlay lines using a brute search > algo, maybe the performance doesn't matter as there are not so > many added nodes . Wouldn't be easer to move creation of overlays to this stage of algorithm? Or mark some object for creating overlays earlier and do it now? Just a thought, I don't know these algorithms. -- 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] Create different Maps with working routing betweenthem - is it possible?
Hi Walter, > since Garmin does not support Unicode, > I have to use at least different codepages for Europe. I use CP1252 for Europe and English/international names whenever possible. I think it is the best compromise, especially because some devices do not support required code pages, like for example there is no support for CP1250 on Edge. Multiple code pages would require multiple maps with separate indexes. To get correct routing between multiple separate maps, each map should have external routing nodes on boundaries. These nodes should be at the same position on adjacent maps. I guess mkgmap has no support for that kind of nodes on irregular country extracts. Proposed suggestion could be to force external routnig nodes on every road at crossing of administrative boundary. -- 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] [Patch v1] reduce line distortion
Hi Gerd, I guess you already got very complicated code ;) I'm not perfectionist, I would accept some errors in processing. For example address placing precision could be in range 20-50m. If there is a node in this range, I would try use it for multiple addresses. I'm afraid that inserting a new node within distance 20m from existing node could distort lines on 24-bit layer and should be avoided. -- 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] Create different Maps with working routing betweenthem - is it possible?
Hi Walter, > At the moment I am looking for a solution for 2 very big parts, > which are in total bigger than 4 GB. There is no problem with big maps, just do it. All tools support them - splitter, mkgamp, BaseCamp + Mapinstall and current GPS. I create map of Europe, which is about 11GB, it works fine. I use 64-bit java to compile 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] Lines from the Unit-BaseMap in the gmapsupp
Hi Arndt, > BC shows not only the gmapsupp, the BaseMap from the Oregon > is shown too. BaseCamp shows only single map plus gobal map from PC. But detailed map should hide global map. If you see them both, then maybe your map has transparency flag set? -- 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] [patch v1] don't route the highway=construction ways
Hi, I guess Garmin img format allows for many non-standard solutions, but I would be afraid to implement them into standard compilation. It could lead to unexpected problems, difficult to trace. My last experience with using routable lines as no-routable objects for addressing is following: - routing in Mapsource works correctly, - routing in latest BaseCamp works for motocycle, hiking, bicycle etc., - routing in latest BaseCamp doesn't work for car. This was cGPSmapper compilation, I haven't tested mkgmap outcome. -- 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] [patch v1] don't route the highway=construction ways
Hi Gerd, > I am not sure what you did and what "routing doesn't work" means > in this case. My map was similar to the experiments, that you have analyzed here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/023244.html Only I have added relatively small number of non-routable lines with address. This worked correctly until recent releases of BaseCamp, where I get direct routes (straight lines) instead of routes following roads. Problem appears only for "driving" activity (car). When I change activity to "motorcycling" or "trucking", recalculation gives proper routing on roads. I'm not sure if current topic cold lead to similar problems, but I'm cautious about mixing routable/no-routable roads in a single map. -- 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] [patch v1] don't route the highway=construction ways
Hi Gerd, > The patch implements a way to have a line > with a routable type that appears in NET but not in NOD. > In other words, the NET file doesn't contain a pointer into NOD. I only express concern, that it could break routing, because it looks like a quite non-standard approach. -- 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] obsolete spaces in tags
Hi Gerd, I would go for a) - only correcting source text form OSM. I think correct style shouldn't create wrong lables. And author of style could use double spaces intentionally, in which case there would be needed an option to disable second correction and proper explanation in manual. IMHO better keep it simple. -- 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] address search in Canada
Hi Gerd, I think you can perform standard cleaning for each name or label, removing leading, trailing and duplicate spaces. Maybe there are even more similar corrections, which could be applied. -- 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] highway=razed
Hi Gerd,
> I think 1st I wanted to point out that the "mop up" rule
> should be removed, it is likely to produce wrong routing.
I doubt it could make a really bad routing, it is nearly the lowest
category of road anyway. As a result IMHO it goes to personal
preferences, whether to use it. Do not remove it - if you don't like it,
then leave it as comment.
There are more similar problems in default style. For example, should we
create a point for a "place=", which has no name?
Maybe simple to use something like {echotags "FIXME"} to give warnings,
whenever we are not sure of a proper solution? This will delegate
problem to an actual user.
--
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] highway=razed
Hi Gerd,
> Most of these ways are areas, but don't have the area=yes tag.
> I am not sure why the "mop up" rule would ignore them when the
> area=yes tag exists.
I'm not sure if I understand your problem, so following are my
observations only.
Area described as a highway could be a multipolygon, without are=yes
tag. Myltipolygon is area by default. I add following line to my style:
highway=* & mkgmap:mp_created=true { add area=yes; }
Highway area drown as a line clutters map and IMHO should be avoided.
Usually there exist corresponding highway line 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] Problem with too large shields on streets with ref and name
Hi Bernd, I agree, shield with a name doesn't work well on nuvis. I prefer to use only street name without reference number. Reference could be added as secondary label for address search or as a first label on upper layers of a map. I'm not sure if problem with nuvi is important enough to change default 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] Exclude POIs from index
Hi Dave, when you search for all POIs, then GPS look for all POI that are near your current position. It doesn't use index for that kind of search, so you can't exclude POIs selectively. You would have to remove them form map. You can try to search for a category of POIs or search by name to get only a selection of POIs. -- 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] addr:street and street name matching for house number searchs
Hi Carlos, the best solution would be to correct errors in OSM data. Polish mappers got a site, which shows all addresses, that needs to be corrected. Maybe you can ask Spanish community to do something similar? See: http://v3.mrowka.org/adresy/#7/52.298/19.199 -- 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] maxspeed evaluation
Hi Gerd,
The tag mkgmap:road-speed-max=* is only evaluated
by mkgmap when the tag mkgmap:road-speed=*.
If mkgmap:road-speed is not set, the value in
mkgmap:road-speed-max is completely ignored.
My early proposition for limiting speed looked like this:
... { set mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 2 }
This was solution, that I found working in my tests.
Is mkgmap:road-speed-max evaluated after adding mkgmap:road-speed? If
yes, then your proposition looks better.
--
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] maxspeed evaluation
Hi Bernd, Maybe if i try to '+0' My guess is that simple +0 is a number while '+0' is a string, and probably mkgmap:road-speed expect a string. So I suggest to try: mkgmap:road-speed='+0' -- 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] maxspeed evaluation
Hi Gerd,
I think the advantage of my version is that it doesn't override
an existing mkgmap:road-speed=* tag.
Yes, I have noticed. Maybe that kind of action would be simpler:
... { add mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 2 }
I think that making mkgmap:road-speed-max independent of
mkgmap:road-speed could be even better solution. At least this is what
we need for processing maxspeed tag, this -0 value is quite artificial.
--
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] What is the idea behind --adjust-turn-headings?
Hi Felix, Another possibility would be to decrease the road speed at the turn/intersection by 1 or 2 levels - then have the turn/intersection. At road-speed 0 or 1 it is already much better - and the overall time for the way will decrease! (if you have 10meters in and out of the turn with lower road-speed). I'm afraid this could greatly increase time for calculating a route. I have done tests with some commercial data and cGPSmapper. I'm not sure if results are directly compatible with mkgmap, but in my opinion, for routing speed most important is the number of roads (class 4 roads in case of long distance routes). Single road with multiple nodes (junctions) is better than the same nodes arranged as multiple roads. -- 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] Numbering loss in the version which came after the r3602
Hi Alexandre, You can search for street Rua Porto Alegre to see the problem what data are you using for compilation? I have tried to find this place on OSM, I think this is actually Rua Manaus in OSM, with no house numbers: http://www.openstreetmap.org/way/93121424 -- 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] Numbering loss in the version which came after the r3602
Hi Alexandre, I confirm, that there is no address on your map with current mkgmap. Data seems to be OK, so lets wait for Gerd opinion. -- 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] Memory Full - with newest mkgmap versions appearing again
Hi Felix isn't it device problem? It happens to me form time to time, I have always assumed, that device remembers all map-id (tile id) ever used and sometimes gets no memory for a new one. Device reset cures this problem. Maybe you have changed range of map id for some maps and this caused more problems for users who loads updates? -- 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] some questions
Hi Gert, map on PC and gmpasupp.img, both include subfile *_mdr.img, which contains search index. They are similar but not the same. MapInstall and Mapsource convert file form PC to format needed in gmapsupp. Mkgmap can create both versions. -- 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] Duplicate cities
Hi Gerd, Hmm, splitter keeps most mp-relations complete, we only exclude some boundary relations. I see. But maybe potential increase wouldn't be that big, if you add boundaries? Or maybe you can preserve only some levels of boundaries? Or you can use boundary data form --bounds option? Anyway, I prefer version 1 - keep complete relation, that could be useful for mkgmap. -- 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] Duplicate cities
Hi Gerd, When you use --add-pois-to-areas mkgmap will generate a POI based on the existing data, and this POI will have the tag place=city (for the example), so for each tile we calculate different coordinates for the city POI. Not only cites but all polygons can get duplicate POIs. Probably cities are worst, because they are easily accessible with search function. You can solve this particular problem by telling splitter to keep all administrative boundaries complete, but that will produce a lot more data in each tile: --boundary-tags=administrative Looks like the easiest solution, so maybe we can allow for bigger tiles. I think you can save complete multipolygons 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] levels in style aren't processed correctly
Hi Steve, I don't understand this. If you have no --levels option then the default should be used, which has a maximum of 4. Looks like there is no defaults now, or maybe only level 0 gets a default resolution. What do you think that the message text should be? Maybe something like 'level 1' is used in style while its resolution is not defined in option 'levels=' nor overview-levels=. What are the conditions to cause this error? My previous analysis was wrong. This is what I'm doing: - I have modified default style changing some resolution xx to level 0, level 1 or level 2. - I have commented levels= and overview-levels= in options file. Now I run compilation with following command line options: 1) --levels=0:22,1:21,2:20 --gmapsupp --no-tdbfile 2) --levels=0:22,1:21 --gmapsupp --no-tdbfile 3) --levels=0:22,1:21 --overview-levels=4:16 --gmapsupp --no-tdbfile Compilation 1) goes correctly. Compilation 2) ends with an error. Compilation 3) creates a map. Map for case 2) consist of only layer 0 and 1, so all references to level 2 in style could be ignored. I would expect successful compilation at case 2). Next observation is that case 3) shouldn't be different from case 2), there is no definition for level 2 either. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] levels in style aren't processed correctly
Hi, I have defined a rule in style like this: highway=path [0x16 road_class=0 road_speed=0 level 0] When I compile map with --levels=0:24, then I get paths correctly. When I use option --levels=0:23, then paths are missing. I would expect paths on level 0 regardless of resolution. -- 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] levels in style aren't processed correctly
Hi, I think problem is with initial conversion levels - resolution. I thought, that levels in style are depreciated, but Steve's suggestion works, I get correct results when using proper levels inside options file. If I delete levels form style, then command line values still aren't used. Are they any default values in code? -- 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] problem with highways as multipolygons
Hi Gerd, I'm satisfied with current solution. I think the problem arise from micro-mapping, where many linear features get area shape. Since we usually have both approaches, line and area, we needn't to converted area to lines. Some idea how to check area: find any nodes, where routable ways connect to area. If there exist ways connecting these nodes inside area, then area is not needed for routing. -- 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] problem with highways as multipolygons
Hi Gerd,
The apply tells mkgmap to add the tag area=yes to the members,
and I think that's what you want.
This was my first thought too, but:
Note that the members of the
mp-relation are not the members of the original OSM relation, they
are the artifical ways.
Apply adds tags to original members while I have problems with
artificial ways. Artificial ways inherit tags form original relation, so
I would expect, that tags added to relation would appear in artificial
ways. As you explained, this is no true.
Apply would work if there were created corresponding artificial
relation too.
I think it's ok, that multipolygon appears as polyline and polygon. That
way we can create object for boundary and for area. Problem appears,
when multipolygon has no area tag, which is quite possible, since
multipolygon implies area. I have added a rule to correct this problem:
highway=* mkgmap:mp_created=true {add area=yes;}
See attached patch, which corrects footway, path and steps with area too.
Often highway=service is marked as area, but I think it could be usable
to draw a road around area.
--
Best regards,
Andrzej
--- resources/styles/default/lines 2015-05-09 17:17:14.697647600 +0200
+++ resources/styles/default/lines 2015-05-09 16:42:46.238400600 +0200
@@ -17,6 +17,9 @@ highway=* name=* { set mkgmap:street='
# Mark highways with the toll flag
highway=* (toll=yes|toll=true) { set mkgmap:toll=yes }
+# mark multipolygons as area
+highway=* mkgmap:mp_created=true {add area=yes;}
+
# Hide proposed ways
highway=proposed {delete highway;delete junction}
# Hide unaccessible tunnels
@@ -150,7 +153,7 @@ highway=service [0x07 road_class=0 road_
highway=cycleway [0x07 road_class=0 road_speed=1 resolution 23]
-highway=footway|highway=path|highway=steps [0x16 road_class=0 road_speed=0
resolution 23]
+(highway=footway|highway=path|highway=steps) area!=yes [0x16 road_class=0
road_speed=0 resolution 23]
highway=track [0x0a road_class=0 road_speed=1 resolution 22]
highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 22]
highway=road { add mkgmap:dead-end-check = false} [0x06 road_class=0
road_speed=1 resolution 22]
diff -urpN f:\Garmin\_rozne\mkgmap\resources/styles/default/polygons
resources/styles/default/polygons
--- resources/styles/default/polygons 2015-02-12 14:51:32.04842 +0100
+++ resources/styles/default/polygons 2015-05-09 16:43:54.987721400 +0200
@@ -52,8 +52,11 @@ place=islet name=* [0x53 resolution 20
shop=* [0x08 resolution 22]
+# mark multipolygons as area
+highway=* mkgmap:mp_created=true {add area=yes;}
+
# squares and plazas
-highway=pedestrian area=yes [0x17 resolution 22]
+(highway=pedestrian|highway=footway|highway=path|highway=steps) area=yes
[0x17 resolution 22]
# other highways that have area=yes set must be parking lots
highway=* area=yes [0x05 resolution 22]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with highways as multipolygons
Hi Gerd,
I agree that it looks strange,
but it works when you use apply like this:
type=multipolygon highway=* { apply { set area=yes; } }
As I understand apply deals with relation's members, which aren't
highways at all. I have already tried apply but this is simply wrong
approach.
You may also ask for mkgmap:mp_created=true in the rules.
Does it mean that polyline is created form multipolygon and nothing
else? I get about 600 objects in Poland which I would delete using this
rule. All looks like good candidates for removal. And probably I should
use complimentary rule in polygons file, to get proper support for
these objects. Looks good for temporary solution.
I can't reproduce that the lines rules are applied,
with my test file that contains the complete relation
only the polygon rules are used. I assume your input
file contains only a part of the relation?
See attached file with single relation. I get highway=footway as
polyline. Here result of echotags:
relation with added area=yes in style:
4764899 - [highway=footway,area=yes,type=multipolygon]
highway in lines
4611686018427387910 (4764899) -
[highway=footway,mkgmap:mp_created=true,mkgmap:stylefilter=polyline]
Maybe you could create a new relation in
MultiPolygonRelation.processElements()? Relation could include all tags
form original relation and new polylines as members. This would allow
for some processing in style.
Note: default style deals with highway=pedestrian area=yes, but
ignore area tag for most other types of highway. I think at least
footway and stairs should be checked for area.
--
Best regards,
Andrzej
multi-hw.7z
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with highways as multipolygons
Hi All,
I have stuck at following problem:
There is relation 4764899:
type=multipolygon
highway=footway
Line 336969927 as inner
Line 336969921 as outer
This is an area, probably it should include tag area=yes, but actually
it doesn't. Mkgmap creates a new polyline from multipolygon and polyline
is processed according to rules in lines part of style.
I haven't found any method to safely remove this line from my map. I
have tried to added following rule to relations file:
type=multipolygon highway=*
{
set area=yes;
}
but this doesn't work, new tags aren't added to created polyline. This
looks for me like a bug.
Any ideas, how to deal with multipolygon?
--
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] address search and case significance of street name
Hi Gerd, If any element processed later has a name like ABC street or abc Street which we consider as a street name, we will use Abc Street again. I'm not sure what for are used names from this table. I don't think that case could be important for comparison of street names. But I would prefer to see street name on a map with the original spelling. Otherwise mkgmap could propagate spelling errors, which would be difficult to trace. -- 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] inc/address and --housenumbers
Hi Gerd, 2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. A road at the border of 2 cities can have 2 different addresses, including road name, zip code, city and region. Maybe country too? I don't think that duplicating road object is a right solution. Road name can be added as a second label, I hope that other data can have multiple values too. Cgpsmapper allows for 2 addresses for a road, it probably doesn't duplicate road line, but I haven't checked. -- 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] inc/address and --housenumbers
Hi Gerd, I see that discussion has gone further, do you still need example of a map from cgpsmapper? -- 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] addr:place support
Hi Gerd, It doesn't require much code to generate the pseudo roads, so maybe it is something for a special option. Would be nice, if you preserve this code. Maybe even for all addresses, not only for addr:place? But actually I can extract addresses form OSM sources, parse them, convert to roads and get the same result. Either way, I'm glad, that we have found what works and what has to be avoided. Although the wiki says that either addr:place or addr:street should be used I see many nodes with both. IMHO use addr:street and ignore addr:place. Most probably addr:place is incorrectly set instead of addr:city, which you get from other data anyway. I see no good reason to ignore information when it is easy to use. Yes, I know the feeling, never refuse free 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] addr:place support
Hi Gerd, If you have to buildings on the same side of the road so that distance between the houses is smaller than the distance to the road, MapSource will select the pseudo road. I confirm, this doesn't work in Mapsource. Probably there is some influence of NET on routing. Isn't it NET, where information about crossroads is held? I have prepared a mapset, where address points are placed in separate, transparent img. Now routing works, not only in the case you have described but for points in greater distance from roads too. Please try attached map, you can simply overwrite previous files. Try a route like: Point One 2 - Point Four 4 - Point Two 3. -- Best regards, Andrzej adr_punkt1.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] addr:place support
Hi Gerd, I think this is plausible, the routing algo searches for the closest road and tries to build a route to the other house, but that fails because it finds the pseudo roads which are not routable (2 and 3) or not connected to the road network (4). This is not how Mapsource usually behave. Please try to use route tool from toolbar and click with it on 2 random points on the map. You should get a route on roads, even if you click outside road. I'm not sure about case 4 but 2 and 3 should work. In my opinion problem is somewhere else. Please create a route in case 2-4 and then try to recalculate it changing map to case 1 (standard compilation). -- 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] addr:place support
Hi Thorsten, I don't know about Mapsource, but this is how the Garmin GPSMap 62s behaves. It is looking for the nearest road, whatever this is, and tries to route from that. If this nearest road is not connected, you will get a routing error. I know about this. There is some distance range form current position, where should be a routable road to begin a routing. Maybe the same distance limit is in effect for point addressing, but it doesn't explain total failure of Gerd's new function in Mapsource. I can only repeat, Mapsource doesn't behave that way, see the picture, that I have attached some mails ago. This is exactly the same case, a road created between 2 address points on short non-routable artificial roads. The only difference is that map is created with cgpsmapper. Maybe new code still creates routable ways for address points? It could lead to straight routes, if road network is discontinuous. -- 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] addr:place support
Hi Gerd, that's why I asked for samples this morning Sorry, I missed your request. Maybe because I don't manipulate maps ;) This is a straight compilation by cgpsmapper, where I add short non-routable road for each city in mp source. I have quoted example in previous mail. I can try to create a simple map with similar case. -- 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] addr:place support
Hi Gerd, problem is interesting, I gladly investigate. I can confirm, that there is maximum distance off road, where Mapsource still finds routing on road. Could be like 100-150m. I have created a single example of map with point addressing. It consist of 2 routable roads and 4 non-routable roads for addresses. Address search works. You can get a proper route between points 1-3, but point 4 is too far and Mapsource uses straight line to it. You can decompile map with GPSMapEdit and check, which roads are routable, Attached archive contains mapset for Mapsource. -- Best regards, Andrzej adr_punkt.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] addr:place support
Hi Gerd, routing doesn't work when I use the addresses as waypoints for the route :-( I'm not sure what are you doing. I think Garmin can calculate a route through any points, regardless if they are on road or not. When using address point outside road, it calculate route to the nearest point on road and then straight line towards address. Maybe this doesn't work, if point is too far from any road? I haven't tested it on single map, I have used non-routable transparent overlay with addresses and a routable map. In this configuration, nuvi calculate route as in attached picture. -- 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] addr:place support
Hi Gerd, see attached picture from cgpsmapper map. I get this route in Mapsource this way: I start new route from Edit menu. I add 2 points using search address function. I click at recalculate button in route window. The only difference that I notice is that my addresses uses a non-zero length line, I create road which is about 10m. -- 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] addr:place support
Hi Gerd, I have to find out how to add MapRoads to NET without adding them to NOD without messing up the pointers. Maybe you could check if road have defined road_class? My guess is that road_class is needed in NOD but not in NET. -- 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] addr:place support
Hi Gerd, If fear when I add invisible and roads and don't add them to the routing network routing to such an address will not work. It works for me. I create routable map with cgpsmapper, where I add objects like this for each city: [POLYLINE] Type=0x13 Label=DOBRZEWINO CityName=DOBRZEWINO RegionName=POMORSKIE CountryName=POLSKA TOPO~[0X1D]PL Data0=(54.45135,18.37234),(54.45144,18.37242) [END] This is not a routable road but can be found in address search. I also create address map for Poland. Map is compiled with mkgmap but I strip NOD subfile from it. This way it becomes non-routable but contains address search: http://www.gmaptool.eu/en/content/poland-addresses-osm -- 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 - missing area, trim not working
Hi Gerd, I'm trying to minimize map size and I feel, that trim can help a bit. Probably I'm wrong, these are empty parts anyway. Thanks for advices. -- 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 - missing area, trim not working
Hi Carlos and Gerd, I tried once bounding poly in phyghtmap and it didn't worked for me. I don't remember what was wrong. No problems with osmosis. Now I need some solution for trim. I get usable split with polygon-file in splitter, but I'd like to remove empty areas. Is trim in splitter disabled by bounding poly? -- 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] address search and road names with refs
Hi Gerd, I don't want to see the ref when I am searching for an address. If possible, I want to see it and be able to search for it when searching for a road. When creating search index, shield could be separated from street name and both elements added to search index independently. It should also appear when the map is rendered. This could be difficult. For a label consisting of a shield and a name, Mapsource shows road shield on map and street name under the cursor. But this doesn't work in nuvis, see the picture that I have attached to earlier post. -- 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] address search and road names with refs
Hi Gerd, there are two problems. First is if we should add road reference to road name. Second problem is conditional - if we add a reference, then should it be searchable? On my map I don't add reference to name. I put reference in second label if name exist and in first label if it doesn't. Merging both won't look good on some nuvis, where shield graphics is extended to a full name, see attached picture. This solution has a downside - only first label is visible on a map and road references aren't visible in cities, where street have names. For second problem I would prefer that road number was searchable, because this way you could find address as: B101, 117, Freiberg. Please note, that putting reference number to a second label also allows for finding this address, without multiplying results when searching for proper street name. I think choice of solution is quite arbitrary. Maybe we should gather some opinions, before deciding about default 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] roadspeed in default style
Hi Gerd, I tried to combine the previous versions to one that looks plausible to me, see attachment. Looks good to me. -- 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] roadspeed in default style
Hi, I agree that we can remove the extra lines to delete maxspeed. Roadspeed is included at finalize stage. Most processing of highways and railways is done before it. Deleting of maxspeed at this stage shouldn't have any negative impact for default style. The cautious solution would be to restore original value of maxspeed at the end of include, but I don't feel it is necessary. -- 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] Question on Auto-Zoom
Hi Michael, I don't know about outdoor devices, I disable autozoom on them. In nuvi the idea is quite simple, it uses 3-4 ranges of speed and remembers zoom that you have set at that speed. So you can tune autozoom behavior. -- 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] roadspeed in default style
Hi Gerd,
I think these two rules
maxspeed~'.*:urban' { set maxspeed=50 }
maxspeed~'.*:rural' { set maxspeed=90 }
make it impossible that these 4 rules will ever fire:
maxspeed=AT:rural { set maxspeed=100 }
maxspeed=DE:rural { set maxspeed=100 }
maxspeed=RU:urban { set maxspeed=60 }
maxspeed=UA:urban { set maxspeed=60 }
Right, thanks Gerd. Should be reversed, specific countries first and
catch all last:
maxspeed=AT:rural { set maxspeed=100 }
maxspeed=DE:rural { set maxspeed=100 }
maxspeed~'.*:rural' { set maxspeed=90 }
maxspeed=RU:urban { set maxspeed=60 }
maxspeed=UA:urban { set maxspeed=60 }
maxspeed~'.*:urban' { set maxspeed=50 }
--
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] roadspeed in default style
Hi Bernd, maybe this rule works as you expected, but it is a catch all, i don't like them ;-) Right, catch all doesn't look safe. Probably would be better to change maxspeedkmh()!=* to maxspeedkmh()120. I think setting mkgmap:road-speed-class is only needed for the highest value, higher then 120 kmh I would take care to set road_speed=7 only for highway=motorway and this would be better done in lines file. On my maps I wouldn't set road_speed=7 anyway, I prefer more realistic values. -- 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] roadspeed in default style
Hi Bernd,
first question, what should this rule do?
maxspeed=* maxspeedkmh()!=* { delete maxspeed }
This rule deletes tag maxspeed if we can't assign a numeric value to it.
the last rules should be
maxspeed up to 120 kmh
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 120
{ set mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 6 }
maxspeed higher then 120 kmh
maxspeed=* mkgmap:road-speed-class!=* maxspeedkmh() 120
{ set mkgmap:road-speed-class = 7 }
mkgmap:road-speed-class isn't set anywhere in default style, except in
current roadspeed include file. Condition mkgmap:road-speed-class!=*
would be false, maybe you wanted to put mkgmap:road-speed-max there?.
Setting value for mkgmap:road-speed-class is what I want to avoid in my
include. Setting mkgmap:road-speed-max=7 doesn't limit anything either,
could be omitted. The reason for setting mkgmap:road-speed='-0' is to
clear any existing value, but maybe this is superfluous.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] roadspeed in default style
Hi,
one of threads reminded me about roadspeed include in default style.
As far as I understand, Garmin maps made by mkgmap contain average road
speed, which can be used for calculation of arrival time.
Include roadspeed deals with speed limits and convert them into value,
which is then treated as average speed. In my opinion this is wrong
assumption. Better average speed could be estimated from road type.
Speed limit should be used only to limit average speed, for example on
good roads in urban area. I'm using this approach in my maps. I have
attached my alternative for roadspeed.
--
Best regards,
Andrzej
#
# Sets the maximum road speed based on the maxspeed tag.
# In case mkgmap:road-speed-max is set the element road_speed is limited.
#
# road_speed classification:
# road_speed | highest speed
# 7 | No speed limit
# 6 | 70 mph / 110 km/h
# 5 | 60 mph / 90 km/h
# 4 | 50 mph / 80 km/h
# 3 | 35 mph / 60 km/h
# 2 | 25 mph / 40 km/h
# 1 | 15 mph / 20 km/h
# 0 | 3 mph / 5 km/h
#
maxspeed=none { set maxspeed=140 }
maxspeed=signals { delete maxspeed }
maxspeed=walk { set maxspeed=10 }
maxspeed~'.*:urban'{ set maxspeed=50 }
maxspeed~'.*:rural'{ set maxspeed=90 }
maxspeed~'.*:trunk'{ set maxspeed=100 }
maxspeed~'.*:motorway' { set maxspeed=130 }
maxspeed=AT:rural { set maxspeed=100 }
maxspeed=DE:rural { set maxspeed=100 }
maxspeed=RU:urban { set maxspeed=60 }
maxspeed=UA:urban { set maxspeed=60 }
maxspeed=* maxspeedkmh()!=* { delete maxspeed }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 10 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 0 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 20 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 1 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 40 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 2 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 60 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 3 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 80 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 4 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 100 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 5 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 120 { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 6 }
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() != * { set
mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 7 }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Hi Bernd, No didn't work. only the description of the last layer is visible on the device, see the attached screenshot 106.jpg Are you creating multiple maps from single template.img? Template.args include mapname, which overwrites definition, that you give as mkgmap option. This results in duplicated mapnames in your files. GPS rejects duplicates and probably this is the reason, why you don't see maps. You can try to remove mapnames from template.args: grep -v mapname template.args template2.args And then compile map with options like this: ... mkgmap.jar ... --mapname=65001001 -c template2.args --description=bonn_20150306_1700_basemap --gmapsupp The only advantage of using template.args is that you get name for each tile, which is not visible in GPS anyway. -- 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] Problem to understand splitter.jar --description
Hi Bernd you can't get something like bonn_20150503_1700_basemap oder bonn_20150503_1700_fixme, only the description you set in template.args I'm not sure if I understand your problem, since solution looks simple form me - add required description after template.args, like: ... mkgmap.jar ... -c options -c template.args --description=bonn_20150503_1700_basemap --gmapsupp -- 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] open issues in the housenumber2 branch
Hi Gerd, How should we handle missing information? You can't guess if there is no house with missing number or there is one but not mapped in OSM data. So none solution would cover all cases. I would take the solution, which looks better in your code ;) What do you think about implementing precise address search in mkgmap? I mean: change each address point into a short line (like 10m) of predefined type and give a single house number to this line. There could be some more complex cases, like house number 3/5 which can be supported too. The line for address doesn't need to contain routing data in NOD, only house number in NET. -- 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] open issues in the housenumber2 branch
Hi Gerd, The question is if the users prefers to see that we are guessing or not. I think that general rule should be to create maps faithful to input data. But in this case I'm not against relaxing the rule, if this simplify map a bit. Is is possible to have roads in NET and index etc. without referencing them in NOD? It works in practice. You can strip NOD from img and map remains functional with working address search. Only routing disappears. I don't know details of NOD structure and I'm not sure about hybrid map, where only selected roads are referenced in NOD, but I guess it could work 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] Overview map in gmapsupp.img?
Hi Gerd, I see no reason why we should not add the overview map to the gmapsupp if that is what the user wants and the device is working fine with it. There is no need to add overview to gmapsupp. It can be copied as a separate file to GPS with the same result. Or user can merge overview map and detailed maps to a single gmapsupp: mkgmap.jar --gmapsupp --index 1*.img overview.img The second version adds data from overview map into index search, which cause duplicated search results, see attached picture. I think both version will show duplicated cities when performing search near current position. I haven't checked thoroughly, but I have noticed a delay, when switching from detailed map to overview in GPS. I think single map with more levels could be faster. Summarizing: in my opinion this is not a proper way to create a map. If you add direct support for this procedure to mkgmap, you would give some kind of recommendation for it. And since it can be easily done without any changes to mkgmap, I would rather leave it as it is. -- 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] Overview map in gmapsupp.img?
Hi Ralf, Is this possible on gps units which support only one map file? It is possible on all current outdoor GPS and nuvis but probably not on eTrex Legend HCx. You would have to merge img. It can be done with mkgmap or GMapTool. -- 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] Oneway
Hi Dave, Garmin format as used in img allows only for equivalent of oneway=1. Mkgmap have to reverse line direction in case of oneway=-1. So you need only one pattern in TYP file, with arrows pointing form left to right. Actually it means arrows pointing from start of a line towards its end. I'm trying to guess what is your real question. Do you get arrows pointing in wrong direction? -- 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] Overview map in gmapsupp.img?
Hi Ralf, - When I enable the basemap I see my map in zoom levels 8km and below. From 12 km and above I see the basemap. - When I disable the basemap I see my detailed map tiles in zoom levels 120km and below. It shows way too much detail and it takes very long to draw the map. That's how map is designed. Default definitions for levels in mkgmap is: --levels=0:24,1:22,2:20,3:18 This means, that last level has 18-bit resolution and is visible in zoom range 5-8km (this depends also on detail settings in device). Above these zoom GPS uses basemap. If you disable basemap, then you see last level from detailed map, which contains too many data to be displayed fast and clean. The proper solution for you would be to add more levels to detailed map. Try to use this option for mkgmap: --levels=0:24,1:22,2:20,3:18,4:16,5:14 This should include proper levels for zoom up to 120km. You can add even more levels, but probably at these levels map won't be better than basemap already present in GPS. -- 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] Overview map in gmapsupp.img?
Hi Ralf, What is the advantage of using more map tile levels instead of putting them into the overview map? This is a standard design, supported by mkgmap and Garmin tools. Yours is not, so you have to do some additional work. Isn't it the reason, for which you have started this thread? Have you tried a search for cities in eTrex? I think you can get double hits for cities present on overview map. -- 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] Overview map in gmapsupp.img?
Hi Ralf, Without the overview map in the gmapsupp.img my eTrex Legend HCx displays only the yellow background and the tile borders (no map) on all zoom levels down to 50 km. From 30 km onwards it displays the map tiles. You probably have deleted or disabled in menu Garmin basemap. Please look for file gmapbmap.img in eTrex memory and if present, then enable Worldmap in device menu. If you miss gmapbmap.img, then you can copy this file form any other GPS. -- 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] mixed index branch merge
Hi,
in my opinion stopwords sholud be dependent on country code and should
be defined in style or in definition of local parameters, the same way
like zip code before street name.
Style would be preferred, since definitions can be included in default
style, where contribute many people. Probably we could get definitions
for many countries quite fast. I think it could be something like:
mkgmap:country=POL {set mkgmap:stopwords='ulica;ul.'}
Looking for solution, please take in consideration maps, which include
many countries at once.
--
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] mixed index branch merge
Hi, What about multi-lingual countries such as Belgium or Switzerland? Good remark. I think we can set mkgmap:stopwords directly too, without defining intermediate variable for language. These definitions would be evaluated per each object, we could change stopwords when using for example name_fr instead of name tag. -- 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] mixed index branch merge
Hi, I can't imagine someone wanting all the languages in the map at the same time. Can the Garmin format even handle that? City Navigator maps support multiple languages. Street names change, when you change language settings in GPS. For example, if you use German, then street name is Waldheimer Weg but in Italian you see Via Villa del Bosco. I have found this example in South Tyrol–Trentino region. Not possible with mkgmap but you can add multiple labels to a street and all should be included in search index. I think in most cases we could put stopwords for 2-3 languages. For case above, we can set both via and weg as stopwords in Italy. -- 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] help needed for graphical problem
Hi Gerd, Or do you see a simple way to limit the iteration to a part of the way near the wanted point? I have looked at algorithm here: http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm It looks simple, it calculates error to grid at each step by adding a value representing ascent (or descent) of a line. If error is bigger than 0.5 grid, then coordinate is increased and error recalculated against new coordinate. State of algorithm is defined by 3 values: grid coordinates and error. I think there shouldn't be a problem, to restore these 3 variables for any point (grid point) of a line and then make next 10 iterations. -- 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] help needed for graphical problem
Hi Gerd, looking at Kompakte Variante i think that for each calculated point (x,y) this is true: err = (x - xS +1)*dy + (y - yS +1)*dx where xS and yS are start coordinates - initial value for x0, y0. If you find arbitrary intermediate point on the line and round its position to nearest Garmin grid point, then you get values for x, y and you can calculate err. And simply make some more iteration, finding a point, where err is the lowest. Ok, I can make a mistake somewhere, I haven't tested it, but it looks for me as a valid solution. -- 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] help needed for graphical problem
Hi Gerd, I guess it is about small distances, this part of makeBetweenPoint(): // distances are rather small, we can use flat earth approximation int lat30 = (int) (getHighPrecLat() + dLat30 * fraction); int lon30 = (int) (getHighPrecLon() + dLon30 * fraction); return makeHighPrecCoord(lat30, lon30); I think lat30 and lon30 can be rounded up and down to grid value, which would give 4 points nearest to required coordinate. Then we could select the most suitable, for example comparing angle of segments. But does it actually matter? Maybe only for very sort line? -- 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] help needed for graphical problem
Hi Gerd, one more notice - for splitting very short lines could be better to calculate intermediate point using grid coordinates of line instead of high precision like in makeBetweenPoint(). -- 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] help needed for graphical problem
Hi Gerd, I have attached picture with 2 lines split around middle point. Upper line is about 50m, lower 500m. Both have delta_lat equal to 1 grid step. I don't think that splitting make big problem here. If you allow for 10m of offset for splitting point, then Bresenham's algorithm has to calculate only 8 points. For me it looks like a good solution. Are you going to insert multiple points into a line? -- 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] Firmware V4.00 on new Marine Devices
Hi Jürgen, any news about my test file? Garmin has released new update for some models of echoMAP: http://www8.garmin.com/support/download_details.jsp?id=4749 I'm trying to download this update: http://www8.garmin.com/support/download_details.jsp?id=4763 but link to exe is broken. Maybe you have a copy? -- 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] Firmware V4.00 on new Marine Devices
Hi, see this post: http://www.boote-forum.de/showpost.php?p=3760543postcount=42 It seems that version 4.0 of firmware was affected and bug remains after upgrade from 4.0 to 4.2. But when upgrading form 3.40 to 4.20 directly, OSM maps work correctly. -- Best regards ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Firmware V4.00 on new Marine Devices
Hi Jürgen, Achim (the guy with the Echomap) cannot test it within the next two weeks. But I asked him not to forget to test it, anyway. I am also curious about the test maps even though we meanwhile have a solution for the problem. Would be interesting to know which maps works. But I rather don't expect Achim to flash back buggy firmware, which is ok for me. The most important is that free maps work again. Thanks for investigating the problem. -- 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] Railway tracks drawn around station buildings
Hi Greg, I was reacting to the notion that fixing the railway station rendering didn't belong in the default style. I hope I have never suggested it? I have voiced some opinions about purpose of default style but not about this particular bug. I have no doubts that it should be corrected in default style. So, what I meant is that IMHO mkgmap should view the default style the same way, as providing the best conversion known to the mkgmap developers, where best means the conversion that is most useful to a user with no special desires running on some typical class of devices. The device target probably would be something reasonably modern, like an oregon or etrex 30 or a nuvi from the last few years, although I haven't found that anything newer than a Etrex Vista HCx to be all that different. Actually Garmin devices are very different. There is no one standard. This alone makes idea of best conversion futile. Map, that is designed for outdoor device could be too heavy for nuvi and even displayed in a weird way. Routing on nuvi depends on model. POI categories could be classified differently on different Garmin models. Even displayed colors can depend on GPS model. -- 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] Railway tracks drawn around station buildings
Hi Gerd, ... [0x14 resolution 22] I suggest to add a comment, that most devices display object 0x14 only on layer 0 (or resolution 24? I'm not sure) and it can be invisible at resolution 22. This could prevent some surprises. -- 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] Firmware V4.00 on new Marine Devices
Hi Jürgen, I would gladly investigate problem but have no affected device. I will wait patiently, thanks. My map works in HomePort, but I haven't prepared gmapsupp.img for this. You can correct img with gmaptool, like in this example: http://www.gmaptool.eu/en/content/map-visible-basecamp -- 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] Firmware V4.00 on new Marine Devices
Hi Jürgen, could you please test this map: http://files.mkgmap.org.uk/download/251/gmapsupp-marine.7z This a map from OSM data but recompiled with cgpsmapper. It uses different parameters in TRE than maps from waterways.cz. -- 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] Lines distorted
Hi Enrico, Garmin maps have limited resolution, about 2.4m. One can't draw precisely a line, which length is near to this resolution. You can try to assign the same Garmin object type to all these segments, then probably mkgmap will be able to merge them and smooth. -- 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] Patch: New filter not-contained
Hi Max,
I like your idea, but application in style doesn't look good for me.
Wouldn't your rule add a superfluous comma, if name repeats?
What I really would like to have, are conditional statements inside
apply{} block. This could be used not only to parse name, but for
example to examine member's role in relation.
--
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] Patch: New filter not-contained
Hi Max, from your explanation I get, that presence of a tag value is tested after processing with your filter. If this is the case, then there is no problem with comma. -- 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] minxed-index branch ready for trunk?
Hi, I have never tested gmapsupp.img created by mkgmap. I have used MapInstall to create gmapsupp from map installed on PC and it worked well enough for me. -- 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] How to show land and see
Hi Walter, The last commands in polygons file are natural=sea[0x32 resolution 14] natural=land [0x4b resolution 14] Don't use object 0x4b in style, mkgmap should create it automatically. Use lowest priority for 0x4b in style or define only color without giving a priority to polygon 0x4b. -- 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] How to show land and see
Hi Walter, some clarifications: object 0x4b is a special kind of polygon, it is used as a map background and covers whole map area. You should not use it in style, because it is created by mkgmap (except for transparent maps). You can use polygon 0x4b in TYP to change background color of a map. Priorities that you set for polygons in TYP actually are draw orders. Polygon with draw order 1 is drawn before polygon with draw order 2. If polygons overlap, then polygon with higher draw order will be visible. I can't guess why you have problems with sea. I suggest that you revert to the solution, which worked for you and then only add polygon 0x4b to TYP file, without draw order or with lowest draw order. -- 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] How to use extended line types
Hi Walter, I have tried with linetype 0x1901, but I could not address it neither as 0x1901 nor as 0x11901. I think there is no subtypes for line 0x19. Line 0x1901 is probably created as 0x19 (or 0x1900). You can use lines from 0x01 to 0x2b and then from 0x10001 up. Try for example 11901. -- 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] Problem in splitter (Africa)
Hi Gerd, 3) or stop with an error message that tells the user that it is not possible to split with the used resolution Seems to be the best solution. Let user decide how to proceed. You could include some advices in final message, but the choice of solution depends on user requirements, you can't always guess what they are. -- 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] small issue with Way.getCofG()
Hi Gerd, we are not interested in the exact solution See example from QGIS plugin, function centroids(self): https://github.com/zsiki/realcentroid/blob/master/realcentroid.py -- 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] small issue with Way.getCofG()
Hi Gerd, when using --add-pois-to-areas I would prefer to get a point inside a polygon. See some ideas here: http://mathoverflow.net/questions/56655/get-a-point-inside-a-polygon But I accept average as a simple practical solution, in most cases point will be inside. -- 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
Hi Mike, add for mkgmap option --show-profiles=1 -- 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
Hi Mike option --show-profiles sets a flag in TDB file, which is a part of installation for PC. I'm not aware of any similar flag in img for device. Original topo maps from Garmin include DEM data, which are used for computing profiles. This could be the reason, why BaseCamp doesn't support contours in img. -- 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] Error in distance calculations
Hi Gerd, I think your calculations are OK for small distances. You could check latitude spread and switch to more complex calculations, similarly like you have for distance() function. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Corrections for mp reader
Hi,
I have made 3 simple corrections for reader of Polish mp format.
Proposed patch is included.
1. Line RouteParam= have most parameters optional, oneway and toll
too. Mkgmap should use defaults, when parameters are missing. Probably
there should be syntax check added, but I don't know how to invoke exit
with error message.
2. CGPSmapper supports multiple labels, I have added support for lines
Label2= and Label3=.
3. Country name can have separator and short name. I have included
function unescape() for Country=.
--
Best regards,
Andrzej
--- src/uk/me/parabola/mkgmap/general/MapElement.java 2013-12-29
01:00:05.255294100 +0100
+++ src/uk/me/parabola/mkgmap/general/MapElement.java 2014-12-21
15:21:25.062799600 +0100
@@ -78,6 +78,15 @@
this.labels[0] = name;
}
+ public void add2Name(String name) {
+ for (int i = 1; i 4; i++) {
+ if (this.labels[i] == null) {
+ this.labels[i] = name;
+ break;
+ }
+ }
+ }
+
public void setLabels(String[] labels) {
this.labels = Arrays.copyOf(labels, 4);
}
--- src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
2014-12-08 15:48:50.073510300 +0100
+++ src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
2014-12-21 15:07:19.816915200 +0100
@@ -484,6 +484,8 @@
private boolean isCommonValue(MapElement elem, String name, String
value) {
if (name.equals(Label)) {
elem.setName(unescape(recode(value)));
+ }else if (name.equals(Label2) || name.equals(Label3)) {
+ elem.add2Name(unescape(recode(value)));
} else if (name.equals(Levels) || name.equals(EndLevel) ||
name.equals(LevelsNumber)) {
try {
endLevel = Integer.valueOf(value);
@@ -503,7 +505,7 @@
} else if (name.equals(Phone)) {
elem.setPhone(recode(value));
} else if (name.equals(CountryName)) {
- elem.setCountry(recode(value));
+ elem.setCountry(unescape(recode(value)));
} else if (name.equals(RegionName)) {
//System.out.println(RegionName + value);
elem.setRegion(recode(value));
--- src/uk/me/parabola/mkgmap/reader/polish/RoadHelper.java 2014-06-25
16:52:16.95686 +0200
+++ src/uk/me/parabola/mkgmap/reader/polish/RoadHelper.java 2014-12-21
14:24:37.760538400 +0100
@@ -101,8 +101,8 @@
roadClass = 0;
if (roadClass 4)
roadClass = 4;
- oneway = Integer.parseInt(f[2]) 0;
- toll = Integer.parseInt(f[3]) 0;
+ oneway = (f.length 2) ? Integer.parseInt(f[2]) 0: false;
+ toll = (f.length 3) ? Integer.parseInt(f[3]) 0: false;
byte noAccess = 0;
for (int j = 0; j f.length - 4; j++){
if (Integer.parseInt(f[4+j]) == 0)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] A few thoughts on non-rectangular tiles
Hi Gerd, what about a simple solution, that could be used for tests? I mean to add a support for bounding poly to mkgmap as an input option, for example: --bounding-poly=12345678.poly With this option mkgmap could define tile area as a common area of a polygon and bounding box inside osm data. I think this could be used in template.args too, if splitter prepares polygons for each tile. And we could create polygons manually for testing maps, even if splitter doesn't support polygons yet. -- 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] A few thoughts on non-rectangular tiles
Hi Gerd, there are some tasks, which splitter could automatize. But I'm more interested in getting a working map than optimizing workflow. That's why I ask to start with mkgmap ;) -- 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] Multi-word street search with city
Hi Steve, it is a good news, thanks. Meanwhile I have done some tests with trailing flags, which suggest that this is not used by Mapsource. Regardless of what I have done, search in Mapsource remained the same. Or maybe I haven't found a good test. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
