Oliver (skobbler) wrote:
> Let's assume that a business user has a database of non-publicly accessible
> objects (e.g. a subsurface cable network for demonstration purposes). If the
> user installs its own instance of an OpenStreetMap server and draws the
> "non-publicly accessible subsurface cable
>He shouldn't draw then into the database, as this mixes OSM data and his
>own data. Why not just use a layer on top of the OSM data?
One of the big advantages of OSM is that you the "drawing tools". An option
would be to create a blank database on top of the OSM data by using the OSM
tools.
Reg
Hi,
Oliver (skobbler) wrote:
>> He shouldn't draw then into the database, as this mixes OSM data and his
>> own data. Why not just use a layer on top of the OSM data?
>
> One of the big advantages of OSM is that you the "drawing tools". An option
> would be to create a blank database on top of th
On Wed, Jun 23, 2010 at 9:11 AM, Oliver (skobbler)
wrote:
>
> Hello everybody,
>
> I am still concerned that some business users cannot make use of
> OpenStreetMap data because of the Share-Alike-rule as they don't want or
> cannot share proprietary data.
Umm, if you want it so that some people a
On 06/24/2010 09:34 AM, Andy Allan wrote:
> On Wed, Jun 23, 2010 at 9:11 AM, Oliver (skobbler)
>
> Really, if people (businesses, charities, individuals or whoever) have
> data they wish to keep private, they can still use OSM data
> internally. If they want to "Publicly Convey this Database, any
>
Andy Allan writes:
>
> No. That would be avoiding the whole point of the share-alike license.
> If they have geographic data that we don't have, and they mix it with
> OSM data, then the whole point is that we end up with access to their
> geographic data. It's called share-alike! Not
> "take-o
Jukka Rahkonen wrote:
> Andy Allan writes:
>> If they have geographic data that we don't have, and they mix it
>> with OSM data, then the whole point is that we end up with access
>> to their geographic data.
> [...]
> You are obviously reading section 4.5 in a different way that I do.
> [...
On 06/24/2010 10:07 AM, Jukka Rahkonen wrote:
>
> For me it looks like business users can feel safe with their data if they do
> not
> make derivative databases, for example by enhancing their own data by taking
> tags from OSM database.
If enhancing means incorporating the data into a single dat
Richard Fairhurst writes:
> Jukka Rahkonen wrote:
> > Andy Allan writes:
> >> If they have geographic data that we don't have, and they mix it
> >> with OSM data, then the whole point is that we end up with access
> >> to their geographic data.
> > [...]
> > You are obviously reading section 4
>What we're currently seeing is "import mania",
>poeple trying to stuff every possible bit of information into OSM
>because that's the easiest way for them to use it in conjunction with
>OSM data. There is too much geodata in the world for this to be
>sustainable - OSM must stick to things that ma
Jukka Rahkonen wrote:
> Users must just take care that they do not edit cable lines according to
> what they see on the OSM map, otherwise all of the cable network data
> will be considered to be derived from OSM data and thus fall under odbl.
Very very broadly yes, but actually at that point (
On 24 June 2010 09:31, Frederik Ramm wrote:
> Hi,
>
> Oliver (skobbler) wrote:
> >> He shouldn't draw then into the database, as this mixes OSM data and his
> >> own data. Why not just use a layer on top of the OSM data?
> >
> > One of the big advantages of OSM is that you the "drawing tools". An
Frederik Ramm writes:
> I think that OSM as a whole - and this is not a legal issue - needs to
> improve interoperability. What we're currently seeing is "import mania",
> poeple trying to stuff every possible bit of information into OSM
> because that's the easiest way for them to use it in
13 matches
Mail list logo
