On Sun, Jan 30, 2011 at 9:42 PM, Marko Mäkelä <marko.makela@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

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

On Mon, Jan 31, 2011 at 08:31:09PM +0100, Henning Scholland wrote:

Am 31.01.2011 20:16, schrieb Marko Mäkelä:

...

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 found an easy way to "fix" this issue. I set one Garmin-polygon-ID with a transparent image. In polygons-style-file I created as example the following rule:

shop=supermarket & building!=* [0x0D resolution 23]

For building=yes I've an extra rule. 0x0D is my transparent Garmin-ID. It works fine. Only default name should be set in the rule and not in TYP-file.

Oh, you seem to have a different use case for the add_poi feature. I was thinking that I do not necessarily want to have a POI for certain areas, say, amenity=school & name!=* or amenity=parking & access=private. You seem to not want a polygon for features for which POIs are to be generated. The add_poi action would help also there: just tell mkgmap to create the POI but not the polygon. For instance, do not create a polygon for amenity=recycling or tourism=lean_to, but just the POI. Marko

Moin, Henning Scholland schrieb am 31.01.2011 21:41:

Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon?

In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. Therefor there is some need, to disable the POI generation for some polygons, or for detecting the automatically generated POIs, to prevent there inclusion in the map. Gruss Torsten

Am 03.02.2011 12:51, schrieb Ben Konrath:

On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikow<de_muur@gmx.de> wrote:

...

Moin,

Henning Scholland schrieb am 31.01.2011 21:41:

...

Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out No, this is a error in osm-data. One object should only taged once. So if you tag this information to a node, you shouldn't tag same info to the polygon. If add-pois-to-area creates an POI, there shouldn't be any node in OSM-data. If there is already a node and so there are two symbols in the map, it's not an mkgmap-bug.

Henning

Ben Konrath schrieb am 03.02.2011 12:51:

That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out.

No, in the OSM data is only a polygon, and AFTER the POI is added to the area, I have the node and the polygon. The style processing afterwards has no chance to detect, whether there is a polygon belonging to the node or not. So in the resulting map I get both, a polygon area and a symbol. For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. But the add-pois-to-areas function is only working on all types or not working at all. And I can not remove such types from the point style, because in the OSM data there are also nodes of the same type without a corresponding polygon. So my suggestion would be, to mark all created POIs with an extra tag, e.g. mkgmap_created=add-pois-to-areas or something like that. Then I could use in the points-style a rule like type=xyz & mkgmap_created!=add-pois-to-areas ... which would only place a symbol in the map if there is no corresponding polygon. Gruss Torsten

Am 03.02.2011 22:36, schrieb Marko Mäkelä:

On Thu, Feb 03, 2011 at 05:02:43PM +0100, Torsten Leistikow wrote:

...

For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. For some minor map features, I would want only the symbol, not the polygon. For example, mappers could start drawing bus stop shelters from Bing aerial images. The shelters would be smaller than the Garmin map resolution, and thus the POI would be enough. Did you try my "hack" with a transparent polygon?

All in all I think the best would be an action in polygon-style for creating a POI. Henning

Marko Mäkelä schrieb am 03.02.2011 22:36:

...

That would scratch your itch (I would use mkgmap:generated), but it would not solve the use case that I outlined above.

Yes, thats clear. We have to kind of "complaints" about the add-pois-to-areas functions: 1. Some people wants to have sometimes the areas without an extra POI in the map 2. Some people wants to have sometimes a POI without an additional area in the map. For the second problem there is a hack suggested, to use a transparent area. My suggestion was only aimed at the first problem, to mark the automatically generated POIs, so that they can be ignored during the points style processing. In the end we all agree, that some kind of add_poi action rule would be very nice, but there is probably quite some work required to implement such a feature. Gruss Torsten

On Mon, Jan 31, 2011 at 9:57 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:

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]

I hit that one :-). I just added the option in the help file because I didn't know about this 'x' rule. Cheers, Ben

Ben Konrath (ben@bagu.org) wrote:

Hi Charlie,

On Mon, Jan 31, 2011 at 8:35 AM, <charlie@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

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