From jjbross@gmail.com on January 15, 2012 05:57:43

Thanks for reporting this issue. Please provide the version number of the mapsforge library which used for testing.

From thilo.mu...@gmail.com on February 11, 2012 05:41:28

Owner: jjbross@gmail.com

From jjbross@gmail.com on February 23, 2012 12:09:15

Is this issue still valid? Reporter has not replied with requested information.

From mirarki...@gmail.com on February 23, 2012 23:17:50

This no longer seems to be an issue - or the maps have been updated where I spotted it.

It was here, for instance, which now is rendered with amenity=school covering the actual building, that'll be another bug (?): http://www.openstreetmap.org/?lat=60.622627&lon=15.623472&zoom=18&layers=M I saw an issue with multipolygons not joining correctly though, I'll post that in a separate report.

Attachment: multipolygon3.png

From mirarki...@gmail.com on February 23, 2012 23:21:56

Actually, I'll take that back. That building actually isn't rendered, and my other testcases have gotten landuse=forest in the outer polygon. This is the latest versions from the site (writer and viewer, 0.2.4) and a late Locus as well.

From mirarki...@gmail.com on February 23, 2012 23:23:33

That means that one of the cases,

outer: landuse=forest
inner: *
multipolygon: *

works, but not

outer: -
inner: *
multipolygon: building=yes

?

From jjbross@gmail.com on February 24, 2012 09:34:51

please test with latest SVN version, I guess this is a duplicate of issue188

From mirarki...@gmail.com on February 25, 2012 07:20:59

I can't test with the latest svn version. The mapfile-writer 3.0.0 creates a map that isn't compatible with any app I can run, and I haven't got the faintest on how to build a new AdvancedMapViewer. If you can point me to a compiled .apk for the map viewer I can test.

From thilo.mu...@gmail.com on March 03, 2012 12:08:20

The AdvancedMapViewer is not yet a maven project but just an ordinary Android project for Eclipse, which you can check out from our SVN repository. You will find it in the following directory: trunk/Applications/Android/AdvancedMapViewer

You will need to install the Android SDK for Eclipse. To build the rest of the mapsforge project with maven, please follow the instructions on the GettingStartedDevelopers wiki article.

From LudwigBr...@gmail.com on March 04, 2012 03:08:40

I have just stumbled over what I think is an instance of this problem. Both reader and were built with r1856 , the viewer was the AdvancedMapViewer.

The area in question is a river area in Warsaw, Poland.

This is a view on OSM: http://www.openstreetmap.org/?lat=52.2533&lon=21.0261&zoom=15&layers=M I think the relation in question is #215712, but there might be others involved. It is a complicated relation and while it shows correctly on OSM.org, the data itself might be flawed.

Attached are a two screenshots which show that somehow polygon creation is going totally wrong.

Attachment: 1856-warsaw.png 1856-warsaw-2.png

From mirarki...@gmail.com on March 04, 2012 23:25:35

You couldn't point me to a built AdvancedMapViewer, could you? I'm not an Android developer, so I don't have the infrastructure or the time to set it up.

But the same thing probably happen to all major rivers, lakes and oceans?

From LudwigBr...@gmail.com on March 05, 2012 04:20:06

Just tested this with r1881 , the more northerly area of the river now appears correct, but the river part south of it is missing. Screenshot attached.
Sorry, right now in area with very poor internet connection, so cannot investigate further.

Attachment: 1881-warsaw.png

From LudwigBr...@gmail.com on March 21, 2012 04:21:11

Another instance of this, this time in central Rome. This shows a regression in the 3.x library against 2.4. I have not investigated this further, but I think the cause is probably the same. The 2.4 map was done with r1413 , the 3.0 with r1975 .

Attachment: rome-1413.png rome-1975.png

From LudwigBr...@gmail.com on March 21, 2012 06:11:42

I think the problem for Rome is relation #5071.
See http://www.openstreetmap.org/?lat=41.89859&lon=12.46618&zoom=16&layers=M

From LudwigBr...@gmail.com on March 22, 2012 00:06:10

I investigated this a bit further and played around with the mapfile writer, particularly the way relations are handled. The unfortunate fact is that OSM contains a lot of invalid data. The mapfile writer ignores all relations that have invalid data, even though in some cases this is just an inner polygon that is not correctly closed. In this case the entire relation is ignored, leading to very obvious rendering errors.

One experiment I made was to ignore the errors in the polygons and just continue on. In BaseTileBasedDataProcessor.java I commented out the returns like this:

        // skip invalid relations
        if (!this.polygonizer.getDangling().isEmpty()) {
            LOGGER.fine("relation contains dangling ways which could not be merged to polygons: "
                    + relation.getId());
            //return true;
        } else if (!this.polygonizer.getIllegal().isEmpty()) {
            LOGGER.fine("relation contains illegal closed ways with fewer than 4 nodes: " + relation.getId());
            //return true;
        }

The result is that the river section that disappeared previously is now rendered. It is certainly not rendered entirely correctly, but the main features appear, which I think is a better solution. Screenshot is attached.

I think there is a case of a 'best effort' rendering that tries to render something even though the underlying data is not correct. Maybe the behaviour could be controlled by a command-line switch, which would help to make differences clear and help quality control.

Some food for thought.

Attachment: rome-1975m.png

From vshpi...@gmail.com on March 27, 2012 00:05:10

Can you please advise on other tweaks to map-writer code from your experiments on this matter? I've attached a screenshot of New York map, AMV is built from 0.3.1 snapshot, as well as the map-writer, the "return true" lines were commented out.
PBF from Geofabrik was used, --bp completeWays=yes(tried without this option and with clipIncompleteEntities=true).

Attachment: device-2012-03-27-003123.png

From jjbross@gmail.com on March 28, 2012 12:45:22

I have added a boolean parameter 'skip-invalid-relations' to the map writer which controls whether relations that contain invalid data are added to the map file or not.

From jos...@gmail.com on April 11, 2012 00:20:45

Not really sure, if it is related, but I'm having similar issue with multipolygon rendering. I've attached a file, how the map is rendered, here's a link to actual location in OpenStreetMap: http://osm.org/go/0lP6wSgl-- .

Attachment: vilnius-draw-error.png

From LudwigBr...@gmail.com on April 11, 2012 06:30:26

I have seen this problem in Vilnius, but I am not sure if this is the same issue. It was actually present in pre 0.3 maps, albeit in slightly different form.

I tried to investigate it a bit, but gave up due to time constraints. I am just sharing here what I remember on top of my head.

The river here is made of a multipolygon with several riverbank stretches. It renders correctly in the standard OSM Mapnik renderer (which is extremely forgiving when it comes to bad data), but at least in the version that I investigated a few months ago also rendered incorrectly in the Merkaartor OSM editor.

What somehow happens is that instead of taking the longer way along the actual riverbank, the particular stretch of riverbank was drawn as the shortest line between two end-points of riverbank ways and thus the river overflows in the bend. (The same seems to happen in the lower left corner of your image as well).

At the end I was not sure if this was a OSM data problem (relations are hard to understand) or a borderline case where relation data is somehow misinterpreted by Merkaartor and mapsforge.

Maybe this is a directional problem that the overflowing stretch has the wrong direction and thus the endpoints are incorrectly matched.

From thilo.mu...@gmail.com on August 09, 2012 10:07:34

Issue 345 has been merged into this issue.

Mapsforge has changed a lot since then, can create new issue if still valid.