[OpenLayers-Dev] 2.7 ticket list
Pedro Simonetti Garcia
pedrosimonetti at gmail.com
Fri May 2 14:36:56 EDT 2008
If you would like me to review stuff that would be fine.
Of course! Your (and anybody else's) help will be much appreciated.
2008/5/1 Stephen Woodbridge <woodbri at swoodbridge.com>:
> 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.
> 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.
> 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.
> > Pedro Simonetti.
> > 2008/4/28 Christopher Schmidt <crschmidt at metacarta.com <mailto:
> > crschmidt at metacarta.com>>:
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev