Skip to content

use of OpenStreetMap data without attribution (attributed to Mapbox in master version) #3766

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

Closed
matkoniecz opened this issue May 21, 2020 · 32 comments
Labels

Comments

@matkoniecz
Copy link
Contributor

matkoniecz commented May 21, 2020

Summary:

OpenStreetMap data requires attribution to be used and this attribution is missing, at least on my phone.

Steps to reproduce:

Start app, switch to "nearby" tab with map without attribution.

Attribution hidden in settings also would be insufficient, but not even that is done.

Data is clearly from OpenStreetMap (with contour lines added) as confirmed by looking at data unique to OSM and not appearing elsewhere.

See https://www.openstreetmap.org/copyright

System logs:

Not attempted, will add if missing attribution is something device-specific.

Device and Android version:

Mi A2 Lite, running stock Android Zero, in Android 9 version.

Commons app version:

2.12.3~dc08a5e88

Screen-shots:

Will add if problem will turn out to be device-specific.

Would you like to work on the issue?

I am not planning to do this, I have already more OpenStreetMap related plans that I am able to do and this is something that users of data are legally obligated to do.

More info

You are using OpenStreetMap data for displaying maps. Great and thanks for using this map data!

It is nice to see that you use what I (and thousands of other mappers) collected. But you are doing it without a required attribution, that according to the licence must be clearly visible to all users.

This is quite embarrassing, given that Wikimedia Commons community is generally excellent at respecting copyright and copyright like restrictions.

@maskaravivek
Copy link
Member

Yes, unfortunately, the current production version of the app doesn't have attribution. It seems that the attribution got removed sometime before the last release.

It was present in the previous versions of the app. A lot of changes were done recently on the maps page because of which it might have got missed. See #2911 for reference.

Our latest master has the attribution present and I believe it would be released soon to production. cc @misaochan

Screenshots from latest master:

Screen Shot 2020-05-21 at 11 52 56 AM

Screen Shot 2020-05-21 at 11 53 22 AM

@matkoniecz
Copy link
Contributor Author

It is great that it is better in master version.

But note that you are using OpenStreetMap data, hosted and styled by Mapbox.

Mapbox may have their own additional requirements.

But https://www.openstreetmap.org/copyright requires notice associated with the map reasonably calculated to make any Person that views the map aware that content was obtained from the OpenStreetMap database.

It is requirement that cannot be modified or changed by Mapbox, and showing "Mapbox" is not fulfilling it. It must be attributed to OpenStreetMap (though Mapbox may be additionally credited for map styling and hosting).

Note section 4.3 of the Open Database License used by OpenStreetMap:

"include
a notice associated with the Produced Work reasonably calculated to
make any Person that uses, views, accesses, interacts with, or is
otherwise exposed to the Produced Work aware that Content was
obtained from the Database, Derivative Database, or the Database as
part of a Collective Database, and that it is available under this
License."

I know that what you show in this images it is apparently standard attribution proposed by Mapbox. But I hope that at least in this case proper attribution will be used (yes, I know that Moovit, Mapbox, FB, Snapchat are also hiding attribution and using OSM data anyway and describing maps in way suggesting that they collected data on their own).

@matkoniecz matkoniecz changed the title Illegal use of OpenStreetMap data without attribution use of OpenStreetMap data without attribution May 21, 2020
@matkoniecz
Copy link
Contributor Author

matkoniecz commented May 21, 2020

Using OpenStreetMap data and using "Mapbox" as an attribution is like taking Wikimedia Commons image (on license requiring attribution) and using "author: internet" or "author: me, I found it with google" as an attribution.

Or to match it more exactly - hosting it on AWS and using "author: Amazon" as an attribution.

@matkoniecz matkoniecz changed the title use of OpenStreetMap data without attribution use of OpenStreetMap data without attribution (attributed to Mapbox in master version) May 21, 2020
@maskaravivek
Copy link
Member

Thanks for the detailed explanation @matkoniecz. We will fix it as soon as possible.

Currently when the (i) icon is clicked on the map, a dialog box appears as shown above. It shows (c) OpenStreetMap. Is it not the right way of attributing OpenStreetMap? Should the attribution be in the text on the map itself? As shown in this screenshot from the https://www.openstreetmap.org/copyright page.

Screen Shot 2020-05-21 at 7 08 25 PM

Tagging @neslihanturan as she is our designer. She might have ideas on how we could display proper attribution.

@matkoniecz
Copy link
Contributor Author

matkoniecz commented May 22, 2020

(i) icon is clicked on the map, a dialog box appears as shown above. It shows (c) OpenStreetMap. Is it not the right way of attributing OpenStreetMap?

The problem is that

  • it requires clicking on (i) icon while license requires attribution to be "reasonably calculated to make any Person that views the map aware"
    • and it is quite obvious that normal user will not click on every icon and therefore will never see it
  • there is a big Mapbox logo and popup lists (c) Mapbox first
    • So normal user will see solely Mapbox attribution and even popup window is not clarifying situation
    • it is done in way suggesting that data is from Mapbox. As hosting is not copyright protected sole copyrightable work by Mapbox is map styling. All map data is (c) OpenStreetMap.

"(c) OpenStreetMap" is attribution fulfilling license. "(c) OpenStreetMap contributors" is suggested, but not required by license. For 100% compliance either linking to full license or mentioning ODBL would be nice.

But the major and fundamental problem is that OpenStreetMap attribution is effectively hidden, while clear Mapbox attribution is shown.

Note that you may be required to show Mapbox logo by their terms of service, so you may need to show both

  • "(c) OpenStreetMap (ODBL)", "(c) OpenStreetMap", "(c) OpenStreetMap contributors" or other clearly visible attribution fulfilling license. This part must not be affected by Mapbox terms (though their design decision may make more complicated to apply proper attribution)
  • Mapbox logo (one of perks of more expensive plan is that Mapbox is not requiring you to show Mapbox logo - note that Mapbox is unable to waive OpenStreetMap license)

disclaimer: I am not a lawyer, I am biased toward OpenStreetMap attribution as an OpenStreetMap mapper.

But I am pretty sure that "Mapbox" with hidden "(c) Mapbox (c) OpenStreetMap" is not making clear that all data is from OpenStreetMap.

And "reasonably calculated to make any Person that views the map aware (...)" is nor fulfilled by attribution hidden behind icon that normal user will never click.

@matkoniecz
Copy link
Contributor Author

matkoniecz commented May 22, 2020

BTW, thanks for very quick reaction made by actual humans - unlike to some major corporations using OSM data without any attribution (or extremely poor one, designed to mislead user).

And I am blaming any confusion 100% on Mapbox that misleads its customers and makes unusually hard to properly attribute OpenStreetMap. With its website and documentation hiding knowledge that basically no data used in its products is Mapbox-owned and that clearly visible attribution to OpenStreetMap is required.

@matkoniecz
Copy link
Contributor Author

I added this app to page listing entities using OpenStreetMap data without attribution - in https://wiki.openstreetmap.org/w/index.php?title=Lacking_proper_attribution&type=revision&diff=1997453&oldid=1997351

@maskaravivek
Copy link
Member

Thanks for the detailed explanation. I will bump up this issue internally.

But the major and fundamental problem is that OpenStreetMap attribution is effectively hidden, while clear Mapbox attribution is shown.

Would you be able to point us to any app/website that correctly shows the Mapbox and OpenStreetMap attributions? I am requesting this from you with the assumption that you might have come across quite a few open source app that are using these maps.

Tagging few of our collaborators here:
@misaochan @nicolas-raoul @neslihanturan @sivaraam

@sivaraam
Copy link
Member

sivaraam commented Jun 4, 2020

Would you be able to point us to any app/website that correctly shows the Mapbox and OpenStreetMap attributions?

I think the info in the following page is a good start: https://wiki.openstreetmap.org/wiki/They_are_using_OpenStreetMap

I'll let you know if I find something better.

@sivaraam
Copy link
Member

sivaraam commented Jun 4, 2020

I think the info in the following page is a good start: https://wiki.openstreetmap.org/wiki/They_are_using_OpenStreetMap

Mentioning the source for the sake of completeness:

See also They are using OpenStreetMap for rather correct attribution examples.

Source

@maskaravivek
Copy link
Member

https://wiki.openstreetmap.org/wiki/They_are_using_OpenStreetMap

Thanks @sivaraam. It would be great if someone could check a few apps from this list and share a screenshot here of the map page from apps with proper attribution. It would be easier for anyone to pick up the fix that way.

@matkoniecz
Copy link
Contributor Author

matkoniecz commented Jun 4, 2020

Would you be able to point us to any app/website that correctly shows the Mapbox and OpenStreetMap attributions? I am requesting this from you with the assumption that you might have come across quite a few open source app that are using these maps.

Sadly none of apps that I use is in Mapbox ecosystem, and all Mapbox clients that I know (FB, Snapchat and others) refuse to attribute OSM.


But from quick check https://foursquare.com/explore?mode=url&near=Gda%C5%84sk%2C%20Poland&nearGeoId=72057594041027370 website has OK attribution text, though "OpenStreetMap" should link to https://www.openstreetmap.org/copyright


https://nuclearsecrecy.com/nukemap/ (though I admit that phone styling suffers from too small text everywhere - but as it is not applied to just attribution I am OK with that, also for some reason wrong license is given).

Part applicable here with a fixed license would be "Map data © OpenStreetMap contributors (ODBL), Imagery © Mapbox"

@misaochan
Copy link
Member

misaochan commented Jun 4, 2020

If the format at https://foursquare.com/explore?mode=url&near=Gda%C5%84sk%2C%20Poland&nearGeoId=72057594041027370 is acceptable, that would be my preference. On mobile screens there is very little space.

I will add this to our 2.13.1 hotfix list.

@matkoniecz
Copy link
Contributor Author

matkoniecz commented Jun 4, 2020

"© Mapbox © OpenStreetMap" in always[0] visible text, with Mapbox linking to whatever Mapbox requires and OpenStreetMap linking to https://www.openstreetmap.org/copyright should be OK.

Or "© Mapbox © OpenStreetMap (ODBL)" for version without links.

Disclaimer: I am not a lawyer, it is what I think that license requires and would be enough to keep me happy.

[0]always visible= "always visible if map is shown of size big enough that such label would fit on the map without covering very significant part of the map"

Dislaimer 2: I have not checked what Mapbox requires from you.

@ashishkumar468
Copy link
Collaborator

I looked into the code and read the docs, seems like as of now MapBox SDK does not support custom Attribution View

@misaochan
Copy link
Member

misaochan commented Jun 11, 2020

Interesting, it does say that "You may not otherwise alter the Mapbox wordmark or text attribution notice", so it seems to me that if we made this change we would be breaching Mapbox's terms.

@matkoniecz Any chance you can take this up with Mapbox themselves?

@sivaraam
Copy link
Member

sivaraam commented Jun 11, 2020

Interesting, it does say that "You may not otherwise alter the Mapbox wordmark or text attribution notice", so it seems to me that if we made this change we would be breaching Mapbox's terms.

Yes. But they also say this:

By default, the Mapbox wordmark and information button are located on the bottom left of the map. You may move these elements to a different position, but they must stay on the map view. For display options, see the API documentation for the UiSettings class. You may also reposition these elements within the activity’s XML layout.

Mapbox includes this built-in information button for your convenience. If you decide not to use it, you must include attribution on the map in a text format. The attribution must include © Mapbox as a link to https://www.mapbox.com/about/maps/, "© OpenStreetMap" as a link to http://www.openstreetmap.org/copyright, and "Improve this map" as a link to https://www.mapbox.com/map-feedback/. If you choose to use one of our Satellite styles, you must also include © DigitalGlobe as a link to https://www.digitalglobe.com/. Note that in the future, Mapbox may update the information on the attribution panel and require additional attribution to our suppliers.

Additionally, you must provide a telemetry opt-out option elsewhere in your application if you choose not to use the built-in information button.

Observe how the second paragraph provides us with an option to include on the map in a text format which is exactly in the format that OSM requires (in addition to some Mapbox requirements).

I guess the problem is they don't say how that could be done 🤔

@matkoniecz
Copy link
Contributor Author

@matkoniecz Any chance you can take this up with Mapbox themselves?

I can try, but Mapbox is remarkably slow where it comes to topic of attributing OpenStreetMap.

@ashishkumar468
Copy link
Collaborator

@matkoniecz I've looked into their code, although they have mentioned that the text could be changed, there seems to be no public method to update the same. Should we try creating an issue in their repository(if not already) to maybe expose methods to do so?

@misaochan
Copy link
Member

Hi @matkoniecz , any luck with Mapbox? I feel like it will be much more beneficial to your cause for Mapbox to support this in their SDK. Otherwise all the apps that are using the Mapbox Android SDK will be stuck looking for lengthy, potentially hack-ish workarounds since they have not exposed methods to modify the attribution.

@matkoniecz
Copy link
Contributor Author

matkoniecz commented Jul 1, 2020

I got no response from Mapbox (their response time on topic of attribution is in months, in some cases more than year) but I got some info on Telegram channel (OpenStreetMap dev):

By default attribution with the information button is included in the sdk. You can adjust it with XML or go into the UiSettings object

I have not tested it so far.

@ashishkumar468
Copy link
Collaborator

I have opened an issue in the Mapbox's repo raising the concern, hopefully we will get some clarity from over there.

@sivaraam
Copy link
Member

sivaraam commented Jul 18, 2020

I guess the problem is they don't say how that could be done.

Some time ago, I happened to contact Mapbox support about this with hope of getting something useful. This is what they say:

You can put the text attribution on the map instead of using our UISetting, but you would still need to link to the attribution links https://www.mapbox.com/about/maps/ and http://www.openstreetmap.org/copyright somehow, such as in the menu, or by adding a TextView on the map. In addition to the attribution links, you will need to put the telemetry opt-out button somewhere, such as in your settings.

My support request, for reference Hi,

In https://docs.mapbox.com/help/how-mapbox-works/attribution/#mapbox-maps-sdk-for-android it is said that we can include attribution on the map in a text format. Due to a requirement, we would like to provide attribution in text format on the map rather than showing the attribution dialog using the UiSetting class.

It's not clear how we could provide that attribution in text format using the MapBox Android SDK. Can you help us with this?

The only hint is that they mention adding a TextView on the map.

Edit: Add question sent to support

@misaochan
Copy link
Member

@ashishkumar468 just informed me that his workstation is down and repairs will take a while due to the Covid situation where he is. We will look into this further when he is able to come back.

@sivaraam
Copy link
Member

sivaraam commented Jul 24, 2020

Some time ago, I happened to contact Mapbox support about this with hope of getting something useful.

Just an update about this.

I asked them for an example or specific instructions on how to achieve this.

Thanks for the response. I'll look into and let you know if we could find a way to add a TextView on the map. In the meantime, if you could share specific instructions/examples of how to achieve this that would be great.

This is the response that I got:

Because this is not a standard use of our attribution text, the implementation will be up to you.

So, no hopes there.

ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Jul 29, 2020
Added open streetmap attribution in nearby
ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Jul 29, 2020
* Added OPENSTREET attribution in nearby
misaochan pushed a commit that referenced this issue Aug 11, 2020
* Fixes #3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string
@ashishkumar468
Copy link
Collaborator

This is fixed on 2.13, closing this PR, the changes should be visible in the next release.

@misaochan
Copy link
Member

Hi @matkoniecz , this should be out in our current beta release, v2.13.1. Could you please register for beta testing and let us know if it works for you? Thanks!

misaochan added a commit that referenced this issue Sep 14, 2020
* #3624 DateTimeFormat wrong - match pattern returned from servers (#3625)

* Revert "Fixes: #3179 Make category search non case-sensitive (#3326)" (#3636)

Simply lower casing the name of the category sent to the server
doesn't result in the server doing a case insensitive category
search. In fact, it reduces the category search space as only
categories that has a lower case character is searched even
if the search text contains upper case characters.

The test case did not catch this issue as the first character
of the title is case insensitive[1].

So, revert the changes done in commit afdeaae.

See further disucssion in the issue thread of #3179 starting
from [2].

[1]: https://www.mediawiki.org/wiki/Manual:Page_title
[2]: #3179 (comment)

* Bugfix/security exception (#3627)

* Fixes #3626
* Check is file is actually created before writing to file, file picker android

* Handle Security exception

* Fixes #3436 and #2881: Media Detail design Overhaul (#3505)

* ic_map_dark_24dp: map icon for white background

* ic_info_outline_dark_24dp: info icon for dark background

* MediaDetailFragment: update the spacer as per image aspect ratio

* fragment_media_detail: design overhaul

* fragment_media_detail: remove redundant background color statements

* make requested changes

* add dark mode support

* minor ui tweak

* white map icon in dark mode

* make rquested changes

* make requested changes to layout

* fix misalignment of category list

* subtle amendments

* convert comments to javadocs

* minor amendments

* minor changes

* add styles for media detail

* Media detail fragment refactored

* make suggested changes

* minor name fix

* fix the delete button border

* Fixes #3639 (Fix Save State implementation of CheckBoxTriState ) (#3686)

* Add #3723 and #3721 to 2.13 release, fix conflicts

Conflicts were caused by merging #3723 before #3721 , so I just rolled both into one commit.

* Fix NullPointer when clicking on image in MediaDetailFragment (#3730)… (#3739)

* Update changelog.md

* Versioning for v2.13

* Fixes #3705 (Crash when viewing pic I just uploaded) (#3782)

* Fixes #3705
* Let the MediaDetailPager fragment know when the contributions have been updated

* Handle NPE, null check on adapter in MediaDetailPagerFragment

* Fixed BookmarkLocationsDao DB migration (#3793)

* Fixes #3725 (#3795)

* Downgraded okhttp version to support Api 19 devices

* Handled null CompoundDrawable[2] in etTitle-> UploadMediaDetailsFragment (#3828)

* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception (#3830)

* Fixes #3829
* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception

* removed unused imports, handled possible exceptions

* Let Fresco handle the downsampling of image

* invalidate in onTransformEnd

* Expose an interface TransformationListener in ZoomableDraweeView to listen to transformation change end

* removed photoView dependency

* removed unused imports in ZoomableActivity

* Bugfix, expand/collapse

* changed functio name

* Bugfix/p18 uploads (#3869)

* updated gradle plugin version

* BugFix #3856
* Do not use preference for deciding acceptable lat long for nearby uploads, instead save the corresponding location in the Contribution via UploadItem

* Marshall contribution's hasInvalidLocation

* reset un-related changes

* Fixed test cases

* Minor code formatting and docs

* Fixes #3882 (#3883)

* Make hasInvalidLocation non-null integer with default value 0

Co-authored-by: Ashish Kumar <[email protected]>

* Fixes #3766, Added OPENSTREET attribution (#3889)

* Fixes #3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string

* Versioning and changelog for v2.13.1 (#3908)

* Update changelog.md

* Versioning for v2.13.1

* Fixes #3914 (#3915)

* Verify user login before setting upload count

* fixed compile-time error

* fix erros

* delete emptied files

* remove empty file CategoriesModel.java

Co-authored-by: Seán Mac Gillicuddy <[email protected]>
Co-authored-by: Kaartic Sivaraam <[email protected]>
Co-authored-by: Kshitij Bhardwaj <[email protected]>
Co-authored-by: Vitaly V. Pinchuk <[email protected]>
Co-authored-by: Josephine Lim <[email protected]>
Co-authored-by: Ashish Kumar <[email protected]>
ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Oct 10, 2020
* commons-app#3624 DateTimeFormat wrong - match pattern returned from servers (commons-app#3625)

* Revert "Fixes: commons-app#3179 Make category search non case-sensitive (commons-app#3326)" (commons-app#3636)

Simply lower casing the name of the category sent to the server
doesn't result in the server doing a case insensitive category
search. In fact, it reduces the category search space as only
categories that has a lower case character is searched even
if the search text contains upper case characters.

The test case did not catch this issue as the first character
of the title is case insensitive[1].

So, revert the changes done in commit afdeaae.

See further disucssion in the issue thread of commons-app#3179 starting
from [2].

[1]: https://www.mediawiki.org/wiki/Manual:Page_title
[2]: commons-app#3179 (comment)

* Bugfix/security exception (commons-app#3627)

* Fixes commons-app#3626
* Check is file is actually created before writing to file, file picker android

* Handle Security exception

* Fixes commons-app#3436 and commons-app#2881: Media Detail design Overhaul (commons-app#3505)

* ic_map_dark_24dp: map icon for white background

* ic_info_outline_dark_24dp: info icon for dark background

* MediaDetailFragment: update the spacer as per image aspect ratio

* fragment_media_detail: design overhaul

* fragment_media_detail: remove redundant background color statements

* make requested changes

* add dark mode support

* minor ui tweak

* white map icon in dark mode

* make rquested changes

* make requested changes to layout

* fix misalignment of category list

* subtle amendments

* convert comments to javadocs

* minor amendments

* minor changes

* add styles for media detail

* Media detail fragment refactored

* make suggested changes

* minor name fix

* fix the delete button border

* Fixes commons-app#3639 (Fix Save State implementation of CheckBoxTriState ) (commons-app#3686)

* Add commons-app#3723 and commons-app#3721 to 2.13 release, fix conflicts

Conflicts were caused by merging commons-app#3723 before commons-app#3721 , so I just rolled both into one commit.

* Fix NullPointer when clicking on image in MediaDetailFragment (commons-app#3730)… (commons-app#3739)

* Update changelog.md

* Versioning for v2.13

* Fixes commons-app#3705 (Crash when viewing pic I just uploaded) (commons-app#3782)

* Fixes commons-app#3705
* Let the MediaDetailPager fragment know when the contributions have been updated

* Handle NPE, null check on adapter in MediaDetailPagerFragment

* Fixed BookmarkLocationsDao DB migration (commons-app#3793)

* Fixes commons-app#3725 (commons-app#3795)

* Downgraded okhttp version to support Api 19 devices

* Handled null CompoundDrawable[2] in etTitle-> UploadMediaDetailsFragment (commons-app#3828)

* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception (commons-app#3830)

* Fixes commons-app#3829
* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception

* removed unused imports, handled possible exceptions

* Let Fresco handle the downsampling of image

* invalidate in onTransformEnd

* Expose an interface TransformationListener in ZoomableDraweeView to listen to transformation change end

* removed photoView dependency

* removed unused imports in ZoomableActivity

* Bugfix, expand/collapse

* changed functio name

* Bugfix/p18 uploads (commons-app#3869)

* updated gradle plugin version

* BugFix commons-app#3856
* Do not use preference for deciding acceptable lat long for nearby uploads, instead save the corresponding location in the Contribution via UploadItem

* Marshall contribution's hasInvalidLocation

* reset un-related changes

* Fixed test cases

* Minor code formatting and docs

* Fixes commons-app#3882 (commons-app#3883)

* Make hasInvalidLocation non-null integer with default value 0

Co-authored-by: Ashish Kumar <[email protected]>

* Fixes commons-app#3766, Added OPENSTREET attribution (commons-app#3889)

* Fixes commons-app#3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string

* Versioning and changelog for v2.13.1 (commons-app#3908)

* Update changelog.md

* Versioning for v2.13.1

* Fixes commons-app#3914 (commons-app#3915)

* Verify user login before setting upload count

* fixed compile-time error

* fix erros

* delete emptied files

* remove empty file CategoriesModel.java

Co-authored-by: Seán Mac Gillicuddy <[email protected]>
Co-authored-by: Kaartic Sivaraam <[email protected]>
Co-authored-by: Kshitij Bhardwaj <[email protected]>
Co-authored-by: Vitaly V. Pinchuk <[email protected]>
Co-authored-by: Josephine Lim <[email protected]>
Co-authored-by: Ashish Kumar <[email protected]>
ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Oct 10, 2020
* commons-app#3624 DateTimeFormat wrong - match pattern returned from servers (commons-app#3625)

* Revert "Fixes: commons-app#3179 Make category search non case-sensitive (commons-app#3326)" (commons-app#3636)

Simply lower casing the name of the category sent to the server
doesn't result in the server doing a case insensitive category
search. In fact, it reduces the category search space as only
categories that has a lower case character is searched even
if the search text contains upper case characters.

The test case did not catch this issue as the first character
of the title is case insensitive[1].

So, revert the changes done in commit afdeaae.

See further disucssion in the issue thread of commons-app#3179 starting
from [2].

[1]: https://www.mediawiki.org/wiki/Manual:Page_title
[2]: commons-app#3179 (comment)

* Bugfix/security exception (commons-app#3627)

* Fixes commons-app#3626
* Check is file is actually created before writing to file, file picker android

* Handle Security exception

* Fixes commons-app#3436 and commons-app#2881: Media Detail design Overhaul (commons-app#3505)

* ic_map_dark_24dp: map icon for white background

* ic_info_outline_dark_24dp: info icon for dark background

* MediaDetailFragment: update the spacer as per image aspect ratio

* fragment_media_detail: design overhaul

* fragment_media_detail: remove redundant background color statements

* make requested changes

* add dark mode support

* minor ui tweak

* white map icon in dark mode

* make rquested changes

* make requested changes to layout

* fix misalignment of category list

* subtle amendments

* convert comments to javadocs

* minor amendments

* minor changes

* add styles for media detail

* Media detail fragment refactored

* make suggested changes

* minor name fix

* fix the delete button border

* Fixes commons-app#3639 (Fix Save State implementation of CheckBoxTriState ) (commons-app#3686)

* Add commons-app#3723 and commons-app#3721 to 2.13 release, fix conflicts

Conflicts were caused by merging commons-app#3723 before commons-app#3721 , so I just rolled both into one commit.

* Fix NullPointer when clicking on image in MediaDetailFragment (commons-app#3730)… (commons-app#3739)

* Update changelog.md

* Versioning for v2.13

* Fixes commons-app#3705 (Crash when viewing pic I just uploaded) (commons-app#3782)

* Fixes commons-app#3705
* Let the MediaDetailPager fragment know when the contributions have been updated

* Handle NPE, null check on adapter in MediaDetailPagerFragment

* Fixed BookmarkLocationsDao DB migration (commons-app#3793)

* Fixes commons-app#3725 (commons-app#3795)

* Downgraded okhttp version to support Api 19 devices

* Handled null CompoundDrawable[2] in etTitle-> UploadMediaDetailsFragment (commons-app#3828)

* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception (commons-app#3830)

* Fixes commons-app#3829
* DownSample Upload image to be shown in UploadMediaDetailFragment to handle OOM, Bitmap Too large exception

* removed unused imports, handled possible exceptions

* Let Fresco handle the downsampling of image

* invalidate in onTransformEnd

* Expose an interface TransformationListener in ZoomableDraweeView to listen to transformation change end

* removed photoView dependency

* removed unused imports in ZoomableActivity

* Bugfix, expand/collapse

* changed functio name

* Bugfix/p18 uploads (commons-app#3869)

* updated gradle plugin version

* BugFix commons-app#3856
* Do not use preference for deciding acceptable lat long for nearby uploads, instead save the corresponding location in the Contribution via UploadItem

* Marshall contribution's hasInvalidLocation

* reset un-related changes

* Fixed test cases

* Minor code formatting and docs

* Fixes commons-app#3882 (commons-app#3883)

* Make hasInvalidLocation non-null integer with default value 0

Co-authored-by: Ashish Kumar <[email protected]>

* Fixes commons-app#3766, Added OPENSTREET attribution (commons-app#3889)

* Fixes commons-app#3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string

* Versioning and changelog for v2.13.1 (commons-app#3908)

* Update changelog.md

* Versioning for v2.13.1

* Fixes commons-app#3914 (commons-app#3915)

* Verify user login before setting upload count

* fixed compile-time error

* fix erros

* delete emptied files

* remove empty file CategoriesModel.java

Co-authored-by: Seán Mac Gillicuddy <[email protected]>
Co-authored-by: Kaartic Sivaraam <[email protected]>
Co-authored-by: Kshitij Bhardwaj <[email protected]>
Co-authored-by: Vitaly V. Pinchuk <[email protected]>
Co-authored-by: Josephine Lim <[email protected]>
Co-authored-by: Ashish Kumar <[email protected]>
ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Oct 10, 2020
* Fixes commons-app#3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string
ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Oct 10, 2020
* Fixes commons-app#3766
* Added OPENSTREET attribution in nearby

* Added custom text attribution in Nearby

* Deleted unused class CustomBorderTextView

* review suggested changes

* modified telemetry summary string
@matkoniecz
Copy link
Contributor Author

matkoniecz commented Mar 12, 2021

Sorry for delay! I see that it is now fixed, thanks!

I updated list at OSM Wiki in https://wiki.openstreetmap.org/w/index.php?title=Lacking_proper_attribution&diff=2125175&oldid=2124271

Screenshot_20210312-173148

@misaochan
Copy link
Member

Happy to hear that, @matkoniecz ! Any chance of updating your Google Play review? ;)

@matkoniecz
Copy link
Contributor Author

matkoniecz commented Mar 17, 2021

Thanks for a reminder, also fixed! (now also response should be changed, currently it is quite not fitting :) )

@misaochan
Copy link
Member

Hmm, I can't seem to find my old response, I guess it might be automatically hidden when the review is updated? Anyway, thanks a lot @matkoniecz . :)

@matkoniecz
Copy link
Contributor Author

matkoniecz commented Mar 17, 2021

screen04

I edited it to include original complaint in case that someone would see it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants