[OpenLayers-Dev] 2.7 ticket list

Pedro Simonetti Garcia pedrosimonetti at gmail.com
Fri May 2 14:36:56 EDT 2008


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 <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.
> >
>
> 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 <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...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080502/695de89e/attachment.html


More information about the Dev mailing list