[Legal-general] Who would start using an OSM PD repository?

[Sunburned Surveyor]

TimSC,

I've had some time to consider your questions. After some serious
thought I realize that a database is the best way to store a seamless
geospatial data set.

It doesn't sound like your getting a lot of love from the OSMF board.
:] You can contact me if you want to explore the idea of setting up an
expiremental PD database.

Landon

On Wed, Jul 21, 2010 at 7:53 AM, Sunburned Surveyor
<sunburned.surveyor at gmail.com> wrote:
> TimSC,
>
> You have good questions, and I think you have done a great job of
> identifying the challenges of setting up a place to host the OSM PD
> data. If you think a duplicate OSM software stack is the way to go, we
> should probably wait to see what the USGS cooks up. It looks like they
> may already have a duplicate software stack they are testing. (I'm not
> sure if they are willing to host data outside the US on this stack at
> some point. We'd have to wait and see.)
>
> I've been having an internal struggle with some of your questions
> about the internal repository. I need more time to think about these
> questions. Let me chew on them for a while and I'll see if I can get
> back to you.
>
> I'm willing to help get something set up, but I must honestly admit I
> don't have time to learn how to set-up and maintain a duplicate OSM
> software stack. I could donate space on a web server and help out with
> maintenance and set-up, but the whole thing is too big a job for me
> right now.
>
> Landon
>
> On Wed, Jul 21, 2010 at 1:37 AM, TimSC <mapping at sheerman-chase.org.uk> wrote:
>> Hi Landor,
>>
>> I was thinking about how to maintain the central data for a PD dataset. I
>> think there is interest in PD within OSM but it has clearly not translated
>> into a PD branch (or fork). I am still struggling to understand that
>> failure, to avoid making the same mistakes.
>>
>> On 20/07/10 17:40, Sunburned Surveyor wrote:
>>>
>>> I'm curious about how much and how serious the interest is in a public
>>> domain repository for data that would be pushed upstream to the
>>> regular OSM database.
>>>
>>
>> If I understand you, you plan to download an OSM from from a file repository
>> (such as git or svn), edit it locally, and load back to the repository.
>>
>> Advantages of a repository:
>> Relatively simple to administrator and host
>> Large overall size is easily supported
>> Relatively simple to upload into the main SA dataset
>>
>> Disadvantages:
>> No usernames, OSM usernames only get added to the data after uploading and
>> downloading from the main server AFAIK
>> No history of changes
>> Edges of tiles are difficult to handle
>> For densely mapped areas, an extreme number of separate files are needed
>> (local data editors cannot load entire cities)
>> No potlatch
>> Not easy to use, the main server is difficult enough. Finding the correct
>> file would be confusing, every country having a different structure? yikes.
>> If multiple users make changes to the same area (accidentally), merging the
>> data might be difficult
>>
>> Another approach is to use the existing software stack - known as "the rails
>> port" and written in ruby (on rails). I have this working on my ubuntu
>> desktop and it was relatively(?) easy to install. But I don't know the ruby
>> language (yet).
>>
>> Advantages:
>> Accessing the data is relatively simple
>> Full edit history, user messaging system and sign up page
>> Potlatch should work, along with all other OSM tools
>>
>> Disadvantages:
>> Difficult to administer, linux knowledge is uncommon, ruby knowledge is
>> rare. Who would do backups? Planet dumps? Bug fixes?
>> The rails port would need to be adapted for PD use, to remove duplicated
>> stuff from the main OSM page
>> OSM/PD usernames would probably be separate from OSM usernames (unless some
>> complex jiggery pokery was added)
>> Hosting the rails port requires more specialist hosting (repositories are
>> common, the rails port is a rare breed).
>> Uploading data to the main SA dataset might be tricky - node IDs would
>> differ between the PD and SA datasets. This might be rejected as a conflict.
>>
>> Or a third approach is to implement a new server stack. This would not be a
>> good idea, unless the other options are completely unworkable. The API for
>> the main dataset periodically changes and we would need to keep in step to
>> use OSM tools. It would also duplicate effort.
>>
>> If anyone can think of other pros and cons, I would be interested.
>>
>> Conclusions: we don't need to choose right away. We can do one, then
>> transition to another option. The rails port seems to me the way to go,
>> eventually. If you have hosting with the USGS, it would do as a temporary
>> solution. I am personally not very interested in a repository, until I
>> thought there were PD mappers active in my area. The rails port would need
>> some adaptation to make it usable. Hosting the database is another issue, as
>> repository or on the rails port. What is OSMF's view on this? Also, given
>> the relicensing may cause an CC-SA-BY fork. What are they doing in this
>> area? Can our efforts be combined?
>>
>> TimSC
>>
>>
>