Skip to content

Conversation

@galen8183
Copy link
Contributor

Followup of #2657

Add GEospatial Ontario's (GEO's) 2018-2022 orthophotography WMS service from
https://geohub.lio.gov.on.ca/maps/lio::geospatial-ontario-imagery-data-services/about

Licensed under the OGL Ontario,
a license approved by the OSMF LWG

Regarding the licence attribution concerns in my previous PR (#2657 (comment)),
I'm really not sure what's wrong here... the source licence URL is/was already
linked in the attribution property, and like many other layers the license_url
links to the OSMF page on OGL variants. Please let me know if all of those
entries are incorrect, or if linking to a wiki page is in fact correct here.

Signed-off-by: Galen CC [email protected]

@andrewharvey andrewharvey force-pushed the canada-ontario-ortho branch from 6714e43 to 5555ccf Compare April 17, 2025 05:35
@andrewharvey
Copy link
Collaborator

andrewharvey commented Apr 17, 2025

The license_url doesn't have consistent use within existing sources and the current CONTRIBUTING guide and schema documentation aren't clear on what exactly this field should contain. In #790 (comment) I've proposed what I think we should use, but until it's documented I don't think we can expect too much of the field, and this PR uses it to point to documentation of the licensing permissions which is okay for the time being.

If we want the field to point to the publisher's statement on the data license, https://www.ontario.ca/page/copyright-information is probably the page to point to, then https://osmfoundation.org/wiki/OGL_Canada_and_local_variants would go under permission_url. But we'd want to get this schema change accepted and documented first (#790 (comment))

@andrewharvey
Copy link
Collaborator

What about the 2023-2027 layer? Should that be added to as best?

https://ws.geoservices.lrc.gov.on.ca/arcgis5/rest/services/AerialImagery/GEO_Imagery_Data_Service_2023to2027/ImageServer

@galen8183
Copy link
Contributor Author

galen8183 commented Apr 17, 2025

What about the 2023-2027 layer? Should that be added to as best?

It's documented as "coming soon", I'd be happy to add it now but perhaps it shouldn't be marked as best until it's complete. WDYT?

@andrewharvey
Copy link
Collaborator

It's documented as "coming soon", I'd be happy to add it now but perhaps it shouldn't be marked as best until it's complete. WDYT?

That's fine, can leave out for now and add later when it's ready I think.

@andrewharvey andrewharvey merged commit 1940bcd into osmlab:gh-pages May 16, 2025
1 check passed
@artemisquadatro
Copy link
Contributor

Hello all,

I’d like to know if the permission_osm field can be changed from "implicit" to "explicit".

LWG has reviewed Open Government Licence – Ontario and concluded that it is compatible with the ODbL. Please read the assessment below:

https://osmfoundation.org/wiki/Licensing_Working_Group/Minutes/2024-03-04#Assessment_of_Open_Government_License_-_Ontario

Given this ruling, I believe it is safe to change "implicit" "explicit" to allow it to be used in OSM editors.

@andrewharvey
Copy link
Collaborator

I’d like to know if the permission_osm field can be changed from "implicit" to "explicit".

I don't know the history behind that field, it's not mentioned on the contributing documentation at https://github.com/osmlab/editor-layer-index/blob/gh-pages/CONTRIBUTING.md so the only documentation is within the schema where it is described as "explicit/implicit permission by the owner for use in OSM".

Is there any reason we need to record this? I understand CC0 would be implicit permission, since the license doesn't mention OSM so we implicitly assume it's suitable for OSM. Other sources that may be copyrighted but the owner has provided direct support for OSM would be explicit as we have explicit permission from the owner for use in OSM.

But what about CC BY + waiver? I suppose that is explicit? But then if we have fields for the license the data is under, and then another field for the justification/further documentation on why this licnese is suitable, seems the permission_osm is not needed.

I've proposed changing how we record the licensing at #2605 but no feedback yet.

Given this ruling, I believe it is safe to change "implicit" "explicit" to allow it to be used in OSM editors.

I assume that a condition of being accepted into this index is the source can be used to improve OSM, regardless of the implicit/explicit permission.

Am I mistaken?

@artemisquadatro
Copy link
Contributor

I assume that a condition of being accepted into this index is the source can be used to improve OSM, regardless of the implicit/explicit permission.

Yes, any source included in the Editor Layer Index (ELI) is allowed to be used for mapping in OSM. However, layers marked as "implicit" don’t appear in the iD imagery selector. I'm not too entirely sure of the reasoning behind this, but it seems that only layers tagged as "explicit" are included in the iD imagery lists.

@andrewharvey
Copy link
Collaborator

Yes, any source included in the Editor Layer Index (ELI) is allowed to be used for mapping in OSM. However, layers marked as "implicit" don’t appear in the iD imagery selector. I'm not too entirely sure of the reasoning behind this, but it seems that only layers tagged as "explicit" are included in the iD imagery lists.

I couldn't find anything within the iD or ELI code that would do that? Where's the code?

@artemisquadatro
Copy link
Contributor

Yes, any source included in the Editor Layer Index (ELI) is allowed to be used for mapping in OSM. However, layers marked as "implicit" don’t appear in the iD imagery selector. I'm not too entirely sure of the reasoning behind this, but it seems that only layers tagged as "explicit" are included in the iD imagery lists.

I couldn't find anything within the iD or ELI code that would do that? Where's the code?

My apologies for the extremely late reply. Couldn't find any code but this layer along with the new NRCan-HRDEM-DTM both marked as "implicit" do not show on the ID layer selector.

@andrewharvey
Copy link
Collaborator

My apologies for the extremely late reply. Couldn't find any code but this layer along with the new NRCan-HRDEM-DTM both marked as "implicit" do not show on the ID layer selector.

It's likely that iD hasn't taking in the updates yet, this was merged May 16th but iD released May 12 (so wouldn't have included this change), there was a patch release Jun 4th but it may not have taken in ELI updates.

Currently iD only takes ELI updates during the iD release which is ad-hoc and infrequent.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants