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

[Sunburned Surveyor]

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