Stephen,<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
If you would like me to review stuff that would be fine.<br></blockquote><br>Of course! Your (and anybody else&#39;s) help will be much appreciated.<br><br>regards,<br><br>Pedro Simonetti.<br><br><div class="gmail_quote">
2008/5/1 Stephen Woodbridge &lt;<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>&gt;:<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">Pedro Simonetti Garcia wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Christopher,<br>
<br>
 &nbsp; &nbsp;This is not a reason to fork a project!<br>
<br>
<br>
Okay, you&#39;ve convinced myself :)<br>
<br>
Since OL is a front-end application, isn&#39;t appropriate to<br>
maintaing server code in it.<br>
<br>
I&#39;ll create an account in OL&#39;s track to get involved with the<br>
KaMapCache layer.<br>
<br>
Meanwhile, I&#39;ll communicate with the ka-Map list, and start<br>
writing a basic how-to ka-Map+OL. If there&#39;s anyone else<br>
interested in help, it will me much appreciated.<br>
</blockquote>
<br></div>
Pedro,<br>
<br>
If you would like me to review stuff that would be fine. It has been a few years since I have worked on a ka-map project and some of the more active devs would probably be a better resource, but I&#39;m happy to help if I can.<br>

<br>
Chris,<br>
<br>
You are right about forking projects and I wasn&#39;t advocating it as the standard. Because of the reasons you stated about ka-map, I have maintained my own fork of precache.php and tile.php for some time. In part because it took a long while for the patch to add a directly level into the cache structure to deal with too many files in a directory, that I submitted. By the time that got added I had also added various convenience features for my automation tool that are probably not generally useful.<br>

<br>
Regardless, in my mind ka-map as a project has been largely deprecated by OpenLayers functionality on the client side. I think it would be a shame to loose the server side components precache.php and tile.php as these are good solutions for the PHP side of the house. Hopefully this will not happen, but the only other consumer of ka-map tiles is OpenLayers, hence my suggestion that it might be a logical place for these components to also live.<br>

<br>
-Steve<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
regards,<br>
<br>
Pedro Simonetti.<br>
<br>
2008/4/28 Christopher Schmidt &lt;<a href="mailto:crschmidt@metacarta.com" target="_blank">crschmidt@metacarta.com</a> &lt;mailto:<a href="mailto:crschmidt@metacarta.com" target="_blank">crschmidt@metacarta.com</a>&gt;&gt;:<div>
<div></div><div class="Wj3C7c"><br>
<br>
 &nbsp; &nbsp;On Sun, Apr 27, 2008 at 10:42:16PM -0500, Stephen Woodbridge wrote:<br>
 &nbsp; &nbsp; &gt; Chris,<br>
 &nbsp; &nbsp; &gt;<br>
 &nbsp; &nbsp; &gt; I sympathize with your sentiment that tile.php and precache.php not<br>
 &nbsp; &nbsp; &gt; being part of OpenLayers, but I think it is very useful to have them<br>
 &nbsp; &nbsp; &gt; with the examples, for a couple of reasons.<br>
 &nbsp; &nbsp; &gt;<br>
 &nbsp; &nbsp; &gt; 1) it keeps a version that we know works because it has been tested,<br>
 &nbsp; &nbsp; &gt; with the code<br>
 &nbsp; &nbsp; &gt; 2) it makes it easy for people to find these as they may not have<br>
 &nbsp; &nbsp;come<br>
 &nbsp; &nbsp; &gt; from the ka-map project but might still want to use the,<br>
<br>
 &nbsp; &nbsp;So, let&#39;s look at other code that this might apply to:<br>
<br>
 &nbsp; &nbsp; * TileCache<br>
 &nbsp; &nbsp; * MapServer<br>
 &nbsp; &nbsp; * GeoServer<br>
 &nbsp; &nbsp; * Worldwind tile server<br>
 &nbsp; &nbsp; * GDAL2tiles<br>
<br>
 &nbsp; &nbsp;All of these have changing versions, some of which will work interact<br>
 &nbsp; &nbsp;differently with the outside world between different versions, all of<br>
 &nbsp; &nbsp;which might not be the first place that people will look.<br>
<br>
 &nbsp; &nbsp;However, I don&#39;t think it&#39;s a sane expectation that OpenLayers is going<br>
 &nbsp; &nbsp;to host the code for any of these.<br>
<br>
 &nbsp; &nbsp;In fact, the primary reason, in my opinion, that this is special for<br>
 &nbsp; &nbsp;ka-Map is two-fold:<br>
<br>
 &nbsp; &nbsp; * The ka-Map project has experienced a long-term dearth of development,<br>
 &nbsp; &nbsp; &nbsp;in part due to the success of OpenLayers as a web-mapping frontend.<br>
 &nbsp; &nbsp; &nbsp;This means that for the past year or more, there has been limited<br>
 &nbsp; &nbsp; &nbsp;support for ka-Map from the people who know it best, and that affects<br>
 &nbsp; &nbsp; &nbsp;many things, like documentation, releases, etc. This happens in Open<br>
 &nbsp; &nbsp; &nbsp;Source, and I&#39;ll admit that OpenLayers is at least partially<br>
 &nbsp; &nbsp; &nbsp;responsible, as developer attention has been focused elsewhere.<br>
 &nbsp; &nbsp; * ka-Map was never designed for external use as a separable client and<br>
 &nbsp; &nbsp; &nbsp;server side components. As such, the documentation for the<br>
 &nbsp; &nbsp; &nbsp;server-side components on their own was never particularly seperable,<br>
 &nbsp; &nbsp; &nbsp;and the end result was that the server side was only described as<br>
 &nbsp; &nbsp; &nbsp;part of the whole process.<br>
<br>
 &nbsp; &nbsp;These two things combine to make ka-Map a less than palatable solution<br>
 &nbsp; &nbsp;for users concentrating on OpenLayers, because the server-side<br>
 &nbsp; &nbsp;components of ka-Map are not easy to set up using the documentation<br>
 &nbsp; &nbsp;available from the ka-Map project at this time. However...<br>
<br>
 &nbsp; &nbsp;This is not a reason to fork a project!<br>
<br>
 &nbsp; &nbsp;Make no mistake: maintaining seperate copies of the ka-Map source code<br>
 &nbsp; &nbsp;in OpenLayers is a fork. We should not fork any project for convenience:<br>
 &nbsp; &nbsp;all the difficulties that exist in using ka-Map in OpenLayers are easily<br>
 &nbsp; &nbsp;solvable. Most are solvable without code: documentation is the only<br>
 &nbsp; &nbsp;thing that most of these problems need, and documentation can be easily<br>
 &nbsp; &nbsp;written in the OpenLayers wiki, the ka-Map wiki, etc.<br>
<br>
 &nbsp; &nbsp;Helping the ka-Map project out by working to document a seperable<br>
 &nbsp; &nbsp;server-side component, one designed for use in other applications like<br>
 &nbsp; &nbsp;OpenLayers, would be useful to many people, and probably not just<br>
 &nbsp; &nbsp;OpenLayers. That&#39;s the appropriate place to solve the problem of ka-Map<br>
 &nbsp; &nbsp;source code not being effectively documented or clearly available:<br>
 &nbsp; &nbsp;forking the project is a mistake, and my first step towards doing so<br>
 &nbsp; &nbsp;with the tile.php in examples/ was a faux paus that I should have<br>
 &nbsp; &nbsp;corrected long ago. If there are people who are interested in solving<br>
 &nbsp; &nbsp;problems within the ka-Map code, we should not continue to solve them in<br>
 &nbsp; &nbsp;OpenLayers, where only OpenLayers users benefit.<br>
<br>
 &nbsp; &nbsp;Get involved. Help bring life to the ka-Map server side project, kick<br>
 &nbsp; &nbsp;out a release, get SVN access, and help out the people who spent so much<br>
 &nbsp; &nbsp;time writing the code in the first place.<br>
<br>
 &nbsp; &nbsp;Regards,<br>
 &nbsp; &nbsp;--<br>
 &nbsp; &nbsp;Christopher Schmidt<br>
 &nbsp; &nbsp;MetaCarta<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br>