Symbol / Text placement (Mapsforge & TileMill)

[Emux]

Lately I had the chance to work with TileMill in order to create some online raster maps.
So I I studied its render API and found quite a few properties that can be applied to map elements,
that would be useful to have them also at mapsforge.

Comparing a TileMill raster map and its equivalent Mapsforge vector map
the most missing feature (from user reports) is the flexibility at symbol and text placement.
Specifically allow the render theme creator to specify if a symbol or a label can overlap or not.

I think we cannot do it right now, any thoughts for that?
If we find difficult to implement the allow-overlap feature per symbol or label,
then it would be still useful to control overlap centrally for the entire render theme.

Allow for overlapping symbols or text:
https://www.mapbox.com/carto/api/2.3.0/#marker-allow-overlap
https://www.mapbox.com/carto/api/2.3.0/#text-allow-overlap
Or
https://www.mapbox.com/carto/api/2.3.0/#marker-ignore-placement

--
Emux
Cruiser - Atlas

[Maki]

I haven't tried TileMill yet but their showcase is impressive. I see they use CSS. I recently started porting Tiramisù to mapcss for JOSM and that made me remember how powerful and readable CSS are, some things are so much simpler than Mapforge's XML (but not everything).

Anyway,yes you are right, symbol/text placement is somewhat of an issue. I had already proposed a priority mechanism https://code.google.com/p/mapsforge/issues/detail?id=476

Other than the collision management there is the slightly different problem of multiple icons for the same node (pizza, restaurant, hotel in the same building for example). In this case it would be nice to stack the icons and expand the stack on user tap (think about how folders work on launchers).

Another partially related issue is linesymbols not being shown until very high zoom levels. I don't know exactly how it works, but I have the impression that unless there is a segment long enough to fit it the symbol is suppressed, which makes no sense. I think this should be solved, if possible already in 0.4.x.

BUT, all this is meaningless until the tile border on closed ways bug isn't solved. It can't happen. Not on highways (see attachment).

Best regards,

Maki.

[Emux]

I haven't tried TileMill yet but their showcase is impressive. I see they use CSS. I recently started porting Tiramisù to mapcss for JOSM and that made me remember how powerful and readable CSS are, some things are so much simpler than Mapforge's XML (but not everything).

I use TileMill extensively lately building nautical raster maps (which have many peculiarities) and at the same time I build also their equivalent vector maps with Mapsforge.
TileMill API is indeed very strong and often something I do quite easily with it, I have to think twice in order to write the rules for Mapsforge.
The most typical example and missing feature is symbol / label overlapping.

Though we must have in mind that TileMill is a desktop tool and Mapsforge has to perform live render at mobile devices (powerful or not).

Anyway,yes you are right, symbol/text placement is somewhat of an issue. I had already proposed a priority mechanism https://code.google.com/p/mapsforge/issues/detail?id=476

A priority mechanism has already been implemented at dev branch.
You can see its use at dev rendertheme-v4 and try it with Cruiser Beta or Atlas Beta (they follow the dev branch).

Other than the collision management there is the slightly different problem of multiple icons for the same node (pizza, restaurant, hotel in the same building for example). In this case it would be nice to stack the icons and expand the stack on user tap (think about how folders work on launchers).

That's a nice idea, but I'm afraid currently it could work better with overlays.
The map rendering produces bitmap tiles that fill the map view.
There is not any direct interactivity with actual map contents and the user.

[Emux]

Another thing that would be useful also at Mapsforge, is to expand the label placement beyond the current available 4 positions (N, E, S, W) relative to the symbol.

We can implement additional label placement at the 4 "corners" of a symbol canvas (NW, NE, SE, SW), for a total of 8 possible positions around a symbol (like QGIS labels).

e.g. see attached image

[Maki]

Il giorno domenica 13 luglio 2014 22:30:47 UTC+2, emux ha scritto:

TileMill API is indeed very strong and often something I do quite easily with it, I have to think twice in order to write the rules for Mapsforge.
The most typical example and missing feature is symbol / label overlapping.

They have a lot of features, but the power I was speaking of is in the CSS, in particular in the C letter. With one rule you set the color of paths based on SAC scale. In another one you set the dash width based on zoom-level. In a third one you set the dash array based on the trail_visibility. With a bunch of lines of code you are done. In Mapsforge you need to make out every possible combination in an hard to read format; and even for simpler stuff there is a lot of repetition that could be avoided. I suppose that moving to a pure CSS styling would mean rewriting a lot of stuff, but an hybrid system, like Osmarender could be useful.

A priority mechanism has already been implemented at dev branch.
You can see its use at dev rendertheme-v4 and try it with Cruiser Beta or Atlas Beta (they follow the dev branch).

Yes, but AFAIK there is no threshold for triggering a "no-kill" switch. It wouldn't be perfect but still better than nothing. I have Cruiser beta installed since forever, but I still haven't managed to find the time to test the new features. I did however try to use the new "map styles" feature with the default osmarender theme with no luck. Isn't that theme supposed to have multiple styles built in?

Maki

[Emux]

I did however try to use the new "map styles" feature with the default osmarender theme with no luck. Isn't that theme supposed to have multiple styles built in?

The map styles exist now at both the master and dev branches.

The default osmarender theme has not changed (besides a complete renewal of the symbols).
But it's in the plan to include a new improved version.

To check the map styles you can use the rendertheme-v4, it can be found at Samples assets folder.

[Ludwig]

On 14 July 2014 17:02, Emux <deve...@gmail.com> wrote:

Another thing that would be useful also at Mapsforge, is to expand the label placement beyond the current available 4 positions (N, E, S, W) relative to the symbol.

We can implement additional label placement at the 4 "corners" of a symbol canvas (NW, NE, SE, SW), for a total of 8 possible positions around a symbol.
Like the attached image.

In dev that should not be too difficult to implement as the actual position calculation has been cleared up a bit.

IMHO the biggest improvement could be a 'auto' placement that will pick an empty area around the symbol. This could also be used to avoid placing labels over tile boundaries: if we had a good implementation for that all the complexity of managing the label cache could simply be dropped.

Ludwig

[Emux]

Yes I agree, we could easily expand the current label placement mechanism to include more positions.

The 'auto' placement is a nice idea but as option, because there are many cases where a label is expected or "must" be at specific position relative to the symbol.

Ludwig what's your thoughts also about the overlap feature (per symbol/label or centrally for all) ?

[Ludwig]

I agree that (more or less randomly, even with priority) dropping labels/icons is really undesirable for some maps. 

Certainly disabling the collision detection on a global level should not be difficult. On a individual level I am not so sure, I will have to look. 

--
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/53C55017.8030508%40gmail.com.

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

[Maki]

Il giorno domenica 13 luglio 2014 21:23:13 UTC+2, Maki ha scritto:

BUT, all this is meaningless until the tile border on closed ways bug isn't solved. It can't happen. Not on highways (see attachment).

Could something like this work in Mapsforge?

https://www.mapbox.com/tilemill/docs/guides/metatiles/ 

Maki

[Ludwig]

I have been thinking about this. 

The problem is the map file format, which (at least at certain levels) contains the data for just one tile and since there is no meta information stored for the data, we still would not know what certain objects are (we would not know that two adjacent areas of water are the same lake). 

A potential work-around would be to read in a lower zoom level (where the data for the meta tile we would want to render is stored in one segment of the map file). To get the same data included in that tile that we had at the higher zoom level, the tag-mapping.xml would need to shift by one or two zoom-levels. 

Apart from compatibility (maps that would not have shifted their tag-mapping.xml would have less info on tiles rendered as meta-tiles) I am not sure what other issues we would get.

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/937e3ef3-2358-4663-a640-70e0b7a9abc7%40googlegroups.com.

[Emux]

Maki's suggestion is interesting.
I have played a lot with Metatile settings (tiles number and buffer size) at TileMill, trying to solve cut off labels/icons or performance issues that exist also there.
But we must be careful, as it's actually quite easy to kneel down even a powerful pc with inappropriate values.

[Ludwig]

Yes, performance kills this.

If we have a 100*100 tile, to have enough margin to render all the labels, we would need to go to something like a 150*150 tile (margin just a quarter tile on all sides), meaning that instead of an area of 10000 we would need to render something more than double the size only then to throw it away. 

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/53CE17AD.7060905%40gmail.com.

[Ludwig]

On 14 July 2014 00:53, Maki <tarta...@gmail.com> wrote:

BUT, all this is meaningless until the tile border on closed ways bug isn't solved. It can't happen. Not on highways (see attachment).

Why is the highway closed there? I know drawing the lines along the tile boundaries for closed areas is annoying, but highways should not be closed.

Ludwig

 

[Maki]

Well, I don't know, but it's not the only case I found. Actually highways can be closed, there are even examples on OSM wiki. What about forcing an area=no in the map writer for highways?

About performance, I don't think you need a 25% buffer all around, we are talking about a few pixels (speaking of the border on closed ways). Moreover the typical tile size nowadays is more like 512x512. Since Oruxmaps (beta) switched to 0.4 that alone drastically reduced the cut off labels on my devices. But can't labels and (maybe) symbols be rendered separately from the rest without cropping? If a part is beyond the borders it just gets passed to the adjacent tile rather than thrown away.

I think that reading the buffer data from the previous zoom level would cause more problems than it solves, because of the different zoom-appear, if a thing like this has to be done it needs to read from the adjacent tiles, or else we need a different approach from the map writer building tiles that overlap.

[Emux]

I have pushed at dev some changes that add support for caption placement at all 8 positions around a symbol (below, below left, below right, above, above left, above right, left, right).
This is implemented at both Android and Java.