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

[Sunburned Surveyor]

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
>
>