Open Data License/Regional Cuts - Guideline
Be aware that this page can be edited by any registered user and does not represent the views of the OSMF. The data is licensed by the OSM Foundation as granted by the contributor terms. Refer to the OSM Foundation website for a more authoritative answer to legal questions: |
Community Guideline - Regional Cuts
Background: What is the problem?
This primarily relates to making and publicly publishing visual 2D maps, (a Produced Work within the terms of our ODbL license), and where the map covers a very large, probably global, area.
If you publish such a map, you may want to make some regions from OpenStreetMap data and some from data provided elsewhere. We will use the phrase "Regional Cut" to define a geographic region that you take from OpenStreetMap. If you can think of a better term, please propose.
The guideline and examples
Status: Endorsed by the OSMF board 2014-06-06. Read the formal guideline.
Open issues, use cases, discussion
Any text here is NOT part of the guideline!
Should there be minimum area limit? How small?
Question to OpenStreetMap community: How big an area? Country-wide or smaller? ... for example cities?
Things to consider:
- City-scale have been "allowed" in the past ... i.e. it has happened but as a community we have never discussed the ramifications. Good, bad?
- The issue is probably not one of absolute size but of connection between the Regional Cut and the data surrounding it: roads, railways etc. Less is best?
- What is a reasonable boundary? … countries are well defined admin boundaries … and GIS folks operated all the time on admin boundaries.
Please add your thoughts
- I can see that a common use case could be for one regional entity - e.g. a city administration - to want to add a few kilometres of hinterland from OSM. I.e. the main thing on the site is their city map made from their data, but they provide a bit of buffer around the city made from OSM (because they have no own data for that area). This use case does not necessarily require special consideration because it can mostly be served by a "map overlay" technique like we had in CC-BY-SA times. However if we wanted to allow making a combined city+surroundings database without share-alike, then both the "only country size" and the "no holes" rule would have to be adapted. --Frederik Ramm (talk) 18:41, 7 April 2014 (UTC)
- 1) I consider administrative boundaries only as one of many choices (so current rule "There is a clear boundary around the Regional Cut." is IMHO really fine) and 2) I consider a minimum of "whole country" as conflicting with desired uses. Think of a web site for husky tours in Lapland - there's no project inherent need to contain more than only certain parts of Finland, Sweden and Norway, and there's no inherent need to end at administrative borders (but rather climatic + geologic borders). Think of a project about Arctic & Antarctica - there is no country in this area, so obeying the current rule "The Regional Cut is at least a country." will be quite difficult ;-) Think of a project for big ships - there's no project inherent need to contain _the whole_ countries land masses that contain most of the features, so take up most of the memory, but only for land features nearby the sea. => I don't understand why we need a "minimum size" requirement, but who ever sees a need for it: Can it be formulated relative to the project's scope, e.g. as percentage? --Schoschi (talk) 23:07, 9 June 2014 (UTC)
- A reasonable general way to limit the complexity of the cut without referring to minimum sizes, no holes etc. would be to limit how much longer the cut line may be in comparison to a circle of the same area. If you for example allow cuts with a maximum length of two times the circumference of a circle with the same area this would effectively exclude all complex forms independent of their topology and it would be scale independent and would also not require arbitrary rules. --Imagico (talk) 14:46, 19 June 2014 (UTC)
- The current limit (at least country size) seems reasonable to me. If there were no limits at all you could circumvent the intention of the guideline by creating tiny regions around every single feature (for example) or use a grid with tiny cell sizes to cherry pick as you need. --Dieterdreist (talk) 13:53, 1 October 2018 (UTC)
Matching data across map data boundaries
Unless we only allow continents or islands, it is inevitable that there will be a road, a railway or a river that crosses the boundary and does not quite match up. This makes the map look ugly and will make routing fail. Is it reasonable to allow users to adjust the OpenStreetMap data or the "other" data without triggering share alike? If so, are the conditions set in the proposal good enough to prevent users unfairly weaselling out of share-alike?
Please add your thoughts
- I like the idea of allowing this but I wonder how we are to check/see if our requirements have been met. --Frederik Ramm (talk) 18:43, 7 April 2014 (UTC)
- Assumption of good faith backed up by many eye-balls is the obvious method. To be more sure, we might be more insistent on the map provider identifying what areas they are using and what the boundaries are. This is probably not an issue though unless we are OK with areas smaller than countries ... with a country the border is known and it should be fairly easy to detect which ones. MikeCollinson (talk) 11:08, 10 May 2014 (UTC)
- I like the idea of allowing this but I wonder how we are to check/see if our requirements have been met. --Frederik Ramm (talk) 18:43, 7 April 2014 (UTC)
- I'd like to allow this too, but I suggest restricting adaptations to the non-osm data, for two reasons: 1) we do not want osm data to be tainted by foreign data (on the other hand, we can/must declare that modifying foreign data in this limited fashion does not taint it with osm data) and 2) we want to discourage adaptation-only changesets that might split ways at the boundary or tweak alignment to the other data instead of to reallity. Vincent De Phily (talk) 09:36, 5 May 2014 (UTC)
- Thank you, good point. I have added an extra sentence asking that such adaptions be only made on their local data copies. I think that resolves the issue? MikeCollinson (talk) 11:08, 10 May 2014 (UTC)
- I'd like to allow this too, but I suggest restricting adaptations to the non-osm data, for two reasons: 1) we do not want osm data to be tainted by foreign data (on the other hand, we can/must declare that modifying foreign data in this limited fashion does not taint it with osm data) and 2) we want to discourage adaptation-only changesets that might split ways at the boundary or tweak alignment to the other data instead of to reallity. Vincent De Phily (talk) 09:36, 5 May 2014 (UTC)
- Country borders are not always as easy as what you think: there are numerous border conflicts in the world, sometimes quite large (look at the borders claimed by China conflicting with ALL countries around, notably with Afghanistan, India, Nepal, Bhuta, Mongolia and even Russia, and including in the Ocean for islands that were still part of the territorial waters of countries very far from China, even if we include Taiwan in it: this conflicts all around the full area of the "Southern China Sea"). A data provider may be legally bound by the Chinese law, another bound by the Indian law, and their interpretation of copyright or database right will depend on these countries. We will have difficulties if there are parts of proprietary data covering areas that are claimed by another country as we cannot decide if their inclusion of proprietary data in that conflicting right is subject to this rule.
- For this reason, I suggest that providers that want to restrict an area where they want to publish proprietary data to exclude from ODbL derivative, clearly provide a visible delimitation of the border they claim (which should also be consistant to their own legal obligations that they have in each country where this organization has a legal existence or activity).
- If these locations of registration of the organization falls within the European Union, they should also the European legislation extended to all countries or territories that are part of the EU for commercial or fiscal activities, excluding the special territories of other EU member countries that are excluded from the plain aplication of the treaty, but not excluding such territories if a special territory is part of the country where the organization is legally registered: for example an organization in Denmark should include Greenland in its relevant scope, but an organization in Germany will not be required to cover Greenland if it publishes data covering several countries in the EU including parts of Denmark).
- If data is about customs, the relevant boundary will be that of the applicable custom union (e.g. the EEA+EFTA) in which the organization is registered.
- If data is about national activities of a national army, the relevant boundary will that applicable to the whole area legally covered by their military forces, except those that are deployed under an international mandate.
- If data is about currency, the relevant boundary will be that where the currency has legal tender (e.g. the whole Eurozone), excluding foireign areas where the currency may also be traded (in various currency markets).
- If data is about justice, the relevant boundary will be that of the legal judiciary branch from which the provider is publishing data, i.e. the applicable juridiction to which the registered organization is legally bound.
- Etc. As these relevant borders may not be easy to determine, the provider should publish the relevant borders they claim to cover with proprietary data, and make this border clearly visible: we may then request them to prove that they are bound to these borders (the border data itself may remain private and does not need to match exactly the borders defined in OSM data which may be a tradeoff between conflicting national claims), or to adjust these borders to also include or exclude some parts they have no national requirement to cover completely. — Verdy_p (talk) 15:43, 14 November 2017 (UTC)
Resolution: The concept and text will remain in the formal guideline. The text was slightly modified to point out that these artificial adjustments should not be added back to the main OSM database. MikeCollinson (talk) 05:15, 4 June 2014 (UTC)