[OpenLayers-Dev] ESRI and OpenLayers

[David Zwarg]

Greetings community,

One thing to note for the ArcIMS and ArcXML patches: they are a best effort
to implement the most commonly used functions in ArcXML.  This includes get
image and get feature requests.

Anyone who's looked at the ArcXML specification knows that it's very
thorough, and supports a myriad of operations.  The ArcXML support in the
patch mentioned implements image requests and feature requests.  However,
there are limits to what is implemented.  The entire ArcXML schema is not
replicated in the ArcXML patch, so it's not a complete port.  As with most
projects, the current patch satisfies the business need that I have with the
resources that I have.

I am willing and able to be the custodian of that component, but will need
more feedback from users of the ArcIMS layer for advanced operations
(geocoding, projection (have you heard of this proj4js library?), etc.).

Thanks,
z

On Sun, Mar 8, 2009 at 10:03 AM, carls <carlshe at 163.com> wrote:

>
> I had tested
> 'root/sandbox/dzwarg/openlayers/lib/OpenLayers/Layer/ArcIMS.js'
> and 'root/sandbox/dzwarg/openlayers/lib/OpenLayers/Format/ArcXML.js' with
> OL2.7. It works well.
>
> I hope and would like to see the support of ArcIMS in OL2.8, if possible.
>
> Thanks.
>
>
> Christopher Schmidt-2 wrote:
> >
> > Eric,
> >
> > Your email led me into a response that is really far more appropriate to
> > the entire dev list in my opinion. ESRI and OpenLayers is a particularly
> > large hole in the library support, and I wanted to really get down a lot
> > of my thoughts on why this is. Please take all this with a large grain
> > of salt as being my personal point of view... but perhaps not an
> > entirely-inaccurate one, given my level of involvement in the project.
> >
> > On Mon, Mar 02, 2009 at 04:27:21PM -0700, Eric Wolf wrote:
> >> Christopher,
> >>
> >> I hate to open old wounds, but I'm preparing a presentation centered
> >> around generating a tile cache consumable by OpenLayers but based on
> >> an ArcGIS map layout. I've tried some different configurations:
> >
> > So, I want to start off by saying this: No existing OpenLayers core
> > contributor has, in any major way, a personal or professional motivation
> > towards supporting ESRI's web services, so far as I am aware.  This
> > includes the OpenGeo community (generally speaking, tightly coupled with
> > GeoServer), the Camptocamp group (which works almost exclusively outside
> > the realm of ESRI, as far as I've observed: possibly motivated by
> > Europe's lack of proprietary buy-in, hooray), or the DM Solutions
> > (primarily around MapGuide, and MapServer) or MapGears (primarily around
> > MapServer) contributors. I expect that if you came with $$ to any of
> > these groups, they would be likely to be able to help you, but it's not
> > so common of a problem to make it worthwhile for them to spend time
> > maintaining ESRI-specific code without a customer asking for it.
> >
> > With that in mind, almost all work on ESRI-related developments thus far
> > has been by non-core contributors to the project, and OpenLayers has,
> > in some cases, not had a great track record with non-core contributors
> > of content doing the work to get their code in trunk.
> >
> > The ESRI AGS code developed thus far has been prey to this: several
> > people have used it, but not:
> >
> >  * Documented it
> >  * Tested it
> >  * Created examples for it
> >
> > As such, the code is not something that the OpenLayers community can
> > support without a strong leader stepping up and taking on the task on
> > the code.
> >
> > Some counter-examples to this are:
> >
> >  * The recently committed ArcGIS 9.3 REST API layer.
> >  * The in-review ESRI ArcXML layer.
> >
> > Both of these sets of code have had committed developers who have
> > written tests, provided documented examples, etc. in clean, well-laid
> > out patches.
> >
> > Based on your problem description on the mailing list -- something you
> > neglected to include in this email, which makes it difficult to respond
> > to precisely -- I can not describe what the best solution is for you,
> > based on my personal knowledge. I don't use any ESRI products or
> > anything else.
> >
> > Though I don't know if it's the best thing for your use case, I do feel
> > that it would be beneficial to the OpenLayers community to have access
> > to ESRI's map caches. Cached map tiles are clearly much faster than
> > non-cached map tiles, and the recent developments of ESRI's -- making
> > available, for example, sampleserver.esri.com or whatever it is -- make
> > this type of development much simpler.
> >
> > However, to accomplish this goal, there still needs to be a champion of
> > the task -- someone who is reasonably experienced in Javascript, and
> > willing to step up and take on the task of providing the OpenLayers
> > community with the support it needs to get this support into the
> > library. This means that, for example, documentation and examples would
> > need to be written, etc.  and the contributo would likely need to
> > demonstrate some willingness to continue to support developers in
> > maintaining the code, since none of us are, as far as i know,
> > particularly well-versed or highly motivated to maintain the code at a
> > reasonable level of quality on our own.
> >
> > You proposed a number of possible solutions:
> >
> >> * Turning on WMS in ArcServer and pointing TileCache at it. Works but
> >> ArcServer wants to serve the layers independently, so I get back to
> >> the SLD problem.
> >
> > To me, this seems like a configuation issue. That is, the WMS serves
> > layers individually, but they're typically possible to combined, with
> > something like:
> >
> > layers=0,1,2
> >
> > In your TileCache config. However, I only know very little of ESRI's
> > software, so I can't comment on that for sure, and I haven't seen any
> > links that help me look at your setup to confirm-or-dis-confirm this
> > notion of mine.
> >
> >> * Generating a tile cache out of ArcServer and kludging TileCache to
> >> serve it up.
> >
> > I don't know what 'ArcServer' is, but I expect that this would have
> > essentially the same problem that has existed i ArcGIS caches in the
> > past, which is that most people who have access to caches don't know
> > what the parameters used to create the cache are.
> >
> >> And lastly:
> >>
> >> * Pulling the AGS plugin for OpenLayers out of the sandbox
> >
> > This code should probably be in trunk, as described above. The fact that
> > it is not is because no sufficiently motivated Javascript developer has
> > made it so. (As Mr. Schaub pointed out at one point, these things arent
> > meant to happen magically; in Open Source, you need to either pay
> > someone to do it, or do it yourself.)
> >
> >> I haven't actually tried the last bit because of some of your emails
> >> I've found from 2007. It sounds like AGS is a dead-end. Is this true?
> >> Is there a specific reason?
> >
> > AGS is not a dead-end, but you probably read emails where I was
> > expressing my frustration, centered mostly around the stuff above.
> > Specifically, the same problem as there is in many aspects of the
> > project has arisen here:
> >  * Someone writes some code
> >  * The code is insufficient, poorly documented, or simply 'not done'
> >  * The author of the code expects it to get in trunk
> >  * Requests to do more work to make it happen are ignored.
> >
> > The general assumption in these cases seems to be that if someone writes
> > some code, it will automatically be in trunk, which is simply
> > unrealistic. OpenLayers is a high quality code library, and it seems
> > completely reasonable to me that in order to keep it that way, we have
> > to maintain some standards. However, this means that some code does not
> > make it into trunk in a timely manner, and the patch authors feel
> > shunned or ignored. Although this is almost always not the case, the
> > emotions there are very frustrating as a developer: the expectation that
> > patches lead to changes in the library 'for free' is just unfair to the
> > core development team.
> >
> > In this case, I was unable to st up the ArcGIS cached layer code to talk
> > to any server I could find documented on the web. If I an't do it, I
> > can't imagine that most users can do it: I'm a pretty smart guy in
> > general. If I cant' pull it off, then it is probably the case that
> > others can't either, and that means that putting it in trunk is asking
> > for pain. With that in mind, I saw no significant personal benefit to
> > working on it, and the code has sat.
> >
> > My expressed frustration is/was probably unfair. I'm not aware of any
> > problem with the code as it exists -- except that people are using it,
> > and not giving back to the community by trying to get it into trunk. I
> > find that combination extremely unfair, given the amount of work that so
> > many people put in to make the library possible. I'd love to see some
> > organizations out there who are using this code really invest in it, and
> > make the library better for everyone as a result. This could come in the
> > form of paying developers to work on it, project sponsorship with a
> > stated request -- though not binding, clearly somewhat motivating -- or
> > other potential venues. Without any of this kind of support,
> > organizations -- of which there are several -- using the AGS code are
> > simply taking from the library, and not giving back. that type of
> > behavior is frustrating to me, and that has probably come through in
> > previous emails.
> >
> >> And input would be greatly appreciated.
> >
> > Using ESRI services in OpenLayers needs champions -- people who are
> > willing to truly support the cause. ArcXML has a champion in the form of
> > dzwarg, who has been working with me on an ArcXML ticket. ArcGIS rest
> > layer had a champion in the form of Jeff Adams. AGS cache needs the
> > same. The community could probably rally up and make this support
> > happen: lots of people have expressed interest. Open Source isnt all
> > about things being done for you, and I'd love to see some of the users
> > of the software really invest in OpenLayers more than they have up to
> > this point. ESRI-specific services are a great example of this, where
> > there's a lot of code floating about, but relatively limited support of
> > it outside of the companies using it or specific use cases, and that's
> > a great example of what I'd love to see change.
> >
> > Sorry for using you email as a jumping off point for a 'rant' like this,
> > but the state of ESRI-in-OpenLayers is an excellent example of what
> > *feels* like poor community support of library in favor of immediate
> > needs, and I really like the idea of that changing. (And if I'm
> > completely ignoring a significant effort in this regard, this is a
> > perfect oppourtunity for the existing community members whose work I
> > have been ignoring to step up and tell me how wrong I am!)
> >
> > Regards,
> > --
> > Christopher Schmidt
> > MetaCarta
> > _______________________________________________
> > Dev mailing list
> > Dev at openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >
> >
>
>
> -----
> Regards, Carl SHE
> --
> View this message in context:
> http://n2.nabble.com/ESRI-and-OpenLayers-tp2412861p2444558.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090309/09e3f5ca/attachment.html