RepositoryInfo.getLocation():URI
RepositoryInfo
I mean)
dev
to eventually become 1.0-RC3? And get the init
bug into 1.0-RC2
?
I've sent the following to the dev mailing list:
I've spent the last couple days updating the state of the IP review.
Several dependencies were added and several CQs were split into multiple CQs, resulting in 10 new CQs.
The following issues are causing us grief:
[11343] JSONassert - Depends on org.json:json which has a license specifying "the Software shall be used for Good, not Evil." Whilst amusing, this is not an open source license. Apparently we can get versions of this without the moral restriction, but I'm concerned that version mismatches may bite us.
Current status: withdrawn
[8959] restlet - Had to be split into several CQs.
Current status: waiting for IP team to re-open
[9008] jetty - Had to be split into 2 CQs.
Current status: waiting for IP team to re-open
[8960] BerkeleyDB - Will be removed, but hasn't been yet. SleepyCat license is a no go.
Current status: rejected
[9000] osmosis - The LGPL license is a problem. It seems it may have more serious license issues. See the CQ for the details.
Current status: waiting for a response from us
[10775] jtds - This is LGPL but as a transitive dependency from GeoTools it shouldn't be a problem. However, I think we can drop SQL Server support for now, which would make it unnecessary.
Current status: waiting for a response from us
[8992] jettison - This includes the source from org.json:json which is not covered by an open source license. We may be able to replace the files, but potential version conflicts exist.
Current status: waiting for a response from us
mapdb - Will be removed, but hasn't been yet.
org.json:json - Not an open source license. See [3453]. We may be able to replace it with an acceptable version, but it's unclear to me if we can apply an open source license to any of the versions, or just a specific one.
There are another 14 CQs waiting for review.
I'm intrigued by GeoGig, not sure whether it's something I'll be able to contribute to, but hoping to find some like-minded souls. I've been in the GIS business for over 30 years, most recently dealing with the utilities market and coding in C# (it's been 15 years since I used Java).
One of my most interesting projects was a cadastral mapping application that constructs map content by entering survey measurements from a bunch of hardcopy plans. It uses an append-only event source (a set of immutable flat files) to record the edits used to create the map. Everything is relative to a set of control points that provide some initial absolute positions. But instead of storing the derived positions, it just stores the input measurements. What that
means is that it has to re-calculate the geometry each time it opens the map.
That may seem a bit pointless, but it does simplify things in situations where the source data could change. For example, if my original control has moved, I can just append that change to my editing timeline and that's me done (I don't need to modify any positions because all derived positions are transient).
It occurred to me that this approach applies to any application that involves relative positioning. And the append-only structure makes it quite easy to handle branching.
I don't think GeoGig as it currently stands would be able to work with spatial data in this sort of way. I'm just wondering whether it's something that could be bolted on, or would that be better tackled as something brand new.