[daisy] A geo-enabled Daisy ?

[Bruno Dumon]

On Thu, 2007-05-03 at 02:31 -0400, Luca Morandini wrote:
> On 5/2/07, Bruno Dumon <bruno at outerthought.org> wrote:
> >
> > On Wed, 2007-05-02 at 03:03 -0400, Luca Morandini wrote:
> > > 1) A page could be linked to a geographic feature (for the time being,
> > > just a point) by specifying its coordinates, which would be stored,
> > > via a "location" part type into a geometric field of the relevant
> > > MySQL table. This calls for the ability to link a part type to a
> > > particular column type in the database (by the way the column type is
> > > DBMS-specific).
> >
> > I guess you rather mean a location field type (instead of part type)?
> 
> Yes, a field type would be more appropriate.... though it would have
> to be converted from text (in the form) to binary (in the table).
> 
> 
> > And the reason for having such a specific field type is probably [only]
> > to enable special searches?
> 
> Not only: my rationale is producing geographic content for maps not
> necessarily served by Daisy. Imagine adding a geo-enabled Daisy
> document for every airport, you could then embed such airports
> location as background information in a map served by a different
> system as long as the Daisy column containing location information is
> accessible and stored according to a given binary format ("Well Known
> Binary" in OpenGIS -speak).
> 
> 
> > One way to look at this is that you need a sort of custom index (just
> > like there is now the fulltext index), and than preferably also some
> > corresponding query-possibilities in the Daisy query language.
> 
> It would be nice indeed, but I am a step before that: I would like to
> add a field type of a given, DBMS dependent, column type and store in
> it the content of a couple of text field taken from the form. I
> suppose it could be done, but I'd like to have some hints on how to
> get there.

I think I understand it better now, but the approach is still the same,
you need to get that table somehow populated, and this could be:

 (1) by an application that runs periodically, queries for all relevant
documents and updates the table
 (2) by an application listening to JMS events
 (3) by an extension in the repository server listening to synchronous
events

Both (1) and (2) are quite simple (for someone with Java development
skills), they are simple stand-alone applications.

For how to write these, see
http://cocoondev.org/daisydocs-2_0/373-cd/375-cd/28-cd.html

(3) is a bit more involved towards deployment as it requires adding
component metadata and adding the component to the block.xml (not
difficult either but not documented) -- things which will get easier in
the future once we upgrade our component architecture.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org