Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Hi Charlie, Like Marko, I would much much prefer an add_poi style action than the univeral --add-pois-to-areas. Yeah. And finally, and apologies for bleating on about this, I would love it if the POI that was added was *always* placed inside the area bounds, rather than in the area's centre-of-mass as currently happens. That's a sore spot for me too. I started a patch to calculate the value based on the shape's centroid but the centroid is not always going to be inside the shape for extremely concave polygons. For example, I suspect the centroid of Museo Nacional de Costa Rica is not inside the shape: http://www.openstreetmap.org/?lat=9.932377lon=-84.070927zoom=18layers=M There's a trick I could use to nudge the POI into the shape for cases like this so I might code that up when I can find some time. There's another problem that needs to be sorted out when using the driving directions to the POIs. When I'm driving to the big box store in the suburbs, I don't actually want directions to the building, but rather directions to the parking lot (car park in the UK terms) of the building. To solve this I think a new relation type will be needed where you can relate a parking lot to a building. And then of course we'll need to support this in mkgmap. Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
On Tue, Feb 01, 2011 at 11:13:33AM +0100, Ben Konrath wrote: There's another problem that needs to be sorted out when using the driving directions to the POIs. When I'm driving to the big box store in the suburbs, I don't actually want directions to the building, but rather directions to the parking lot (car park in the UK terms) of the building. To solve this I think a new relation type will be needed where you can relate a parking lot to a building. And then of course we'll need to support this in mkgmap. You could solve this by adding operator= or name= to the amenity=parking. Then, you would just navigate to the parking lot that is called 'big box store'. For foot and bicycle navigation, I'd define a POI for the main door building=entrance. This won't work perfectly when you are navigating to a store inside a shopping mall or when there are multiple entrances, but it is good enough. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
On Mon, Jan 31, 2011 at 07:35:17AM +, char...@cferrero.net wrote: Sorry, can't help with your problem, but can you explain what --ignore-unnamed-areas is? I can't find any reference to it elsewhere. My DWIM sense says that it is a parameter to --add-pois-to-areas. But there is no such option in the mkgmap source tree. mkgmap simply ignores unknown options. On a related note, I believe that an alternative to add-pois-to-areas should be implemented, by introducing an add_poi action in the polygons style file. In that way, one could flexibly choose which polygons deserve a POI. Regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Marko Mäkelä schrieb am 31.01.2011 20:16: On a related note, I believe that an alternative to add-pois-to-areas should be implemented, by introducing an add_poi action in the polygons style file. In that way, one could flexibly choose which polygons deserve a POI. I just started using add-pois-to-areas last week. Before I was put off by the problem of unwanted POIs. But due to the Bing images, more and more objects are mapped as areas instead of POIs now. I still think, that an add_poi action is highly desirable (it could be easily extended so that you could specify, whether you want the POI in the centre, on the first/last node, on all nodes, between the nodes...) But a much easier solution for the unwanted POIs would be, if the add-pois-to-areas function would add a predifined tag to each created POI (e.g. mkgmap_created=add-pois-to-areas). With such a marking it should be possible to ignore all unwanted POIs within the points style processing. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Hi My DWIM sense says that it is a parameter to --add-pois-to-areas. But there is no such option in the mkgmap source tree. mkgmap simply ignores unknown options. Option checking was added quite a long time ago... Now any option that is not in the options help is rejected with an error. [unless it is preceeded with x- eg --x-ignore-unnamed-areas] ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Hi Charlie, On Mon, Jan 31, 2011 at 8:35 AM, char...@cferrero.net wrote: Sorry, can't help with your problem, but can you explain what --ignore-unnamed-areas is? I can't find any reference to it elsewhere. That's a custom patch I include with the version of mkmap that I use. It doesn't add a POI for areas that don't have a name. I'd be happy to share the patch if you're interested. I haven't posted it because it's kind of a hack but it works. I guess a better solution would be to make it an option to --add-poi-to-area but, as a bunch of people have pointed out, that functionality really needs to be reworked. I've thought doing it a couple of times but sadly I don't have a lot of extra time these days. I did, however, post a couple of updates to the original patch a while ago but I'm not sure if those were integrated. (I think anyway, it was a while ago) Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
On Sun, Jan 30, 2011 at 9:42 PM, Marko Mäkelä marko.mak...@iki.fi wrote: On Sun, Jan 30, 2011 at 08:53:09PM +0100, Ben Konrath wrote: I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp You seem to have have a vertical band of inverted land/sea west from Oakville. I would guess that the NW or NE corner of the inverted box is at a tile border. I would suspect some error at the spot where one of the vertical lines intersects with the real coastline. Hmm, I was almost going to believe that the ocean starts right south of Canada, but then I remembered that there is some piece of land called the United States in between. :-) You can't really see the U.S. across the lake from Toronto it's easy to pretend it's not there :-). I would guess two possible causes for your problem. Either your tile boundaries are chosen badly, so that some multipolygons are severed by them, or the input data is bad. splitter.jar will leave some 'safety margin' around the tiles, but it may not be enough. When the Lake Päijänne in Finland was defined in a single multipolygon (it used to be natural=coastline), I got some errors that I fixed by moving my tile boundaries so that the entire lake fits in a single tile. The actual coastline seem fine around where the problem flooded land hits the lake. I think it probably has something to do with the multipolygon that makes up the North shore of Lake Ontario. I'm using my own Canada polygon cut from the planet so I might be cutting off the parts of the multipolygon. I'll look into this when I have some time. If you want generate-sea to work on a non-rectangular map extract (and if the Great Lakes have been defined as natural=coastline), you may have to apply some black magic when choosing the tile borders. For my Finland map, I extracted the natural=coastline from the Geofabrik finland.osm.pbf with Osmosis, and loaded the result in JOSM. Then I figured out how to choose the tile borders so that the missing sections of natural=coastline would be outside the tile borders. Only in the north, I had to use extend-sea-sectors to augment a missing bit, because I did not want to create lots of tiny tiles near the Swedish/Finnish land border. Thanks, this is really useful information. I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties 400M could be a bit scarce, but probably not causing this. I run with -Xmx1024m. If your logging.properties is like the one I have at http://www.polkupyoraily.net/osm/, you should have some mkgmap.log.* files. The most recent one should be mkgmap.log.0. Does anybody know what's going on? What's the best way to debug a problem like this? Search mkgmap.log.0 for 'MultiPolygon' or 'coastline'. Or, if you are ambitious, take and adapt my logging.ignore, and grep -vf logging.ignore mkgmap.log.0, and fix all errors. That is doable for a small country, such as Finland. I update my public map only when there are no serious errors (such as multipolygon issues or dead-end oneways other than some driveway). Again, great information. Thanks! I'll check how Canada is doing on the error front. For now I'm relying on people who download my map to let me know if something's broken but it's would be better to add some error checking like you do. Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Ben Konrath (b...@bagu.org) wrote: Hi Charlie, On Mon, Jan 31, 2011 at 8:35 AM, char...@cferrero.net wrote: Sorry, can't help with your problem, but can you explain what --ignore-unnamed-areas is? I can't find any reference to it elsewhere. That's a custom patch I include with the version of mkmap that I use. It doesn't add a POI for areas that don't have a name. I'd be happy to share the patch if you're interested. I haven't posted it because it's kind of a hack but it works. I guess a better solution would be to make it an option to --add-poi-to-area but, as a bunch of people have pointed out, that functionality really needs to be reworked. I've thought doing it a couple of times but sadly I don't have a lot of extra time these days. I did, however, post a couple of updates to the original patch a while ago but I'm not sure if those were integrated. (I think anyway, it was a while ago) I thought as much. My solution to the same issue has been via the style file: i.e. leisure=park name=* [0xbla resolution bla] This means that a POI is only created when the area has a name (that can be used in a POI search) Like Marko, I would much much prefer an add_poi style action than the univeral --add-pois-to-areas. And finally, and apologies for bleating on about this, I would love it if the POI that was added was *always* placed inside the area bounds, rather than in the area's centre-of-mass as currently happens. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with --generate-sea near Toronto, Canada
Hi, I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties -jar \ /home/ben/osm/mkgmap/dist/mkgmap.jar --tdbfile --latin1 --gmapsupp \ --country-name=Canada --country-abbr=CAN '--series-name=OSM Canada' \ '--family-name=Open Street Map Canada 12 Jan 2011' --location-autofill=1 \ --add-pois-to-areas --ignore-unnamed-areas --road-name-pois --check-roundabout-flares \ --route --remove-short-arcs --drive-on-right --check-roundabouts --family-id=34244 \ --product-id=1 --generate-sea=extend-sea-sectors,multipolygon --make-all-cycleways -c template.args --description=ALL Does anybody know what's going on? What's the best way to debug a problem like this? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
On Sun, Jan 30, 2011 at 08:53:09PM +0100, Ben Konrath wrote: I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp You seem to have have a vertical band of inverted land/sea west from Oakville. I would guess that the NW or NE corner of the inverted box is at a tile border. I would suspect some error at the spot where one of the vertical lines intersects with the real coastline. Hmm, I was almost going to believe that the ocean starts right south of Canada, but then I remembered that there is some piece of land called the United States in between. :-) I would guess two possible causes for your problem. Either your tile boundaries are chosen badly, so that some multipolygons are severed by them, or the input data is bad. splitter.jar will leave some 'safety margin' around the tiles, but it may not be enough. When the Lake Päijänne in Finland was defined in a single multipolygon (it used to be natural=coastline), I got some errors that I fixed by moving my tile boundaries so that the entire lake fits in a single tile. If you want generate-sea to work on a non-rectangular map extract (and if the Great Lakes have been defined as natural=coastline), you may have to apply some black magic when choosing the tile borders. For my Finland map, I extracted the natural=coastline from the Geofabrik finland.osm.pbf with Osmosis, and loaded the result in JOSM. Then I figured out how to choose the tile borders so that the missing sections of natural=coastline would be outside the tile borders. Only in the north, I had to use extend-sea-sectors to augment a missing bit, because I did not want to create lots of tiny tiles near the Swedish/Finnish land border. I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties 400M could be a bit scarce, but probably not causing this. I run with -Xmx1024m. If your logging.properties is like the one I have at http://www.polkupyoraily.net/osm/, you should have some mkgmap.log.* files. The most recent one should be mkgmap.log.0. Does anybody know what's going on? What's the best way to debug a problem like this? Search mkgmap.log.0 for 'MultiPolygon' or 'coastline'. Or, if you are ambitious, take and adapt my logging.ignore, and grep -vf logging.ignore mkgmap.log.0, and fix all errors. That is doable for a small country, such as Finland. I update my public map only when there are no serious errors (such as multipolygon issues or dead-end oneways other than some driveway). For what it is worth, yesterday I found out that http://www.openstreetmap.org/browse/relation/1201329 contained some minor puddles in Mikkeli, Finland in role=outer and exactly one lake and island (role=outer, role=inner) somewhere in Canada. After I removed the bogus role=outer puddles, JOSM warned that the remaining multipolygon had unclosed polygons. I did not try to fix that. (I guess that there should be a validator that complains about multipolygons whose members are far apart. In the recent days, I have also come across Finnish-German and Finnish-Spanish multipolygons.) Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Hi Ben, the generate-sea algorithm sometimes floods the land in case there is a gap in the coastline data. There are several generate-sea options to fix these gaps. I recommend to have a closer look at: * close-gaps=NUM Close gaps in coastline that are less than this distance (metres). Common values are between 500 and 6000. * floodblocker The floodblocker is a kind of rescue system that detects if land area is flooded and removes the sea from these areas. You get information of all options if you call mkgmap without any option: java -jar mkgmap.jar WanMil Hi, I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties -jar \ /home/ben/osm/mkgmap/dist/mkgmap.jar --tdbfile --latin1 --gmapsupp \ --country-name=Canada --country-abbr=CAN '--series-name=OSM Canada' \ '--family-name=Open Street Map Canada 12 Jan 2011' --location-autofill=1 \ --add-pois-to-areas --ignore-unnamed-areas --road-name-pois --check-roundabout-flares \ --route --remove-short-arcs --drive-on-right --check-roundabouts --family-id=34244 \ --product-id=1 --generate-sea=extend-sea-sectors,multipolygon --make-all-cycleways -c template.args --description=ALL Does anybody know what's going on? What's the best way to debug a problem like this? Thanks, Ben ___ 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
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Ben Konrath (b...@bagu.org) wrote: Hi, I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties -jar \ /home/ben/osm/mkgmap/dist/mkgmap.jar --tdbfile --latin1 --gmapsupp \ --country-name=Canada --country-abbr=CAN '--series-name=OSM Canada' \ '--family-name=Open Street Map Canada 12 Jan 2011' --location-autofill=1 \ --add-pois-to-areas --ignore-unnamed-areas --road-name-pois --check-roundabout-flares \ --route --remove-short-arcs --drive-on-right --check-roundabouts --family-id=34244 \ --product-id=1 --generate-sea=extend-sea-sectors,multipolygon --make-all-cycleways -c template.args --description=ALL Sorry, can't help with your problem, but can you explain what --ignore-unnamed-areas is? I can't find any reference to it elsewhere. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
