<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
Ahh crap, I knew this was going to happen, the questions I mean. :c)
I can continue with the detail offline if you like too . . .<br>
<br>
I don't know how much detail you want to get into here, but we've been
reviewing some of the code with regard to implementing some aspects in
our package that deal with the tile services and optional reading and
outputting of data. <br>
<br>
The group on this end has some reservations about how the code was put
together and how we want to extend it, if possible. It's about a 50/50
right now, and still in the discussion phase as to whether to use the
OpenLayers code or go a separate route. Just about all of your points
below have been discussed on our end. We've been trying to think about
how to best list those concerns and not seem overly critical of
OpenLayers which seems to have a loyal following. It's why we looked
in the first place and are looking again now. We also did some looking
during the early phases of our project, but OpenLayers was no where
near capable of doing the things that it does now. The reading/writing
aspects are the plus aspect that we're looking for from OpenLayers.
While the principals don't require all of these types of capabilities,
it is understood that they will help along our project towards general
acceptance. In the end, maybe we just stay a niche product and leave
it at that. <br>
<br>
It's out there now with Version 1.0.0 released, and ready for flogging
by others. If we don't get any bites, then fine, better than not
trying to let others look at all though.<br>
<br>
It's still in it's open-source infancy however, but you can see the
project at:: <a class="moz-txt-link-freetext" href="http://www/geomoose.org/moose">http://www/geomoose.org/moose</a><br>
<br>
bobb<br>
<br>
<br>
<br>
<br>
Christopher Schmidt wrote:
<blockquote cite="mid:20071001172901.GA17328@crschmidt.net" type="cite">
<pre wrap="">(I'll disclaim this by saying that OpenLayers is one of the projects I
think of as 'my' open source projects: OpenLayers, TileCache,
FeatureServer. However, I think that I could make the same argument for
other libraries that are not mine as well.)
On Mon, Oct 01, 2007 at 11:35:58AM -0500, Bob Basques wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Also, I believe that there are some flaws with the coding approach in
some cases for OpenLayers. I'm trying not to downplay Openlayers here,
but I believe that Open Layers is at the point of a re-write as well.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm wondering what makes you think that. Is it something that has been
said, or do you feel this way from observation of the code or something
else?
For the record, although I do feel that OpenLayers can only last another
6 months or so before we go to version 3.0 (though I'd love to make it
last longer), even when we do so, by the time we do, it will probably be
very similar to Python's setup -- you write your application for 2.x,
turn on debugging to ensure there are no deprecation warnings, and if
there aren't, then you can probablye switch to 3.0 without any problems.
I can't say that this will be the path for sure, but I highly doubt
there will be a substantial rewrite of OpenLayers in the next 12-18
months.
</pre>
<blockquote type="cite">
<pre wrap="">Recently we've been discussing using the OpenLayers tiling "get" methods
for incorporation into our package, but some concerns about memory leaks
and coding methodologies are cause for concern by our team.
</pre>
</blockquote>
<pre wrap=""><!---->
These types of things are great to share between projects, and sharing
them might lead to alleviating the concerns on both sides -- either by
resolving the issues within OpenLayers, or in the worst case, confirming
the status is the way you think it is, thus leading to a sounder call on
this type of decision. A project which doesn't reach out like this is,
in my opinion, one which should be carefully considered when approaching
incubation: much of the purpose of OSGeo and the community of Open
Source developers is to establish the bonds needed to ensure that the
products coming out are the best they can be.
If someone is doing something similar to OpenLayers, and is implementing
the same wheel simply because they are unable to make OpenLayers do what
they want given its current state, I think they are likely to be passed
up as time goes on. OpenLayers has grown a large -- and growing daily --
community. Part of the reason is because we have taken an active attempt
to reach out to similar projects and offer to maintain the functionality
they are using for them.
Many OpenLayers use cases are, for example, similarly or better met by
the ka-Map code. To help out users looking for OpenLayers-like ease of
use and ka-Map like tile loading, OpenLayers implemented and supports a
ka-Map layer class to display data from ka-Map tiles, and the OpenLayers
community -- via myself and Schuyler Erle -- built TileCache, an
alternative to ka-Map's tiling engine.
Neither will solve all cases for all users, but they have both helped to
increase the community around OpenLayers. In some cases, it's possible
that this has smothered another community (though that has never been
intentional!), which is something that OSGeo needs to be careful of
happening to projects which pass through incubation.
The same has been done with WorldWind tile access, with vector drawing,
with so many other things: working together with others doing the same
thing is one of the biggest reasons, in my opinion, that OpenLayers has
grown its community. Without that community, the project would not be
sustainable -- and without the efforts put forth to work with other
software, and to solve other problems, that community wouldn't exist.
</pre>
<blockquote type="cite">
<pre wrap="">In short, pointing potential users at any one application/package is not
going to promote innovations and the overall code stack will suffer
because of it.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree. But OpenLayers isn't an application. Pointing potential users
at only applications using GDAL for raster data access does not, to me,
seem to limit innovation.
Of course, OSGeo is open to more than just one project in the same
space. FDO and GDAL/OGR are in a similar space, but both are undergoing
or have undergone incubation.
The community around a project is far more important. Is it
self-sustaining? Is it likely to last? As OpenLayers grows -- and
continues to improve -- will other projects which compete with it
survive? Is a project different enough that it will have a different set
of users -- different enough that OpenLayers improvements and expansions
won't snuff it out?
Oftentimes, the answer is "Yes." Other times, the answer is "Maybe we
should change our tactic." MapBuilder has recently been working on
creating a build which uses OpenLayers as the map rendering library.
ka-Map has done the same thing. DM Solutions Fusion project has done the
same thing. All these are building application-level functionality on
top of OpenLayers -- which means that as OpenLayers improves, these
other projects will also be able to improve. That is an important
consideration, in my opinion, and one that any project which is directly
competing with OpenLayers at the library level may want to ask itself.
I say this not because I think OpenLayers is the best at what it does.
Other libraries have a smaller Javascript footprint, a smaller memory
footprint, a more concise object model, less dependancies on external
code, easier usability, etc. I say this because I think that as time
goes on, OpenLayers will improve faster than a project which can not
sustain a vibrant and growing community.
1 year ago, I wouldn't have advised that anyone use OpenLayers for
mission critical tasks.
6 months ago, I would have advised you would need to spend a fair amount
of time understanding it to get use out of it.
3 months ago, I would have said you would need to be aware of it's
limitations.
Now? Now it's one of the premier places that people look for vector
editing in the browser. It's got support for parsing and saving out a
number of geographic information formats. Now it's got hooks so that it
really is a library -- and can be treated like one, underlying other
applications. Now it's got a vibrant community growing by dozens of
people every week. Now I'm working with my employer to make it the
primary search interface to our enterprise product.
1 week ago, I might not have advised it for a number of different things
-- for example, if you wanted client side reprojection support, I might
have pointed you to Mapbuilder, or some other client.
But now I don't have to, because there is a huge amount of work being
done in OpenLayers to support exactly that. 1 week ago, I would have
targeted this to 3 - 6 months in the future. But Mike Adair, building on
his work with the MapBuilder project, came through and built it -- not
in a week, but in a day, so far as I could tell. Now, OpenLayers can
have real client side reprojection support.
This single case can be expanded to dozens of others I can share -- but
it wouldn't change the fact any more than I've already stated.
There is room for many other web mapping applications. There may even be
room for other web mapping libraries. But they better have something
htat's siginficantly different from OpenLayers -- because if they don't,
eventually, they may well get passed by. It might well be better to help
improve OpenLayers -- we're very open to that! -- than to develop it on
your own.
</pre>
<blockquote type="cite">
<pre wrap="">Making the strengtha and weakness know would be a much
better approach.
</pre>
</blockquote>
<pre wrap=""><!---->
I think the biggest thing OSGeo needs to consider when taking in
projects for incubation is if they have longevity. What's the 'bus
number'? Is it maintained by a single person -- and if that person wears
out, who's next? That's far more important to the future of a project
than whether it has competition or not.
Regards,
</pre>
</blockquote>
</body>
</html>