New LabelLayer

[Ludwig]

I have just pushed a very large changeset to dev. This introduces a new LabelLayer to address many of the issues regarding layout/clipping/overwriting etc. 

TL;DR: new LabelLayer writes labels directly onto canvas, no more clipping, but you will need to add a new layer to your app.

Ludwig

From mapsforge-map/docs/LabelLayer.md:

The New Label Layer

===================

The new LabelLayer is responsible for drawing labels and icons onto a map. This effectively splits the responsibility of drawing a map into the TileRendererLayer, which will now only draw ways and areas (essentially items that will appear the same when a map is rotated), and the LabelLayer which will draw labels, road-names and icons (everything that needs to have a fixed angle relative to the screen).

Problems in 0.4.x

-----------------

In the current, 0.4.x, we have have a couple of issues, that are either unresolvable with the current approach or the implementation has so many problems that they are difficult to solve without a complete rewrite. More specifically:

  * No support for map rotation. Since labels were drawn at a fixed angle onto a tile, rotating the tile would also rotate the labels. 

  * Complex implementation: since labels were drawn onto tiles, it had to be carefully where labels overlapped tile boundaries. In these cases, labels had to be drawn onto adjacent tiles. The implementation for this was very complex and had several errors, most notably that it could not account for tiles being purged from a cache and redrawn. One result were labels wrongly clipped at tile boundaries.

  * Overwriting for parallel roads: the label placement algorithm was not applied to roads, resulting in road names overwriting each other.

  * No priority, a random first-come/first-serve algorithm for label placement, often obscuring more important place names.

  * A related problem in the TileRendererLayer is that through the extensive use of local variables it is impossible to multi-thread that layer. 

The new approach

----------------

  * Labels are drawn separately and directly onto the canvas. This will make it possible to rotate the underlying tiles and keep labels horizontal. Rotation is not yet implemented, but the new implementation goes a long way towards supporting map rotation.

  * Labels are not tiled anymore, therefore clipping at tile boundaries has been eliminated and the complex accounting for tile dependencies could be removed. 

  * Road labels are now part of the placement algorithm.

  * There is now a priority element on captions, symbols, line-symbols and pathtestext. The higher the priority, the earlier the element is drawn onto the map, ensuring that labels with higher priority are visible.

  * In the DatabaseRenderer a number of local variables have been removed. This work is not yet complete, but it is a step towards multi-threading here.

As with other changes introduced, this is an incremental change that leaves user code as much unaffected as possible, but it also makes the implementation a little tricky. 

  * The labels are retrieved from the map database in a tile by tile fashion. There is no way to retrieve labels by location. And as every single item has to be passed through the rendertheme mechanism this retrieval is relatively expensiv.

  * The labels need to be redrawn for every redraw of the map. No everything can be done on the main UI thread. Computing the label placement is relatively expensive.

The new implementation addresses this in the following way:

  * All map elements to be placed on the LabelLayer are derived from MapElementContainer in mapsforge-core. Technically, this should go into mapsforge-map, but for the PointTextContainer we need different implementations for Android/Awt, which requires a factory method through the GraphicFactory. A MapElementContainer knows how to draw itself onto the Canvas. 

  * Label retrieval hooks into the retrieval by the TileRendererLayer that was previously responsible for drawing the labels. This eliminates a double reading of the map file -- however, at the expense of some complex operations.

  * The label data is then stored in the TileBasedLabelStore, a LRU cache that is organized according to tiles. 

  * The TileBasedLabelStore precomputes the layout for the last requested area. This assumes that the area does not change very often, as it is the case with usual map panning. 

  * Whenever the visible tile set changes, the LayoutCalculator thread recomputes the layout and, when finished, requires the LayerLabel to be redrawn.

Notes for users

===============

TileRendererLayer:

------------------

The TileRendererLayer now takes an additional argument of the TileBasedLabelStore, which receives the labels that the DatabaseRenderer produces. 

A TileBasedLabelStore must be created first (alongside tile caches), it takes just one argument, its capacity. The minimum capacity can be established the same way as for the tile cache, e.g. in the BasicMapViewer example:

this.tileBasedLabelStores.add(new TileBasedLabelStore(2 * AndroidUtil.getMinimumCacheSize(this, this.mapViews.get(0).getModel().displayModel.getTileSize(), this.mapViews.get(0)

.getModel().frameBufferModel.getOverdrawFactor(),this.getScreenRatio())));

This then needs to passed into the TileRendererLayer and alongside the TileRendererLayer we need the LabelLayer.

protected void createLayers() {

TileRendererLayer tileRendererLayer = Utils.createTileRendererLayer(this.tileCaches.get(0), this.tileBasedLabelStores.get(0),

this.mapViewPositions.get(0), getMapFile(), getRenderTheme(), false);

this.layerManagers.get(0).getLayers().add(tileRendererLayer);

LabelLayer labelLayer = new LabelLayer(AndroidGraphicFactory.INSTANCE, this.tileBasedLabelStores.get(0));

this.layerManagers.get(0).getLayers().add(labelLayer);

}

If you do not want any labels, pass null for the TileBasedLabelStore to the TileRendererLayer.

Rendertheme Change:

-------------------

The priority attribute has been added to caption, pathText, lineSymbol and symbol. The default priority is 0, higher priorities are rendered first, lower priority elements later if space is still available. 

Remaining Problems:

---------

  * Memory as usual: mapsforge sails close to OOM all the time and keeping the label data for all the visible tiles in memory can cause an app to OOM. Finding the right balance is difficult. 

  * The AwtPointTextContainer does not currently calculate the boundaries correctly for line-broken labels. The problem here is that the size needs to be computed before the actual text is written to canvas.

  * SwingMapViewer does not have a LabelsLayer.

Notes for Rotation:

-------------------

This is only one step towards a proper map rotation.

One of the issues is that the calculation of the layout is quite expensive. For that reason it is precomputed in a separate thread, rather than on the UI thread. However, for rotation tis layout has to be done for every change in rotation as different labels will clash. This introduces some instability in the label layout as with different rotations different labels will be drawn. 

A different approach would be to calculate the maximum radius of a label and assume it is actually not rectangular, but circular. That way the layout would not change with rotation and could be done only once for a set of tiles. It would also mean that the overlap of labels could be computed quicker: it is only combined radius < distance. With line-breaking labels that would be possible.

It might also be that at the moment the center point of labels to the left/right/below/above symbols are calculated wrong and will not be correct for rotating maps. 

[Emux]

Hi Ludwig,

Thanks for that indeed very large commit!
I will test it (and also study the code) and report any remarks.

One quick question, reading at the doc "SwingMapViewer does not have a LabelsLayer".
This means that now the AWT is unable to show labels?

--
Emux
Cruiser - Atlas

[Ludwig]

Well, two things:

technically it should be easy to add the LabelLayer to the SwingMapViewer, it just needs the creation of the TileBasedLabelStore and the LabelLayer. I had wanted to do that, but then somehow I could not run the SwingMapViewer on my mac at all (I could not zoom in, not sure if that is a recent problem), so I left it for the moment.

The only other Awt specific thing is the layout of the PointTextContainer, here AwtPointTextContainer. As I have not tested it, I am not sure if the labels are acutally placed at the correct position or if they are miles off. (However, that should be easy to fix as it should just be a question of shifting by point of origin). 

The other bit that I know is broken is the layout of line-broken text. 

The way this works now is that when a MapElementContainer is constructed, it needs to determine its boundary around the pivot point. This boundary is then used to establish whether the element has space on the map. In the Android case, the boundary is computed with the StaticLayout. In the Awt case, the correct boundary would only be established when it is actually written to canvas (and the boundary used is one of the text not line-broken). One way to fix it would be to do the computations twice, the first time at construction (when the text is not actually written), the second time when the AwtPointTextContainer is actually written.

There are probably more things that are somehow broken....

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/5385832A.4090008%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Emux]

Ok first impressions follow.

  * There is now a priority element on captions, symbols, line-symbols and pathtestext. The higher the priority, the earlier the element is drawn onto the map, ensuring that labels with higher priority are visible.

Tested with render theme v4, I really like this feature!
It clearly advances the usability of the map.

  * SwingMapViewer does not have a LabelsLayer.

It's true that now at AWT we don't have any labels.


I notice an issue, testing with default osmarender theme (which does not have label priorities).
When I pan the map some labels disappear in order for other labels to appear at their position.
When I reverse the pan the new labels are gone and the old ones are back again.
You can see this with the berlin.map and scale 1km at area where the big "Berlin" name appears.

[Ludwig]

When I pan the map some labels disappear in order for other labels to appear at their position.

I had not actually noticed this, but I expected this to happen. This is why:

every time a new tile shifts into view (or even when the labels on a tile are updated) the layout algorithm kicks in (done by the LayoutCalculator). The labels visible on tiles are then recomputed by constructing a list ordered by priority. This sort is not stable, it depends on the tile order and beyond priority there is no ordering defined on the MapElementContainers. Then the items in that list are drawn onto the canvas if not an item has already been drawn on that space.

I agree that any instability is undesirable, but I have no real idea on how to prevent it in general. 

I had been thinking of additionally ordering labels by their distance to the visible map center (but that would introduce even more instability, even though it might be more useful if we assume that the map center is a users focal point).

Any suggestion?

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/5385BAC5.1040505%40gmail.com.

[Emux]

I need to think over it to be able to suggest something here.

What really worries me is that rendering now seems even slower.
e.g. when I try to pan the map quickly, the movement is jerky, the label calculations apparently play a role here.

An interesting example of vector layers and how they appear to draw from the user perspective is Osmand.
You can pan the map fluently and then the draw takes place layer by layer.

I started the integration at Cruiser Beta to be able to use it more versatilely
and to provide to anyone who needs another mean to test the new features.
Atlas Beta will follow as soon as I check the Awt issues.

[Tobias]

That's excellent news, thanks a lot! This solves some of the major issues I see at the moment, especially the priority feature is most welcome.
This probably fixes the repeated drawing of captions on large areas (lakes, national parks, forests) too.
Does is also allow a fix for pathtext rendering for streetnames ion curved roads where the segments are too short for the whole name to be rendered and thus isn't drawn at all?

[Emux]

Ludwig continuing the tests with Android I see that the double tap zoom behavior does not work anymore as intended.

The 'zoom in' seems to take place with pivot the center of the map instead of the double tap point.
And at zoom animation finish we have a sudden map movement in order for the double tap point to be inside map view.

[Emux]

And another thing I notice is that there are optical differences at map rendering.
Specifically the coastline with default Osmarender theme, now it seems to be missed.

[Ludwig]

This probably fixes the repeated drawing of captions on large areas (lakes, national parks, forests) too.

Unfortunately it does not. The problem is that the data comes from the map file tile by tile and for every tile it computes the extend of the area and places a label in the middle of that. So the LabelLayer ends up with lots of labels for the area, but there is no way of knowing which one would actually be the most central one. Eliminating double labels would not be too difficult, but I cannot think of a way of determining which one to keep.

Does is also allow a fix for pathtext rendering for streetnames ion curved roads where the segments are too short for the whole name to be rendered and thus isn't drawn at all?

That not, either. The current (and previous) algorithm goes through the road segments one at a time and determines which ones are long enough to render the text. But really the text should be drawn on a path (i.e. the whole road). I have been thinking about it, but so far I have not come up with a good answer for cheaply computing a (minimal or about minimal) bounding box of a path to test for label collision. Technically I could of course take the bounding box of the road, but then image a very curved road, that would eliminate all other labels contained in that curve.

What I need for this would be a cheap way for testing overlap of rectangles that are not aligned in their orientation (anyone any pointers?)

Ludwig

[Ludwig]

What really worries me is that rendering now seems even slower.
e.g. when I try to pan the map quickly, the movement is jerky, the label calculations apparently play a role here.

Noticed that too. I had hoped rendering would actually speed up as I removed a lot of unneeded computations (e.g. for computing positions in the previous version the tile coordinates were computed again and again for every single point). But the drawing on the canvas directly seems to take up too much time, in some way it is back to what rewrite tried to address. I am experimenting with speed-up solutions.

Ludwig

[Emux]

I am experimenting with speed-up solutions.

Do you think we have to retry android:hardwareAccelerated="true" at manifest?

[Ludwig]

I am also currently looking at speed-ups. I had previously enabled hardware acceleration but it seemed actually to have limited effect (I don't think it is faster drawing bitmaps unless they are scaled, but it could be faster drawing the labels). 

But it would be good to know where the flickering comes from. My hunch is that it come from an overdrawing of the screen with a background colour. I do not have a good device with me that really shows the flickering, which makes it difficult to investigate.

I have been timing the drawing and it is faster to draw tile bitmaps than it is to draw labels. On the Nexus 5 I am currently using I see something like 6 ms to draw all the tiles compared with about 0.3 ms to draw each label (so having 50 labels will take about 15ms). The frame rate is set at about 33 (30 ms per frame in the LayerManager). 

But the lagging actually seems to come from the FileSystemTileCache where there is too much locking. Just experimenting with it. Will report later.

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/5386D5CE.50300%40gmail.com.

[Emux]

What if the labels drawing (and its calculations) takes place only when the map is idle i.e. after the map pan / zoom ends?
And while we move the map only the tiles drawing is permitted.

[Ludwig]

I have kind-of tried this. One of the problems is that we do not know when the panning ends and it feels kind of funny when the labels all disappear for a while, but it somehow is an option.

--

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/5386DC42.80003%40gmail.com.

[Emux]

While we pan the map now, we usually see empty areas with just the labels draw and after the tiles draw below them.

It's more aesthetic and probably not feasible, but it would be more pleased for the eye to have them at the same time or the tiles to draw first.

[Emux]

Ludwig has the rendering changed at you?

I compare master and dev branch and at dev I see many lines to be dashed instead of solid (osmarender and render theme v4). Like buildings, roads etc
I remind also the previous issue with the missing coastline.

[Emux]

I have pushed at dev the needed changes in order for the SwingMapViewer to be compatible with the new LabelLayer.

[Ludwig]

The render theme v4 xml changed quite considerably, much closer to what I am using (the one in master is more an outdoor map). 

That change was probably a mistake as it makes comparisons in rendering difficult. For comparison I would suggest just checking out the one from master into dev. 

Maybe I should revert to the old one.

I looked at the coastline stuff and using a map with correct coastlines/water areas and a suitable rendertheme it displays ok. Using master and e.g. the cyprus.map from the download server the coastlines do not come out correctly either. At this point I am not really sure if there is a problem with the coastlines in dev at the moment. 

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/53871DF0.7050700%40gmail.com.

[Emux]

I summarize the results as they span multiple posts above.

I make the tests comparing master and dev branches (either with Samples / SwingMapViewer or Cruiser / Atlas).
Using both internal osmarender and render theme v4 (master and dev) with maps from mapsforge download server e.g. cyprus.map

Currently there are 3 issues:

- With dev branch there is not coastline using whatever render theme: osmarender, render theme v4 (master or dev).
With master coastlines work fine as always.

- Dev branch strangely at devices has dashed lines (roads, buildings), at emulator (GenyMotion) appears fine.

- Something seems to have changed also at map mechanism, as double tap does not work anymore correctly.

[Ludwig]

I have just committed to dev a change that at least for the moment backs out of the untiled LabelLayer as I have not found a way to get the performance better: the problem really is one of laying out all the labels for the screen in one go, which needs about 100ms, which is too long to be done all the time.

The code is now back to writing labels onto the tiles, but with a rewritten and much simplified handling of the dependencies between tiles for labels that overlap tiles. The placing of line-broken labels has also been improved. The Samples app has been adjusted accordingly. 

Priorities for labels are still there, but they are not applied to road labels. The problem we have with road labels is their rotation: there is no easy overlap detection (and if we bluntly define a rectangle around the roads we end up with too many road labels colliding even if they do not). We need some sort of cheap heuristics for a clash of rotated rectangles (something like a separating axis test, but lightweight).

An untiled LabelLayer is still possible, see the LabelLayerMapViewer in the Samples app. The LabelLayer now has the thread for the layout running in the background removed and the layout is done synchronously whenever something changes (either new tiles visible or new data on the tiles).

Anyway, I do not have any slow devices for testing with me, but I hope the performance is roughly in the class of what we had before. 

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/53882B86.9030803%40gmail.com.

[Emux]

+1 for making the label layer optional.

I have for testing an old device (even with Android 2.3) and will report back any remarks.

Now the TileBasedLabelStore.destroy() is not public and is never called.
Don't we need it anymore?

- Zoom in with double tap still not works as intended (it jumps)

- I still see the dashed lines e.g. at roads / buildings

Ludwig can you confirm any of the above?

[Emux]

Using the labels on tiles, now the 'oneway' arrow icon is painted above the road labels and not alternately with them.

[Emux]

The LabelLayer now has the thread for the layout running in the background removed and the layout is done synchronously whenever something changes (either new tiles visible or new data on the tiles).

Using the label layer, the synchronous layout makes the panning even more cumbersome (tested at Android / Java).

[Emux]

At PointTextContainer:67 in clashesWith method, what is the fixed value 200 at xy distance check?
It must be constant?

[Emux]

There are still issues with the coastline.

I attach 2 samples:
- Atlas with mapsforge master
- Atlas Beta with latest dev

[Emux]

Now the TileBasedLabelStore.destroy() is not public and is never called.
Don't we need it anymore?

Ok I didn't look carefully, it's public.
Though it's not called at LabelLayerMapViewer.

[Emux]

Another issue I see is the relative position of the labels with their symbols.

- At Android the labels overlap their symbols.
- At Java the labels are at the wrong position.

I attach samples.

[Ludwig]

On 7 June 2014 01:46, Emux <deve...@gmail.com> wrote:

Using the label layer, the synchronous layout makes the panning even more cumbersome (tested at Android / Java).

At the moment I do not have any good solution to this, and my main aim is to have a common code base for both the LabelLayer and the on-tile labels that works correctly. Then we have a base-line from which to investigate performance issues. The label layout certainly needs to be done off the UI thread, but without dragging the whole app down with it. 

 

[Ludwig]

At PointTextContainer:67 in clashesWith method, what is the fixed value 200 at xy distance check?
It must be constant?

Good that someone actually reads the code. When checking in I was pondering to remove this altogether. It is an experiment in removing double labels that are close together. (We get these double labels for areas that overlap tiles, each tile gets its own label). I am not really sure if it works at all and probably needs some sort of configuration if it does. 

 

[Ludwig]

Now the 'oneway' arrow icon is painted above the road labels and not alternately with them.

To me the one-way labels look ok. (They had a problem for a while as I was not rotating them correctly and then they would show up above the roads for one-way streets running east to west).

Do you have a screenshot? 

 

[Ludwig]

- Zoom in with double tap still not works as intended (it jumps)

Fixed with 51c6cf69c3cc9. It was caused by the removal of MercatorProjection(LatLong, byte, int) as it now linked to MercatorProjection(LatLong, float, int). Joys of overloading/type promotion, probably wrong to overload like this.

- I still see the dashed lines e.g. at roads / buildings

Not sure what you mean, but I will look out for it, might be caused by problems with closed/nonClosed ways. 

 

[Ludwig]

Another issue I see is the relative position of the labels with their symbols.

- At Android the labels overlap their symbols.
- At Java the labels are at the wrong position.

On Android, the label position is now centered to the point the label is attached to. Previously it was the baseline, so the label was always a bit above the actual point. (The screenshot you are showing uses the internal theme where the label for a station is offset dy=-10, that was above the circle previously, but now the shift would have to be bigger).

(See AndroidPointTextContainer, line 147 or so.)

I actually think that the new implementation is correct, particularly if you consider the case where you would have a single character like 'U' to denote an underground station or the case where labels are to the left or to the right of a point. (The positioning is not perfect, but better than without that shift).

The only problem is of course that it changes the appearance compared to older versions when like in the current internal osma rendertheme, dy values are used to position the labels.

The change on Java is probably due to a simplification of the positioning code. Previously, there was a lot of shifting of the actual point to draw the label, now the Android version uses the alignment. I guess on the Java front it just writes the label from the point of origin regardless of alignment. I will have a look later (fixing the double-tap issue means I can also run the Java version again).

 

 

I attach samples.

--
Emux
Cruiser - Atlas

--

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/539221EF.5000005%40gmail.com.

[Ludwig]

There are still issues with the coastline.

I attach 2 samples: Atlas with with master and Atlas Beta with latest dev.

It is somehow caused by a change in what is recognized as a closed line. I am investigating. 

 

[Emux]

Good that someone actually reads the code.

Well I prefer studying the code and its changes in order to better handle / modify the libraries.

[Emux]

About the dev 'oneway' issue, I attach a screenshot.

Further examining it, I see that this issue exists also at master: 'name' and 'ref' paint one over the other, or 'ref' label and 'oneway' symbol mix up.

But now at dev I see this issue quite often: 'oneway' symbol over the 'name' label.
Check inside the black square.

[Emux]

I attach 2 screenshots regarding the dashed lines issue.

Strangely I see it only on Android 2.3, it's easy reproducible at emulator also.

- dashed_master: Cruiser with unmodified mapsforge master

- dashed_dev: Samples with latest mapsforge dev

[Ludwig]

I fixed the dash-line issue, probably most elusive stupid bug I ever spent time on. (Reason was that I wanted to preallocate space in List, but instead copied an entire array of data (as I forgot to say .size(), had nothing whatsoever to do with Android 2.3 but somehow just manifest itself there. Very bizarre.

Also hope that I fixed the water issue. This one is a little more tricky. There is a test if a way is closed, but in reality the lat/long values for the water are sometimes not equal (comes from the compression algorithm in the writer), but the values were identical once converted to Points. I now test if the points are only a very short distance apart, hope this works.

Both pushed on dev.

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/5392DDFF.9090407%40gmail.com.

[Emux]

Indeed very strange issue while appearing only at specific Android version.
My first thought was it had to do with the rendering at that Android.

I can confirm that both issues appear to have been solved.

[Emux]

More tests with the dev branch:
I compare master and dev with berlin.map zoomed at level 17 at default start position.

I see that the map view fills with the rendered tiles much faster with the master than with the dev branch.
The lag at dev is observable with naked eye at high end devices and even with Genymotion at a powerful pc.

[Emux]

The change on Java is probably due to a simplification of the positioning code. Previously, there was a lot of shifting of the actual point to draw the label, now the Android version uses the alignment. I guess on the Java front it just writes the label from the point of origin regardless of alignment. I will have a look later (fixing the double-tap issue means I can also run the Java version again).

The whole positioning thing seems to malfunction in Java.
e.g. the caption's 'position' tag does not work either

[Ludwig]

The Java bit had not been properly adjusted yet to the new mechanism, I have just pushed a commit that should go some way to rectifying the situation.

It is not entirely correct yet, the main issue that I do not really know how Awt writes text wrt the anchor point (baseline-align?). 

There are two spots in the AwtPointTextContainer that need some attention:

1. the computeBoundary() function. The boundary is used to determine label clashes and to compute which labels overlap to another tile. The boundary computation for line-broken strings is pretty crude and might give wrong results. (On the Android front the computation is more correct as the StaticLayout is computed in the ctor before the drawing process, if something similar could be done in Awt we would have better label placement).
2. y-adjustment for line-broken text. I do not actually know how the block of line broken text is related to the anchor point. It would have to be shifted for the positioning to work.

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/5399A930.9020402%40gmail.com.

[Emux]

I'll examine more thoroughly the code.

Ludwig the 'left' position needs a fix.
At AwtPointTextContainer:136 it misses a '-' for rectangle left parameter.

return new Rectangle(-boxWidth, -boxHeight / 2f, 0, boxHeight / 2f);

[Ludwig]

Yes, fixed, was actually a copy and paste error from the Android version. Thanks.

--

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/539AF018.1050607%40gmail.com.

[Emux]

the computeBoundary() function. The boundary is used to determine label clashes and to compute which labels overlap to another tile. The boundary computation for line-broken strings is pretty crude and might give wrong results. (On the Android front the computation is more correct as the StaticLayout is computed in the ctor before the drawing process, if something similar could be done in Awt we would have better label placement).

I understand what you mean, though I don't know if we can do such computations in Java outside draw.

y-adjustment for line-broken text. I do not actually know how the block of line broken text is related to the anchor point. It would have to be shifted for the positioning to work.

Both x and y positions need adjustments for line broken text.

I fixed them but I want to perform more tests before committing the changes.

[Emux]

I have committed to dev the required x/y adjustments for Java line broken text.
I used the layout's elements for the measurements for more accuracy and simplicity.

[Emux]

To summarize the aforementioned issues.
After the latest commits (and besides the performance that is discussed now in a separate topic),
I think the only remaining dev issue is the overlapping of the oneway symbol with the road labels.

It was reported with a sample above:
https://groups.google.com/d/msg/mapsforge-dev/AedxgdAWnR0/6JLY9yX95BMJ

[Emux]

I published new Beta versions of Cruiser / Atlas with an option in settings to enable the LabelLayer at rendering.

LabelLayer (alpha) is going to play a central role in upcoming map rotation implementation.
So I thought to expose more its functionality for all to better test it.

[Tobias]

Thanks for that!
I tested it a bit, rendering of captions/symbols/pathText is much better on tile borders, and rendering speed is pretty good - no big difference to me.
One strange thing - some delicate lineSymbols are getting heavier, but not all (no transparency involved).
In the screenshot of Atlas on the left side all symbols are rendered with the same strength, on the right side with label layer the symbols on the upper tiles are stronger, the lower right are the same.
Best regards,
Tobias

[Emux]

I started to use it more extensively later because of an issue I have with regular Mapsforge on a grid map (missing symbols at tile borders).

So far I can make 3 remarks:

- The rendering speed is much better than our tests several months ago (because of the various rendering improvements / fixes since then)

- The CPU load is also very much higher during pan / zoom than without it (measured on mobile devices and desktop)

- I have seen often cases where whole tiles do not fill, I need to pan the map for them to render. That's usually on map view borders.

[Emux]

I pushed some fixes for LabelLayer implementation,
improving its behavior regarding redrawing and tile cache handling.

Please report any feedback.

[Murray Hughes]

Where are things with the Label Layer and rotation? I have a few things I want to draw on the map that are are always north and don't mind trying to solve the problem but wanted to know if anyone had started or knew how it can be achieved. 

Murray

[Emux]

LabelLayer should be fine now (please report any issues).

'Internal' map rotation is work in progress.. (nothing to use yet).

--
Emux

[Murray Hughes]

Can I help with on ‘internal’ map roation? I need to get place labels and also some markers working so I might as well contribute to a end solution.

Murray

—
Sent from here

--

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/55FFFAD1.9010501%40gmail.com.

[Emux]

As it's a major code rework, we have a separate branch 'rotation' (based on 'dev') which contains Ludwig's initial work.

This needs to get latest 'dev' merging and anyone can contribute to that.
Actually we encourage all of you!

BTW you mean markers and labels that are built in the map file?
Because if we're talking about Marker overlay, that can be easily rotated in it's draw method.

--
Emux

[Murray Hughes]

Ludwig, Do you think you can merge in the latest develop and I can spend the next few days working on some of the remaining issues. Or I can just include a merge with develop as part of my PR.

Thanks

Murray

—
Sent from here

--

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/55FFFDAB.3070604%40gmail.com.

[Emux]

Please.. not mixing PR(s) with merging.

PR should be minimal / clean and update themselves via 'rebase' on latest branch they are based on.

I'll perform the merging later (of course it has conflicts) and notify!

(BTW we'll need to continue our rotation conversation on related topic or new one)

--
Emux

[Emux]

I removed 'alpha' state from LabelLayer in Samples.

After the fixes in last Mapsforge release and checking it since then,
there do not seem to exist any issues in everyday use.

--
Emux

[Ludwig]

+1, will merge into master and make rc3 tomorrow

--

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/5649B59C.6010702%40gmail.com.