Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Osm license #52

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Osm license #52

wants to merge 13 commits into from

Conversation

brunesto
Copy link

@brunesto brunesto commented Oct 21, 2020

Hello this is to resolve #51 - the osm tile usage policy . it does not remove the app, just adds copyright label and changes the way TileRetriever is instanciated

Adding the copyright label is just a couple of lines in MapView

For beeing able to easily use own tile provider (e.g. in the MobileSample class) it required more changes: Basically TileProviderRetriever is gone, instead the TileRetriever has to passed as a constructor arg to MapView and BaseMap. Hence CachedOsmTileRetriever does not have static fields methods anymore.

I wanted to keep the changes small, so 2 further changes are probably needed:

  • Instead of moving CachedOsmTileRetriever around I just modified module-info.java
  • It breaks compatibility, so an empty MapView constructor would be needed

maps/src/main/java/com/gluonhq/maps/MapView.java Outdated Show resolved Hide resolved

static {
{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a huge fan of double brace initialization. May be add a constructor instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if the logic was appropriate before you made the change., but now we have different instances of CacheThread writing to the same cache directory.

Copy link
Author

@brunesto brunesto Oct 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean there were 2 instances of CacheThread because the sample created 2 CachedOsmTileRetriever, right?
If this was the issue, I just added a String parameter to the CachedOsmTileRetriever constructor and it is used as suffix to build the cache root path cacheRoot.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a big fan of the implementation in CachedOsmTileRetriever. If you check CacheThread, you will find that it has an indefinite while loop and it keep on running. The deactivate() which is supposed to break the while loop is never called. The whole class needs to be re-written IMO.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please remove the change where you added a string name as suffix for cache directory? It is better to keep the class as it is. I will log an issue with the shortcomings on the class.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reverted the commit that added suffix to cache

@@ -41,4 +41,5 @@
* @return an image representing the tile
*/
Image loadTile(int zoom, long i, long j);
String copyright();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method makes more sense in OsmTileRetriever.

Copy link
Author

@brunesto brunesto Oct 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure? In this case MapView would have to accept a OsmTileRetriever instead of TileRetriever as its constructor argument.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the delay. I somehow missed the notifications.

I am not sure. @jperedadnr do you have a preference here? Will all types of TileRetriever need a copyright license and it make sense to add "copyright" to TileRetriever interface?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've done a full review of the PR, looks good to me, with some comments that should be addressed.

About the copyright, yes, it might not be mandatory, but I'd say it can stay with TileRetriever.

In my comments, I suggest to use CSS for the label, in which case you can set its visibility to false. Even setting the copyright text to null won't show it. (We don't really have a way to enforce the developer to use/show the license).

@abhinayagarwal
Copy link
Collaborator

Hi @brunesto ,

Thank you for the PR. Please sign the Gluon CLA as per the Gluon contribution requirement.

@jperedadnr
Copy link
Contributor

@brunesto We have just merged a pending PR, can you fix the conflicts?

@brunesto
Copy link
Author

brunesto commented Oct 29, 2020

@jperedadnr I think it's done

@jperedadnr jperedadnr added the CLA signed Author has signed the Gluon CLA label Nov 3, 2020
maps/src/main/java/com/gluonhq/impl/maps/BaseMap.java Outdated Show resolved Hide resolved
maps/src/main/java/com/gluonhq/maps/MapView.java Outdated Show resolved Hide resolved
@@ -37,4 +37,5 @@

exports com.gluonhq.maps;
exports com.gluonhq.maps.tile;
exports com.gluonhq.impl.maps.tile.osm;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we are going to export this package, it shouldn't be under impl, so osm should be under com.gluonhq.maps.tile ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see the original comment: "...Instead of moving CachedOsmTileRetriever around I just modified module-info.java ..."

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look at it but I don't see a simple way to split the CachedOsmTileRetriever between impl and exported packaged, so I prefer not to make any changes for that in the PR.

@@ -68,7 +70,28 @@

@Override
public void start(Stage stage) {
MapView view = new MapView();
TileRetriever osm=new CachedOsmTileRetriever() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this for demo only, why don't we already provide this implementation as part of com.gluonhq.maps.tile.osm, exactly as is? Or with a name like DefaultCachedOsmTileRetriever ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I think it is better if tile provider is explicit, i.e. the developer should know where the tiles are coming from. Also like this it is easy to modify the url to switch to a different provider.

/**
* Create a MapView component.
*/
public MapView() {
baseMap = new BaseMap();
public MapView(TileRetriever tileRetriever) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of compatibility, we could keep the no-args constructor, and default to a possible implementation of CachedOsmTileRetriever (see comment below)?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it... I would prefer to not have a no-args constructor actually, for the reasons in comment above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA signed Author has signed the Gluon CLA
Projects
None yet
Development

Successfully merging this pull request may close these issues.

usage policy of osm tiles
3 participants