Friday, 28 March 2008

JTS at the sharp end of many arrows

Miguel Montesinos and Jorge Sanz from the gvSIG project have made a nice diagram showing the relationships between a bunch of GFOSS projects. It' s nice to see JTS close to the centre of the diagram - although having so many arrows pointed at it makes me a little nervous!

They show JTS having a dependency on Batik for some reason - that must be an error, there's no relationship between the two. Or does Batik use JTS?

It would have been nice to see a "parent-of" relationship between JTS and GEOS and NTS, since the latter two also form a key component of quite a few projects. And I'm pretty sure MapGuide OS uses GEOS, as does OGR.

But it's not surprising there's a few errors and omissions - it's a pretty complicated web of relationships. And this is over only what - 8 years? I wonder what the diagram will look like in another 8...


Unknown said...

Hi Martin,

This is an interesting diagram, but as you mentionned there are some mistakes, and I think the arrow from JUMP to OGR/GDAL should go to JTS instead.
JTS : +1

One could also have added mapyrus, a java library to draw eps/pdf/svg/image maps from shapefiles or databases. It also uses jts (optional) and recently, I was wondering how powerful could be jeql (for data manipulation) + mapyrus (for data representation).



Dr JTS said...


Good point about the bad arrow to OGR from JUMP. JUMP definitely doesn't use OGR (fine library though it is, non-Java is a showstopper).

Thanks for the reminder about Mapyrus. I was actually checking out GMT last night, because I had a similar idea that it would be cool to be able to output PDF/SVG/etc from JEQL. Mapyrus is much more interesting, though, since it's Java. If you have any ideas about how such an integration would work, I'd be interested to hear them.

Dr JTS said...

Well, I dug into the Mapyrus codebase, and unfortunately I don't see much possibility for integration with Jeql. The code is very clever, and obviously a lot of work has gone into understanding how to emit the various formats. Unfortunately, the code is not well modularized - especially the output side!

I don't see much interest in trying to integrate at the language level, either, since the Mapyrus language appears to be heavily procedural in nature. The whole idea of Jeql is to be higher-level and more declarative.

At this point I think GMT will provide more of a model for the language to specify graphics. And I will look into libraries like iText and Batik for output capabilities (although it might be tempting to try and repurpose some of the code from Mapyrus)

Frank Hardisty said...

Hello Martin,

I think I can guess at the JTS -> Batik dependency. If you want to write out a JTS Geometry in SVG, you are likely to use Batik.

Neither library knows anything about the other, so I would agree that it is an error, if this diagram is trying to be UML.