Hi Steve,

Hi

I have a map of the UK with sea (using --generate-sea=extend-sea-sectors)

This is much better than the last time I tried as it was faster and there is no flooded land.

I do get a lot of horizontal and vertical artefacts when zoomed out that go away when I zoom in.

I assumed that Mark's patch would be the cure for that, but it doesn't appear to make any difference.

Is that right or am I missing something?

..Steve

My patch doesn't fix the H & V artifacts - I believe those are caused by mapsource (they also appear in maps made with cgpsmapper). Sometimes they go away just by panning (without zooming). What my patch does do is remove the "slim triangles" that occur at the junction of polygons. Using the new mp code, I have just made the Baltic map both with and without my patch and I can assure you it is effective in reducing the number of artifacts. It's a shame that the artifacts are so visible in the sea. Although I think the new mp code is a great step forward, I shall keep using generate-sea=polygons simply because the H & V artifacts are less visible (as they are now on the land and not the sea and with a light background colour, they are not so noticeable). Also, when using polygons, the lines at the tile boundaries are covered up. Mark

On 19.01.2010 00:50, Mark Burton wrote:

Also, if you compare our sea with, say, the NZ open GPS map (built using cgpsmapper), there's a lot more artifacts in the NZ map than there is now in our maps (either using polygons or multipolygon).

And in response to what Felix has just posted, the NZ maps support routing across multiple tiles in mapsource. I was intrigued to know if our packaging (overview map, tdb, etc.) was causing our maps to fail to route across multiple tiles so I built a map using mkgmap that used the tiles from the NZ map. And guess what, mapsource could route just dandy. So it's not our overview map or tdb that's stopping the multi-tile routing in mapsource, it's something in the tiles (.img) files that's wrong.

Sorry for not being very clear. I think the routable overview map would only be used for very long distance routing. So route from tile onto overview map (motorways/trunk_roads/primaries/ferries only) to destination, continue on normal map. I think the overview map is only used if Mapsource cannot route using the normal tiles (e.g. setting avoid highways with City Navigator maps and trying to route from Poland to Portugual ). The main reason for overview map with roads would be to have faster map panning when zoomed out in Mapsource. I hope that once we have no more overlap, map redraw speed also increases (and less flashing up in Mapsource when zoomed out far - if you know what I mean). Well I'm open for testing if new patches come....

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

I have never seen it so bad. The lines should ONLY appear on tile boundaries. Now please don't tell me those are all tile boundaries ??? I'll send a screenshot of how the whole Oceania extract looks on my PC in around 15-20 minutes (just kicked in the compiler, last compile was still without sea). On 19.01.2010 00:59, Steve Ratcliffe wrote:

Hi Mark

...

My patch doesn't fix the H& V artifacts - I believe those are caused by mapsource (they also appear in maps made with cgpsmapper).

Oh OK, I've attached a picture of the worst bit - that is expected then?

I took another look at the NZ maps on your suggestion and there are indeed a few artefacts there which look similar. Interesting. If there is no obvious reason, then reducing the number of sea polygons would be a good idea I suppose.

..Steve

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On 19.01.2010 01:05, Steve Ratcliffe wrote:

Hi Felix

...

I have never seen it so bad. The lines should ONLY appear on tile boundaries. Now please don't tell me those are all tile boundaries ???

No they are not tile boundaries, they are boundaries between sea polygons.

It is the worst area, most of the map is much better than that.

..Steve

Never seen such errors, on the other hand I just tried --generate-sea,polygons,extend-sea on australia-oceania and the result is more or less no sea at all. I believe the problem here is however, that NZ is too far away from Ozi. Therefore the map gets splitted badly. I have attached a pic (sorry that it is so big but this is already using "highes" detail in Mapsource, still only 21 KB)

Steve,

Oh OK, I've attached a picture of the worst bit - that is expected then?

Hmm, that's particularly bad, attached is what I get when using multipolygon (and my h v patch). As you can see, not bad at all. Zooming in and out doesn't make it change very much.

I took another look at the NZ maps on your suggestion and there are indeed a few artefacts there which look similar. Interesting. If there is no obvious reason, then reducing the number of sea polygons would be a good idea I suppose.

Perhaps, but when there is a lot of islands, you are always going to get a lot of sea polygons. That is one definite advantage of using generate-sea=polygons because then you only get one polygon per island and one sea polygon per-tile (obviously, these may be split if they are large). Mark

Hi Mark

Hmm, that's particularly bad, attached is what I get when using multipolygon (and my h v patch). As you can see, not bad at all. Zooming in and out doesn't make it change very much.

All (or almost all at least) of the lines I see go away when I zoom in. In gpsmapedit, I don't notice any gaps between the polygons at any level. I'll take a closer look tomorrow.

Perhaps, but when there is a lot of islands, you are always going to get a lot of sea polygons. That is one definite advantage of using

On Garmin maps there are not that many polygons as they surround the islands. ..Steve

Steve,

Does this splitting happen at the generate sea stage or is it being mangled later on?

It's done by the new mp code. Mark

On 19.01.2010 00:26, Steve Ratcliffe wrote:

Hi

I have a map of the UK with sea (using --generate-sea=extend-sea-sectors)

This is much better than the last time I tried as it was faster and there is no flooded land.

I do get a lot of horizontal and vertical artefacts when zoomed out that go away when I zoom in.

I assumed that Mark's patch would be the cure for that, but it doesn't appear to make any difference.

Is that right or am I missing something?

No, I think there is simply still some work missing. I would use --generate-sea=polygons,extend-sea-sectors, I think it gives better performance in Mapsource or GPS (please speak up stranger if you had time to really compare and tell if it is advisable to use or not). IMHO the main problem is here that mkgmap still has no decent overview map (ideally we would have a non empty overview map). My top3 of what mkgmap still is missing or doing wrong: 1. Address Search only working in Mapsource (or inside active tile on "old generation" GPS) 2. Overview map empty and a bit incorrect 3. Routing over tile boundaries in Mapsource -if solved the overlap should not be needed (size decrease). Once 1-3 are implemented, mkgmap has no more disadvantages at all compared to cgpsmapper pro (costing big $$$$), and many many advantages. It really shows how successful open source is. BTW - I would have guessed that sea polygons will still take ages until correctly implemented (on the other hand I thought 2-3 month ago it will only be a matter of days until address search works not only in Mapsource but also on GPS correctly). In my opinion less important/major things to get right: # transliterations (there seems to be some good work according to the osm forum mkgmap section) # coping better with contourline maps (e.g. some possibility to get rid of those long straight lines that happen on data holes) # using units. most importantly make it possible to calculate from miles to kilometers, from feet to meters... (would be enough if one could have multiplication with factors in style-file). # I'll certainly have more ideas/wishes once the above is implemented.