Re: [mkgmap-dev] Did anyone realize cGPSmapper speaks Garmin NT?
On 26 April 2011 18:08, WanMil wmgc...@web.de wrote: What's the difference between 'old' Garmin format and NT format? Is it that NT maps are using the GMP subformat to group tiles into larger packages? Or are there any other specifics? The word on the street is that newer features like speed limit display and lane assist only work on NT maps, though of course, that may not be down to the format itself. There are indications that the UMP maps may support lane assist, though I have no way to verify this. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Did anyone realize cGPSmapper speaks Garmin NT?
On 26 April 2011 18:21, Felix Hartmann extremecar...@gmail.com wrote: Basically no additional features require NT. (not even 3d buildings or lanes or real junction view and so on). I think 1 or 2 special things need NT format though. Ah, I should have waited a minute before pressing send. Do you know about the specific example of speed limit display? Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] junction=roundabout
On 23 April 2011 16:41, Minko ligfiet...@online.nl wrote: a) because it is part of that roundabout. See Yes, I see now, that alone makes it all make sense. And it also means that the oneway=no suggestions of others won't work either. The best I can come up with is to have separate ways for the cycle path part, either not tagged as roundabout at all or tagged oneway=no. I'd consider it very unwise to have roundabouts default to 2-way for cyclists. The ones around here do enough mad stuff without having them come the wrong way around a roundabout too... Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
It looks like we may not be out of the woods yet on this one - with the latest patch, trying to build a map of Ireland (from the Geofabrik extract) fails, where it had succeeded before. Single tile, no splitting: java.lang.ArrayIndexOutOfBoundsException: 36 at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:41) at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:22) at java.util.Arrays.mergeSort(Arrays.java:1167) at java.util.Arrays.mergeSort(Arrays.java:1155) at java.util.Arrays.mergeSort(Arrays.java:1155) at java.util.Arrays.sort(Arrays.java:1079) at java.util.Collections.sort(Collections.java:117) at uk.me.parabola.imgfmt.app.net.NETFile.writePost(NETFile.java:82) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:228) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:101) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:65) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:224) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:221) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Exiting - if you want to carry on regardless, use the --keep-going option Command line is: java -Xms2g -Xmx2g -Dlog.config=svn/mkgmap/logging.properties -jar svn/mkgmap/dist/mkgmap.jar --family-id=333 --mapname= --family-name='OSM Ireland' --series-name='OSM Ireland' --description='OSM Ireland' --country-name='IRELAND' --country-abbr='IRL' --latin1 --gmapsupp --net --route --index --tdbfile --add-pois-to-areas --remove-short-arcs --check-roundabouts --generate-sea=multipolygon --check-roundabout-flares ireland.osm dermot3.TYP Worth knowing about in case the same problem doesn't get spotted in other tests. Cheers, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ 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.
It's amusing and not particularly surprising how, as soon as we have searchable maps, we discover the importance of having better addressing information about locations. So far a lot of a fundamental principles have been mentioned: * That using is_in information is easy, but not satisfactory, since it's often missing, inconsistent, poorly maintained and hard to use to infer a hierarchy of belonging (arbitrary bits of streets usually don't have it set, so how do you make a best guess of what nearby element should own it? * That boundary polygons are increasingly present on our map, that they can solve most of the problems of is_in, that they are already succeeding is_in for other address-sensitive applications in OSM, but that they are very hard to process as part of how mkgmap processes the map. I am convinced that is_in is never going to give us satisfactory results, that we cannot trust the values entered in that field by mappers and that, the more boundary polygons are used to solve other problems, the less is_in will even be maintained. I have not been entering is_in in my mapping for at least two years, at most I will correct entries by others. Mkgmap needs to, at those parts of the process where address hierarchy information is currently inferred, be capable of querying an external source to find the required information. Because at least some of my ideas for a possible source are a little cumbersome, it would probably be ideal if a number of options are permitted, rather like how drawing the sea is managed. One of the address lookup plugins would probably be the existing simple one based on is_in, for users who want to avoid extra prerequisites. So if that's what a simple, poorly-functioning address plugin looks like, what would the best one look like? Right now, the ultimate OSM geocoder is Nominatim. It is capable of consuming a place name or co-ordinate (of a road segment, say) and deducing an address hierarchy. It already uses the best clues available to do this - including both boundary polygons and is_in tags. And because an entire hierarchy is deduced, it offers us the flexibility to index locations under more than one hierarchy element, as many commercial Garmin maps seem to. For instance, my current location might reasonably be searched for under any of the following names in the city field: Dublin (city of which my location is a suburb) Dublin (historical county where I am located) Dublin 15 (postal district) Blanchardstown (Historical village and focus of modern suburb) and there are even sub-parts of Blanchardstown, typically corresponding to old rural townlands that might be searched for: Corduff, Ongar, Carpenterstown. Only the most disciplined maintainer of is_in will capture enough information to permit matching on all of these elements and there is no way sufficient consistency will exist. So a Nominatim lookup is the way to go, as we export all of the problems to an externally maintained tool. The snag: Even though Mapquest, who currently host the biggest public Nominatim instance, are very generous with the level of API lookups they allow there will be trouble if every mkgmap user performs thousands of Nominatim lookups when refreshing their Garmin maps. It will also be slow and bandwidth-intensive. This can be solved somewhat by having one's own instance of Nominatim, possibly containing only an interesting subset of the map. It would very likely prove worthwhile to define a cache file format into which to stuff those results of the query that mkgmap will require. If these cache files were maintained by country of bbox, they could be calculated centrally by people with sufficient hardware or expertise, then made available for download by normal users. This is a lot like what Steve suggests above, but without the expectation that mappers maintain the address file (because they just plain won't, and the required information is already available from Nominatim, so it would be a waste anyway). I'm interested in your comments on this. While to do what I describe certainly requires some hard work, it's all front-loaded, once we can find a working framework we never have to worry about it again. Well, not until Nominatim is superseded by an even more awesome geocoder. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ 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 16 February 2011 14:40, Robert Vollmert rvollmert-li...@gmx.net wrote: 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? I wasn't thinking of trying to force the address data into OSM format at all, but rather to store it away in a crude but persistent hash of a sort that mkgmap could learn to consult. Part of my reason for this is that I think the actual lookup of address data will be expensive, so you won't want to refresh these data as often as you will your planet extract - or at least, you'll want to confine you lookups to places that either aren't in your cache because they are new or that you have reason to suspect that a refresh is needed. If the hash is keyed on a combination of OSM ID and version, that could be the trigger for a fresh lookup from Nominatim or whatever service proves most useful. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Converting mkgmap generated maps to Mac format (was Index branch - success!)
I'm also having some problems with getting a map of mine into BaseCamp for MacOS. My source is a self-generated map made from ireland.osm (Geofabrik) with the latest index branch snapshot. I had to persevere before I managed to get the command line version of gmapibuilder from: http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py ...to do what I wanted. I have always use the GUI version until now. I started wtih a command line like this: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img .img This completed, and Garmin Map Manager copied the result into place, but BaseCamp failed to use it. But including the base map in the list of maps at the end of the command line produced something that BaseCamp will accept: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img .img The problem is, Basecamp still claims that the map lacks address information, so I'm out of ideas. Can anybody see a snag with what I've done? Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Missing icons when using TYP file
Hi, For a while I've been using my own TYP file, customised from the one maintained by Computerteddy. In theory I have changed very little in the file - some road colours, and a few translations from German and American into English :) I've also changed the Family ID to 333 because that's what my maps use. My editing is done using the popular Czech online TYP editor and the resulting TYP file works fine for me when compiled into my maps using mkgmap. With the exception of Teddy's POI icons, such as the one for bus stops. Such icons appear on all of my Garmin devices only as tiny squares, even though the correct icons appear inside the editor. If I download one of Computerteddy's ready-made maps all icons appear as expected. My best guess is that Computerteddy may be overriding the default mappings for elements like bus stops, though I'm hoping to hear any other possible causes before I jump into a replumbing job. Thanks for any pointers, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing icons when using TYP file
2010/11/10 Carlos Dávila cdavi...@orangecorreo.es: Did you check the match between the bus_stop code in the TYP file and the one you have defined in your points style file? Not so far, since I had not overridden the default (perhaps there isn't one), but I will do so for this tag as a test. Thanks, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing icons when using TYP file
2010/11/10 Carlos Dávila cdavi...@orangecorreo.es: Did you check the match between the bus_stop code in the TYP file and the one you have defined in your points style file? OK, I've done this now. In short, the default styles map bus_stop to 0x2f subtype 17 where only 0x2f subtype 08 (by default bus/rail stations or rail halts) were having this icon applied in the TYP file. So I'll probably adapt the TYP file to follow the defaults for those elements not working. Thanks for the help, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Display motorway exits name correctly
2010/9/3 Carlos Dávila cdavi...@orangecorreo.es: Motorway exits tagged as the example below are rendered by mapnik [1] with a line break instead of ; as they appear in the traffic signals [2]. Is there a way to get the same with the mkgmap styles? Currently they are rendered in a single line and they don't fit within the gps screen in most cases. That doesn't to me look like a valid use of the name tag. Are those multiple values the different destinations signposted at that exit? If so, these should be included in the exit_to tag: http://wiki.openstreetmap.org/wiki/Motorway_junction Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Display motorway exits name correctly
2010/9/3 Carlos Dávila cdavi...@orangecorreo.es: exit_to is a recently (June 2010) introduced tag for motorway_junctions and I didn't know it. I'm afraid most people have tagged motorway_junction name with what now is intended to go in exit_to tag, so there will be some confusion on it for some time. Anyway, my question is still valid, now for exit_to tag. I don't think so - if people have used the name tag for this, they shouldn't have, and the solution to broken data is to repair it. As to the exit_to tag, I can't see any good reason to display it on a standard map. It's more useful for navigation instructions. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Cannot generate map with --index
OK - blowing away my checked out code and starting again fixed the problem. Thanks to everyone for the suggestions. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Cannot generate map with --index
On 14 August 2010 09:48, Johann Gail johann.g...@gmx.de wrote: Yes, that might help. The error java.lang.IllegalAccessError points to a problem with the compiled code, not with the input osm data. Possibly there are some problems with your java runtime? I'll try it. Java is the normal MacOS system Java 6 on Snow Leopard, so you'd like to hope is wasn't to blame. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Cannot generate map with --index
On 12 August 2010 22:21, Steve Ratcliffe st...@parabola.me.uk wrote: I believe that you need to recompile mkgmap from scratch, do 'ant rebuild'. I did that, to no effect. Though in the spirit of your suggestion, I could blow away my code and check out from scratch, if you think that might help. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Cannot generate map with --index
On 12 August 2010 20:37, Felix Hartmann extremecar...@googlemail.com wrote: Might be good if that data were found... Maybe it's time to start splitting the file until I find the culprit. That's how I found a piece of broken coastline that was causing trouble before. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Cannot generate map with --index
Hi, For a while I've been out of the habit of adding --index to my command line because I don't use Mapsource to put maps on my devices. However, I wanted to do some experiments and find that I can't make it work with the following command line: java -Xms2g -Xmx2g -Dlog.config=svn/mkgmap/logging.properties -jar svn/mkgmap/dist/mkgmap.jar --family-id=333 --mapname= --family-name='OSM Ireland' --series-name='OSM Ireland' --description='OSM Ireland' --country-name='IRELAND' --country-abbr='IRL' --latin1 --gmapsupp --net --route --tdbfile --add-pois-to-areas --remove-short-arcs --check-roundabouts --generate-sea=multipolygon --check-roundabout-flares --index --adjust-turn-heading ireland.osm dermot.TYP Dropping --index from he command line fixes things. The error I get is: Exception in thread main java.lang.IllegalAccessError: tried to access method uk.me.parabola.imgfmt.app.ImgReader.position()J from class uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets at uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.init(RGNFileReader.java:227) at uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.init(RGNFileReader.java:201) at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.getOffsets(RGNFileReader.java:186) at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFileReader.java:71) at uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java:107) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java:170) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:113) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:374) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:122) And my data source is the Geofabrik ireland.osm country extract. Any ideas? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bicycle routing improvements (reverting breakage from r1431)
On 10 August 2010 16:27, Felix Hartmann extremecar...@googlemail.com wrote: to be routed on roads without much traffic. As long as there is no consensus worldwide whether or not cyclists by default are allowed on trunk roads, I wouldn't add them (and even then it probably makes not much sense, you would have to enter them as road_class=0, road_speed=0 -- but that clashes with motorcar usage). The question here is whether you exclude bikes, not whether you add them. I get the fact that a smaller road less trafficked by motor vehicles will often be better for cycling and that this is at odds with how Garmin devices will try to route them. But they problem is that highway=trunk can occur in important places in a road network that are not so nice to have to avoid on a bike. As an example, have a look at the trunk roads that occur in the centre of Dublin: http://www.openstreetmap.org/?lat=53.34725lon=-6.2653zoom=16layers=M Certainly, as a city centre, these roads can be full of cars, but no more so than any other city streets, and having these routes prohibited to cyclists gets in the way of reasonable routing. Worse, if you disallow them to pedestrians, a route to, say, a shop located on the trunk road can't even be calculated. And keep in mind here that I'm not asking for a special case to support some strange quirk of Irish mapping. The assumptions of build quality or access restrictions are the special cases here, we're just using the tag as originally conceived. I wish I had a better suggestion, though... Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction for highway=motorway[_link]
On 9 August 2010 05:56, Marko Mäkelä marko.mak...@iki.fi wrote: I think that it has to be done on a case-by-case basis. If there is a lesser road nearby, then the default (bicycle=no) is OK. If there is no other practical choice or there is only light traffic on the road, then bicycle=yes makes sense. I would say that bicycle=no is a sensible default for highway=trunk. It isn't. bicycle=no means that bicycles are legally precluded from using the road. Nothing on the wiki indicates that this should be assumed and many countries use trunk to tag roads that are both legal and (in many cases) appropriate for bicycles. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction for highway=motorway[_link]
On 8 August 2010 17:41, Marko Mäkelä marko.mak...@iki.fi wrote: shoulders) but the only choice in the area. I believe that the default style (correctly) does add bicycle=no to highway=trunk. When I get If this is so, then the default should be changed. The fact that various countries have overloaded trunk for their own usage is not a reason to force everybody else to add redundant tags to thousands of km of road. Ultimately I can see this kind of thing beings solved by per-country defaults, but right now such a default just isn't reasonable. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Warning references bad object ID
On 13 June 2010 21:05, Johann Gail johann.g...@gmx.de wrote: So I think the upper bit is used for somthing. If I mask it out I will get 121B and this will be 4635 in decimal. Could this be the faulty relation? Hi, There's no sign of this number being the relation in question. In addition, I tried the same trick on all three of the overlong numbers, to no effect. Could this be a signed-versus-unsigned problem? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Warning references bad object ID
On 14 June 2010 06:34, Marko Mäkelä marko.mak...@iki.fi wrote: The high-order bit is set on objects generated by the multipolygon processor. I guess that the low-order bits are just a running number (count of generated objects). Are there any MultiPolygon messages before that one? No, unfortunately those are the only warnings related to multipolygons. One possible improvement to the error messages would be to display the location of an arbitrary node of the erroneous way, if the original way ID is not available. That would certainly help. Clearly, it would be good if mkgmap could point to the right object, but my immediate concern is to find and fix the bad data. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Warning references bad object ID
On 14 June 2010 18:50, WanMil wmgc...@web.de wrote: the multipolygon with id 4611686018427393761 is an artificial polygon created by the --generate-sea=multipolygon option. There is definitely no chance for the multipolygon code to get the original object ID. This must be fixed in generate-sea code. A! That would explain it. In that case, I may need to find some bad coastline. Thanks for the tip! Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Warning references bad object ID
Hi folks, I periodically generate a map of Ireland from the Geofabrik ireland.osm extract. With warnings enabled, I get the following: 2010/06/13 20:39:27 WARNING (MultiPolygonRelation): ireland.osm: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427389788 contains errors. 2010/06/13 20:39:27 WARNING (MultiPolygonRelation): ireland.osm: Polygon 4611686018427393761(6P)(4611686018427392539[6P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. Clearly there is no such object ID. Can anybody identify where this is going wrong? Thanks, Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mdr address index with gmapsupp and macroadtrip installers
2009/11/30 Clifford Nolan clifford.no...@ul.ie: Most of the cities in Ireland are tagged as villages or hamlets, etc and we do not have postcodes outside Dublin city. To be precise, we don't even have postcodes in Dublin city, but postal districts that don't map well do what a Garmin device expects to be able to do with a postcode - should you, for instance, be able to enter 4 as a postcode search criterion? Or should it expect Dublin 4? Most Navteq maps I've seen appear (correctly IMHO) not to attempt to model Dublin postal districts as postcodes, but as towns. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - drive on left + roundabout direction checking
I love the roundabout warnings and, with their help, I've been able to fix all the broken roundabouts in Ireland that they have identified. In the process, though, I've spotted a particular kind of false positive that I suspect we can avoid. Consider this way: http://www.openstreetmap.org/browse/way/43100358 Before I split this way, it went directly from the roundabout west as N52, connecting in the process to the terriary road to its south _which itself connects to the roundabout_. Neither road has flares mapped for it. I got the following warning: 2009/10/27 23:20:25 WARNING (RouteNode): Incoming roundabout flare road (N52, http://www.openstreetmap.org/browse/way/43100358) points in wrong direction? http://www.openstreetmap.org/?lat=53.25524lon=-7.53688zoom=17 My interpretation is that, since these roads connect to the roundabout and then to each other, they must be flare ways. My suggestion is that there should be a certain reasonable maximum length within which flare ways are expected to connect together, and that otherwise, they be considered normal roads. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - drive on left + roundabout direction checking
Hi Mark, 2009/10/27 Mark Burton ma...@ordern.com: misc roundabout related breakage in the GB data). So far, my solution in this situation is just to partition one of the fake flares so that it will no longer trigger a warning. Yup, mine too. Your suggestion to avoid the warning is probably OK - perhaps the max distance should be scaled by the distance between the nodes on the roundabout i.e. if the flare roads are longer than, say, 5 times the distance between the nodes where the flares join the roundabout. That's easy to implement and should be correct most of the time. Another option - possibly a safer one - is to base the max length on the roundabout diameter, if that's easily deduced. Twice roundabout diameter would probably be a safe assumption. Have you seen any of the roundabout forks/overlaps errors? I saw a few forks, including one roundabout that was, to put it politely, buggered. So another nice warning in our armoury. This particular one would probably have shown up as an overlap too, but I think I had it fixed by the time overlaps were detected by name. We're in the happy position in Ireland of (now) having fairly healthy roundabouts, so with any luck I won't be able to provide much new feedback :D Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - drive on left + roundabout direction checking
2009/10/28 Mark Burton ma...@ordern.com: Unfortunately, obtaining the roundabout's diameter is rather a lot of work (for me and the computer!) as the original ways that make up the roundabout are no longer at hand. It probably could be done but I don't think it's really worth it. I shall go for my simple scheme to begin with. The simple way will work, but could you not collect all roundabout nodes together and compute min and max for both lat and long, giving you two workable diameter measures from which you could consider the larger? Or do you by that point literally only have the roundabout nodes that appear to belong to the flare-vee under consideration? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Reduce road class/speed when road is narrow
2009/10/13 Mark Burton ma...@ordern.com: It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6 !). Can the style file hack that? This, of course, is why units really suck in fields that could so easily be strictly numeric... Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Reduce road class/speed when road is narrow
2009/10/13 Mark Burton ma...@ordern.com: The OSM wiki says: Describes the width of a way or other map feature. The unit is meters unless otherwise specified. Why didn't they say the unit is meters and leave it at that. Completely mad. Many such keys did indeed in the past indicate that values were to be in m, km/h and other internationally-standard measures. But it's a wiki and the docs often change... Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - drive on left + roundabout direction checking
2009/10/3 Paul n...@pointdee.co.uk: Yup. That did it. As the logging.properties in resources was the only file of that name I just presumed it was the one to use That finally worked for me too. That revealed to me that there were in fact about 15 wrong-way roundabouts in Ireland. I'm happy to say that there are now none at all :D One question, though - I'm also getting a few warnings like the following: 2009/10/03 15:06:21 WARNING (MapBuilder): Highway N2 has no region (define a default region to zap this warning) 2009/10/03 15:06:21 WARNING (MapBuilder): Highway M8 has no region (define a default region to zap this warning) 2009/10/03 15:06:21 WARNING (MapBuilder): Highway M11 has no region (define a default region to zap this warning) 2009/10/03 15:06:21 WARNING (MapBuilder): Highway N11 has no region (define a default region to zap this warning) 2009/10/03 15:06:21 WARNING (MapBuilder): Highway M1 has no region (define a default region to zap this warning) I can imagine that applying a county name to these roads would be a valid thing to do - but what tagging scheme is expected? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1198: Merge in the sea polygon patch from
Since the sea polygons are being discussed... With the merge back into trunk, should I expect that the support there is identical to that on the multipolygon branch? I ask because there appear to be remaining differences. My test data is the Geofabrik Ireland extract. This is processed correctly (apart from the spurious lines we know about already) by the multipolygon branch but if I process it using trunk code I get a mostly flooded map. Anybody else seeing such differences? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - drive on left + roundabout direction checking
2009/9/27 Mark Burton ma...@ordern.com: Also, it now issues a warning for each roundabout it finds that appears to go in the wrong direction. I just got 720 warnings when I processed the GB map so either there is a problem with the code or there is a lot of duff roundabouts. I checked a handful of them and they were all wrong. Hi Mark, I've tried this on my map of Ireland and it works fine. Unexpectedly, though, I see _no_ errors for wrong way roundabouts. One theory is that our roundabouts are all pointing the right way... Is there any verbose mode I need to have on to see these? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitting at country borders?
2009/9/20 Apollinaris Schoell ascho...@gmail.com: but why split along the border? if you for example load bavaria-nord, bavaria-south+austria-northwest, austria-southwest-italy-nord is there any disadvantage? all borders are open in most of europe.why reintroduce them everywhere. For every .img file we generate, we have to specify country, don't we? Once destination search begins to work, it's likely to become very difficult to Navigate to, say, Kufstein in Austria if it happens to appear on a map tile mostly containing Bavaria and therefore set to Germany as a country. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitting at country borders?
2009/9/20 Apollinaris Schoell ascho...@gmail.com: first someone needs to figure out how search works at all. it may not even use country specified in a img tile. While we should certainly keep an open mind, it's too convenient that Garmin choose to break all their maps at national borders too. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon support?
2009/9/12 Steve Ratcliffe st...@parabola.me.uk: I think that has had some reasonable testing so I shall merge the multipolygon fixes to trunk. Oh goody. Isn't the sea polygon support on that branch too? Will they be merged too? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sea Polygons and java 1.6
2009/8/22 Steve Ratcliffe st...@parabola.me.uk: Agreed, so I am especially looking for Mac users to give advice and/or offer to help. In particular SoyLatte is often suggested, but this requires that you be a research licensee. The openJDK release from the same source has recently appeared and is GPL of course and so has no such restriction, but it is marked beta and although I would be surprised if there were any problem with a command line app it would be good to have it confirmed. I'm a mac user and the Java 1.6 requirement of the splitter caused me to look into this a bit. After a lot of messing around, including with Soylatte (which worked, BTW), I reached the conclusion that on MacOS Leopard at least, 1.6 is already available and many Mac users will already have it sitting silently on their machines: http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update1.html The Java preferences application will allow you to switch which version of Java is used by default. Or rather, that's how it is for me. Others can perhaps provide better info. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] sea polygons
2009/8/8 Christian Gawron christian.gaw...@gmx.de: Here is an improved version of the sea polygon patch which also handles shorelines intersecting the boundary of the map (set by the bounds element). I have tested it with Ireland - there are still some islands which are flooded, so the patch should not be considered final. Hi Christian, This works amazingly well. Danke dir! As you say, it's not quite perfect - I haven't looked in enough detail to find the flooded islands, but I have seen that at lower zoom levels, there are artefacts of land in grid-patterns in the sea, presumably on the interfaces of your sea polygons. Nothing to get worked up about, though. I'll be converting the map for use in Road Trip, which should allow me to grab screen shots, though I suppose you can probably see everything I can. I'll keep playing, but for now I'm very happy! Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] phone number bug?
FWIW, I think this problem is model-specific. My Nuvi 250 can't do Bluetooth, but it can display addresses and phone numbers and it formats them perfectly for me. Cliff's device seems to dislike the same data from the same img file, though. Dermot 2009/8/4 Bernhard Heibler bernh...@heibler.de: Hi Cliff, I was unable to reproduce your problem on my Nuvi 360. I have create a map of Ireland using your options. I just have skipped the TYP and the style file stuff. I used Hickey's Pharmacy in Santry as an example and the Nuvi displays the Phone Symbol right in front of the phone number. Havn't tried to give them a call ... but it looks fine for me. Could you point me to a POI that you used ? Maybe the address gets to long ? Thanks Berni. Hello, I use mkgmap to make Garmin maps for my Nuvi 860T gps. I notice that POIs which have only a phone number can be used directly with my bluetooth hands-free phone to call it. However, as soon as there is any address info attached to the POI as well, the phone number appears as follows in the info screen for the POI: POI xyz street adress+353 87 1234567 Notice that the phone number appears at the end of the address info without any space and it is no longer available to me to dial directly from the gps unit. The call that I use to make the map is as follows: ava -Xmx512m -jar /Applications/mkgmap/dist/mkgmap.jar --remove-short-arcs --ge nerate-sea --description=OSM_Ireland --country-name=Ireland --country-abbr= IRL --series-name=Openstreetmap --latin1 --tdbfile --codepage=1252 --style-fi le=./cliff_style --family-id=1 --product-id=1 --net --road-name-pois --add-pois- to-areas --route ./ireland.osm java -Xmx512m -jar /Applications/mkgmap/dist/mkgmap.jar --family-id=1 --gmapsupp 6*.img M001.TYP Does this look like a bug? Thanks, Cliff ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1119: Copies address data to the POIs created when using the --add-pois-to-areas option.
Hearty thanks for committing this, Steve. Dermot 2009/8/4 svn commit s...@mkgmap.org.uk: Version 1119 was commited by steve on 2009-08-04 14:20:29 +0100 (Tue, 04 Aug 2009) Copies address data to the POIs created when using the --add-pois-to-areas option. - Clinton Gladstone ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Apparent bug: POIs from areas
Folks, By accident, I've noticed that when areas are converted to POIs, address and phone number information (and maybe other stuff) does not seem to be preserved. For instance, see here: http://www.openstreetmap.org/browse/way/4482136 The maps I create can display address and phone number for normal point POIs, but not for this restaurant. Happy mapping! Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] sea polygons
This exhausted the 2G of heap space I had allocated when I tried it on
a map of Ireland. Are there known practical limits I should try to
stay within?
Dermot
2009/8/1 Christian Gawron christian.gaw...@gmx.de:
Hi,
the attached patch adds a sea polygon (based on the bounding box of the
map) and a multipolygon relation with all lines tagged as natural=coastline
as inner elements. The code merges coastline components as far as possible.
The patch also contains the multipolygon patch by Rudi which wasn't commited
so far (without this patch, the rendering fails).
The sea polygon is created as natural=sea, for which I added a mapping to
garmin type 0x32.
Caveat: I have only tested this for islands (Corsica) so far.
Best wishes
Christian
Index: src/uk/me/parabola/mkgmap/reader/osm/Way.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/Way.java (Revision 1115)
+++ src/uk/me/parabola/mkgmap/reader/osm/Way.java (Arbeitskopie)
@@ -76,6 +76,10 @@
}
}
+ public boolean isClosed() {
+ return points.get(0).equals(points.get(points.size()-1));
+ }
+
/**
* A simple representation of this way.
* @return A string with the name and start point
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(Revision 1115)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(Arbeitskopie)
@@ -5,7 +5,6 @@
import java.util.List;
import java.util.Map;
-import uk.me.parabola.imgfmt.Utils;
import uk.me.parabola.imgfmt.app.Coord;
/**
@@ -23,8 +22,9 @@
* this because the type of the relation is not known until after all
* its tags are read in.
* @param other The relation to base this one on.
+ * @param wayMap Map of all ways.
*/
- public MultiPolygonRelation(Relation other) {
+ public MultiPolygonRelation(Relation other, MapLong, Way wayMap) {
setId(other.getId());
for (Map.EntryElement, String pairs:
other.getRoles().entrySet()){
addElement(pairs.getValue(), pairs.getKey());
@@ -33,8 +33,16 @@
if (value != null pairs.getKey() instanceof Way) {
Way way = (Way) pairs.getKey();
- if (value.equals(outer))
- outer = way;
+ if (value.equals(outer)){
+ // duplicate outer way and remove
tags for cascaded multipolygons
+ outer = new Way(-way.getId());
+ outer.copyTags(way);
+ for(Coord point: way.getPoints())
+ outer.addPoint(point);
+ wayMap.put(outer.getId(), outer);
+ if (way.getTags() != null)
+ way.getTags().removeAll();
+ }
else if (value.equals(inner))
inners.add(way);
}
@@ -52,11 +60,20 @@
{
for (Way w: inners) {
if (w != null) {
- ListCoord pts = w.getPoints();
- int[] insert =
findCpa(outer.getPoints(), pts);
- if (insert[0] 0)
- insertPoints(pts, insert[0],
insert[1]);
- pts.clear();
+ int[] insert =
findCpa(outer.getPoints(), w.getPoints());
+ //if (insert[0] 0)
+ insertPoints(w, insert[0],
insert[1]);
+
+ // remove tags from inner way that
are available in the outer way
+ if (outer.getTags() != null){
+ for (Map.EntryString,
String mapTags: outer.getTags().getKeyValues().entrySet()){
+ String key =
mapTags.getKey();
+ String value =
mapTags.getValue();
+ if (w.getTag(key) !=
null)
+ if
(w.getTag(key).equals(value))
+
w.deleteTag(key);
+ }
+
Re: [mkgmap-dev] [PATCH v2] sea polygons
2009/8/2 Christian Gawron christian.gaw...@gmx.de: I can reproduce this problem and will have a look at it. My first guess is that either the shoreline is not closed or that there is still a problem with the multipolygon code. Well, the coastline has been stable for a long time, so it _should_ be closed, but we shouldn't deny the possibility. I'm thinking osmarender would make it very visible if that were the problem, though... Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
2009/6/6 Mark Burton ma...@ordern.com: If you want to have a routable map for bicycles why not just remove all the oneway tags? Because cyclists are required to obey oneway restrictions. Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
