As in previous years, I think some further work on kothic-js would be good. Client side rendering considerably reduces server overheads for setting up your own mapping website, so ideas such as making it leaflet 0.7 compatible (appears to only work with 0.5.x or below atm), or client side caching (indexeddb etc) would be good. The latter would also allow interactivity to be added to the maps.
I'll put it on the wiki at some point. I don't know the kothic codebase in enough detail and also time is tight for me so not sure if I'd be able to mentor it, but as an idea I think it's good. Nick -----Rob Nickerson <rob.j.nicker...@gmail.com> wrote: ----- To: talk@openstreetmap.org From: Rob Nickerson <rob.j.nicker...@gmail.com> Date: 11/02/2014 09:35PM Subject: Re: [OSM-talk] Summer of Code 2014 Hi All, I tried to send the following idea to the "imports" mailing list the other day, but turns out I wasn't registered to post there. I guess it fits well with Summer of Code so I will add it to the wiki, but not being a developer I can't mentor anyone. ---- <snip> So my question is: How do we improve our import work flows so that it is easier to keep imported or merged data up to date? Some ideas: 1. Tools to compare OSM data against the available external data set. One recent blog post on this by SK53 http://sk53-osm.blogspot.co.uk/2014/02/looking-for-footpaths-in-hickling-notts.html 2. We need to be asking for not just full datasets but also regular change-sets. If we cannot get a change-set from the data supplier then we need to be keeping a copy of any imported data and creating comparison tools between the original imported data and the updated data from that government/organisation. 3. More data conflation tools. Not all data can be imported in bulk. We need to look at developing more tools to allow for piecemeal imports from the local community. For example the Android app Vespucci *could* be extended/forked to allow the following work flow: 3a. A new "import" dataset is added to a holding database. 3b. On the ground mappers can can then view this database on the ground using Vespucci on their tablet/phone 3c. For each element they mark it as "verified" or "incorrect", and if necessary change the tags or geometry using the tools already built into Vespucci. At this stage Vespucci has not shown any other OSM data, just the holding database layer. This makes it easier to use in areas of high data density. 3d. If the data is just nodes then Vespucci searches for potential matches in the OSM data. Is one is found the user is asked how to merge the two. If not found then the node is imported into OSM. 3e. For ways the user can either work with Vespucci to merge/import the data, or they can log in when back home using JOSM or ID and work with these editing tools to merge the verified data from the holding database. Any other ideas? RobJN _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
