Wayfinding maps based on collection code (location)
Hello, I am working on an OPAC feature to display graphical overhead maps and I would like to incorporate this into the existing Koha 3 codebase. The idea is gleaned from NEU library and would work the same way with these exceptions: • Allow many/different image types or content links: gif, jpeg, png, flash,html, etc. • Have a specific link for “find it on map” or “map it” – something like that. I am looking for suggestions for ways that would be acceptable to the Koha coding community as far as where to store the data and where to link it. It would seem one could enter link data using the existing authorized values. In other words, create a new authorized type “maplinks” then allow Koha administrators to put in any content they want much like the existing icon system. In addition, a sys-pref is required to turn this feature on/off should be present. Any ideas, thoughts, chance for inclusion. I want to work with the Koha coding community to mesh this as nicely as possible. What would be the best way to proceed and what would the release manager like to see. I am aiming on finishing this project by Summer 2009. Thank you, Darrell Ulm
Hi, On Tue, Mar 3, 2009 at 10:24 AM, Darrell Ulm <darrellulm@smfpl.org> wrote:
I am looking for suggestions for ways that would be acceptable to the Koha coding community as far as where to store the data and where to link it. It would seem one could enter link data using the existing authorized values. In other words, create a new authorized type “maplinks” then allow Koha administrators to put in any content they want much like the existing icon system.
+1 to building in support for library maps. Defining a new authorized value is certainly a possible approach, and has the advantage of being fairly easy to do, but I would favor a more indirect approach that looks at a combination of relevant item fields (library, collection code, shelving location, and first part of call number, for example), then compares that combination against a mapping table set up by the Koha administrator to determine which map to display. That way, the building map feature can be used without requiring a global change to the item records to add a new authorized value. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
Hi, On Tue, Mar 3, 2009 at 10:36 AM, Galen Charlton <galen.charlton@liblime.com> wrote:
Defining a new authorized value is certainly a possible approach, and has the advantage of being fairly easy to do, but I would favor a more indirect approach that looks at a combination of relevant item fields (library, collection code, shelving location, and first part of call number, for example), then compares that combination against a mapping table set up by the Koha administrator to determine which map to display. That way, the building map feature can be used without requiring a global change to the item records to add a new authorized value.
I just realized that I may have misunderstood what you were suggesting that the authorized value be linked to - if the maplink is an attribute of the library (or collection code, or shelving location), that gets us the level of indirection I suggested. A scheme that could take the call number into a account would still be nice, though, as it would help a library that has taken the effort to make a detailed map of their collection. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
I just realized that I may have misunderstood what you were suggesting that the authorized value be linked to - if the maplink is an attribute of the library (or collection code, or shelving location), that gets us the level of indirection I suggested. A scheme that could take the call number into a account would still be nice, though, as it would help a library that has taken the effort to make a detailed map of their collection.
Regards,
Galen
Galen, Yes, the collection code would be a nice feature. This is a pretty simple mapping. I think a editable table would be the way to go as the authorized values cannot contain everything (or can they?). One could encode everything into an authorized value entry, but it would not be easy for administrators to deal with. So we will likely need a small new table with the entries and a new simple interface. It would be really nice to also offer to upload many types of content, like Flash. Technically, entries could link to a inline YouTube video player and have someone virtually walk them to the location although we intend to use Flash since the tools we have simplify the creation of animated maps. Still, even static maps would be a nice feature. Just wondering, what is the standard way to proceed on this. Are the design plans located in the wiki? Thanks again. Darrell Ulm
Galen Charlton <galen.charlton@...> writes:
On Tue, Mar 3, 2009 at 10:24 AM, Darrell Ulm <darrellulm@...> wrote:
I am looking for suggestions for ways that would be acceptable to the Koha coding community as far as where to store the data and where to link it. It would seem one could enter link data using the existing authorized values. In other words, create a new authorized type “maplinks” then allow Koha administrators to put in any content they want much like the existing icon system.
+1 to building in support for library maps.
Defining a new authorized value is certainly a possible approach, and has the advantage of being fairly easy to do, but I would favor a more indirect approach that looks at a combination of relevant item fields (library, collection code, shelving location, and first part of call number, for example), then compares that combination against a mapping table set up by the Koha administrator to determine which map to display. That way, the building map feature can be used without requiring a global change to the item records to add a new authorized value.
Regards,
Galen
Yes, I agree. The (lib, ccode, loc, call) will come into play in most libraries and certainly all large systems. The call number could be a *range* in order to show which shelf the item is located. Not involving the Itype would be good since it is always smart to avoid unneeded complexity for catalogers. So are you suggesting a new small table? That would work of course. A question concerning how the images would be loaded. I suppose if images were linked using authorized values, they could be dumped into a directory and then moved around as needed by the Koha admin. There may be a way that makes more sense, any ideas? :) The intent is to start working on this in April-ish. Always good to do the design 1st and get the input of the Koha community. Darrell Ulm
On Tue, Mar 3, 2009 at 11:20 AM, Darrell Ulm <darrellulm@smfpl.org> wrote:
The call number could be a *range* in order to show which shelf the item is located.
Agreed.
So are you suggesting a new small table? That would work of course.
Yes.
A question concerning how the images would be loaded. I suppose if images were linked using authorized values, they could be dumped into a directory and then moved around as needed by the Koha admin. There may be a way that makes more sense, any ideas? :)
Since I'm assuming that the maps will be static files (PNGs, Flash animations, or whatever), storing them in the filesystem rather than the database makes sense. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
Galen Charlton <galen.charlton@...> writes:
Since I'm assuming that the maps will be static files (PNGs, Flash animations, or whatever), storing them in the filesystem rather than the database makes sense.
OK, sounds reasonable. Hope to start in a month and I will get back to you. Darrell Ulm
Hi Darrell, This sounds fantastic! I'm not a techie but from an end user point of view I would love a map which shows clients at a glance which physical part of the library houses the collection they are looking for. Go you! cheers Jo. Darrell Ulm wrote:
Hello, I am working on an OPAC feature to display graphical overhead maps and I would like to incorporate this into the existing Koha 3 codebase. The idea is gleaned from NEU library and would work the same way with these exceptions: • Allow many/different image types or content links: gif, jpeg, png, flash,html, etc.
• Have a specific link for “find it on map” or “map it” – something like that.
I am looking for suggestions for ways that would be acceptable to the Koha coding community as far as where to store the data and where to link it.. It would seem one could enter link data using the existing authorized values. In other words, create a new authorized type “maplinks” then allow Koha administrators to put in any content they want much like the existing icon system.
In addition, a sys-pref is required to turn this feature on/off should be present.
Any ideas, thoughts, chance for inclusion. I want to work with the Koha coding community to mesh this as nicely as possible. What would be the best way to proceed and what would the release manager like to see. I am aiming on finishing this project by Summer 2009.
Thank you,
Darrell Ulm
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (3)
-
Darrell Ulm -
Galen Charlton -
Joann Ransom