Re: [mkgmap-dev] Address & city country name assignment.
[This is not particularly in reply to Dermot.] First off, congratulations on the progress that you've been making with respect to search. My suggestion would be to move region (country, city) detection into a preprocessing step, outside of mkgmap. That is, some other tool preprocesses and normalizes the osm data and assigns consistent is_in tags. Then mkgmap looks only at the is_in tags. The same approach could be used for coast line and multipolygon handling: A preprocessor would fix up or delete broken multipolygons and standardize tagging (on outer way, on the relation, etc.) Ideally, there'd be planet dumps and extracts or a read-only API that delivered such normalized data, as this would be useful to most consumers of OSM data. Other things that could be done: - Normalize footway/cycleway/path. - Assign maxspeed tags based on inside/outside built up area. - ... I realize this is quite far away, and going just part of the way would make mkgmap harder to use (need to run a bunch of tools on the extract before compiling the map). So I'm not saying anyone should do this, just trying to suggest an alternative approach. Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address & city country name assignment.
On Feb 16, 2011, at 15:20, Dermot McNally wrote: > On 16 February 2011 13:28, Robert Vollmert wrote: > >> My suggestion would be to move region (country, city) detection into a >> preprocessing step, outside of mkgmap. That is, some other tool preprocesses >> and normalizes the osm data and assigns consistent is_in tags. Then mkgmap >> looks only at the is_in tags. > > That was actually my first thought on how to improve things. But the > problem is that you would potentially be doing this: > > * Obtain hierarchy where the role of each element is known > * Flatten this into an ordered list of elements, still respecting a > hierarchy as best you can, but discarding the knowledge of roles > * Bring this flattened version of the data into mkgmap and attempt to > use the existing hints to extrapolate the knowledge of the roles that > you only just threw away in the last step. So instead of writing is_in tags, write the actual data as relations? One relation per street, one relation per city, etc., with all streets as members in the corresponding city relation? Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] OT: Garmin Edge 705 FAT recovery needed
On Mar 21, 2011, at 20:27, Marko Mäkelä wrote: > Around March 10, the internal file system in my Garmin Edge 705 could no > longer be mounted by Linux. I was also unable to convert saved tracks > into training runs, which I guess means that the Garmin firmware failed > to read the file system as well. Also the base map (gmapbmap.img) failed > to load. So, currently the Edge 705 is crippled in that I can see the > gmapsupp.img that is on the SD card, but cannot save any tracks. > > I saved the entire 1GB image from the device to my computer. There is > about 23 MB of nonzero data followed by zero bytes. The actual payload > may be smaller. It looks like the "boot" sector and all of FAT1 and most > of FAT2 are zeroed out. I doubt that there's any vital unit-specific data stored on a removable SD card. It's possible to use the Edge without the card right? Regardless, since you've backed up the data, messing with the content of the SD card should be safe. So what I'd probably do in your situation is to try formatting the sd card with one FAT partition (some mkdosfs invocation), insert it, and expect the device to work as it used to. Is it possible that your SD card has failed? Presumably, you didn't get any errors when making that backup, but maybe a write error also causes the errors you've been seeing? Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
On Jun 2, 2009, at 07:50, Thilo Hannemann wrote: When looking at the log output there are a lot of ways with the name "SIEDLUNG NEUD?RFEL" (#35170047, #35160048, #35170059, #35170062, #35170063, #35170064, #35170070, #35170071, #35170072, #35170084, ... all in all 174) at about lat 51,08201/lon 14,67827. There are much less ways with that name in the original germay.osm.bz2! They consume 174 entries in TableA and TableB (whatever that is). But in TableB only 62 entries are allowed. This triggers a subdivision, but that doesn't help, as still they all get into one subdivision, which gets divided further and further until the assertion is triggered. [...] The log output is available at http://osm.arndnet.de/mkgmap.log.0 (15 MB) The input file problem.osm is available at http://osm.arndnet.de/problem.osm.zip (16 MB) I think this is just bad data: As far as I know, the splitter doesn't create new osm ids, and if you look at those ways (e.g. http://www.openstreetmap.org/browse/way/35170062) you'll see that those existed but have been deleted. Is it possible that your germany.osm.bz2 was from a different time than problem.osm.bz2? If not, maybe there's a bug somewhere (splitter?) that undeletes elements with visible='no', and your source data contained the deleted ways? Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
On Jun 2, 2009, at 07:50, Thilo Hannemann wrote: The command line is java -Xmx2048m -ea -Dlog.config=logging.properties -jar trunk/dist/ mkgmap.jar --net --route problem.osm The log output is available at http://osm.arndnet.de/mkgmap.log.0 (15 MB) The input file problem.osm is available at http://osm.arndnet.de/problem.osm.zip (16 MB) Reduced (and slightly munged) extract that causes the same error here at http://page.mi.fu-berlin.de/vollmert/tmp/neud.osm.gz Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitting an country borders?
On Sep 16, 2009, at 09:42, Marko Mäkelä wrote: > I seem to remember someone mentioning that Garmin supports non- > rectangular > map tiles. Would that help? Or would it be too much effort with > too little > gain to implement that in mkgmap (and splitter)? > Am 16.09.2009, Carsten Schwede wrote: >> What need mkgmap special to enable routing between tiles? I would >> like >> to use this special also in the cutting program I use for creating a >> completely routable worlmap... On Sep 16, 2009, at 09:14, d...@team-oid.de wrote: > I'm currently a bit confused. > Is it possible to route over mapssets or not? > I think it's still not working for maps which are splitted without > splitter. Since there's some confusion I'll try to summarize, though my knowledge may be a little out-of-date. # IMG format For routing to work between two different IMGs, the nodes on the "boundary" need to be marked specially. Here, "boundary" is in theory just the nodes where both routing graphs meet. These don't necessarily need to lie on the edge of the map, and the map doesn't necessarily need to have a rectangular shape. AFAIK, it should be possible to route using two tiles where one contains a country's motorway network and another contains the lower- class roads, with boundary nodes at the motorway ramps. It may well be that the routing algorithm expects a different, tile-like separation, however. It's unlikely that a tile needs to be rectangular, but it may well be that a tile should be convex (geographically and/or with respect to the routing graph). # mkgmap Mkgmap needs to know which nodes to mark as boundary nodes. The simple way is to just tell mkgmap, which is what happens when using polish (.mp) input, where you flag boundary nodes. If you want to test some of the above speculation, creating appropriate .mp files is probably the easiest way to go. For .osm, mkgmap determines boundary nodes itself. Here lies the restriction to rectangular tiles: The .osm input needs to contain a -element specifying the desired bounds of the output IMG. The OSM data itself need not be contained within the -element. mkgmap clips all geometry to these bounds and generates boundary nodes wherever ways are clipped (there's probably lots of special cases here). Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
