Integrating Jeql and Mapyrus

7 views
Skip to first unread message

Martin Davis

unread,
Apr 2, 2008, 5:05:16 PM4/2/08
to JEQL Users
Michael Michaud posted a suggestion about looking at integrating the
Mapyrus library with Jeql, to provide rich output capability (a la
GMT). I replied on my blog, but thought I would copy the reply here
for all to see.



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)

Michaël Michaud

unread,
Apr 2, 2008, 5:48:34 PM4/2/08
to jeql-...@googlegroups.com
Martin Davis a écrit :

>Michael Michaud posted a suggestion about looking at integrating the
>Mapyrus library with Jeql, to provide rich output capability (a la
>GMT). I replied on my blog, but thought I would copy the reply here
>for all to see.
>
>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!
>
>

Yes, I was also surprised to see all the output code in only one or two
classes.

>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.
>
>

I did not notice this difference of level. Probably difficult to
integrate two script languages with a different approaches.

>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)
>
>

I must have a look on GMT (have you got a project url ?)
I'm sure iText and Batik are very good libraries for pdf and svg (and
maybe we'll soon be able to focus on one format and rely on other tools
to do the conversion - I saw that the last inkscape version can open and
edit a pdf map ;-))
I thought a combination of jeql and mapyrus could improve usability with
minimal development resources, but it may not be a good choice for a
tight integration of both parts.
Let's hear what others think

Regards,

Michaël

>>
>
>
>
>

Martin Davis

unread,
Apr 2, 2008, 7:00:10 PM4/2/08
to jeql-...@googlegroups.com
On Wed, Apr 2, 2008 at 2:48 PM, Michaël Michaud <michael...@free.fr> wrote:


>
I must have a look on GMT (have you got a project url ?)
 
http://gmt.soest.hawaii.edu/     Pretty nice, especially if you are a Unix command line wizard  8^)  I think there's an opportunity to improve the scripting - and of course, it should be in Java  8^)

I'm sure iText and Batik are very good libraries for pdf and svg (and
maybe we'll soon be able to focus on one format and rely on other tools
to do the conversion - I saw that the last inkscape version can open and
edit a pdf map ;-))

Wow - I thought PDF was basically write-only.  I hope this isn't a sign that PDF is winning over SVG (I mean, I know it is from installed base - but I hope SVG is retaining the moral high ground!

I thought a combination of jeql and mapyrus could improve usability with
minimal development resources, but it may not be a good choice for a
tight integration of both parts.
Let's hear what others think

Absolutely.  Clearly producing graphical output is of high interest.  The question is, is there any point in providing yet another tool/approach, or is what's already out there good enough?  (And there is probably no right answer to this question...  While nobody want to reinvent wheels, there is also a strong desire to have as few tools to learn as possible).

BTW, it occurred to me that since Mapyrus might be very nice if it was reworked to use Groovy as its host language.  That should be fairly straightforward, and immediately brings all the power of Groovy (and before you ask the obvious question, yes I have thought about whether Jeql has the same possibility - but so far I haven't found a way of doing that that would provide as simple a syntax)

M

Reply all
Reply to author
Forward
0 new messages