Another idea will be if a localized community (e.g. a city) all agree to go PD. Then new users who sign up to the website will be informed of a list of places were their contributions will be considered PD, as well as any ways crossing PD/SA borders.<br>
<br>A nice goal would be to make Africa PD, because it would be one step in creating a super map that combines official government information with local observation on the ground, which is often radically different.<br><br>
This (as well as some of the other ideas in this thread) assumes that the main community is not hostile to the idea.<br><br><div class="gmail_quote">On Sun, Nov 2, 2008 at 10:21 PM, Kari Pihkala <span dir="ltr"><<a href="mailto:kari.pihkala@gmail.com">kari.pihkala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> Setting up a parallel PD world on separate servers is less work for<br>

> programmers but infinitely more work for everyone else down the chain<br>
> because so many things have to be done in both universes at the same<br>
> time, or will only be done in one.<br>
<br></div>It would be great if there was a way to share one database. However, I see problems there and possible fights over data. Here's my suggestion for a two database solution:<br>
<br>There are at least two methods to move data from OSM/PD database to OSM/ODbL. I doubt that the other way (OSM/ODbL -> OSM/PD) will be possible after the new license is effective.<br><br>1. Contributors upload PD GPS tracks and both can use them to create features. - This is already possible.<br>

2. Any feature created into OSM/PD can be easily copy/pasted into OSM/ODbL. - I tried using two layers in JOSM and it is possible to copy features from a layer to another. For some reason, the coordinates were not copied, e.g., manual positioning is required at the moment, but that would be easy to fix.<br>

<br>I know that #2 won't work for everything - ways connected to other ways, relations or adjusting node positions.. but it will work for completely new features.<br><br>We could also create tools, which will work on two layers at once. Move a node in PD version and ODbL version is also affected..<br>

<br>So, technical solutions exist to help people to maintain two databases. There will always be more work, but it works and it is clearer.<br><br>Any other ideas how the two databases could be linked together? <br><br>Or how to solve the 3 issues for keeping one database? <br>
<font color="#888888">
<br>- Kari<br><br><br></font><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Sun, Nov 2, 2008 at 11:42 AM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<br>
</div></div><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">
Hi,<br>
<div><br>
> To make people change their mind it will help if we can at least point to<br>
> some project or publication that uses OSM/PD. Chicken and egg. So let's<br>
> start with the least amount of effort and see what happens.<br>
<br>
</div>You need code to extract "all PD stuff" from OSM, whether you do this as<br>
a one-off export to start your own PD server or whether you write<br>
something that can be used today, tomorrow, and the day after tomorrow<br>
against the original OSM data base...<br>
<div><br>
> I would rather see the programmers concentrate on more important things like<br>
> undo.<br>
<br>
</div>Setting up a parallel PD world on separate servers is less work for<br>
programmers but infinitely more work for everyone else down the chain<br>
because so many things have to be done in both universes at the same<br>
time, or will only be done in one.<br>
</div></div><div><div></div><div><div><div></div><div class="Wj3C7c"><br>
Bye<br>
Frederik<br>
<br>
--<br>
Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
<br></div></div><div class="Ih2E3d">
_______________________________________________<br>
Legal-general mailing list<br>
<a href="mailto:Legal-general@openstreetmap.org" target="_blank">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></div></blockquote></div><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></blockquote></div><br>