z-index of elements: usage of groups in org.oscim.map.Layers

[eddiemuc]

Hello,

I am looking for a way to easily allow adding and removing of Layers to a VTM Map using z-index (which on flat map view would decide in which order elements are displayed). Basically I look for an easy equivalent of the zIndex option in Android Google Maps available in the various map element models (com.google.android.gms.maps.model.*, explained e.g. here: https://developers.google.com/maps/documentation/android-sdk/marker?hl=en#marker_z-index or https://developers.google.com/maps/documentation/android-sdk/reference/com/google/android/libraries/maps/model/PolygonOptions?hl=en#zIndex(float)

I am aware that layers have an order in VTM (like in Mapsforge) and are drawn in this order. However, it is hard to maintain a full priority order of elements across a whole application. I am looking for some utilities/helpers to ease the burden here.

I noticed that class org.oscim.map.Layers (which holds the layers for a map) support some sort of "group" function with methods addGroup(int) and add(Layer layer, int group). Questions:

• Are those the recommended way to deal with z-index of elements?
• The functionality seems to be somehow incomplete. For example, if normal "add" (without group) is used then the group index maintained by the group-version of add is no more valid. Also, on removal of layers the group index is no longer updated. Is this intended? Am I missing something?
• If both of the above is correct, would you be interested in an update of this "group" functionality (via PR)? For example:
  • keep group index intact also when layers are removed or added via "normal" add function
  • "addGroup" needs to be called mandatory before group is used, but fires exception when group exists. Howeber there's no way to know from outside which groups exist. I would recommend to delete (=deprecate) addGroup and auto-add groups as they are coming

If VTM does not support z-index and is not interested in enhancement I would start building an own workaround solution for our app (c:geo).

[devemux86]

Layer z-index in Mapsforge and VTM works similarly:

• Can use the List's order for the simplest implementation and change the order dynamically.
  VTM uses the ItemizedLayer for markers and Parameters.MARKER_SORT controls y-axis sort (because of 3D).
• Or use the "group" methods for a more detailed control.

if normal "add" (without group) is used then the group index maintained by the group-version of add

The methods are not supposed to be mixed, better select and use one of them.

However there's no way to know from outside which groups exist.

We add and maintain the groups, so we know them?
(also groups are unique, also keys in a Map)

[eddiemuc]

Thanks for quick reply.

if normal "add" (without group) is used then the group index maintained by the group-version of add

The methods are not supposed to be mixed, better select and use one of them.

That's not possible since at least VTM uses normal "add" also internally in class org.oscim.map.Map:

• in constructor: mLayers.add(0, mEventLayer)
• in method setBaseMap: mLayers.add(1, tileLayer)

My suggestion would be to handle normal add as if they would be done to a default group 0. Then mixing would be possible.

However there's no way to know from outside which groups exist.

We add and maintain the groups, so we know them? (also groups are unique, also keys in a Map)

True, but would need to be maintained in duplication in app code outside of VTM since there's no public method in class Layers to access this data from outside. I suggest adding something like boolean hasGroup(int group)

Also, removal of layers is not reflected in current Layers grouping mechanism and will lead to false index data. This looks buggy to me.

It seems to me that it is of no interest to VTM/Mapsforge to enhance this mechanism? That's ok for me, I just want to know before I build my own workaround outside of VTM/Mapsforge. I would prefer to enhance VTM/Mapsforge directly, but I am ok with whatever you decide.

[devemux86]

VTM uses normal "add" also internally

Event layer has special use and works at the bottom.
Why is there a problem with that?

in method setBaseMap

It is not mandatory to use the default methods (like setBaseMap).
Can add map layers at any z-order with regular or group methods.

Regular methods exist since Mapsforge / VTM beginning.
Layer groups were added much later, as extra API option.

need to be maintained in duplication in app code outside of VTM since there's no public method in class Layers to access this data from outside

Sorry, it is still not clear?
We use Mapsforge / VTM groups for a long time, very easily without duplicate code or any problems.

Also, removal of layers is not reflected in current Layers grouping mechanism and will lead to false index data.

What does removing layers have to do with groups? They are completely different entities.
Groups are declared once at app's start and remain fixed, the layers are added / removed.

Maybe not being used in the right way or expect them to work differently?

It seems to me that it is of no interest to VTM/Mapsforge to enhance this mechanism?

I am always available for Mapsforge / VTM improvements!
However we must first clearly understand the suggestions and reproduce the reports. 🙂

I suggest adding something like boolean hasGroup(int group)

Sure, contains for layers / groups were added via #1032.
(Mapsforge already had contains for layers)

[eddiemuc]

Hi @devemux86,

as written in my initial post, my intention is simply to make usage of groups an easier task without the needs of redesigning your whole app when you plan to introduce it. I believe this could be reached with a few easy changes in class Layers as follows:

• auto-add groups when they are first used in add(Layer layer, int group) (instead of throwing an exception when group doesn't exist)
• on first usage of add(Layer layer, int group), move all existing layers in a "default" group 0. From this point on forward, put all layers added with "normal" add into this default group
• add methods Set<Integer> getGroups() which returns a list of all currently existing groups, as well as a method boolean hasGroup(int group) which returns true if the given group exists

This would ensure that:

• all existing methods will still work as before and as expected by users. Especially users with no interest in groups will get same behavior as before
• "mixed" usage of normal "add" and group add would coexist well
• one could start "converting" pieces of an app to "groups" without having to redesign the whole app at once

You are correct that when one strictly designs an app either using solely normal add or the group variant, one could reach the same functionality. However, I believe in APIs which can be used easily also in environments where one can't just change the app design "from scratch". Especially when it would be so easy to reach (as in this case).

That's my whole intention. But I really don't want to force my perspective onto your project if you feel differently. So what do you say?

As for the remove(Layer layer) method, I have to apologize. This method leaves the group index intact, I overlooked this at first.

[devemux86]

Hi @eddiemuc!

auto-add groups when they are first used in add(Layer layer, int group) (instead of throwing an exception when group doesn't exist)
add methods Set getGroups() which returns a list of all currently existing groups

See #1033 and mapsforge/mapsforge#1405 and if something else is needed.
(also the throw statements were replaced)

a method boolean hasGroup(int group) which returns true if the given group exists

containsGroup was added in #1032 and mapsforge/mapsforge#1404.

on first usage of add(Layer layer, int group), move all existing layers in a "default" group 0. From this point on forward, put all layers added with "normal" add into this default group

It is not yet clear its need or what such an internal automation solves?

Also I am afraid that it will change the way the library works internally
and thus cause problems to the apps already using Mapsforge / VTM.

all existing methods will still work as before

Exactly and this is extremely important (in relation to the point above).

Mapsforge / VTM always had excellent compatibility with updates,
without changing the public API and breaking user apps.

[eddiemuc]

Hi @devemux86 ,

many many thanks for the quick changes!

Wrt making normal and group add mixable: you are right with your concerns, I will think about this some more...

[devemux86]

@eddiemuc I merged #1033 and mapsforge/mapsforge#1405.