[Legal-general] Fwd: Do we need an extra server at all...?

[Kari Pihkala]

> How would it be possible to share waypoints/tracks with OSM?

That was suggested by Frederik in his original post. However, I think it
requires heavy modifications to the client and server software - so I would
prefer a separate database for PD, at least for now.

I think JOSM can do the job of copying data from PD to SA, at least to some
degree.

> I agree that it will be a lot of work to get support for any type of
> shared database from the OSM admins. I think perhaps that is a battle
> that should be fought after we can demonstrate some broad community
> support in our effort.

True. So, it may be good to set up our own database and start filling it to
show the OSM admins that there is a demand for it. Later, we can join it
back to OSM. So, we go for option 2:
2. Two databases, one for SA objects and one for PD objects. Manual copying
of objects from PD to SA.

So, in addition to a file repository, we could also start looking for a
database server. It should be a server with (preferably) Linux, Ruby on
Rails and MySQL. Fast internet connection and a lot of disk space :).

There's good instructions how to set it up and I've managed to do it on my
own PC.
http://wiki.openstreetmap.org/index.php/The_Rails_Port

- Kari


2008/11/10 Sunburned Surveyor <sunburned.surveyor at gmail.com>

> Kari,
>
> How would it be possible to share waypoints/tracks with OSM?
>
> I agree that it will be a lot of work to get support for any type of
> shared database from the OSM admins. I think perhaps that is a battle
> that should be fought after we can demonstrate some broad community
> support in our effort.
>
> As for the integration issue, it should be possible to write some
> software that helps with the process. I could write software that
> would scan a layer from OSM PD and compare it to another layer from
> OSM SA. It could then select feature geometries that were in the PD
> layer but not the SA layer, and move these two a separate layer that
> could be loaded into OSM SA. Obviously, there will be some challenges
> to overcome. For example:
>
> - Even feature geometries for the same feature won't match exactly.
> We'll have to allow for some type of error buffer.
> - When a PD feature is placed in the OSM SA database it would be nice
> if its nodes matched the nodes in the SA layer. That means either
> adjusting the nodes of the PD feature before upload, or adjusting the
> nodes of the SA feature.
>
> Landon
>
> On Mon, Nov 10, 2008 at 5:58 AM, Kari Pihkala <kari.pihkala at gmail.com>
> wrote:
> > Currently, we have two/three options to get the PD database running. I've
> > listed pros and cons for these.
> >
> > 1. One database, which holds PD and SA objects, some objects may belong
> to
> > both. Contributors can decide which set of objects they are modifying.
> >  + tightly integrated into OSM infrastructure
> >  + easy to apply map changes to PD and SA objects at the same time (?)
> > - requires changes to the server and client software (to manage different
> > object versions)
> >  - takes a long time to implement (we don't even have the design for it)
> >  - setting up requires support by OSM administrators
> >
> > 2. Two databases, one for SA objects and one for PD objects. Manual
> copying
> > of objects from PD to SA.
> >  + possible to set up right now
> >  + can be done without support from OSM admins
> >  - may drift apart from OSM
> >  - manual work to copy PD objects to SA database
> >
> > There is one issue with the two database system. If we have a completely
> own
> > server and database, it means that the users need to create a new login
> id
> > for it. Also, the GPS track repository will be separate from the current
> > OSM. This could be prevented by creating only way/nodes tables and
> accessing
> > the current OSM/SA users tables/GPS tables. But this requires support
> from
> > OSM admins. So this option looks like:
> >
> > 3. Two databases, one for SA objects and one for PD objects. Manual
> copying
> > of objects from PD to SA. Shares users/GPS tracks with the current
> OSM/SA.
> >  + is tightly within OSM
> >  - requires some work to create new tables for nodes/ways, but not as
> > demanding as option #1.
> >  - setting up requires support from OSM admins
> >  - manual work to copy PD objects to SA database
> >
> > I think the option #3 is the best - it can be set up fairly quickly and
> it
> > is still tightly within OSM. The downside is that the OSM admins need to
> > approve the changes. It can be challenging, if you think how difficult it
> > was to  get a mailing list..
> >
> > How do we proceed? Should we contact the admins and ask if #3 is doable
> or
> > should we just go on with #2??
> >
> > - Kari
> >
> > 2008/11/10 Joseph Gentle <josephg at gmail.com>
> >>
> >> On Fri, Nov 7, 2008 at 1:35 AM, Sebastian Spaeth <sebastian at sspaeth.de>
> >> wrote:
> >> > Sunburned Surveyor wrote:
> >> >> I'm interested in a PD map for my portion of the world. I cruise over
> >> >> to the OSMPD data repository and see what is available. If there
> isn't
> >> >> enough data for my map, I break out my GPS receiver, if there is
> >> >> enough data: Woohoo!
> >> >> I really don't see a practical way to suck OSM SA data back into the
> >> >> public domain. Really the data flow can only go one direction:
> >> >
> >> >> OSM PD Mapper > PD Repository > OSM
> >> >
> >> > Yep, I think this is the only realistic expectation.
> >>
> >> We need a good map merging system. It may need to be human-assisted to
> >> resolve conflicts.
> >>
> >> -J
> >>
> >> > spaetz
> >> >
> >> > _______________________________________________
> >> > Legal-general mailing list
> >> > Legal-general at openstreetmap.org
> >> > http://lists.openstreetmap.org/listinfo/legal-general
> >> >
> >>
> >> _______________________________________________
> >> Legal-general mailing list
> >> Legal-general at openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/legal-general
> >
> >
> > _______________________________________________
> > Legal-general mailing list
> > Legal-general at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/legal-general
> >
> >
>
> _______________________________________________
> Legal-general mailing list
> Legal-general at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-general/attachments/20081110/f21bb620/attachment.html>