[OpenLayers-Users] Experience using OpenLayers

[Christopher Schmidt]

On Thu, May 17, 2007 at 06:39:56PM -0400, Jeff Yutzler wrote:
> I've spent some time over the last couple of weeks evaluating
> OpenLayers v2.3 as a web mapping client and I have a series of
> observations.
> 
> First of all, a little about our architecture.  We have a J2EE web
> application built on top of IONIC's Red Spider Enterprise API.  We
> also have a web mapping client built on top of OpenLayers.  In between
> we have an AJAX/JSON conduit between the two.  This works well for us
> because the Enterprise API supports all of the OGC capabilities we
> need, things like Web Map Context, Web Feature Server, and Catalog.
> Besides, the idea of using an open proxy is not palatable for many of
> our customers for security reasons.  Since we can take advantage of
> all of our OGC capabilities through the Enterprise API, we do all of
> that work on the web application side and pass the relevant bits to
> the client via AJAX/JSON.

Note that if the data you expose via JSOn is not
public-to-the-whole-web, using JSON as a workaround as a 'solution' for
the same origin policy may be dangerous. I mention this only because
it's something that I didn't realize for a long time :) 

> For us, the trivial use case is allowing the user to load a Web Map
> Context, add, remove, reorder, and configure WMS/WFS layers and do WMS
> GetFeatureInfo/WFS GetFeature requests to see the data underlying the
> layers.  We were able to do most of these things with OpenLayers
> almost directly out of the box and we are pretty excited about that. 

That's great to hear! 

>     * an Oracle database is being populated in real time by an
>       external process with feature / location data of moving features
>     * We have a Web Map Context that we load into OpenLayers containing:
>           o some base map
>           o a WMS layer representing the current location of the features 
>             in the database
>           o a WMS layer representing past locations of the features in
>             the database.  This layer supports temporal extents so we
>             can see the feature tracks for a fixed length of time (this
>             length is called feature decay)
>           o a layer (extending OpenLayers.Layers.Markups) that
>             contains feature information for the features currently on
>             the screen (we cap the number of features so that it doesn't
>             get unwieldy).  We put invisible markups on the screen that
>             the users can click on to find out feature details.
>     * The user configures the map refresh rate and the feature decay.
>       As the map refreshes, features start moving around the map.
>     * The user can activate "chase mode" whereby the map recenters
>       itself to where the chased feature is right now whenever it
>       updates.

Any possibility of a demo URL for this? Even if it's with faked data, it
would be interesting to see how OpenLayers can be used 'for real' -- I'm
much more a cartogrpaher than a 'GIS' person.

> The biggest problem we have with OpenLayers is the way image updates
> are handled.  The main thing that attracted us to OpenLayers is the
> way the map scrolls smoothly when the user pans around.  The screen
> does not turn blank and since adjacent tiles are already downloaded,
> updates are fast.  Unfortunately, this only applies when the user
> moves laterally, not when specific tiles need to be redrawn.  In our
> use case above, the map refreshes can take a few seconds depending on
> the amount of data involved and the speed of the server and it looks
> pretty lame when the layer disappears while it is reloading.  We know
> it is possible to keep the old tile image in place, load the new image
> on top, then remove the old image when the new one is done loading,
> but I don't see any reference to this concept in the trac ticketing
> system.  We would be interested in seeing this in a future release and
> would consider developing it ourselves if necessary.

When you say 'update', I assume you mean 'mergeNewParams'. There are
some things that can be done in this regard -- the biggest problem is
that right now, there's not a difference between 'move this tile' (which
has to hide the old one so that spain doesn't end up in brazil) and
'change properties of this tile other than geo' which is a case where
you don't want to hide the tile first. If you open a ticket for this,
I can add more discussion there -- it's a feature  that people have
fumbled for the lack of, but not one that's been pushed high up on a
priority list by existing users.

> My next step in development is to support WFS-T.  We are reluctant to
> try out 2.4RC3, but maybe it is time.  We are also interested in
> multi-line, multi-polygon, and inner ring support.  We've implemented
> this capability in other web clients so we know it can be done here.
> I see this is on the road map for 2.5. Since we have full WFS-T
> support via Red Spider Enterprise, this work should go quickly.

2.4RC3 is a relatively complete release. With the exception of a few
minor bugs (georss serialization, for example), I expect very few
differences between RC3 and RC4, and it seems possible that RC4 will be
the final release. An OpenLayers release doesn't make it to RC stage
without a significant amount of testing, both automated and
non-automated, so the RCs are pretty low risk.

Multi-line, multi-polygon, and inner ring support exists in the format
parsers. The place where it doesn't exist yet is in the UI for feature
creation, but if you have existing data, it can be displayed. This
doesn't sound like it will solve all of your use cases, but it will at
least allow you to visualize the content even if you can't do everything
you want with it.

> The most annoying thing I had to do was provide something more capable
> than the default Layer Switcher.  Before working with OpenLayers, we
> built a client from scratch on top of YUI so we had a lot of controls
> already built.  Unfortunately, the YUI event model and the
> Prototype-based event model are like oil and water.  I could not use
> the drag and drop ability from YUI because the Layer Switcher was
> eating the mouse up events before they could reach the <LI> that was
> being dragged.  Because of this, it would not stop dragging reliably.
> Ack!  I ended up replacing the Layer Switcher completely with our own
> thing which is not awful, but it is so different it would not fit into
> your code base at all.

Hm, it's unfortunate to hear that there is a major problem here. I'd
like to work to resolve what that problem is, though I'd also like to go
on a 6 month sojourn through the Rocky Mountains, and given current time
constaints in my daily life, it seems that both are equally likely :)
Still, it seems that if there is a significant problem using OpenLayers
with other event frameworks, we have a bug, and I'd like to see it
fixed.

> By the way, is there an example for using the measurement tool?  I
> don't see one anywhere.  I see it in the code but I figure I would
> want to see an example of using it before I add it to our own client.

Any measurement tool in the current code (possibly in MouseToolbar?) is
out of date, and it is hoped that a more competent replacement will
exist for 2.5.

> Oh, and on the forum debate, I recommend not having a separate forum.
> However, I do suggest you publicize the link to Nabble a little more.
> I spent a lot of time blindly looking through the mail archives before
> I spotted it.

Any suggestions on where to put this? I know most things by URL, so an
outsider point of view on this aspect of the project would be useful. 

Thanks for the feedback!

Regards,
-- 
Christopher Schmidt
MetaCarta