On Tue, Sep 29, 2009 at 10:54 AM, Tom Hughes <t...@compton.nu> wrote: > On 29/09/09 11:24, Frankie Roberto wrote: > >> A more direct way to do it *now* is to suggest specific improvements >> by filing bugs on http://trac.openstreetmap.org under the website >> component. >> >> Okay, will do. I'm always a bit shy about submitting improvement ideas >> as bugs (as it feels like asking someone else to do the work, rather >> than offering to help), but I guess it helps to keep it all in one place. > > Thank you for your reticence! As the person that receives them all the > tickets in question I have much the same feeling, that is just asking for > somebody else to do something.
Generally bug trackers reduce work. They consolidate bugs/feature requests in one place, people can easily search for already filed bugs or see that they're filed already and not bother you again. When I've become interested in helping with some application the bug trackers is usually a very good place to start for getting an idea of what needs to be done or what features are wanted. And when I'm maintaining something I very much like getting lots of enhancements requests. I can prioritize them and turn them into a TODO list. Different projects also have different preferences. I've filed over 100 bugs and enhancement requests to JOSM for instance. Most of who've been fixed already, and they don't seem to mind. But since Trac is set up so that bugs against website are filed as bugs against you personally then perhaps it would be easier for everyone if it were made obvious what sort of things you want filed against the website component in trac. For example at the top of http://trac.openstreetmap.org/newticket >> Linking the tags to the wiki is going to be a great way of joining the >> two things together much more closely. The other thing I'd like to see >> is being able to browse sideways from the 'browse' pages, so that it's >> possible to navigate from, say, a pub, through to other pubs nearby. >> But I guess this requires some more XAPI-like functionality to be added >> to the main server? > > The wiki's full of shit though, so do we really want to encourage people to > believe all the stuff that is there... It sucks, but it's the best description of the tagging system we use. It's not very easy to find if you're a new mapper. I just pretended to be one and I went from: http://openstreetmap.org -> Help & Wiki -> [[Main_Page]] -> [[Map Making]] -> [[Editing]] -> [[Tagging]] -> [[Map Features]] Picking what sounded most likely to tell me how to tag data and presuming that I didn't know what the "Map Features" link in the sidebar meant. Making the wiki more accessible to casual mappers via Potlatch/JOSM will hopefully serve to improve it. And it's honestly not that bad. Most objections to it seem to be that it has some silly voting system or gives an inaccurate idea of the sort of tags we actually do have. That's true, but if you just want to get on with editing and are interested in what goes with amenity=parking which is the use case for most people that use it it works just fine. >> * removing the forward/back links to the way numbered one above and one >> below (as these are essentially just random links) > > Not an unreasonable point. > >> * displaying the address in a more address-like style, perhaps also >> marked up with the hCard microformat. > > I'm not at all sure that we should start getting "clever" about how we > display specific tags - to my mind we are about the data and we should be > tag agnostic and just display the raw data and let the reader draw > conclusions from it. > > Doing "clever stuff" with our data is primarily something for other people > to do, not for us to do. > >> * showing the date that the node/way/relation was first created (rather >> than just date of the last changeset). > > Certainly possible but I'm not sure how much value it has. > >> * making wikipedia=* and website=* links more prominent, possibly with >> icons. > > I think this comes under "clever" rendering again. This sort of thing also helps mappers. If we render the address in a manner which people are used to then they're probably more likely to spot if it's wrong or incomplete and fix the data. Aside from i18n reasons that's why I modified the site to use the name:$lang tags when they're available. But aside from these specific points it's pretty clear that displaying a dump of the raw data we have and providing a pretty page to show incoming users from flickr and other sites are somewhat conflicting goals. Is anyone doing a more friendly rendering of OSM node/ways/relations now that sites like flickr could link to instead? If not that would be a very interesting project for the Wikimedia OSM Toolserver if someone is interested. >> * removing the created_by=* tag and displaying that less prominently, >> perhaps with a link to the Potlatch/JOSM/etc pages on the wiki. > > This is more borderline and I can see some point to it. Could you provide me with the output of: select count(*),v from changeset_tags where k='created_by' group by v order by count desc; Run on the database so that I can implement this for the most common cases. >> * adding some stats like "total length" (for open ways) or "area size" >> (for closed ways). > > Relatively expensive for us to compute though so we would need to be a bit > careful with larger/more complicated objects. Aside from whether that's a good idea I wonder if there's a way to do that in OpenLayers. It already has to load the complete way from the API in order to display it. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
