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

[question] fulfiling licensing terms when we use non-OSM data to represent AOOs and sites #817

Open
tlongers opened this issue Sep 8, 2022 · 2 comments

Comments

@tlongers
Copy link
Member

tlongers commented Sep 8, 2022

In some cases we represent areas of operation or sites using geospatial data that isn't from OSM, and is bound by different licensing agreements.

These usually include the requirement to cite the source, and link back to it. For example, we might want to use some geospatial data from the Myanmar Information Management Unit (MIMU), which publishes its licensing terms here:

3.1 All MIMU products and those of other development, humanitarian and peace-focused actors shared through the MIMU's website are available free of charge and cannot be sold or used for commercial purposes.
3.2 Users may copy, freely duplicate and further distribute these products and datasets provided that MIMU (or the original author where relevant) is clearly cited as the reference and that copies of the material are not sold.

Where we make use of such polygons and points, what methods could be used to fulfil the licensing requirement to cite the osurce? I can think of these three routes:

a) Add a citation within the popover for each polygon.
b) Update the general copyright/licensing in the bottom right corner of the maps.
c) Include the source of geospatial data as a source for the AOO datapoint itself, so it will appear in the list of sources in the source popover.

My preference is option "b". Currently our maps look like this:

image

If we used some MIMU data, it could look like this if we updated the citation area:

image

If we took that route we'd need to consider:

  • where we store the information on licencing. The location model has an attribute called location:origin that stores a plain flag for the source of geospatial information (e.g. "osm", "sfm", etc), which is currently only used to tell the tooling we use to sync with OSM which objects to ignore. The attribute location:source could be brought into play here too, containing a reference to a source entity for the source of geosptial information - in our model, this would be the most logical and consistent approach.
  • how we make the app aware of cases where there is a variety of geospatial sources. I'm not sure if we have a pattern in place that does something similar in the app.
  • design issues where the map might contain a larger number of possible sources, with attendant citation requirements e.g. OSM, UN body A, UN body B, Google, MIMU, some self-created stuff. Space may become limited.
  • probably some importer wrangling to make it all happen 😱

What's your take in this @hancush @smcalilly ?

@hancush
Copy link

hancush commented Sep 8, 2022

Hi, @tlongers!

Agree displaying sources on the map is most straightforward. Also agree location:source with a reference to a source is the most logical place to put source information, especially because we'll need both the source name and a URL to create the link in the credits.

The location import is separate from the main import and is much easier to adjust, so I don't anticipate it will be difficult to add the location source as its own field, or store the whole (or a subset of) the location metadata object on the model, in the same way we do the sfm object. From there, accessing this information in the app is trivial.

Re: design, we could always move credits into an obvious but collapsible panel, e.g., https://opengeo.tech/maps/leaflet-panel-layers/examples/collapsible-panel.html. That should address the space issue.

Thoughts?

@tlongers
Copy link
Member Author

tlongers commented Oct 6, 2022

We'll develop this further when we've done some work our side on the specific geo.

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

No branches or pull requests

2 participants