<div dir="ltr"><div><div><div><div class="gmail_extra">I wonder about checkpoints for "good standing with their communities" <br>on 19 May, "mid-term evaluation" on 23 June and "final evaluation deadline".<br>


<br></div>Should there be a precise set of what must be be done till 19 May and 23 June, <br>or is it decided based on whatever there is an active development? I assume <br>that to pass "final evaluation deadline" entire project must be delivered, but how <br>


the two previous ones are supposed to be handled?<br></div><div><br>I am unsure what I should write as "detailed timeline: how do you plan to <br>spend your summer?". Should I declare when each feature will be finished? Or<br>


is it about something else?<br><br>My proposal is available on <br><a href="http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mateusz_konieczny/5629499534213120" target="_blank">http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mateusz_konieczny/5629499534213120</a><br>


</div><div>I would appreciate any feedback.<br></div><div><br></div>> > - what type was previously selected (i.e. if a user had selected a type X<br><div>
> >   in the past, then this selection will be assumed as more likely the next<br>
> > time)<br>
><br>
> Also a good idea although I would see this rather as choosing which item to<br>
> highlight.<br><br></div><div>I think that it may be better to avoid forcing user to click in cases when <br></div><div>algorithm guessed right without additional data.<br></div><div><br>> Additionally, features with certain tags could and should block routing even<br>



> if they just cross the path without sharing a nnode. Think of a gate<br>
> (barrier=gate or a military no-go area).<br><br></div>I am not sure. In the first case barrier should have either different layer or <br>share node ("If a linear barrier crosses a highway, they must connect with <br>


a node at intersection." - from Barriers article on wiki), and in the second <br>road should have access tags. Though both cases are currently not <br>reported as a problem by JOSM validator (I filed ticket for the first case, as<br>


wiki is quite clear. Second seems to have no suggested solution on wiki,<br></div><div>maybe it should be discussed on tagging mailing list).<br></div><div><br>> - Deal with various tagging variants.<br><br>Added as part of defining route types ("improving definitions of route types <br>

to handle tagging variations").<br>
<br>> 
- Deal with features intersecting without nodes when they should block<br>
> routing.<br><br></div><div>I think that all cases like this are mapping bugs and should be reported<br>by JOSM validator (expecting every single router to parse thing like military<br></div><div>no-go areas instead of checking access tags on roads is IMHO a poor idea).<br>


</div><div><br>> - Make a proper handling of implicit way splitting (may require user action,<br>
> but the less the better. Users wouldn't accept to click through hard-to-<br>
> understand and possibly multiple modal windows).<br><br></div><div>Added to proposal as "implicit way splitting (for nodes that are in <br>the middle of way), with minimal required user action" <br><br>> Make a proper Undo (This one being particular important)<br>


<br></div><div>I am confused here, there is probably no need to revert way selection.<br>Is it about implicit splitting requested during selecting route? I added <br>note about this.<br></div><div><br>> Maybe cope with runtime and/or space constraints<br>

</div></div><div class="gmail_extra"><br>I mentioned it in the new proposal version ("algorithm that will find <br>
suitable connection in acceptable time, without too high memory usage"). <br></div><div class="gmail_extra"><br>> Making a user interface to handle user-defined connection types, might be a<br>
quite large sub-editor).<br><br>
</div><div class="gmail_extra">I am not sure is it necessary, I thought that types would be edited like validator<br>rules. Possible to do, but 99,9% of users never needs to do it and others<br></div><div class="gmail_extra">


may simply edit text file.<br></div><div class="gmail_extra"><br>> Fitting that into the various JOSM storage ideas (File format, storage in<br>
the central JOSM wiki repository, store in local user preferences).<br>
<br></div><div class="gmail_extra">Is is about distributing plugin or is it about how it will work? Or maybe both?<br></div><div class="gmail_extra"><br>> - Probably i18n for the interface parts.<br><br></div><div class="gmail_extra">


Now "making translations possible" is mentioned while discussing interface.<br></div><div class="gmail_extra"><br>>- Find sensitive testing case and defend the whole thing on various community<br>> mailing lists (I will assist you, but it is inevitable to meet the real needs<br>



> of various local comunities, and inevitable to make the software really<br>
> useful).<br><br></div><div class="gmail_extra">I hope that this one will require changes no bigger than (re)defining route types.<br><br>> I think it would be helpful to first have it as a plugin and see it in action.<br>


<br></div><div class="gmail_extra">OK, I will rework proposal to indicate that it is intended to start as a plugin <br>and mention integration into JOSM trunk as potential future goal.<br><br></div><div class="gmail_extra">


Should I mention public transport plugin in proposal as source of this idea?<br><br>> I'll have a closer look at your<br>> proposal in the train tomorrow and then comment as soon as I found my Wifi on<br>
> the conference venue :)<br><br></div><div class="gmail_extra">Thanks!<br></div></div>