Either mkgmap error or splitter error
Great work of you in development of this software. But I have a problem in creating a map of the Netherlands. Mkgmap reports an error, because the map is too large. So I used splitter with the --max-nodes option and decreased the number down to 1000000, but now I get an error in splitter (Relation in too many areas). Ignoring this error will cause a problem in Mapsource, zooming in and out doesn't work correct (no screen updating) and some tiles are completely empty. In the forum I couldn't get an answer for this problem. My only solution is to delete all tracks POIs and paths in mkgmap style-file to reduce the osm-data, but in this way I lose a lot of information, what I don't want to do. Can you tell me what I have to do for creating an error free map with all available osm data? Greetings, Ralf
Use 500000 Ralf Reimann wrote:
Great work of you in development of this software. But I have a problem in creating a map of the Netherlands. Mkgmap reports an error, because the map is too large. So I used splitter with the --max-nodes option and decreased the number down to 1000000, but now I get an error in splitter (Relation in too many areas). Ignoring this error will cause a problem in Mapsource, zooming in and out doesn't work correct (no screen updating) and some tiles are completely empty. In the forum I couldn't get an answer for this problem. My only solution is to delete all tracks POIs and paths in mkgmap style-file to reduce the osm-data, but in this way I lose a lot of information, what I don't want to do. Can you tell me what I have to do for creating an error free map with all available osm data?
Greetings, Ralf
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ralf, did all tiles created by the splitter compile without error of mkgmap? I had a similar problem with netherlands when activating routing in mkgmap and I had to reduce max-nodes to 500000. But I didn't test it with Mapsource but with my Garmin where the created map seems to work then. Regards Andre -------- Original-Nachricht --------
Datum: Tue, 26 May 2009 16:06:29 +0200 Von: Ralf Reimann <ralrei@gmx.de> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Either mkgmap error or splitter error
Great work of you in development of this software. But I have a problem in creating a map of the Netherlands. Mkgmap reports an error, because the map is too large. So I used splitter with the --max-nodes option and decreased the number down to 1000000, but now I get an error in splitter (Relation in too many areas). Ignoring this error will cause a problem in Mapsource, zooming in and out doesn't work correct (no screen updating) and some tiles are completely empty. In the forum I couldn't get an answer for this problem. My only solution is to delete all tracks POIs and paths in mkgmap style-file to reduce the osm-data, but in this way I lose a lot of information, what I don't want to do. Can you tell me what I have to do for creating an error free map with all available osm data?
Greetings, Ralf
-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
In my experience it is not possible to split the whole world (or Europe) using a sensible max-nodes setting unless you settle with very small tiles. Western Netherlands and Denmark are problem areas, I manually divide failing tiles after an initial split using --max-nodes=1200000 Ralf Reimann wrote:
Great work of you in development of this software. But I have a problem in creating a map of the Netherlands. Mkgmap reports an error, because the map is too large. So I used splitter with the --max-nodes option and decreased the number down to 1000000, but now I get an error in splitter (Relation in too many areas). Ignoring this error will cause a problem in Mapsource, zooming in and out doesn't work correct (no screen updating) and some tiles are completely empty. In the forum I couldn't get an answer for this problem. My only solution is to delete all tracks POIs and paths in mkgmap style-file to reduce the osm-data, but in this way I lose a lot of information, what I don't want to do. Can you tell me what I have to do for creating an error free map with all available osm data?
Greetings, Ralf
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Tue, May 26, 2009 at 6:06 PM, Lambertus <osm@na1400.info> wrote:
I manually divide failing tiles after an initial split using --max-nodes=1200000
Just out of interest, would it be possible to better automate your process by reusing an areas.list file, with your manual areas specially defined? I would expect that the tiles would remain relatively stable over time, only requiring periodic updates to account for data growth. Cheers.
I wasn't clear about that but you are right: The planet was splitted once with max-nodes=1200000 and then made manual changes to the areas.list. Clinton Gladstone wrote:
On Tue, May 26, 2009 at 6:06 PM, Lambertus <osm@na1400.info> wrote:
I manually divide failing tiles after an initial split using --max-nodes=1200000
Just out of interest, would it be possible to better automate your process by reusing an areas.list file, with your manual areas specially defined? I would expect that the tiles would remain relatively stable over time, only requiring periodic updates to account for data growth.
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Wed, May 27, 2009 at 09:33:59AM +0200, Lambertus wrote:
I wasn't clear about that but you are right: The planet was splitted once with max-nodes=1200000 and then made manual changes to the areas.list.
If you are editing areas.list by hand, could you please consider making the tile borders follow natural or political borders more closely, like I requested some time ago on this list? If the tile borders at http://garmin.na1400.info/routable.php are accurate, you have split Finland into 8+ tiles, some of which share large areas with Sweden, Estonia, Latvia, Norway and Russia. To me, a natural tile border would be the Baltic sea in the SW of Finland. It's not very useful to have Estonia and Finland on the same tile; there's 80 km of water in between. Same for Southern Finland and Sweden. Russia and Finland are connected by a small number of border crossings, and they should use different code pages (cp1251 for Cyrillic, cp1252 for Latin). Your current "east border" of Finland looks reasonable. It is also OK to have the sparsely populated north Norway/Sweden/Finland in a single map tile (routable/13-05-2009/63240168.img). If anything, I'd split that tile near the Russian border and extend it a bit south, to include the northern coast of the Baltic sea. For what it is worth, I have an areas.list for a 3-tile Finland at http://www.polkupyoraily.net/osm/. The tile borders might not be directly applicable, since it is based on finland.osm.bz2 instead of the whole planet. Another simple suggestion: Please consider making a single tile of Iceland and Faroe Islands. Currently, they are combined with parts of UK and Norway. Best regards, Marko
On Wed, 27 May 2009, Marko Mäkelä wrote:
If you are editing areas.list by hand, could you please consider making the tile borders follow natural or political borders more closely, like I requested some time ago on this list? If the tile borders at http://garmin.na1400.info/routable.php are accurate, you have split Finland into 8+ tiles, some of which share large areas with Sweden, Estonia, Latvia, Norway and Russia. To me, a natural tile border would be the Baltic sea in the SW of Finland. It's not very useful to have Estonia and Finland on the same tile; there's 80 km of water in between. Same for Southern Finland and Sweden. Russia and Finland are connected by a small number of border crossings, and they should use different code pages (cp1251 for Cyrillic, cp1252 for Latin).
Some time ago I asked for the support of polygonal tiles (just like in the Garmin maps) on this list. This way, even border towns could be assigned to the correct country/tile. Unfortunately (for me), it seems that there are many other and more important issues to be solved beforehand. I've considered to plunge into the code and do it myself, but it looks like it's going to be a major rewrite as quite a lot of the internals depend on rectangular areas rounded to some power of 2 instead of arbitrary points at the highest precision. In a couple of months I will have some spare time -- if nobody does it until then, I'll give it a try. -Wolfgang
I know that you requested this before, but I see no good way to implement this and satisfy everyone's needs. Perhaps for Finland, Iceland and other island nations this might work, but what about countries with neighbors on each side and no straight borders? There would always be someone complaining about the tile edges. So for now I've decided not to do any of those adjustments. What's the harm in having a section of another country on your GPS? The bit about code pages is interesting, but I would rather focus on internationally readable maps than localized maps (which can be easily generated by an OSM user from that country). Perhaps this reasoning will change when polygon tiles are possible. Marko Mäkelä wrote:
On Wed, May 27, 2009 at 09:33:59AM +0200, Lambertus wrote:
I wasn't clear about that but you are right: The planet was splitted once with max-nodes=1200000 and then made manual changes to the areas.list.
If you are editing areas.list by hand, could you please consider making the tile borders follow natural or political borders more closely, like I requested some time ago on this list? If the tile borders at http://garmin.na1400.info/routable.php are accurate, you have split Finland into 8+ tiles, some of which share large areas with Sweden, Estonia, Latvia, Norway and Russia. To me, a natural tile border would be the Baltic sea in the SW of Finland. It's not very useful to have Estonia and Finland on the same tile; there's 80 km of water in between. Same for Southern Finland and Sweden. Russia and Finland are connected by a small number of border crossings, and they should use different code pages (cp1251 for Cyrillic, cp1252 for Latin).
Your current "east border" of Finland looks reasonable. It is also OK to have the sparsely populated north Norway/Sweden/Finland in a single map tile (routable/13-05-2009/63240168.img). If anything, I'd split that tile near the Russian border and extend it a bit south, to include the northern coast of the Baltic sea.
For what it is worth, I have an areas.list for a 3-tile Finland at http://www.polkupyoraily.net/osm/. The tile borders might not be directly applicable, since it is based on finland.osm.bz2 instead of the whole planet.
Another simple suggestion: Please consider making a single tile of Iceland and Faroe Islands. Currently, they are combined with parts of UK and Norway.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I just wrote this in a pm, but I think I may ask this on the mailing list too: Is there a way to test the routing at home? Garmin offers a software called "Garmin mobile PC" which should be able to do the routing based on Garmin map files. Is there a freeware alternative? Markus
On Tue, May 26, 2009 at 6:41 PM, <gypakk@gmx.eu> wrote:
Is there a way to test the routing at home? Garmin offers a software called "Garmin mobile PC" which should be able to do the routing based on Garmin map files. Is there a freeware alternative?
If you use Windows or Mac OS, you can use Garmin's Mapsource or Roadtrip. I have found that this is a reasonable test of routing, but does not always match what happens on the GPS. I am not aware of an alternative for Linux; Qlandkarte does not support routing. Cheers.
Clinton Gladstone escribió:
On Tue, May 26, 2009 at 6:41 PM, <gypakk@gmx.eu> wrote:
Is there a way to test the routing at home? Garmin offers a software called "Garmin mobile PC" which should be able to do the routing based on Garmin map files. Is there a freeware alternative?
If you use Windows or Mac OS, you can use Garmin's Mapsource or Roadtrip. I have found that this is a reasonable test of routing, but does not always match what happens on the GPS.
I am not aware of an alternative for Linux; Qlandkarte does not support routing.
You can also use MapSource on Linux, under wine. I do so usually and it works fine. Cheers Carlos
Thank you and thanks to Mark! I must admit, I did not know that Mapsource supports routing... :-) Just managed to display a small gmapsupp.img in Mapsource. Now I can start extended tests of Mark's cycle patch. Markus -------- Original-Nachricht --------
Datum: Tue, 26 May 2009 18:51:49 +0200 Von: Clinton Gladstone <clinton.gladstone@googlemail.com> An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Routing tests without Garmin device? Garmin emulator for PC?
On Tue, May 26, 2009 at 6:41 PM, <gypakk@gmx.eu> wrote:
Is there a way to test the routing at home? Garmin offers a software called "Garmin mobile PC" which should be able to do the routing based on Garmin map files. Is there a freeware alternative?
If you use Windows or Mac OS, you can use Garmin's Mapsource or Roadtrip. I have found that this is a reasonable test of routing, but does not always match what happens on the GPS.
I am not aware of an alternative for Linux; Qlandkarte does not support routing.
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
gypakk@gmx.eu wrote:
Thank you and thanks to Mark!
I must admit, I did not know that Mapsource supports routing... :-)
Just managed to display a small gmapsupp.img in Mapsource. Now I can start extended tests of Mark's cycle patch.
Markus
I didn't know Mapsource did all this either. That's interesting - and maybe for a different reason than originally stated. Consider: 1) Mapsource can do simulated routing. 2) In order to do (1) above, Mapsource decrypts Garmin's .img files. 3) As a consequence of (2), the algorithm and keys to decrypting Garmin's .img files are in Mapsource. 4) Mapsource runs on a PC. 5) PC software can be spied on whilst running, and portions can be deciphered (remember the deCSS business 10 years ago?). 6) As a consequence of (4) and (5), Mapsource could be reverse-engineered (or some portions could anyway). 7) Reverse engineering software is legal (in Europe) for purposes of creating "compatable" systems. 8) Mkgmap tries to makes a map that is "compatable" with Garmin GPS navigators. Anyone see where the logic of this is going? :-) We've been complaining that we can't explore Garmin's file format properly because we can't decrypt their files... are we missing a trick here? Do any of our Norwegian members have contact with the shadowy "M.O.R.E" (Masters of Reverse Engineering)? :-) Steve
gypakk@gmx.eu wrote:
Is there a way to test the routing at home? Garmin offers a software called "Garmin mobile PC" which should be able to do the routing based on Garmin map files. Is there a freeware alternative?
If you do have a Garmin GPS but want to test routing in areas where you can't go you can use the unit's simulation mode.
participants (11)
-
Andre Hinrichs -
Carlos Dávila -
Clinton Gladstone -
Felix Hartmann -
gypakk＠gmx.eu -
Lambertus -
Marko Mäkelä -
Ralf Kleineisel -
Ralf Reimann -
Steve Hosgood -
Wolfgang v. Hansen