Stephen, If you would like me to review stuff that would be fine. >
Of course! Your (and anybody else's) help will be much appreciated. regards, Pedro Simonetti. 2008/5/1 Stephen Woodbridge <[EMAIL PROTECTED]>: > Pedro Simonetti Garcia wrote: > > > Christopher, > > > > This is not a reason to fork a project! > > > > > > Okay, you've convinced myself :) > > > > Since OL is a front-end application, isn't appropriate to > > maintaing server code in it. > > > > I'll create an account in OL's track to get involved with the > > KaMapCache layer. > > > > Meanwhile, I'll communicate with the ka-Map list, and start > > writing a basic how-to ka-Map+OL. If there's anyone else > > interested in help, it will me much appreciated. > > > > Pedro, > > 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'm happy to help if I can. > > Chris, > > You are right about forking projects and I wasn'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. > > 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. > > -Steve > > regards, > > > > Pedro Simonetti. > > > > 2008/4/28 Christopher Schmidt <[EMAIL PROTECTED] <mailto: > > [EMAIL PROTECTED]>>: > > > > > > On Sun, Apr 27, 2008 at 10:42:16PM -0500, Stephen Woodbridge wrote: > > > Chris, > > > > > > I sympathize with your sentiment that tile.php and precache.php > > not > > > being part of OpenLayers, but I think it is very useful to have > > them > > > with the examples, for a couple of reasons. > > > > > > 1) it keeps a version that we know works because it has been > > tested, > > > with the code > > > 2) it makes it easy for people to find these as they may not have > > come > > > from the ka-map project but might still want to use the, > > > > So, let's look at other code that this might apply to: > > > > * TileCache > > * MapServer > > * GeoServer > > * Worldwind tile server > > * GDAL2tiles > > > > All of these have changing versions, some of which will work interact > > differently with the outside world between different versions, all of > > which might not be the first place that people will look. > > > > However, I don't think it's a sane expectation that OpenLayers is > > going > > to host the code for any of these. > > > > In fact, the primary reason, in my opinion, that this is special for > > ka-Map is two-fold: > > > > * The ka-Map project has experienced a long-term dearth of > > development, > > in part due to the success of OpenLayers as a web-mapping frontend. > > This means that for the past year or more, there has been limited > > support for ka-Map from the people who know it best, and that > > affects > > many things, like documentation, releases, etc. This happens in > > Open > > Source, and I'll admit that OpenLayers is at least partially > > responsible, as developer attention has been focused elsewhere. > > * ka-Map was never designed for external use as a separable client > > and > > server side components. As such, the documentation for the > > server-side components on their own was never particularly > > seperable, > > and the end result was that the server side was only described as > > part of the whole process. > > > > These two things combine to make ka-Map a less than palatable > > solution > > for users concentrating on OpenLayers, because the server-side > > components of ka-Map are not easy to set up using the documentation > > available from the ka-Map project at this time. However... > > > > This is not a reason to fork a project! > > > > Make no mistake: maintaining seperate copies of the ka-Map source > > code > > in OpenLayers is a fork. We should not fork any project for > > convenience: > > all the difficulties that exist in using ka-Map in OpenLayers are > > easily > > solvable. Most are solvable without code: documentation is the only > > thing that most of these problems need, and documentation can be > > easily > > written in the OpenLayers wiki, the ka-Map wiki, etc. > > > > Helping the ka-Map project out by working to document a seperable > > server-side component, one designed for use in other applications > > like > > OpenLayers, would be useful to many people, and probably not just > > OpenLayers. That's the appropriate place to solve the problem of > > ka-Map > > source code not being effectively documented or clearly available: > > forking the project is a mistake, and my first step towards doing so > > with the tile.php in examples/ was a faux paus that I should have > > corrected long ago. If there are people who are interested in solving > > problems within the ka-Map code, we should not continue to solve them > > in > > OpenLayers, where only OpenLayers users benefit. > > > > Get involved. Help bring life to the ka-Map server side project, kick > > out a release, get SVN access, and help out the people who spent so > > much > > time writing the code in the first place. > > > > Regards, > > -- > > Christopher Schmidt > > MetaCarta > > > > > > >
_______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
