What about BonusPack support?

[2ndGAB]

Hello,
Where are we supposed to report issues or ask for support about BonusPack?
Now that BonusPack seems supposed to be included in OSMDroid core (a good thing I think) where does the support will be done?
I wonder if Mathieu still answers to questions on his repository.

[spyhunter99]

Great question. I've hashed some things out with @MKergall regarding this. I think the short term goals are to

1. get Mathieu write access on this repo to make life easier for him. @neilboyd can you help with this?
2. osmbonuspack primarily focuses on kml, geoson, routing support
3. osmdroid to start deprecating the older overlay sets
4. most likely some refactoring in osmdroid to better integrating the classes migrated over from bonuspack.

#252 is still open for a reason. Primarily for number 3 above. I'm not exactly sure what right looks like here. We also now have a few classes with duplicate names in different packages. There's also a lot of house keeping we should do regarding unused interfaces in the main library.

To more directly answer your question, most of the folks on osmdroid also monitor osmbounspack for new issues and whatnot. I think what was agreed to was the items in number 2 above would remain at osmbonuspack and thus issues related to that should be posted over there, everything else presumably over here

[kurtzmarc]

I just wanted to chime in and give my opinion. I haven't been very active on osmdroid lately, but have seen a lot of the evolution of osmdroid over time. If I had stayed active, I would have pushed to reduce the feature list of osmdroid. My feeling is that osmdroid should just cover core functionality - a map view, one or two overlays, a demo project and that's it. The original intent of osmdroid is to be a drop-in replacement for google maps (even if it is v1 which is obsolete). I loved that osmbonuspack was separate - it kept a clear division between core functions and what you can "do" with osmdroid. If we think that merging the two projects is necessary then my response to that would be that we need to expose additional interfaces for developers so osmbonuspack can implement what they need. Overlays should be "drop-in", new tile providers should be possible by extending base classes - we should provide all the tools necessary so that projects like osmbonuspack can do what they do without needing to tightly integrate with the core.

Just wanted to give another view. Best of luck and let me know if I can help!

[2ndGAB]

The original intent of osmdroid is to be a drop-in replacement for google maps

But OSMDroidBonusPack adds gaps to OSMDroid to replace GoogleMaps!
From my point of view, without BonusPack, OSMDroid is not really useable and personnally, I would have choosed another solution, maybe MapBox or I don't know what else.
But that's just my point of view.

[MKergall]

Hi all,

Here are my views:

1. About the philosophy/strategy:
   As discussed with @spyhunter99, the idea was to move some classes that can be considered as "core features" of a "modern map library" from OBP to osmdroid.
   From my point of view, these key classes are: Marker, Polyline and Polygon (along with underlying classes like InfoWindow stuff).
   @spyhunter99 also decided to move CacheManager. It makes sense (as implementation requires a close link with osmdroid internals).
   3 other classes have also been moved: FolderOverlay, and the MapEventsOverlay/MapEventsReceiver couple. This is more questionable, but why not.

2. About the practical aspects, to answer to the question from @2ndGAB :
   I'm currently waiting for the release of osmdroid including those additions - once the house keeping mentionned by spyhunter will be done.
   Once this osmdroid version is released, I will update OBP, to remove all redundant classes.
   Until then, people can still raise issues about those classes in OBP project, I will try to provide support.
   But since the copy of sources to osmdroid, I don't perform any change on copied classes anymore. Their source code repository is now osmdroid.

Everything else in OBP will just stay in OBP: routes, POI and geocoding services, markers clustering, KML and GeoJSON. And I will continue to support related issues in OBP project (welcoming help from others!).