Resue: Rendering Issues

[Ludwig]

Right now we seem to have three issues with Rescue:

1. The wrong tiles being displayed sometimes. I have seen this and it certainly is a rescue/rewrite issue. My feeling is that incorrect tiles come from the cache, which would somehow mean that the cache is broken. 
2. A map area cut off after rotation that does not get repainted. I think the problem is that somehow a framebuffer for a vertical display is used on a horizontal display. (Funnily I have also seen this with Firefox).
3. Some tiles not being drawn. Since none of the code for rendering tiles changed at all in Rescue and we have seen similar problems with tiles with 'too much data' even in master, I have the feeling that this is not related to any Rescue change. This of course does not mean that it should not be fixed, but maybe someone else could have a look into it first. 

Since some of the issues are a little difficult to replicate, I am thinking of putting some more debug logging into the build and turning this on by default. There will be a setting to turn it off for those who already wanted to use Rescue in production, but for those of us who are just trying Rescue it will produce a better audit trail of what was actually happening.

We also need an issue tracker for Rescue. Can I for the moment suggest that we use email with descriptive subjects (rather than tagging onto other emails, it just makes it easier to track).

I think I will first look into the second issue here. 

Ludwig

[emux]

Hi Ludwig,
Just to inform you:

Another common rendering problem that exists also at master branch,
is about area fill with semi-transparent (color or png).
That shows tile border artifacts at zoom levels 12-13.

The relevant topic is at:
https://groups.google.com/forum/#!topic/mapsforge-dev/1TzknbgeJgo
where there is also an image example.

For the record:
The force-polygon-line=”true” at tag-mapping.xml seems to eliminate the problem.
But then the build process becomes very strict throwing a lot of:
WARNING: outer way of multi polygon is not a polygon, skipping it: WAY_ID
and the result map has cut polygons.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[emux]

Hi Ludwig,

There is also the issue with downloaded raster tiles and their scaling.
They most come at 256x256 pixels.

How about in AndroidBitmap.scaleTo method,
at android.graphics.Bitmap.createScaledBitmap,
use for "filter" parameter "true" as value (I think bilinear interpolation)?

Another idea is to allow the user to specify the tile size at AndroidGraphicFactory,
so using a TileDownloadLayer to be able to return to 256 at high DPI devices.
Now this is only possible if we try to reverse the size with:
AndroidGraphicFactory.INSTANCE.setUserScaleFactor(1 / getResources().getDisplayMetrics().scaledDensity)
and not directly calling setTileSize as it is private.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

On Saturday, December 14, 2013 4:28:02 AM UTC+2, Ludwig wrote:

[Ludwig]

Yes, you are right, the default tile size should be 256.

On 17 December 2013 01:42, emux <deve...@gmail.com> wrote:

Hi Ludwig,

I want to mention a circular reference between AndroidGraphicFactory and Tile classes,
affecting rendering tile size (which happened to me to keep increasing at application use).

At AndroidGraphicFactory we have
private final int defaultTileSize = Tile.TILE_SIZE;

But the Tile.TILE_SIZE is not anymore a constant but a variable,
which is set at setTileSize using itself (defaultTileSize) at calculation.

I think that the "256" value of Tile has to be fixed into a constant and used from there,
and can exist another variable that will hold the calculated tile size.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

On Saturday, December 14, 2013 4:28:02 AM UTC+2, Ludwig wrote:

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/4cae1d79-a949-4f2c-b829-986f4a47a3b9%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[emux]

Hi Ludwig,

I accidentally deleted my last post, but thankfully it exists at your answer.

I see at Samples app that the AndroidGraphicFactory is initialized
explicitly at startup and more specifically in an Application class.

Is this the only way?

I tried do the initialization at Activity's onCreate
and with each application restart the Tile.TILE_SIZE keeps increasing.
Apparently because of the mentioned reason of my last (deleted) post.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Ludwig]

Hi there, 

fixing the circular dependency is on my list, but I wanted to maybe do that in a refactoring that also renames the TILE_SIZE to comply with checkstyle and moves some general configurations into some sort of configuration file. So this will be a few days.

I think instantiating the AndroidGraphicsFactory inside the Application class is a safe way of ensuring that the AndroidGraphicsFactory is created exactly once at startup before any Activity. Android guarantees that to happen. 

Is creating an Application object any problem for you? I have similar code in production that has not caused any issues. 

Ludwig

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/26603a06-8d5f-4ef3-940e-9d50046f965d%40googlegroups.com.

[emux]

Not it is not any problem.
I just wondered if it can be initialized at another point,
since I don't use Application for other reasons.

But at Application class, it works fine.
I'll wait for the circular dependency fix and try again.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[emux]

Hi Ludwig,

I see that at Samples app in AndroidManifest.xml there is
android:hardwareAccelerated="true"

Where I try it at a Samsung S2 (4.1.2) the map has occasionally flashes when I move him.
This is most visible when I move him slowly with my finger.

But if I set hardware accelerated to false, the flashes seem to disappear.
Any thoughts on that?
Do we really need the hardware accelerated true?

[Ludwig]

Thanks for reporting this, I have noticed the flashes on 4.4.2 but I had no real explanation for them. I will try disabling hardware acceleration and see. 

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/815f2117-2d37-40a4-bd6c-bc9a58593562%40googlegroups.com.

[Christian Pesch]

Hi,

I was trying to chase issue 3. but found it hard to understand how this could happen. I started with adding debug output to MapWorker#renderTile(), LayerManager#doWork(), TileLayer#draw(), AwtCanvar#drawBitmap(), DatabaseRenderer#executeJob() but the only insight that I gained was that zoom level 8 and larger doesn't show the issue while zoom level 7 and below reproducibly omit the rendering of tiles,  

Please point me to some code places where I could start debugging.

Best regards

Christian

[Ludwig]

which map file are you using? 

This issue almost certainly has something to do with the zoom-interval-config, i.e. the grouping of data by the map file writer. The default configuration is 5,0,7,10,8,11,14,12,21, see https://code.google.com/p/mapsforge/wiki/GettingStartedMapWriter

This means that there are three intervals for which the data is stored inside the mapfile. So, with the default config there is an interval for all zoom levels from 0 to 7 and another one for 8 to 11, which would explain why you see the issue up to level 7, but not for 8 and above. It looks like the data stored for the 0-7 interval is somehow corrupted. I remember there was a discussion on this list a long while ago with similar problems for Holland(?) and the issue was that there was 'too much data' for that tile, causing somehow an overrun for the allocated space.

Quick Google: this must have been the issue: https://code.google.com/p/mapsforge/issues/detail?id=158

As a debug hint, you might want to look at the public MapReadResult readMapData(Tile tile) in the mapfile-reader: I assume that somehow you do not get any data back at that point. 

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/aa8c9469-2c51-428d-8f40-adc5f0646e42%40googlegroups.com.

[Christian Pesch]

I was using ftp://ftp.mapsforge.org/maps/europe/germany.map

Your hint was great: there is simply no data within the map file. I've reported this issue https://code.google.com/p/mapsforge/issues/detail?id=478 and stumbled over another issue report https://code.google.com/p/mapsforge/issues/detail?id=441 which claims that the ftp.mapforge.org data is outdated. It seems that one day someone generated new map files - but that was in July.

Is it possible to generate new map files periodically?

Kind regards

Christian

PS: To me it seems that rendering issue 3 is mostly related to the defective map files.

[Ludwig]

There is also the issue with downloaded raster tiles and their scaling.
They most come at 256x256 pixels.
How about in AndroidBitmap.scaleTo method,
at android.graphics.Bitmap.createScaledBitmap,
use for "filter" parameter "true" as value (I think bilinear interpolation)?
Another idea is to allow the user to specify the tile size at AndroidGraphicFactory,
so using a TileDownloadLayer to be able to return to 256 at high DPI devices.
Now this is only possible if we try to reverse the size with:
AndroidGraphicFactory.INSTANCE.setUserScaleFactor(1 / getResources().getDisplayMetrics().scaledDensity)
and not directly calling setTileSize as it is private.

I have set filter to true, which smoothes everything a bit. I am ambivalent if this actually improves readability of the scaled tiles (as the black/white transition around text gets a bit smudged). If the consensus is that the smoothing is actually detrimental, I am equally happy to reset this to false.

As both tile size and transparency are now passed down to the DownloadLayer, it is now possible to modify the url to request higher resolution images (should the source support this). I would be surprised if tile servers will not find a common way of supporting higher resolution imagery for retina displays, but at the moment there seems to be a bit of a 'that is your problem, not ours' attitude at at least some tile server providers: http://support.mapbox.com/discussions/tilemill/7637-512px-tile-size.

With the DisplayModel introduced it is possible to, at least indirectly, control the tile size. Unless this is considered insufficient control, I would suggest calling this issue solved on the mapsforge side.

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/9866c0d3-ceb0-482f-9e8b-b22bf9e6764e%40googlegroups.com.

[Ludwig]

This started this thread a while ago:

 

Right now we seem to have three issues with Rescue:

1. The wrong tiles being displayed sometimes. I have seen this and it certainly is a rescue/rewrite issue. My feeling is that incorrect tiles come from the cache, which would somehow mean that the cache is broken. 

1. A map area cut off after rotation that does not get repainted. I think the problem is that somehow a framebuffer for a vertical display is used on a horizontal display. (Funnily I have also seen this with Firefox).

1. Some tiles not being drawn. Since none of the code for rendering tiles changed at all in Rescue and we have seen similar problems with tiles with 'too much data' even in master, I have the feeling that this is not related to any Rescue change. This of course does not mean that it should not be fixed, but maybe someone else could have a look into it first. 

#2 has been fixed, I hope.

#3 is a problem in the map file generation, not in the display: where the tiles are empty there is simply no data in the map file. 

#1 I have not been able to reproduce. I have seen this on one occasion myself, so the issue exists. My hunch at the time was that it might be left-over tiles in the file system cache. If someone has any suggestion on how to reproduce it, please let me know, without a starting point it is impossible to track this down.

#4 was:

Another common rendering problem that exists also at master branch,
is about area fill with semi-transparent (color or png).
That shows tile border artifacts at zoom levels 12-13.

I think this is also impossible to fix as it results from the design of the map file that tiles data. The 'tiles' in the map file correspond to tiles at certain zoom levels with polygons clipped to the tiles. When compositing the data it is then unknown if the polygon naturally clipped at the tile boundaries or if this was introduced through the tiling process. In an ideal world, of course the renderer could look across to the next tiles, see that the same type of way is there and then refrain from drawing a polygon boundary along the tile lines, but in the real world we are processing one tile at a time and do not have the resources to check each polygon against all polygons on the next tiles. 

The only practical solution I see is simply not defining outlines for such polygons.

So, apart from #1 rendering issues have been resolved as far as is possible.

Ludwig

[emux]

Hi Ludwig,
 

As both tile size and transparency are now passed down to the DownloadLayer, it is now possible to modify the url to request higher resolution images (should the source support this). 

With the DisplayModel introduced it is possible to, at least indirectly, control the tile size. Unless this is considered insufficient control, I would suggest calling this issue solved on the mapsforge side.

Can you clarify a bit how tile size is passed down to TileDownloadLayer ?

TileSource interface has hasAlpha which we must implement at custom tile sources.

But for the tile size, do you mean we have to set at TileDownloadLayer a DisplayModel with
displayModel.setUserScaleFactor(1 / AndroidGraphicFactory.getDeviceScaleFactor())
in order to reverse back from device scale factor to the original 256 tile size?

[emux]

Hi,

#4 was:

Another common rendering problem that exists also at master branch,
is about area fill with semi-transparent (color or png).
That shows tile border artifacts at zoom levels 12-13.

I think this is also impossible to fix as it results from the design of the map file that tiles data. The 'tiles' in the map file correspond to tiles at certain zoom levels with polygons clipped to the tiles. When compositing the data it is then unknown if the polygon naturally clipped at the tile boundaries or if this was introduced through the tiling process. In an ideal world, of course the renderer could look across to the next tiles, see that the same type of way is there and then refrain from drawing a polygon boundary along the tile lines, but in the real world we are processing one tile at a time and do not have the resources to check each polygon against all polygons on the next tiles. 

The only practical solution I see is simply not defining outlines for such polygons.

For the record, I copy here a proposition regarding the map creation from the relative topic:
"On zoom levels 12 and 13 tile images are created by rendering geometries from zoom level 14 (this is the default zoom-interval-conf setting).
Since geometries are clipped to tile boundaries, the clipping lines become visible when rendering on lower zoom level tiles.
To avoid this you could create the map file such that no tiles are rendered using higher zoom level geometries."

[Ludwig]

The TileDownloadLayer has a display model, that gives you the requested tileSize. This could be passed to the tileSource.

But for the tile size, do you mean we have to set at TileDownloadLayer a DisplayModel with
displayModel.setUserScaleFactor(1 / AndroidGraphicFactory.getDeviceScaleFactor())
in order to reverse back from device scale factor to the original 256 tile size?

You can call setDisplayModel() with something akin to the FixedTileSizeDisplayModel that is defined in test. (Admittedly this is not tested).

public class FixedTileSizeDisplayModel extends DisplayModel {

private int tileSize;

public FixedTileSizeDisplayModel(int tileSize) {

this.tileSize = tileSize;

}

@Override

public int getTileSize() {

return tileSize;

}

}

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/c716c30b-a4d5-4fd9-884a-67b1614968ea%40googlegroups.com.

[Tobias]

Hi Ludwig and everyone,
Thanks a lot for your efforts on rescueing mapsforge! Looks quite good as far as I can see.

I have designed a theme for openandromaps/mapsforge called Elevate (http://www.openandromaps.org/kartenlegende/elevation-hike-theme) in which I invested some time, so I got some experience with the obstacles and bugs involved with it. As I have no programming experience I just can report some bugs or wishes which would make this easier (not just for me).

I managed to use your sample.apk with my theme (for those who are interestet: unzipping apk, replacing the files in the osmarender\ directory with PNG-folder and Elevate.xml renamed to osmarender.xml, zipping again to apk, use zipsigner from play store on it, install apk). It would be great to have an easier way to use external themes, maybe I missed it.

One problem with mapsforge 0.3 which still exists are multipolygons with Island within a hole: http://wiki.openstreetmap.org/wiki/Multipolygon#Island_within_a_hole
Maybe it's an issue with mapwriter, but it can be quite ugly looking:
https://lh5.googleusercontent.com/-jyrDWen4Swc/UsxZRb-PJsI/AAAAAAAAADs/6u2NIVfTqCc/s1600/island.png
It happens if in a mp is an inner area which contains an outer area of the main mp. Maybe it's also related to the inner area being bigger than a tile. My solution for the moment was to fix this by removing the inner island from the mp in OSM if I found one, but that no real solution.
As I fixed all those spots that I know of there isn't any point in OSM right know, but in the current version of Bayern at Openandromaps the problem is still existent at this point: 47.703225, 12.77955
If it's a problem with mapwriter one should just add this http://www.openstreetmap.org/relation/3397699 to this http://www.openstreetmap.org/relation/1713021 as outer again for testing.

A smaller issue with rescue: there seem to be some small displacements going on at tile borders which weren't visible in 0.3, this is best visible at contourlines, marked in the picture with green arrows, also in comparison to the rendering in Oruxmaps/0.3:
https://lh4.googleusercontent.com/-1It1TyiGeF8/UsxgXflqzOI/AAAAAAAAAD8/MgvFMeCbjxk/s1600/displacements.png
At lower zooms it even looks like borders at some places. Maybe it's also related to the next issue.

Borders of areas which are bigger than tiles are getting rendered on tile borders at certain zoom levels. This was also an issue with 0.3, but now it's even bigger. I managed to work around it with protected areas to not use borders till Zoom 13, but this is no longer working as you can see in this picture:
https://lh3.googleusercontent.com/-jFfkNadZXT8/UsxisILm6QI/AAAAAAAAAEI/tDqIUXYKFEE/s1600/borders.png
One workaround was to use force-polygon-line="true" in mapwriter, but that can't be done if you want to fill the area and not just render the border as with protected areas here.

Another issue, maybe a wish: with symbols you can, more or less, set priorities which is rendered preferably, in putting the rule higher up in the theme. With captions on nodes (as with place=city/town etc.) this isn't really working, it just seems random and doesn't matter where the rule is placed. It just seems dependent on the size of the caption, and that's even worse - larger sized captions for city names aren't rendered because smaller sized ones for suburbs are rendered. I don't know if there's an easy solution for this. Something like this is also happening with peaks, but I don't think there would be any other solution as to prefer to render peaks/volcanoes with higher ele programmed into mapsforge as theming doesn't allow anything like that.

Caption is also an issue in areas: they are rendered very often in a larger area, which looks ugly and wrong, probably also in connection with tiles. That's a reason why Christian has to calculate "Poly-Nodes" for the most important ones as lakes (which aren't named in osmarender.xml at all).


Now some wishes, from important to not so much :-)

dy on areas: Lot's of point of interests are no longer just nodes, often they are tagged on the way oft a building. With mapsforge it's only possible to view either a symbol or a caption on a way. It would be great to have working dy on areas too, so for example I can make alpine hut symbols and captions look the same, and it doesn't matter if it's mapped to a node or a way. I made a bug report for that here:
http://code.google.com/p/mapsforge/issues/detail?id=466

positive dy orientated on topline of caption (or dy caption multiplication): one thing you can see in the displacement picture is also that the elevation isn't rendered in the sample.apk screenshot, but in the Oruxmaps one. That happens because sample.apk uses a larger font multiplicator, and if the topline of a caption touches a symbol it isn't rendered in mapsforge. That makes it hard to design themes which work on hdpi and mdpi devices, as positive dy values have to be either huge which looks bad on mdpi, or you have to make different dy's for different font multiplicators. One solution would be to use the topline of a caption for positioning with positive dy's (and bottomline as it is with negative), so that if you use a bigger multiplicator the captions won't touch the symbol. Or that with font multiplicators dy's for captions are multiplied too.

startoffset and others on pathText: in Osmarender there are some options which would be really valuable to have in mapsforge:
http://wiki.openstreetmap.org/wiki/Osmarender/Rules#.3CpathText.3E
If there are several texts to render on a path, for example the hiking route ref and the street name, they can only be rendered atop each other. Something like text-anchor, startoffset or dy would help here!

dy on lines: at the moment all lines are perfectly aligned around the original line. it's not possible to draw two parallel lines on a way, which would be really useful for tunnels, for example dy=-5 for the first line and dy=+5 for the second. or if you have hiking/cycle routes you could draw a slightly offset line next to the highway it belongs to.


So that's all I have on my plate for now, which would make designing themes easier and the maps more accessible and professional looking.
I hope you have the time to look into some of this, and thanks again for all your efforts!

Best regards,
Tobias

[emux]

Hi Tobias,

I have designed a theme for openandromaps/mapsforge called Elevate (http://www.openandromaps.org/kartenlegende/elevation-hike-theme) in which I invested some time, so I got some experience with the obstacles and bugs involved with it. As I have no programming experience I just can report some bugs or wishes which would make this easier (not just for me).

I use already Elevate render theme, it's very nice work!
 

I managed to use your sample.apk with my theme (for those who are interestet: unzipping apk, replacing the files in the osmarender\ directory with PNG-folder and Elevate.xml renamed to osmarender.xml, zipping again to apk, use zipsigner from play store on it, install apk). It would be great to have an easier way to use external themes, maybe I missed it.

You can use Cruiser, a map/navigation application using mapsforge 0.3.1-snapshot (backwards compatible with 0.3.0).
It has map file chooser and render theme file chooser.
Cruiser Beta is about to be updated with mapsforge rewrite rescue.

Can I ask you, from your experience, what's your opinion about the issue I mention at:
https://groups.google.com/d/msg/mapsforge-dev/IZ8Ctnmwuv0/twAniVG2sDAJ
There exists the original topic with image example of the problem.

[Ludwig]

Thanks for the long list of rendering issues. 

Overall, IMHO there are different causes for the problems:

1. Bugs in OSM data (lots of invalid polygons exist)
2. Problems with OSM labelling (lots of very differently sized places labelled 'city')
3. Problems with the map file writer (like data overflows and problems handling nested polygons, tiling artifacts).
4. Rendering issues on the client side.

As far as I am aware, there were not actually any changes from master to Rewrite and I have not touched the rendering or tile algorithms at all. I do notice the differences that you point out (like in the contours image) but I have no real explantation for them. If you could produce a small map file (a cut around the area you see the problems in), both with binary file and osm input file, that would help to investigate this.

I have not yet looked at the relations you mention, but in the past also invalid OSM data has been the source of errors. The main cause were polygons that were self-intersecting. These fail a validation and are then not included, but JOSM reported these polygons as valid. One solution, which I am not sure if it made it into the source tree, is to perform a buffer(0) operation around invalid polygons (this essentially takes the outline, removing the offending intersections). Another problem had been rounding errors where non-rounded data produced valid polygons, but the rounding introduced the dreaded self-intersections. 

City labels often disappear because the OSM data denotes smaller and large cities as 'city' or 'town'. There is actually a preference for 'city', but if two very different sized cities are labelled the same, it is impossible for mapsforge to know which one has preference: it is a bit a problem with the Euro-centric label system in OSM. I have worked around the worst offenders by patching the OSM data (or even fixing OSM in a case where some missionaries had labelled their village headquarter in South America a city). In some cases results could be improved if the mapfile writer would take tags like 'capital' into account, but I fear that the rules will simply become too complex and might cause detrimental changes elsewhere. The collision detection algorithm in the renderer then causes the apparently random behaviour which labels are rendered.

For a while an osmosis plugin existed, called something like area2point, that converted areas into an additional point. That was quite useful for the problem you described with the buildings. The plugin does not work any more with current osmosis, but it might simply be a problem of adjusting it to the new osmosis plugin architecture (which would be preferable to a change in the mapfile writer).

About this time last year I had a discussion with Thilo about his plans for Rewrite. He was aware of many of the labelling problems and said they were a key reason for changing to the Rewrite architecture. The real way forward would be to not tile the labels, but to draw them on top in one untiled layer. That way the labelling algorithm could avoid things like the multiple labelling of lakes etc. Another effect would be that it would be possible to rotate the map layer (but not the labels).

On the render theme front, it would require a new XSD. Since you have spent a lot of time thinking about it, can I suggest that you have a look at rendertheme.xsd and come up with the changes required: best in a way that it would be backward compatible, so adding rather than removing attributes etc. Then we could discuss this here on the list and come up with an implementation plan.

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/cc4a68f5-a161-4f3a-a25a-f76df56add21%40googlegroups.com.

[Tobias]

Hi Emux,
thanks for your kind words. I still have to really test Cruiser, haven't got around it except of once starting it. But having rescue in beta sounds promising.

Can I ask you, from your experience, what's your opinion about the issue I mention at:
https://groups.google.com/d/msg/mapsforge-dev/IZ8Ctnmwuv0/twAniVG2sDAJ
There exists the original topic with image example of the problem.

I think it's the same bug as the one I described in the the paragraph "Borders of areas". In mapsforge 0.3 it was only at Zoom 12-13, but now with rescue it's at different zooms as well. It's not only with semi-transparency but with all kind of borders of closed areas, if the borders are thicker than a certain value. As you and I mentioned it doesn't happen with force-polygon-line="true" because than those borders behave like ways and not areas.

Best regards,
Tobias

[Tobias]

Hi Ludwig,
thanks for your fast response! As I wrote I'm not a developer so I don't got everything you wrote, but I try.

Overall, IMHO there are different causes for the problems:

1. Bugs in OSM data (lots of invalid polygons exist)

Those aren't the causes here. I know quite well issues with intersections etc., but this is valid OSM mapping which mapwriter isn't rendering right. Just have a place where http://wiki.openstreetmap.org/wiki/Multipolygon#Island_within_a_hole is happening, probably with "holes" that are crossing tile borders, and we have the effect as shown in the example. So it's correct mapping but defect rendering, probably cause 3.

1. Problems with OSM labelling (lots of very differently sized places labelled 'city')

I didn't mean this. I meant that with symbols that if I put a rule1 with symbol1 in the theme.xml above another rule2 with a symbol2, and there are two nodes close to each other with rule1 and rule2, rule1 is always rendered first if there isn't enough space to render both rules. If I do the same with a caption, for example place city-rule above suburb-rule, this isn't the case. Here it seems only the size of the space the caption will take is taken into account, and not the position of the rule in theme.xml. I would like to have a possibility to have rules which are coming first in render.xml also be executed first.
If a tag is wrong is not the point, even a falsely tagged city should be rendered first because it's placed above suburbs in theme.xml - which it isn't at the moment.
 

1. Problems with the map file writer (like data overflows and problems handling nested polygons, tiling artifacts).
2. Rendering issues on the client side.

As far as I am aware, there were not actually any changes from master to Rewrite and I have not touched the rendering or tile algorithms at all. I do notice the differences that you point out (like in the contours image) but I have no real explantation for them. If you could produce a small map file (a cut around the area you see the problems in), both with binary file and osm input file, that would help to investigate this.

I will forward this to Christian who creates the maps, I'm just into theme-design. But I think those glitches in the contours Image are probably everywhere, it's just easily visible in contours.
 

 The collision detection algorithm in the renderer then causes the apparently random behaviour which labels are rendered.

And that would be great if there would be a possibility to influence that by theme design, Locus does that with additional tags in their mapsforge version:
http://docs.locusmap.eu/doku.php/manual:vector_maps_theme_config
 

For a while an osmosis plugin existed, called something like area2point, that converted areas into an additional point. That was quite useful for the problem you described with the buildings. The plugin does not work any more with current osmosis, but it might simply be a problem of adjusting it to the new osmosis plugin architecture (which would be preferable to a change in the mapfile writer).

So that would have to be dealt at map writing stage, and it would create nodes additonally to ways/buildings, right? So that's what Christian does with poly-nodes already, but only for a view things.
 

About this time last year I had a discussion with Thilo about his plans for Rewrite. He was aware of many of the labelling problems and said they were a key reason for changing to the Rewrite architecture. The real way forward would be to not tile the labels, but to draw them on top in one untiled layer. That way the labelling algorithm could avoid things like the multiple labelling of lakes etc. Another effect would be that it would be possible to rotate the map layer (but not the labels).

Sounds promising, are there any plans to include this in rescue?
 

On the render theme front, it would require a new XSD. Since you have spent a lot of time thinking about it, can I suggest that you have a look at rendertheme.xsd and come up with the changes required: best in a way that it would be backward compatible, so adding rather than removing attributes etc. Then we could discuss this here on the list and come up with an implementation plan.

OK, I will look into it! Thanks a lot.

Best regards,
Tobias

[Maki]

Il giorno mercoledì 8 gennaio 2014 11:42:46 UTC+1, Ludwig ha scritto:

On the render theme front, it would require a new XSD. Since you have spent a lot of time thinking about it, can I suggest that you have a look at rendertheme.xsd and come up with the changes required: best in a way that it would be backward compatible, so adding rather than removing attributes etc. Then we could discuss this here on the list and come up with an implementation plan.

I already made a proposal on the issue tracker for the priority problem.

https://code.google.com/p/mapsforge/issues/detail?id=476

and another one that would help giving the user the ability to control what is shown

https://code.google.com/p/mapsforge/issues/detail?id=474 

[emux]

Hi Ludwig,

I see from the code that the dy parameter at caption is not scaled.
Does it need to be scaled?

Considering that when we use svg then the symbols are scaled
and their size probably will not fit with fixed dy value for a caption.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

On Saturday, December 14, 2013 4:28:02 AM UTC+2, Ludwig wrote:

[Tobias]

I think scaling dy is a great idea, as this is one of the headaches at the moment if you want to use a theme on a device with different dpi and therefore different symbol and font size.
Best regards,
Tobias

[emux]

Hi Tobias,

positive dy orientated on topline of caption (or dy caption multiplication): one thing you can see in the displacement picture is also that the elevation isn't rendered in the sample.apk screenshot, but in the Oruxmaps one. That happens because sample.apk uses a larger font multiplicator, and if the topline of a caption touches a symbol it isn't rendered in mapsforge. That makes it hard to design themes which work on hdpi and mdpi devices, as positive dy values have to be either huge which looks bad on mdpi, or you have to make different dy's for different font multiplicators. One solution would be to use the topline of a caption for positioning with positive dy's (and bottomline as it is with negative), so that if you use a bigger multiplicator the captions won't touch the symbol. Or that with font multiplicators dy's for captions are multiplied too.

Do you mean that at both Android and Java, the positive dy would be measured
till the ascent of the caption's font and not the baseline as it appears to be now?

This calculation may be needed to be made early at code,
as the dy is used prior the drawing for the collision detection of symbols / labels.

[Tobias]

Yes, that would help a lot. With that when larger fonts or multiplicators are used the baseline would move down and the caption isn't eliminated.
Now dy when positive is dependent on symbol and caption size, when negative only on symbol size, which isn't consistent.

[Maki]

I see from the code that the dy parameter at caption is not scaled.
Does it need to be scaled?

Yes, yes, yes! :-)

But what about making dy unnecessary? It's just a random thought, but what if we just indicate the placement of the label (top/bottom)? It will automatically adjust to symbol size, if there is more than one label the second one is placed below or above the other.

Maki.

[emux]

But what about making dy unnecessary? It's just a random thought, but what if we just indicate the placement of the label (top/bottom)? It will automatically adjust to symbol size, if there is more than one label the second one is placed below or above the other.

+1

I think that wherever we can avoid fixed values and instead use relative placements, it's better.

[Tobias]

Yes, yes, yes! :-)

But what about making dy unnecessary? It's just a random thought, but what if we just indicate the placement of the label (top/bottom)? It will automatically adjust to symbol size, if there is more than one label the second one is placed below or above the other.

Maki.

What captions at symbols are concerned: +1

With circles dy is also valuable, for example I put motorway_junction number in a circle, but it needs (at the moment) dy to properly align. Maybe that's a momentary solution of a different problem, that captions and circles have different starting points (bottom line vs. center).
I think one solution for that would be to make rendering more consistent: position caption always around a central point starting at the middle line (not top or bottom). Like this they would behave as every other element and more consistent.