Re: [OSGeo-Discuss] Using ArcGIS Desktop with PostGIS [SEC=UNCLASSIFIED]

2014-07-11 Thread rburhum
Hello Bruce,

I have not worked on this since January of last year, but I have an ArcGIS
Extension I wrote that enables ArcMap to read/write to any GDAL datasource.
I think if you recompile it for 10.2 it should work - even if you only have
the ArcGIS Basic license.

Contributions are welcomed.

- Ragi

View this message in context:
Sent from the OSGeo Discuss mailing list archive at
Discuss mailing list

Re: [OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.

2013-05-12 Thread rburhum
Dear Adrian,

I recently saw a reply that you made to a blog post I wrote recently.
Although the criticism were meant to be directed to the *OGC* as an
*organization*, I can tell by your comments, descriptions and overall tone,
that you felt *personally* attacked and offended. You have my sincere
apologies if you felt that way. This was never meant to be a personal

I would be happy to elaborate, with far more detail, each single one of my
comments/points. We can do this either publicly or in a private e-mail
exchange (whatever you feel is best). 

Based on your responses though, I have to admit that we have fundamental
disagreements in several aspects – and some serious ones at that.
- I would be happy to discuss XML vs JSON vs MessagePack conversations and
why the first of those is (lately) not adopted by any modern API. JSON is
the real winnder nowadays (for good reasons). In terms of serialization
frameworks, MessagePack has implementations in
I dare to say it is “somewhat” supported.

- I would be happy to discuss why security is more than certificate exchange
or username/password submission during requests.

- I would be happy to discuss why complexity of specifications hinders
adoption.  There are technical reasons why geojson and mbtiles are gaining
traction without much effort and GML is not. (Much love to all my friends
that were involved with GML – I apologize if this offends you).

- I would be happy to discuss why I think SQL (SQL:1999, or SQL:2003, or
SQL:2008 or SQL:2011) is a better choice for an API than a full fledged OGC
query language that tries to abstract querying. As a side comment, you are
correct at thinking that my reasoning here came from experience. Around 10
years ago I was sitting at my ESRI office and a co-worker came into the
office and asked me for help since he was in charge of implementing one of
the OGC WFS version specs. The nicest thing that I can tell you is that “it
was painful and unreasonable in many regards” and that it ended up requiring
to hire an “OGC consultant” to try to implement the spec as close as
possible (to *explain* – not to implement) 

- I would be happy to accept the fact that OGC does not have “reference
implementations”. That is, of course, as soon as the OGC itself stops using
that those terms. I think there was a misunderstanding with the reference
implementation licensing comment. Let me just say that there is plenty of
Open Source that is BSD or Apache licensed (for example, AFAIK, *everything*
from the Apache Foundation
But please, let’s leave licensing talks for the end.

- I would be happy to explain the different between a stateful and a
stateless architecture and why websockets are a paradigm shift for the web.
If you want to implement the same concepts of a spec without “being tied to
the web” or “web browsers” feel free to take “web” out of “websockets” and
just use sockets. The same stateful vs stateless architecture argument

- I would be happy to explain why SPDY is not “another protocol” but one of
the inspirations/guides for httpv2. We are still talking http here.

- I would be happy to explain WebSQL even though it died. Why you may ask?
Because there was only one implementation of the standard (sqlite) and the
standards organization (W3C) refused to make it a standard without a
competing implementation. I hope the irony of this situation doesn’t escape

- I would be happy to explain why the OGC doesn’t have to fully re-invent
the wheel when it comes down implementing a Spatial DVCS. The fact that it
is “spatial” doesn’t mean it needs to be completely different. I would talk
to the GeoCouch guys that have a perfectly good replication model that works
or would also look at things like Git, Mercurial, PostgreSQL, MySQL or even
the ESRI Versioning and replication system. Replication/versioning is a
solved problem. We just don’t have a *standard* that defines how everyone
should implement it. Ironically, I can point out a couple of OGC members
that are experts in this field.

- I would be happy to explain why perhaps, after all these years, it is time
to stop ignoring temporal datasets and addressing some of the not so “low
hanging fruit”.

- I would thank you for calling me young! Although I am not sure I am
confused all the time. Well, perhaps 70% of the time I am! 

In all honesty, I have to admit though, the original post was written as a
quick reaction to another set of e-mails I received in regards to some OGC
decisions as of late. 

The truth is that, until last week, I equated the OGC as a standards body
that was meant to be equivalent to the W3C (except, of course, for GIS).
Sadly, this also means that I would expect a similar behavior/quality of
decisions from the OGC (maybe this is a mistake on my part?). If you look at

Re: [OSGeo-Discuss] The importance of a project's license

2012-07-27 Thread rburhum
As someone who has done several for-pay projects (both big and small) to
combine proprietary and foss4g code, I can give a summary from a set of
anecdotal evidence and trends that I have noticed from a US-based consultant
point of view.

From my experience, the adoption of an open source project obviously depends
a lot on the license and the *environment* it is going to be deployed on.
Let me explain.

When offering a solution to a customer, it is easy to convince them that
changes/enhancements to a particular component they are getting for free
should be released out back to the community. It takes 1 minute to convince
them of this. No friction there. What is much more difficult is to convince
them that *all* the code they have been building for sometime now, needs to
also be released under the same terms (think GPLv3). *That*, I can certainly
say that 99.99% of the time they feel really strongly against!

When consuming full-blown GPL-licensed code, the situation when somebody has
to also license their entire code base under the GPL depends on the
environment. Let me take the example of LGPL and full blown GPL (forget
about Affero GPLv3 for this discussion).

For server-side and desktop technologies, take the example where the
processes are running separate. Changing GPL code is effectively enhancing
that component I got for free, which they understand (they may not
understand in-proc or out-of-proc). From a practical stand-point, the
restrictions/obligations are similar to that of LGPL because the client's
code is separate from open source project's code, so adopting an open
source project under GPL or LGPL is of low friction.

For components that are running in-proc, then the license matters much more.
An LGPL licensed project still gives them the concept of I just need to
release the fixes that I make to the library I got for free, so it is an
easy-sell. GPL-licensed code goes beyond this, so every single customer I've
had where I offered to consume GPL-code in-proc said 'no' (except for one in
academia, but that was a special case).

For customers where I have built iOS apps for, it gets really really tricky.
iOS does not allow shared linking of code (it is all static linking), in
that scenario, LGPL becomes the new GPL. Some people argue that you can
use a special provision of LGPL to be able to use LGPL-licensed  code in the
Apple App Store. But there is no legal precedent for that yet (and thus, as
of right now, it is a theoretical argument), so most businesses that respect
licenses (or don't want to run the risk) will stay away from it altogether.

For web development development, it is a different story and a much longer
discussion because of the various ways you can consume open source projects.

Now for MIT, Apache, and similar licenses, you don't have any of these
implications. It is much easier to convince somebody to consume a project of
this kind. Afterwards, you can always give arguments for why it is
beneficial to open source a generic component and, so far, I have never
encountered friction against this. The FileGDB and ArcObjects GDAL drivers
are examples of this.

As far as GitHub vs Sourceforge, I think it is hard to argue that any new
open source is far more likely to adopt GitHub vs any other repo kind out
there. The reasoning, besides the technological implications, are IMHO,
rooted in generational-gap arguments.

My two-cents,

- Ragi

View this message in context:
Sent from the OSGeo Discuss mailing list archive at
Discuss mailing list