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