I wonder about checkpoints for "good standing with their communities" on 19 May, "mid-term evaluation" on 23 June and "final evaluation deadline".
Should there be a precise set of what must be be done till 19 May and 23 June, or is it decided based on whatever there is an active development? I assume that to pass "final evaluation deadline" entire project must be delivered, but how the two previous ones are supposed to be handled? I am unsure what I should write as "detailed timeline: how do you plan to spend your summer?". Should I declare when each feature will be finished? Or is it about something else? My proposal is available on http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mateusz_konieczny/5629499534213120 I would appreciate any feedback. > > - what type was previously selected (i.e. if a user had selected a type X > > in the past, then this selection will be assumed as more likely the next > > time) > > Also a good idea although I would see this rather as choosing which item to > highlight. I think that it may be better to avoid forcing user to click in cases when algorithm guessed right without additional data. > Additionally, features with certain tags could and should block routing even > if they just cross the path without sharing a nnode. Think of a gate > (barrier=gate or a military no-go area). I am not sure. In the first case barrier should have either different layer or share node ("If a linear barrier crosses a highway, they must connect with a node at intersection." - from Barriers article on wiki), and in the second road should have access tags. Though both cases are currently not reported as a problem by JOSM validator (I filed ticket for the first case, as wiki is quite clear. Second seems to have no suggested solution on wiki, maybe it should be discussed on tagging mailing list). > - Deal with various tagging variants. Added as part of defining route types ("improving definitions of route types to handle tagging variations"). > - Deal with features intersecting without nodes when they should block > routing. I think that all cases like this are mapping bugs and should be reported by JOSM validator (expecting every single router to parse thing like military no-go areas instead of checking access tags on roads is IMHO a poor idea). > - Make a proper handling of implicit way splitting (may require user action, > but the less the better. Users wouldn't accept to click through hard-to- > understand and possibly multiple modal windows). Added to proposal as "implicit way splitting (for nodes that are in the middle of way), with minimal required user action" > Make a proper Undo (This one being particular important) I am confused here, there is probably no need to revert way selection. Is it about implicit splitting requested during selecting route? I added note about this. > Maybe cope with runtime and/or space constraints I mentioned it in the new proposal version ("algorithm that will find suitable connection in acceptable time, without too high memory usage"). > Making a user interface to handle user-defined connection types, might be a quite large sub-editor). I am not sure is it necessary, I thought that types would be edited like validator rules. Possible to do, but 99,9% of users never needs to do it and others may simply edit text file. > Fitting that into the various JOSM storage ideas (File format, storage in the central JOSM wiki repository, store in local user preferences). Is is about distributing plugin or is it about how it will work? Or maybe both? > - Probably i18n for the interface parts. Now "making translations possible" is mentioned while discussing interface. >- Find sensitive testing case and defend the whole thing on various community > mailing lists (I will assist you, but it is inevitable to meet the real needs > of various local comunities, and inevitable to make the software really > useful). I hope that this one will require changes no bigger than (re)defining route types. > I think it would be helpful to first have it as a plugin and see it in action. OK, I will rework proposal to indicate that it is intended to start as a plugin and mention integration into JOSM trunk as potential future goal. Should I mention public transport plugin in proposal as source of this idea? > I'll have a closer look at your > proposal in the train tomorrow and then comment as soon as I found my Wifi on > the conference venue :) Thanks!
_______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
