Summary: | Map of library in search system | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | OPAC | Assignee: | Owen Leonard <oleonard> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P2 | CC: | ago, barbara.johnson, bargioni, bugzilla, cbrannon, cnighswonger, gmcharlt, jhannert, magnus, mirko, mjr, nengard, nicolas.legrand, paul.poulain, r.delahunty, sally.healey, severine.queune, veron |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10814 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12015 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Chris Cormack
2010-05-20 23:34:39 UTC
Restoring where "Previous assignee was mjr@ttllp.co.uk" I have started to collect some ideas here: http://wiki.koha-community.org/wiki/Shelf_Map_RFC Please feel free to add/delete/comment! OK, I'm taking a crack at a simple implementation of this. See http://wiki.koha-community.org/wiki/Shelf_Map_RFC for some hints on how I intend to go about it. Work in progress will be available from git@github.com:MagnusEnger/kohawork.git, on a branch called bug737-shelfmap ( https://github.com/MagnusEnger/kohawork/tree/bug737-shelfmap ). Hi Magnus, these may help you: http://catalogo.pusc.it/cgi-bin/koha/opac-detail.pl?biblionumber=13381 and http://catalogo.pusc.it/pusc_opac.js I asked PUSC what they were doing, but haven't heard back from them yet. Best regards, Albert I added another "example in the wild" in the wiki. The library maps at Pontificia Università della Santa Croce work independently from Koha. They are 12 years old and run for Aleph 300 and Amicus too. The tool is based on a set of gif images and a database of objects to pin on the corresponding map. Every map has properties: id, filename, name and every object has properties: id, type, map_id, x-coord, y-coord, string_value. Since my library basically uses itemcallnumbers in the form "[A-Z][A-Z] [0-9]+", the value used for objects are the first two letters. Other libraries can have different type of itemcallnumbers, and this implies an effort to satisfy every kind of situation. The returned page contains a gif image with letters, dynamically composed using GD Perl module, and an html map for links to a special virtual bookshelf. Look at http://bib6.pusc.it/cgi-bin/piantine/search?piantina=0SC for an example. Albert, http://catalogo.pusc.it/pusc_opac.js is not very useful. It is a set of customizations of my opac. One of them allows to build the "compass" link, but this can be easily done with a little modification to the opac-detail template. The tool also allows to edit maps -adding, moving, or deleting letters- using a web interface. An interesting solution I hope to introduce could be to avoid GIF and use SVG: it opens up a lot of dynamic features on the web page, through javascript. Hi Magnus, in the light of Bug 9265 (switch to HTML5 doctype) and without taking a look at your branch, has a decision been made regarding the "how"? I would not mind more HTML5 in Koha but I am not sure what to make out of http://en.wikipedia.org/wiki/Html5_canvas#Intellectual_property_over_canvas regarding licensing issues. Mirko: My plan was to generate PNGs on the server for the initial implementation. On the other hand, I ran out of time for this (unfunded) "project", so I'm setting it back to "NEW". The code I did create is on GitHub, if anyone wants to take it and run with it! *** Bug 10814 has been marked as a duplicate of this bug. *** Would love to see this get some steam behind it again. I could easily see an authorized value category with codes to urls for specific locations in the library. This would work great as we could limit codes to specific libraries. Then we would just need a table linking the item to a code, and make this selectable in item editing. Would love to see this get some steam behind it again. I could easily see an authorized value category with codes to urls for specific locations in the library. This would work great as we could limit codes to specific libraries. Then we would just need a table linking the item to a code, and make this selectable in item editing. Actually, instead of linking specific items to maps, I would suggest that perhaps there could be some way of specifying a specific combination of branch and shelving location in the Authorized Values table that, if matched on a item in the record details, an symbol appears next to the shelving location that patrons can click on to show the map in a model. Still chewing on this. You wouldn't have to have a separate table to link libraries, shelving locations and maps, if you created specific shelving locations for each library, limiting that location to that library. That would create a long shelving locations table, but it would mean not creating a new table, and if you are limiting to the library, that library is only seeing their shelving locations. Theoretically, that would work. With each unique shelving location code, I would create a separate Authorized Value in a category like SHELVINGMAPS, and use the same shelving location code, and provide the url. In jQuery, I would find the itemnumber, get the shelving code, and then link the map. This would be more ideal if it were built in. Better yet, if I am going to the trouble of creating individual shelving locations for each library, why not take advantage of the icons for that location. It would be great if we could upload our own images for a custom icon, and just define the map in the shelving location. (Unless the icons for shelving locations are actually used somewhere.) |