WanMil,

at the moment I have no idea why tile boundaries are visible. What do you see if you zoom in? Do you see any kind of line style or is it just an empty line?

Just a line with a bluey-purpley colour. Look at the image in the last email and zoom right in to that and you will see it's just a plain line.

I did have a visualization of the bounding box (a motorway on the bbox) but that's definitely not part of the patch.

Do you have any idea what I could looking for?

Not yet. It's interesting that the line is not visible in the sea polygons. Mark

WanMil,

My workaround was based on the assumption that all polygons created by the mp code will be clipped to the bounding box later (by the style code). Can you confirm that?

Yes, polys are clipped in StyledConverter.addShape(). I looked at the output using mapedit and the land has no polygons that touch the tile edges (except for other map features like woods, lakes, buildings, etc.) So the lines are not coming from stuff in the img file. Weird... Mark

WanMil,

Good news - I don't think it's your problem. I disabled the sea generation completely and the lines on the tile edges are still there.

Haven't a clue what's causing them (and I don't care because they don't show up when I use generate-sea=polygons).

One issue that I don't think you can do much about is that mapsource tends to show horizontal and vertical gaps between polygons when you zoom out. They are a bit weird because they come and go as you pan and zoom. Having polygons for sea (as opposed to having polygons for land, which is what I have been using) means that you get more artifacts visible when using mapsource. That's a shame but may well not be a problem when viewing the map on a real gps.

Anyway, your new MP code is producing great results (and it's quick).

Mark

Mark, thanks a lot! I did have a bad test... I generated a map of belgium with generate-sea=multipolygon,no-sea-sectors and whole belgium is flodded :-( BUT I found out that some of the coastline segments are missing or are not completely contained in the OSM dump, so that's no shame for mkgmap. I think it's a general problem that the osm dumps do not contain any detailed information about the shape that was used to cut out the OSM data. Without this shape we don't have a good chance to detect the edges and to close open polygons. Maybe we can propose this to the next version of the API? Another idea is to introduce a kind of ShapeDetector which tries to regenerate the original shape of a tile / OSM dump. I don't have a good idea how to do this and I have less idea how to do this in acceptable time. Maybe we can use an java.awt.geom.Area object and add all lines with a dimension of 1 unit. At the end of reading the OSM file we could get the outer shape from the area object. But I don't think that this is quick..... Anyhow the mp code of my patch is not the solution for all but at the moment it improves the handling of multipolygons very much compared to the current trunk. And after committing I think I will get some more feedback from other map generators which will help to improve things. WanMil

WanMil,

Good news - I don't think it's your problem. I disabled the sea generation completely and the lines on the tile edges are still there.

Oops, I may have spoken too soon. With your v3 patch in place, I made a new map with generate-sea=polygons and not only are the lines still there, all my sea has disappeared! Don't worry, I now think the lines between the tiles are always there on my Baltic map and I just haven't seen them before because when you use generate-sea=polygons you get polygons covering all of the map. But when you use generate-sea=multipolygon, there are no land polygons and so the lines show through from underneath. Now why they are there, I don't know at the moment (I don't think it's the fault of the MP code). However, there is still a problem in that with your v3 patch in place, I no longer get any sea polygons visible when I use generate-sea=polygons. I wonder if the change you made to the size of the sea polygons is responsible for that? Could you please change that code so that it only produces the over-large sea background when generateSeaUsingMP is true? Thanks, Mark

On 18/01/10 18:05, WanMil wrote:

Attached patch (against the mp branch) solves this.

OK thanks, applied. Is everyone happy that this is now a big improvement over trunk? ..Steve

Felix,

Please put the extend-sea patch also into the branch...

I am hoping that Ronny will provide a new version that includes the missing help blurb. Mark

Felix,

he did already. 4th message in the thread about the patch where he added some comments.

I can't see any addition to the help blurb in either OsmX... or the options file. Did I miss a post?

Anyhow I think that the behaviour should become default, cause so many people use geofabrik data (is there a need to not use it?).

I started adding options to generate-sea because I did not want to change the existing default behaviour. If this new option is to become enabled by default, we should have a "no-extend-sea-sectors" option to disable it. Mark

Hi Steve,

...

On 18/01/10 18:05, WanMil wrote:

...

Attached patch (against the mp branch) solves this.

OK thanks, applied.

Is everyone happy that this is now a big improvement over trunk?

It's performed well when processing the Baltic map.

One thought, and I may be completely wrong here because I haven't looked at the "spec" for multipolygon processing, but this new MP implementation seems to have a constraint that the inner polys can't touch the outer poly(s). Is that so? and is that reasonable? After all why is it not acceptable to have a MP like this:

.......*******..... .......*******..... .......*******..... ................... ...................

or even more interesting:

...........*........ ..........***....... .........*****...... ....................

i.e. the inner poly butts up against the edge of the outer?

Are those "naughty" MPs?

Mark

In the end I don't really care very much about what's the exact definition. There will be some mps that have touching polys. So we should try to implement it. The problem is the algorithm in the mp code that detects if a polygon contains another polygon. It works as follows: * Create a java.awt.Polygon class from p1 * Check if p1 contains the first point of p2 => This contains the first problem: The definition of the java.awt.Polygon.contains(..) method is a bit complicated (and not completely understood by me). The problem arises if a point lies on the boundary. To get more information about this study the class comment of http://java.sun.com/javase/6/docs/api/java/awt/Shape.html * Now the algorithm checks that no line of p2 intersects a line of p1. If p2 has an overlapping line with p1 this check fails and p1 does not contain p2 in the meaning of the mp code. => I think this could be easily improved. The algorithm is VERY simple. If anyone knows a good and speedy algorithm that checks if p1 contains p2 please post a reference to the algorithm so that we can implement it. WanMil